PowerFlex: Overdreven skift af dataroller forårsager IO-ventetid og fejl

Under visse klyngetilstandsovergange kan MDM-rollebalancelogikken producere hurtige, gentagne primære/sekundære rolleskift på tværs af mange kamme (interne datastrukturer, der sporer, hvilke SDS-noder der gemmer hvert stykke enhedsdata). Hver rolleswitch ugyldiggør kamtilknytninger på klientsiden (SDC) og tvinger I/O til at trække sig tilbage. Når nok kamme påvirkes samtidigt, forårsager de kumulative omkostninger til genforsøg I/O-ventetidspidser og I/O-fejl på SDC-værter. Afhængigt af værtsmiljøet kan dette resultere i program-I/O-timeouts, VM'er i skrivebeskyttet tilstand eller filsystemets utilgængelighed.

Denne funktionsmåde er observeret under flere udløsningsscenarier og er ikke begrænset til en enkelt driftsprocedure.

Fælles indikatorer

• MDM_DATA_DEGRADED hændelse efterfulgt af vedvarende I/O-ventetid, der varede 1-15+ minutter
• SDC-værter rapporterer I/O-fejl og/eller I/O-timeouts i det forringede vindue
  • VMware (ESXi): VMFS-timeout for hjerteslag, SCSI-hardwarefejl (sense data: 0x4 0x0 0x0), VM'er, der går i skrivebeskyttet tilstand, potentiel HA-failover
  • Linux: I/O-fejl i systemlogfiler (/var/log/messages, dmesg), kan programmer opleve I/O-timeouts eller skrivebeskyttet genmontering af filsystemet
• MDM-hændelseslogfiler viser systemet i DEGRADERET tilstand længere end forventet for et enkelt SDS-tab
• Systemet genopretter til sidst sig selv til en NORMAL tilstand uden manuel indgriben (normalt)

Scenarie 1: Ukontrolleret SDS-tab (ingen vedligeholdelsestilstand)

Hvornår kan det ske:

• Dette er et sjældent scenario. For at de hurtige, gentagne rolleskifthændelser kan forekomme under et ukontrolleret SDS-tab, skal flere specifikke betingelser være til stede samtidigt:

• • Storskala miljø - Betydeligt antal SDS-noder og diskenheder
  • Tung produktion I/O-belastning - Betydelig I/O-aktivitet på det tidspunkt, hvor sikkerhedsdatabladet svigter
  • Genopbyg arbejdsbyrden overstiger behandlingskapaciteten – Antallet af metadatarækker, der skal genopbygges, overstiger MDM-balancerens grænse pr. cyklus på 1.024 rækker

Hver rebalancecyklus kan behandle op til 1.024 metadatarækker. Når flere rækker skal genopbygges, kan balanceren ikke afslutte den aktuelle plan, før den genereres.

Hvad sker der:

• SDS afkobles brat fra MDM (begivenhed SDS_DECOUPLED)
• Alle SDC'er, der var tilsluttet dette SDS, mister deres forbindelser → SDC-afbrydelseshændelser
• MDM markerer klyngen som FORRINGET (hændelse) MDM_DATA_DEGRADED)
• Da antallet af rækker, der skal genopbygges, er over 1.024, kan MDM-balanceren ikke afslutte den aktuelle plan for genbalancering
• Balanceren starter en ny plan, mens den forrige plan stadig kører, hvilket producerer hurtige, gentagne rolleskifthændelser
• SDC'er for klienter oplever kontinuerlige I/O-fejl (IO_FAULT_NOT_PRI, SCSI sense 0x4). Når gentagne forsøg er opbrugt, rapporterer værtsoperativsystemet I/O-fejl, timeouts eller et skrivebeskyttet filsystem
• MDM-sporbeviser:

Når genbalancearbejdsbelastningen overstiger grænsen på 1.024 rækker, viser MDM-sporingen tærsklen, der overskrides:

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.

Dette indikerer, at 1.098 rækker krævede genopbygning, men kun 1.024 kunne behandles i den aktuelle cyklus. De resterende rækker udløser en ny rebalanceringsplan, før den forrige plan fuldføres, hvilket starter feedbacksløjfen.

