PSOD (Purple Screen of Death) в ESXI системах

Добрый день! Уважаемые читатели и подписчики компьютерного блога Pyatilistnik.org. 21 век, это безусловно век компьютерных технологий, глубокое понимание которых позволяет вам быть востребованным специалистом. Но, что отличает специалиста от профессионала, и что главное для бизнеса. Ответ на этот вопрос определяется одним словом, траблшутинг, кто не знает, это навык быстрого поиска и проблем и их устранение. Сегодня я хочу с вами поговорить про трабшутинг гипервизора Vmware ESXI, а именно пурпурных экранов смерти "PSOD (Purple Screen of Death)". Уверен. что вам будет интересно.

Что такое PSOD

Пурпурный экран смерти или PSOD (Purple Screen of Death) - это экран пурпурного цвета, который появляется, в двух ситуациях. Первая, это когда у вашего гипервизора Vmware ESXI проблемы с физическим железом и совместимостью его с операционной системой, либо же это проблема самой ОС, но я такое еще не встречал за свою практику. Второй вариант пурпурного экрана ESXI, это тестовая среда, где вы изучаете гипервизор и оттачиваете свои навыки траблшутера устраняя проблемы с ним. Экран Purple Screen of Death является аналогом синего экрана Windows (BSOD) и зеленого экрана (GSOD).

Как правило, PSOD детализирует состояние памяти во время сбоя и включает в себя другую информацию, такую ​​как:

1. версия и сборка ESXI
2. тип исключения
3. дамп реестра, что работало на каждом процессоре во время сбоя
4. обратная трассировка
5. время работы сервера
6. сообщения об ошибках и информация о дампе ядра

Логично предположить, что ничего хорошего в PSOD нет, ладно если это тестовая среда, то там можно не переживать за железо и его совместимость, а если продакшн, то тут большие проблемы, давайте научимся их диагностировать. Кстати выглядит это вот так. Данный экран можно лицезреть локально через подключенный монитор к серверу, или же через консоль порта управления, по типу ILO порта от HP, IMM IBM, IDRAC Dell или IPMI у Supermicro или Intel.

Почему это происходит?

PSOD - это паническое поведение ядра системы. Хотя мы все знаем, что ESXi не основан на UNIX, реализация паники соответствует определению UNIX. Ядро ESXi (vmkernel) запускает эту меру безопасности в ответ на событие или ошибку, которая неустранима и будет означать, что продолжение работы будет представлять высокий риск для сервисов и виртуальных машин.

Наиболее распространенные причины возникновения PSOD:

• Аппаратные сбои, в основном связанные с ОЗУ или ЦП. Обычно они выдают ошибку "MCE" или "NMI (Non-Maskable Interrupt)".

