PowerFlex: Un eccessivo cambio di ruolo dei dati causa latenza ed errori di I/O

In determinate transizioni di stato del cluster, la logica di bilanciamento dei ruoli MDM può produrre rapidi e ripetuti switch dei ruoli primari/secondari su molti comb (strutture di dati interne che tengono traccia dei nodi SDS che archiviano ogni parte dei dati del volume). Ogni cambio di ruolo invalida le mappe comb lato client (SDC) e forza i tentativi di I/O. Quando un numero sufficiente di COMB è interessato contemporaneamente, l'overhead cumulativo dei tentativi causa picchi di latenza di I/O ed errori di I/O sugli host SDC. A seconda dell'ambiente host, ciò può causare timeout di I/O delle applicazioni, VM che passano allo stato read-only o non disponibilità del file system.

Questo comportamento è stato osservato in più scenari di attivazione e non è limitato a una singola procedura operativa.

Indicatori comuni

• MDM_DATA_DEGRADED seguito da una latenza I/O sostenuta della durata di 1-15+ minuti
• Gli host SDC segnalano errori di I/O e/o timeout di I/O durante la finestra danneggiata
  • VMware (ESXi): Timeout heartbeat VMFS, errori hardware SCSI (sense data: 0x4 0x0 0x0), macchine virtuali che entrano nello stato read-only, potenziale failover HA
  • Linux: Errori di I/O nei registri di sistema (/var/log/messages, dmesg), le applicazioni potrebbero riscontrare timeout di I/O o rimounting del file system read-only
• I registri eventi MDM mostrano il sistema in stato DEGRADED più a lungo del previsto per una singola perdita di SDS
• Il sistema alla fine si ripristina automaticamente a uno stato NORMAL senza alcun intervento manuale (di solito)

Scenario 1: Perdita anomala dell SDS (nessuna modalità di manutenzione)

Quando può accadere:

• Si tratta di uno scenario raro. Affinché gli eventi di cambio ruolo rapidi e ripetuti si verifichino durante una perdita scorretta dell SDS, devono essere presenti contemporaneamente diverse condizioni specifiche:

• • Ambiente su larga scala: numero significativo di nodi e volumi SDS
  • Carico I/O di produzione pesante: attività I/O significativa nel momento in cui l SDS si guasta
  • Il carico di lavoro di ricostruzione supera la capacità di elaborazione: il numero di righe di metadati che richiedono la ricostruzione supera il limite per ciclo del bilanciatore MDM di 1.024 righe

Ogni ciclo di ribilanciamento può elaborare fino a 1.024 righe di metadati. Quando è necessario ricostruire più righe, il bilanciatore non può completare il piano corrente prima di generare quello successivo.

Che succede:

• L SDS si disaccoppia bruscamente dall MDM (evento SDS_DECOUPLED)
• Tutti gli SDC connessi a tale SDS perdono le connessioni → eventi di disconnessione dell SDC
• MDM contrassegna il cluster come DEGRADED (evento MDM_DATA_DEGRADED)
• Poiché il numero di righe da ricostruire è superiore a 1.024, il bilanciatore MDM non può completare il piano di ribilanciamento corrente
• Il bilanciatore avvia un nuovo piano mentre il piano precedente è ancora in esecuzione, producendo eventi rapidi e ripetuti di scambio di ruolo
• Gli SDC client riscontrano errori I/O continui (IO_FAULT_NOT_PRI, SCSI sense 0x4). Una volta esauriti i tentativi, il sistema operativo host segnala errori di I/O, timeout o un file system read-only
• Evidenze di tracce MDM:

Quando il carico di lavoro di ribilanciamento supera il limite di 1.024 righe, la traccia MDM mostra la soglia superata:

2026/03/28 22:43:53.246702 MED:7f1f984aedb0:balanceExec_HandleDegradedRows:00343: BALANCER: Storage Pool: 1193844800000000 - 1024 rows processed out of 1098 degraded rows. 0 allocation failures. 0 cumulative allocation failures.

Ciò indica che 1.098 righe richiedevano la ricostruzione, ma solo 1.024 potevano essere elaborate nel ciclo corrente. Le righe rimanenti attivano un nuovo piano di ribilanciamento prima del completamento del piano precedente, avviando il ciclo di feedback.

Catena di eventi:

Log Source     Event / Pattern
MDM events     SDS_DECOUPLED — SDS formally declared dead
MDM events     MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces     Flood of IO_FAULT_NOT_PRI — SDS received IO for a comb it is no longer primary for
ESXi vmkernel  SCSI sense data: 0x4 0x0 0x0 — Hardware error
MDM events     MULTIPLE_SDC_CONNECTIVITY_CHANGES — Mass SDC connectivity storm
MDM events     SDC_DISCONNECTED_FROM_SDS_IP — SDCs losing contact with the failed SDS

