Мир пошел не так: использование журналов событий для устранения неполадок Hyper-V

Журналы событий в Windows Server — это одно из первых мест, куда следует заглянуть, если что-то пойдет не так. Однако навигация по ним может быть сложной по нескольким причинам. Во-первых, в Windows Server существует множество различных каналов событий, и отображаемые каналы будут зависеть не только от того, какие серверные роли и функции вы установили, но и от того, с какой версией Windows Server вы работаете. Во-вторых, имена, которые Microsoft дает каналам событий, часто загадочны и необычны. В-третьих, административная консоль Event Viewer несколько неуклюжа в работе, поэтому для захвата и анализа событий лучше использовать Windows PowerShell. Это означает, конечно, что вам потребуются определенные навыки работы с PowerShell для эффективной работы с журналами событий. И наконец, в-четвертых, онлайн-документация Microsoft по каналам журналов событий для Windows Server, мягко говоря, отсутствует. В этой статье рассматриваются некоторые каналы событий, которые вы, возможно, захотите использовать при устранении неполадок узлов Hyper-V и виртуальных машин, работающих на этих узлах. В следующей статье мы рассмотрим, как можно использовать PowerShell для получения событий из журналов событий и извлечения из них полезной информации.

Каналы событий Hyper-V

Когда какое-либо событие происходит в системе Windows Server, такой как узел Hyper-V, например, когда виртуальная машина выключается на узле, событие записывается в соответствующий канал журнала событий. По сути, вы можете представить канал журнала событий как своего рода приемник, который улавливает определенные виды событий, происходящих в системе. Затем захваченные события можно прочитать с помощью средства сбора журнала событий, например встроенного средства просмотра событий. Перехваченные события также можно собирать и анализировать с помощью таких командлетов Windows PowerShell, как Get-EventLog и Get-WinEvent.

Hyper-V, конечно же, является технологией гипервизора, обеспечивающей возможности виртуализации на платформе Windows Server. Hyper-V впервые был представлен в Windows Server 2008, но с годами он был дополнен дополнительными функциями, поскольку сама платформа Windows Server продолжала развиваться. По мере добавления новых возможностей в Hyper-V в Windows Server 2012, Windows Server 2012 R2 и Windows Server 2016 произошли соответствующие изменения в определении каналов журнала событий на этих платформах. В следующей таблице перечислены доступные каналы для Hyper-V в каждой версии Windows Server, насколько мне удалось определить на основе ограниченного объема документации, предоставляемой Microsoft:

Обратите внимание, что некоторые из этих каналов событий могут отсутствовать на вашем хосте, если не включены определенные функции. Например, для канала событий Hyper-V High-Availability требуется, чтобы на узле была установлена функция отказоустойчивой кластеризации. Также обратите внимание, что определенные типы журналов событий присутствуют в канале только в том случае, если они были включены. Аналитика и отладка — это два типа журналов такого рода. Краткое, но полезное объяснение того, какие типы событий регистрируются некоторыми из этих различных каналов событий, можно найти в этой публикации Ларса Ивера в блоге Microsoft Virtualization.

Обратите внимание, что журналы событий также входят в различные типы каналов, такие как административный, аналитический, отладочный, диагностический, операционный, сетевой, резервирование и хранилище. Например, на рисунке ниже показаны четыре типа журналов событий в канале событий Hyper-V-VMMS. Также обратите внимание, что некоторые из этих типов каналов собираются только после того, как администратор включил ведение журнала для этого конкретного типа канала.

Использование журналов событий Hyper-V для устранения неполадок

Помимо журнала системных событий, канал журнала событий Hyper-V-VMMS, вероятно, является тем местом, с которого вы чаще всего хотите начинать при устранении неполадок. Это связано с тем, что служба управления виртуальными машинами (VMMS) на узле Hyper-V управляет многими ключевыми функциями таких узлов и виртуальных машин, работающих на этих узлах. Например, когда инициируется динамическая миграция, в журнале Hyper-V-VMMS-Admin будет зарегистрировано событие (информация сокращена), подобное следующему:

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

Затем журнал Hyper-V-VMMS-Admin, скорее всего, покажет некоторые дополнительные события, подобные этим:

Эти события, записанные в журнале событий Hyper-V-VMMS-Admin, позволяют предположить, что какая-то сетевая проблема вызвала сбой динамической миграции на узлах Hyper-V. На этом этапе нам нужно приступить к устранению неполадок сетевого подключения между двумя хостами Hyper-V, участвующими в динамической миграции, чтобы попытаться выяснить, что может быть не так. Для этого можно начать с обычных инструментов, таких как ping, но это также может быть аппаратная проблема, связанная с сетевой картой на одном из хостов, или это может быть неправильная настройка некоторых дополнительных сетевых настроек на одной из сетевых карт. Конечно, существует миллион вещей, которые могут пойти не так, когда дело доходит до обеспечения сетевого подключения, но это уже другая история.

Вот еще один пример использования журнала событий Hyper-V-VMMS-Admin для устранения неполадок с узлами Hyper-V. Администратор наблюдал следующее событие ошибки (информация была сокращена), которое повторялось каждые 10 минут на его кластеризованных хостах Hyper-V:

Мероприятие также включало следующую информацию:

Администратор был озадачен ссылкой на «том 4», поскольку этого конкретного тома CSV не существовало в его хост-кластере Hyper-V. Быстрый поиск в Интернете по коду ошибки может «0x80070002» предположить, что проблема как-то связана с Центром обновления Windows, но это несколько вводит в заблуждение. Вместо этого оказалось, что проблема связана с Hyper-V Replica Broker. Выяснилось, что администратор переименовал все тома CSV в кластере, чтобы придерживаться их существующей номенклатуры, но конфигурация брокера по-прежнему указывала на старый том. Как только он обновил путь в брокере, чтобы он указывал на новое имя для CSV, ошибки для события с идентификатором 29120 перестали регистрироваться в журнале событий Hyper-V-VMMS-Admin. Это иллюстрирует важность понимания того, как недавние изменения, которые вы могли внести в конфигурацию ваших хостов Hyper-V, могут привести к непредвиденным ошибкам, возникающим, если вы неправильно изменили параметр или забыли внести требуемое изменение в какой-либо параметр.

Хорошее понимание архитектуры Hyper-V и того, как ее различные компоненты взаимодействуют и работают вместе, также может быть полезным при устранении неполадок с хостами Hyper-V. Хороший пример того, как такие знания можно использовать при возникновении проблемы, можно найти в этом посте Эйдана Финна о том, как понимать сообщения об ошибках Hyper-V. Эйдан является самым ценным профессионалом Microsoft, который регулярно пишет в блогах о решениях Microsoft для инфраструктуры, и если в вашей среде развернут Hyper-V, я настоятельно рекомендую администраторам Hyper-V следить за действиями Айдана в блогах.