PowerFlex 3.x: migracja vTree może spowodować panikę lub zawieszenie SDS

W PowerFlex w wersji 3.6.7 podczas zaplanowanej migracji vTree wiele serwerów SDS ulega awarii, co powoduje, że system przechodzi w stan niedostępności danych.

W wyniku opóźnień migracji wykorzystanie pojemności puli pamięci masowej (SP) gwałtownie wzrasta i można osiągnąć pełne wykorzystanie w krótkim czasie.

Zdarzenia MDM:

2026-06-30 07:27:19.340 SDS_DECOUPLED ERROR SDS: SDS11 (id: 64cb920800000006) decoupled.
2026-06-30 07:27:19.465 MDM_DATA_DEGRADED ERROR The system is now in DEGRADED state
....
2026-06-30 07:32:20.638 SDS_DECOUPLED ERROR SDS: SDS9 (id: 64cb920b00000009) decoupled.
2026-06-30 07:32:20.638 SDS_DECOUPLED ERROR SDS: SDS12 (id: 64cb920a00000008) decoupled.
2026-06-30 07:32:21.842 MDM_DATA_FAILED CRITICAL The system is now in DATA FAILURE state. Some data is unavailable
...
2026-06-30 07:32:23.538 DEV_CAPACITY_USAGE_CRITICAL ERROR Capacity usage on Protection Domain PD1, Storage Pool FGSP_01 is CRITICAL.
2026-06-30 07:32:23.605 DEV_CAPACITY_USAGE_FULL ERROR Capacity usage on Protection Domain PD1, Storage Pool FGSP_02 is FULL.

Dzienniki śledzenia na wszystkich węzłach SDS, których dotyczy problem, generują ten sam ślad stosu błędów:

2026/07/01 17:45:33.506630 Panic in file /data/build/workspace/ScaleIO-Common-Job/src/mos/mos_timer.c, line 437, function mosTimerReq_AddByQ, PID 1291427.Panic Expression pReq->state == MOS_TIMER_REQ_STATE__IDLE .
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(mosDbg_PanicPrepare+0xe5) [0x932ce5]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(mosTimerReq_AddByQ+0x143) [0x917043]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(vaeCleaner_CleanVae+0x64) [0x668904]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(head_removeVae+0x170) [0x545e00]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(head_Update+0x373) [0x546363]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contHead_UpdateFull+0x69) [0x4db689]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contCmd_AddHead+0x18a) [0x60d85a]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contCmd_AddHeadGroup+0x100) [0x61b630]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contCmd_NewRequest+0x15fd) [0x62b96d]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contNet_RecvRequest+0xd0) [0x4ce880]

W przypadku PowerFlex w wersji starszej niż 3.6.7 podczas zaplanowanej migracji vTree postęp migracji zawiesza się i nigdy nie kończy się.

W interfejsie użytkownika > PowerFlex Manager Running Storage Jobs wyświetlany jest komunikat Ładowanie w nieskończoność:

query_vtree_migration dane wyjściowe pokazują, że procent postępu nigdy się nie zmienia:

scli --query_vtree_migration --volume_id 53b80e00000000d1
VTree ID: ba46bf57000000d1 Name: PDC-GC-LNX-N-01-PFSP01-01-V043
    Storage Pool 5f2f4acc00000000 Name: PDC-FLEX-LNX-SP01
    Protection Domain 908ff43700000000 Name: PDC-FLEX-LNX-PD01
    Data layout: Medium granularity
    Provisioning: Thin
    Total capacity in use: 504.7 GB (516787 MB)
    Total user data: 504.7 GB (516787 MB)
            Total base user data: 504.7 GB (516787 MB)
            Total snapshots user data: 0 Bytes
    VTree migration info:
            Migration status: Migrating
            Source:      Storage Pool: PDC-FLEX-LNX-SP01 ID: 5f2f4acc00000000 Protection Domain: PDC-FLEX-LNX-PD01 ID: 908ff43700000000
            Destination: Storage Pool: PDC-FLEX-LNX-SP03 ID: 5f2fe70d00000004 Protection Domain: PDC-FLEX-LNX-PD03 ID: 9090907800000003
            Conversion type: No conversion
            Queue position: 1
            Progress percentage : 34%

Wpływ

W wersjach wcześniejszych niż 3.6.7 migracja woluminów nigdy się nie kończy, wykorzystanie pojemności SP jest krytyczne lub wyższe, a aplikacje mogą doświadczać błędów we/wy.

W wersji 3.6.7 niedostępność danych.