Kæde af begivenheder:

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

Scenarie 2: SDS-slukning under PMM-indgang

Hvornår kan det ske:
Dette er et sjældent scenarie, der kræver to samtidige begivenheder:

• Et sikkerhedsdatablad går i beskyttet vedligeholdelsestilstand (PMM)
• Sikkerhedsdatabladet svigter eller slukkes, før PMM-overgangen er fuldført

Hvad sker der: 

• MDM modtager PMM-indtastningskommandoen og registrerer den som fuldført
• SDS afkobles uventet, mens PMM-posten stadig er i gang
• MDM markerer klyngen som FORRINGET
• Rollejusteringsfaktoren skifter ind i en vedvarende rolleskiftsløjfe gennem hele PMM-indgangsfasen
• Ikke-PMM-datarækker skiftes gentagne gange på tværs af hele lagerpuljen
• Stormen fortsætter, indtil sikkerhedsdatabladet slutter sig til klyngen igen og fuldfører overgangen til vedligeholdelsestilstand

Kæde af begivenheder:

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

Eksempel på MDM-hændelsessekvens:

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 sikkerhedsdatabladet tilsluttes igen, og PMM fuldføres:

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

Scenarie 3: SDS i øjeblikkelig vedligeholdelsestilstand (IMM)

Hvornår kan det ske:
Et sikkerhedsdatablad går ind eller ud af IMM (Instant Maintenance Mode). Dette scenarie opstår, når et enkelt SDS er i vedligeholdelsestilstand, og systemet ikke kan beslutte, hvilket SDS der skal håndtere I/O for specifikke data.

Hvad sker der:

• Systemet ændrer gentagne gange, hvilket SDS der er ansvarlig for at betjene de samme data
• Disse konstante ændringer betyder, at applikationer ikke ved, hvor de skal sende deres I/O-anmodninger hen
• I/O sendes til det forkerte SDS, hvilket forårsager gentagne forsøg og forsinkelser
• Programmer oplever ventetid eller timeouts, mens de forsøger at få adgang til de berørte data

Påvirkning:

• Påvirkning fra kunden: Programmer rapporterer ventetid og timeouts, mens sikkerhedsdatabladet er i IMM
• Varighed: Fortsætter, mens sikkerhedsdatabladet er i IMM-tilstand
• Opsving: Automatisk – løser problemet, når sikkerhedsdatabladet afslutter IMM

Kæde af begivenheder:

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

Scenarie 4: SDS-udgang fra beskyttet vedligeholdelsestilstand (PMM)

Hvornår kan det ske:
Et sikkerhedsdatablad afslutter beskyttet vedligeholdelsestilstand (PMM). Dette scenarie opstår under hver PMM-udgang - det er ikke en sjælden begivenhed, men sværhedsgraden afhænger af, hvor længe vedligeholdelsestilstandsoperationen varede.

Hvad sker der:

• Når sikkerhedsdatabladet afslutter PMM, skal rollejusteringslederen omfordele datasegmenter for at medtage det tilbagevendende SDS
• Genbalanceprocessen påvirker hele storagepuljen, ikke kun data på det returnerende SDS
• Rolleskift forekommer på tværs af mange datasegmenter under reintegrationen
• Programmer kan opleve korte I/O-fejl eller ventetid, efterhånden som rolletildelingerne stabiliseres

Påvirkning:

• Påvirkning fra kunden: For korte vedligeholdelsesvinduer (mindre end 5 sekunder) er virkningen næppe mærkbar. Ved udvidet vedligeholdelse med aktiv I/O kan der forekomme tusindvis af rolleskift, hvilket forårsager vedvarende I/O-stalle
• Varighed: Fortsætter i reintegrationsfasen, indtil rebalanceringen er afsluttet
• Opsving: Automatisk

Kæde af begivenheder:

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

Eksempel på MDM-hændelsessekvens:

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

Log udgange:
 

MDM-hændelseslogfiler: MDM-hændelsesloggen viser sekvensen på klyngeniveau. Nøgleindikatorerne er handlinger for rolleskift under afslutning af vedligeholdelsestilstand.

