PowerFlex: Överdriven datarollväxling orsakar IO-latens och fel

Under vissa klustertillståndsövergångar kan MDM-rollbalanslogiken producera snabba, upprepade primära/sekundära rollbyten över många kammar (interna datastrukturer som spårar vilka SDS-noder som lagrar varje del av volymdata). Varje rollväxel ogiltigförklarar kombinationskartor på klientsidan (SDC) och tvingar I/O-återförsök. När tillräckligt många kammar påverkas samtidigt orsakar den kumulativa omprövningen I/O-latenstoppar och I/O-fel på SDC-värdar. Beroende på värdmiljön kan detta resultera i tidsgränser för program-I/O, virtuella datorer som går in i skrivskyddat tillstånd eller att filsystemet inte är tillgängligt.

Det här beteendet har observerats under flera utlösarscenarier och är inte begränsat till någon enskild driftsprocedur.

Gemensamma indikatorer

• MDM_DATA_DEGRADED följt av ihållande I/O-latens på 1–15+ minuter
• SDC-värdar rapporterar I/O-fel och/eller I/O-timeouter under det degraderade fönstret
  • VMware (ESXi): VMFS-pulsslagstimeouter, SCSI-maskinvarufel (sense data: 0x4 0x0 0x0), virtuella datorer som går in i skrivskyddat tillstånd, potentiell HA-failover-funktion
  • Linux: I/O-fel i systemloggar (/var/log/messages, dmesg) kan program uppleva I/O-timeouter eller skrivskyddad återmontering av filsystemet
• MDM-händelseloggar visar att systemet är i DEGRADERAT tillstånd längre än förväntat för en enskild SDS-förlust
• Systemet återställer sig så småningom automatiskt till ett NORMALT tillstånd utan manuella åtgärder (vanligtvis)

Scenario 1: Störande SDS-förlust (inget underhållsläge)

När det kan hända:

• Detta är ett sällsynt scenario. För att snabba, upprepade rollväxlingshändelser ska inträffa under en olycklig SDS-förlust måste flera specifika villkor vara uppfyllda samtidigt:

• • Storskalig miljö – ett stort antal SDS-noder och -volymer
  • I/O-belastning för tung produktion – betydande I/O-aktivitet just nu när SDS misslyckas
  • Återskapa arbetsbelastningen överskrider bearbetningskapaciteten – Antalet metadatarader som kräver återskapande överskrider MDM-balanserarens gräns per cykel på 1 024 rader

Varje ombalanseringscykel kan bearbeta upp till 1 024 metadatarader. När fler rader måste återskapas kan balanseraren inte slutföra den aktuella planen innan nästa genereras.

Vad händer:

• SDS frikopplas abrupt från MDM (händelse SDS_DECOUPLED)
• Alla SDC:er som var anslutna till den SDS:en förlorar sina anslutningar → SDC-frånkopplingshändelser
• MDM-enheten markerar klustret DEGRADERAT (händelse MDM_DATA_DEGRADED)
• Eftersom antalet rader som ska återskapas är över 1 024 kan MDM-balanseraren inte slutföra den aktuella ombalanseringsplanen
• Balanseraren startar en ny plan medan den tidigare planen fortfarande körs, vilket ger snabba, upprepade rollväxlingshändelser
• Klient-SDC:er ser kontinuerliga I/O-fel (IO_FAULT_NOT_PRI, SCSI sense 0x4). När återförsöken är uttömda rapporterar värdoperativsystemet I/O-fel, tidsgränser eller ett skrivskyddat filsystem
• MDM-spårbevis:

När ombalanseringsarbetsbelastningen överskrider gränsen på 1 024 rader visar MDM-spårningen att tröskelvärdet överskrids:

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.

Detta anger att 1 098 rader krävde återskapande, men endast 1 024 kunde bearbetas i den aktuella cykeln. De återstående raderna utlöser en ny ombalanseringsplan innan den tidigare planen slutförs, vilket startar feedbackloopen.

Händelsekedja:

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: SDS-avstängning under PMM-inmatning

När det kan hända:
Detta är ett sällsynt scenario som kräver två samtidiga händelser:

• En SDS aktiveras till skyddat underhållsläge (PMM)
• SDS-värdet slutar fungera eller stängs av innan PMM-övergången har slutförts

Vad händer: 

• MDM tar emot PMM-inmatningskommandot och registrerar det som lyckat
• SDS frikopplas oväntat medan PMM-posten fortfarande pågår
• MDM-enheten markerar klustret som DEGRADERAT
• Rollbalanseraren går in i en varaktig rollväxlingsloop under PMM-ingångsfasen
• Icke-PMM-datarader rollväxlas upprepade gånger över hela lagringspoolen
• Stormen kvarstår tills SDS återansluter till klustret och slutför övergången till underhållsläge

Händelsekedja:

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

Exempel på MDM-händelsesekvens:

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

När SDS ansluts igen och PMM slutförs:

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

Scenario 3: SDS i IMM (Instant Maintenance Mode)

När det kan hända:
En SDS går in i eller avslutar Instant Maintenance Mode (IMM). Det här scenariot inträffar när en enda SDS är i underhållsläge och systemet inte kan avgöra vilken SDS som ska hantera I/O för specifika data.

Vad händer:

• Systemet ändrar upprepade gånger vilket säkerhetsdatablad som ansvarar för att leverera samma data
• Dessa ständiga ändringar innebär att programmen inte vet vart de ska skicka sina I/O-begäranden
• I/O skickas till fel SDS, vilket orsakar omförsök och fördröjningar
• Program upplever svarstider eller tidsgränser när de försöker komma åt berörda data

