Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

Crash cluster vSphere 6.7. Troubleshooting again (part 1).

В начале своего повествования хотел бы поблагодарить наших партнеров из компании «КРОК«:

  • Нашего менеджера Андрея-за оперативную организацию технической поддержки.
  • Инженера VmWare Никиту-за саму поддержку. За важные советы по восстановлению и тонкой отладке системы. Да и в целом за отличный best practice для меня.

А теперь к теме…

На минувшей неделе, а именно в четверг в обед, испытали некоторый шок и трепет…

Из истории…

У нас три ноды DELL (2Xeon, 512gb, 256SSD mirror на каждой ноде). В ходе реализации проекта, была предусмотрена схема отказоустойчивости (3-1). Вроде все ровно последние года полтора после очередного UPGRADE.

Последнее обновление до версий:

Было сделано еще месяца 4 назад (плюс, минус), и в целом все было нормально, никаких обновлений прошивок или еще чего-то с тех пор не происходило, банально на это не было времени ☹

Но в тот день начали происходить странные вещи (хронология):

Одна из нод поведала о следующем:

И впала (здесь не синий, а розовый «экран смерти»).

Все машинки соответственно смигрировали на оставшиеся две ноды (у нас 3-1-это печально, но не критично).

Через пару минут с таким же розовым «экраном смерти» падает вторая нода из трех.

Все машинки переезжают на оставшуюся единственную. Нагрузка по (процам и памяти возрастает до критической-это в каком то роде напомнило мне сериал HBO «Чернобыль», в смысле поведения реактора), но машинки дико тупят, но продолжают быть активными, хотя в этой ситуации работать с ними уже практически невозможно. Vcenter также был пока доступен. Но при такой нагрузке оставшаяся нода прожила достаточно не долго (примерно минут 10) и также «впала в анабиоз».  Так минут за 15-25 мы полностью потеряли кластер. Далее повторный поочередный запуск, то одной, то другой нод никакого результата не дал: нода поднимается, работает нескольк минут на ней стартуют все машинки и она тут же падает и так веерно одна за другой по кругу. Vcenter соответственно также перестал быть доступен, точнее он не успевал подняться ни на одной из нод ☹.

Вмваре я эксплуатирую еще с 3 версии, но такое вижу впервые… Печаль…

Траблешутинг.

Включаю ноду начинаю максимально тушить прикладные машинки, чтобы погасить запредельную нагрузку на нее, постепенно нагрузка начинает падать и неспешно подходит к тому значению, когда, нода становится стабильной и более не падает (нагрузка 99-100%). Тут всплыл интересный момент: большинство продакшин машинок, которые я не затушил продолжали быть доступны как локально, так и пинговались по сети, но ни по шаре ни по например RDP зайти на них было не возможно, то есть по сути для продакшина они все оказались недоступны ☹.

Вицентр теперь нормально стал доступен даже через WEB-это уже не плохо.

Судя по характеру падения, проблема касается гипервизора, а соответственно надо его обновлять.

Но перед этим надо обновить сам vCenter.

Начинаю обновлять vCenter и во время его обновления нода снова падает.

Сразу снова запускаю все три ноды на случай того, если снова начнется веерное падение, для того, чтобы хоть vCenter был доступен на какой-то из живых…

vCenter перезагружается, но войти на него более невозможно, локально под рутом пускает, но больше никак. На эту тему будут полезны вот эти посты:

https://kb.vmware.com/s/article/50113586

https://kb.vmware.com/s/article/2147144

https://kb.vmware.com/s/article/67179

https://www.vmgu.ru/news/vmware-vcenter-server-appliance-services

https://itblog.ru.net/vmware/vsphere/vami-unable-to-login/

Проблема исправляется, открывается веб интерфейс vCenter, но там следующее окно, об обновлении с ошибкой (нода как раз перезагрузилась, когда vCenter обновлялся), которое не дает ничего сделать из-под веба. Для того чтобы это исправить будет полезен вот этот пост:

https://kb.vmware.com/s/article/67179

Окошко пропадает, теперь можно обновлять обычным способом:

Сейчас здесь пусто, а до этого были видны два апдейта. Начинаю обновлять один за другим, но тут ждет следующий сюрприз: примерно на 56% обновлений выскакивает ошибка обновления и все. Кнопка отменить здесь активна, и можно отменить его, но это не решает того, вопроса, что надо vCenter дообновить.

