PowerFlex: Надмірне перемикання ролей даних спричиняє затримку та помилки в IO

За певних переходів стану кластерів логіка балансування ролей MDM може створювати швидкі, повторювані перемикання первинних/вторинних ролей через багато комбінів (внутрішніх структур даних, які відстежують, які вузли SDS зберігають кожен шматок даних об'єму). Кожен перемикач ролі анулює клієнтські (SDC) гребінчасті карти та змушує повторювати ввод/вивод. Коли одночасно впливає достатньо гребінців, накопичення повторних спроб спричиняє стрибки затримки вводу/виводу та помилки вводу/виводу на SDC-хостах. Залежно від середовища хоста, це може призвести до тайм-аутів вводу/виводу додатків, переходу віртуальних машин у стан лише для читання або недоступності файлової системи.

Ця поведінка спостерігалася при кількох сценаріях тригерів і не обмежується жодною операційною процедурою.

Поширені індикатори

• MDM_DATA_DEGRADED подія, за якою слідує тривала затримка введення/виведення тривалістю 1-15+ хвилин
• SDC-хости повідомляють про помилки введення/виведення та/тайм-аут під час деградованого вікна
  • VMware (ESXi): Тайм-аути серцебиття VMFS, апаратні помилки SCSI (sense data: 0x4 0x0 0x0), що переходять у стан лише для читання, потенційне аварійне перемикання HA
  • Linux: Помилки введення/виведення в системних журналах (/var/log/messages, dmesg), застосунки можуть стикатися з тайм-аутами вводу/виводу або перемонтуванням файлової системи лише для читання
• Журнали подій MDM показують, що система перебуває у стані DECGRADED довше, ніж очікувалося, при одній втраті SDS
• Система зрештою самовідновлюється до НОРМАЛЬНОГО стану без ручного втручання (зазвичай).

Сценарій 1: Незручна втрата SDS (без режиму обслуговування)

Коли це можливо:

• Це рідкісний випадок. Для швидкої, повторюваної зміни ролей під час незграбної втрати SDS необхідно одночасно існувати кілька специфічних умов:

• • Великомасштабне середовище — значна кількість вузлів SDS та томів
  • Велике навантаження на виробничі введення/виведення — значна активність введення/виведення в момент відмови SDS
  • Навантаження на перебудову перевищує обчислювальну потужність — кількість рядків метаданих, що потребують перебудови, перевищує ліміт балансування MDM у 1 024 рядки на цикл

Кожен цикл ребалансування може обробляти до 1 024 рядків метаданих. Коли потрібно перебудувати нові ряди, балансувальник не може завершити поточний план до генерації наступного.

Що відбувається:

• SDS раптово відокремлюється від MDM (подія SDS_DECOUPLED)
• Усі SDC, які були підключені до цього SDS, втрачають свої з'єднання → події відключення SDC
• MDM позначає кластер як ДЕГРАДОВАНИЙ (подія MDM_DATA_DEGRADED)
• Оскільки кількість рядків для перебудови перевищує 1 024, MDM балансувальник не може завершити поточний план ребалансування
• Балансувальник запускає новий план, поки попередній план ще працює, що призводить до швидких, повторюваних подій зміни ролей
• Клієнтські SDC бачать безперервні збої введення/виведення (IO_FAULT_NOT_PRI, SCSI sense 0x4). Після вичерпання повторних спроб ОС хоста повідомляє про помилки введення/виведення, тайм-аути або файлову систему лише для читання
• Докази слідів MDM:

Коли навантаження на ребалансування перевищує ліміт у 1 024 рядки, траса MDM показує поріг, який перетинено:

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.

Це свідчить про те, що 1 098 рядків потребували перебудови, але лише 1 024 могли бути оброблені в поточному циклі. Залишкові ряди запускають новий план перебалансування до завершення попереднього плану, запускаючи цикл зворотного зв'язку.

Ланцюг подій:

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: Вимкнення SDS під час входу в PMM

Коли це можливо:
Це рідкісний сценарій, який вимагає двох одночасних подій:

• SDS переходить у режим захищеного обслуговування (PMM)
• SDS виходить з ладу або вимикається до завершення переходу на PMM

Що відбувається: 

• MDM отримує команду введення PMM і фіксує її як виконану
• SDS несподівано від'єднується, поки запис PMM ще триває
• MDM позначає кластер як ДЕГРАДОВАНИЙ
• Балансувальник ролей входить у тривалий цикл перемикання ролей протягом усієї фази входу в PMM
• Рядки даних, які не є PMM, багаторазово переключаються між ролями по всьому пулу зберігання
• Буря триває, доки SDS не приєднається до кластера і не завершить перехід у режим обслуговування

Ланцюг подій:

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

Приклад послідовності подій 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

Коли SDS знову з'єднується і PMM завершується:

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

Сценарій 3: SDS у режимі миттєвого обслуговування (IMM)

Коли це можливо:
SDS входить або виходить з режиму миттєвого обслуговування (IMM). Цей сценарій виникає, коли один SDS перебуває в режимі обслуговування, і система не може вирішити, який SDS має обробляти ввод/вивід для конкретних даних.

Що відбувається:

• Система неодноразово змінює, який SDS відповідає за обробку тих самих даних
• Ці постійні зміни означають, що додатки не знають, куди надсилати свої запити на введення/вивід
• I/O передається не в той SDS, що призводить до повторних спроб і затримок
• Додатки стикаються з затримкою або тайм-аутами під час спроби отримати доступ до постраждалих даних

Вплив:

• Вплив на клієнта: Додатки повідомляють про затримку та тайм-аути, поки SDS знаходиться в IMM
• Тривалість: Продовжується, поки SDS перебуває в стані IMM
• Відновлення: Автоматично — розв'язується, коли SDS виходить з IMM

Ланцюг подій:

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

Сценарій 4: Вихід SDS із захищеного режиму обслуговування (PMM)

Коли це можливо:
SDS виходить із режиму захищеного обслуговування (PMM). Цей сценарій трапляється під час кожного виходу з PMM — це не рідкісна подія, але її серйозність залежить від тривалості роботи режиму технічного обслуговування.

Що відбувається:

• Коли SDS виходить з PMM, балансувальник ролі повинен перепризначати сегменти даних, щоб включити повернений SDS
• Процес ребалансування впливає на весь пул зберігання, а не лише дані на поверненому SDS
• Зміни ролей відбуваються на багатьох сегментах даних під час реінтеграції
• Заявки можуть стикатися з короткими помилками введення/виведення або затримкою у міру стабілізації ролей

Вплив:

• Вплив на клієнта: Під час коротких періодів обслуговування (менше 5 секунд) удар майже непомітний. При тривалому обслуговуванні з активним введенням/виведенням можуть відбуватися тисячі змін ролей, що призводить до тривалих зупинок вводу/виводу
• Тривалість: Триває під час фази реінтеграції до завершення ребалансування
• Відновлення: Автоматична

Ланцюг подій:

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

Приклад послідовності подій MDM:

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

Результати журналу:
 

Журнали подій MDM: Журнал подій MDM показує послідовність на рівні кластера. Ключовими індикаторами є операції перемикання ролей під час виходу з режиму технічного обслуговування.

Журнали трасування SDS: На вузлах SDS журнали трасування показують повторювані операції перемикання ролей під час реінтеграції:

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

Велика кількість записів ролей Switch за короткий часовий проміжок (тисячі або більше за секунди) є остаточним показником цієї проблеми на стороні SDS.

Журнали SDC/хостів: VMware (ESXi) SDC вводу/виводу повторює спроби, показуючи гребінець, цільовий SDS та код помилки:

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)

