Устранение сбоев виртуальных машин

Остановить экраны

Поскольку все больше и больше организаций переносят свои физические серверы на виртуальные машины, проблемы, связанные с физическими серверами, становятся все более распространенными в корпоративных средах. Например, в старые времена (которые на самом деле были всего несколько лет назад) системным администраторам иногда приходилось бороться с физическими сбоями серверов с пресловутым синим экраном смерти (BSOD). Этот синий экран, также известный как , предоставляет лишь минимальную информацию о том, что могло вызвать проблему, но в некоторых случаях его может быть достаточно, чтобы помочь вам определить причину сбоя. Если ваш сервер (физический или виртуальный) работает под управлением Windows Server 2008 или Windows Server 2008 R2, хорошим источником информации о том, как устранять BSOD, является Глава 32. информация в этой главе по-прежнему актуальна для Windows Server 2012 и Windows Server 2012 R2.

Дампы памяти

Что делать, если информации на экране остановки недостаточно, чтобы помочь вам устранить причину сбоя вашей виртуальной машины? Или что, если ваш сервер просто зависнет и перестанет отвечать? В этом случае вы по-прежнему можете видеть пользовательский интерфейс рабочего стола операционной системы Windows Server, но нажатие клавиш или перемещение мыши не вызывает никакой реакции (рабочий стол завис). В таких случаях вам понадобится , который в основном представляет собой двоичный файл, содержащий содержимое части памяти вашего сервера на момент его сбоя. Windows Server 2008 и Windows Server 2008 R2 предоставляют четыре варианта настройки дампов памяти:

• Нет — при сбое сервера дамп памяти не создается.
• Ядро — сбрасывается только память ядра.
• Небольшой — также известный как мини-дамп, этот дамп памяти содержит наименьший набор информации, которая может быть полезна для выявления проблемы.
• Завершено — все содержимое системной памяти сбрасывается.

Полные дампы памяти могут быть огромными и требуют, чтобы размер файла подкачки был как минимум на 1 МБ больше, чем объем памяти на сервере. Полные дампы всегда называются Memory.dmp и находятся в папке %SystemRoot%, и каждый новый полный дамп перезаписывает любой предыдущий полный дамп. Дампы памяти ядра также называются MEMORY.dmp и также находятся в %SystemRoot%.

На другом конце спектра находится небольшой дамп памяти, и каждый раз, когда возникает небольшой дамп, в вашей системе в папке %SystemRoot%Minidump создается новый файл с закодированным по времени именем вида MiniMMDDYY-NN.dmp.. Дополнительную информацию об этих различных типах дампов памяти можно найти по адресу http://support.microsoft.com/kb/254649.

Обратите внимание, что в Windows Server 2012 появился новый тип дампа памяти, называемый автоматическим, как показано здесь:

Рисунок 1: Новая опция дампа памяти в Windows Server 2012.

Однако оказывается, что эта новая опция действительно создает только дамп ядра, но занимает меньше места, чем в предыдущих версиях Windows Server. Дополнительные сведения об этой новой опции см. на странице http://blogs.technet.com/b/askcore/archive/2012/09/12/windows-8-and-windows-server-2012-automatic-memory-dump.aspx..

Проверьте сервер

Если операционная система Windows Server на вашем сервере зависает и перестает реагировать на действия пользователя, вы можете попытаться принудительно . Это намеренно приводит к сбою системы, который создает файл *.dmp в вашей папке %SystemRoot% или в ее папке минидампа в зависимости от типа дампа памяти, который вы настроили на сервере. Однако, прежде чем сделать это, убедитесь, что ваш сервер настроен на создание полного дампа памяти или дампа ядра (автоматического), так как объем информации в небольшом дампе часто недостаточен для выявления причины сбоя системы (и обязательно перезагрузите компьютер). ваш сервер после внесения такого изменения). Также убедитесь, что на вашем сервере достаточно свободного места на диске для создания файла дампа памяти, либо освободив место на существующих дисках, либо добавив дополнительный диск (или VHD/VHDX, если сервер является виртуальной машиной) для хранения файл дампа памяти.

Если проблема воспроизводима (то есть, если вы можете постоянно переводить свой сервер в неотвечающее состояние, выполняя на нем определенные действия), вы можете отредактировать реестр, чтобы разрешить вам вручную аварийно завершать работу сервера с клавиатуры. Соответствующий раздел реестра, который необходимо создать, имеет имя CrashOnCtrlScroll и тип REG_DWORD, и ему следует настроить значение 0x01. Для клавиатуры в стиле PS/2 вы создаете этот раздел реестра здесь:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesi8042prtParameters

Однако для USB-клавиатуры вам необходимо создать ее здесь:

HKEY_LOCAL_MACHINESystemCurrentControlSetServiceskbdhidParameters

После создания соответствующего раздела реестра и присвоения ему значения 0x01 теперь вы можете вручную завершить работу сервера, удерживая нажатой правую клавишу CTRL и дважды нажимая клавишу ScrLk (Scroll Lock). Происходит проверка (сбой) и на диск записывается дамп памяти.

Однако если ваш сервер представляет собой виртуальную машину поколения 2, работающую на узле Windows Server 2012 R2 Hyper-V, вместо этого вам потребуется создать раздел реестра CrashOnCtrlScroll в гостевой операционной системе в этом месте:

HKEY_LOCAL_MACHINESystemCurrentControlSetServiceshyperkbdParameters

В любом случае обязательно перезагрузите гостевую операционную систему вашей виртуальной машины после того, как вы внесли какие-либо из вышеуказанных изменений в реестр, чтобы они вступили в силу.

НМИ

Если описанный выше метод CTRL+ScrLk+ScrLk по какой-либо причине не работает, вы можете использовать переключатель немаскируемого прерывания (NMI), который вызывает NMI на системном процессоре, если эта функция доступна в вашей серверной системе.. Дополнительные сведения об этом см. на странице http://support.microsoft.com/kb/927069.

Debug-VM

Если ваша виртуальная машина работает под управлением Windows Server 2012 R2, вы можете использовать новый командлет Debug-VM Windows PowerShell для проверки виртуальной машины на наличие ошибок и создания файла дампа. Этот командлет внедряет немаскируемое прерывание (NMI) в виртуальную машину гостевой операционной системы, что приводит к проверке операционной системы на наличие ошибок. Синтаксис и примеры использования этого командлета см. на странице http://technet.microsoft.com/en-us/library/dn464280.aspx.

ВМ2ДМП

Если ваша виртуальная машина работает на хосте Windows Server 2008 или Windows Server 2008 R2 Hyper-V, вы можете использовать инструмент Hyper-V VM State to Memory Dump Converter (VM2DMP) для выполнения полного дампа памяти, даже если другой (или нет) опция дампа памяти настроена в гостевой операционной системе. Вы просто сохраняете состояние своей не отвечающей виртуальной машины, получаете VM2DMP и следуете инструкциям на странице http://blogs.technet.com/b/virtualworld/archive/2010/02/02/vm2dmp-hyper-v-tm-vm. -state-to-memory-dump-converter.aspx.

Однако есть одна проблема: в приведенном выше сообщении в блоге говорится, что вы можете получить VM2DMP из галереи архивов MSDN по адресу http://code.msdn.microsoft.com/vm2dmp, но он больше не доступен там, потому что он никогда не был поддерживаемым инструментом.. Поэтому, если вам это нужно, вам придется либо получить его от надежного коллеги, либо загрузить его из надежного стороннего источника. К сожалению, я не могу рекомендовать сторонние источники, так что здесь вы сами.

Другая проблема заключается в том, что VM2DMP несовместим с форматом сохраненного состояния, используемым Windows Server 2012 или более поздней версии Hyper-V, что приводит нас к следующему разделу.

LiveKd

Если ваша виртуальная машина работает под управлением Windows Server 2012 или более поздней версии или если она работает под управлением более ранней версии Windows Server и у вас нет доступа к утилите VM2DMP, вы можете использовать LiveKd, утилиту Windows Sysinternals, для запуска инструментов отладки Windows. (Kd и Windbg) на вашем хосте Hyper-V и используйте его для создания дампа памяти вашей виртуальной машины. Однако у этого подхода есть несколько недостатков:

• Вам нужно будет понять, как использовать инструменты отладки Windows. Это не тривиально, но вы можете найти множество полезных сообщений, подобных этому, в различных блогах TechNet, которые помогут вам начать работу. Также обязательно ознакомьтесь с этим постом в блоге Марка Руссиновича. Дополнительную информацию по этой теме см. в разделе «Анализ ошибок Windows» на вики-сайте TechNet по адресу http://social.technet.microsoft.com/wiki/contents/articles/6302.windows-bugcheck-analysis.aspx.
• Вам может потребоваться приостановить виртуальную машину, чтобы записать файл дампа памяти, и это может привести к некоторым изменениям в состоянии памяти не отвечающей виртуальной машины. Однако рекомендуется приостановить виртуальную машину, прежде чем использовать инструменты отладки для создания дампа памяти, потому что, если вы не приостановите виртуальную машину, результирующий файл дампа может оказаться несогласованным.
• Создание файла дампа памяти может занять много времени (возможно, часы) в зависимости от размера и конфигурации памяти виртуальной машины.

Что делать дальше

Допустим, у вас есть файл дампа памяти с вашей виртуальной машины, которая потерпела крах. Что вы можете сделать дальше, чтобы устранить проблему? В основном у вас есть два варианта:

• Заархивируйте файл дампа, загрузите его в OneDrive или другое общедоступное облачное хранилище, позвоните в службу поддержки Microsoft и попросите их просмотреть его и сказать, что могло пойти не так.
• Станьте экспертом в интерпретации дампов памяти.

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

Последнее слово

Возможно, в этой области VMware все еще имеет преимущество над Hyper-V, потому что они выпустили инструмент, который можно использовать для преобразования моментального снимка виртуальной машины, работающей на хосте ESX, в файл.dmp, который затем можно анализировать стандартными средствами отладки Windows. Этот инструмент называется Checkpoint To Core Tool (vmss2core). Дополнительную информацию о нем можно найти по адресу http://www.vmware.com/pdf/snapshot2core_technote.pdf, а также загрузить инструмент с веб-сайта VMware Labs по адресу https://. labs.vmware.com/flings/vmss2core.

Я считаю, что конкуренция — это, в конце концов, хорошо. Давайте посмотрим, выпустит ли Microsoft инструмент, превосходящий этот.