Виртуализация сети в Hyper-V. Что нового в Windows Server 2012 R2?

 

О программно-конфигурируемых или программно-определяемых сетях (Software Defined Networking, SDN) за последние полтора-два года писалось неоднократно. Технология виртуализации сети (Hyper-V Network Virtualization, HNV), впервые представленная в Windows Server 2012, является одной из реализаций подхода SDN. Об архитектуре HNV и настройке с помощью System Center 2012 Virtual Machine Manager (VMM) я рассказывал в предыдущих постах. HNV претерпела несколько изменений и усовершенствований в Windows Server 2012 R2, о которых кратко и пойдет речь сегодня.

Изменения в архитектуре HNV

Принципиальное изменение в архитектуре HNV заключается в переносе фильтра Windows Network Virtualization (WNV) внутрь расширяемого программного коммутатора Hyper-V (Hyper-V Extensible Switch). В чем важность этого изменения?

Напомню, что HNV использует инкапсуляцию пакетов для пересылки трафика между виртуальными машинами (ВМ) виртуализованной сети, расположенными на разных физических хостах. Исходный пакет с IP-адресами, принадлежащими виртуализованной сети (так называемыми CA-адресами) покидает ВМ, перехватывается WNV-фильтром и упаковывается в структуру NVGRE, которая, в свою очередь, помещается в пакет с IP-адресами, соответствующими физическому сегменту сети (PA-адресами). Далее такой пакет может беспрепятственно передаваться между хостами ЦОД-а. В сетевом стеке Windows Server 2012 упомянутый фильтр располагается между коммутатором Hyper-V и драйвером физического сетевого адаптера хоста. Как следствие, все модули расширения Hyper-V Extensible Switch, если таковые имеются, «видят» только исходные пакеты с CA-адресами, и ничего не знают о PA-адресах и вообще о том, что дальше происходит с пакетом, прежде чем он покинет хост.

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

Стоит также отметить, что если в Windows Server 2012 WNV-фильтр необходимо включать в свойствах сетевого адаптера, то в Windows Server 2012 R2 фильтр включен по умолчанию, и технология HNV готова к использованию сразу после загрузки ОС.

Отслеживание изменения IP-адреса

Еще одно важное нововведение Windows Server 2012 R2 заключается в том, что Hyper-V стал «обучаемым», то есть умеет теперь отслеживать изменения CA-адресов внутри ВМ.

И ранее, и сейчас настроить HNV можно либо скриптами PowerShell, либо с помощью VMM. В первом случае соответствующими командлетами необходимо отредактировать политику HNV и отразить в ней те CA-адреса, которые заданы внутри ВМ. В случае с VMM, как показано здесь, требуется создать пул IP-адресов для CA-пространства, после чего при создании очередной виртуальной машины VMM будет брать из этого пула свободный адрес, присваивать его создаваемой ВМ и обновлять политику HNV.

Что произойдет, если владелец ВМ изменит вручную внутри своей виртуальной машины IP-адрес? Эта ВМ не сможет более взаимодействовать с другими ВМ виртуализованной сети, поскольку в Windows Server 2012 нет механизма, который в подобной ситуации автоматически изменил бы политики HNV и отразил в них новый CA-адрес. Конечно администратор физических хостов может через PowerShell отредактировать политику HNV, но в условиях ЦОД-а такой подход представляется слабо реальным. Если же ВМ была развернута с помощью VMM, то последний и призван контролировать распределение адресов. И он это делает до тех пор, пока выданный им из пула IP-адрес остается неизменным. Но изменение IP внутри ВМ вручную приводит к тому, что VMM теряет контроль над сетевыми настройками ВМ, а с ними теряется и централизованное управление политикой HNV, ради которого поддержка HNV и была встроена в VMM.

В Windows Server 2012 R2 ситуация иная. Изменение CA-адреса внутри ВМ сразу же отражается в политике HNV хоста, на котором запущена ВМ, хост передает эти изменения VMM, а тот, в свою очередь, синхронизирует изменения с остальными хостами, на которых присутствуют ВМ из этой же виртуализованной сети.