Якщо повторні спроби вичерпані, повертаються помилки SCSI: 

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

Поради щодо діагностики: Якщо ви бачите помилки введення/виведення на кількох SDS-вузлах (не лише на тому вузлі, що мав проблему), це може свідчити про бурю перемикання ролі, а не про звичайну поведінку деградованого стану. Якщо помилки введення/виведення ізольовані лише одним SDS, це очікувана поведінка деградованого стану.

Сценарій 5: Фазові переходи режимів обслуговування 

Коли це можливо:
Під час переходу, коли SDS переходить або виходить з режиму обслуговування (IMM або PMM) — у момент зміни стану змінюється з нормального на MM або з MM назад у нормальний

.Що відбувається:

• Балансувальник ролей перерозподіляє обов'язки за дані відповідно до змін
• Короткі спалахи перемикання ролей відбуваються, коли система звикає до нової структури
• Застосування можуть зазнавати коротких стрибків затримки під час переходу

Вплив:

• Вплив на клієнта: Короткі стрибки затримки, що тривають від кількох до кількох хвилин. Зазвичай нижче порогів тайм-ауту для подачі заявки
• Тривалість: Триває від секунд до кількох хвилин, потім заспокоюється
• Відновлення: Автоматична

Ланцюг подій:

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

Дефект програмного забезпечення в логіці балансу ролей MDM викликає цикл зворотного зв'язку, коли кластер переходить у стан через роботу

в режимі втрати SDS або режиму обслуговування.За певних умов MDM неодноразово перепризначає, які SDS-вузли відповідають за обслуговування вводу/виводу на уражені комби. Кожне перепризначення анулює кешований вигляд SDC про місцезнаходження даних, що змушує повторювати ввод/вивод. Коли одночасно впливає багато комбів, обсяг перепризначень перевищує здатність SDC оновлюватися, що призводить до тривалих помилок введення/виведення між кількома хостами.

Буря зазвичай самообмежується. Він розв'язується після стабілізації кластера, але тривалість залежить від розміру домену захисту та навантаження на введення/виведення на момент події.

Ця проблема вирішена у версії PowerFlex Core 4.5.6. Оновіть до цієї версії, коли вона буде доступна. Зверніться до служби підтримки Dell для отримання інформації про терміни релізу.

Для планових операцій з технічного обслуговування:

• Не перемикайте і не перезавантажуйте SDS, доки не з'явиться журнал MDM SDS_MAINTENANCE_MODE_STARTED. Переконайтеся, що SDS повністю перейшла в режим обслуговування, перш ніж приступати до фізичного обслуговування.
• Слідкуйте за стрибками затримки при вході або виході з режиму обслуговування.

Для незапланованих відключень SDS:

• Буря є самообмеженою і зазвичай минає за кілька хвилин, коли скупчення стабілізується. Якщо проблема спостерігається, збирайте getinfo журнали з усіх SDS-вузлів у домені захисту, від усіх менеджерських MDM якомога швидше після події, і зв'яжіться зі службою підтримки Dell.

У рідкісних випадках, коли проблема не вирішується самостійно, тимчасове вимкнення та повторне увімкнення перебудови може дозволити MDM стабілізуватися:

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

# Зачекайте 5-10 секунд, потім увімкніть Rebuild: 

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