Сегодня у нас история про блейд-сервер HPE ProLiant BL460c Gen8 (735151-B21), который мы получили в своё распоряжение в комплекте с нештатной работой контроллера управления HPE Integrated Lights-Out (iLO) 4. Первичная оценка состояния аппаратных компонент сервера показала, что сам по себе сервер вполне работоспособен, но наблюдаются проблемы в работе некоторых функций iLO. Например, на веб-странице входа в iLO, сразу бросился в глаза баннер с сообщением о выявленной проблеме самотестирования iLO: "iLO Self-Test reports a problem with: Embedded Flash/SD-CARD".
Если по рекомендации из баннера перейти в раздел "Diagnostics" веб-интерфейса iLO, то там попеременно мы можем видеть следующие сообщения об ошибках самотестирования Embedded Flash/SD-CARD:
Controller firmware revision 2.10.00 NAND read failure: Media is in a WRITE-PROTECTED state
Controller firmware revision 2.10.00 Embedded media initialization failed due to media write-verify test failure
Очевидно, что мы наблюдаем какое-то повреждение NAND памяти, которую микрокод iLO использует для записи и хранения данных. Эта проблема проявляет сопровождается такими дополнительными негативными эффектами, как, например:
- Не работает функция выгрузки аппаратного лога Active Health System (AHS) в веб-интерфейсе iLO;
- Не запускается встроенная утилита Smart Storage Administrator (SSA) для офлайн обслуживания контроллеров Smart Array (доступна по "F5" при загрузке сервера);
- Не запускается функционал Intelligent Provisioning (доступен по "F10" при загрузке сервера)
Если без последнего можно прожить, то первые два пункта могут оказаться крайне полезны в некоторых ситуациях.
Прежде всего нам нужно понять, является повреждение NAND логическим или же это более серьёзное физическое повреждение. Для этого мы сначала воспользуемся простыми методами, которые работают с NAND iLO на логическом уровне. Пробуем воспользоваться функцией форматирование флэша, которая доступна в разделе "Diagnostics" веб-интерфейса iLO по ссылке "iLO Health". Обратите внимание на то, что эта ссылка активна лишь только в том случае, если самотестирование iLO выявило проблему.
Здесь нам будет доступна одна большая кнопка форматирования флэша. После окончания процедуры форматирования контроллер iLO уйдёт в перезагрузку. В обсуждениях на сайте поддержки HPE Community встречается информация о том, что в некоторых ситуациях однократной процедуры форматирования может быть недостаточно для исправления проблемы и предлагают это делать 2-3 раза. Однако, в нашем случае это не помогло.
Следующим шагом мы решили попробовать метод сброса iLO, упоминаемый в ветке обсуждения "[ProLiant DL360e Gen8] NAND Error", который кому-то помог в данной ситуации:
I set the DIP Switch number 1 to ON, did the flash format, and reverted it to OFF. Fixed the issue.
Изучаем по нашему серверу документ "HP ProLiant BL460c Gen8 Server Blade Maintenance and Service Guide" и находим в нём описание сервисного DIP-переключателя System maintenance switch, который имеет 12 переключателей. Судя по описанию, интересующий нас первый переключатель S1, позволяет временно отключить встроенные функции безопасности iLO.
Выключаем и обесточиваем сервер, находим на материнской плате DIP SW1 и переводим первый переключатель в положение "ON".
После этого возвращаем сервер в блейд-корзину и подключаемся к веб-интерфейсу iLO, где мы сразу увидим дополнительный баннер об отключенных функциях безопасности ILO.
В таком состоянии снова пытаемся выполнить процедуру форматирования флэша, затем снова выключаем сервер и переводим первый переключатель обратно в положение "OFF".
В нашем случае процедура оказалась безрезультатной.
Возникло предположение, что функция форматирования через веб-интерфейс может работать как-то не так, как мы этого ожидаем, либо в памяти ILO есть другие какие-то логические проблемы. Для проверки этой гипотезы, решили попробовать альтернативный метод сброса/форматирования iLO с помощью консольной утилиты HPONCFG, как это описано в статье "HPE Integrated Lights-Out 4 (iLO 4) – How to Format the NAND Used to Store AHS logs, OneView Profiles, and Intelligent Provisioning". В нашем примере в 11-й слот блэйд-корзины отправляется фрагмент XML-разметки для XML API iLO на языке Remote Insight Board Command Language (RIBCL), который инициирует процедуру сброса iLO:
HPONCFG 11 << end_marker
<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN="adminname" PASSWORD="password">
<RIB_INFO MODE="write">
<FORCE_FORMAT VALUE="all"/>
</RIB_INFO>
</LOGIN>
</RIBCL>
end_marker
В выводе результата работы утилиты должна появиться информация об успешном выполнении команды форматирования:
Bay 11: Executing RIBCL request ...
Bay 11: Awaiting RIBCL results ...
Bay 11: RIBCL results retrieved.
...
<RIBCL VERSION="2.23">
<RESPONSE
STATUS="0x0000"
MESSAGE='Forcing a format of the partition after the iLO reset.'
/>
</RIBCL>
...
В результате выполнения команды iLO отправится в перезагрузку. После загрузки мы можем проверить лог ILO, чтобы убедиться в том, что форматирование действительно было выполнено:
8276 ... Embedded Flash/SD-CARD: One or more storage devices have been formatted.
78275 ... REST API Warning: REST API memory cleared (SCHEMA_PROV_ID master storage file set to default. Reboot system.).
Однако, не смотря на то, что после формата статус iLO в веб-интерфейсе снова "позеленел", буквально через несколько минут проблема снова вернулась.
На этом этапе доступные нам инструменты починки логических проблем iLO исчерпаны и приходим к выводу, что имеет место быть аппаратная неисправность NAND iLO.
Глядя на название неработающего теста iLO "Embedded Flash/SD-CARD" предполагаем, что в качестве альтернативы встроенному NAND флэшу возможно использовать Secure Digital (SD)-карту, которую можно установить в SD-слот, расположенный на оборотной стороне мини-платы с NAND чипом. Пробуем установить чистую SD-карту на 8GB и снова пытаемся провести форматирование в веб-интерфейсе iLO. Форматирование отрабатывает, но никаких ощутимых изменений это не даёт.
Обращаемся к одной серьёзной сервисной конторе (не будем показывать пальцем 
) за консультацией о том, что в такой ситуации можно сделать, описав проблему и все манипуляции, что успели уже попробовать. Получаем однозначный ответ о том, что в данном случае всю материнскую плату - под замену, так как модуль флэша не поставляется как отдельный FRU и формальным путём, как самостоятельная опция, заменён быть не может. При этом оценили услуги по замене почти в 100К рублей (45K за материнскую плату и 48K за командировку инженера в наше захолустье).
Пришло понимание того, что финансово не очень интересно вкладывать такую сумму в ремонт уже устаревшего оборудования и сервер становится претендентом на доживание на складе в качестве донора для других подобных серверов. Но внутренний скряга во мне не успокоился …
Ради спортивного интереса решил проконсультироваться с одним местным умельцем. Послал ему фото предположительно проблемного участка (уверенности в том, что это именно это тот флэш модуль, у меня на тот момент времени ещё не было) .
Специалист сказал, что по сути флэш копеечный и вместе со стоимостью своей работы "аккуратно сдуть феном старый/напаять новый" оценил в 2,5K рублей и сразу заказал аналогичный чип у китайцев.
Перепаяли чип. Поставили сервер обратно в блейд-корзину и вызвали форматирование NAND из веб-интерфейса iLO. После форматирования и перезагрузки iLO в веб-интерфейсе снова появилась ошибка, но уже другого вида - сообщалось о невозможности прочитать таблицу разделов. Запустили форматирование ещё раз здесь же, в веб-интерфейсе. После второго форматирования и перезагрузки iLO все ошибки пропали.
Проверили ранее неработающую функцию выгрузки аппаратного лога Active Health System в веб-интерфейсе iLO. Теперь она заработала. Это хороший признак и означает то, что перепаянный чип, как таковой, принят iLO и работает. Есть прогресс …
Однако, на данном этапе у нас всё ещё не работает встроенная утилита Smart Storage Administrator, как и не работает функционал Intelligent Provisioning. Вероятно, это связано с ранее потерянным служебным разделом на NAND с этими самыми утилитами.
Попытки записать новую версию HPE Intelligent Provisioning Recovery Media for Gen8 через загрузочный образ последней доступной версии 1.74 (22 Jul 2021) (загрузочный образ IP174.2021_0707.4.iso) оказались безуспешными. При каждой попытке загрузки процесс безмолвно прерывался. Новая загадка…
Учитывая предыдущий опыт коллег, когда им помогал откат на старые версии Intelligent Provisioning Recovery Media, попробовали использовать загрузочные образы версий пониже - 1.72 (9 Dec 2020), 1.71 (21 Feb 2019), 1.70 (9 Oct 2017)… Результат тот же – начало загрузки, чёрный экран вместо приглашения Intelligent Provisioning Recovery Media, перезагрузка сервера …
Полагая что, работа с логическими разделами на NAND iLO непосредственно связана с микрокодом iLО и может быть ре-инициализирована в ходе пере-прошивки iLO, попробовали принудительно пере-прошить микрокод последней актуальной версии iLO 4 - v2.82 (2 Mar 2023). Однако, на поведение загрузочных образов Intelligent Provisioning Recovery Media это никак не повлияло.
После ряда дополнительных попыток стало понятно, что у нас не срабатывает прошивка Intelligent Provisioning ни с одним из загрузочным образов Recovery Media. Пока перечитывал в интернете обсуждения о проблемах с загрузкой Intelligent Provisioning, заметил что в некоторых случаях помогает установка Intelligent Provisioning не с загрузочного образа, а непосредственно из хостовой ОС, например из соответствующего пакета под Linux. На этом фоне решил испытать подобный подход, но только с предустановленной ОС Windows.
Устанавливаем на сервер чистую ОС Windows Server 2016 64-Bit EN Datacenter и пытаемся запустить соответствующий пакет Intelligent Provisioning for Microsoft Windows 64-bit Operating Systems версии 1.64.0.0 (2 Mar 2017) (файл cp031302.exe), но сразу получаем ошибку в логе установщика (можно найти в каталоге C:\cpqsystem\log):
... ERROR : iLO 3/4 Channel Interface Driver for Windows Server is required to proceed.
Доустанавливаем в систему недостающее звено - необходимый драйвер iLO 4 Channel Interface Driver for Windows Server 2016 and Server 2019 последней актуальной версии 4.1.0.0 (9 Sep 2019) (файл cp039985.exe).
Ещё раз повторяем попытку установки Intelligent Provisioning и следим за логом установки…
... INFO : iLO Channel Interface Driver is found.
... INFO : Mounting the embedded media.
... INFO : Checking server generation.
... INFO : Mounting the embedded drives.
... INFO : Writing new gaius images to embedded media.
... INFO : Flashing gaius image to embedded drive.
... INFO : Successfully wrote gaius image.
... INFO : Writing new vid image to embedded media.
... INFO : flashing vid image to vid drive
... INFO : Successfully wrote vid image.
... INFO : Unmounting embedded media.
... INFO : Unmounting the embedded drives.
... INFO : Updating blob store
... INFO : Intelligent Provisioning flash complete.
Видим, что на этот раз прошивка Intelligent Provisioning сработала успешно.
Через пару минут в интерфейсе iLO появилась информация о текущей установленной версии Intelligent Provisioning (ранее она не отображалась) 1.64.
После этого штатным образом заработала загрузка разных ISO образов подмонтированных через iLO Virtual Media. В частности, нормально смог загрузиться образ последней версии IP174.2021_0707.4.iso, с загрузкой которого ранее были проблемы. Это позволило обновить Intelligent Provisioning до последней версии 1.74.
После финального обновления через Intelligent Provisioning Recovery Media штатно заработала возможность входа во встроенную утилиту Smart Storage Administrator в ходе загрузки сервера через кнопку "F5", а также заработала возможность входа в среду Intelligent Provisioning в ходе загрузки сервера через кнопку "F10".
Теперь можно констатировать факт того, что в конечном итоге функциональность iLO полностью восстановлена. Путь к финальному результату оказался долгий, но, как говорится, дорогу осилит идущий.
В завершении хочется отметить, что, в ходе поиска информации по проблеме с отказом NAND флэша iLO, нашёл интересную статью "HPE Integrated Lights-Out 4 (iLO 4) - HPE Active Health System (AHS) Logs and HPE OneView Profiles May Be Unavailable Causing iLO Self-Test Error 8192, Embedded Media Manager and Other Errors", которая косвенно подтверждает гуляющую в интернете гипотезу о том, что в ранних версиях микрокода iLO 4 (до версии 2.61) имели место быть ситуации с неоправданно интенсивной записью в NAND, которые могут приводить серверы HPE ProLiant Gen8 к выше описанным сложностям в работе iLO/SSA/Intelligent Provisioning и даже отказу NAND (либо переходу в режим "только чтение"), как это и произошло в нашем случае.
RSS - Записи
Добавить комментарий