Способность отслеживать изменения CA-адресов позволяет теперь реализовать ряд важных сценариев:

1. Поддержка кластеризации. В виртуализованной сети можно объединять ВМ в высокодоступный гостевой кластер с помощью службы failover clustering и механизма общих VHDX-файлов (Shared VHDX). Кроме того, HNV-шлюз также может быть кластеризован.

2. Использование DHCP-сервера в виртуализованной сети. Внутри ВМ можно настроить DHCP, которым буду пользоваться другие ВМ этой сети.

Поддержка широковещательного и группового трафика ( Broadcast/ Multicast)

Возможность использования DHCP в виртуализованной сети требует дополнительных пояснений, поскольку кроме «отслеживания» динамических адресов необходимо обеспечить широковещательный трафик в пределах виртуализованного сегмента. Именно виртуализованного, ведь если broadcast каждой виртуальной сети выпускать в сеть физическую, то уровень флуда в ЦОД-е будет зашкаливать.

Прежде всего для передачи broadcast/multicast трафика будет использоваться групповой IP, если таковой сконфигурирован на физическом адаптере хоста. Однако настройка multicast IP едва ли является распространенной практикой в ЦОД-ах. Соответственно, если multicast не сконфигурирован на физике, то широковещательные пакеты из виртуальной сети передаются с помощью одноадресной рассылки (unicast), причем только на те PA-адреса, где находятся ВМ, принадлежащие той же виртуальной подсети.

В качестве иллюстрации ниже в несколько упрощенном виде приведен процесс запроса и получения IP-адреса DHCP-клиентом. Синим цветом выделены PA-адреса, зеленым – CA-адреса.

Поддержка broadcast/multicast трафика также включает в себя поддержку Duplicate Address Detection (DAD), Network Unreachability Detection (NUD).

Повышение производительности

С точки зрения повышения производительности сетевых операций при использовании HNV следует отметить два момента.

Во-первых, при использовании тиминга сетевых адаптеров с динамическим режимом балансировки трафика (имеется в виду новый режим Dynamic для встроенной в ОС технологии NIC Teaming) для ВМ в виртуализованной сети обеспечивается не только отказоустойчивость на уровне сетевого адаптера, как было в Windows Server 2012, но и собственно балансировка трафика между адаптерами группы, а стало быть повышается пропускная способность сети для ВМ.

Во-вторых, на рынке начали появляться сетевые адаптеры с поддержкой NVGRE Encapsulated Task Offload. Производительность сетевых операций во многом зависит от того, используются ли аппаратные возможности сетевого адаптера, например, такие как Large Send Offload (LSO), Receive Side Scaling (RSS) или Virtual Machine Queue (VMQ). Если сетевой адаптер поддерживает перечисленные технологии, то для невиртуализованного сетевого трафика они просто работают. Применение же этих механизмов для инкапсулированных NVGRE-пакетов предполагает, что адаптер умеет анализировать CA-пакеты внутри GRE. Mellanox и Emulexобъявили о поддержке NVGRE Encapsulated Task Offload в некоторых моделях своих адаптеров. Ниже результаты тестов одного из таких адаптеров.

Диагностика и тестирование

Чем сложнее технология, тем сложнее выявлять причины возникающих проблем. По крайней мере, к HNV это относится в полной мере. А потому набор диагностических инструментов для HNV в Windows Server 2012 R2 расширен.

Microsoft Message Analyzer. Эта бесплатная утилита представляет собой сетевой (и не только) анализатор, пришедший на смену Network Monitor. Microsoft Message Analyzer распознает структуру NVGRE и позволяет легко анализировать инкапсулированные пакеты, включая CA-адреса. Замечу, что данный анализатор обеспечивает перехват не только сетевого трафика, но и с помощью Event Tracing for Windows (ETW) системных и других сообщений на удаленных хостах с Windows 8.1 и Windows Server 2012 R2.

