PowerFlex: Overdreven datarolleveksling forårsaker I/O-ventetid og feil

Under visse klyngetilstandsoverganger kan MDM-rollebalanselogikken produsere raske, gjentatte primære/sekundære rollebrytere på tvers av mange kammer (interne datastrukturer som sporer hvilke SDS-noder som lagrer hver del av volumdata). Hver rollebryter ugyldiggjør kamtilordninger på klientsiden (SDC) og tvinger I/O-forsøk på nytt. Når nok kammer påvirkes samtidig, forårsaker de kumulative omgjorte kostnadene topper i / O-ventetid og I/O-feil på SDC-verter. Avhengig av vertsmiljøet kan dette føre til tidsavbrudd for applikasjons-I/O, at virtuelle maskiner går inn i skrivebeskyttet tilstand eller at filsystemet blir utilgjengelig.

Denne atferden er observert i flere utløserscenarier og er ikke begrenset til én enkelt driftsprosedyre.

Vanlige indikatorer

• MDM_DATA_DEGRADED hendelse etterfulgt av vedvarende I / O-ventetid som varer 1-15+ minutter
• SDC-verter rapporterer I/O-feil og/eller I/O-tidsavbrudd i løpet av degradert vindu
  • VMware (ESXi): VMFS-tidsavbrudd for hjerteslag, SCSI-maskinvarefeil (sense data: 0x4 0x0 0x0), virtuelle maskiner som går inn i skrivebeskyttet tilstand, potensiell HA-failover
  • Linux: I/O-feil i systemlogger (/var/log/messages, dmesg), kan programmer oppleve I/O-tidsavbrudd eller ny montering av filsystem skrivebeskyttet
• MDM-hendelseslogger viser systemet i DEGRADERT-tilstand lenger enn forventet for et enkelt SDS-tap
• Systemet gjenoppretter til slutt seg selv til en NORMAL tilstand uten manuell inngripen (vanligvis)

Scenario 1: Uvennlig SDS-tap (ingen vedlikeholdsmodus)

Når det kan skje:

• Dette er et sjeldent scenario. For at de raske, gjentatte rollebyttehendelsene skal oppstå under et ugrasiøst SDS-tap, må flere spesifikke forhold være til stede samtidig:

• • Stort miljø – et betydelig antall SDS-noder og -volumer
  • Tung I/O-belastning for produksjon – betydelig I/O-aktivitet i det øyeblikket SDS svikter
  • Gjenoppbyggingsarbeidsbelastningen overskrider behandlingskapasiteten – Antall metadatarader som krever gjenoppbygging, overskrider MDM-balanseringens grense per syklus på 1024 rader

Hver rebalanseringssyklus kan behandle opptil 1 024 metadatarader. Når flere rader må gjenoppbygges, kan ikke balansereren fullføre gjeldende plan før den genereres neste.

Hva skjer:

• SDS frikobler seg brått fra MDM (hendelse SDS_DECOUPLED)
• Alle SDC-er som var koblet til dette SDS-et, mister tilkoblingen → SDC-frakoblingshendelser
• MDM markerer klyngen DEGRADERT (hendelse MDM_DATA_DEGRADED)
• Fordi antall rader som skal gjenoppbygges, er over 1 024, kan ikke MDM-balansereren fullføre gjeldende rebalanseringsplan
• Balansereren starter en ny plan mens den forrige planen fortsatt kjører, og produserer raske, gjentatte rollebyttehendelser
• SDC-er for klient ser kontinuerlige I/O-feil (IO_FAULT_NOT_PRI, SCSI sense 0x4). Når forsøkene er oppbrukt, rapporterer vertsoperativsystemet I/O-feil, tidsavbrudd eller et skrivebeskyttet filsystem
• MDM-sporingsbevis:

Når workloaden for rebalansering overskrider grensen på 1 024 rader, viser MDM-sporingen terskelen som 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 1098 rader krevde ombygging, men bare 1024 kunne behandles i den nåværende syklusen. De gjenværende radene utløser en ny rebalanseringsplan før den forrige planen fullføres, og tilbakemeldingssløyfen startes.

Hendelsesforløp:

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-avslåing under PMM-oppføring

Når det kan skje:
Dette er et sjeldent scenario som krever to samtidige hendelser:

• Et SDS går inn i PMM (Protected Maintenance Mode)
• SDS mislykkes eller slås av før PMM-overgangen fullføres

Hva skjer: 

• MDM mottar PMM-oppføringskommandoen og registrerer den som vellykket
• SDS kobles uventet fra mens PMM-oppføringen fortsatt pågår
• MDM markerer klyngen DEGRADERT
• Rollebalansereren går inn i en vedvarende rollebrytersløyfe gjennom hele PMM-inngangsfasen
• Ikke-PMM-datarader blir gjentatte ganger rollebyttet på tvers av hele lagringsutvalget
• Stormen vedvarer til SDS kobles til klyngen og fullfører overgangen til vedlikeholdsmodus

Hendelsesforløp:

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-hendelsessekvens:

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 kobles til igjen og PMM fullføres:

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

Scenario 3: SDS i modus for øyeblikkelig vedlikehold (IMM)

Når det kan skje:
Et SDS går inn i eller ut av IMM (Instant Maintenance Mode). Dette scenariet oppstår når en enkelt SDS er i vedlikeholdsmodus og systemet ikke kan bestemme hvilket SDS som skal håndtere I/O for bestemte data.

Hva skjer:

• Systemet endrer gjentatte ganger hvilket SDS som er ansvarlig for å betjene de samme dataene
• Disse stadige endringene betyr at applikasjonene ikke vet hvor de skal sende I/O-forespørslene sine
• I/O sendes til feil SDS, noe som fører til nye forsøk og forsinkelser
• Applikasjoner opplever ventetid eller tidsavbrudd mens de prøver å få tilgang til de berørte dataene