Ten problem jest spowodowany wielowątkowym wyścigiem obejmującym mechanizm współużytkowanego czasomierza w składniku czyszczącym element alokacji woluminu (VAE) podczas operacji migracji woluminów.

W wersjach PowerFlex wcześniejszych niż 3.6.7 asynchroniczny proces czyszczenia był używany do usuwania danych ze starych lokalizacji SP po migracji. W rzadkich sytuacjach, takich jak współbieżne operacje zarządzania woluminami, jednoczesne usuwanie woluminów, duże obciążenie we/wy lub niestabilność sieci, ten proces może doświadczyć sytuacji wyścigu, który powoduje, że migracje wydają się być zablokowane na czas nieokreślony.

Aby rozwiązać ten problem, w wersji 3.6.7 wprowadzono ulepszony mechanizm monitorowania. Ten mechanizm bezpieczeństwa był wyposażony w zegar zaprojektowany w celu wykrywania zablokowanego wątku czyszczenia VAE i proaktywnego uruchamiania usługi SDS w celu uniknięcia uszkodzenia danych lub przedłużającego się przestoju, podobnie jak system obsługuje zablokowane polecenia we/wy lub MDM.

Jednak w początkowej implementacji tej poprawki czasomierz monitorowania został zainicjowany tylko raz podczas konstruowania danych migracji i był udostępniany globalnie we wszystkich kolejnych wywołaniach czyszczenia VAE. Gdy wiele wątków w tle próbuje uzyskać dostęp do tego pojedynczego udostępnionego czasomierza jednocześnie podczas dużych obciążeń migracji, wyzwalany jest nowy warunek wyścigu. Ten równoczesny dostęp powoduje, że mechanizm śledzenia nieprawidłowo oznacza narzędzie czyszczące VAE jako zablokowane, co powoduje niezamierzone awarie usługi SDS i lokalne zakłócenia dostępności danych, co skutkuje niedostępnością danych.

Trwała poprawka (zalecana)

Uaktualnij klaster do wersji PowerFlex 3.6.7.1 lub nowszej. Uwzględniono poprawkę dotyczącą zarówno warunków czyszczenia VAE, jak i wyścigu czasowego.

Obejście problemu (jeśli uaktualnienia nie można wykonać natychmiast)

W wersjach wcześniejszych niż 3.6.7

1. W głównym systemie MDM przejdź do katalogu dzienników śledzenia znajdującego się pod adresem /opt/emc/scaleio/mdm/logs/. Aby znaleźć bieżący dziennik śledzenia, uruchom polecenie ls -ltr, więc najnowszy trc.z.* Log znajduje się na dole listy.
2. Ponieważ dzienniki są skompresowane, użyj trace_decompress Przedsiębiorstwo użyteczności publicznej zlokalizowane pod /opt/emc/scaleio/mdm/bin/

tail -f <current_trace_log> | /opt/emc/scaleio/mdm/bin/trace_decompress

3. Filtruj według identyfikatora SDS (na przykład TGT) wpisy. Użyj polecenia grep polecenie do znalezienia:

tail -f <current_trace_log> | /opt/emc/scaleio/mdm/bin/trace_decompress | grep volumeBlock_HandleQueryCleanVaeResponse

4. Zidentyfikuj TGT. Poszukaj wierszy podobnych do następujących w filtrowanych danych wyjściowych:

TGT 41a903f100000036 not done yet

Jeśli TGT Identyfikator pozostaje spójny w czasie i prawdopodobnie odpowiada węźle SDS. Uruchom ponownie krok 3, aby upewnić się, że jest spójny.

5. Uruchom następujące polecenie, aby wyświetlić listę wszystkich węzłów SDS i dopasować TGT Identyfikator z nazwą SDS/adresem IP:

scli --query_all_sds

6. Po uzyskaniu potrzebnych informacji można SSH do tego SDS i uruchom ponownie usługę SDS, uruchamiając:

pkill sds

W wersji 3.6.7

• Serializacja operacji zarządzania woluminami — uruchamianie tylko jednego usuwania, zmiany rozmiaru lub migracji naraz.
• Zmniejszenie obciążenia we/wy w dotkniętych domenach ochrony podczas migracji.
• Unikanie masowych migracji vTree; Podziel je na małe grupy.
• Nie wstrzymuj ani nie anuluj migracji, gdy sieć wykazuje niestabilność.

Działania te zmniejszają prawdopodobieństwo jednoczesnego użycia czasomierza, a tym samym zmniejszają liczbę zdarzeń paniki.

Wersje, których dotyczy problem

PowerFlex Core 3.x.x.x

Naprawiono w wersji

PowerFlex Core 3.6.7.1