На рисунке показан перехват ping-ов между двумя ВМ с CA-адресами 10.30.1.104 и 10.30.1.101 и PA-адресами 192.168.100.104 и 192.168.100.104.

Выделив GRE-пакет, можно увидеть поле, содержащее идентификатор виртуальной подсети (Virtual Subnet ID, VSID).

Ping. В утилите ping появился новый ключ «-p», который позволяет пропинговать хост по PA-адресу. Как правило PA-пространство задается в виде отдельной логической сети VMM, отличной от адресов, используемых для управления хостами виртуализации, да и любых других адресов.

В этом случае PA-адреса не отображаются в отклике ipconfig /all и не пингуются «обычным» пингом. Ключ «-p» решает эту проблему и позволяет проверить связь между хостами в PA-пространстве.

Test-VMNetworkAdapter. Для крупного ЦОД-а типичной является ситуация, когда администратор ЦОД-а не имеет доступа к гостевой ОС внутри ВМ. Если возникает проблема на уровне сетевого взаимодействия, то проверить прохождение пактов в PA-пространстве администратор ЦОД-а еще может, а вот настройки CA-пространства ему могут быть недоступны. Помочь может командлет Test-VMNetworkAdapter. По сути этот командлет реализует пинг между двумя ВМ, причем пинг с одного CA-адреса на другой CA-адрес. (Администратор может не иметь возможности поменять CA-адреса внутри ВМ, но увидеть эти адреса в консоли VMM или Hyper-V можно, «не залезая» внутрь ВМ). С помощью командлета необходимо указать, какая ВМ является получателем, какая отправителем пакетов, каковы адреса отправителя и получателя, номер последовательности и MAC-адрес получателя.

Test-VMNetworkAdapter -VMName Fabrikam_SRV02 -Receiver -ReceiverIPAddress 10.30.1.107 -SenderIPAddress 10.30.1.108 -SequenceNumber 102

Test-VMNetworkAdapter -VMName Fabrikam_SRV03 -Sender -ReceiverIPAddress 10.30.1.107 -SenderIPAddress 10.30.1.108 -SequenceNumber 102 -NextHopMacAddress 00-1d-d8-b7-1c-0c

Отклик, вроде изображенного ниже, говорит о том, что сетевое взаимодействие между ВМ происходит нормально, включая упаковку и распаковку CA-пакетов в PA-пакеты и обратно. А стало быть, с большой вероятностью проблемы следует искать уже внутри ВМ (правила firewall, запуск сервисов и пр.)

HNV- шлюз

Для того, чтобы ВМ виртуализованной сети могли взаимодействовать с внешним миром, необходимо настроить HNV-шлюз. Windows Server 2012 R2 может выступать в качестве такого шлюза что называется «из коробки». То есть все необходимые сервисы и компоненты для реализации функции шлюза Network Virtualization есть в составе новой серверной ОС, надо только их настроить. Как это делается, каковы возможности такого шлюза – тема отдельного поста, который я надеюсь в ближайшее время опубликовать.

Итак, реализация концепции SDN в Windows Server 2012 R2 получила свое дальнейшее развитие. Изменения направлены на повышение гибкости и производительности решения. Дополнительные инструменты диагностики помогут эффективнее обнаруживать и устранять возможные проблемы, а наличие встроенного шлюза и его поддержка в VMM 2012 R2 ускорят развертывание виртуализованных сетей в масштабах ЦОД.

Дополнительную информацию можно найти во втором модуле курса «Все о System Center 2012 R2 (Jump Start)» на обучающем портале MVA.

Надеюсь, материал был полезен.

Спасибо!

Comments

• Anonymous
  January 01, 2003
  Да, в работе
• Anonymous
  January 01, 2003
  Саша, есть понимание того, что нужно описать HNV Gateway более подробно, отдельной статьей.
• Anonymous
  January 01, 2003
  Будет? -)