Фиолетовый экран смерти (PSOD) – что с этим делать

This article is available in the following languages:

‍

‍‍‍

‍

Содержание

Что такое PSOD? 

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

Какое влияние?

Что делать, когда это случится?

Как предотвратить это?

TL;DR

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

Используйте Runecast Analyzer (бесплатная пробная версия), чтобы проверить, не подвержены ли ваши хосты угрозам, которые могут привести к фиолетовому экрану смерти VMware. 

Что такое PSOD

PSOD (Purple Screen of Death) означает Фиолетовый Экран Диагностики, часто называемый Фиолетовым Экраном Смерти (происходит от более широко известного Голубого Экрана Смерти, иногда встречающегося в Microsoft Windows).

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

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

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

А ВЫ ЗНАЛИ?

Экран называется либо фиолетовый или розовый, но на самом деле цвет - темно-пурпурный (RGB:171,0,171 | CMYK:0.00, 1.00, 0.00, 0.33).

Причины PSOD 

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

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

1. Аппаратные сбои, в основном, связанные с оперативной памятью или процессором. Обычно они выбрасывают ошибку "MCE" или "NMI". 

• "MCE" - Machine Check Exception (Исключение проверки машины), которое представляет собой механизм внутри процессора для обнаружения и сообщения о проблемах с оборудованием. Существуют важные детали для определения первопричины проблемы в кодах, отображаемых на фиолетовом экране. 
• "NMI" - немаскируемое прерывание, представляющее собой аппаратное прерывание, которое не может быть проигнорировано процессором. Поскольку NMI является очень важным сообщением о сбое HW, ответ по умолчанию, начинающийся с ESXi 5.0 и более поздних версий, должен вызывать PSOD. Более ранние версии просто регистрировали ошибку и продолжали ее регистрировать. Как и в случае с MCE, фиолетовый экран, вызванный NMI, предоставляет важные коды, которые очень важны для поиска и устранения неисправностей.

2. Ошибки программного обеспечения

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

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

А ВЫ ЗНАЛИ?

В целях тестирования или если вам просто любопытно, вы можете вручную запустить PSOD.

Войдите на хост ESXi через DCUI или SSH с привилегированной учетной записью и запустите:

vsish -e set /rereliability/crashMe/Panic

Мы рекомендуем делать это только на тестовой системе и только после того, как полностью прочитаете эту статью.

Последствия PSOD

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

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

Для меня самым проблемным аспектом PSOD является то, что вы теряете доверие к своей инфраструктуре. Вы можете восстановиться путем перезагрузки, и у вас может быть HA или даже FT, так что воздействие может не быть разрушительным... но пока вы не решите первопричину, мысль о том, что это может случиться снова или на другом сервере, не будет давать вам покоя.

Что делать при PSOD

1. Проанализировать сообщение об ошибке

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

2. Связаться со службой поддержки VMware

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

3. Перезагрузите пострадавший хост ESXi.

Для восстановления сервера необходимо его перезагрузить. Также я бы посоветовал держать его в режиме обслуживания до тех пор, пока вы не выполните полный RCA, не определите причину и не исправите ее. Если вы не можете позволить себе держать его в режиме обслуживания, по крайней мере, отрегулируйте свои DRS правила так, чтобы на нем работали только неважные ВМ, так что в случае попадания еще одного PSOD воздействие будет минимальным.

4. Забрать базу данных ядра

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

В зависимости от конфигурации, дамп ядра будет в одной из этих форм:

a. На царапиной перегородке 

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

c. Как файл .dump на vCenter - через сервис netdump

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

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

5. Расшифровать ошибку

Поиск и устранение неисправностей и анализ корневой причины могут заставить почувствовать себя Шерлоком Холмсом. Иногда PSOD могут превратиться в историю, вдохновленную Артуром Конан Дойлом, но в большинстве случаев это довольно простой процесс.

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

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

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

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

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

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

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

Как предотвратить PSOD

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

Убедитесь, что ваши серверы находятся в списке VMware Hardware Compatibility Checklist вместе со всеми устройствами и адаптерами. Это защитит вас от некоторых неожиданных проблем, связанных с аппаратным обеспечением, а также обеспечит поддержку VMware в случае PSOD.

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

Runecast регулярно анализирует всю базу знаний VMware (kb.vmware.com), которая состоит из более чем 30 000 статей. Мы извлекаем полезные сведения из KB, чтобы сделать виртуализированные инфраструктуры более устойчивыми, безопасными и эффективными. Мы хорошо знакомы с PSOD и можем определить большинство предварительных условий, которые могут привести к этой проблеме. Проактивно анализируя вашу среду, Runecast Analyzer поможет вам избежать этих проблем, чтобы вы могли быть уверены, что большинство PSOD, скрывающихся в вашем окружении, предотвращено.

>> Скачать бесплатную пробную версию Runecast Analyzer.

‍

‍

‍‍‍