PowerFlex: Nadměrné přepínání rolí dat způsobuje latenci vstupně-výstupních operací a chyby.

Při určitých přechodech stavu clusteru může logika vyrovnávání rolí MDM vytvářet rychlé a opakované přepínání primárních/sekundárních rolí v mnoha hřebenech (interní datové struktury, které sledují, které uzly SDS ukládají jednotlivá data svazku). Každý přepínač rolí zneplatní mapování hřebenů na straně klienta (SDC) a vynutí opakování vstupně-výstupních operací. Pokud je současně ovlivněno dostatečné množství hřebenů, kumulativní režie opakování způsobí špičky latence vstupně-výstupních operací a vstupně-výstupní chyby na hostitelích SDC. V závislosti na hostitelském prostředí to může vést k vypršení časového limitu vstupně-výstupních operací aplikace, přechodu virtuálních počítačů do stavu jen pro čtení nebo nedostupnosti systému souborů.

Toto chování bylo pozorováno ve scénářích několika triggerů a není omezeno na žádný jeden provozní postup.

Běžné indikátory

• MDM_DATA_DEGRADED událost následovaná trvalou latencí I/O trvající 1–15+ minut
• Hostitelé SDC hlásí chyby I/O nebo překročení časového limitu I/O během sníženého režimu okna
  • VMware (ESXi): Překročení časových limitů prezenčního signálu VMFS, chyby hardwaru SCSI (sense data: 0x4 0x0 0x0), virtuální počítače přecházející do stavu jen pro čtení, potenciální převzetí služeb při selhání HA
  • Linux: Chyby I/O v systémových protokolech (/var/log/messages, dmesg), u aplikací může docházet k vypršení časového limitu I/O nebo k opětovnému připojení systému souborů pouze pro čtení
• Protokoly událostí MDM zobrazují systém v DEGRADED stavu déle, než se očekávalo pro jednu ztrátu SDS
• Systém se nakonec sám obnoví do NORMÁLNÍHO stavu bez ručního zásahu (obvykle)

1. scénář: Vážná ztráta SDS (bez režimu údržby)

Kdy se to může stát:

• To je vzácný scénář. Aby během těžké ztráty SDS docházelo k rychlým opakovaným událostem změny rolí, musí být současně přítomno několik specifických podmínek:

• • Rozsáhlé prostředí – značný počet uzlů a svazků SDS
  • Těžké výrobní zatížení I/O – významná aktivita I/O v okamžiku selhání SDS
  • Úloha opětovného sestavení překračuje kapacitu zpracování – počet řádků metadat vyžadujících opětovné sestavení překračuje limit nástroje vyrovnávání MDM na cyklus 1 024 řádků.

Každý cyklus rebalancování může zpracovat až 1 024 řádků metadat. Pokud je potřeba znovu sestavit více řádků, nástroj pro vyrovnávání nemůže dokončit aktuální plán před vygenerováním dalšího.

Co se stane:

• SDS se náhle odpojí od MDM (událost SDS_DECOUPLED)
• Všechny SDC, které byly připojeny k tomuto SDS, ztratí svá připojení → událostech odpojení SDC
• Uzel MDM označí cluster jako DEGRADED (událost). MDM_DATA_DEGRADED)
• Vzhledem k tomu, že počet řádků, které se mají znovu sestavit, je větší než 1 024, nástroj pro vyrovnávání uzlů MDM nemůže dokončit aktuální plán vyvážení
• Nástroj pro vyrovnávání spustí nový plán, zatímco předchozí plán je stále spuštěný, a vytváří rychlé a opakované události přepínání rolí
• U klientských SDC dochází k průběžným selháním I/O (IO_FAULT_NOT_PRI, SCSI sense 0x4). Po vyčerpání opakovaných pokusů hostitelský operační systém nahlásí vstupně-výstupní chyby, vypršení časových limitů nebo systém souborů jen pro čtení
• Důkaz trasování MDM:

Když úloha opětovného vyvážení překročí limit 1 024 řádků, trasování MDM zobrazí překročenou prahovou hodnotu:

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.

