Устранение неполадок виртуализации сети Hyper-V (часть 1)

• Устранение неполадок виртуализации сети Hyper-V (часть 3)

Устранение неполадок любого технологического компонента – непростая задача. Вы должны убедиться, что хорошо разбираетесь в технологии, прежде чем приступать к устранению неполадок. Виртуализация сети Hyper-V, иногда называемая HNV, — это технология, в основном предназначенная для провайдеров облачного хостинга. Поставщики облачного хостинга поддерживают виртуализированные рабочие нагрузки для клиентов и должны убедиться, что виртуальные машины работают правильно. В случае возникновения каких-либо проблем провайдерам облачного хостинга необходимо устранять неполадки и запускать службы с минимальным временем простоя.

В сценарии размещенного аварийного восстановления, когда виртуальные машины клиента хранятся в обоих местах; удаленно и локально, становится необходимым, чтобы клиенты сами устраняли неполадки в своих компонентах. В этой статье описывается сценарий, в котором виртуальные машины клиента расположены в общем облаке IaaS, и поставщику облачного хостинга необходимо устранять неполадки компонентов сетевой виртуализации Hyper-V.

Существует два подхода к устранению неполадок, которым может следовать виртуальный администратор при устранении неполадок компонентов сетевой виртуализации Hyper-v; 1) проверка конфигурации виртуализации сети Hyper-V на всех узлах Hyper-V и 2) включение трассировки компонентов виртуализации сети. Первый подход к устранению неполадок объясняет несколько основных шагов, которые можно выполнить, чтобы выяснить проблемы с конфигурацией HNV. Второй подход к устранению неполадок является более сложным и может использоваться, если с конфигурацией HNV все в порядке. Мы узнаем, как проверить конфигурацию виртуализации сети Hyper-V на узлах Hyper-V с помощью командлетов PowerShell и как включение трассировки компонентов виртуализации сети поможет вам выявить основную причину, которая будет объяснена в следующей части этой серии статей.

Прежде чем приступить к устранению неполадок, давайте воспользуемся схемой виртуализации сети Hyper-V, которая будет использоваться в этой серии статей для устранения неполадок. Как показано на рисунке 1.0 ниже, на двух хостах Hyper-V (HVHOSTA и HVHOSTB) работают четыре виртуальные машины. Предположим, что синие виртуальные машины принадлежат Заказчику-А, а зеленые виртуальные машины принадлежат Заказчику-Б.

Рисунок 1.0: Проект виртуализации сети Hyper-V с двумя виртуальными машинами заказчика

VSID 5001 назначается VM1 и VM3, и эти виртуальные машины принадлежат виртуальной подсети 10.0.0.0/24. ВМ2 и ВМ4 назначаются с VSID 5002. Эти виртуальные машины принадлежат другой виртуальной подсети 10.0.1.0/24. Адрес провайдера (PA) 192.168.10.67 управляет виртуальными машинами, работающими на HVHOSTA, а PA 192.168.10.68 управляет виртуальными машинами, работающими на HVHOSTB.

Кончик:
PA отвечает за взаимодействие между виртуальными машинами, расположенными на локальных или удаленных серверах Hyper-V.

Как показано на рисунке 1.0 выше, VM1 и VM3 должны иметь возможность взаимодействовать друг с другом, но каким-то образом связь между этими двумя виртуальными машинами прерывается, и вам необходимо диагностировать проблемы и устранять их. Для целей этой серии статей мы будем устранять проблемы со связью между VM1 и VM3.

1. Проверка конфигурации виртуализации сети Hyper-V на всех узлах Hyper-V

Ваша первая задача — проверить конфигурацию HNV на обоих хостах Hyper-V. Конфигурацию виртуализации сети Hyper-V можно проверить с помощью SCVMM (System Center Virtual Machine Manager) или командлетов HNV PowerShell. Поскольку SCVMM использует командлеты PowerShell для создания записей конфигурации для виртуализации сети Hyper-V, легко проверить конфигурацию HNV с помощью командлетов PowerShell. Чтобы убедиться, что виртуализация сети Hyper-V настроена правильно, вы можете использовать приведенные ниже командлеты PowerShell, которые кратко объясняются.

• Get-NetVirtualizationCustomerRoute
• Get-NetVirtualizationProviderAddress
• Get-VMNetworkAdapter
• Get-Нетвиртуализатионлукупрекорд

Прежде чем приступить к проверке конфигурации HNV на всех узлах Hyper-V, рекомендуется проверить, какой метод развертывания был выбран для реализации параметров политики виртуализации сети Hyper-V. Существует два способа реализации виртуализации сети Hyper-V; с помощью SCVMM или командлетов PowerShell виртуализации сети. Небольшой поставщик облачного хостинга будет использовать командлеты PowerShell для реализации политик виртуализации сети для виртуальных машин клиента. Следует иметь в виду, что в случае использования командлетов PowerShell для реализации HNV конфигурация теряется при перезагрузке сервера Hyper-V.

