Blog of Khlebalin Dmitriy

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

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

Во второй части удалось поднять vCenter HA.

Осталось завершить траблешутинг и вернуть систему в рабочее состояние.

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

— hostname: ESX16.comp.loc
— this is VMware ESXi 6.7.0 build-13644319 EP 09 (U2)
— server model and BIOS version
Dell Inc. PowerEdge R630 | BIOS: 2.9.1 | Date: 12/04/2018

— Network Interface Card (NIC, hardware only, lspci)
vmnic   PCI bus address  link  speed  duplex  MTU   driver  driver version  firmware version      MAC address        VID   DID   SVID  SDID  name
——   —————  —-  ——  ——  —   ——  —————  —————-      ————        —   —   —-  —-  ————————————
vmnic0  0000:01:00.0     Up    1000   Full    1500  ntg3    4.1.3.2         bc 1.39 ncsi 1.5.1.0  18:66:da:f3:d0:70  14e4  165f  1028  1f5b  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic1  0000:01:00.1     Down  0      Half    1500  ntg3    4.1.3.2         bc 1.39 ncsi 1.5.1.0  18:66:da:f3:d0:71  14e4  165f  1028  1f5b  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic2  0000:02:00.0     Down  0      Half    1500  ntg3    4.1.3.2         bc 1.39 ncsi 1.5.1.0  18:66:da:f3:d0:72  14e4  165f  1028  1f5b  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic3  0000:02:00.1     Down  0      Half    1500  ntg3    4.1.3.2         bc 1.39 ncsi 1.5.1.0  18:66:da:f3:d0:73  14e4  165f  1028  1f5b  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic4  0000:04:00.0     Up    10000  Full    9000  qfle3   1.0.50.11        7.14.11              f4:e9:d4:b7:fe:f0  14e4  168e  14e4  1006  Broadcom Corporation QLogic 57810 10 Gigabit Ethernet Adapter
vmnic5  0000:04:00.1     Up    10000  Full    9000  qfle3   1.0.50.11        7.14.11              f4:e9:d4:b7:fe:f2  14e4  168e  14e4  1006  Broadcom Corporation QLogic 57810 10 Gigabit Ethernet Adapter
==========================================================================================================================================================================================================

ESXi 6.7 U2    ntg3 version 4.1.3.2-1vmw    N/A
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=20918

ESXi 6.7 U2    qfle3 version 1.0.86.0    FFV 15.00.14/7.14.xx
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=21521

Рекомендую обновить согласно матрице совместимости.

В backtrace я вижу, что PSOD был вызван ошибкой LINIT1/NMI, данная ошибка могла вызываться включенной настройкой -iovDisableIR, но в нашем случае она выключена.
https://kb.vmware.com/s/article/2149592

В остальных случаях данный PSOD указывает на проблемы со стороны физических компонентов сервера.

An NMI is a physical hardware event.

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

Прошу Вас обратиться к вендору для дальнейшей диагностики.

