Падучая ESXi или возвращение блудного хоста

И снова статья от участника телеграм-канала VMware User Group Rus.

Третьего дня в чат опять пришли коллеги с стандартной проблемой – хост отвалился от vCenter  – ШТО ДЕЛАТЬ?

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

Вводные

Есть некий хост с VMware (разумеется, с последними патчами – а то было тут как-то PR 2412475: You see Sensor -1 type hardware health alarms on ESXi hosts and receive excessive mail alerts). Хост отвалился от VCenter (разумеется, тоже с последними патчами – особенно это касается линейки 7.0). Виртуальные машины на хосте продолжают работать, отказоустойчивости на уровне сервисов (Oracle real application clusters, database availability group, MS SQL Always On и так далее) нет, но и просто так перезагрузить хост – не вариант. Нет никаких гарантий, что хост поднимется, что есть ресурсы на других хостах.

В данном случае имеет смысл обратиться в поддержку – если, конечно, у вас система работает на поддерживаемой конфигурации, куплены лицензии и куплена эта самая поддержка. Поддержку можно купить «поштучно» – VMware Per Incident Support.

Шаг 1. Что было, то и будет; и что делалось, то и будет делаться, и нет ничего нового под солнцем

Многое про такие ситуации уже написано до нас – например, в статье Перезапуск Management agents в ESXi и терпение от Grigory Pryalukhin – и надо просто прочитать, переписать к себе в план восстановления после сбоя (Disaster recovery plan / DRP) и быть готовым к такой ситуации.

Теоретически две команды, упомянутые в статье, работают

Практически – к командам можно дописать

Из kb Verifying if management services are running on an ESXi host (2030663) и Restarting the Management agents in ESXi (1003490) . Но как «работают» – может через полчаса, а может и через три часа. А может и не работают совсем, но с гарантией у вас будет: очень, очень тормозящий и DCUI, и ssh, и даже с рабочими hostd и vpxa – нет никаких гарантий возврата хоста.

Если рестарт сервисов вам помог – вы молодцы, если нет – читаем дальше. Будем считать, что какой-то доступ к консоли у вас есть, но вызывающий страдания. Например, страдания может вызвать дописывание по TAB, причем не просто страдания – а повисание сессии. При этом ls работает.

Шаг 2. Пороемся в первоисточниках, обратимся к Марксу

На второй стадии надо бы выяснить источник проблемы в том же vpxa.log, но, зачастую источник очевиден – указанные сервисы отлично умирают при проблемах с SSD / USB – раньше такого было как-то поменьше(статистики нет). На это месте идем читать статью vSphere 7 Update 2 loses connection with SD Cards a Workaround. Все симптомы те же, и понятно как найти источник беды – пропала SD карта.

Можно (если у вас в итоге первой части завелся хотя бы SSH, или есть доступ к консоли через IPMI и DCUI, или сервер стоит рядом и можно подключить монитор и клавиатуру) попробовать повызывать , согласно статье,

и поделать прочие упражнения – вдруг поможет. Может не помочь, USB и SD иногда умирают насовсем. Хуже всего, когда умирают путем падение в Read only – диск как бы есть, а ни логи записать, ни патч поставить.

Если лечении из статьи помогло – то мигрируем виртуалки с хоста и готовимся к замене SD / USB по вашей процедуре – с бекапом и восстановлением, с переустановкой и накатыванием конфигурации, с профилями  или как там у вас сделано.

Если не помогло, то переходим к шагу 3 – аварийное покидание хоста.

Шаг 3. Аварийное покидание хоста

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

Остается два пути – или перезагрузить хост твердо и жестко, или выключить на нем виртуальные машины по одной, и зарегистрировать их на другом хосте. С первым случаем проблем нет – хотя всегда может не повезти и VM просто не поднимутся по HA. Или поднимутся – но не поднимется база или какой-то сервис, так что лучше все же выключить виртуальные машины штатно.

Блокировка и возможность перерегистрации виртуальных машин описана в статье Investigating virtual machine file locks on ESXi hosts (10051), но вы можете столкнуться с тем, что виртуальную машину вы выключили, 5-10 минут прошло – а она не желает включаться на другом хосте, никак. В таком случае необходимо учесть следующее – тормозами по полчаса, а то и полтора часа, страдают все сервисы, то есть виртуальная машина с ее точки зрения уже выключена, а с точки зрения хоста еще в работе. Для проверки такого состояния есть 1.5 пути.

Первый путь – запуск esxtop, про который стоит почитать у Duncan Epping тут. Если у вас world / процесс от виртуальной машины числится как рабочий – просто ждите. Через полчаса, а может через два часа – ее отпустит и она станет «выключенной». Половина пути – можете от скуки открыть лог-файл самой виртуальной машины и почитать, что там будет интересного (только не забудьте вспомнить, как выходить из vi, кроме как перезагрузкой хоста, да и помните про проблемы при дописывании по TAB):

Когда выключится – просто зарегистрируйте VM на другом хосте, запустите и не забудьте выбрать I MOVED IT при ответе на вопрос при запуске на 66%.

Конечно, если терпения нет, то можете и изучит команду kill, но в этом тексте ничего про это не будет.

Когда все переедет – можете перезагружать хост, но

Шаг 4. Возвращение блудного хоста

Выключите DRS на кластере перед ребутом – потому что хост поднимется как не загруженный, и DRS сразу туда все потащит. Команда эта тоже может не помочь:

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

Collecting diagnostic information for ESX/ESXi hosts and vCenter Server using the vSphere Web Client (2032892), Collecting diagnostic information for VMware ESXi (653), “vm-support” command in ESX/ESXi to collect diagnostic information (1010705) и уже спокойно анализируйте выгрузку.