Технические сведения о виртуализации сети Hyper-V в Windows Server

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, версии 21H2 и 20H2

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

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

Рисунок 1. Виртуализация серверов в сравнении с виртуализацией сетей

Концепции виртуализации сетей Hyper-V

В Виртуализации сети Hyper-V (HNV) клиент или клиент определяется как владелец набора IP-подсетей, развернутых в корпоративном или центре обработки данных. Клиент может быть корпорацией или предприятием с несколькими подразделениями или подразделениями в частном центре обработки данных, для которых требуется сетевая изоляция, или клиент в общедоступном центре обработки данных, размещенном поставщиком услуг. Каждый клиент может иметь одну или несколько виртуальных сетей в центре обработки данных, а каждая виртуальная сеть состоит из одной или нескольких виртуальных подсетей.

Существует две реализации HNV, которые будут доступны в Windows Server 2016: HNVv1 и HNVv2.

• HNVv1

  HNVv1 совместим с Windows Server 2012 R2 и System Center 2012 R2 диспетчер виртуальных машин (VMM). Конфигурация для HNVv1 зависит от управления WMI и командлетов Windows PowerShell (облегченных с помощью System Center VMM) для определения параметров изоляции и параметров изоляции (ЦС) — виртуальной сети — сопоставлений и маршрутизации физических адресов (PA). В Windows Server 2016 никакие дополнительные функции не были добавлены в HNVv1, и новые функции не планируется.

  • Set Teaming и HNV V1 несовместимы с платформой.

  Для использования шлюзов NVGRE высокой доступности пользователям необходимо либо использовать команду LBFO, либо команду No. Or

  o Использование развернутых шлюзов сетевого контроллера с командным коммутатором SET.

• HNVv2

  В HNVv2 реализовано значительное количество новых функций, реализованных с помощью расширения пересылки виртуальной платформы фильтрации Azure (VFP) в коммутаторе Hyper-V. HNVv2 полностью интегрирован с Microsoft Azure Stack, который включает новый сетевой контроллер в стеке программно-определяемых сетей (SDN). Политика виртуальной сети определяется через сетевой контроллер Майкрософт с помощью API RESTful NorthBound (NB) и подключен к агенту узла через несколько интерфейсов SouthBound (SBI), включая OVSDB. Политика агента узла в расширении VFP коммутатора Hyper-V, в котором она применяется.

  Внимание

  В этом разделе рассматривается HNVv2.

Виртуальная сеть

• Каждая виртуальная сеть состоит из одной или нескольких виртуальных подсетей. Виртуальная сеть формирует границу изоляции, в которой виртуальные машины в виртуальной сети могут взаимодействовать только друг с другом. Традиционно эта изоляция была применена с использованием виртуальных ЛС с диапазоном сегрегированных IP-адресов и идентификатором тега 802.1q или виртуальной локальной сети. Но при использовании HNV изоляция применяется с помощью инкапсуляции NVGRE или VXLAN для создания сетей наложения с возможностью перекрытия IP-подсетей между клиентами или клиентами.

• Каждая виртуальная сеть имеет уникальный идентификатор домена маршрутизации (RDID) на узле. Этот RDID примерно сопоставляется с идентификатором ресурса для идентификации ресурса REST виртуальной сети в сетевом контроллере. Ресурс REST виртуальной сети ссылается с помощью пространства имен универсального идентификатора ресурса (URI) с добавленным идентификатором ресурса.

Виртуальные подсети

• Виртуальная подсеть реализует семантику подсети IP уровня 3 для виртуальных машин одной виртуальной подсети. Виртуальная подсеть формирует широковещательный домен (аналогично виртуальной локальной сети) и изоляция применяется с помощью поля NVGRE Tenant Network ID (TNI) или VXLAN Network Identifier (VNI).

• Каждая виртуальная подсеть принадлежит одной виртуальной сети (RDID), и она назначается уникальным идентификатором виртуальной подсети (VSID) с помощью ключа TNI или VNI в заголовке инкапсулированного пакета. VSID должен быть уникальным в центре обработки данных и находится в диапазоне от 4096 до 2^24-2.

