PowerFlex 3.x: перенос vTree может привести к критической ошибке или зависанию SDS

В PowerFlex версии 3.6.7 во время запланированного переноса vTree происходит сбой нескольких SDS, что приводит к переходу системы в состояние недоступности данных.

В результате задержек переноса потребление емкости пула хранения данных (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 при выполнении заданий хранилища отображается бесконечная загрузка:

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, перенос томов никогда не заканчивается, коэффициент использования емкости процессора СХД критический или выше, в приложениях могут возникать ошибки ввода-вывода.

В версии 3.6.7 недоступность данных.

Эта проблема вызвана состоянием многопоточной гонки, включающим механизм совместно используемого таймера в компоненте очистки Volume Allocation Element (VAE) во время операций переноса томов.

В PowerFlex версий до 3.6.7 для удаления данных из старых местоположений процессоров СХД после переноса использовался асинхронный процесс очистки. В редких условиях, таких как параллельные операции управления томами, одновременное удаление томов, высокая нагрузка ввода-вывода или нестабильность сети, этот процесс мог столкнуться с состоянием гонки, которое приводило к зависанию операций переноса на неопределенный срок.

Для решения этой проблемы в версии 3.6.7 был введен расширенный механизм мониторинга. Этот защитный механизм включал таймер, предназначенный для обнаружения застрявшего потока очистки VAE и упреждающего вызова паники в сервисе SDS, чтобы предотвратить повреждение данных или длительные зависания, аналогично тому, как система обрабатывает зависшие команды ввода-вывода или MDM.

Однако при первоначальной реализации этого исправления таймер мониторинга инициализировался только один раз во время создания данных миграции и совместно использовался для всех последующих вызовов очистки VAE. Когда несколько фоновых потоков одновременно пытаются получить доступ к этому единственному общему таймеру во время интенсивных рабочих нагрузок миграции, активируется новое состояние гонки. Такой одновременный доступ приводит к тому, что механизм отслеживания неправильно помечает очиститель VAE как зависший, что приводит к непреднамеренным сбоям сервиса SDS и локальному нарушению доступности данных, что приводит к недоступности данных.

Окончательное исправление (рекомендуется)

Модернизируйте кластер до PowerFlex 3.6.7.1 или более поздней версии. Исправление состояний гонки VAE-очистителя и таймера.

Временное решение (если модернизация не может быть выполнена немедленно)

В версиях до 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 (например, 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 Идентификатор остается неизменным с течением времени, скорее всего, он соответствует задействованному узлу SDS. Повторно выполните шаг 3, чтобы убедиться, что он остается согласованным.

5. Выполните следующую команду, чтобы вывести список всех узлов SDS и сопоставить TGT Идентификатор с именем/IP-адресом SDS:

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