PowerFlex. Чрезмерное переключение ролей данных приводит к задержке ввода-вывода и ошибкам

При определенных переходах между состояниями кластера логика балансировки ролей MDM может создавать быстрые, повторяющиеся переключения между основными и вторичными ролями во многих комбинированных компьютерах (внутренних структурах данных, которые отслеживают, какие узлы SDS хранят каждый фрагмент данных тома). Каждый переключатель роли делает недействительными гребенчатые карты на стороне клиента (SDC) и принудительно выполняет повторные операции ввода-вывода. Если одновременно затронуто достаточное количество гребней, кумулятивные издержки на повторные попытки вызывают скачки задержки ввода-вывода и ошибки ввода-вывода на хостах SDC. В зависимости от среды хоста это может привести к истечению времени ожидания операций ввода-вывода приложений, переходу виртуальных машин в состояние «доступно только для чтения» или к недоступности файловой системы.

Такое поведение наблюдалось при нескольких сценариях срабатывания и не ограничивается какой-либо одной операционной процедурой.

Общие индикаторы

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

Сценарий 1. Некорректная потеря SDS (без режима обслуживания)

Когда это может произойти:

• Это редкий сценарий. Чтобы во время потери SDS произошла быстрая, повторяющаяся переключение ролей, должны одновременно присутствовать несколько определенных условий:

• • Крупномасштабная среда — значительное количество узлов и томов SDS
  • Высокая нагрузка производственных операций ввода-вывода — значительная активность операций ввода-вывода в момент сбоя SDS
  • Рабочая нагрузка перестроения превышает вычислительную емкость — количество строк метаданных, требующих перестроения, превышает ограничение балансировщика MDM на один цикл в 1024 строки

Каждый цикл повторной балансировки может обрабатывать до 1024 строк метаданных. Когда необходимо перестроить больше строк, балансировщик не может завершить текущий план до создания следующего.

Что происходит:

• SDS резко отключается от MDM (событие SDS_DECOUPLED)
• Все SDC, которые были подключены к этому SDS, теряют свои подключения → событий отключения SDC
• MDM помечает кластер как DEGRADED (событие MDM_DATA_DEGRADED)
• Так как количество строк, подлежащих перестроению, превышает 1024, средство балансировки MDM не может завершить текущий план повторной балансировки
• Балансировщик запускает новый план, пока предыдущий план все еще выполняется, что приводит к быстрым повторяющимся событиям переключения ролей
• В клиентских SDC постоянно происходят сбои операций ввода-вывода (IO_FAULT_NOT_PRI, SCSI sense 0x4). После того как повторные попытки будут исчерпаны, ОС хоста сообщает об ошибках ввода-вывода, истечении времени ожидания или о файловой системе, доступной только для чтения
• Доказательство трассировки MDM:

Если рабочая нагрузка повторной балансировки превышает ограничение в 1024 строки, трассировка 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. Отключение питания программно-определяемого хранилища при входе PMM

Когда это может произойти:
Это редкий сценарий, для которого требуются два события одновременно:

• SDS переходит в режим защищенного обслуживания (PMM)
• Программно-определяемое хранилище выходит из строя или выключается до завершения перехода 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. Программно-определяемое хранилище в режиме мгновенного обслуживания (IMM)

Когда это может произойти:
Система SDS переходит в режим мгновенного обслуживания (IMM) или выходит из него. Этот сценарий возникает, когда один SDS находится в режиме обслуживания и система не может решить, какая SDS должна обрабатывать ввод-вывод для конкретных данных.

Что происходит:

• Система многократно изменяет SDS, отвечающий за обслуживание одних и тех же данных
• Эти постоянные изменения означают, что приложения не знают, куда отправлять свои запросы ввода-вывода
• Операции ввода-вывода отправляются на неверный 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

Большим количеством записей ролей переключения за короткий промежуток времени (тысячи и более в течение нескольких секунд) является окончательным индикатором этой проблемы со стороны SDS.

Журналы SDC/хостов: Повторные попытки ввода-вывода SDC VMware (ESXi), отображающие гребенку, целевую 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