Для систем хранения данных HPE 3PAR, находящихся на действующем контракте сервисного обслуживания обычно замена вышедших из строя комплектующих не представляет каких-либо сложностей и сопровождается пошаговыми инструкциями специалистов тех.поддержки HPE. Однако, если на руках оказывается СХД без такого контракта, то все задачи по обслуживанию превращаются в интереснейший квест. В этой и нескольких последующих заметках я попробую описать несколько приёмов по решению таких задач своими силами.
Начнём с описания исходных данных, от которых в нашем примере мы будем отталкиваться. Итак, имеется "не первой свежести" двух-контроллерная СХД HP 3PAR StoreServ 7200 2-Node Storage (QR482A), которая ранее эксплуатировалась и вроде-как даже была живой, но до меня доехала в не очень хорошем состоянии. Первичный осмотр СХД показал наличие нескольких неприятных моментов:
1) Одна из нод (Node, контроллер СХД) не запускается, выдавая цвето-музыку всеми индикаторами коммуникационной панели. Фактически СХД стартует, но стартует только на одной ноде. При этом запустившаяся нода в упор не видит вторую ноду. Консольный порт проблемной ноды не отвечает. Требуется замена неисправной ноды.
2) Не самая актуальная версия прошивки нод 3PAR OS с учётом того, что сервер управления Virtual Service Processor (VSP), с которого можно провести обновление, для данной СХД недоступен (то есть отсутствует). Необходимо развернуть старую версию VSP и поэтапно поднять уровень версий 3PAR OS/VSP.
3) В инструментах управления СХД, например в консоли HP 3PAR Management Console, видно, что у СХД есть два проблемных 1GB-чанклета в состоянии "Failed". Возможно потребуется замена дисковых накопителей.
4) Для возможности дальнейшего использования СХД (с учётом исправления пунктов 1-3) потребуется выполнить процедуру сброса настроек "Out Of The Box" (OOTB). Однако, отсутствует пароль сервисной учётной записи пользователя "console", который необходим для выполнения процедуры OOTB, доступной через прямое подключение на консольном порту ноды.
Попробуем последовательно решить все описанные проблемы.
Если говорить о замене ноды, то в целом процедура описана с наглядными картинками в онлайн-документе: HPE 3PAR StoreServ 7000 Storage - Removing and Replacing the Node. Однако она предполагает то, что неисправная нода меняется на новую, полученную от тех.поддержки HPE и уже подготовленную к правильному "взлёту". У меня же на руках есть запчасть в виде исправной ноды, которая ранее работала в другой СХД и мне потребуется пару дополнительных телодвижений, чтобы заменить неисправную ноду. Последовательность действий при этом будет такой:
1) При запущенной СХД "на горячую" вынимаем неисправную ноду. Снимаем у неисправной ноды крышку корпуса, отключаем от SATA-коннектора встроенный SSD-накопитель (в моём случае это SanDisk X110 64GB) и извлекаем этот накопитель.
Кроме этого, можно извлечь из неисправной ноды SFP-модули.
2) Открываем крышку корпуса у ноды, которую мы планируем установить взамен неисправной и устанавливаем в неё внутренний SSD-накопитель, который мы сняли в п.1. Дополнительно устанавливаем в ноду SFP-модули, которые мы сняли в п.1.
3) Вставляем "на горячую" сменную ноду в СХД и ждём пока система синхронизирует между собой ноды, заджойнит их в кластер и полностью введёт сменную ноду в работу.
За текущими процессами, происходящими на вновь подключенной ноде в ходе её загрузки, мы сможем наблюдать, подключившись к консольному порту ("Mfg") ноды с помощью специального переходника, как это было описано ранее.
По окончании загрузки заменённой ноды, подключимся к СХД по протоколу SSH от имени учётной записи "3paradm", просмотрим перечень активных задач и убедимся в том, что теперь обе ноды доступны и включены в работу в кластере:
3PAR02 cli% showtask -active
3PAR02 cli% shownode
Дополнительно можно выполнить команду выполнения проверки текущего состояния компонент СХД:
3PAR02 cli% checkhealth -svc -detail
В нашем случае в ходе выполнения последней команды было обнаружено сообщение:
...
Cage Cages not on current firmware
...
При этом и в консоли управления HP 3PAR Management Console стало видно, что корзине СХД после замены ноды "поплохело":
Такая ситуация сложилась из-за того, что сменная нода оказалась с набором микрокода, отличным от того, что имелся на второй рабочей ноде. Попробуем это исправить.
Вернёмся в SSH-сессию на СХД и запросим информацию о текущих версиях микрокода дисковых корзин:
3PAR02 cli% showcage
Id Name LoopA Pos.A LoopB Pos.B Drives Temp RevA RevB Model FormFactor
0 cage0 1:0:1 0 0:0:1 0 18 21-24 321c DCN1 SFF
1 cage1 1:0:2 0 0:0:2 0 18 21-24 4078 4078 DCS2 SFF
Как видим, версии cage0 и cage1 в нашем случае, действительно отличаются. Чтобы запросить более детальную версию о корзинах, можно выполнить команду:
3PAR02 cli% showcage -d
Чтобы подтянуть версию микрокода корзины cage0 выполняем команду:
3PAR02 cli% upgradecage cage0
Upgrading cage cage0 cpuA from rev 321c to revision in file /opt/tpd/fw/cage/ebod/hp_eos_canister_local_combined_v4078.gff.
Upgrading cage cage0 cpuB from rev to revision in file /opt/tpd/fw/cage/ebod/hp_eos_canister_local_combined_v4078.gff.
Beginning test after upgrade for cage0
cage0 passed test after upgrade
После окончания процесса снова проверяем версии:
3PAR02 cli% showcage
Id Name LoopA Pos.A LoopB Pos.B Drives Temp RevA RevB Model FormFactor
0 cage0 1:0:1 0 0:0:1 0 18 21-24 4078 4078 DCN1 SFF
1 cage1 1:0:2 0 0:0:2 0 18 21-24 4078 4078 DCS2 SFF
Как видим, версии микрокода сравнялись.
После этого можем заглянуть в графическую консоль управления и убедиться в том, что там тоже всё "заколосилось".
На этом первую задачу с заменой неисправной ноды HPE 3PAR 7200 в нашем случае можно считать решённой.
Обратная ссылка: HPE 3PAR 7200. Избавляемся от чанклетов в состоянии "Failed" /
Обратная ссылка: HPE 3PAR 7200. Получаем доступ к 3PAR Console Menu для OOTB /