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

В Windows Server 2012 появилась разработка виртуализации сети (Network Virtualization, NV), обеспечивающая возможность виртуализации на принципно новеньком уровне – уровне сетевого сектора. В отличие от обычной серверной виртуализации NV позволит вам виртуализовать IP-подсети и на сто процентов скрыть от виртуальных машин (ВМ) и приложений снутри ВМ реальную IP-адресацию, применяемую в вашей инфраструктуре. При всем этом ВМ как и раньше могут вести взаимодействие меж собой, с другими физическими хостами, с хостами в других подсетях.

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

Начнем с основополагающего вопроса: «Для чего нужна виртуализация сети?»

Зачем нужна виртуализация сети?

В случае серверной виртуализации с маленькими обмолвками ОС снутри ВМ работает так, как если б была установлена на физический сервер и являлась единственной ОС на этом оборудовании. Схожая абстракция позволяет запускать несколько изолированных экземпляров виртуальных серверов на одном физическом. По аналогии виртуализация сети приводит к тому, что виртуальная, а поточнее в данном контексте виртуализованная сеть, работает так, как если б она являлась физической сетью. Соответственно, данный уровень виртуализации позволяет создавать и использовать несколько виртуальных сетей, может быть с перекрывающимися либо даже вполне совпадающими местами Айпишников, на одной физической сетевой инфраструктуре. И эта сетевая инфраструктура, вообщем говоря, может включать в себя случайное количество физических серверов и сетевого оборудования (см. рис. ниже).

Виртуализация сети в Hyper-V. Концепция
Прирастить

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

Большая упругость в размещении ВМ в границах ЦОД

NV предоставляет определенную свободу при размещении ВМ в рамках ЦОД. А именно, размещение ВМ подразумевает настройку Айпишники, соответственного физическому сектору сети, и настройку VLAN для обеспечения изоляции. Коль скоро NV допускает сосуществование на одном хосте ВМ с совпадающими Айпишниками, мы более не связаны используемой в ЦОД схемой IP-адресации и не упираемся в ограничения, накладываемые VLAN.

Облегченный перенос ВМ в скопление

Так как при использовании виртуализации сети Айпишник и конфигурация ВМ остаются постоянными, это существенно упрощает процесс переноса ВМ в примыкающий ЦОД организации, в скопление хостера либо общественное скопление. И клиенты приложения, и ИТ-администраторы продолжают использовать свои инструменты для взаимодействия с ВМ/приложением без переконфигурации.

Динамическая миграция (Live Migration) за границы сабсети

Динамическая миграция ВМ ограничена пределами IP-подсети (либо VLAN-ами). Если мигрировать ВМ в другую сабсеть, будет нужно перенастройка IP снутри гостевой ОС со всем вытекающими последствиями. Но если динамическая миграция производится меж 2-мя хостами с Windows Server 2012 с включенной NV, то хосты могут размещаться в разных секторах физической сети, при всем этом виртуализация сети обеспечит непрерывность сетевых коммуникаций перемещаемой ВМ.

Завышенная утилизация ресурсов физических хостов и сетей

Отсутствие зависимости от IP-адресации и VLAN-ов позволяет более умеренно загружать физические хосты и поболее отлично утилизировать имеющиеся ресурсы. При всем этом необходимо подчеркнуть, что NV поддерживает VLAN, и вы сможете соединять оба метода изоляции, к примеру, изолировав трафик NV в выделенном для этих целей VLAN-не.

Концепция Hyper-V Network Virtualization

При настройке NV с каждым виртуальным сетевым адаптером (vNIC) ассоциируется пара Айпишников:

Адресок заказчика (Customer Address, CA). Адресок, настроенный заказчиком снутри ВМ. Этот адресок является видимым для самой ВМ и ОС в ней, по этому адресу ВМ видна для инфраструктуры заказчика, этот адресок не меняется при перемещении ВМ в границах ЦОД, или за его пределы.
Адресок провайдера (Provider Address, PA). Адресок, присваиваемый админом ЦОД либо хостером, исходя из физической сетевой инфраструктуры. Этот адресок применяется при передаче пакетов по сети меж хостами Hyper-V, на которых запущены ВМ и сконфигурирована разработка NV. Этот адресок лицезреем в физическом секторе сети, но не лицезреем для ВМ и гостевой ОС.

Виртуализация сети в Hyper-V. Концепция
Прирастить

В процессе сетевого взаимодействия ВМ сформировывает пакет с адресами отправителя и получателя из места CA. Таковой пакет покидает ВМ и хостом Hyper-V упаковывается в пакет с адресами отправителя и получателя из места PA. Адреса PA определяются на базе таблицы политики виртуализации. После чего пакет передается по физической сети. Хост Hyper-V, получивший пакет, на базе все той же таблицы политики виртуализации делает оборотную функцию: извлекает начальный пакет, определяет ВМ-получателя и перенаправляет начальный пакет с адресами CA подходящей ВМ.

Таким макаром, виртуализация сети, в конечном счете, сводится к виртуализации адресов, применяемых виртуальными машинами. В свою очередь, виртуализация адресов в Hyper-V Windows Server 2012 вероятна при помощи 2-ух устройств: Generic Routing Encapsulation и IP Rewrite. Разглядим коротко каждый их их.

Generic Routing Encapsulation

В первом механизме начальный пакет c CA-адресами инкапсулируется в структуру GRE (Generic Routing Encapsulation, см. RFC 2890), которая упаковывается в IP-пакет с необходимыми PA-адресами. В заголовок GRE добавляется также уникальный идентификатор виртуальной сабсети (Virtual Subnet ID, поле «Ключ GRE» на рис.), которой принадлежит начальный пакет, и МАС-адреса виртуальных сетевых адаптеров ВМ отправителя и получателя.

