В нескольких прошлых постах, посвященных технологии виртуализации сети (Hyper-V Network Virtualization, HNV), я сказал об архитектуре, настройках, также о новых способностях HNV в Windows Server 2012 R2. Сейчас пойдет речь о, пожалуй, самой сложной теме – построении HNV-шлюза на базе Windows Server 2012 R2 для предоставления виртуализованным сетевым секторам доступа во окружающий мир. Будет много снимков экрана.

Почти всегда виртуальным машинам (ВМ), развернутым в виртуализованных сетях, нужно взаимодействие с наружным миром – для связи с другими объектами ЦОДа, для выхода в Веб, для доступа к корпоративной сети компании, которая расположила в ЦОДе эти самые ВМ и пр. Применительно к технологии HNV наружным миром является все что угодно, находящееся за пределами виртуализованной сети. И до того как двигаться далее, нужно еще раз обусловиться с терминологией, которая за два года существования HNV немного поменялась.

Терминология

Итак, определяющим понятием HNV является сеть заказчика (Customer Network), владеющая уникальным идентификатором Routing Domain ID (RDID). Это и есть та виртуализованная сеть. Для Customer Network существует несколько синонимов, зависимо от того, каким инвентарем вы пользуетесь:

в VMM это VM Network;
в PowerShell это Routing Domain;
в почти всех статьях и блогах это Tenant либо Tenant Virtual Network.

Но все эти определения сущность Customer Network. Любая сеть заказчика состоит из одной либо более виртуальных субсетей (Virtual Subnet), и у каждой виртуальной сабсети есть собственный уникальный 24-битный идентификатор VSID. Маршрутизация пакетов меж ВМ, принадлежащими одной сети заказчика, осуществляется автоматом, независимо от того, размещены ли эти машины в одной виртуальной сабсети либо в различных, на одном физическом хосте, либо на различных. А вот если нужна связь с наружным миром, другими словами нужно передать пакеты за границы Customer Network, то должен быть настроен HNV-шлюз (HNV Gateway, HNVGW).

Варианты реализации шлюза

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

от nAppliance
от Iron Networks
от F5

В этом посте я сосредоточусь на разработке HNV-шлюза на базе Windows Server 2012 R2, при всем этом управление HNV в моей демонстрационной сети, в том числе настройка шлюза, будет осуществляться при помощи System Center 2012 R2 Virtual Machine Manager (VMM). Используя дальше сокращение VMM, я предполагаю конкретно версию R2, если очевидно не обозначено другое.

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

Архитектура шлюза

Архитектурно HNV-шлюз на базе Windows Server 2012 R2 представляет собою физический хост, на котором запущена одна либо несколько ВМ, выполняющих маршрутизацию пакетов из виртуализованных сетей во окружающий мир и назад. Обращаю внимание, это конкретно физический хост. Воплотить HNV-шлюз просто в виде виртуалки не получится уже хотя бы поэтому, что для инкапсуляции пакетов (см. пост о концепции HNV) нужна роль Hyper-V, а вложенную виртуализацию Hyper-V не поддерживает.

Справедливости ради необходимо отметить, что на техническом уровне шлюз можно выстроить и на базе Windows Server 2012. Но при всем этом, во-1-х, шлюз с Windows Server 2012 востребует пуска стольких ВМ, сколько у вас Customer Networks, и масштабирование такового решения проблемно. Во-2-х, для управления таким шлюзом при помощи VMM нужно будет написать провайдер для VMM. Внедрение же Windows Server 2012 R2 + System Center 2012 R2 Virtual Machine Manager – это фактически готовый HNV-шлюз «из коробки». В Windows Server 2012 R2 реализован мультитенантный шлюз, позволяющий использовать одну ВМ для маршрутизации трафика разных виртуализованных сетей, а в System Center 2012 R2 Virtual Machine Manager уже встроен провайдер для управления таким шлюзом.

Какие варианты работы HNV-шлюза есть? Таких два.

Private Cloud (Routing)

1-ый вариант реализует маршрутизацию трафика из Customer Network в сеть ЦОДа, при этом маршрутизация может быть как прямой, так и c трансляцией адресов (NAT).

На рисунке изображена ровная маршрутизация, которая имеет смысл, если места CA-адресов различных тенантов (Customer Networks) не пересекаются и им нужен доступ в корпоративную сеть. Либо, как на рисунке, есть только один тенант с несколькими подсетями. Для личного облака, когда тенанты, к примеру, представляют собой виртуализованные сети разных департаментов большого предприятия, полностью вероятный вариант.