"MCE" - исключение проверки компьютера, представляющее собой механизм в ЦП для обнаружения и сообщения о проблемах с оборудованием. Есть важные детали для определения основной причины проблемы в кодах, отображаемых на фиолетовом экране.
"NMI" - не маскируемое прерывание, которое является аппаратным прерыванием, которое не может игнорироваться процессором. Поскольку NMI является очень важным сообщением о сбое железа, ответ по умолчанию, начиная с ESXi 5 и более поздних версий, - запускает PSOD, но это кстати можно поправить и просто регистрировать проблему. Более ранние версии просто регистрировали ошибку и продолжали работать. Как и в случае с MCE, фиолетовый экран, вызванный NMI, предоставит важные коды, которые имеют решающее значение для устранения неполадок, вообще у Vmware на эту тему есть статья (https://kb.vmware.com/s/article/1014767).

• Программные ошибки

1. неправильное взаимодействие между компонентами ESXi SW (например: KB2105711)
2. недостаточно ресурсов: память, проблема с буфером (например: KB2034111, KB2150280)
3. бесконечный цикл + переполнение стека (например: KB2105522)
4. неправильные или не поддерживаемые параметры конфигурации (например: KB2012125, KB2127997)

• Проблема с драйверами сторонних производителей.

Ошибки в драйверах, которые пытаются получить доступ к некоторому неверному индексу или несуществующему методу, например KB2146526, KB2148123. Очень часто администраторы могут интегрировать, какой либо драйвер в ESXI и получить PSOD. Были случаю, что видел пурпурный экран из-за драйвера SMIS провайдера для RAID контроллера.

Что происходит с виртуальными машинами при Purple Screen of Death

Когда возникает PSOD и происходит сбой хоста, он завершает все работающие на нем сервисы вместе со всеми размещенными виртуальными машинами. Виртуальные машины отключаются не корректно, для них это равносильно сделать Power OFF. Если хост является частью кластера и вы настроили HA, эти виртуальные машины будут запущены на других хостах в кластере. Помимо сбоя и недоступности виртуальных машин в то время, когда они не работают, "грязное отключение" (dirty shutdown) может повлиять на некоторые критически важные приложения, такие как серверы баз данных, где ее придется восстанавливать, или задания резервного копирования в том же Veeam Backup.

Кроме того, все другие службы, предоставляемые хостом, будут прерваны, поэтому, если ваш хост является членом кластера VSAN, PSOD также повлияет на vSAN. Для меня самым неприятным аспектом PSOD является то, что он заставляет вас терять доверие к своей инфраструктуре, вы уже будите ожидать, что продакшн сервисы могут быть недоступны, поэтому старайтесь всегда все дублировать, а если на это не выделяют денег, то главное донести до руководства, потом в случае чего вы их ткнете носом, я так делал на своей предыдущей работе, когда не хотели подключать второй канал с интернетом.

Как диагностировать дамп PSOD

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

• Первым делом, если есть IP KVM или консоль порта управления, то делаем скриншот, он пригодится для анализа. Если нет возможности то сфотографируйте на телефон, если сервис критичный, то просто перезагружаем. если нет времени на фото, такое можно представить если у вас сервера в цоде.
• После перезагрузки ESXI хоста у вас создастся дамп памяти, который можно анализировать и передать представителям технической поддержки Vmware, при условии, что она у вас есть.

По умолчанию у вас дамп пурпурного экрана должен лежать в корне файловой системы, так называемый root каталог, но его может там и не оказать, стопроцентно его можно найти по пути /var/core/. Для получения файла вам необходимо включить ssh и подключиться по ssh к вашему хосту ESXI, как это делать я уже показывал ранее.

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

Должны быть статусы Active и Configured, если путей нет, то хранится по умолчанию, либо же может быть по указанным путям.

Чтобы понять, где лежит дамп PSOD, введите команду:

Команда запросит два каталога и проверит наличие файла, в моем примере в root ничего не было, а вот в core был лог "/var/core/vmkernel-zdump.1".

Проще всего конечно использовать утилиту WinSCP с графическим файловым редактором.В моем случае файл дампа PSOD был размером 91 мегабайт. Копируем его для диагностики.

Генерация VMkernel zdump вручную из файла дампа на хосте ESXi.

vmkernel-log.1. файл с простым текстом, хотя может начинаться с нулевыми символами. Данный файл потом легко смотреть через текстовый редактор, например NotePad++. (ПО генерации дампа можно еще почитать вот тут)

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

1. Версия продукта с номером сборки
2. Детали сообщения об ошибке, вызвавшего PSOD
3. Регистры процессора
4. Детали физического процессора
5. Время загрузки хоста Esxi
6. Трассировка лога или его еще называют след стека
7. Информация о дампе памяти

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

• Exception Type 0 #DE: Divide Error
• Exception Type 1 #DB: Debug Exception
• Exception Type 2 NMI: Non-Maskable Interrupt
• Exception Type 3 #BP: Breakpoint Exception
• Exception Type 4 #OF: Overflow (INTO instruction)
• Exception Type 5 #BR: Bounds check (BOUND instruction)
• Exception Type 6 #UD: Invalid Opcode
• Exception Type 7 #NM: Coprocessor not available
• Exception Type 8 #DF: Double Fault
• Exception Type 10 #TS: Invalid TSS
• Exception Type 11 #NP: Segment Not Present
• Exception Type 12 #SS: Stack Segment Fault
• Exception Type 13 #GP: General Protection Fault
• Exception Type 14 #PF: Page Fault
• Exception Type 16 #MF: Coprocessor error
• Exception Type 17 #AC: Alignment Check
• Exception Type 18 #MC: Machine Check Exception
• Exception Type 19 #XF: SIMD Floating-Point Exception
• Exception Type 20-31: Reserved
• Exception Type 32-255: User-defined (clock scheduler)

У Vmware каждой из таких ошибок есть специальная KB статья, так что это не проблема выяснить причину.

Дополнительная диагностика

Полезную информацию вам могут подсказать и логи на самом хосте или же на вашем vCenter сервере или же на вашем Dump Collector. О том, где хранятся и как выгружать логи VVMware ESXI я уже рассказывал, я не буду на это останавливаться, тут лишь напомню, пути к журналам.

• Системные сообщения /var/log/syslog.log - Содержит все общие сообщения журнала и может использоваться для устранения неполадок.
• VMkernel /var/log/vmkernel.log - Записывает действия, связанные с виртуальными машинами и ESXi. Большинство записей PSOD будет в этом журнале, поэтому обратите на это особое внимание.
• Журнал хост-агента ESXi /var/log/hostd.log - Содержит информацию об агенте, который управляет и настраивает хост ESXi и его виртуальные машины.
• Предупреждения VMkernel /var/log/vmkwarning.log - Записывает действия, связанные с виртуальными машинами. Следите за записями журнала, связанными с исчерпанием (Heap WorkHeap).
• Журнал агента vCenter /var/log/vpxa.log - Содержит информацию об агенте, который взаимодействует с vCenter, так что вы можете использовать его для определения задач, вызванных vCenter и которые могли вызвать PSOD.
• Журнал Shell /var/log/shell.log - Содержит запись всех введенных команд, поэтому вы можете соотнести PSOD с выполненной командой.

Как самому вызвать PSOD

В качестве тестирования и повышения навыков понимания программных продуктов Vmware, разработчики внедрили в свой гипервизор возможность запланировано вызывать пурпурный экран. Сделать, это можно из shell оболочки или же через ssh подключение, для этого введите команду:

На этом у меня все, я надеюсь, что вы научились исправлять и анализировать пурпурные экраны смерти на гипервизоре VMware ESXI, а с вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org.