PowerFlex 3.x: la migrazione vTree può causare un errore irreversibile o un blocco dell SDS

Nella versione 3.6.7 di PowerFlex, durante una migrazione vTree pianificata, si verifica un errore irreversibile di più SDS, causando l'ingresso di uno stato di non disponibilità dei dati nel sistema.

A causa dei ritardi nella migrazione, il consumo di capacità del pool di storage (SP) aumenta rapidamente e può raggiungere il pieno utilizzo in un breve periodo di tempo.

Eventi 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.

I registri di traccia su tutti i nodi SDS interessati generano la stessa traccia dello stack con errore irreversibile:

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]

Nelle versioni di PowerFlex precedenti alla 3.6.7, durante una migrazione vTree pianificata, l'avanzamento della migrazione si blocca e non viene mai completato.

Nell'interfaccia utente > di PowerFlex Manager Running Storage Jobs, viene visualizzato Loading infinito:

query_vtree_migration l'output mostra la percentuale di avanzamento che non cambia:

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%

Impatto

Nelle versioni precedenti alla 3.6.7, la migrazione dei volumi non termina mai, l'utilizzo della capacità degli SP è critico o superiore e le applicazioni potrebbero riscontrare errori di I/O.

Nella versione 3.6.7, non disponibilità dei dati.

Questo problema è causato da una race condition multi-thread che coinvolge un meccanismo di timer condiviso all'interno del componente pulitore VAE (Volume Allocation Element) durante le operazioni di migrazione dei volumi.

Nelle versioni di PowerFlex precedenti alla 3.6.7, veniva utilizzato un processo di pulizia asincrona per eliminare i dati dalle vecchie posizioni degli SP dopo una migrazione. In rare condizioni, ad esempio operazioni di gestione simultanee dei volumi, eliminazioni simultanee di volumi, elevato carico di I/O o instabilità di rete, questo processo potrebbe riscontrare una race condition che fa sì che le migrazioni appaiano bloccate a tempo indeterminato.

Per risolvere questo problema, nella versione 3.6.7 è stato introdotto un meccanismo di monitoraggio avanzato. Questo meccanismo di sicurezza era dotato di un timer progettato per rilevare un thread di pulizia VAE bloccato e causare in modo proattivo un errore irreversibile del servizio SDS per evitare il danneggiamento dei dati o stalli prolungati, in modo simile a come il sistema gestisce i comandi I/O o MDM bloccati.

Tuttavia, nell'implementazione iniziale di questa correzione, il timer di monitoraggio è stato inizializzato solo una volta durante la costruzione dei dati di migrazione ed è stato condiviso a livello globale in tutte le successive chiamate VAE cleaner. Quando più thread in background tentano di accedere contemporaneamente a questo singolo timer condiviso durante carichi di lavoro di migrazione intensivi, viene attivata una nuova race condition. Questo accesso simultaneo fa sì che il meccanismo di tracciamento contrassegni erroneamente VAE Cleaner come bloccato, con conseguenti arresti anomali involontari del servizio SDS e interruzioni localizzate dell'availability dei dati, con conseguente non disponibilità dei dati.

Correzione permanente (consigliata)

Aggiornare il cluster a PowerFlex 3.6.7.1 o versione successiva. La correzione per entrambe le condizioni di VAE-cleaner e timer race è inclusa.

Soluzione alternativa (se l'aggiornamento non può essere eseguito immediatamente)

Nelle versioni precedenti alla 3.6.7

1. Sull MDM primario, passare alla directory dei registri di traccia individuata in /opt/emc/scaleio/mdm/logs/. Per trovare il registro di traccia corrente, eseguire ls -ltr, quindi l'ultima trc.z.* log è elencato nella parte inferiore dell'elenco.
2. Poiché i log vengono compressi, utilizzare il comando trace_decompress utilità situata all'indirizzo /opt/emc/scaleio/mdm/bin/

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

3. Filtrare per l'ID SDS (ad esempio, TGT) voci. Utilizzare il tasto grep comando per trovare:

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

4. Identificare la TGT. Nell'output filtrato cercare righe simili alle seguenti:

TGT 41a903f100000036 not done yet

Se il TGT L'ID rimane coerente nel tempo ed è probabile che corrisponda al nodo SDS coinvolto. Eseguire nuovamente il passaggio 3 per verificare che rimanga coerente.

5. Eseguire il seguente comando per elencare tutti i nodi SDS e far corrispondere TGT ID con nome/indirizzo IP dell SDS:

scli --query_all_sds

6. Una volta ottenute le informazioni necessarie, è possibile SSH a tale SDS e riavviare il servizio SDS eseguendo:

pkill sds

Nella versione 3.6.7

• Serializzare le operazioni di gestione dei volumi: eseguire solo un'eliminazione, un ridimensionamento o una migrazione alla volta.
• Ridurre il carico di I/O sui domini di protezione interessati durante l'esecuzione delle migrazioni.
• Evitare migrazioni vTree in blocco; Distribuiscili in piccoli gruppi.
• Non sospendere o annullare una migrazione quando la rete mostra instabilità.

Queste azioni riducono la probabilità di utilizzo simultaneo del timer e quindi riducono gli eventi di errore irreversibile.

Versioni interessate

PowerFlex Core 3.x.x.x

Risolto nella versione

PowerFlex Core 3.6.7.1