PowerFlex: Zmiana ról nadmiernej ilości danych powoduje opóźnienia i błędy we/wy

W przypadku niektórych przejść stanu klastra logika równoważenia ról MDM może powodować szybkie, powtarzające się przełączanie ról podstawowych/pomocniczych w wielu comb (wewnętrznych strukturach danych, które śledzą, które węzły SDS przechowują każdy fragment danych woluminu). Każdy przełącznik roli unieważnia mapy comb po stronie klienta (SDC) i wymusza ponawianie prób we/wy. W przypadku jednoczesnego wpływu na wystarczającą liczbę comb skumulowany narzut ponawiania prób powoduje skoki opóźnień we/wy i błędy we/wy na hostach SDC. W zależności od środowiska hosta może to spowodować przekroczenie limitu czasu we/wy aplikacji, przejście maszyn wirtualnych w stan tylko do odczytu lub niedostępność systemu plików.

To zachowanie zostało zaobserwowane w wielu scenariuszach wyzwalania i nie jest ograniczone do żadnej pojedynczej procedury operacyjnej.

Wspólne wskaźniki

• MDM_DATA_DEGRADED zdarzenie, po którym następuje utrzymujące się opóźnienie we/wy trwające 1-15+ minut
• Hosty SDC zgłaszają błędy we/wy i/lub przekroczenie limitu czasu we/wy w oknie obniżonej wydajności
  • VMware (ESXi): Limity czasu pulsu VMFS, błędy sprzętowe SCSI (sense data: 0x4 0x0 0x0), maszyny wirtualne wchodzące w stan tylko do odczytu, potencjalne przełączenie awaryjne HA
  • Linux: Błędy we/wy w rejestrach systemowych (/var/log/messages, dmesg), w aplikacjach może wystąpić przekroczenie limitu czasu we/wy lub ponowne zamontowanie systemu plików w trybie tylko do odczytu
• Dzienniki zdarzeń MDM pokazują, że system znajduje się w stanie DEGRADED dłużej niż oczekiwano w przypadku pojedynczej utraty SDS
• System w końcu sam powraca do NORMALNEGO stanu bez ręcznej interwencji (zazwyczaj)

Scenariusz 1: Niewdzięczna utrata SDS (brak trybu serwisowego)

Kiedy może się to zdarzyć:

• To rzadki scenariusz. Aby podczas niewdzięcznej utraty SDS wystąpiły szybkie, powtarzające się zdarzenia zmiany ról, musi wystąpić jednocześnie kilka określonych warunków:

• • Środowisko o dużej skali — znaczna liczba węzłów i woluminów SDS
  • Duże obciążenie we/wy produkcji — znaczna aktywność we/wy w momencie awarii SDS
  • Obciążenie robocze odbudowy przekracza pojemność przetwarzania — liczba wierszy metadanych wymagających ponownego kompilowania przekracza limit modułu równoważenia MDM na cykl wynoszący 1024 wiersze

Każdy cykl równoważenia może przetwarzać maksymalnie 1024 wiersze metadanych. Gdy trzeba odbudować więcej wierszy, moduł równoważenia nie może zakończyć bieżącego planu przed wygenerowaniem następnego.

Co się dzieje:

• Serwer SDS nagle odłącza się od MDM (zdarzenie SDS_DECOUPLED)
• Wszystkie klienty SDC, które były połączone z tym serwerem SDC, tracą połączenia → zdarzeniach rozłączenia SDC
• MDM oznacza klaster jako DEGRADED (zdarzenie) MDM_DATA_DEGRADED)
• Ponieważ liczba wierszy do ponownego skompilowania przekracza 1 024, moduł równoważenia MDM nie może ukończyć bieżącego planu równoważenia
• Moduł równoważenia uruchamia nowy plan, podczas gdy poprzedni plan jest nadal uruchomiony, generując szybkie, powtarzające się zdarzenia zmiany roli
• SDC klienta widzą ciągłe awarie we/wy (IO_FAULT_NOT_PRI, SCSI sense 0x4). Po wyczerpaniu ponownych prób system operacyjny hosta zgłasza błędy we/wy, przekroczenie limitu czasu lub system plików tylko do odczytu
• Ślady MDM:

Gdy obciążenie ponownego równoważenia przekroczy limit 1 024 wierszy, ślad MDM pokazuje przekroczenie próg:

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.

Oznacza to, że 1098 wierszy wymagało przebudowy, ale tylko 1024 można było przetworzyć w bieżącym cyklu. Pozostałe wiersze wyzwalają nowy plan równoważenia przed zakończeniem poprzedniego planu, uruchamiając pętlę informacji zwrotnych.