SDS-sporingslogfiler: På SDS-noder viser sporingslogfiler gentagne rolleswitchhandlinger under reintegration:

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

Et stort antal Switch-rolleposter i et kort tidsvindue (tusinder eller mere inden for få sekunder) er den endelige SDS-sideindikator for dette problem.

SDC-/værtslogfiler: VMware (ESXi) SDC I/O forsøger igen at vise kammen, mål-SDS og fejlkoden:

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)

Hvis SCSI-fejl udtømmes igen, returneres SCSI-fejl: 

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

Diagnostisk tip: Hvis du ser I/O-fejl på flere SDS-noder (ikke kun den node, der var et problem), kan det være tegn på en storm med rolleskift snarere end normal funktionsmåde for forringet tilstand. Hvis I/O-fejl isoleres til et enkelt sikkerhedsdatablad, forventes dette at være forringet tilstand.

Scenarie 5: Faseovergange i vedligeholdelsestilstand 

Hvornår kan det ske:
Under overgangen, når et SDS går ind eller ud af vedligeholdelsestilstand (IMM eller PMM) - i øjeblikket ændres tilstanden fra normal til MM eller fra MM tilbage til normal.

Hvad sker der:

• Rollebalanceren omfordeler dataansvar for at imødekomme ændringen
• Der opstår kortvarige udbrud af rolleskift, efterhånden som systemet finder sig til rette i det nye arrangement
• Programmer kan opleve korte stigninger i ventetiden under overgangen

Påvirkning:

• Påvirkning fra kunden: Korte ventetidspidser, der varer sekunder til et par minutter. Normalt under programtimeouttærsklerne
• Varighed: Varer sekunder til et par minutter og sætter sig derefter
• Opsving: Automatisk

Kæde af begivenheder:

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

En softwaredefekt i MDM-rollebalancelogikken forårsager en feedbacksløjfe, når klyngen skifter tilstand på grund af et SDS-tab eller en vedligeholdelsestilstand.

Under visse omstændigheder omfordeler MDM gentagne gange, hvilke SDS-noder der er ansvarlige for at betjene I/O til berørte kamme. Hver omfordeling ugyldiggør SDC's cachelagrede visning af, hvor dataene er placeret, hvilket tvinger I/O-registreringer. Når mange kamme påvirkes samtidigt, overstiger mængden af omfordelinger SDC'ernes evne til at opdatere, hvilket resulterer i vedvarende I/O-fejl på tværs af flere værter.

Stormen er typisk selvbegrænsende. Det løses, når klyngen stabiliseres, men varigheden afhænger af størrelsen på beskyttelsesdomænet og I/O-belastningen på tidspunktet for hændelsen.

Problemet er løst i PowerFlex Core version 4.5.6. Opgrader til denne version, når den er tilgængelig. Kontakt Dell Support for at få oplysninger om tidslinjen for udgivelsen.

For planlagte vedligeholdelsesoperationer:

• Sluk eller genstart ikke et sikkerhedsdatablad, før MDM-loggen er logget SDS_MAINTENANCE_MODE_STARTED. Kontroller, at sikkerhedsdatabladet er gået helt i vedligeholdelsestilstand, før du fortsætter med fysisk vedligeholdelse.
• Overvåg for stigninger i ventetiden, når du går i eller forlader vedligeholdelsestilstand.

Ved ikke-planlagte SDS-afbrydelser:

• Stormen er selvbegrænsende og forsvinder typisk inden for få minutter, efterhånden som hoben stabiliserer sig. Hvis problemet observeres, skal du indsamle getinfo logfører fra alle SDS-noder i beskyttelsesdomænet, fra alle manager-MDM'er så hurtigt som muligt efter hændelsen, og kontakt Dell Support.

I sjældne tilfælde, hvor problemet ikke løser sig selv, kan midlertidig deaktivering og genaktivering af genopbygning gøre det muligt for MDM at stabilisere sig:

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

# Vent 5-10 sekunder, og aktiver derefter genopbygning: 

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