Виртуализация сети в Hyper-V. Настройка HNV-шлюза на базе Windows Server 2012 R2

В нескольких предыдущих постах, посвященных технологии виртуализации сети (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. Но при этом, во-первых, шлюз с Windows Server 2012 потребует запуска стольких ВМ, сколько у вас Customer Networks, и масштабирование такого решения затруднительно. Во-вторых, для управления таким шлюзом с помощью 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)

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

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

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

Hybrid Cloud (Site to site VPN)

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


Увеличить

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

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

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


Увеличить

В Windows Server 2012 R2 для маршрутизации появилась возможность использовать так называемые ячейки (compartments). В виртуальной машине для каждого тенанта создается некий объект «ячейка» (compartment), в которую включаются виртуальные сетевые интерфейсы, IP-адреса, таблица маршрутизации, 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 видно, что пока ни одна из сетей ВМ не использует шлюз.