Łańcuch zdarzeń:

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

Scenariusz 2: Wyłączanie karty SDS podczas wprowadzania PMM

Kiedy może się to zdarzyć:
Jest to rzadki scenariusz, który wymaga dwóch jednoczesnych zdarzeń:

• Karta SDS przechodzi w tryb chronionej konserwacji (PMM)
• Serwer SDS ulega awarii lub zostaje wyłączony przed zakończeniem przejścia PMM

Co się dzieje: 

• MDM otrzyma polecenie wpisu PMM i zarejestruje je jako pomyślne
• Serwer SDS nieoczekiwanie odłącza się, gdy wpis PMM jest nadal w toku
• MDM oznacza klaster jako DEGRADED
• Moduł równoważenia ról wchodzi w trwałą pętlę zmiany ról przez całą fazę wejścia PMM
• Wiersze danych inne niż PMM są wielokrotnie przełączane w całej puli pamięci masowej
• Burza trwa do momentu, aż SDS ponownie dołączy do klastra i zakończy przejście trybu konserwacji

Łańcuch zdarzeń:

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

Przykładowa sekwencja zdarzeń 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

Po ponownym dołączeniu SDS i zakończeniu PMM:

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

Scenariusz 3: SDS w trybie natychmiastowej konserwacji (IMM)

Kiedy może się to zdarzyć:
Karta SDS wchodzi lub wychodzi z trybu natychmiastowej konserwacji (IMM). Ten scenariusz występuje, gdy pojedynczy serwer SDS jest w trybie konserwacji i system nie może zdecydować, który serwer SDS powinien obsługiwać operacje we/wy dla określonych danych.

Co się dzieje:

• System wielokrotnie zmienia, który SDS jest odpowiedzialny za obsługę tych samych danych
• Te ciągłe zmiany oznaczają, że aplikacje nie wiedzą, gdzie wysyłać swoje żądania we/wy
• Operacje we/wy są wysyłane do niewłaściwego serwera SDS, co powoduje ponawianie prób i opóźnienia
• Aplikacje doświadczają opóźnień lub przekroczenia limitu czasu podczas próby uzyskania dostępu do danych, których dotyczy problem

Skutek:

• Wpływ na klienta: Aplikacje zgłaszają opóźnienia i limity czasu, gdy SDS jest w IMM
• Czas trwania: Kontynuacja, gdy SDS jest w stanie IMM
• Odzyskiwania: Automatycznie — rozwiązuje problem po zamknięciu programu IMM z SDS.

Łańcuch zdarzeń:

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

Scenariusz 4: SDS – wyjście z trybu chronionej konserwacji (PMM)

Kiedy może się to zdarzyć:
Karta SDS opuszcza tryb chronionej konserwacji (PMM). Taki scenariusz występuje przy każdym wyjściu PMM - nie jest to rzadkie zdarzenie, ale dotkliwość zależy od tego, jak długo trwała praca w trybie konserwacji.

Co się dzieje:

• Gdy SDS wychodzi z PMM, moduł równoważenia ról musi ponownie przypisać segmenty danych, aby uwzględnić powracający SDS
• Proces równoważenia ma wpływ na całą pulę pamięci, a nie tylko na dane w powracającym SDS
• Podczas reintegracji dochodzi do zamiany ról w wielu segmentach danych
• Aplikacje mogą doświadczać krótkich błędów we/wy lub opóźnień po ustabilizowaniu się przypisanych ról

Skutek:

• Wpływ na klienta: W przypadku krótkich okien konserwacyjnych (mniej niż 5 sekund) wpływ jest ledwo zauważalny. W przypadku długotrwałej konserwacji z aktywnymi wejściami/wyjściami mogą wystąpić tysiące przełączników ról, powodując długotrwałe przestoje we/wy
• Czas trwania: Kontynuowany w trakcie fazy reintegracji, aż do zakończenia równoważenia
• Odzyskiwania: Automatyczna

Łańcuch zdarzeń:

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

Przykładowa sekwencja zdarzeń MDM:

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

Dane wyjściowe dziennika:
 

Dzienniki zdarzeń MDM: Dziennik zdarzeń MDM pokazuje sekwencję na poziomie klastra. Kluczowymi wskaźnikami są operacje przełączania ról podczas wychodzenia z trybu konserwacji.

