PowerFlex: Overmatig wisselen van datarol veroorzaakt IO-latentie en fouten

Summary: In dit artikel wordt uitgelegd hoe overmatig wisselen van data I/O-latentie en fouten veroorzaakt.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

Bij bepaalde clusterstatusovergangen kan de MDM-logica voor rolbalans snelle, herhaalde primaire/secundaire rolwisselingen produceren in vele kammen (interne gegevensstructuren die bijhouden welke SDS-knooppunten elk stukje volumegegevens opslaan). Elke rolwisseling maakt client-side (SDC) kamtoewijzingen ongeldig en dwingt I/O-pogingen af. Wanneer er voldoende kammen tegelijk worden beïnvloed, veroorzaakt de cumulatieve overhead voor opnieuw proberen I/O-latentiepieken en I/O-fouten op SDC-hosts. Afhankelijk van de hostomgeving kan dit leiden tot I/O-time-outs van applicaties, VM's die de status alleen-lezen activeren of niet-beschikbaarheid van het bestandssysteem.

Dit gedrag is waargenomen onder meerdere triggerscenario's en is niet beperkt tot een enkele operationele procedure.

Gemeenschappelijke indicatoren

  • MDM_DATA_DEGRADED gebeurtenis gevolgd door aanhoudende I/O-latentie van 1-15+ minuten
  • SDC-hosts rapporteren I/O-fouten en/of I/O-time-outs tijdens het verslechterde venster
    • VMware (ESXi): VMFS heartbeat time-outs, SCSI-hardwarefouten (sense data: 0x4 0x0 0x0), VM's die de status alleen-lezen krijgen, mogelijke HA-failover
    • Linux: I/O-fouten in systeemlogboeken (/var/log/messages, dmesg), kunnen applicaties te maken krijgen met I/O-time-outs of het opnieuw koppelen van de alleen-lezen bestandssysteem
  • In MDM-gebeurtenislogboeken wordt het systeem langer in de status GEDEGRADEERD weergegeven dan verwacht bij een enkel SDS-verlies
  • Het systeem herstelt zichzelf uiteindelijk naar een NORMALE toestand zonder handmatige interventie (meestal)
 
Opmerking: Op het moment van schrijven is dit probleem alleen gemeld in omgevingen met VMware (ESXi) en Linux SDC-hosts. Er zijn geen meldingen bekend van het gedrag dat van invloed is op Windows SDC-hosts, hoewel het onderliggende defect in de MDM-kernlogica zit en niet OS-specifiek is.


Scenario 1: Onaangenaam SDS-verlies (geen onderhoudsmodus)

Wanneer het kan gebeuren:

  • Dit is een zeldzaam scenario. Om de snelle, herhaalde rolwisselingen te laten optreden tijdens een ondankbaar SDS-verlies, moeten verschillende specifieke omstandigheden tegelijkertijd aanwezig zijn:
    • Grootschalige omgeving: aanzienlijk aantal SDS-knooppunten en -volumes
    • I/O-belasting tijdens zware productie - aanzienlijke I/O-activiteit op het moment dat de SDS uitvalt
    • Workload opnieuw opbouwen overschrijdt de verwerkingscapaciteit: het aantal metadatarijen dat opnieuw moet worden opgebouwd, overschrijdt de limiet per cyclus van 1024 rijen van de MDM-balancer

Elke herbalanceringscyclus kan maximaal 1024 metadatarijen verwerken. Wanneer meer rijen opnieuw moeten worden opgebouwd, kan de balancer het huidige plan niet voltooien voordat het volgende wordt gegenereerd.

Wat gebeurt er:

  • De SDS ontkoppelt abrupt van de MDM (gebeurtenis SDS_DECOUPLED)
  • Alle SDC's die op die SDS waren aangesloten, verliezen hun verbindingen → gebeurtenissen waarbij de SDC wordt verbroken
  • De MDM markeert het cluster als GEDEGRADEERD (gebeurtenis MDM_DATA_DEGRADED)
  • Omdat het aantal rijen dat opnieuw moet worden opgebouwd meer dan 1024 is, kan de MDM-balancer het huidige herbalanceringsplan niet voltooien
  • De balancer start een nieuw plan terwijl het vorige plan nog loopt, waardoor snelle, herhaalde rolwisselingen ontstaan
  • Client-SDC's hebben voortdurend te maken met I/O-storingen (IO_FAULT_NOT_PRI, SCSI sense 0x4). Nadat het aantal nieuwe pogingen is uitgeput, meldt het hostbesturingssysteem I/O-fouten, time-outs of een alleen-lezen bestandssysteem
  • MDM-sporenbewijs:

Wanneer de herbalanceringsworkload de limiet van 1024 rijen overschrijdt, geeft de MDM-tracering aan dat de drempelwaarde wordt overschreden:

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.

Dit geeft aan dat 1.098 rijen opnieuw moesten worden opgebouwd, maar dat er in de huidige cyclus slechts 1.024 konden worden verwerkt. De resterende rijen activeren een nieuw herbalanceringsplan voordat het vorige plan wordt voltooid, waardoor de feedbacklus wordt gestart.

