В прошлый раз я описал концепцию и общую архитектуру Hyper-V Network Virtualization (NV) – технологии Windows Server 2012, обеспечивающей виртуализацию на уровне сетевого сегмента. Сегодня речь пойдет о настройке этой технологии с помощью PowerShell и System Center 2012 SP1 Virtual Machine Manager (VMM).
Настройка Hyper-V Network Virtualization с помощью PowerShell
На хосте с развернутой ролью Hyper-V доступно несколько командлетов PowerShell, с помощью которых выполняется настройка требуемой конфигурации NV. Основных командлета четыре:
Как обычно для PowerShell, существуют аналогичные команды с префиксами Get-, Set-, Remove- для получения текущих параметров, изменения и удаления соответственно.
Еще пара командлетов, Get-NetVirtualizationGlobal и Set-NetVirtualizationGlobal позволяют определить (и, соответственно, задать), используется ли внешний Gateway для маршрутизации трафика.
Самый простой способ познакомиться с перечисленными командлетами – изучить и попробовать применить в тестовой среде два скрипта-примера, разработанных моими коллегами. Каждый скрипт содержит детальные комментарии, описание моделируемой среды и указание на те переменные и константы, которые вам необходимо заменить на собственные значения. Найти и скачать скрипты можно здесь:
Проверял лично, работает. :) Но, думаю очевидно, что в масштабах ЦОД-а манипуляция подобными скриптами превращается в крайне сложную задачу. Поэтому далее гораздо более детально я рассмотрю настройку NV с помощью VMM.
Настройка Hyper-V Network Virtualization с помощью System Center 2012 SP1 Virtual Machine Manager
Технология NV является частью Hyper-V в Windows Server 2012. System Center поддерживает Windows Server 2012, начиная с версии System Center 2012 SP1. Здесь и далее речь идет о VMM именно из System Center 2012 SP1. Я предполагаю, что VMM уже развернут, хосты Hyper-V в него добавлены, поэтому буду обращать внимание только на те настройки, которые непосредственно связаны с NV.
Настройка NV с помощью VMM состоит из следующих шагов:
- Включение фильтра Windows Network Virtualization (WNV) на хостах с поднятой ролью Hyper-V.
- Включение NV для нужных логических сетей.
- Создание сетей виртуальных машин (VM Network) и пулов IP-адресов.
- Создание шаблонов виртуальных машин (VM Template) с привязкой к нужным сетям виртуальных машин.
- Развертывание ВМ с использованием подготовленных в п. 4 шаблонов.
Рассмотрим последовательно каждый шаг.
Включение фильтра Windows Network Virtualization (WNV)
Вручную
Напомню, что правила, определяющие работу NV, задаются в так называемой политике виртуализации. Определенные настройки, заданные в политике виртуализации, непосредственно к сетевым пакетам применяются драйвером-фильтром уровня NDIS (Network Driver Interface Specification), называемым Windows Network Virtualization (WNV). Этот фильтр необходимо включить на тех хостах Hyper-V, на которых планируется использовать NV. Вручную это делается в свойствах физического сетевого адаптера хоста. Подчеркиваю, именно физического адаптера, а не виртуального, который, как правило, создается при настройке внешнего свитча Hyper-V.
.png)
С помощью Logical Switch
В качестве альтернативы ручной настройке можно использовать появившийся в VMM 2012 SP1 механизм логических свитчей (Logical Switch). Более подробное описание настроек сети в VMM можно найти вот в этом посте Георгия Гаджиева. Здесь же кратко упомяну, что логический свитч необходим для того, чтобы применить заданный набор настроек к сетевым адаптерам и свитчам Hyper-V Extensible Switch на множестве хостов. Найти описанные ниже настройки можно в разделе «Fabric», подразделе «Networking» консоли VMM. Фактически в логическом свитче можно задать три группы настроек: настройки для физических сетевых адаптеров хостов, настройки для виртуальных сетевых адаптеров ВМ (а точнее, для портов Hyper-V Extensible Switch, к которым ВМ подключаются) и настройки для расширений (extensions) Hyper-V Extensible Switch.
Первая группа настроек, а именно она нас больше всего интересует, задается путем создания специального профиля, который называется Uplink Port Profile. В профиле необходимо установить чекбокс, показанный на рисунке, благодаря которому и будет в дальнейшем включен фильтр WNV.
_mini_oszone.png)
Увеличить
Вторая группа настроек задается путем создания профиля, который называется Virtual Adapter Port Profile. В этом профиле нет настроек, напрямую связанных с NV, но именно там можно задать различные параметры безопасности свитча (например, DHCP Guard), производительности (например, IP Sec offload), ограничения трафика (Quality of Service).
Ну а далее при создании логического свитча можно указать необходимые расширения для Hyper-V Extensible Switch, выбрать Virtual Adapter Port Profile и, самое главное, добавить Uplink Port Profile, в котором мы пометили чекбокс «Enable Windows Network Virtualization».
_mini_oszone.png)
Увеличить
Тем самым, мы создали некоторый набор настроек в виде логического свитча. Остается применить созданный логический свитч к требуемым хостам Hyper-V, а как следствие, применятся к хостам и все настройки этого логического свитча. Для этого в консоли VMM в свойствах хоста переходим на закладку Virtual Switches, нажимаем «New Virtual Switch», затем «New Logical Switch» и выбираем нужный логический свитч. Проверяем, что для требуемого физического сетевого адаптера применяется тот самый Uplink Port Profile.
_mini_oszone.png)
Увеличить
Включение NV для логических сетей
Следующий шаг – включение NV для требуемых логических сетей (Logical Networks). Логические сети в VMM позволяют администратору описать физическую сетевую топологию ЦОД-а. Это описание в дальнейшем помогает существенно упростить подключение ВМ к требуемым сетевым сегментам. Похожим образом администратор Active Directory (AD) с помощью сайтов и подсетей описывает физическую сеть предприятия для оптимизации трафика репликации AD. Применительно же к NV логические сети VMM не просто описывают реальную сетевую топологию, но и определяют пространство PA-адресов, которые будут использоваться для передачи пакетов между ВМ на разных хостах.
Итак, представим себе, что в физической сети используется IP-адресация из диапазона 192.168.1.0/24. Нам же необходимо поверх этой сети виртуализовать сети двух компаний ОАО «Синие» и ОАО «Красные». Причем обе компании используют одинаковый диапазон IP-адресов, а именно: 10.0.0.0/24.
Создаем логическую сеть (кнопка меню «Create Logical Network») и на первом же экране разрешаем для этой сети NV:
_mini_oszone.png)
Увеличить
На следующем экране создаем сайт и указываем, какие группы хостов могут этот сайт использовать (фактически в нем располагаются) и какие IP-подсети этому сайту принадлежат.
_mini_oszone.png)
Увеличить
Теперь для этой логической сети необходимо создать пул IP-адресов. В контексте NV именно из этого пула VMM будет выделять PA-адрес и ассоциировать с ВМ и настроенными внутри них CA-адресами. В консоли VMM нажимаем «Create IP Pool», задаем имя пула и на следующем экране указываем для какого сайта и какой IP-подсети создаем пул.
_mini_oszone.png)
Увеличить
Затем необходимо задать диапазон IP-адресов и, если требуется, какие-то адреса зарезервировать. Например так:
_mini_oszone.png)
Увеличить
На последующих экранах можно указать адрес шлюза по умолчанию, а также адреса серверов DNS и WINS. Теперь, когда логическая сеть создана и настроена, остается указать, какие конкретно хосты Hyper-V будут с ней ассоциированы, или иными словами, на каких хостах могут быть запущены ВМ, требующие доступ к этой сети. В свойствах хостов на закладке «Hardware» надо выбрать сетевой адаптер хоста и пометить соответствующую логическую сеть.
_mini_oszone.png)
Увеличить
Создание сетей виртуальных машин (VM Network) и пулов IP-адресов
На предыдущих шагах мы включили фильтр WNV и настроили логическую сеть с пулом IP-адресов, который будет использоваться для выделения PA-адресов. Таким образом, мы подготовили физическую инфраструктуру или, в терминологии VMM, подготовили Fabric. Теперь поверх этой инфраструктуры можно создавать и виртуализовывать произвольные сети клиентов нашего ЦОД-а. В рассматриваемом сценарии этими клиентами, как вы помните, являются компаний ОАО «Синие» и ОАО «Красные», использующие одинаковую подсеть 10.0.0.0/24.
С выходом SP1 для System Center 2012 в VMM появился новый тип объектов – сеть виртуальных машин (VM Network), далее просто «сеть ВМ». В первую очередь, этот тип объектов предназначен для NV, хотя, как вы увидите в дальнейшем, даже если NV не используется, как минимум одну сеть ВМ создать необходимо. Ну а в нашем случае, очевидно, нужно создать две сети ВМ для «Синих» и «Красных» соответственно. Процесс этот очень похож на создание логической сети – мы создаем сеть ВМ, определяем в ней один или несколько сайтов с указанием подсетей, затем создаем для подсетей пулы IP-адресов. Но эти пулы уже будут использоваться для выделения CA-адресов виртуальным машинам.
Итак, в консоли VMM переходим в раздел «VMs and Services» и нажимаем кнопку «Create VM Network». В первом окне задаем имя создаваемой сети и выбираем из списка логическую сеть, поверх которой будет работать данная сеть ВМ.
_mini_oszone.png)
Увеличить
Следующий шаг весьма важный. Коль скоро мы настраиваем NV, выбираем верхний пункт. Он будет доступен для выбора только в том случае, если для логической сети, указанной на предыдущем шаге, была включена поддержка NV, что мы уже сделали.
_mini_oszone.png)
Увеличить
Но здесь же хотел бы обратить ваше внимание на вторую опцию «No Isolation». Если выберем ее, то укажем тем самым VMM, что виртуальные машины этой сети должны напрямую (без изоляции) подключаться к логической сети. Никаких дополнительных настроек в этом случае уже не потребуется. Создаваемые затем ВМ буду получать IP-адреса из пулов, настроенных непосредственно в логической сети. То есть опцию «No Isolation» вы выбираете в том случае, когда технология NV вам не нужна. И поэтому закономерно, что для каждой логической сети можно создать только одну сеть ВМ без изоляции.
Мы же двигаемся дальше и в следующем окне создаем подсеть (одну или несколько), которая требуется клиенту.
_mini_oszone.png)
Увеличить
На завершающем экране мастера выбираем способ взаимодействия ВМ создаваемой сети с внешним миром. Поскольку мы не настраивали специально внешний шлюз (об этом речь пойдет в следующем посте), то выбор здесь один – «No Connectivity», означающий, что ВМ смогут взаимодействовать только в пределах этой сети ВМ.
_mini_oszone.png)
Увеличить
Последняя задача данного этапа – настроить для созданной сети ВМ пулы адресов, то есть CA-адреса. В консоли VMM выбираем сеть ВМ и нажимаем «Create IP Pool». На первом экране проверяем, что указаны нужные сеть ВМ и подсеть:
_mini_oszone.png)
Увеличить
На втором задаем диапазон IP-адресов для ВМ:
_mini_oszone.png)
Увеличить
Указываем шлюз по умолчанию:
_mini_oszone.png)
Увеличить
При необходимости задаем далее адреса серверов DNS и WINS. Сеть «Красных» настроена. Повторяем процедуру для ОАО «Синие» и в результате получаем вот такую картину:
_mini_oszone.png)
Увеличить
Настройка собственно виртуализации сети на этом завершена. Если вспомнить концепцию и архитектуру NV, описанные мною в предыдущем посте, то становится понятно, что VM Network соответствует термину Customer Network, а VM Subnet – термину Virtual Subnet. Действительно, если с помощью командлетов Get-SCVMNetwork и Get-SCVMSubnet получить информацию о созданных только что нами объектах, то в отклике первого командлета среди прочего вы увидите Routing Domain ID (RDID), а второго – Virtual Subnet ID (VSID).
Остается создать шаблоны ВМ для каждой сети, и на их основе можно будет развертывать требуемое количество «Синих» и «Красных» ВМ.
Создание шаблонов виртуальных машин (VM Template)
Процедура создания шаблонов для ВМ, которые будут использовать NV, совершенно стандартная и по сути ничем не отличается от создания шаблонов для любых других ВМ. Единственное, на что надо обратить внимание, что виртуальный сетевой адаптер подключен к нужной сети ВМ. Например, для шаблона «Красных» эта настройка выглядит следующим образом:
.png)
Параметр «Static IP» указывает VMM на то, что при создании ВМ по этому шаблону необходимо выделить статический IP-адрес из пула, связанного с сетью Red_VMnet01. А поскольку для этой сети включена технология NV, то выделенный адрес будет CA-адресом. Кроме того, в процессе развертывания виртуальной машины VMM выделит из пула, связанного с соответствующей логической сетью, PA-адрес, ассоциирует пару CA-адрес / PA-адрес и пропишет необходимые строчки в политику виртуализации того хоста, на котором будет развернута ВМ. Если в ЦОД-е используется динамическая адресация, то IP-адреса могут выделяться не из пулов VMM, а из скопов DHCP-сервера, и в этом случае в шаблоне ВМ необходимо выбрать параметр «Dynamic IP».
Развертывание ВМ с использованием подготовленных шаблонов
Теперь все полностью готово, и можно разворачивать ВМ на основе подготовленных шаблонов. Нажимаем кнопку «Create Virtual Machine» и выбираем нужный шаблон.
.png)
Проверка результатов
Если все перечисленные шаги проделаны без ошибок, то для эксперимента можно создать пару «Красных» и пару «Синих» ВМ на одном или нескольких физических хостах Hyper-V и убедиться в том, что полученные ВМ работают с адресами из сети 10.0.0.0/24, возможно даже IP-адреса «Синих» и «Красных» полностью совпадают, но при всем при этом «Красные» видят друг друга и полностью изолированы от «Синих».
Давайте посмотрим, как выглядит отклик одного из упомянутых в начале поста командлетов в моей тестовой среде. Ниже фактически изображена политика виртуализации на одном из хостов:
_mini_oszone.png)
Увеличить
В частности видно, что машине Red-Web1 был выделен CA-адрес 10.0.0.2 (первый доступный адрес в пуле) и ассоциирован с PA-адресом 192.168.1.52. ВМ принадлежит подсети с VSID=15184632 и относится к Customer Network с идентификатором RDID={206146EB-F035-4A19-A625-054C49DEEBD7}.
Еще один очень интересный параметр «Rule» со значением «TranslationMethodEncap» говорит о том, что для виртуализации IP-адресов используется механизм NVGRE. Этот механизм применяется по умолчанию при настройке NV в VMM и рекомендуется для большинства сценариев виртуализации сети. Можно проверить работу механизма инкапсуляции, сделав c машины Red-Web1 ping на адрес 10.0.0.3 и посмотрев сетевым монитором на структуру передаваемых пакетов.
_mini_oszone.png)
Увеличить
Во-первых, можно наблюдать, что пинги передаются в виде GRE-пакетов между хостами с PA-адресами 192.168.1.52 и 192.168.1.53. Во-вторых, в заголовке GRE указано, что внутри лежит пакет некоторого протокола с номером 0x6558 (выделен на рисунке синим), каковым и является стандарт NVGRE. В-третьих, по спецификации NVGRE следующие 24 бита (обведены красным) содержат VSID. Действительно, если 0xE7B2F8 перевести в десятичный вид, получим VSID=15184632, что является подсетью «Красных».
Таким образом, мы настроили и выполнили проверку работоспособности технологии Hyper-V Network Virtualization. Однако пожалуй, это не более чем лабораторные испытания, поскольку мы не обеспечили взаимодействие ВМ с внешним миром. О том, как это выглядит с архитектурной точки зрения и как настраивается, поговорим в следующем посте.
А пока вы можете:
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