Dzienniki śledzenia SDS: W węzłach SDS dzienniki śledzenia pokazują powtarzające się operacje przełączania ról podczas ponownej integracji:

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

Duża liczba wpisów ról Switch w krótkim czasie (tysiące lub więcej w ciągu kilku sekund) jest ostatecznym wskaźnikiem tego problemu po stronie SDS.

Dzienniki SDC/hosta: Ponawianie próby we/wy VMware (ESXi) SDC, pokazując comb, docelowy SDS i kod błę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)

W przypadku wyczerpania ponownych prób zwracane są błędy SCSI: 

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

Wskazówka diagnostyczna: Jeśli błędy we/wy są widoczne w wielu węzłach SDS (nie tylko w węźle, w którym wystąpił problem), może to wskazywać na burzę po przełączeniu ról, a nie normalne zachowanie stanu o obniżonym sprawdzeniu. Jeśli błędy we/wy są izolowane tylko w pojedynczym serwerze SDS, takie zachowanie powinno być obniżone.

Scenariusz 5: Przejścia fazowe w trybie konserwacji 

Kiedy może się to zdarzyć:
Podczas przejścia, gdy SDS wchodzi lub wychodzi z trybu konserwacji (IMM lub PMM) — w tym momencie stan zmienia się z normalnego na MM lub z powrotem z MM z powrotem na normalny.

Co się dzieje:

• Moduł równoważenia ról redystrybuuje obowiązki związane z danymi, aby dostosować się do zmiany
• Pojawiają się krótkie serie zmian ról, gdy system przyzwyczaja się do nowego układu
• Aplikacje mogą doświadczać krótkich skoków opóźnień podczas przejścia

Skutek:

• Wpływ na klienta: Krótkie skoki opóźnienia trwające od kilku sekund do kilku minut. Zwykle poniżej progów limitu czasu aplikacji
• Czas trwania: Trwa od kilku sekund do kilku minut, a następnie stabilizuje się
• Odzyskiwania: Automatyczna

Łańcuch zdarzeń:

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

Wada oprogramowania w logice równowagi ról MDM powoduje pętlę sprzężenia zwrotnego, gdy klaster przechodzi w stan z powodu utraty SDS lub działania trybu konserwacji.

W pewnych warunkach MDM wielokrotnie ponownie przypisuje węzły SDS odpowiedzialne za obsługę operacji we/wy do combów, których dotyczy problem. Każde ponowne przypisanie unieważnia buforowany widok SDC miejsca, w którym znajdują się dane, wymuszając ponawianie prób we/wy. W przypadku jednoczesnego wpływu wielu comb ilość ponownych przypisań przekracza zdolność SDC do aktualizacji, co powoduje utrzymujące się błędy we/wy na wielu hostach.

Burza jest zazwyczaj samoograniczająca się. Problem zostanie rozwiązany po ustabilizowaniu klastra, ale czas trwania zależy od rozmiaru domeny ochrony i obciążenia we/wy w momencie wystąpienia zdarzenia.

Ten problem został rozwiązany w rozwiązaniu PowerFlex Core w wersji 4.5.6. Uaktualnij do tej wersji, gdy będzie dostępna. Skontaktuj się z działem pomocy technicznej firmy Dell , aby uzyskać informacje o harmonogramie wydania.

W przypadku planowanych prac konserwacyjnych:

• Nie wyłączaj i nie włączaj ponownie karty SDS ani nie uruchamiaj jej ponownie, dopóki nie pojawią się logi MDM SDS_MAINTENANCE_MODE_STARTED. Przed przystąpieniem do konserwacji fizycznej sprawdź, czy serwer SDS całkowicie przeszedł w tryb konserwacji.
• Monitoruj skoki opóźnień podczas wchodzenia lub wychodzenia z trybu konserwacji.

W przypadku nieplanowanych awarii systemu SDS:

• Burza jest samoograniczająca się i zazwyczaj ustępuje w ciągu kilku minut po ustabilizowaniu się klastra. W przypadku zaobserwowania problemu należy zebrać getinfo dzienniki ze wszystkich węzłów SDS w domenie ochrony, z systemów MDM wszystkich menedżerów tak szybko, jak to możliwe po wystąpieniu zdarzenia, i skontaktuj się z działem pomocy technicznej firmy Dell.

W rzadkich przypadkach, gdy problem nie zostanie rozwiązany samodzielnie, tymczasowe wyłączenie i ponowne włączenie odbudowy może pozwolić na ustabilizowanie MDM:

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

# Poczekaj 5-10 sekund, a następnie włącz odbudowę: 

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