Многие администраторы VMware ESXi сталкивались с такой проблемой, как «фиолетовый экран смерти». Самое неприятное в этой проблеме, что у вас возникает недоверие к своей собственной инфраструктуре. В голове постоянно крутятся мысли о том, что такая же проблема может повториться и на другом сервере.

Что такое PSOD?

PSOD расшифровывается, как Purple Screen of Diagnostics, часто называемый  Purple Screen of Death от более известного  Blue Screen of Death,  встречающегося в Microsoft Windows.

Это диагностический экран, отображаемый VMware ESXi, когда ядро ??обнаруживает фатальную ошибку, при которой оно либо не может безопасно восстановиться, либо не может продолжать работу.

Он показывает состояние памяти во время сбоя, а также дополнительные сведения, которые важны для устранения причины сбоя: версия и сборка ESXi, тип исключения, дамп регистра, обратную трассировку, время безотказной работы сервера, сообщения об ошибках и информацию о дампе ядра. (файл, созданный после ошибки, содержащий дополнительную диагностическую информацию).

Данный экран отображается в консоли сервера. Чтобы увидеть его, вам нужно будет либо находиться в центре обработки данных и подключить монитор, либо подключиться удаленно с помощью внеполосного управления сервером (iLO, iDRAC, IMM и т.д. в зависимости от вашего вендора).  

Почему появляется PSOD?

PSOD - это сбой в ядре. Все мы знаем, что ESXi не основан на UNIX, но механика сбоя соответствует определению UNIX. Ядро ESXi (vmkernel) запускает эту меру безопасности в ответ на события или ошибки, которые невозможно исправить, это будет означать, что продолжение работы может создать высокий риск для служб и виртуальных машин. Проще говоря: когда хосты ESXi чувствуют, что они повреждены, они совершают «харакири» и, истекая пурпурной кровью, пишут «предсмертную записку» с подробным описанием причин, по которым они это сделали!

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

1. Аппаратные сбои, в основном связанные с RAM или CPU. Обычно они выдают ошибку «MCE» или «NMI».

«MCE» — исключение проверки компьютера, которое представляет собой механизм в ЦП для обнаружения и сообщения о проблемах с оборудованием. В кодах, отображаемых на фиолетовом экране, есть важные детали для определения основной причины проблемы.

«NMI» — немаскируемое прерывание, то есть аппаратное прерывание, которое не может игнорироваться процессором. Поскольку NMI является очень важным сообщением об отказе HW, ответ по умолчанию, начиная с ESXi 5.0 и более поздних версий, должен запускать PSOD. Более ранние версии просто регистрировали ошибку и продолжали. Как и в случае с MCE, фиолетовый экран, вызванный NMI, предоставляет важные коды,  которые имеют решающее значение для устранения неполадок.

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

·         неверное взаимодействие между компонентами ESXi SW (см. KB2105711)

·         условия гонки (см. KB2136430 )

·         из ресурсов: память, динамическая область памяти, буфер (см. KB2034111,  KB2150280)

·         бесконечный цикл + переполнение стека (см. KB2105522 )

·         неверные или неподдерживаемые параметры конфигурации (см. KB2012125,  KB2127997)

3. Некорректно функционирующие драйвера; ошибки в драйверах, которые пытаются получить доступ к некорректному индексу или несуществующему методу (см. KB2146526,  KB2148123)

Какое влияние оказывает PSOD?

Когда возникает сбой, хост выходит из строя и завершает работу всех служб, работающих на нем, вместе со всеми размещенными виртуальными машинами. Виртуальные машины отключаются резко и не завершают свою работу корректно. Если хост является частью кластера и вы настроили HA, эти виртуальные машины будут запущены на других хостах в кластере. Помимо простоя и недоступности виртуальных машин во время их простоя, «грязное» завершение может повлиять на некоторые критически важные приложения, такие как серверы баз данных, очереди сообщений или задания резервного копирования.

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

Что делать?

1. Проанализируйте сообщение на фиолетовом экране.

Одна из самых важных вещей, которые нужно сделать при появлении фиолетового экрана - это  сделать снимок экрана. Если вы подключаетесь к консоли удаленно (IMM, iLO, iDRAC, …), будет легко сделать снимок экрана, если нет такой возможности, хотя сфотографируйте экран на телефон. На этом экране много полезной информации о причине сбоя.

2. Обратитесь в службу поддержки VMware.

Прежде чем приступить к дальнейшему исследованию и устранению неполадок, рекомендуется обратиться в службу поддержки VMware, если у вас есть контракт на поддержку. Параллельно с вашим расследованием они смогут помочь вам в проведении корневого анализа причин (RCA).

3. Перезагрузите затронутый хост ESXi.

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

4. Получите coredump

После загрузки сервера вы должны собрать дамп ядра - coredump. Coredump, также называемый vmkernel-zdump, представляет собой файл, содержащий журналы с более подробной информацией, чем та, что отображается на фиолетовом экране диагностики, и будет использоваться при дальнейшем устранении неполадок. Даже если причина сбоя может показаться очевидной из сообщения PSOD, которое вы проанализировали на шаге 1, рекомендуется подтвердить ее, просмотрев журналы из coredump.

В зависимости от вашей конфигурации у вас может быть дамп ядра в одной из следующих форм:

а. Во временном разделе

b. В виде файла .dump  в одном из хранилищ данных хоста

c. В виде файла .dump  на vCenter — через службу netdump

Coredump становится особенно важным, если конфигурация хоста должна  автоматически сбрасываться после PSOD , и в этом случае вы не увидите сообщение на экране. Вы можете скопировать файл дампа с хоста ESXi с помощью SCP, а затем открыть его с помощью текстового редактора (например, Notepad ++). Он будет вмещать содержимое памяти на момент сбоя, и первые его части будут содержать сообщения, которые вы видели на фиолетовом экране. Служба поддержки VMware может запросить весь файл, но у вас лишь будет возможность извлечь только журнал vmkernel, который более нагляден:

5. Расшифруйте ошибку.

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

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)

Поскольку сбой в ядре обрабатывается процессором, для получения дополнительной информации об этих исключениях см.  Руководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 1: Базовая архитектура  и  Руководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 3A.

Наиболее распространенные случаи описаны в отдельных статьях базы знаний VMware. Поэтому используйте эту таблицу в качестве индекса для ошибок PSOD:

6. Проверьте журналы

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

Если вы администрируете корпоративную среду, вероятно, у вас под рукой есть специализированное решение для управления журналами (например,  VMware Log Insight или SolarWinds LEM ), поэтому их будет легко просматривать, но если у вас нет управления журналами, вы можете легко  экспортировать их .

Наиболее интересные файлы журналов для изучения: