PowerFlex: Exzessiver Datenrollenwechsel führt zu I/O-Latenz und Fehlern

Bei bestimmten Clusterstatusübergängen kann die MDM-Rollenausgleichslogik schnelle, wiederholte primäre/sekundäre Rollenwechsel über viele Bereiche hinweg erzeugen (interne Datenstrukturen, die nachverfolgen, welche SDS-Nodes welche Volume-Daten speichern). Jeder Rollenwechsel macht clientseitige (SDC) Comb-Zuordnungen ungültig und erzwingt I/O-Neuversuche. Wenn genügend Kämme gleichzeitig betroffen sind, verursacht der kumulative Wiederholungsaufwand I/O-Latenzspitzen und I/O-Fehler auf SDC-Hosts. Je nach Hostumgebung kann dies zu Anwendungs-I/O-Timeouts, VMs in einen schreibgeschützten Status oder Nichtverfügbarkeit des Dateisystems führen.

Dieses Verhalten wurde bei mehreren Auslöseszenarien beobachtet und ist nicht auf ein einzelnes Betriebsverfahren beschränkt.

Allgemeine Indikatoren

• MDM_DATA_DEGRADED Ereignis, gefolgt von anhaltender I/O-Latenz von 1–15+ Minuten
• SDC-Hosts melden I/O-Fehler und/oder I/O-Timeouts während des heruntergestuften Zeitfensters
  • VMware (ESXi): VMFS-Heartbeat-Timeouts, SCSI-Hardwarefehler (sense data: 0x4 0x0 0x0), wenn VMs in den schreibgeschützten Status übergehen, potenzielles HA-Failover
  • Linux: I/O-Fehler in Systemprotokollen (/var/log/messages, dmesg), können bei Anwendungen I/O-Timeouts auftreten oder das Dateisystem wird schreibgeschützt erneut gemountet.
• MDM-Ereignisprotokolle zeigen das System länger als erwartet für einen einzigen SDS-Verlust länger als erwartet im Status DEGRADED an
• Das System stellt sich schließlich ohne manuelle Intervention selbst in einen NORMALZUSTAND zurück (in der Regel)

Szenario 1: Unzulässiger SDS-Verlust (kein Wartungsmodus)

Wann es passieren kann:

• Dies ist ein seltenes Szenario. Damit die schnellen, wiederholten Rollenwechselereignisse während eines nicht ordnungsgemäßen SDS-Verlusts auftreten können, müssen mehrere bestimmte Bedingungen gleichzeitig erfüllt sein:

• • Große Umgebung – erhebliche Anzahl von SDS-Nodes und -Volumes
  • Hohe I/O-Produktionslast: Erhebliche I/O-Aktivität beim Ausfall des SDS
  • Workload für erneuten Aufbau überschreitet Verarbeitungskapazität: Die Anzahl der Metadatenzeilen, die neu erstellt werden müssen, überschreitet das Limit des MDM-Balancer pro Zyklus von 1.024 Zeilen

Jeder Neuverteilungszyklus kann bis zu 1.024 Metadatenzeilen verarbeiten. Wenn weitere Zeilen neu erstellt werden müssen, kann der Balancer den aktuellen Plan erst fertigstellen, bevor der nächste generiert wird.

Was passiert:

• Der SDS wird abrupt vom MDM entkoppelt (Event SDS_DECOUPLED)
• Alle SDCs, die mit diesem SDS verbunden waren, verlieren ihre Verbindungen → SDC-Trennungsereignissen
• Der MDM markiert das Cluster als HERABGESTUFT (Ereignis MDM_DATA_DEGRADED)
• Da die Anzahl der neu aufzubauenden Zeilen mehr als 1.024 beträgt, kann der MDM-Balancer den aktuellen Neuverteilungsplan nicht abschließen
• Der Balancer startet einen neuen Plan, während der vorherige Plan noch ausgeführt wird, was zu schnellen, wiederholten Rollenwechselereignissen führt
• Client-SDCs sehen kontinuierliche I/O-Ausfälle (IO_FAULT_NOT_PRI, SCSI sense 0x4). Nachdem alle erneuten Versuche ausgeschöpft sind, meldet das Hostbetriebssystem I/O-Fehler, Timeouts oder ein schreibgeschütztes Dateisystem
• MDM-Trace-Nachweis:

Wenn die Neuverteilungs-Workload das Limit von 1.024 Zeilen überschreitet, zeigt die MDM-Ablaufverfolgung an, dass der Schwellenwert überschritten wird:

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.

Dies zeigt, dass 1.098 Zeilen neu aufgebaut werden mussten, aber nur 1.024 im aktuellen Zyklus verarbeitet werden konnten. Die verbleibenden Zeilen lösen einen neuen Ausgleichsplan aus, bevor der vorherige Plan abgeschlossen ist, wodurch die Feedbackschleife in Gang gesetzt wird.

