PowerFlex 3.x: Vツリーの移行によりSDSのパニックまたはハングが発生する可能性がある

PowerFlexバージョン3.6.7では、スケジュールされたVツリーの移行中に、複数のSDSがパニック状態になり、システムがデータ欠損状態になります。

移行の遅延の結果として、ストレージ プール(SP)の容量消費量が急速に増加し、短期間で完全な使用率に達する可能性があります。

MDMイベント:

2026-06-30 07:27:19.340 SDS_DECOUPLED ERROR SDS: SDS11 (id: 64cb920800000006) decoupled.
2026-06-30 07:27:19.465 MDM_DATA_DEGRADED ERROR The system is now in DEGRADED state
....
2026-06-30 07:32:20.638 SDS_DECOUPLED ERROR SDS: SDS9 (id: 64cb920b00000009) decoupled.
2026-06-30 07:32:20.638 SDS_DECOUPLED ERROR SDS: SDS12 (id: 64cb920a00000008) decoupled.
2026-06-30 07:32:21.842 MDM_DATA_FAILED CRITICAL The system is now in DATA FAILURE state. Some data is unavailable
...
2026-06-30 07:32:23.538 DEV_CAPACITY_USAGE_CRITICAL ERROR Capacity usage on Protection Domain PD1, Storage Pool FGSP_01 is CRITICAL.
2026-06-30 07:32:23.605 DEV_CAPACITY_USAGE_FULL ERROR Capacity usage on Protection Domain PD1, Storage Pool FGSP_02 is FULL.

影響を受けるすべてのSDSノードのトレース ログは、同じパニック スタック トレースを生成します。

2026/07/01 17:45:33.506630 Panic in file /data/build/workspace/ScaleIO-Common-Job/src/mos/mos_timer.c, line 437, function mosTimerReq_AddByQ, PID 1291427.Panic Expression pReq->state == MOS_TIMER_REQ_STATE__IDLE .
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(mosDbg_PanicPrepare+0xe5) [0x932ce5]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(mosTimerReq_AddByQ+0x143) [0x917043]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(vaeCleaner_CleanVae+0x64) [0x668904]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(head_removeVae+0x170) [0x545e00]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(head_Update+0x373) [0x546363]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contHead_UpdateFull+0x69) [0x4db689]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contCmd_AddHead+0x18a) [0x60d85a]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contCmd_AddHeadGroup+0x100) [0x61b630]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contCmd_NewRequest+0x15fd) [0x62b96d]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contNet_RecvRequest+0xd0) [0x4ce880]

3.6.7より前のPowerFlexバージョンでは、スケジュール設定されたVツリーの移行中に、移行の進行状況がハングし、完了しません。

Running Storage Jobs>PowerFlex Manager UIに、次のようにLoadingと表示されます。

query_vtree_migration 出力には、進行状況のパーセンテージが変化しないことが示されています。

scli --query_vtree_migration --volume_id 53b80e00000000d1
VTree ID: ba46bf57000000d1 Name: PDC-GC-LNX-N-01-PFSP01-01-V043
    Storage Pool 5f2f4acc00000000 Name: PDC-FLEX-LNX-SP01
    Protection Domain 908ff43700000000 Name: PDC-FLEX-LNX-PD01
    Data layout: Medium granularity
    Provisioning: Thin
    Total capacity in use: 504.7 GB (516787 MB)
    Total user data: 504.7 GB (516787 MB)
            Total base user data: 504.7 GB (516787 MB)
            Total snapshots user data: 0 Bytes
    VTree migration info:
            Migration status: Migrating
            Source:      Storage Pool: PDC-FLEX-LNX-SP01 ID: 5f2f4acc00000000 Protection Domain: PDC-FLEX-LNX-PD01 ID: 908ff43700000000
            Destination: Storage Pool: PDC-FLEX-LNX-SP03 ID: 5f2fe70d00000004 Protection Domain: PDC-FLEX-LNX-PD03 ID: 9090907800000003
            Conversion type: No conversion
            Queue position: 1
            Progress percentage : 34%

効果