При использовании NAT каждому тенанту HNV-шлюз ставит в соответствие выделенный Айпишник на собственном наружном интерфейсе, и все пакеты от виртуальных машин тенанта отправляются во окружающий мир с этим выделенным IP в поле «IP-адрес отправителя».

Hybrid Cloud (Site to site VPN)

2-ой вариант подразумевает построение туннеля типа «сеть-сеть» от HNV-шлюза до нужной точки, к примеру, через Веб до корпоративной сети заказчика.

Прирастить

Это как раз типовой хостерский сценарий, когда ВМ заказчика размещаются в ЦОДе хостера и связываются через VPN с сетью заказчика. Разработка HNV при всем этом позволяет заказчику сохранить опции IP и не страшиться за работоспособность софта снутри ВМ, а хостеру – расположить у себя виртуалки с подходящими заказчику IP, изолируя эти виртуалки от других ВМ и не настраивая VLANы.

Завершая строительный раздел поста, отмечу коротко, в чем все-таки заключается мультитенантность шлюза на базе Windows Server 2012 R2.

Представьте для себя, что в ЦОДе виртуализованы сети 2-ух заказчиков, Contoso и Woodgrove, использующие полностью схожие CA-пространства: 10.0.0.0/24. Как «развести» пакеты этих заказчиков на HNV-шлюзе? 1-ое вероятное решение – сделать на шлюзе для каждого заказчика свою ВМ и указать ее в настройках соответственной сети заказчика в качестве default gateway. Таким макаром, пакеты, направленные во окружающий мир из Contoso, всегда будут приходить на сетевой интерфейс одной ВМ шлюза, пакеты из Woodgrove – на интерфейс 2-ой ВМ и т. д. Как упоминалось, шлюз на базе Windows Server 2012 конкретно таковой подход и использовал бы.

Прирастить

В Windows Server 2012 R2 для маршрутизации появилась возможность использовать так именуемые ячейки (compartments). В виртуальной машине для каждого тенанта создается некоторый объект «ячейка» (compartment), в которую врубаются виртуальные сетевые интерфейсы, Айпишника, таблица маршрутизации, ARP-таблица и пр. Элементы одной ячейки изолированы от частей другой ячейки. Маршрутизация пакетов от Contoso, таким макаром, осуществляется в рамках соответственной ячейки и не пересекается, не оказывает влияние на маршрутизацию пакетов Woodgrove в другой ячейке, даже если записи в таблицах маршрутизации этих ячеек смотрятся идиентично. Таковой подход позволяет использовать одну ВМ для маршрутизации пакетов различных тенантов без каких-то конфликтов.

Прирастить

Как видно на рис. выше, существует ячейка по дефлоту (default compartment), которая содержит в себе сетевые опции, задаваемые при разработке ВМ, и две ячейки для тенантов, показавшиеся в процессе опции HNV-шлюза.

Создание шлюза

Подкрепившись теорией, перейдем конкретно к созданию шлюза. Для простоты я рассмотрю вариант шлюза без кластеризации, хотя понятно, что в реальном ЦОДе таковой принципиальный элемент виртуализации подразумевает работу в режиме высочайшей доступности. Детализированный документ о том, как сделать HNV-шлюз высокодоступным можно отыскать тут.

Главные шаги по созданию шлюза содержат в себе последующее:

настройка логических сетей и сетей ВМ;
настройка хоста для роли шлюза
подготовка ВМ для шлюза
добавление шлюза в VMM
настройка шлюза для определенных сетей ВМ

Давайте по порядку.

Настройка логических сетей и сетей ВМ

Этот пункт достаточно тщательно описан в одном из прошлых постов, потому покажу только, как логические и виртуальные сети смотрятся у меня в лабораторном свечном ЦОДике Contoso.

Прирастить

Для нашей задачки необходимы три логические сети: наружный сектор (Contoso_External_LN01), сеть для управления шлюзом (Contoso_Management_LN01) и сеть (Contoso_HNV_LN01), поверх которой фактически создаются виртуализованные сети. IP-пул сети Contoso_HNV_LN01 задает PA-пространство, а в свойствах этой сети непременно должен быть помечен чекбокс, разрешающий внедрение технологии HNV.

Прирастить

Сети ВМ (VM Networks, они же сети заказчиков, они же Customer Networks) смотрятся так:

Прирастить

Вы видите две сети ВМ для компаний Adatum и Fabrikam, использующие пересекающееся адресное место (10.30.1.0/24). В колонке Gateway Connection видно, что пока ни одна из сетей ВМ не употребляет шлюз.