Ereigniskette:

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

Beispiel für eine MDM-Ereignissequenz:

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

Szenario 2: SDS wird während des PMM-Eintritts ausgeschaltet

Wann es passieren kann:
Dies ist ein seltenes Szenario, bei dem zwei Ereignisse gleichzeitig erforderlich sind:

• Ein SDS wechselt in den geschützten Wartungsmodus (PMM)
• Der SDS fällt aus oder wird ausgeschaltet, bevor die PMM-Umstellung abgeschlossen ist

Die Folge? 

• Der MDM empfängt den PMM-Eintragsbefehl und zeichnet ihn als erfolgreich auf
• Der SDS wird unerwartet entkoppelt, während der PMM-Eintrag noch ausgeführt wird
• Der MDM markiert das Cluster als HERUNTERGESTUFT
• Der Rollenausgleich tritt während der gesamten PMM-Übergangsphase in eine dauerhafte Rollenwechselschleife ein
• Die Rollen von Nicht-PMM-Datenzeilen werden wiederholt im gesamten Storage-Pool getauscht.
• Der Sturm hält an, bis der SDS wieder dem Cluster beitritt und den Übergang in den Wartungsmodus abschließt

Ereigniskette:

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

Beispiel für eine MDM-Ereignissequenz:

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

Wenn der SDS wieder zusammentritt und der PMM abgeschlossen wird:

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

Szenario 3: SDS im Instant Maintenance Mode (IMM)

Wann es passieren kann:
Ein SDS wechselt in den Instant Maintenance Mode (IMM) oder verlässt diesen Modus. Dieses Szenario tritt auf, wenn sich ein einzelner SDS im Wartungsmodus befindet und das System nicht entscheiden kann, welcher SDS I/O-Vorgänge für bestimmte Daten verarbeiten soll.

Was passiert:

• Das System ändert wiederholt, welcher SDS für die Bereitstellung derselben Daten verantwortlich ist
• Diese ständigen Änderungen bedeuten, dass Anwendungen nicht wissen, wohin sie ihre I/O-Anfragen senden sollen
• I/O-Vorgänge werden an den falschen SDS gesendet, was zu erneuten Versuchen und Verzögerungen führt.
• Bei Anwendungen kommt es beim Versuch, auf die betroffenen Daten zuzugreifen, zu Latenz oder Timeouts.

Auswirkungen:

• Auswirkungen auf Kunden: Anwendungen melden Latenz und Timeouts, während sich der SDS im IMM befindet.
• Dauer: Wird fortgesetzt, während sich der SDS im IMM-Status befindet
• Recovery: Automatic – wird behoben, wenn der SDS den IMM beendet

Ereigniskette:

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

Szenario 4: SDS beendet den geschützten Wartungsmodus (PMM)

Wann es passieren kann:
Ein SDS beendet den geschützten Wartungsmodus (PMM). Dieses Szenario tritt bei jedem Beenden des PMM auf – es ist kein seltenes Ereignis, aber der Schweregrad hängt davon ab, wie lange der Wartungsmodusvorgang gedauert hat.

Was passiert:

• Wenn der SDS den PMM verlässt, muss der Rollenausgleichshelfer Datensegmente neu zuweisen, um den zurückkehrenden SDS einzubeziehen.
• Der Neuausgleichsprozess wirkt sich auf den gesamten Storage-Pool aus, nicht nur auf die Daten auf dem zurückgegebenen SDS
• Rollenwechsel treten während der Reintegration über viele Datensegmente hinweg auf
• Bei Anwendungen können kurze I/O-Fehler oder Latenzzeiten auftreten, wenn sich die Rollenzuweisungen stabilisieren

Auswirkungen:

• Auswirkungen auf den Kunden: Bei kurzen Wartungsfenstern (weniger als 5 Sekunden) sind die Auswirkungen kaum spürbar. Bei längerer Wartung mit aktiver I/O können Tausende von Rollenwechseln auftreten, die anhaltende I/O-Ausfälle verursachen
• Dauer: Wird während der Reintegrationsphase fortgesetzt, bis das Rebalancing abgeschlossen ist.
• Wiederherstellung: automatisch

Ereigniskette:

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

Beispiel für eine MDM-Ereignissequenz:

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

Protokollausgaben:
 

MDM-Ereignisprotokolle: Das MDM-Ereignisprotokoll zeigt die Sequenz auf Clusterebene. Die wichtigsten Indikatoren sind Rollenwechselvorgänge während des Beendens des Wartungsmodus.