Ключевым преимуществом виртуальной сети и домена маршрутизации является то, что клиенты могут перенести собственные топологии сети (например, подсети IP-адресов) в облако. На рисунке 2 представлен пример, в котором компания Contoso располагает двумя раздельными сетями: сетью R&D и сетью Sales. Поскольку у данных сетей разные ID доменов маршрутизации, они не могут взаимодействовать друг с другом. То есть contoso R&D Net изолирован от Contoso Sales Net, хотя оба принадлежат Contoso Corp. Contoso R&D Net содержит три виртуальных подсети. Отметим, что как RDID, так и VSID в центре регистрации и обработки данных уникальны.

Рисунок 2. Клиентские сети и виртуальные подсети

Переадресация уровня 2

На рис. 2 виртуальные машины в VSID 5001 могут перенаправляют свои пакеты на виртуальные машины, которые также находятся в VSID 5001 через коммутатор Hyper-V. Входящие пакеты из виртуальной машины в VSID 5001 отправляются в определенный VPort на коммутаторе Hyper-V. Правила входящего трафика (например, инкапсулирование) и сопоставления (например, заголовок инкапсулирования) применяются коммутатором Hyper-V для этих пакетов. Затем пакеты перенаправляются в другой VPort на коммутаторе Hyper-V (если целевая виртуальная машина подключена к одному узлу) или другому коммутатору Hyper-V на другом узле (если целевая виртуальная машина находится на другом узле).

Маршрутизация уровня 3

Аналогичным образом виртуальные машины в VSID 5001 могут направлять свои пакеты на виртуальные машины в VSID 5002 или VSID 5003 распределенным маршрутизатором HNV, который присутствует в VSwitch каждого узла Hyper-V. После доставки пакета в коммутатор Hyper-V HNV обновляет VSID входящего пакета до VSID целевой виртуальной машины. Исключительным условием для этого является нахождение обоих VSID в пределах одного RDID. Поэтому адаптеры виртуальной сети с RDID1 не могут отправлять пакеты в адаптеры виртуальной сети с RDID2 без обхода шлюза.

Примечание.

В описании потока пакетов выше термин "виртуальная машина" фактически означает адаптер виртуальной сети на виртуальной машине. Как правило, виртуальная машина имеет лишь один виртуальный сетевой адаптер. В этом случае слова "виртуальная машина" и "виртуальный сетевой адаптер" могут концептуально означать то же самое.

Каждая виртуальная подсеть определяет подсеть IP уровня 3 и границы домена рассылки уровня 2 (У2) аналогично VLAN. Когда виртуальная машина передает пакет, HNV использует юниадресную репликацию (UR) для создания копии исходного пакета и замены целевого IP-адреса и MAC адресами каждой виртуальной машины, которые находятся в одном VSID.

Примечание.

Когда Windows Server 2016 поставляется, широковещательные и подсети многоадресные рассылки будут реализованы с помощью одноадресной реплика. Маршрутизация многоадресной рассылки между подсетями и IGMP не поддерживаются.

Помимо представления домена рассылки, VSID обеспечивает изоляцию. Адаптер виртуальной сети в HNV подключен к порту коммутатора Hyper-V, который будет иметь правила ACL, примененные непосредственно к порту (ресурсу REST VirtualNetworkInterface) или виртуальной подсети (VSID), в которой она является частью.

Порт коммутатора Hyper-V должен применять правило ACL. Этот ACL может быть РАЗРЕШЕН ALL, DENY ALL или быть более конкретным, чтобы разрешить только определенные типы трафика на основе 5 кортежей (исходный IP-адрес, IP-адрес назначения, исходный порт, порт назначения, протокол).

Примечание.

Расширения коммутатора Hyper-V не будут работать с HNVv2 в новом стеке программно-определяемой сети (SDN). HNVv2 реализуется с помощью расширения коммутатора платформы виртуальной фильтрации Azure (VFP), которое нельзя использовать в сочетании с любым другим расширением коммутатора стороннего поставщика.

Переключение и маршрутизация в виртуализации сети Hyper-V

HNVv2 реализует правильную переключение уровня 2 (L2) и семантику маршрутизации уровня 3 (L3), чтобы работать так же, как физический коммутатор или маршрутизатор. Когда виртуальная машина, подключенная к виртуальной сети HNV, пытается установить подключение к другой виртуальной машине в той же виртуальной подсети (VSID), сначала потребуется узнать MAC-адрес ЦС удаленной виртуальной машины. Если есть запись ARP для IP-адреса целевой виртуальной машины в таблице ARP исходной виртуальной машины, используется MAC-адрес из этой записи. Если запись не существует, исходная виртуальная машина отправит трансляцию ARP с запросом НА MAC-адрес, соответствующий IP-адресу целевой виртуальной машины. Коммутатор Hyper-V перехватит этот запрос и отправит его агенту узла. Агент узла будет выглядеть в локальной базе данных для соответствующего MAC-адреса для IP-адреса запрошенной целевой виртуальной машины.

