Привет! Я руковожу группой технической поддержки и сопровождения в компании «Онланта». Наша команда заметила, что в процессе эксплуатации All-Flash систем хранения данных OceanStor Dorado 5000 V6 примерно после двух и более лет в работе начинают проявляться дефекты, которые потенциально могут повлиять на доступность данных и работу СХД в целом. 

Одна из таких проблем – встроенные M2 SATA SSD накопители. Они используются и как системные, храня на себе ОС контроллера, и как конфигурационные базы данных, и как Coffer — диски, куда сбрасывается Write‑cache при аварийном отключении системы, пока BBU (модуль резервного питания) обеспечивает работу оборудования.

В этой статье — рассказ о том, как мы анализировали, решали и предотвращали подобные неприятности.

Первые проблемы и анализ

Впервые мы начали сталкиваться с такой коллизией в системах, представляющих собой Scale-out конфигурацию из двух Dorado 5000 V6, объединенных в один кластер. При сроке работы более двух лет проявлялась проблема: один из контроллеров перезагрузился, затем вернулся в работу. В логах это выглядело следующим образом.

Event log. Сообщение о том, что контроллер CTE0. A перезагрузился для восстановления внутреннего сбоя:

2023-03-30 20:01:33    0xF00CF007D    Fault    Warning    Recovered    2023-03-30 20:18:02    Controller (controller enclosure CTE0, controller A) is being repaired due to an internal error. Error code: --.

Wait about 30 minutes until the fault is rectified.

Config log. В логе зафиксирован Software reset ноды 0 (CTE0.A):

После перезагрузки контроллер в статусе Normal:

При более углубленном анализе было выявлено, что перезагрузка была вызвана модулем FDSA. Он отвечает за обнаружение и устранение неисправностей (Fault Diagnose & Self-healing Architecture):

*Примечание: на представленном скриншоте кусок лога с другого массива с подобной проблемой на контроллере 1А, т.е. с нодой 2.

Алгоритм проверки состояния системных дисков примерно следующий. FDSA периодически пытается создать и прочитать файлы в разделах этого диска. Если этого сделать не удается, модуль предпринимает попытку восстановления:

Чуть выше в файле лога мы можем увидеть, с чего всё началось. Во время процесса чтения-записи драйвер не может завершить операции и делает Remount файловой системы в Read-only режим:

После возникновения и самоустранения проблемы, данный кейс был поставлен на мониторинг, и в течение десяти дней проблема не повторялась. Но это было только начало массовых неприятностей.

Так как все системы поставлялись с очень старой версией ПО, в которой имелись существенные недоработки, которые ускоряют их амортизацию (в т.ч. касательно системных дисков), на значительной части СХД диски износились.  На них стали появляться плохие блоки, которые, как покажут дальнейшие анализы, и будут  корневой причиной перезагрузок, а порой и полного отключения контроллеров.

Далее подобных кейсов становилось всё больше и больше, и все приходили с разной симптоматикой. Контроллер перешел в статус Faulty:

2024-06-13 04:15:04    0xF000A028F    Fault    Major    Unrecovered    None    The system disk of controller (controller enclosure CTE0, controller B, controller BOM 03059103, controller SN 210305910310M3******) is faulty. Error code: 0x4000cf4d.

Collect related information and contact technical support engineers to replace the controller.

Причина – всё тот же системный диск, и это уже явно указано в Event-логе. Описание Error-кода следующее:

Решение, указанное в описании, — замена контроллера целиком. При единичных сбоях мы так и поступали, пока зип-контроллеры были в наличии. Но когда кейсов уже стало несколько десятков, пришлось искать другое решение. И оно оказалось на поверхности – замена только системного диска.

Поначалу все проходило гладко. Запускалась процедура замены сбойного контроллера, в нем менялся только системный диск и возвращался в шасси. К слову, использовался новый пустой системный диск Enterprise-класса от Intel, ибо найти такие же диски, какие стояли в контроллерах с завода, не удалось. Вероятно, они производились по заказу изготовителя. Во время загрузки контроллер автоматически подключался по PXE к своему соседу, делал необходимую разметку диска, копировал все необходимое ПО и успешно загружался.

Это решение хорошо работало, пока мы не столкнулись с ситуацией, когда на обоих контроллерах были плохие SSD и во время замены диска в контроллере 0В сломался диск в рабочем контроллере 0А.

Данные Error-коды также говорят о неисправностях системного диска, что в этом случае делает невозможным копирование системы на новый диск.

Вместе с этим возникли сопутствующие проблемы. В системе включился Write-protection всех LUN — это нормальная ситуация, когда в одном шасси присутствуют два сбойных компонента (контроллеры, BBU). Таким образом защищаются данные на запись от потери. Решение было принято следующее.