SDS-Trace-Protokolle: Auf SDS-Nodes zeigen Trace-Protokolle wiederholte Rollenwechselvorgänge während der erneuten Integration an:

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

Eine hohe Anzahl von Switch-Rolleneinträgen in einem kurzen Zeitfenster (Tausende oder mehr innerhalb von Sekunden) ist der definitive SDS-seitige Indikator für dieses Problem.

SDC-/Hostprotokolle: VMware (ESXi) SDC-I/O-Wiederholungen mit Kamm, Ziel-SDS und Fehlercode:

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)

Wenn Wiederholungen erschöpft sind, werden SCSI-Fehler zurückgegeben: 

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

Diagnosetipp: Wenn I/O-Fehler auf mehreren SDS-Nodes (nicht nur auf dem Node, auf dem ein Problem aufgetreten ist) angezeigt werden, kann dies eher auf einen Sturm des Rollenwechsels als auf ein normales Verhalten im heruntergestuften Status hinweisen. Wenn I/O-Fehler auf einen einzigen SDS isoliert werden, handelt es sich um erwartetes Verhalten im heruntergestuften Zustand.

Szenario 5: Phasenübergänge im Wartungsmodus 

Wann es passieren kann:
Wenn ein SDS während des Übergangs in den Wartungsmodus (IMM oder PMM) eintritt oder ihn verlässt, ändert sich der Status von normal zu MM oder von MM zurück zu normal.

Was passiert:

• Der Rollenausgleichsmitarbeiter verteilt die Datenverantwortlichkeiten neu, um die Änderung zu berücksichtigen
• Kurze Ausbrüche von Rollenwechseln treten auf, wenn sich das System an die neue Anordnung gewöhnt
• Bei Anwendungen können während der Umstellung kurze Latenzspitzen auftreten.

Auswirkungen:

• Auswirkungen auf den Kunden: Kurze Latenzspitzen von Sekunden bis zu einigen Minuten In der Regel unterhalb der Schwellenwerte für Anwendungs-Timeouts
• Dauer: Dauert Sekunden bis einige Minuten, dann legt sich
• Wiederherstellung: automatisch

Ereigniskette:

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

Ein Softwarefehler in der MDM-Rollenausgleichslogik verursacht eine Rückkopplungsschleife, wenn der Status des Clusters aufgrund eines SDS-Verlust- oder Wartungsmodusvorgangs wechselt.

Unter bestimmten Bedingungen weist der MDM wiederholt neu zu, welche SDS-Nodes für die Bereitstellung von I/O für betroffene Kämme verantwortlich sind. Jede Neuzuweisung macht die zwischengespeicherte Ansicht des SDC mit dem Speicherort der Daten ungültig, wodurch I/O-Wiederholungsversuche erzwungen werden. Wenn viele Kämme gleichzeitig betroffen sind, übersteigt die Anzahl der Neuzuweisungen die Aktualisierungsfähigkeit der SDCs, was zu dauerhaften I/O-Fehlern auf mehreren Hosts führt.

Der Sturm ist in der Regel selbstlimitierend. Das Problem wird behoben, sobald sich das Cluster stabilisiert hat. Die Dauer hängt jedoch von der Größe der Schutzdomain und der I/O-Last zum Zeitpunkt des Ereignisses ab.

Dieses Problem wurde in PowerFlex Core Version 4.5.6 behoben. Führen Sie ein Upgrade auf diese Version durch, sobald sie verfügbar ist. Wenden Sie sich an den Dell Support , um Informationen zum Versionszeitplan zu erhalten.

Für geplante Wartungsvorgänge:

• Schalten Sie einen SDS erst aus und wieder ein oder starten Sie ihn neu, bis der MDM SDS_MAINTENANCE_MODE_STARTED. Vergewissern Sie sich, dass der SDS vollständig in den Wartungsmodus versetzt wurde, bevor Sie mit der physischen Wartung fortfahren.
• Überwachen Sie Latenzspitzen beim Ein- oder Ausschalten des Wartungsmodus.

Bei ungeplanten SDS-Ausfällen:

• Der Sturm ist selbstbegrenzend und löst sich in der Regel innerhalb von Minuten auf, wenn sich das Cluster stabilisiert. Wenn das Problem auftritt, sammeln Sie getinfo Protokolle von allen SDS-Nodes in der Schutzdomain, von allen Manager-MDMs so bald wie möglich nach dem Ereignis und wenden Sie sich an den Dell Support.

In seltenen Fällen, in denen sich das Problem nicht selbst löst, kann der MDM durch vorübergehendes Deaktivieren und erneutes Aktivieren der Neuerstellung stabilisiert werden:

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

# Warten Sie 5 bis 10 Sekunden und aktivieren Sie dann die Neuerstellung: 

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