Примечание.

Агент узла, действующий в качестве сервера OVSDB, использует вариант схемы VTEP для хранения сопоставлений CA-PA, таблицы MAC и т. д.

Если mac-адрес доступен, агент узла внедряет ответ ARP и отправляет его обратно на виртуальную машину. После того как сетевой стек виртуальной машины содержит все необходимые сведения о заголовке L2, кадр отправляется в соответствующий порт Hyper-V на V-Switch. Внутри системы коммутатор Hyper-V проверяет этот кадр на основе правил сопоставления кортежей N, назначенных V-Port, и применяет определенные преобразования к кадру на основе этих правил. Наиболее важно, чтобы создать заголовок инкапсуляции с помощью NVGRE или VXLAN, в зависимости от политики, определенной в сетевом контроллере, применяется набор преобразований инкапсуляции. На основе политики, запрограммируемой агентом узла, сопоставление ЦС-PA используется для определения IP-адреса узла Hyper-V, где находится целевая виртуальная машина. Коммутатор Hyper-V гарантирует, что к внешнему пакету применяются правильные правила маршрутизации и теги VLAN, чтобы он достиг удаленного адреса PA.

Если виртуальная машина, подключенная к виртуальной сети HNV, хочет создать соединение с виртуальной машиной в другой виртуальной подсети (VSID), пакет должен быть перенаправлен соответствующим образом. HNV предполагает звездо-топологию, где в пространстве ЦС есть только один IP-адрес, используемый в качестве следующего прыжка, чтобы достичь всех префиксов IP-адресов (то есть один маршрут или шлюз по умолчанию). В настоящее время это применяет ограничение к одному маршруту по умолчанию, а маршруты, отличные от по умолчанию, не поддерживаются.

Маршрутизация между виртуальными подсетями

В физической сети IP-подсеть — это домен уровня 2 (L2), где компьютеры (виртуальные и физические) могут напрямую взаимодействовать друг с другом. Домен L2 — это широковещательный домен, в котором записи ARP (карта IP:MAC-адресов) извлекаются с помощью запросов ARP, которые передаются во все интерфейсы и ответы ARP отправляются обратно в узел запроса. Компьютер использует сведения MAC, полученные из ответа ARP, чтобы полностью создать кадр L2, включая заголовки Ethernet. Однако если IP-адрес находится в другой подсети L3, запрос ARP не пересекает эту границу L3. Вместо этого интерфейс маршрутизатора L3 (следующий прыжк или шлюз по умолчанию) с IP-адресом в исходной подсети должен отвечать на эти запросы ARP с собственным MAC-адресом.

В стандартной сети Windows администратор может создавать статические маршруты и назначать их сетевому интерфейсу. Кроме того, шлюз по умолчанию обычно настраивается как IP-адрес следующего прыжка в интерфейсе, где пакеты, предназначенные для маршрута по умолчанию (0.0.0.0/0) отправляются. Пакеты отправляются в этот шлюз по умолчанию, если определенные маршруты отсутствуют. По сути это маршрутизатор для физической сети. HNV использует встроенный маршрутизатор, который является частью каждого узла и имеет интерфейс в каждом VSID для создания распределенного маршрутизатора для виртуальных сетей.

Так как HNV предполагает звездочку, распределенный маршрутизатор HNV выступает в качестве единого шлюза по умолчанию для всего трафика, который выполняется между виртуальными подсетями, которые являются частью одной сети VSID. Адрес, используемый в качестве шлюза по умолчанию, по умолчанию имеет самый низкий IP-адрес в VSID и назначается распределенному маршрутизатору HNV. Этот распределенный маршрутизатор позволяет эффективно направлять весь трафик внутри сети VSID соответствующим образом, так как каждый узел может напрямую направлять трафик к соответствующему узлу без необходимости посредника. Это тем более верно, если две виртуальные машины из одной сети, но из разных виртуальных подсетей виртуальных машин находятся на одном физическом узле. Как вы узнаете позже в этом разделе, пакету нет необходимости покидать физический узел.

Маршрутизация между подсетями PA