backtrace
2019-10-24T12:08:54.426Z cpu0:2102659)@BlueScreen: LINT1/NMI (motherboard nonmaskable interrupt), vmkapei.HestNMIHandler has diagnosed a Fatal error.
Review reported message(s) in PSOD screen to identify NMI error source details. This may be a hardware $
2019-10-24T12:08:54.426Z cpu0:2102659)Code start: 0x418011400000 VMK uptime: 0:00:34:25.584
2019-10-24T12:08:54.426Z cpu0:2102659)0x450a00002c60:[0x41801150ba15]PanicvPanicInt@vmkernel#nover+0x439 stack: 0x54
2019-10-24T12:08:54.427Z cpu0:2102659)0x450a00002d00:[0x41801150bc48]Panic_NoSave@vmkernel#nover+0x4d stack: 0x450a00002d60
2019-10-24T12:08:54.427Z cpu0:2102659)0x450a00002d60:[0x4180115086ba]NMICheckLint1@vmkernel#nover+0x183 stack: 0x0
2019-10-24T12:08:54.427Z cpu0:2102659)0x450a00002e20:[0x418011508782]NMI_Interrupt@vmkernel#nover+0xb3 stack: 0x0
2019-10-24T12:08:54.428Z cpu0:2102659)0x450a00002ea0:[0x418011544ecc]IDTNMIWork@vmkernel#nover+0x99 stack: 0x0
2019-10-24T12:08:54.428Z cpu0:2102659)0x450a00002f20:[0x4180115463c0]Int2_NMI@vmkernel#nover+0x19 stack: 0x0
2019-10-24T12:08:54.428Z cpu0:2102659)0x450a00002f40:[0x418011563066]gate_entry@vmkernel#nover+0x67 stack: 0x0
2019-10-24T12:08:54.428Z cpu0:2102659)0x451ab159bd08:[0x41801155c921]WorldSaveVTState@vmkernel#nover+0x31 stack: 0x41801155e8fa
2019-10-24T12:08:54.429Z cpu0:2102659)0x451ab159bd20:[0x41801155e8f9]World_Switch@vmkernel#nover+0xb76 stack: 0x451ab2423340
2019-10-24T12:08:54.429Z cpu0:2102659)0x451ab159bd70:[0x41801170b6a6]CpuSchedDispatch@vmkernel#nover+0xa73 stack: 0x418040000080
2019-10-24T12:08:54.429Z cpu0:2102659)0x451ab159beb0:[0x41801170d53f]CpuSchedWait@vmkernel#nover+0x2f4 stack: 0x450200000000
2019-10-24T12:08:54.430Z cpu0:2102659)0x451ab159bf40:[0x41801170dcb4]CpuSched_VcpuHalt@vmkernel#nover+0x12d stack: 0x0
2019-10-24T12:08:54.430Z cpu0:2102659)0x451ab159bfa0:[0x418011536546]VMMVMKCall_Call@vmkernel#nover+0xf7 stack: 0x0
2019-10-24T12:08:54.430Z cpu0:2102659)0x451ab159bfe0:[0x41801155c77d]VMKVMM_ArchEnterVMKernel@vmkernel#nover+0xe stack: 0x41801155c770
2019-10-24T12:08:54.434Z cpu0:2102659)base fs=0x0 gs=0x418040000000 Kgs=0x0
2019-10-24T12:08:54.369Z cpu0:2102659)ApeiHEST: 387: Fatal error reported by 0000:00:02.0(PCI Express Root Port). VID:8086, DID:6f04, DevSts: 0x4, AERUeSts: 0x40000, RPErrSts: 0x54, RPErrSrcId: 0x100000.
2019-10-24T11:34:43.751Z cpu5:2097618)Failed to verify signatures of the following vib(s): [vmware-esx-perccli-1.05.08]. All tardisks validated
2019-10-24T12:08:54.435Z cpu0:2102659)vmkernel             0x0 .data 0x0 .bss 0x0

\==+Kernel Bool Option :
|—-Option Name………………………………….iovDisableIR
|—-Configured Value……………………………..false
|—-Runtime Value………………………………..false
|—-Default Value………………………………..false

—————————————————

По второму хосту ошибка идентичная.

— hostname: ESX17.comp.loc
— this is VMware ESXi 6.7.0 build-13644319 EP 09 (U2)
— server model and BIOS version
Dell Inc. PowerEdge R630 | BIOS: 2.9.1 | Date: 12/04/2018

— Network Interface Card (NIC, hardware only, lspci)
vmnic   PCI bus address  link  speed  duplex  MTU   driver  driver version  firmware version      MAC address        VID   DID   SVID  SDID  name
——   —————  —-  ——  ——  —   ——  —————  —————-      ————        —   —   —-  —-  ————————————
vmnic0  0000:01:00.0     Up    1000   Full    1500  ntg3    4.1.3.2         bc 1.39 ncsi 1.5.1.0  18:66:da:f4:0e:dc  14e4  165f  1028  1f5b  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic1  0000:01:00.1     Down  0      Half    1500  ntg3    4.1.3.2         bc 1.39 ncsi 1.5.1.0  18:66:da:f4:0e:dd  14e4  165f  1028  1f5b  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic2  0000:02:00.0     Down  0      Half    1500  ntg3    4.1.3.2         bc 1.39 ncsi 1.5.1.0  18:66:da:f4:0e:de  14e4  165f  1028  1f5b  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic3  0000:02:00.1     Down  0      Half    1500  ntg3    4.1.3.2         bc 1.39 ncsi 1.5.1.0  18:66:da:f4:0e:df  14e4  165f  1028  1f5b  Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic4  0000:04:00.0     Up    10000  Full    9000  qfle3   1.0.50.11        7.14.11              f4:e9:d4:b7:f8:c0  14e4  168e  14e4  1006  Broadcom Corporation QLogic 57810 10 Gigabit Ethernet Adapter
vmnic5  0000:04:00.1     Up    10000  Full    9000  qfle3   1.0.50.11        7.14.11              f4:e9:d4:b7:f8:c2  14e4  168e  14e4  1006  Broadcom Corporation QLogic 57810 10 Gigabit Ethernet Adapter
==========================================================================================================================================================================================================

