PowerFlex 3.x: vTree-Migration kann zu einem SDS-Fehler oder -Absturz führen

In PowerFlex Version 3.6.7 treten während einer geplanten vTree-Migration bei mehreren SDSs Fehler auf, was dazu führt, dass das System in den Status "Nichtverfügbarkeit von Daten" wechselt.

Infolge der Verzögerungen bei der Migration steigt der Kapazitätsverbrauch des Storage-Pools (SP) rapide an und die vollständige Auslastung kann innerhalb kurzer Zeit erreicht werden.

MDM-Ereignisse:

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.

Trace-Protokolle auf allen betroffenen SDS-Nodes erzeugen dieselbe Panic-Stack-Ablaufverfolgung:

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]

In PowerFlex-Versionen vor 3.6.7 hängt der Migrationsprozess während einer geplanten vTree-Migration und wird nie abgeschlossen.

In der PowerFlex Manager-Benutzeroberfläche > Running Storage Jobs wird Folgendes angezeigt: Endloses Laden:

query_vtree_migration Die Ausgabe zeigt den Fortschrittsprozentsatz an, der sich nie ändert:

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%

Auswirkungen

Bei Versionen vor 3.6.7 endet die Volume-Migration nie, die Kapazitätsauslastung des SP ist kritisch oder höher und bei Anwendungen können I/O-Fehler auftreten.

Bei Version 3.6.7 Nichtverfügbarkeit von Daten.

Dieses Problem wird durch eine Multithread-Wettlaufbedingung verursacht, bei der ein gemeinsamer Zeitgebermechanismus innerhalb der VAE-Bereinigungskomponente (Volume Allocation Element) während Volume-Migrationsvorgängen beteiligt ist.

In PowerFlex-Versionen vor 3.6.7 wurde ein asynchroner Bereinigungsprozess verwendet, um Daten von alten SP-Speicherorten nach einer Migration zu löschen. In seltenen Fällen, z. B. bei gleichzeitigen Volume-Managementvorgängen, gleichzeitigen Volume-Löschungen, hoher I/O-Last oder Netzwerkinstabilität, kann es bei diesem Prozess zu einer Race-Bedingung kommen, die dazu führt, dass Migrationen auf unbestimmte Zeit festgefahren erscheinen.

Um dies zu beheben, wurde in Version 3.6.7 ein erweiterter Überwachungsmechanismus eingeführt. Dieser Sicherheitsmechanismus verfügte über einen Timer, der einen festsitzenden VAE-Reinigungsthread erkennt und den SDS-Service proaktiv in eine Panik versetzt, um Datenbeschädigungen oder längere Verzögerungen zu verhindern, ähnlich wie das System stecken gebliebene I/O- oder MDM-Befehle verarbeitet.

Bei der anfänglichen Implementierung dieses Fixes wurde der Überwachungszeitgeber jedoch nur einmal während der Erstellung der Migrationsdaten initialisiert und global für alle nachfolgenden VAE-Bereinigungsaufrufe freigegeben. Wenn mehrere Hintergrund-Threads versuchen, während hoher Migrations-Workloads gleichzeitig auf diesen einzelnen freigegebenen Timer zuzugreifen, wird eine neue Wettlaufbedingung ausgelöst. Dieser gleichzeitige Zugriff führt dazu, dass der Tracking-Mechanismus den VAE-Cleaner fälschlicherweise als nicht mehr funktionstüchtig kennzeichnet, was zu unbeabsichtigten SDS-Serviceabstürzen und einer lokalen Unterbrechung der Datenverfügbarkeit führt, was wiederum zu einer Nichtverfügbarkeit von Daten führt.

Dauerhafte Korrektur (empfohlen)

Führen Sie ein Upgrade des Clusters auf PowerFlex 3.6.7.1 oder höher durch. Die Korrektur sowohl für die VAE-Cleaner- als auch für die Timer-Rennbedingungen ist enthalten.

Workaround (wenn das Upgrade nicht sofort durchgeführt werden kann)

Auf Versionen vor 3.6.7

1. Navigieren Sie auf dem primären MDM zum Ablaufverfolgungsprotokollverzeichnis unter /opt/emc/scaleio/mdm/logs/. Führen Sie Folgendes aus, um das aktuelle Ablaufverfolgungsprotokoll zu finden: ls -ltr, also das neueste trc.z.* Das Protokoll wird am Ende der Liste aufgeführt.
2. Da Protokolle komprimiert sind, verwenden Sie die trace_decompress Dienstprogramm befindet sich unter /opt/emc/scaleio/mdm/bin/

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

3. Filter für SDS-ID (z. B. TGT) ein. Wählen Sie die grep Befehl zum Suchen:

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

4. Identifizieren Sie die TGT. Suchen Sie in der gefilterten Ausgabe nach Zeilen, die den folgenden ähneln:

TGT 41a903f100000036 not done yet

Wenn die TGT Die ID bleibt im Laufe der Zeit konsistent und entspricht wahrscheinlich dem beteiligten SDS-Node. Führen Sie Schritt 3 erneut aus, um zu bestätigen, dass konsistent ist.

5. Führen Sie den folgenden Befehl aus, um alle SDS-Nodes aufzulisten und die TGT ID mit SDS-Name/IP-Adresse:

scli --query_all_sds

6. Sobald Sie die erforderlichen Informationen haben, können Sie SSH zu diesem SDS und starten Sie den SDS-Service neu, indem Sie Folgendes ausführen:

pkill sds

Für Version 3.6.7

• Serialisieren Sie Volume-Managementvorgänge: Führen Sie jeweils nur einen Löschvorgang, eine Größenänderung oder eine Migration aus.
• Reduzieren Sie die I/O-Last auf den betroffenen Schutzdomains, während Migrationen ausgeführt werden.
• Vermeiden von vTree-Massenmigrationen Verteilen Sie sie in kleine Gruppen.
• Halten oder brechen Sie eine Migration nicht an, wenn das Netzwerk instabil ist.

Diese Aktionen verringern die Wahrscheinlichkeit der gleichzeitigen Verwendung des Timers und reduzieren somit das Auftreten von Fehlern.

Betroffene Versionen

PowerFlex Core 3.x.x.x

Behoben in Version

PowerFlex Core 3.6.7.1