В отличие от HNVv1, который выделил один IP-адрес PA для каждой виртуальной подсети (VSID), HNVv2 теперь использует один IP-адрес PA для каждого участника группы сетевого адаптера Switch-Embedded Teaming (SET). Развертывание по умолчанию предполагает двух сетевых адаптеров и назначает два IP-адреса PA на узел. Один узел имеет IP-адреса PA, назначенные из одной логической подсети поставщика (PA) в одной виртуальной локальной сети. Две виртуальные машины клиента в одной виртуальной подсети действительно могут находиться на двух разных узлах, подключенных к двум разным логическим подсетям поставщика. HNV создаст внешние IP-заголовки для инкапсулированного пакета на основе сопоставления CA-PA. Однако он использует стек TCP/IP узла для ARP для шлюза PA по умолчанию, а затем создает внешние заголовки Ethernet на основе ответа ARP. Как правило, этот ответ ARP поступает из интерфейса SVI на физическом коммутаторе или маршрутизаторе L3, где подключен узел. Поэтому HNV использует маршрутизатор L3 для маршрутизации инкапсулированных пакетов между логическими подсетями поставщика или виртуальными локальными сетями.

Маршрутизация за пределами виртуальной сети

Развертывание большинства клиентских сетей требует, чтобы среда виртуализации сети Hyper-V была связана с ресурсами, не включенными в среду виртуализации сети Hyper-V. Шлюзы виртуализации сетей необходимы для обеспечения возможности связи между этими двумя средами. Инфраструктуры, требующие шлюза HNV, включают частное облако и гибридное облако. В основном шлюзы HNV необходимы для маршрутизации уровня 3 между внутренними и внешними (физическими) сетями (включая NAT) или между различными сайтами и (или) облаками (частными или общедоступными), которые используют VPN-подключение IPSec или туннель GRE.

Шлюзы могут иметь различные физические конструктивные параметры. Их можно создать на платформе Windows Server 2016, включив в коммутатор top of Rack (TOR), действующий в качестве шлюза VXLAN, доступ к которым выполняется через виртуальный IP-адрес (VIP), объявленный подсистемой балансировки нагрузки, помещать в другие существующие сетевые (модуль) или быть новой автономной сетью (модуль).

Дополнительные сведения о параметрах шлюза RAS Для Windows см. в разделе "Шлюз RAS".

Инкапсуляция пакета

В виртуализации сети Hyper-V каждый виртуальный сетевой адаптер связан с двумя IP-адресами:

• Адрес клиента (ЦС) IP-адрес, назначенный клиентом, на основе инфраструктуры интрасети. Этот адрес позволяет клиенту обмениваться сетевым трафиком с виртуальной машиной, как если бы он не был перемещен в общедоступное или частное облако. АК является видимым для виртуальной машины и доступным для клиента.

• Адрес поставщика (PA) IP-адрес, назначенный поставщиком услуг размещения или администраторами центра обработки данных на основе инфраструктуры физической сети. АП появляется в сети в виде пакетов. Обмен ими производится с сервером Hyper-V, на котором размещается виртуальная машина. АП является видимым в физической сети, но не для виртуальной машины.

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

Рисунок 6. Концептуальная схема виртуализации сетей относительно физической инфраструктуры

На схеме виртуальные машины клиента отправляют пакеты данных в пространстве ЦС, которые проходят через инфраструктуру физической сети через собственные виртуальные сети или туннели. В приведенном выше примере туннели можно рассматривать как "конверты" вокруг пакетов данных Contoso и Fabrikam с зелеными метками доставки (PA-адреса), которые будут доставлены с исходного узла слева на узел назначения справа. Ключ заключается в том, как узлы определяют "адреса доставки" (PA), соответствующие contoso и ЦС Fabrikam, как "конверт" помещается вокруг пакетов, а также как конечные узлы могут разорвать пакеты и доставлять их в виртуальные машины contoso и Fabrikam назначения.

Ключевые аспекты виртуализации сетей объясняются при помощи простой аналогии:

• АК каждой виртуальной машины сопоставляется с АП физического узла. С одним АП может быть связано несколько АК.

• Виртуальные машины отправляют пакеты данных в пространствах ЦС, которые помещаются в "конверт" с парой источника и назначения PA на основе сопоставления.

• Сопоставления АК — АП должны позволять узлам производить дифференциацию пакетов для различных клиентских виртуальных машин.

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

Виртуализация сетей при помощи виртуализации адресов