1. Для возобновления доступа к данным переключение Write back → Write through на время работ.

2. Т. к. система у нас была четырехконтроллерная, надежда была на то, что в шасси CTE1 системные диски целые и с помощью них мы сможем восстановить работоспособность системы. Так и вышло. Мы извлекли контроллер CTE1.B для того, чтобы использовать его слот для «заливки» ПО на новые системные диски с последующим использованием этих контроллеров в полке CTE0.

Примечание. Хоть контроллерные полки и соединены между собой RDMA линками крест-накрест, копирование ПО с соседней полки по этим линкам, к сожалению, не предусмотрено. Подключение по PXE происходит только по внутриполочному соединению через бэкплейн в шасси.

3. После восстановления работоспособности всех четырех контроллеров, было выполнено обратное переключение Write through -> Write back.

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

Решение опять же оказалось на поверхности – в нашей лаборатории после многочисленных испытаний мы проработали план подготовки системных дисков таким образом, чтобы на них уже присутствовало все необходимое ПО для работы (релиз SPC + хотпатч SPH). Контроллеру остается только загрузиться, подключиться к работающей системе и зайти в кластер. Никаких дополнительных операций не требуется.

Такой подход нас очень выручил в еще одном интересном кейсе: в один момент на такой же четырехконтроллерной системе Dorado 5000 V6 одновременно сломались системные диски в обоих контроллерах.

Event log:

Также видно, что вместе с этим на всех LUN включился write-protection. Благодаря тому, что инженер был на площадке и проводил работы в соседней стойке, удалось оперативно выполнить ремонт и вернуть систему в нормальное состояние.

Углубленный анализ и превентивные замены

Были проанализированы практически все системные диски, которые вышли из строя, и стало ясно — диски порядком изношены, что и привело к неисправностям.

При анализе SMART-параметров дисков оценивались следующие критерии (пример для модели ME619GXEHDE3TE):

5        -    Reallocated Sector Count
160    -    Uncorrectable Sector Count
181    -    Program Fail Count
182    -    Erase Fail Count
198    -    Offline Uncorrectable Sector
241    -    Total LBAs Written

При анализе в модуле inspection применялись следующие расчеты для определения исправности диска:

(5) > 1 or (160) + (198) > 1
(241) * 32 / 1024 / 240 >= 400 and ((181) > 0 or (182) > 0)
(241) * 32 / 1024 / 240 >= 800

Если диск подпадает под одно из условий, он помечается как Risky, и Smartkit рекомендует обращаться в техподдержку для анализа R&D.

Также в процессе анализа была выявлена закономерность. Значение Total Written в Scale-Out системах в 3–4 раза превышает значение TW в системах без Scale-Out при примерно одинаковом Uptime (5-й столбец, количество лет в работе).

После сбора информации со всех систем, был разработан план-график по замене всех ненадежных дисков.

Предварительно нужно выполнить подготовку системных дисков с необходимым Release и Patch, установленных на затронутой СХД.

План работ включает в себя:

• оповещение администраторов СХД о предстоящих работах и получение разрешения на проведение работ;

• снятие бэкапа конфигурации и снятие бэкапа лицензии; 

• добавление оборудования в SmartKit (добавлять IP исправного контроллера);

• выполнение процедуры Parts Replacement контроллера CTEX.X. (в примере ниже неисправных компонентов нет, снята галочка с пункта Show faulty parts only, поэтому отображаются все контроллеры);

• извлечение контроллера CTEX.X; 

• замена системного диска; 

• установка контроллера (в Smartkit нажать кнопку Replaced);

• проверка восстановления путей (бывали случаи, когда после восстановления контроллера некоторые хосты не восстанавливали пути до него и приходилось делать Rescan);

• снятие сервисных логов (allEvent + operationData/runningData); 

• оповещение дежурной смены об окончании работ.

Заключение

Проведенный анализ проблем, связанных с отказом системных дисков в СХД, наглядно демонстрирует, что даже незначительный на первый взгляд компонент может стать точкой отказа всей сложной инфраструктуры. Ключевой вывод, который мы можем сделать, заключается в том, что проактивность и комплексный подход являются основой надежности.

Важно не просто реагировать на сбои, а выстраивать систему мониторинга, предсказывающую деградацию дисков по SMART-параметрам.

 Наш опыт показал, что тщательный анализ логов, понимание архитектуры своей системы хранения и наличие хорошо протестированного плана действий на случай аварии экономят не только время, но и значительные ресурсы. 

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

А с какими проблемами, связанными с отказом компонентов в СХД, сталкивались вы? Поделитесь вашим опытом и лучшими практиками в комментариях — это поможет всем нам создать более надежную ИТ-экосистему.