Придется делать это через командную строку:

https://www.vmgu.ru/news/vmware-vcenter-server-appliance-60-vcsa-update

https://communities.vmware.com/thread/596060

— Качаем iso.

— Подцепляем его к vcenter.

— Далее через командную строку:

software-packages stage  –iso

software-packages install –staged

Наконец обновление накатилось, vcenter жив и здоров, за исключением того, что мне так и не удалось сделать так чтобы служба запускалась после перезагрузки автоматом, поэтому пока вот так:

service-control —start –applmgmt

Как ее запустить автоматом, я так и не нашел, если есть на эту тему мысли, прошу отписать в комментариях (или правильнее сказать, как исправить данный баг)?

Пришло время обновить гипервизор на нодах.

Первично проанализировали логи, и поняли, причиной падения нод, стало последнее стандартное обновление Гиппервизора (это примерно, как стандартные виндовые драйвера).

Поэтому качаем образ непосредственно под DELL:

Накатываем его:

Получаем:

Два дня, полет нормальный.

Далее необходимо собрать логи и передать партнерам в «КРОК» и «Вмваре» на изучение и детальный глубокий анализ.

Первичные рекомендации по проблеме:

https://kb.vmware.com/s/article/1804

https://www.dell.com/support/article/ru/ru/rubsdc/sln155921/how-to-troubleshoot-lint1-motherboard-interrupt-errors-on-poweredge-servers-running-vmware-vsphere?lang=en

На каждой ноде меняем вот этот параметр:

По факту аварии, решили настроить HA непосредственно для Vcenter, но это уже тема следующего повествования. Продолжение следует… Так же пост будет постепенно дополняться по мере поступления деталей.

Всем хорошей работы!!!

31.10.2019 Posted by | vmware & hyper-v Infrastructure | 1 комментарий

Cannot open the disk or… VMware ESX cannot find the virtual disk… в VMware vSphere 6.7.

Из истории…

Мой коллега Данила, решил недавно «заморочиться» с файловер кластером Microsoft, на нем же поднять кластер SQL, на нем же настроить кластер 1С. В тестовой среде были подняты две ноды:

И в качестве хранилища баз, обоим нодам был презентован vmdk раздел 2гб (соответственно на сервере он стал диском d: ), где и были размещены базы SQL сервера.

В целом это все нормально работало, до тех пор, пока не решили принудительно средствами VmWare, как это делаем обычно, расширить диск до 15гб. Раздел благополучно расширился, но после его расширения, обе ноды отказались стартовать, выпадая с ошибкой:

Cannot open the disk or… VMware ESX cannot find the virtual disk…

Из данной ошибки видно, что ESX не может найти виртуальный диск <vm_name>.vmdk по сему обе ноды не стартуют.

В базе датастора необходимо найти диск, файл <vm_name>-flat.vmdk, это как раз файл с данными нашего vmdk раздела.

<vm_name>.vmdk -конфиг,

<vm_name>-flat.vmdk — файл с данными.

Восстановим файл:

1) При помощи консоли (ssh или putty) заходим по ssh на ESX хост:

ssh root@<hostname_IP>
мне проще и быстрее использовать для этого WinSCP:

2) Переходим в папку, в которой находятся файлы нашей виртуальной машины:

cd /vmfs/volumes/<your_volume>/<VM_directory>

3) Теперь нам необходимо узнать точный размер flat диска (здесь в любом случае  уже потребуется командная строка):

ls -l <vm_name>-flat.vmdk 

Запоминаем текущий размер  — 16106127360 (он у вас безусловно будет другим)

4) Далее при помощи команды vmkfstools нужно создать новый (временный) vmdk файл с именем, например, temp.vmdk и точным размером файла flat (то что мы узнали в предыдущем пункте), тип диска выберем thin (тонкий – то есть растущий по мере наполнения его данными) и адаптером lsilogic (его можно не указывать).

vmkfstools -c 16106127360 -d thin -a lsilogic temp.vmdk

Как видно, на картинке, файлы у нас благополучно появились в директории:

5) У вас должно получиться два файла – temp.vmdk и temp-flat.vmdk. Последний файл нам не нужен, удалим его:

rm temp-flat.vmdk

Или просто клавишей Del в WinSCP 🙂

6) Теперь переименуем temp.vmdk в нужное нам название, то есть в <vm_name>.vmdk:

mv temp.vmdk <vm_name>.vmdk

В WinSCP правой кнопкой, «Переименовать».

7) Vmdk файл – это конфигурационный файл диска, соответственно нам необходимо его отредактировать. При помощи редактора VI открываем файл:

vi <vm_name>.vmdk

Находим в нем строчку:
RW 31457280 VMFS «temp-flat.vmdk»
Соответственно изменяем «temp-flat.vmdk» на «<vm_name-flat>.vmdk».

Сохраняемся и выходим из редактора.

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

https://kb.vmware.com/s/article/9105247?docid=9105247

Самый простой способ «законвертить» его:

https://vmblog.ru/konvertaciya-virtualnyx-diskov-vmdk-iz-thick-v-thin-v-vmware-esxi/

В итоге, обе ноды благополучно стартанули с общим диском, но сам кластер Microsoft не завелся сразу, пришлось передобавить этот диск уже в самом кластере, но самое важное данные, и они целы.

Диск должен быть подмонтирован вот таким способом:

Полезный материал по теме:

http://pyatilistnik.org/create-a-cluster-rdm-disk-in-vmware-esxi/

http://pyatilistnik.org/creating-a-cluster-multi-writer-disk-in-vmware-esxi/

Всем хорошей работы!!!

25.04.2019 Posted by | vmware & hyper-v Infrastructure | Комментарии к записи Cannot open the disk or… VMware ESX cannot find the virtual disk… в VMware vSphere 6.7. отключены

Upgrade VMware ESXi 6.7 to 6.7 Update 1.

На старте у нас версия vCenter 6.7, ранее до нее уже обновились.

Убеждаемся, что Veeam обновлен, приступаем к обновлению vCenter до 6.7U1 (сейчас уже актуально обновление b).

Если давно не обновляли, можно коротко пробежаться вот по этому:

https://miketabor.com/update-vcenter-server-appliance-6-7-to-6-7-update-1/

Обновляем vCenter.

Наша текущая версия vCenter:

Делаем backup  средствами Veeam на случай если что-то пойдет не так:

Здесь же делаем снепшот vCenter, как запасной вариант.

Обновляем vCenter:

На 78% окно закрывается и мы снова видим стартовое окно vCenter, что происходит, пока непонятно.

Но пока не пускает. Управление виртуалками также ничего не кажет…

Сколько ждать, тоже пока непонятно…

Минут 10 спустя…

Пытаемся посмотреть, что с управлением:

Наконец прогрузился- что уже не плохо.

Удаляем ранее сделанный снепшот:

На этом обновление vCenter закончено (здесь все четко, никаких багов и проблем нет).

Далее обновляем хосты ESXi.

Перед этим можно ознакомиться вот с этим постом:

https://miketabor.com/how-to-update-vmware-esxi-6-7-to-6-7-update-1/

Переводим первый хост в «Maintanace mode»

Машинки мигрируют.

Смотрим на то, какая версия ESXi у нас сейчас:

Разбираем кластер (Отключаем HA, Admission Control).

Update сразу не заработал. Вроде все проходит в штатном режиме, но обновление не происходит.

Пока не понятно почему так…

Оказалось, сначала обязательно необходимо поставить вот эти обновления для 6.7 (их 4), потом уже поверх «накатить» Update 6.7U1.

После чего U1 накатывается без проблем.

Версии можно посмотреть здесь:

https://kb.vmware.com/s/article/2143832?lang=en_US

Далее все тоже самое проделываем со следующими нодами. Перед этим не забываем снова собрать кластер, чтоб машинки равномерно разъехались по рабочим нодам.

После обновления всех нод, обновляем VmWare Tools.

Compatibility.

На этом обновление закончено.

Заметил еще одну особенность,  на те машинки, которые были в паузе и те которые не обновились с первого раза, VmWare vSphere Update создал по несколько снепшотов. Автоматически они в последствии не удаляются. Необходимо пробежаться по всем таким машинкам и руками удалить снепшоты.

Всем хорошей работы!!!

P.S. Самое интересное, то, что обновилось все кроме самого vCenter, и самое интересное, что он при обновлении выпадает с ошибкой.

На эту тему версий у меня пока нет, если есть этому объяснение прошу написать в комментарии…

 

19.03.2019 Posted by | vmware & hyper-v Infrastructure | Комментарии к записи Upgrade VMware ESXi 6.7 to 6.7 Update 1. отключены