SDC_DISCONNECTED_FROM_SDS_IP    SDC disconnected from SDS <name>
SDS_DECOUPLED                   SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

Scenario 2: Spegnimento dell SDS durante l'ingresso della PMM

Quando può accadere:
Si tratta di uno scenario raro che richiede due eventi simultanei:

• Un SDS sta entrando in modalità di manutenzione protetta (PMM)
• L SDS si guasta o viene spento prima del completamento della transizione PMM

Che succede: 

• MDM riceve il comando di immissione PMM e lo registra come completato
• L SDS si separa in modo imprevisto mentre la voce PMM è ancora in corso
• MDM contrassegna il cluster come DEGRADED
• Il bilanciamento dei ruoli entra in un ciclo di scambio di ruoli sostenuto per tutta la fase di ingresso della PMM
• Le righe di dati non PMM vengono ripetutamente commutate a livello di ruolo nell'intero pool di storage
• La storm persiste fino a quando l SDS non si ricongiunge al cluster e completa la transizione della modalità di manutenzione

Catena di eventi:

Log Source  Event / Pattern
MDM events  CLI_COMMAND_SUCCEEDED — enter_protected_maintenance_mode command succeeded
MDM events  SDS_DECOUPLED — SDS decoupled before maintenance mode started
MDM events  MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces  Repeated role-switch operations across non-PMM rows

Esempio di sequenza di eventi MDM:

CLI_COMMAND_SUCCEEDED            Command enter_protected_maintenance_mode succeeded
SDS_DECOUPLED                    SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

Quando l SDS si ricongiunge e la PMM viene completata:

SDS_MAINTENANCE_MODE_STARTED     SDS maintenance mode started
MDM_DATA_NORMAL                 The system is now in NORMAL state

Scenario 3: SDS in modalità di manutenzione istantanea (IMM)

Quando può accadere:
Un SDS entra o esce dalla modalità di manutenzione istantanea (IMM). Questo scenario si verifica quando un singolo SDS è in modalità di manutenzione e il sistema non è in grado di decidere quale SDS deve gestire l'I/O per dati specifici.

Che succede:

• Il sistema modifica ripetutamente quale SDS è responsabile della gestione degli stessi dati
• Grazie a questi continui cambiamenti, le applicazioni non sanno dove inviare le richieste di I/O
• L'I/O viene inviato all SDS errato, causando nuovi tentativi e ritardi
• Le applicazioni riscontrano latenza o timeout durante il tentativo di accedere ai dati interessati

Impatto:

• Impatto sul cliente: Le applicazioni segnalano latenza e timeout mentre l SDS è nell'IMM
• Durata: Continua mentre l SDS è nello stato IMM
• Recupero: Automatico: si risolve quando l SDS esce dall'IMM

Catena di eventi:

Log Source  Event / Pattern
SDS traces  Repeated role-switch operations on the same data
SDS traces  Primary and secondary role switches on identical data

Scenario 4: Uscita dell SDS dalla modalità di manutenzione protetta (PMM)

Quando può accadere:
Un SDS esce dalla modalità di manutenzione protetta (PMM). Questo scenario si verifica durante ogni uscita dalla PMM: non è un evento raro, ma la gravità dipende da quanto tempo è durata l'operazione in modalità di manutenzione.

Che succede:

• Quando l SDS esce dalla PMM, il bilanciamento dei ruoli deve riassegnare i segmenti di dati per includere l SDS di ritorno
• Il processo di ribilanciamento interessa l'intero pool di storage, non solo i dati sull SDS di ritorno
• Gli scambi di ruolo si verificano in molti segmenti di dati durante la reintegrazione
• Le applicazioni potrebbero riscontrare brevi errori di I/O o latenza mentre le assegnazioni dei ruoli si stabilizzano

Impatto:

• Impatto sul cliente: Per brevi finestre di manutenzione (meno di 5 secondi), l'impatto è appena percettibile. Per la manutenzione estesa con I/O attivo, possono verificarsi migliaia di scambi di ruoli, causando blocchi I/O prolungati
• Durata: Continua durante la fase di reintegrazione fino al completamento del riequilibrio
• Recupero: Automatico

Catena di eventi:

Log Source  Event / Pattern
MDM events  Role-switch operations across the storage pool during exit
SDS traces  Repeated role-switch operations during reintegration

Esempio di sequenza di eventi MDM:

SDS_MAINTENANCE_MODE_EXIT_STARTED    SDS maintenance mode exit started
SDS_MAINTENANCE_MODE_EXIT_COMPLETED   SDS maintenance mode exit completed

Output registro:
 

Registri eventi MDM: Il registro eventi MDM mostra la sequenza a livello di cluster. Gli indicatori chiave sono operazioni di cambio di ruolo durante l'uscita dalla modalità di manutenzione.