ESXi 6.7 U2    ntg3 version 4.1.3.2-1vmw    N/A
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=20918

ESXi 6.7 U2    qfle3 version 1.0.86.0    FFV 15.00.14/7.14.xx
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=21521

backtrace
2019-10-24T12:10:53.746Z cpu0:2102927)@BlueScreen: LINT1/NMI (motherboard nonmaskable interrupt), vmkapei.HestNMIHandler has diagnosed a Fatal error.
Review reported message(s) in PSOD screen to identify NMI error source details. This may be a hardware $
2019-10-24T12:10:53.746Z cpu0:2102927)Code start: 0x418035a00000 VMK uptime: 0:00:06:39.969
2019-10-24T12:10:53.746Z cpu0:2102927)0x450a00002c70:[0x418035b0ba15]PanicvPanicInt@vmkernel#nover+0x439 stack: 0x54
2019-10-24T12:10:53.747Z cpu0:2102927)0x450a00002d10:[0x418035b0bc48]Panic_NoSave@vmkernel#nover+0x4d stack: 0x450a00002d70
2019-10-24T12:10:53.747Z cpu0:2102927)0x450a00002d70:[0x418035b086ba]NMICheckLint1@vmkernel#nover+0x183 stack: 0x0
2019-10-24T12:10:53.747Z cpu0:2102927)0x450a00002e30:[0x418035b08782]NMI_Interrupt@vmkernel#nover+0xb3 stack: 0x0
2019-10-24T12:10:53.747Z cpu0:2102927)0x450a00002eb0:[0x418035b44ecc]IDTNMIWork@vmkernel#nover+0x99 stack: 0xc314b5bad5
2019-10-24T12:10:53.748Z cpu0:2102927)0x450a00002f30:[0x418035b44f80]IDTVMMNMI@vmkernel#nover+0x29 stack: 0xffffffffffffffff
2019-10-24T12:10:53.748Z cpu0:2102927)0x450a00003000:[0x418035b61e78]SlaveBootEnd@vmkernel#nover+0x9 stack: 0x0
2019-10-24T12:10:53.752Z cpu0:2102927)base fs=0x0 gs=0x418040000000 Kgs=0x0
2019-10-24T12:10:53.689Z cpu0:2102927)ApeiHEST: 387: Fatal error reported by 0000:00:02.0(PCI Express Root Port). VID:8086, DID:6f04, DevSts: 0x4, AERUeSts: 0x40000, RPErrSts: 0x54, RPErrSrcId: 0x100000.
2019-10-24T12:04:28.761Z cpu3:2097618)Failed to verify signatures of the following vib(s): [vmware-esx-perccli-1.05.08]. All tardisks validated
2019-10-24T12:10:53.753Z cpu0:2102927)vmkernel             0x0 .data 0x0 .bss 0x0

\==+Kernel Bool Option :
|—-Option Name………………………………….iovDisableIR
|—-Configured Value……………………………..false
|—-Runtime Value………………………………..false
|—-Default Value………………………………..false

Обновлю биос и фирваре согласно рекомендациям.

Переводим ноду в Маитененс мод:

Тут видна интересная картинка: DRS вроде отрабатывает, но нагружает ноды совсем не равномерно:

Пробую сделать:

Но ничего не работает.

Странно….

Вероятно будет полезен вот этот пост: https://kb.vmware.com/s/article/2150667

Проверяем:

Похоже на то, что работает. Нагрузка по нодам более равномерна… Это радует 😊 Но еще посмотрю, может радоваться рано…

Обновляю прошивки и BIOS.

До обновления:

После:

Здесь же столкнулся с еще одним интересным багом при переводе хоста в Maintenance Mode все машинки с нее съезжают, а хост в Maintenance Mode не переходит.

В этом случае будет полезно вот такое решение:

Через консоль заходим в управление хостом: F2-Troubleshooting Options- Restart Managements Agents