To znamená, že 1 098 řádků vyžadovalo opětovné sestavení, ale v aktuálním cyklu bylo možné zpracovat pouze 1 024. Zbývající řádky aktivují nový plán vyvážení před dokončením předchozího plánu, čímž se spustí smyčka zpětné vazby.

Řetězec událostí:

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

2. scénář: Vypnutí SDS během vstupu PMM

Kdy se to může stát:
Jedná se o vzácný scénář, který vyžaduje dvě souběžné události:

• Disk SDS přechází do režimu chráněné údržby (PMM)
• SDS selže nebo je vypnut před dokončením přechodu PMM

Co se stane: 

• MDM přijme příkaz pro zadání PMM a zaznamená jej jako úspěšný
• SDS se neočekávaně odpojí, zatímco položka PMM stále probíhá
• MDM označí cluster jako DEGRADED
• Nástroj pro vyrovnávání rolí vstupuje do trvalé smyčky přepínání rolí během fáze vstupu PMM
• Řádky dat mimo PMM se opakovaně přepínají v celém fondu úložiště
• Bouřlivé bouře přetrvává, dokud se disk SDS znovu nepřipojí ke clusteru a nedokončí přechod režimu údržby

Řetězec událostí:

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

Příklad sekvence událostí MDM:

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

Když se SDS znovu připojí a PMM se dokončí:

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

Scénář 3: SDS v režimu okamžité údržby (IMM)

Kdy se to může stát:
SDS vstoupí do režimu okamžité údržby (IMM) nebo jej ukončí. K tomuto scénáři dochází, když je jeden SDS v režimu údržby a systém se nemůže rozhodnout, který SDS má zpracovávat I/O pro konkrétní data.

Co se stane:

• Systém opakovaně mění, který SDS je zodpovědný za poskytování stejných dat
• Tyto neustálé změny znamenají, že aplikace nevědí, kam mají své vstupně-výstupní požadavky posílat
• Vstup/výstup se odesílá do nesprávného bezpečnostního listu, což způsobuje opakované pokusy a zpoždění.
• U aplikací dochází při pokusu o přístup k dotčeným datům k latenci nebo vypršení časového limitu

Dopad:

• Dopad na zákazníka: Aplikace hlásí latenci a vypršení časového limitu, když je SDS v IMM
• Délka: Pokračuje, když je SDS ve stavu IMM.
• Obnovení: Automaticky – vyřeší se, když SDS ukončí IMM

Řetězec událostí:

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

Scénář 4: Ukončení SDS z režimu chráněné údržby (PMM)

Kdy se to může stát:
SDS ukončí režim chráněné údržby (PMM). K tomuto scénáři dochází při každém ukončení PMM - nejedná se o vzácnou událost, ale závažnost závisí na tom, jak dlouho trvala operace režimu údržby.

Co se stane:

• Jakmile SDS ukončí PMM, musí nástroj pro vyrovnávání rolí znovu přiřadit datové segmenty tak, aby zahrnovaly vracející SDS
• Proces vyvážení má vliv na celý fond úložiště, nejen na data ve vracejícím se bezpečnostním listu
• Během opětovné integrace dochází k přepínání rolí v mnoha datových segmentech
• U aplikací může docházet ke krátkým vstupně-výstupním chybám nebo latenci, protože přiřazení rolí se stabilizují

Dopad:

• Dopad na zákazníka: U krátkých intervalů údržby (méně než 5 sekund) je dopad sotva znatelný. Při delší údržbě s aktivními vstupy/výstupy může dojít k tisícům přehození rolí, což může způsobit trvalé zastavení I/O
• Délka: Pokračuje během fáze opětovného začlenění, dokud není dosaženo rovnováhy.
• Obnovení: Automaticky

Řetězec událostí:

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

Příklad sekvence událostí MDM:

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

Výstupy protokolu:
 

Protokoly událostí MDM: V protokolu událostí MDM se zobrazuje sekvence na úrovni clusteru. Klíčovými indikátory jsou operace přepínání rolí během ukončení režimu údržby.