Запуск командлета PowerShell на узле Hyper-V сообщит вам, настроена ли у вас какая-либо запись политики или нет. Если выходные данные пусты или ничего не возвращается, необходимо перестроить виртуализацию сети Hyper-V с помощью командлетов PowerShell, если вы не использовали метод развертывания SCVMM. Многие виртуальные администраторы разрабатывают сценарии PowerShell и запускают их для восстановления конфигурации виртуализации сети Hyper-V на всех узлах Hyper-V, когда это необходимо. В соответствии с рекомендациями вы должны убедиться, что сценарии PowerShell создаются и выполняются после перезапуска серверов Hyper-V. Это гарантирует перестройку конфигурации виртуализации сети после перезапуска сервера.

Если вы использовали метод развертывания SCVMM для реализации виртуализации сети Hyper-V, может быть несколько причин, по которым VM1 не может обмениваться данными с VM3 на HVHOSTB, как описано ниже:

• Виртуальные машины не назначены или назначены с неправильным идентификатором виртуальной подсети (VSID)

Виртуальной машине, участвующей в виртуализации сети Hyper-V, должен быть назначен идентификатор виртуальной подсети (VSID). Виртуальная машина не участвует в виртуализации сети Hyper-V, если VSID не назначен. Чтобы получить список VSID, назначенных VM1 и VM3, выполните приведенные ниже команды PowerShell на узлах HVHOSTA и HVHOSTB:

• Get-VMNetworkAdapter | FT VMName, VirtualSubnetID - AutoSize

Как показано в приведенном выше выводе, VM1 назначается правильный VSID (5001), что абсолютно нормально. Если выходные данные возвращают неправильный VSID для VM1, используйте команду чтобы назначить правильный VSID для VM1.

Выполните ту же команду на HVHOSTB, чтобы убедиться, что VM3 назначен с тем же VSID (5001). Вывод должен быть аналогичен приведенному ниже для HVHOSTB:

• Записи поиска неверны для VM1 и VM3

Запись поиска — это то, что модуль WNV использует для обращения к виртуальным машинам, расположенным на локальных или удаленных серверах Hyper-V. Записи поиска создаются с помощью командлета PowerShell . Каждая запись поиска создается с адресом поставщика, который сообщает каждому узлу Hyper-V, куда отправлять трафик для каждой виртуальной машины, участвующей в виртуализации сети Hyper-V. Запись поиска выглядит следующим образом:

Кончик:
Записи поиска создаются для каждой виртуальной машины, участвующей в виртуализации сети Hyper-V, и должны быть заполнены на всех узлах Hyper-V, на которых размещены виртуальные машины клиента.

Чтобы проверить записи поиска на HVHOSTA и HVHOSTB, выполните следующую команду на обоих хостах Hyper-V:

• Get-NetVirtualizationLookupRecord | FT VMName, MACAddress, VirtualSubnetID, CustomerAddress, ProviderAddress — AutoSize

Команда должна вернуть приведенный ниже вывод на обоих хостах Hyper-V:

Поскольку мы устраняем проблемы со связью между VM1 и VM3, обязательно проверьте следующие элементы для VM1 и VM3 в приведенном выше выводе на обоих узлах Hyper-V.

1. MAC-адреса для обеих виртуальных машин правильные. MAC-адреса могут назначаться статически или динамически. Внимательно изучите эту часть, чтобы убедиться, что MAC-адреса указаны правильно для обеих виртуальных машин. Поскольку SCVMM гарантирует, что каждой виртуальной машине назначается уникальный MAC-адрес, на это не нужно обращать внимание, если конфигурация HNV развернута через SCVMM.
2. Идентификаторы VirtualSubnetID, назначенные VM1 и VM3, верны. VM1 и VM3 должны быть назначены с VSID 5001, который соответствует выходным данным, показанным выше. Совет:
   Крайне важно понимать, что записи поиска также создаются с правильным VSID виртуальной машины, что полностью отличается от назначения VSID виртуальной машине.
3. Адреса провайдеров, назначенные VM1 и VM3, верны. Для VM1 PA должен быть 192.168.10.67, а для VM3 PA должен быть 192.168.10.68. Согласно выходным данным выше, VM1 и VM3 назначаются правильным адресам провайдеров.

Если вы обнаружите какие-либо проблемы с приведенным выше выводом, повторно заполните записи поиска на обоих узлах Hyper-V с помощью командлета PowerShell .

Резюме

В первой части этой серии статей были рассмотрены два подхода, которые можно использовать для устранения неполадок с виртуализацией сети Hyper-V. Первый подход заключается в проверке конфигурации виртуализации сети Hyper-V на всех узлах Hyper-V с помощью командлетов PowerShell, а второй подход может использоваться для выявления проблем путем включения трассировки компонентов виртуализации. В этой статье мы также узнали, что конфигурация виртуализации сети Hyper-V теряется при перезапуске сервера Hyper-V, если конфигурация HNV реализована вручную с помощью командлетов PowerShell.

В следующей части этой серии статей мы продолжим фокусироваться на других возможностях, которые могут вызвать сбои связи между VM1 и VM3, а также коснемся второго подхода, который заключается в том, чтобы включить трассировку компонентов виртуализации, чтобы добраться до основной причины.

• Устранение неполадок виртуализации сети Hyper-V (часть 3)