HNV реализует наложение сетей клиентов с помощью инкапсуляции универсальной маршрутизации сетевой виртуализации (NVGRE) или виртуальной локальной сети eXtensible Local Area Network (VXLAN). VXLAN — это значение по умолчанию.

Виртуальная локальная сеть eXtensible (VXLAN)

Протокол VXtensible Local Area Network (VXLAN) (RFC 7348) широко принят на рынке, с поддержкой поставщиков, таких как Cisco, Brocade, Arista, Dell, HP и другие. Протокол VXLAN использует UDP в качестве транспорта. Назначенный IANA порт назначения UDP для VXLAN равен 4789, а исходный порт UDP должен быть хэшом информации из внутреннего пакета, который будет использоваться для распространения ECMP. После заголовка UDP к пакету добавляется заголовок VXLAN, содержащий зарезервированное 4-байтовое поле, за которым следует 3-байтовое поле для идентификатора сети VXLAN (VNI) — VSID, за которым следует другое зарезервированное 1-байтовое поле. После заголовка VXLAN добавляется исходный кадр ЦС L2 (без кадра ETHERNET ЦС).

Инкапсуляция универсальной маршрутизации (NVGRE)

Этот механизм виртуализации сети использует инкапсуляцию универсальной маршрутизации (NVGRE) в качестве части заголовка туннеля. В NVGRE пакет виртуальной машины инкапсулируется внутри другого пакета. Заголовок этого нового пакета снабжается необходимыми IP-адресами источника и назначения типа АП в дополнение к ID виртуальной подсети, хранящемуся в ключевом поле заголовка GRE, как показано на рисунке 7.

Рисунок 7. Виртуализация сетей — инкапсуляция типа NVGRE

Идентификатор виртуальной подсети позволяет узлам идентифицировать клиентскую виртуальную машину для любого заданного пакета, несмотря на то, что pa и ЦС на пакетах могут перекрываться. Это позволяет всем виртуальным машинам одного узла совместно использовать единый АП, как показано на рисунке 7.

Совместное использование АП оказывает серьезное воздействие на масштабируемость сети. Количество IP- и MAC-адресов, требующих запоминания сетевой инфраструктурой, может быть существенно снижено. Например, если на каждом конечном узле имеется в среднем 30 виртуальных машин, количество IP- и MAC-адресов, требующих запоминания сетевой инфраструктурой, снижается на коэффициент 30. ID виртуальной подсети, включенные в пакеты, также позволяют производить простую корреляцию пакетов под фактических клиентов.

Схема совместного использования PA для Windows Server 2012 R2 составляет один PA на каждый узел. Для Windows Server 2016 схема составляет один PA для каждого члена группы сетевого адаптера.

С Windows Server 2016 и более поздних версий HNV полностью поддерживает NVGRE и VXLAN из поля; Для этого не требуется обновление или приобретение нового сетевого оборудования, например сетевых адаптеров (сетевых адаптеров), коммутаторов или маршрутизаторов. Это связано с тем, что эти пакеты на проводе являются обычными IP-пакетами в пространстве PA, который совместим с современной сетевой инфраструктурой. Однако для получения оптимальной производительности поддерживаемых сетевых адаптеров с последними драйверами, поддерживающими разгрузку задач.

Пример развертывания нескольких клиентов

На следующей схеме показан пример развертывания двух клиентов, расположенных в облачном центре обработки данных, с отношением ЦС-PA, определенными политиками сети.

Рисунок 8. Пример архитектуры обслуживания нескольких развертываний одним экземпляром приложения

Рассмотрим пример, приведенный на рисунке 8. До перехода к размещению в службе IaaS, обеспеченной провайдером:

• Компания Contoso задействовала SQL Server (с именем SQL) по IP-адресу 10.1.1.11 и веб-сервер (с именем Web) по IP-адресу 10.1.1.12, который использует свой SQL Server для транзакций базы данных.

• Компания Fabrikam задействовала SQL Server, также имеющий имя SQL и назначенный IP-адрес 10.1.1.11, и веб-сервер, тоже именуемый Web и имеющий IP-адрес 10.1.1.12, который использует свой SQL Server для транзакций базы данных.

Предполагается, что поставщик услуг размещения ранее создал логическую сеть поставщика (PA) через сетевой контроллер, чтобы соответствовать топологии физической сети. Сетевой контроллер выделяет два IP-адреса PA из префикса IP-адреса логической подсети, где подключены узлы. Сетевой контроллер также указывает соответствующий тег виртуальной локальной сети для применения IP-адресов.