Виртуализация сети в Hyper-V. Концепция
Прирастить

Идентификатор сабсети позволяет хосту-получателю верно найти ВМ, для которой предназначен пакет, даже в случае вероятного совпадения CA-адресов в ВМ различных заказчиков. 2-ая принципиальная особенность данного механизма состоит в том, что вне зависимости от количества запущенных на хосте ВМ довольно 1-го PA-адреса для передачи пакетов от всех ВМ. Это значимым образом оказывает влияние на масштабируемость решения при использовании GRE-механизма виртуализации адресов. В конце концов нужно отметить, что описанная схема стопроцентно совместима с имеющимся сетевым оборудованием и не просит какого-нибудь обновления сетевых адаптеров, коммутаторов либо маршрутизаторов.

Но в перспективе было бы совершенно не излишним, чтоб свитч либо роутер могли рассматривать поле Virtual Subnet ID пакета, и админ мог бы настраивать надлежащие правила для коммутации либо маршрутизации пакетов на базе этого поля. Либо к примеру, чтоб все задачки, связанные с упаковкой-распаковкой GRE, брал на себя сетевой адаптер. С этой целью Microsoft вместе с партнерами разработали эталон NVGRE – Network Virtualization using Generic Routing Encapsulation, находящийся на данный момент в стадии IETF Draft. А именно, в рамках этого эталона регламентируется 24-битное поле Tenant Network Identifier (TNI) для хранения идентификатора сабсети, тип протокола 0×6558, указывающий на NVGRE-пакет, и другие аспекты.

Виртуализация сети в Hyper-V. Концепция
Прирастить

IP Rewrite

2-ой механизм по собственной идеологии несколько проще. Каждому CA-адресу ставится в соответствие уникальный PA-адрес. Когда пакет покидает ВМ, хост Hyper-V подменяет в заголовке IP-пакета CA-адреса на PA-адреса и отправляет пакет в сеть. Принимающий хост делает оборотную подмену адресов и доставляет пакет ВМ. Как надо из описанного метода, на каждом физическом хосте с ролью Hyper-V нужно изменить столько PA-адресов, сколько CA-адресов употребляется во всех запущенных на данном хосте виртуальных машинах, использующих виртуализацию сети.

Виртуализация сети в Hyper-V. Концепция
Прирастить

Инкапсуляция пакетов при помощи GRE просит дополнительных затратных расходов. Потому для сценариев с высочайшими требованиями к пропускной возможности канала, к примеру, для ВМ интенсивно использующей 10Gbps-адаптер, как и раз и рекомендуется IP Rewrite. Для большинства же других случаев хорошим является механизм GRE. Ну а с возникновением оборудования, поддерживающего NVGRE, этот механизм не будет уступать IP Rewrite и в производительности.

Сеть заказчика и виртуальная сабсеть

В терминологии Hyper-V Network Virtualization заказчик – это «владелец» группы ВМ, развернутых в ЦОД. На практике, если идет речь о ЦОД-е провайдера хостинговых услуг, таким заказчиком может быть какая-либо компания либо организация. Если говорим о личном облаке, то заказчиком, обычно, выступает департамент либо отдел организации. В любом случае заказчик может обладать одной либо несколькими сетями (Customer Network), и любая такая сеть состоит из одной либо нескольких виртуальных субсетей (Virtual Subnet).

Customer Network

Сеть заказчика определяет границу изоляции виртуальных машин. Другими словами, ВМ, принадлежащие одной сети заказчика, могут вести взаимодействие меж собой. Как следствие, виртуальные сабсети, принадлежащие одной сети заказчика, не должны использовать пересекающиеся места Айпишников.
Любая сеть заказчика идентифицируется при помощи специального идентификатора 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.

Применение этих 2-ух понятий позволяет заказчику переносить свою сетевую топологию в скопление. На рис. ниже изображены две сети компании «Синие» — сеть R&D и сеть отдела продаж. Вначале эти сети изолированы и не должны вести взаимодействие меж собой. Так как при переносе в среду Hyper-V Network Virtualization этим сетям присвоены разные RDID, ВМ этих сетей не могут «видеть» друг дружку. При всем этом, к примеру, ВМ из виртуальных субсетей 1, 2 и 3 сети R&D могут обмениваться пакетами.

Виртуализация сети в Hyper-V. Концепция
Прирастить

Архитектура 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, принадлежащие различным заказчикам.

Виртуализация сети в Hyper-V. Концепция
Прирастить

Если для ВМ врубается виртуализация сети, то для портов Hyper-V Extensible Switch, к которым подключены виртуальные сетевые адаптеры этой ВМ, гипервизор включает списки управления доступом (Access Control List, ACL). Подробнее об ACL я говорил тут. В ACL указывается VSID виртуальной сабсети, которой принадлежит ВМ. Любые пакеты, приходящие на данный порт свитча, с VSID, хорошим от данного в ACL, игнорируются.

Приняв эту логику во внимание, перемещение пакетов смотрится последующим образом. Исходящий от ВМ пакет через порт Hyper-V Extensible Switch попадает в фильтр WNV, который анализирует политику виртуализации NV и применяет к пакету нужные операции (подмена Айпишники либо упаковка в 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 в 3-ем модуле курса « Windows Server 2012: сетевая инфраструктура»;
скачать необычную презентацию (на англ.), слайды из которой я использовал в этом посте, с детализированным описанием процесса передачи пакетов (packet flow) в NV.

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.