Назад | Перейти на главную страницу

Как исправить ошибку «Недопустимое движение диска» (HP SmartArray P411)

Из-за урагана Мэтью наша компания отключила все серверы на два дня. Одним из серверов был хост ESXi с подключенным HP StorageWorks MSA60.

Когда мы сегодня включили резервное копирование и вошли в клиент vSphere, мы заметили, что ни одна из наших гостевых виртуальных машин не доступна (все они указаны как «недоступные»). И когда я смотрю на состояние оборудования в vSphere, контроллер массива и все подключенные диски отображаются как «Нормальный», но все диски отображаются как «ненастроенный диск».

Мы перезагрузили сервер и попытались войти в утилиту конфигурации RAID, чтобы посмотреть, как все выглядит оттуда, но получили следующее сообщение:

Во время POST было сообщено о недопустимом движении привода. Изменения в конфигурации массива после недопустимого перемещения диска приведут к потере старой информации о конфигурации и содержимого исходных логических дисков.

Излишне говорить, что нас это очень смущает, потому что ничего не было «перемещено»; Ничего не изменилось. Мы просто включили MSA и сервер, и с тех пор эта проблема возникает.

MSA подключается с помощью одного кабеля SAS, а диски помечены наклейками, поэтому я знаю, что диски не перемещались и не переключались:

---------------------
| 01 | 04 | 07 | 10 |
---------------------
| 02 | 05 | 08 | 11 |
---------------------
| 03 | 06 | 09 | 12 |
---------------------

На данный момент я не знаю, какой марки и модели диски, но все они - диски SAS емкостью 1 ТБ.

У меня есть два основных вопроса / опасения:

  1. Поскольку мы не сделали ничего, кроме выключения и включения устройств, что могло вызвать это? У меня, конечно, есть возможность перестроить массив и начать заново, но я сомневаюсь в возможности того, что это произойдет снова (тем более, что я понятия не имею, чем это вызвано).

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

Да, это очень опасная ситуация ...

Таким образом, контроллер HP Smart Array может обрабатывать определенное количество движений физических дисков, прежде чем он нарушит конфигурацию массива. Помните, что метаданные HP RAID находятся на физических дисках, а не на контроллере ...

MSA60 - это корпус SAS JBOD первого поколения с 12 отсеками и 3,5-дюймовым корпусом. Срок его службы истек в 2008/2009 году. Он достаточно стар, чтобы не оказаться на критическом пути любой Развертывание vSphere сегодня.

В этом случае контроллер P411 пытается вас защитить. Возможно, вы столкнулись с отказом нескольких дисков, ошибкой прошивки, потерей одного из двух интерфейсов контроллера на задней панели MSA60 или какой-либо другой странной ошибкой.

Это похоже на более старую настройку сервера. Поэтому я хотел бы знать задействованный сервер и версию прошивки Smart Array P411.

Я бы посоветовал отключить питание всех компонентов. Подождите несколько минут. Включение ... и очень пристальное наблюдение за подсказками POST.

См. Подробности в моем ответе здесь:
логические диски на HP Smart Array P800 не распознаются после перезагрузки

Там может быть вариантом для повторного включения ранее отказавшего логического диска с возможностью нажать F1 или F2. Если есть, попробуйте F2.

Вы, ребята, не поверите ...

Сначала я попытался выполнить новую холодную загрузку существующего MSA, подождал пару минут, затем включил хост ESXi, но проблема осталась. Затем я выключил хост и MSA, переместил диски в запасной MSA, включил его, подождал пару минут, а затем включил хост ESXi; проблема все еще оставалась.

В тот момент я подумал, что я в значительной степени облажался, и во время инициализации RAID-контроллера у меня не было ничего, что могло бы повторно включить неисправный логический диск. Итак, я загрузился в конфигурацию RAID, снова проверил, что логических дисков нет, и создал новый логический диск (RAID 1 + 0 с двумя запасными дисками; так же, как мы это делали около 2 лет назад, когда мы впервые настраивали этот хост и место хранения).

Затем я позволил серверу загрузиться обратно в vSphere и получил доступ к нему через vCenter. Первое, что я сделал, - удалил хост из инвентаря, а затем снова добавил его (я надеялся таким образом очистить все недоступные гостевые виртуальные машины, но он не удалил их из инвентаря). Как только хост вернулся в мой инвентарь, я удалил каждую из гостевых виртуальных машин по одной. После очистки инвентаризации я убедился, что хранилище данных не существует и что диски в основном готовы и ждут как «диски с данными». Итак, я пошел дальше и создал новое хранилище данных (опять же, как и пару лет назад, используя VMFS). В конце концов мне было предложено указать параметр монтирования, и у меня была возможность «сохранить существующую подпись». На этом этапе я подумал, что стоит попробовать сохранить подпись - если что-то не сработает, я всегда могу сдуть ее и заново создать хранилище данных. После того, как я завершил процесс создания хранилища данных с опцией сохранить подпись, я попытался перейти к хранилищу данных, чтобы посмотреть, есть ли в нем что-нибудь - оно оказалось пустым. Просто из любопытства я подключился по SSH к хосту и проверил оттуда, и, к своему удивлению, я смог увидеть все свои старые данные и все мои старые гостевые виртуальные машины! Я вернулся в vCenter, повторно просканировал хранилище и обновил консоль, и все наши старые гостевые виртуальные машины были там! Я перерегистрировал каждую виртуальную машину и смог все восстановить! Все наши гостевые виртуальные машины имеют резервную копию и успешно обмениваются данными по сети.

Я думаю, что большинство людей в ИТ-сообществе согласятся, что шансы на то, что что-то подобное произойдет, крайне низки или невозможны.

Насколько я понимаю, это было чудо от Бога ...