Используя сетевой контроллер, Contoso Corp и Fabrikam Corp, затем создайте свою виртуальную сеть и подсети, которые поддерживаются логической сетью поставщика (PA), указанной поставщиком услуг размещения. Компании Contoso и Fabrikam переместили свои серверы SQL Server и соответствующие веб-серверы в одно и то же размещение в службе IaaS, обеспеченной поставщиком, где, по случайному совпадению, они задействовали виртуальные машины SQL на узле 1 (Host 1) Hyper-V и виртуальные машины Web (IIS7) на узле 2 (Host 2) Hyper-V. Все виртуальные машины сохраняют свои исходные внутрисетевые IP-адреса (свои АК).

Обе компании назначаются следующим идентификатором виртуальной подсети (VSID) сетевым контроллером, как указано ниже. Агент узла на каждом из узлов Hyper-V получает выделенные IP-адреса PA от сетевого контроллера и создает два виртуальных сетевых адаптера узла PA в сетевом отсеке, отличном от по умолчанию. Сетевой интерфейс назначается каждому из этих виртуальных сетей узлов, где IP-адрес PA назначен, как показано ниже:

• Виртуальные машины Contoso Corp VSID и PAs: VSID — 5001, SQL PA — 192.168.1.10, веб-PA — 192.168.2.20

• Виртуальные машины Fabrikam Corp VSID и PAs: VSID — 6001, SQL PA — 192.168.1.10, веб-PA — 192.168.2.20

Сетевой контроллер выполняет все сетевые политики (включая сопоставление ЦС-PA) с агентом узла SDN, который будет поддерживать политику в постоянном хранилище (в таблицах базы данных OVSDB).

Когда виртуальная машина Contoso Corp (10.1.1.12) на узле Hyper-V 2 создает TCP-подключение к SQL Server в 10.1.11, происходит следующее:

• ARPs виртуальной машины для целевого MAC-адреса 10.1.1.11

• Расширение VFP в vSwitch перехватывает этот пакет и отправляет его агенту узла SDN.

• Агент узла SDN выглядит в своем хранилище политик для MAC-адреса для 10.1.1.11

• При обнаружении MAC агент узла внедряет ответ ARP обратно на виртуальную машину.

• Если mac не найден, не отправляется ответ, а запись ARP на виртуальной машине для версии 10.1.1.11 недоступна.

• Теперь виртуальная машина создает TCP-пакет с правильными заголовками CA Ethernet и IP-адресами и отправляет его в vSwitch.

• Расширение пересылки VFP в vSwitch обрабатывает этот пакет с помощью слоев VFP (описанных ниже), назначенных исходному порту vSwitch, на котором был получен пакет, и создает новую запись потока в единой таблице потоков VFP.

• Подсистема VFP выполняет сопоставление правил или поиск таблицы потоков для каждого уровня (например, уровня виртуальной сети) на основе заголовков IP и Ethernet.

• Соответствующее правило в слое виртуальной сети ссылается на пространство сопоставления ЦС-PA и выполняет инкапсуляцию.

• Тип инкапсуляции (VXLAN или NVGRE) указывается на уровне виртуальной сети вместе с VSID.

• В случае инкапсуляции VXLAN внешний заголовок UDP создается с помощью VSID 5001 в заголовке VXLAN. Внешний IP-заголовок создается с исходным и целевым АДРЕСом PA, назначенным узлу Hyper-V 2 (192.168.2.20) и узлу Hyper-V 1 (192.168.1.10) соответственно на основе хранилища политик агента узла SDN.

• Затем этот пакет передается на уровень маршрутизации PA в VFP.

• Уровень маршрутизации PA в VFP будет ссылаться на сетевой отсек, используемый для трафика пространства PA, и идентификатор виртуальной ЛС и использовать стек TCP/IP узла для правильной пересылки пакета PA в узел Hyper-V 1.

• После получения инкапсулированного пакета узел Hyper-V 1 получает пакет в сетевом отсеке PA и перенаправит его в vSwitch.

• VFP обрабатывает пакет с помощью уровней VFP и создает новую запись потока в унифицированной таблице потоков VFP.

• Подсистема VFP соответствует правилам входящего трафика на уровне виртуальной сети и удаляет заголовки Ethernet, IP и VXLAN внешнего инкапсулированного пакета.

