С технологической точки зрения виртуализация сети представляет собой довольно сложный механизм, поэтому сделать более-менее полный обзор этой технологии в рамках одного поста, пожалуй, не удастся. Сегодня обсудим концепцию и архитектуру, в следующем посте я сосредоточусь на настройке NV, затем отдельно погорим об организации внешнего доступа к ВМ, запущенным в виртуализованной сети.
Начнем с основополагающего вопроса: «Для чего нужна виртуализация сети?»
Для чего нужна виртуализация сети?
В случае серверной виртуализации с небольшими оговорками ОС внутри ВМ работает так, как если бы была установлена на физический сервер и являлась единственной ОС на этом оборудовании. Подобная абстракция позволяет запускать несколько изолированных экземпляров виртуальных серверов на одном физическом. По аналогии виртуализация сети приводит к тому, что виртуальная, а точнее в данном контексте виртуализованная сеть, функционирует так, как если бы она являлась физической сетью. Соответственно, данный уровень виртуализации позволяет создавать и использовать несколько виртуальных сетей, возможно с перекрывающимися или даже полностью совпадающими пространствами IP-адресов, на одной физической сетевой инфраструктуре. И эта сетевая инфраструктура, вообще говоря, может включать в себя произвольное количество физических серверов и сетевого оборудования (см. рис. ниже)..png)
Увеличить
На приведенном рисунке виртуальные машины из синей сети и красной сети, принадлежащих разным департаментам или организациям, могут использовать одни и те же IP-адреса, могут быть запущены на одном и том же или разных физических хостах, но при этом с одной стороны, они будут полностью изолированы друг от друга, и, с другой стороны, при этом будут безо всяких проблем взаимодействовать с другими сетевыми объектами (реальными или виртуальными) своего департамента или своей организации. Отсюда вытекают назначение технологии NV, преимущества и основные сценарии ее применения.
Большая гибкость в размещении ВМ в пределах ЦОД
NV предоставляет определенную свободу при размещении ВМ в рамках ЦОД. В частности, размещение ВМ предполагает настройку IP-адреса, соответствующего физическому сегменту сети, и настройку VLAN для обеспечения изоляции. Коль скоро NV допускает сосуществование на одном хосте ВМ с совпадающими IP-адресами, мы более не связаны применяемой в ЦОД схемой IP-адресации и не упираемся в ограничения, накладываемые VLAN.
Упрощенный перенос ВМ в облако
Поскольку при использовании виртуализации сети IP-адрес и конфигурация ВМ остаются неизменными, это значительно упрощает процесс переноса ВМ в соседний ЦОД организации, в облако хостера или публичное облако. И клиенты приложения, и ИТ-администраторы продолжают использовать свои инструменты для взаимодействия с ВМ/приложением без переконфигурации.
Динамическая миграция (Live Migration) за пределы подсети
Динамическая миграция ВМ ограничена пределами IP-подсети (или VLAN-ами). Если мигрировать ВМ в другую подсеть, потребуется перенастройка IP внутри гостевой ОС со всем вытекающими последствиями. Однако если динамическая миграция выполняется между двумя хостами с Windows Server 2012 с включенной NV, то хосты могут располагаться в различных сегментах физической сети, при этом виртуализация сети обеспечит непрерывность сетевых коммуникаций перемещаемой ВМ.
Повышенная утилизация ресурсов физических хостов и сетей
Отсутствие зависимости от IP-адресации и VLAN-ов позволяет более равномерно загружать физические хосты и более эффективно утилизировать имеющиеся ресурсы. При этом следует отметить, что NV поддерживает VLAN, и вы можете сочетать оба способа изоляции, например, изолировав трафик NV в выделенном для этих целей VLAN-не.
Концепция Hyper-V Network Virtualization
При настройке NV с каждым виртуальным сетевым адаптером (vNIC) ассоциируется пара IP-адресов:
- Адрес заказчика (Customer Address, CA). Адрес, настроенный заказчиком внутри ВМ. Этот адрес является видимым для самой ВМ и ОС внутри нее, по этому адресу ВМ видна для инфраструктуры заказчика, этот адрес не изменяется при перемещении ВМ в пределах ЦОД, либо за его пределы.
- Адрес провайдера (Provider Address, PA). Адрес, присваиваемый администратором ЦОД или хостером, исходя из физической сетевой инфраструктуры. Этот адрес используется при передаче пакетов по сети между хостами Hyper-V, на которых запущены ВМ и сконфигурирована технология NV. Этот адрес видим в физическом сегменте сети, но не видим для ВМ и гостевой ОС.
_mini_oszone.png)
Увеличить
В процессе сетевого взаимодействия ВМ формирует пакет с адресами отправителя и получателя из пространства CA. Такой пакет покидает ВМ и хостом Hyper-V упаковывается в пакет с адресами отправителя и получателя из пространства PA. Адреса PA определяются на основе таблицы политики виртуализации. После этого пакет передается по физической сети. Хост Hyper-V, получивший пакет, на основе все той же таблицы политики виртуализации выполняет обратную процедуру: извлекает исходный пакет, определяет ВМ-получателя и перенаправляет исходный пакет с адресами CA нужной ВМ.
Таким образом, виртуализация сети, в конечном счете, сводится к виртуализации адресов, используемых виртуальными машинами. В свою очередь, виртуализация адресов в Hyper-V Windows Server 2012 возможна с помощью двух механизмов: Generic Routing Encapsulation и IP Rewrite. Рассмотрим кратко каждый их них.
.png)
Generic Routing Encapsulation
В первом механизме исходный пакет c CA-адресами инкапсулируется в структуру GRE (Generic Routing Encapsulation, см. RFC 2890), которая упаковывается в IP-пакет с необходимыми PA-адресами. В заголовок GRE добавляется также уникальный идентификатор виртуальной подсети (Virtual Subnet ID, поле «Ключ GRE» на рис.), которой принадлежит исходный пакет, и МАС-адреса виртуальных сетевых адаптеров ВМ отправителя и получателя..png)
Увеличить
Идентификатор подсети позволяет хосту-получателю правильно определить ВМ, для которой предназначен пакет, даже в случае возможного совпадения CA-адресов в ВМ разных заказчиков. Вторая важная особенность данного механизма заключается в том, что вне зависимости от количества запущенных на хосте ВМ достаточно одного PA-адреса для передачи пакетов от любых ВМ. Это существенным образом влияет на масштабируемость решения при использовании GRE-механизма виртуализации адресов. Наконец надо отметить, что описанная схема полностью совместима с имеющимся сетевым оборудованием и не требует какого-либо обновления сетевых адаптеров, коммутаторов или маршрутизаторов.
Однако в перспективе было бы совсем не лишним, чтобы свитч или роутер могли анализировать поле Virtual Subnet ID пакета, и администратор мог бы настраивать соответствующие правила для коммутации или маршрутизации пакетов на основе этого поля. Или например, чтобы все задачи, связанные с упаковкой-распаковкой GRE, брал на себя сетевой адаптер. С этой целью Microsoft совместно с партнерами разработали стандарт NVGRE – Network Virtualization using Generic Routing Encapsulation, находящийся сейчас в стадии IETF Draft. В частности, в рамках этого стандарта регламентируется 24-битное поле Tenant Network Identifier (TNI) для хранения идентификатора подсети, тип протокола 0x6558, указывающий на NVGRE-пакет, и другие нюансы..png)
Увеличить
IP Rewrite
Второй механизм по своей идеологии несколько проще. Каждому CA-адресу ставится в соответствие уникальный PA-адрес. Когда пакет покидает ВМ, хост Hyper-V заменяет в заголовке IP-пакета CA-адреса на PA-адреса и посылает пакет в сеть. Принимающий хост выполняет обратную замену адресов и доставляет пакет ВМ. Как следует из описанного алгоритма, на каждом физическом хосте с ролью Hyper-V необходимо сконфигурировать столько PA-адресов, сколько CA-адресов используется во всех запущенных на данном хосте виртуальных машинах, использующих виртуализацию сети..png)
Увеличить
Инкапсуляция пакетов с помощью GRE требует дополнительных накладных расходов. Поэтому для сценариев с высокими требованиями к пропускной способности канала, например, для ВМ активно использующей 10Gbps-адаптер, как и раз и рекомендуется IP Rewrite. Для большинства же остальных случаев оптимальным является механизм GRE. Ну а с появлением оборудования, поддерживающего NVGRE, этот механизм не будет уступать IP Rewrite и в производительности.
Сеть заказчика и виртуальная подсеть
В терминологии Hyper-V Network Virtualization заказчик – это «владелец» группы ВМ, развернутых в ЦОД. На практике, если речь идет о ЦОД-е провайдера хостинговых услуг, таким заказчиком может быть какая-либо компания или организация. Если говорим о частном облаке, то заказчиком, как правило, выступает департамент или отдел организации. В любом случае заказчик может владеть одной или несколькими сетями (Customer Network), и каждая такая сеть состоит из одной или нескольких виртуальных подсетей (Virtual Subnet).
Customer Network
- Сеть заказчика определяет границу изоляции виртуальных машин. Иными словами, ВМ, принадлежащие одной сети заказчика, могут взаимодействовать между собой. Как следствие, виртуальные подсети, принадлежащие одной сети заказчика, не должны использовать пересекающиеся пространства IP-адресов.
- Каждая сеть заказчика идентифицируется с помощью специального идентификатора Routing Domain ID (RDID), который присваивается администратором ЦОД-а, либо управляющим ПО, таким как System Center 2012 Virtual Machine Manager. RDID имеет формат глобального идентификатора (GUID), например {11111111-2222-3333-4444-000000000000}.
Virtual Subnet
- Виртуальная подсеть использует семантику IP-подсети и определяет, таким образом, широковещательный домен (broadcast domain) для ВМ. Виртуальные машины в одной виртуальной подсети должны использовать одинаковый IP-перфикс, то есть принадлежать одной IP-подсети.
- Каждая виртуальная подсеть принадлежит одной сети заказчика (ассоциируется с одним RDID) и идентифицируется уже знакомым нам уникальным идентификатором Virtual Subnet ID (VSID). VSID может принимать значения от 4096 до 2^24-2.
Применение этих двух понятий позволяет заказчику переносить свою сетевую топологию в облако. На рис. ниже изображены две сети компании «Синие» — сеть R&D и сеть отдела продаж. Изначально эти сети изолированы и не должны взаимодействовать между собой. Поскольку при переносе в среду Hyper-V Network Virtualization этим сетям присвоены различные RDID, ВМ этих сетей не могут «видеть» друг друга. При этом, например, ВМ из виртуальных подсетей 1, 2 и 3 сети R&D могут обмениваться пакетами..png)
Увеличить
Архитектура Hyper-V Network Virtualization
NV доступна только в Windows Server 2012.
На хостах с Hyper-V Network Virtualization должна поддерживаться политика виртуализации, в которой собственно задается и хранится информация о пространствах CA и PA, идентификаторах RDID и VSID, применяемых механизмах виртуализации адресов. Windows Server 2012 содержит набор программных интерфейсов (API), с помощью которых ПО может управлять всеми аспектами NV. Таким управляющим ПО в самом простом случае могут быть скрипты PowerShell, в промышленном сценарии эту роль выполняет System Center 2012 Virtual Machine Manager SP1 (VMM). Обращаю внимание, что именно с выходом SP1 в System Center 2012 появилась поддержка Windows Server 2012, а стало быть и NV.
Настройки, заданные в политике виртуализации, непосредственно применяются драйвером-фильтром уровня NDIS (Network Driver Interface Specification), называемым Windows Network Virtualization (WNV). Фильтр WNV располагается ниже Hyper-V Extensible Switch. Это означает, что коммутатор Hyper-V и все его расширения (если таковые имеются) работают с CA-адресами и ничего не знают о PA-адресах. Однако VSID-ы доступны коммутатору и расширениям, поэтому Hyper-V Extensible Switch способен различать, например, CA-адреса 10.0.0.5, принадлежащие разным заказчикам..png)
Увеличить
Если для ВМ включается виртуализация сети, то для портов Hyper-V Extensible Switch, к которым подключены виртуальные сетевые адаптеры этой ВМ, гипервизор включает списки управления доступом (Access Control List, ACL). Подробнее об ACL я рассказывал здесь. В ACL указывается VSID виртуальной подсети, которой принадлежит ВМ. Любые пакеты, приходящие на данный порт свитча, с VSID, отличным от заданного в ACL, игнорируются.
Приняв эту логику во внимание, перемещение пакетов выглядит следующим образом. Исходящий от ВМ пакет через порт Hyper-V Extensible Switch попадает в фильтр WNV, который анализирует политику виртуализации NV и применяет к пакету необходимые операции (замена IP-адреса или упаковка в GRE), после чего пакет отправляется в сеть.
На принимающей стороне входящий пакет попадает в фильтр WNV, который анализирует политику виртуализации NV. Если входящий пакет – пакет GRE, фильтр считывает из GRE-заголовка поле VSID, извлекает исходный IP-пакет и передает его вместе с VSID на тот порт Hyper-V Extensible Switch, к которому подключен vNIC виртуальной машины с CA-адресом, соответствующим адресу получателя в заголовке исходного IP-пакета. Если переданный VSID совпадает с VSID в ACL данного порта, свитч передает пакет виртуальной машине. Если используемый механизм виртуализации – IP Rewrite, фильтр на основе информации из политики виртуализации меняет PA-адреса в пакете на CA-адреса, все по тем же парам PA- и CA-адресов определяет VSID и пакет с уже CA-адресами вместе с VSID направляет на соответствующий порт Hyper-V Extensible Switch. Если переданный VSID совпадает с VSID в ACL данного порта, свитч передает пакет виртуальной машине.
Описанная логика применяется, когда пакет передается между ВМ, расположенными на одном или разных хостах с Windows Server 2012 и поднятой ролью Hyper-V. Ситуация несколько усложнится, если пакет из ВМ, в которой, например, запущено некое бизнес-приложение, должен добраться до рабочей станции с клиентской частью этого бизнес-приложения. В этом случае нам потребуется настроить Hyper-V Network Virtualization Gateway, о чем мы поговорим отдельно.
В следующем посте я расскажу, как настроить NV с помощью: 1) скриптов PowerShell, 2) VMM.
А пока вы можете:
- посмотреть виртуализацию сети в действии в первом модуле курса « Новые возможности Windows Server 2012. Часть 1. Виртуализация, сети, хранилища»;
- получить дополнительную информацию о Hyper-V Network Virtualization в третьем модуле курса « Windows Server 2012: сетевая инфраструктура»;
- скачать оригинальную презентацию (на англ.), слайды из которой я использовал в этом посте, с детальным описанием процесса передачи пакетов (packet flow) в NV.
Надеюсь, материал был полезен.