Keten van gebeurtenissen:

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
Voorbeeld van MDM-gebeurtenissenreeks:
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 uitschakelen tijdens invoer van PMM

Wanneer het kan gebeuren:
Dit is een zeldzaam scenario waarvoor twee gelijktijdige gebeurtenissen nodig zijn:

  • Een SDS gaat naar de Protected Maintenance Mode (PMM)
  • De SDS mislukt of wordt uitgeschakeld voordat de PMM-overgang is voltooid

Wat gebeurt er: 

  • De MDM ontvangt de opdracht PMM-invoer en registreert deze als geslaagd
  • De SDS wordt onverwacht ontkoppeld terwijl de PMM-invoer nog bezig is
  • De MDM markeert het cluster als GEDEGRADEERD
  • De rolbalancer gaat een doorlopende rolswitch-lus in tijdens de PMM-ingangsfase
  • Niet-PMM-datarijen worden herhaaldelijk van rol gewisseld in de gehele storagepool
  • De storm houdt aan totdat de SDS zich weer bij het cluster voegt en de overgang naar de onderhoudsmodus voltooit

Keten van gebeurtenissen:

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

Voorbeeld van MDM-gebeurtenissenreeks:

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

Wanneer de SDS opnieuw wordt gekoppeld en PMM wordt voltooid:

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

Scenario 3: SDS in directe onderhoudsmodus (IMM)

Wanneer het kan gebeuren:
Een SDS wordt gestart in of uit de Instant Maintenance Mode (IMM). Dit scenario doet zich voor wanneer één SDS in de onderhoudsmodus staat en het systeem niet kan beslissen welke SDS I/O moet afhandelen voor specifieke data.

Wat gebeurt er:

  • Het systeem wijzigt herhaaldelijk welke SDS verantwoordelijk is voor het leveren van dezelfde data
  • Deze constante veranderingen betekenen dat applicaties niet weten waar ze hun I/O-aanvragen naartoe moeten sturen
  • I/O wordt naar de verkeerde SDS gestuurd, wat nieuwe pogingen en vertragingen veroorzaakt
  • Applicaties ervaren latentie of time-outs wanneer ze proberen toegang te krijgen tot de getroffen data

Impact:

  • Impact op de klant: Applicaties rapporteren latentie en time-outs terwijl de SDS in IMM staat
  • Duur: Gaat door terwijl de SDS in de IMM-status is
  • Herstel: Automatisch - wordt opgelost wanneer de SDS IMM afsluit

Keten van gebeurtenissen:

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 afsluiten uit beveiligde onderhoudsmodus (PMM)

Wanneer het kan gebeuren:
Een SDS verlaat de Protected Maintenance Mode (PMM). Dit scenario doet zich voor bij elke PMM-exit - het is geen zeldzame gebeurtenis, maar de ernst hangt af van hoe lang de werking van de onderhoudsmodus heeft geduurd.

Wat gebeurt er:

  • Als de SDS de PMM afsluit, moet de rolbalancer datasegmenten opnieuw toewijzen om de terugkerende SDS op te nemen
  • Het herbalanceringsproces is van invloed op de gehele storagepool, niet alleen op de data op de terugkerende SDS
  • Rolwisselingen vinden plaats in veel datasegmenten tijdens de re-integratie
  • Applicaties kunnen te maken krijgen met korte I/O-fouten of latentie naarmate de roltoewijzingen stabiliseren

Impact:

  • Impact op de klant: Bij korte onderhoudsvensters (minder dan 5 seconden) is de impact nauwelijks merkbaar. Voor langdurig onderhoud met actieve I/O kunnen duizenden rolwisselingen optreden, waardoor I/O langdurig vastloopt
  • Duur: Gaat door tijdens de re-integratiefase totdat de herbalancering is voltooid
  • Herstel: Automatisch

Keten van gebeurtenissen:

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

Voorbeeld van MDM-gebeurtenissenreeks:

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

Logboekuitgangen:
 

Opmerking: De onderstaande logboekvoorbeelden zijn generieke weergaven van de patronen die zijn waargenomen bij meerdere gevallen van dit probleem. Ze zijn niet gebonden aan een specifiek scenario dat hierboven is vermeld - dezelfde patronen verschijnen ongeacht de trigger.


MDM-gebeurtenislogboeken: In het MDM-gebeurtenislogboek wordt de volgorde op clusterniveau weergegeven. De belangrijkste indicatoren zijn de functies van de rolwissel tijdens het afsluiten van de onderhoudsmodus.

SDS Trace Logs: Op SDS-knooppunten tonen traceringslogboeken herhaalde bewerkingen voor het wisselen van rollen tijdens re-integratie:

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

Een groot aantal Switch-rollenposten in een kort tijdsbestek (duizenden of meer binnen enkele seconden) is de definitieve SDS-indicator van dit probleem.