Påverkan:

• Inverkan på kunden: Program rapporterar svarstider och tidsgränser medan SDS finns i IMM
• Längd: Fortsätter medan SDS är i IMM-läge
• Återhämtning: Automatisk – löses när SDS avslutar IMM

Händelsekedja:

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: SDS – Avsluta skyddat underhållsläge (PMM)

När det kan hända:
En SDS avslutar Protected Maintenance Mode (PMM). Det här scenariot inträffar under varje PMM-avslutning – det är inte en sällsynt händelse, men allvarlighetsgraden beror på hur länge underhållslägesåtgärden varade.

Vad händer:

• När SDS avslutar PMM måste rollbalanseraren omtilldela datasegment för att inkludera den returnerande SDS
• Ombalanseringsprocessen påverkar hela lagringspoolen, inte bara data på den returnerande SDS:en
• Rollbyten sker i många datasegment under återintegreringen
• Program kan uppleva korta I/O-fel eller svarstider när rolltilldelningarna stabiliseras

Påverkan:

• Inverkan på kunden: För korta underhållsfönster (mindre än 5 sekunder) är effekten knappt märkbar. Vid utökat underhåll med aktiv I/O kan tusentals rollbyten ske, vilket orsakar ihållande I/O-stopp
• Längd: Fortsätter under återintegreringsfasen tills ombalanseringen är slutförd
• Återhämtning: Automatisk

Händelsekedja:

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

Exempel på MDM-händelsesekvens:

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

Loggutgångar:
 

MDM-händelseloggar: MDM-händelseloggen visar sekvensen på klusternivå. Nyckelindikatorerna är rollväxlingsåtgärder under avslutningen av underhållsläget.

SDS-spårningsloggar: På SDS-noder visar spårningsloggarna upprepade rollväxlingsåtgärder under återintegreringen:

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

En stor mängd switchrollposter under ett kort tidsfönster (tusentals eller fler inom några sekunder) är den definitiva indikatorn på SDS-sidan för det här problemet.

SDC-/värdloggar: VMware (ESXi) SDC I/O-återförsök som visar kam, mål-SDS och felkod:

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)

Om överbelastning görs igen returneras SCSI-fel: 

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

Diagnostiskt tips: Om du ser I/O-fel på flera SDS-noder (inte bara den nod som hade ett problem) kan detta tyda på en rollväxlingsstorm i stället för normalt beteende vid degraderat tillstånd. Om I/O-fel är isolerade till en enda SDS är detta ett förväntat beteende med försämrat tillstånd.

Scenario 5: Fasövergångar för underhållsläge 

När det kan hända:
Under övergången när en SDS går in i eller avslutar underhållsläge (IMM eller PMM) - i det ögonblick som tillståndet ändras från normalt till MM, eller från MM tillbaka till det normala.

Vad händer:

• Rollbalanseraren omfördelar dataansvar för att hantera ändringen
• Korta skurar av rollbyten inträffar när systemet sätter sig in i det nya arrangemanget
• Program kan uppleva korta latenstoppar under övergången

Påverkan:

• Inverkan på kunden: Korta latenstoppar som varar i sekunder till några minuter. Vanligtvis under tröskelvärdena för tidsgräns för program
• Längd: Varar sekunder till några minuter och sätter sig sedan
• Återhämtning: Automatisk

Händelsekedja:

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

Ett programvarufel i MDM-rollbalanslogiken orsakar en återkopplingsloop när klustret övergår till tillstånd på grund av en SDS-förlust eller underhållslägesåtgärd.

Under vissa förhållanden omtilldelar MDM upprepade gånger vilka SDS-noder som ansvarar för att betjäna I/O till berörda kammar. Varje omtilldelning ogiltigförklarar SDC:s cachelagrade vy över var data finns, vilket tvingar I/O-återförsök. När många kammar påverkas samtidigt överstiger volymen av omtilldelningar SDC:ernas förmåga att uppdatera, vilket resulterar i ihållande I/O-fel över flera värdar.

Stormen är vanligtvis självbegränsande. Den löses när klustret stabiliseras, men varaktigheten beror på storleken på skyddsdomänen och I/O-belastningen vid tidpunkten för händelsen.

Problemet åtgärdas i PowerFlex Core version 4.5.6. Uppgradera till den här versionen när den blir tillgänglig. Kontakta Dells support för information om tidslinjen för lanseringen.

För planerade underhållsåtgärder:

• Starta inte om eller starta om SDS förrän MDM-enheten loggas SDS_MAINTENANCE_MODE_STARTED. Kontrollera att säkerhetsdatabladet har gått helt in i underhållsläge innan du fortsätter med fysiskt underhåll.
• Övervaka svarstidstoppar när du aktiverar eller avslutar underhållsläge.

För oplanerade SDS-avbrott:

• Stormen är självbegränsande och löses vanligtvis inom några minuter när klustret stabiliseras. Om problemet observeras samlar du in getinfo loggar från alla SDS-noder i skyddsdomänen, från All Manager MDM-enheter så snart som möjligt efter händelsen och kontakta Dells support.

I sällsynta fall där problemet inte löser sig självt kan MDM-enheten stabiliseras tillfälligt genom att inaktivera och återaktivera återskapandet:

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

# Vänta 5-10 sekunder och aktivera sedan rebuild: 

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