На этом траблешутинг закончен. Будем посмотреть, как дальше все будет.

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

P.S. Прошло уже почти две недели с момента падения, пока все в штатном режиме.

21.11.2019 Posted by | vmware & hyper-v Infrastructure | Комментарии к записи Crash cluster vSphere 6.7. Troubleshooting again (part 3). отключены

Crash cluster vSphere 6.7. vCenter High Availability (VCHA) (part 2).

Времени мало, перед работой решил черкнуть пару строк…

В первой части описал  хронологию и траблешутинг падения кластера, вторая часть больше посвящена отладке, а именно настройке vCenter High Availability (VCHA).

https://vmblog.ru/nastrojka-vysokoj-dostupnosti-ha-dlya-vmware-vcenter-6-5/

https://esxsi.com/2018/10/21/vcsa67-ha/

https://vmvtips.com/2019/02/24/vcp-dcv2019-objective-1-2/

У меня уже подцеплен другой VLAN управления (VLAN4), который мне будет необходим чуть позже, поэтому, как его «прикрутить», я здесь этот момент пропущу.

Пробую нажать кнопку Set UP

Предположил, что ошибка связана вот с этим правилом DRS.

 

Но мое предположение оказалось неверным. Результата это никакого не принесло.

Далее предположил, что ошибка вызвана остановленной (а точнее даже выключенной) службой:

Служба vCenter HA в положении Disabled.

Поэтому стартануть ее тоже не получится.

Официальный гайд гласит следующее:

https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vcsa.doc/GUID-10E2CE2D-8CBD-49B7-BC1C-1F25C1A627EC.html

но в живую всего этого нет (вероятно было в версии 6.5)

Пробуем обходной путь:

Тоже не выходит «каменный цветок».

Тогда будет полезен вот этот пост:

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

Через HTML5 ничего не получается, а вот через:

Вполне себе получилось

Службу включил, но потом выключил, и понял, что она не влияет на процесс-это странно, но это факт (вероятно в процессе развертывания HA она в последствии все же стартует сама), пока оставляем выключенной.

Далее продолжаем настройку через этот же интерфейс FLEX (запускаем из под IE, в EDGE, Chrome, мне ее так и не удалось стартануть).

Адреса должны быть в другом VLANe (про него я как раз писал в начале поста).

Хосты и стораджи тоже надо разнести.

В процессе появилась вот такая ошибка:

Предположили, что ошибка связана с правилом DRS, которое привязывает vCenter  к первой ноде (я ранее его уже упоминал). Удаляем правило, снова пересобираем.

И снова та же ошибка:

Руками «передвинул» vcenter на другую корзину и при создании реплик разнес все по разным нодам и по разным лунам.

Но это тоже не помогло. Теперь ошибка на третьей копии vcenter.

Переводим DRS в ручной режим.

Снова пробуем.

Проблема  та же самая.

Выключаем DRS.

И  выключаем Admission Control.

Снова пробуем.

Свершилось чудо. Подозрение пало на то, что как раз Admission Control не давал развернуть HA vCenter.

Снова включаем DRS и Admission Control.

Пробуем INITIATE FALOVER.

Сервак на некоторое время (минут 5-10) впадает в анабиоз. И поднимается вновь.

После чего пассивная нода вдруг становится активной, HA наконец отрабатывает.

Это радует.

Далее осталось разобраться с:

И VMvare Tools, но это уже не относится к падению кластера.

Отправляем логи, коллегам в «КРОК» для изучения и в «VMware» для расшифровки и понимания того, что вызвало такое падение.

В общей сложности кластер был недоступен примерно 4 часа — ЭТО НЕ ЕСТЬ ХОРОШО.

Восстановление обновление и отладка также заняла немало времени. Надеюсь все, что было сделано, было не зря. Пока полет нормальный…

По итогам попробовал «уронить» одну ноду, дабы посмотреть , как все будет.

Как я ранее писал, сначала включил Admission Control, но уронив ноду, выключил его, так как машинки при текущей нагрузке еле ползли и почти впали в гидростопор (резервирование ресурсов в нашей ситуации пока противопоказано).

После отключения все достаточно быстро заколосилось…

Продолжение следует…

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

07.11.2019 Posted by | vmware & hyper-v Infrastructure | | Комментарии к записи Crash cluster vSphere 6.7. vCenter High Availability (VCHA) (part 2). отключены

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 комментарий