SDC-/hostlogboeken: VMware (ESXi) SDC I/O-pogingen om de kam, doel-SDS en foutcode weer te geven:

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)

Als nieuwe pogingen worden uitgeput, worden SCSI-fouten geretourneerd: 

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

Diagnostische tip: Als u I/O-fouten ziet op meerdere SDS-knooppunten (niet alleen het knooppunt dat een probleem had), kan dit duiden op een storm van rolwisseling in plaats van normaal gedrag van gedegradeerde status. Als I/O-fouten worden geïsoleerd in één SDS, wordt dit naar verwachting gedegradeerd gedrag verwacht.

Scenario 5: Faseovergangen onderhoudsmodus 

Wanneer het kan gebeuren:
Tijdens de overgang wanneer een SDS de onderhoudsmodus (IMM of PMM) in- of uitschakelt - op het moment dat de status verandert van normaal naar MM, of van MM terug naar normaal.

Wat gebeurt er:

  • De rolbalancer herverdeelt de verantwoordelijkheden van de gegevens om de verandering mogelijk te maken
  • Korte uitbarstingen van rolwisselingen vinden plaats terwijl het systeem zich in de nieuwe opstelling nestelt
  • Applicaties kunnen korte latentiepieken ervaren tijdens de overgang

Impact:

  • Impact op de klant: Korte latentiepieken die seconden tot enkele minuten duren. Meestal onder de time-outdrempels voor applicaties
  • Duur: Duurt seconden tot een paar minuten en bezinkt dan
  • Herstel: Automatisch

Keten van gebeurtenissen:

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

Cause

Een softwarefout in de logica voor de MDM-rolbalans veroorzaakt een feedbacklus wanneer de cluster de status overschakelt vanwege een SDS-verlies of onderhoudsmodusbewerking.

Onder bepaalde omstandigheden wijst de MDM herhaaldelijk opnieuw toe welke SDS-knooppunten verantwoordelijk zijn voor het leveren van I/O aan aangetaste kammen. Elke nieuwe toewijzing maakt de cacheweergave van de SDC van waar de data zich bevinden ongeldig, waardoor I/O-pogingen worden afgedwongen. Wanneer veel kammen tegelijkertijd worden beïnvloed, is het aantal hertoewijzingen groter dan het vermogen van de SDC's om bij te werken, wat resulteert in aanhoudende I/O-fouten op meerdere hosts.

De storm is meestal zelfbeperkend. Het wordt opgelost zodra het cluster is gestabiliseerd, maar de duur is afhankelijk van de grootte van het beschermingsdomein en de I/O-belasting op het moment van de gebeurtenis.

Resolution

Dit probleem wordt opgelost in PowerFlex Core versie 4.5.6. Voer een upgrade uit naar deze versie zodra deze beschikbaar is. Neem contact op met Dell Support voor informatie over de tijdlijn van de release.

Voor geplande onderhoudswerkzaamheden:

  • Schakel een SDS niet uit en start deze niet opnieuw op totdat de MDM-logboeken zijn geregistreerd SDS_MAINTENANCE_MODE_STARTED. Controleer of de SDS volledig in de onderhoudsmodus is gegaan voordat u verdergaat met fysiek onderhoud.
  • Controleer op latentiepieken bij het starten of verlaten van de onderhoudsmodus.

Voor ongeplande SDS-uitval:

  • De storm is zelfbeperkend en verdwijnt meestal binnen enkele minuten als het cluster stabiliseert. Als het probleem wordt waargenomen, verzamelt u getinfo logt zo snel mogelijk na de gebeurtenis van alle SDS-knooppunten in het beschermingsdomein van alle MDM's van Manager en neemt contact op met Dell Support.

In zeldzame gevallen waarin het probleem niet vanzelf wordt opgelost, kan het tijdelijk uitschakelen en opnieuw inschakelen van rebuild ervoor zorgen dat het MDM zich stabiliseert:

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

# Wacht 5-10 seconden en schakel dan opnieuw opbouwen in: 

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

 

Belangrijk: Het cluster heeft minder redundantie terwijl opnieuw opbouwen is uitgeschakeld. Schakel opnieuw opbouwen alleen lang genoeg uit om het systeem te stabiliseren en schakel daarna onmiddellijk weer in. Het wordt aanbevolen om deze actie uit te voeren met de begeleiding van Dell Support. 

 

Opmerking: Opnieuw opbouwen wordt beheerd op storagepoolniveau. Als de betreffende SDS apparaten in meerdere storagepools heeft, past u deze actie toe op elke betreffende storagepool. Storagepools die geen apparaten van de betreffende SDS bevatten, worden niet beïnvloed. Het beschermingsdomein, de storagepool en de SDS-naar-apparaattoewijzing kunnen worden geïdentificeerd via de scli --query_all opdrachtuitvoer. 

Affected Products

PowerFlex rack, PowerFlex Appliance, PowerFlex rack connectivity, PowerFlex Software
Article Properties
Article Number: 000450312
Article Type: Solution
Last Modified: 12 أيار 2026
Version:  5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.