PowerFlex: Übermäßiger Wechsel von Datenrollen führt zu I/O-Latenz und Fehlern.

Bei bestimmten Clusterstatusübergängen kann die MDM-Rollenausgleichslogik schnelle, wiederholte primäre und sekundäre Rollenwechsel über viele Kämme hinweg erzeugen (interne Datenstrukturen, die nachverfolgen, welche SDS-Nodes welche Volume-Daten speichern). Jeder Rollenswitch macht clientseitige (SDC) Comb-Zuordnungen ungültig und erzwingt I/O-Wiederholungen. Wenn genügend Kämme gleichzeitig betroffen sind, führt der kumulative Mehraufwand für erneute Versuche zu I/O-Latenzspitzen und I/O-Fehlern auf SDC-Hosts. Je nach Hostumgebung kann dies zu Anwendungs-I/O-Timeouts, dem Übergang von VMs in den schreibgeschützten Status oder der Nichtverfügbarkeit von Dateisystemen führen.

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

Allgemeine Indikatoren

• MDM_DATA_DEGRADED Ereignis gefolgt von einer anhaltenden 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), VMs, die in den schreibgeschützten Status wechseln, potenzielles HA-Failover
  • Linux: I/O-Fehler in Systemprotokollen (/var/log/messages, dmesg), können bei Anwendungen I/O-Timeouts oder ein schreibgeschütztes erneutes Mounten des Dateisystems auftreten
• MDM-Ereignisprotokolle zeigen das System länger als erwartet für einen einzelnen SDS-Verlust im Status DEGRADED an
• Das System wird schließlich ohne manuelle Intervention (normalerweise) automatisch in einen NORMALEN Zustand wiederhergestellt

Szenario 1: Unsachgemäßer 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, müssen mehrere spezifische Bedingungen gleichzeitig vorliegen:

• • Große Umgebung – erhebliche Anzahl von SDS-Nodes und -Volumes
  • Hohe I/O-Last in der Produktion – Erhebliche I/O-Aktivität in dem Moment, in dem der SDS ausfällt
  • Rebuild Workload überschreitet die Verarbeitungskapazität: Die Anzahl der Metadatenzeilen, die neu erstellt werden müssen, überschreitet das Zykluslimit des MDM-Balancers von 1.024 Zeilen.

Jeder Neuverteilungszyklus kann bis zu 1.024 Metadatenzeilen verarbeiten. Wenn mehr Zeilen neu erstellt werden müssen, kann der Balancer den aktuellen Plan nicht abschließen, bevor er den nächsten erzeugt.

Was ist los:

• Der SDS wird abrupt vom MDM entkoppelt (Ereignis SDS_DECOUPLED).
• Alle SDCs, die mit diesem SDS verbunden waren, verlieren ihre Verbindung → Trennungsereignisse des SDC
• Der MDM markiert das Cluster als DEGRADED (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) enthalten. Nachdem alle Wiederholungsversuche erschöpft sind, meldet das Hostbetriebssystem I/O-Fehler, Timeouts oder ein schreibgeschütztes Dateisystem.
• MDM-Trace-Nachweise:

Wenn die Workload für den Neuausgleich 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 bedeutet, dass 1.098 Zeilen neu erstellt 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 wird, wodurch die Feedbackschleife beginnt.

Kette von Ereignissen:

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

Szenario 2: Ausschalten des SDS während des PMM-Zugangs

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

• Ein SDS wechselt in den Protected Maintenance Mode (PMM).
• Der SDS fällt aus oder wird ausgeschaltet, bevor die PMM-Umstellung abgeschlossen ist

Was ist los: 

• Der MDM empfängt den PMM-Eingabebefehl und registriert ihn als erfolgreich
• Der SDS wird unerwartet entkoppelt, während der PMM-Eintrag noch ausgeführt wird
• Der MDM markiert das Cluster als DEGRADED
• Der Rollenausgleich wechselt während der gesamten PMM-Einstiegsphase in eine kontinuierliche Rollenwechselschleife.
• Nicht-PMM-Datenzeilen werden wiederholt im gesamten Storage-Pool mit der Rolle gewechselt
• Der Sturm bleibt bestehen, bis der SDS wieder dem Cluster beitritt und den Übergang zum Wartungsmodus abschließt

Kette von Ereignissen:

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 beitritt und der PMM den Vorgang abschließt:

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 oder aus dem IMM (Instant Maintenance Mode). Dieses Szenario tritt auf, wenn sich ein einzelner SDS im Wartungsmodus befindet und das System nicht entscheiden kann, welcher SDS I/O für bestimmte Daten verarbeiten soll.

Was ist los:

• Das System ändert wiederholt, welcher SDS für die Bereitstellung derselben Daten zuständig ist
• Diese ständigen Veränderungen führen dazu, dass Anwendungen nicht wissen, wohin sie ihre I/O-Anfragen senden sollen
• I/O wird an den falschen SDS gesendet, was zu Wiederholungen und Verzögerungen führt
• Bei Anwendungen treten Latenz oder Timeouts auf, wenn sie versuchen, auf die betroffenen Daten zuzugreifen.

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
• Genesung: Automatisch: wird behoben, wenn der SDS den IMM beendet.

Kette von Ereignissen:

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 Protected Maintenance Mode (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 ist los:

• Wenn der SDS den PMM verlässt, muss der Rollenausgleich Datensegmente neu zuweisen, um den wiederkehrenden SDS einzuschließen
• Der Prozess des erneuten Ausgleichs wirkt sich auf den gesamten Storage-Pool aus, nicht nur auf die Daten auf dem zurückkehrenden SDS
• Rollenwechsel treten während der Wiedereingliederung über viele Datensegmente hinweg auf
• Bei Anwendungen können kurze I/O-Fehler oder Latenzzeiten auftreten, während sich die Rollenzuweisungen stabilisieren

Auswirkungen:

• Auswirkungen auf Kunden: Bei kurzen Wartungsfenstern (weniger als 5 Sekunden) sind die Auswirkungen kaum spürbar. Bei längerer Wartung mit aktiven I/O-Vorgängen können Tausende von Rollenswitches auftreten, was zu anhaltenden I/O-Stillständen führt
• Dauer: Wird während der Wiedereingliederungsphase fortgesetzt, bis die Neuverteilung abgeschlossen ist
• Genesung: Automatisch

Kette von Ereignissen:

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 an. 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 Reintegration 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 Einträgen für Switch-Rollen 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 zeigen den Kamm, Ziel-SDS und Fehlercode an:

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 die Anzahl der Versuche erschöpft ist, werden SCSI-Fehler zurückgegeben: 

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

Diagnosetipp: Wenn I/O-Fehler auf mehreren SDS-Nodes auftreten (nicht nur auf dem Node, auf dem ein Problem aufgetreten ist), kann dies eher auf einen Rollenswitch-Sturm als auf normales Verhalten eines herabgesetzten Zustands hindeuten. Wenn I/O-Fehler auf einen einzelnen SDS isoliert werden, handelt es sich hierbei um erwartetes Verhalten im heruntergestuften Zustand.

Szenario 5: Phasenübergänge Wartungsmodus 

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

Was ist los:

• Der Rollenausgleich 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 kann es während des Übergangs zu kurzen Latenzspitzen kommen

Auswirkungen:

• Auswirkungen auf Kunden: Kurze Latenzspitzen von Sekunden bis zu einigen Minuten Liegt in der Regel unterhalb der Schwellenwerte für Anwendungs-Timeouts
• Dauer: Dauert Sekunden bis einige Minuten und setzt sich dann ab
• Genesung: Automatisch

Kette von Ereignissen:

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

Ein Softwarefehler in der MDM-Rollenausgleichslogik verursacht eine Feedbackschleife, wenn der Cluster aufgrund eines SDS-Verlusts oder Wartungsmodus-Vorgangs in den Status 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 zuständig sind. Bei jeder Neuzuweisung wird die zwischengespeicherte Ansicht des SDC über den Speicherort der Daten ungültig, wodurch I/O-Wiederholungen erzwungen werden. Wenn viele Kämme gleichzeitig betroffen sind, übersteigt das Volumen der Neuzuweisungen die Aktualisierungsfähigkeit der SDCs, was zu anhaltenden I/O-Fehlern auf mehreren Hosts führt.

Der Sturm ist in der Regel selbstlimitierend. Sie löst sich auf, 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 Versionszeitrahmen zu erhalten.

Für geplante Wartungsvorgänge:

• Schalten Sie einen SDS erst aus und wieder ein und wieder ein oder starten Sie ihn neu, bis das MDM-Protokoll SDS_MAINTENANCE_MODE_STARTED. Überprüfen Sie, ob der SDS vollständig in den Wartungsmodus versetzt wurde, bevor Sie mit der physischen Wartung fortfahren.
• Überwachen Sie Latenzspitzen beim Wechsel in den oder aus dem Wartungsmodus.

Bei ungeplanten SDS-Ausfällen:

• Der Sturm ist selbstlimitierend und löst sich in der Regel innerhalb von Minuten auf, wenn sich der Cluster stabilisiert. Wenn das Problem beobachtet wird, 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 von selbst löst, kann sich der MDM durch vorübergehendes Deaktivieren und erneutes Aktivieren der Wiederherstellung stabilisieren:

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

# Warten Sie 5-10 Sekunden und aktivieren Sie dann den erneuten Aufbau: 

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