Registri di traccia SDS: Nei nodi SDS, i registri di traccia mostrano ripetute operazioni di scambio di ruoli durante la reintegrazione:

raidComb_SetPriTgtGenNum: combId <id> combGenNum: cur <gen> new <gen>
contCmd_SetCombState: CombId <id> devId <id> PRI->SEC Switch roles
contCmd_SetCombState: CombId <id> devId <id> SEC->PRI Switch roles

Un volume elevato di voci di ruoli switch in una breve finestra temporale (migliaia o più in pochi secondi) è l'indicatore definitivo di questo problema sul lato SDS.

Registri SDC/host: Tentativi di I/O SDC vmware (ESXi) che mostrano comb, SDS di destinazione e codice di errore:

vmkernel log
PowerFlex mapVolIO_Do_CK:1496 :Mit: <addr>. Retrying IO Type WRITE. Failed comb: <id>. SDS_ID <id>. Comb Gen <gen>. Head Gen <gen>.
PowerFlex mapVolIO_Do_CK:1510 :Mit: <addr>. Vol ID <id>. Last fault Status IO_FAULT_NOT_PRI(12). Retry count (1)

Se i nuovi tentativi si esauriscono, vengono restituiti gli errori SCSI: 

sense data: 0x4 0x0 0x0   -- SCSI Hardware Error

Suggerimento diagnostico: Se si riscontrano errori di I/O su più nodi SDS (non solo sul nodo che ha avuto un problema), ciò potrebbe indicare una tempesta di switch di ruoli piuttosto che un normale comportamento in stato danneggiato. Se gli errori di I/O sono isolati su un singolo SDS, si tratta di un comportamento previsto in uno stato danneggiato.

Scenario 5: Transizioni di fase della modalità di manutenzione 

Quando può accadere:
Durante la transizione, quando un SDS entra o esce dalla modalità di manutenzione (IMM o PMM), al momento lo stato cambia da normale a MM o da MM di nuovo a normale.

Che succede:

• Il bilanciamento dei ruoli ridistribuisce le responsabilità dei dati per supportare la modifica
• Si verificano brevi picchi di scambio di ruoli man mano che il sistema si assesta sulla nuova disposizione
• Le applicazioni potrebbero riscontrare brevi picchi di latenza durante la transizione

Impatto:

• Impatto sul cliente: Brevi picchi di latenza che durano da pochi secondi a pochi minuti. Generalmente al di sotto delle soglie di timeout delle applicazioni
• Durata: Dura da pochi secondi a pochi minuti, poi si assesta
• Recupero: Automatico

Catena di eventi:

Log Source  Event / Pattern
SDS traces  Brief role-switch operations during phase transitions

Un difetto software nella logica di bilanciamento dei ruoli dell MDM causa un loop di feedback quando il cluster cambia stato a causa di una perdita dell SDS o di un funzionamento in modalità di manutenzione.

In determinate condizioni, l MDM riassegna ripetutamente i nodi SDS responsabili della gestione dell'I/O ai pettini interessati. Ogni riassegnazione invalida la vista memorizzata nella cache dell SDC della posizione in cui si trovano i dati, forzando i tentativi di I/O. Quando sono interessate molte combinazioni contemporaneamente, il volume delle riassegnazioni supera la capacità di aggiornamento degli SDC, con conseguente prolungamento degli errori di I/O su più host.

La tempesta è in genere autolimitante. Il processo si risolve una volta stabilizzato il cluster, ma la durata dipende dalle dimensioni del dominio di protezione e dal carico di I/O al momento dell'evento.

Questo problema è stato risolto in PowerFlex Core versione 4.5.6. Esegui l'upgrade a questa versione non appena disponibile. Per informazioni sulle tempistiche di rilascio, contattare il supporto Dell .

Per le operazioni di manutenzione pianificata:

• Non spegnere e riaccendere o riavviare un SDS fino a quando MDM non registra SDS_MAINTENANCE_MODE_STARTED. Verificare che l SDS sia entrato completamente in modalità di manutenzione prima di procedere con la manutenzione fisica.
• Monitorare i picchi di latenza quando si entra o si esce dalla modalità di manutenzione.

Per le interruzioni non pianificate dell'SDS:

• La tempesta è autolimitante e in genere si risolve in pochi minuti quando l'ammasso si stabilizza. Se si verifica il problema, raccogliere getinfo registri da tutti i nodi SDS nel dominio di protezione, da tutti gli MDM di gestione il prima possibile dopo l'evento e contattare il supporto Dell.

Nei rari casi in cui il problema non si risolve automaticamente, la disabilitazione temporanea e la riabilitazione della ricostruzione possono consentire a MDM di stabilizzarsi:

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --disable_rebuild

# Attendere 5-10 secondi, quindi abilitare la ricostruzione: 

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --enable_rebuild