PowerFlex 3.x: Міграція vTree може спричинити паніку або зависання SDS

У версії PowerFlex 3.6.7 під час запланованої міграції vTree кілька SDS панікують, що призводить до того, що система переходить у стан недоступності даних.

Внаслідок затримок міграції споживання потужності Storage Pool (SP) швидко зростає і може досягти повного використання за короткий час.

Події 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.

Журнали трасування на всіх уражених SDS-вузлах створюють однаковий трек стеку паніки:

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]

У версіях PowerFlex раніше 3.6.7, під час запланованої міграції vTree, прогрес міграції зависає і ніколи не завершується.

У PowerFlex Manager UI > Running Storage Jobs безкінечно показує завантаження:

query_vtree_migration вихід показує, що відсоток прогресу ніколи не змінюється:

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%

Вплив

У версіях до 3.6.7 міграція томів ніколи не закінчується, використання потужності SP критичне або вище, а застосування може стикатися з помилками введення/виведення.

У версії 3.6.7 дані недоступні.

Ця проблема виникає через багатопотокову гонку, що передбачає спільний таймер у компоненті очищувача Volume Allocation Element (VAE) під час операцій міграції томів.

У версіях PowerFlex до версії 3.6.7 використовувався асинхронний процес очищення для видалення даних зі старих SP-локацій після міграції. За рідкісних умов, таких як одночасні операції управління обсягом, одночасне видалення томів, високе навантаження на введення/виведення або нестабільність мережі, цей процес може зазнавати гоночної умови, через яку міграції виглядають безстроково заблокованими.

Для вирішення цієї проблеми у версії 3.6.7 було введено вдосконалений механізм моніторингу. Цей захисний механізм мав таймер, призначений для виявлення застряглого потоку VAE для очищення та проактивного панікування сервісу SDS, щоб запобігти пошкодженню даних або тривалим затримкам, подібно до того, як система обробляє застрягли команди введення/виведення або MDM.

Однак у початковій реалізації цього виправлення таймер моніторингу був ініціалізований лише один раз під час побудови даних міграції і використовувався глобально для всіх наступних викликів VAE cleaner. Коли кілька фонових потоків намагаються одночасно отримати доступ до цього спільного таймера під час інтенсивних міграційних навантажень, спрацьовує нова умова гонки. Цей одночасний доступ призводить до того, що механізм відстеження неправильно позначає VAE-очищувач як застряг, що призводить до ненавмисних збоїв SDS-сервісу та локальних порушень доступності даних, що призводить до недоступності даних.

Постійне рішення (рекомендовано)

Оновіть кластер до PowerFlex 3.6.7.1 або новішої версії. Виправлення як для VAE-cleaner, так і для умов гонки з таймером включено.

Обхідний шлях (якщо оновлення неможливо виконати негайно)

У версіях раніше 3.6.7

1. На первинному MDM перейдіть до каталогу журналів трасування на /opt/emc/scaleio/mdm/logs/. Щоб знайти поточний журнал трасування , запустіть ls -ltr, тобто останнє trc.z.* журнал наведений внизу списку.
2. Оскільки логарифми стискаються, використовуйте trace_decompress Утиліта, розташована за /opt/emc/scaleio/mdm/bin/

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

3. Фільтр для SDS ID (наприклад, TGT) записів. Використовуйте grep Команда для пошуку:

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

4. Визначте TGT. Шукайте лінії, подібні до наступних, у фільтрованому виході:

TGT 41a903f100000036 not done yet

Якщо TGT ID залишається послідовним з часом, ймовірно, відповідає залученому SDS-вузлу. Повторіть крок 3, щоб переконатися, що він залишається стабільним.

5. Виконайте наступну команду, щоб перелічити всі вузли SDS і зіставити TGT ID з ім'ям SDS/IP-адресою:

scli --query_all_sds

6. Коли у вас буде необхідна інформація, ви можете SSH до цього SDS і перезапустити сервіс SDS, запустивши:

pkill sds

У версії 3.6.7

• Серіалізуйте операції з управління томами — виконуйте лише одне видалення, зміну розміру або міграцію одночасно.
• Зменшити навантаження на введення/виведення на уражені домени захисту під час міграції.
• Уникайте масових міграцій vTree; Групуйте їх невеликими групами.
• Не зупиняйте і не скасовуйте міграцію, коли мережа показує нестабільність.

Ці дії знижують ймовірність одночасного використання таймера і, відповідно, зменшують випадки паніки.

Впливові версії

PowerFlex Core 3.x.x.x

Виправлено у версії

PowerFlex Core 3.6.7.1