• Затем подсистема VFP перенаправит пакет на порт vSwitch, к которому подключена целевая виртуальная машина.

Аналогичный процесс для трафика между Fabrikam Corp Web и виртуальными машинами SQL использует параметры политики HNV для корпорации Fabrikam Corp. В результате при использовании HNV виртуальные машины компании Fabrikam и Contoso взаимодействуют так, как если бы находились в своих интрасетях компаний. При этом они не могут взаимодействовать друг с другом, даже несмотря на то, что используют одинаковые IP-адреса.

Отдельные адреса (ЦС и PAS), параметры политики узлов Hyper-V и преобразование адресов между ЦС и PA для входящего и исходящего трафика виртуальной машины изолируют эти наборы серверов с помощью ключа NVGRE или VNID VLXAN. Более того, сопоставления виртуализации и преобразование лишают архитектуру виртуальной сети привязки к инфраструктуре физической сети. Хотя SQL и Web компании Contoso и SQL и Web компании Fabrikam располагаются в их собственных подсетях IP АК (10.1.1/24), их физическое развертывание происходит на двух узлах в разных подсетях АП: 192.168.1/24 и 192.168.2/24 соответственно. Суть в том, что перекрестно-подсетевое выделение виртуальных машин и динамическая миграция становятся возможными с применением виртуализации сети Hyper-V.

Архитектура виртуализации сетей Hyper-V

В Windows Server 2016 HNVv2 реализуется с помощью платформы фильтрации Виртуальных машин Azure (VFP), которая является расширением фильтрации NDIS в коммутаторе Hyper-V. Ключевым понятием VFP является подсистема потока match-Action с внутренним API, предоставляемым агенту узла SDN для программирования сетевой политики. Сам агент узла SDN получает политику сети от сетевого контроллера через каналы связи OVSDB и WCF SouthBound. Не только политика виртуальной сети (например, сопоставление CA-PA), запрограммированная с помощью VFP, но и дополнительная политика, например списки управления доступом, QoS и т. д.

Иерархия объектов для расширения пересылки vSwitch и VFP является следующей:

• vSwitch

  • Управление внешним сетевым адаптером

  • Разгрузки оборудования сетевого адаптера

  • Правила глобальной пересылки

  • Порт

    • Исходящий слой пересылки для прикрепления волос

    • Списки пробелов для сопоставлений и пулов NAT

    • Единая таблица потока

    • Уровень VFP

      • Таблица потоков

      • Групповой

      • Правило

        • Правила могут ссылаться на пробелы

В VFP слой создается для каждого типа политики (например, виртуальная сеть) и является универсальным набором таблиц правил и потоков. Она не имеет встроенных функциональных возможностей, пока определенные правила не будут назначены данному уровню для реализации таких функций. Каждый слой назначается приоритетом, а слои назначаются порту по возрастанию приоритета. Правила организованы в группы в основном на основе семейства направлений и IP-адресов. Группы также назначаются приоритетом и по крайней мере одно правило из группы может соответствовать заданному потоку.

Логика пересылки для vSwitch с расширением VFP выглядит следующим образом:

• Обработка входящего трафика (входящий трафик с точки зрения пакета, поступающего в порт)

• Переадресация

• Обработка исходящего трафика (исходящего трафика с точки зрения выхода пакета из порта)

VFP поддерживает внутреннее перенаправление MAC для типов инкапсуляции NVGRE и VXLAN, а также внешнего перенаправления виртуальных ЛС MAC.

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

Политика HNV запрограммирована агентом узла. Каждый сетевой адаптер виртуальной машины настроен с помощью IPv4-адреса. Существуют АК, используемые для связи виртуальных машин друг с другом, они поступают в IP-пакетах из этих виртуальных машин. HNV инкапсулирует кадр ЦС в кадре PA на основе политик виртуализации сети, хранящихся в базе данных агента узла.

Рисунок 9. Архитектура HNV

Итоги

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

См. также

Дополнительные сведения о HNVv2 см. по следующим ссылкам:

Content type	Ссылки
Ресурсы сообщества	- Блог по архитектуре частного облака - Задайте вопросы: cloudnetfb@microsoft.com
RFC	- Проект RFC NVGRE - VXLAN — RFC 7348
Связанные технологии	— Технические сведения о виртуализации сети Hyper-V в Windows Server 2012 R2 см . в технической документации по виртуализации сети Hyper-V - Сетевой контроллер