Innvirkning:

• Kundepåvirkning: Programmer rapporterer ventetid og tidsavbrudd mens SDS er i IMM
• Varighet: Fortsetter mens SDS er i IMM-tilstand
• Utvinning: Automatisk - løser når SDS avsluttes IMM

Hendelsesforløp:

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 avslutter beskyttet vedlikeholdsmodus (PMM)

Når det kan skje:
SDS avslutter Protected Maintenance Mode (PMM). Dette scenariet oppstår under hver PMM-avslutning - det er ikke en sjelden hendelse, men alvorlighetsgraden avhenger av hvor lenge vedlikeholdsmodusoperasjonen varte.

Hva skjer:

• Når SDS avslutter PMM, må rollebalansereren tilordne datasegmenter på nytt for å inkludere det returnerende SDS
• Rebalanseringsprosessen påvirker hele lagringsutvalget, ikke bare data om det returnerende SDS-kortet
• Rollebytter forekommer på tvers av mange datasegmenter under reintegreringen
• Programmer kan oppleve korte I/O-feil eller ventetid når rolletilordningene stabiliseres

Innvirkning:

• Kundepåvirkning: For korte vedlikeholdsvinduer (mindre enn 5 sekunder) er virkningen knapt merkbar. For utvidet vedlikehold med aktiv I/O kan tusenvis av rollebrytere forekomme, noe som forårsaker vedvarende I/O-boder
• Varighet: Fortsetter under reintegreringsfasen til rebalanseringen er fullført
• Utvinning: Automatisk

Hendelsesforløp:

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-hendelsessekvens:

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

Logg utganger:
 

MDM-hendelseslogger: MDM-hendelsesloggen viser sekvensen på klyngenivå. Nøkkelindikatorene er rollebryteroperasjoner under utgangen av vedlikeholdsmodus.

SDS-sporingslogger: På SDS-noder viser sporingslogger gjentatte rollebytteoperasjoner under reintegrering:

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 antall oppføringer i bytte av roller i løpet av et kort tidsvindu (tusenvis eller flere i løpet av sekunder) er den definitive SDS-sideindikatoren for dette problemet.

SDC/vertslogger: VMware (ESXi) SDC I/O prøver på nytt å vise kam, mål-SDS og feilkode:

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 du prøver eksos på nytt, returneres SCSI-feil: 

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

Diagnostisk tips: Hvis du ser I/O-feil på flere SDS-noder (ikke bare noden som hadde et problem), kan dette tyde på en rollebryterstorm i stedet for normal degradert tilstandsvirkemåte. Hvis I/O-feil isoleres til en enkelt SDS, er dette forventet atferd for redusert tilstand.

Scenario 5: Faseoverganger i vedlikeholdsmodus 

Når det kan skje:
Under overgangen når et SDS går inn eller ut av vedlikeholdsmodus (IMM eller PMM) - i øyeblikket endres tilstanden fra normal til MM, eller fra MM tilbake til normal.

Hva skjer:

• Rollebalansereren videredistribuerer dataansvar for å imøtekomme endringen
• Korte utbrudd av rollebytter oppstår når systemet finner seg til rette i den nye ordningen
• Applikasjoner kan oppleve korte latenstidstopper under overgangen

Innvirkning:

• Kundepåvirkning: Korte latenstidstopper som varer sekunder til noen få minutter. Vanligvis under terskler for tidsavbrudd for søknad
• Varighet: Varer sekunder til noen få minutter, og legger seg deretter
• Utvinning: Automatisk

Hendelsesforløp:

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

En programvarefeil i logikken for MDM-rollebalanse fører til en tilbakemeldingssløyfe når klyngen overganger på grunn av et SDS-tap eller en drift i vedlikeholdsmodus.

Under visse forhold tilordner MDM gjentatte ganger hvilke SDS-noder som er ansvarlige for å betjene I/O til berørte kammer. Hver ny tilordning ugyldiggjør SDCs bufrede visning av hvor dataene er plassert, noe som tvinger frem nye forsøk. Når mange kammer påvirkes samtidig, overgår volumet av tilordninger SDCenes evne til å oppdatere, noe som resulterer i vedvarende I/O-feil på tvers av flere verter.

Stormen er typisk selvbegrensende. Det løses når klyngen stabiliserer seg, men varigheten avhenger av størrelsen på beskyttelsesdomenet og I/O-belastningen på hendelsestidspunktet.

Dette problemet er løst i PowerFlex Core versjon 4.5.6. Oppgrader til denne versjonen når den er tilgjengelig. Kontakt Dells kundestøtte for å få informasjon om utgivelsestidslinjen.

For planlagte vedlikeholdsoperasjoner:

• Ikke slå SDS av og på eller start den på nytt før MDM-loggene SDS_MAINTENANCE_MODE_STARTED. Kontroller at SDS har gått helt i vedlikeholdsmodus før du fortsetter med fysisk vedlikehold.
• Overvåke for latenstidstopper når du går inn i eller ut av vedlikeholdsmodus.

For ikke-planlagte SDS-avbrudd:

• Stormen er selvbegrensende og løser seg vanligvis i løpet av minutter når klyngen stabiliserer seg. Hvis problemet observeres, samler du inn getinfo logger fra alle SDS-noder i beskyttelsesdomenet, fra alle MDM-er for bestyrere så snart som mulig etter hendelsen, og kontakter Dell Support.

I sjeldne tilfeller der problemet ikke løser seg selv, kan midlertidig deaktivering og aktivering av gjenoppbygging gjøre det mulig for MDM å stabilisere:

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

# Vent 5-10 sekunder, og aktiver deretter gjenoppbygging: 

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