3.6.7より前のバージョンでは、ボリュームの移行が終了せず、SP容量使用率がクリティカルまたはそれ以上になり、アプリケーションでI/Oエラーが発生することがあります。

バージョン3.6.7では、データ欠損。

この問題は、ボリューム移行操作中にVolume Allocation Element (VAE)クリーナー コンポーネント内の共有タイマー メカニズムに関連するマルチスレッド競合状態が原因で発生します。

3.6.7より前のPowerFlexバージョンでは、非同期クリーンアップ プロセスを使用して、移行後に古いSPの場所からデータを削除していました。同時ボリューム管理操作、ボリュームの同時削除、高いI/O負荷、ネットワークの不安定性など、まれな条件下では、このプロセスで競合状態が発生し、移行が無期限に停止しているように見えることがあります。

この問題に対処するために、バージョン3.6.7では強化されたモニタリング メカニズムが導入されました。この安全メカニズムは、スタックしたVAEクリーナー スレッドを検出し、SDSサービスをプロアクティブにパニック状態にしてデータの破損や長時間のストールを防ぐように設計されたタイマーを備えていました。これは、システムがスタックしたI/OまたはMDMコマンドを処理するのと同様です。

ただし、この修正の初期実装では、モニタリング タイマーは移行データの構築中に一度だけ初期化され、後続のすべてのVAEクリーナー呼び出しでグローバルに共有されていました。大量の移行ワークロード中に、複数のバックグラウンド スレッドがこの 1 つの共有タイマーに同時にアクセスしようとすると、新しい競合状態がトリガーされます。このコンカレント アクセスにより、トラッキング メカニズムがVAEクリーナーにスタックとして誤ってフラグを付け、意図しないSDSサービスのクラッシュやデータの可用性に対する局所的な中断が発生し、データが使用不可になります。

恒久対策(推奨)

クラスターをPowerFlex 3.6.7.1以降にアップグレードします。VAEクリーナーとタイマーの競合状態に対する修正が含まれています。

回避策(アップグレードをすぐに実行できない場合)

3.6.7より前のバージョン

1. プライマリーMDMで、にあるトレース ログ ディレクトリーに移動します。 /opt/emc/scaleio/mdm/logs/。現在のトレース ログを検索するには、次のコマンドを実行します。 ls -ltrなので、最新の trc.z.* ログはリストの一番下に表示されます。
2. ログは圧縮されているため、 trace_decompress ユーティリティは次の場所にあります。 /opt/emc/scaleio/mdm/bin/

tail -f <current_trace_log> | /opt/emc/scaleio/mdm/bin/trace_decompress

3. SDS IDのフィルター(例: TGT)エントリに記入します。コマンド grep 検索するコマンド:

tail -f <current_trace_log> | /opt/emc/scaleio/mdm/bin/trace_decompress | grep volumeBlock_HandleQueryCleanVaeResponse

4. の特定 TGT。フィルタリングされた出力で、次のような行を探します。

TGT 41a903f100000036 not done yet

「Fusion」 TGT IDは時間が経過しても一貫性が保たれ、関連するSDSノードに対応している可能性があります。手順3を再実行して、整合性が保たれていることを確認します。

5. 次のコマンドを実行して、すべてのSDSノードを一覧表示し、 TGT SDS名/IPアドレスを持つID:

scli --query_all_sds

6. 必要な情報が揃ったら、次は SSH をそのSDSに追加し、次のコマンドを実行してSDSサービスを再起動します。

pkill sds

バージョン3.6.7の場合

• ボリューム管理操作を逐次化:一度に1つの削除、サイズ変更、移行のみを実行します。
• 移行の実行中に、影響を受ける保護ドメインのI/O負荷を軽減します。
• Vツリーの一括移行は避けてください。それらを小さなグループに分けてバッチ処理します。
• ネットワークが不安定な場合は、移行を一時停止またはキャンセルしないでください。

これらのアクションにより、タイマーが同時に使用される可能性が低くなり、パニックの発生が減少します。

問題が発生するバージョン

PowerFlexコア3.x.x.x

修正バージョン

PowerFlexコア3.6.7.1