Protokoly trasování SDS: Na uzlech SDS se v protokolech trasování během opětovné integrace zobrazují opakované operace přepínání rolí:

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

Velký objem záznamů o rolích přepínače v krátkém časovém intervalu (tisíce nebo více během několika sekund) je definitivním indikátorem tohoto problému na straně SDS.

Protokoly SDC/hostitele: Opakované pokusy o provedení I/O VMware (ESXi) SDC se zobrazením hřebenu, cílového bezpečnostního listu a chybového kódu:

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)

Pokud se opakované pokusy vyčerpají, zobrazí se chyby SCSI: 

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

Diagnostický tip: Pokud se zobrazí chyby I/O na více uzlech SDS (nejen na uzlu, u kterého došlo k problému), může to znamenat zahlcení přepínačem rolí, nikoli normální chování ve sníženém stavu. Pokud jsou vstupně-výstupní chyby izolovány na jeden SDS, jedná se o očekávané chování ve sníženém stavu.

Scénář 5: Fázové přechody režimu údržby 

Kdy se to může stát:
Během přechodu, kdy SDS vstoupí nebo ukončí režim údržby (IMM nebo PMM) - v okamžiku, kdy se stav změní z normálního na MM nebo z MM zpět na normální.

Co se stane:

• Nástroj pro vyrovnávání rolí přerozděluje zodpovědnosti dat tak, aby se přizpůsobil změně.
• Když se systém usadí v novém uspořádání, dochází ke krátkým výbuchům přepínání rolí
• U aplikací může během přechodu docházet ke krátkým špičkám latence

Dopad:

• Dopad na zákazníka: Krátké špičky latence trvající sekundy až několik minut. Obvykle pod prahovými hodnotami časového limitu aplikace
• Délka: Trvá několik sekund až několik minut, poté se usadí
• Obnovení: Automaticky

Řetězec událostí:

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

Softwarová závada v logice vyrovnávání rolí MDM způsobuje smyčku zpětné vazby, když cluster přejde do stavu z důvodu ztráty SDS nebo operace režimu údržby.

Za určitých podmínek uzel MDM opakovaně přiřazuje, které uzly SDS jsou zodpovědné za obsluhu I/O dotčených hřebenů. Každé opětovné přiřazení zneplatní zobrazení SDC uložené v mezipaměti o tom, kde se data nacházejí, a vynutí opakování vstupně-výstupních operací. Pokud je postiženo mnoho hřebenů současně, objem opětovného přiřazení převyšuje schopnost SDC aktualizovat, což vede k trvalým chybám I/O napříč více hostiteli.

Bouře se obvykle sama omezí. Problém se vyřeší, jakmile se cluster stabilizuje, ale doba trvání závisí na velikosti domény ochrany a zatížení I/O v době události.

Tento problém je vyřešen v PowerFlex Core verze 4.5.6. Jakmile bude dostupná verze, proveďte upgrade na tuto verzi. Informace o časovém harmonogramu vydání vám poskytne podpora společnosti Dell .

Pro plánované operace údržby:

• SDS nevypínejte a nerestartujte jej, dokud se uzel MDM nezapíše SDS_MAINTENANCE_MODE_STARTED. Než budete pokračovat ve fyzické údržbě, ověřte, zda systém SDS zcela přešel do režimu údržby.
• Sledujte špičky latence při vstupu do režimu údržby nebo jeho ukončení.

V případě neplánovaných výpadků SDS:

• Bouře se sama omezí a obvykle se vyřeší během několika minut, jakmile se cluster stabilizuje. Pokud zjistíte problém, shromážděte getinfo protokoly ze všech uzlů SDS v doméně ochrany a ze všech manažerských MDM co nejdříve po události a obraťte se na podporu společnosti Dell.

Ve vzácných případech, kdy se problém nevyřeší sám, může dočasné vypnutí a opětovné povolení opětovného sestavení umožnit stabilizaci uzlu MDM:

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

# Počkejte 5–10 sekund a poté povolte opětovné vytvoření: 

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