Hyper-V, VLAN и все-все-все

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

На одном физическом сервере мы поднимали инфраструктуру из виртуальных машин, две из которых должны были работать во внутренней сети, а две других должны были быть подключены к внешним сетям (у нас подходит два канала от двух провайдеров). В качестве платформы виртуализации использовался Hyper-V на Windows Server 2008 Enterprise. Использование Enterprise редакции для платформы виртуализации позволяет по одной лицензии на хостовую машину установить еще 4 виртуальных сервера Windows Server 2008, что весьма выгодно в плане стоимости.

На физическом сервере установлено две сетевые карты, поэтому сразу три канала подключить не получилось. Для того чтобы дать возможность виртуальным машинам работать со всеми тремя каналами, мы решили использовать технологию 802.1Q. В какой-то ситуации, возможно, будет проще приобрести еще одну сетевую карту, однако применение VLAN позволяет воплотить в жизнь много интересных сценариев.

Сценарий, который мы применили, был достаточно прост:

На свитче создаются два VLAN, соответствующие двум провайдерам. В каждый VLAN добавляются access порты, в которые подключены провода, идущие от провайдеров, и то оборудование, которое должно смотреть в них напрямую (в данном случае, один служебный сервер, пара VPN железок и IP камера). Далее создается один транковый порт, в который подключается провод, идущий на хостовую машину. Через вторую сетевую карту хостовая машина имеет доступ к локальной сети. Таким образом, получается жесткое разделение сред и контроль над подключенным сетевым оборудованием.

Теперь о реализации.

В качестве свитча используется AT 9448T. Это управляемый 48 портовый свитч. Самый простой способ произвести настройку – подключиться через консольный порт тем же Putty. Достаточно просто выбрать вариант serial и установить скорость 115200. Появится черный экран, где надо будет нажать Enter, после чего появится приглашение. На всякий случай — стандартный логин/пароль у Телесинов – manager/friend (на старых свитчах, например, он был manager/Ctrl + ati).

Стандартный интерфейс настройки выглядит так:

Однако, можно переключиться и в режим CLI, нажав C, как написано в меню (чтобы вернуться обратно, необходимо набрать команду menu). Мне больше нравится интерфейс с меню, для повседневных операций он удобнее.

Чтобы создать VLAN, необходимо зайти в меню VLAN Configuration, а там в Configure VLANs. Это меню позволяет создавать/изменять/удалять VLAN’ы. Сейчас необходимо создать. Для этого надо выбрать пункт Create VLAN и в появившемся меню настроить нужные параметры:

Чтобы изменить параметр, необходимо нажать цифру, соответствующую нужному пункту.

После того, как все настроено, необходимо нажать C — Create VLAN.

Соответственно, Tagged Ports — порты на которых трафик маркируется, Untagged Ports — обычные порты, которые не маркируют трафик, то есть обычный access port.

В данном случае, в Untagged Ports загонялись порты, в которые подключены линки от провайдеров, оборудование, которое должно смотреть напрямую в канал провайдера, а в Tagged Ports ставился порт, который подключается к хостовой машине, тот самый транк.

Результат настройки приведен на рисунке:

Теперь стоит сохранить конфигурацию. Для этого в главном меню надо нажать S – Save Configuration (этот пункт появляется после внесения изменений в конфигурацию). Дополнительно стоит включить RSTP (полезный протокол, например, позволит защититься от петель, он настраивается в меню Spanning Tree Configuration), настроить интерфейс (настраивается в меню System Administartion -> System Configuration), что позволит использовать SSH (настраивается в Security and Services), собирать информацию со свитча по SNMP (настраивается в System Administartion -> SNMP Configuration ). Но это все уже отдельная тема.

Следующий этап настройки — научить виртуальные машины общаться с нашим свитчом.

Для этого необходимо скачать с сайта производителя сетевой карты последнюю версию драйверов и утилит. В нашем случае это Intel Pro 1000 PM. Поэтому отправляемся на сайт Интела в раздел загрузки (http://downloadcenter.intel.com/default.aspx?lang=rus&iid=subhdr-RU+downloads) и выбираем нужное устройство. Качаем пакет (он называется Intel Ethernet Connections CD — http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3019&DwnldID=18664&lang=rus). Он несет в себе последнюю версию драйверов, набор PROSet и ANS (advanced network services). После установки перезагрузка не требуется. Теперь PROSet не имеет отдельного меню и значка в трее, он интегрируется в диспетчер задач.

Общие просетовские настройки:

Работа с VLAN:

Работа с teams:

Также, тут есть одна интересная тонкость.

Одновременно к адаптеру может быть привязан либо ANS, либо протокол коммутации виртуальных сетей. Это означает, что если адаптер привязан к виртуальной машине, то настроить на нем VLAN или добавить его в Team не получится (этих вкладок тоже не будет), что, в принципе, логично.

Поэтому, если адаптер используется Hyper-V, нужно убрать с него привязку, чтобы можно было произвести конфигурацию. Единственное, отвязывать интерфейсы надо аккуратно, желательно имея возможность физического доступа, если что-то пойдет не так. Самый идеальный вариант — IP KVM. У Dell, например, есть замечательная штука – iDRAC, которая дает полное удаленное управление физическим сервером.

Собственно, теперь для выполнения нашей задачи необходимо создать два VLAN. Для этого на соответствующей вкладке PROSet необходимо нажать New и указать тот VID, который мы дали соответствующему VLAN’у при настройке свитча. После добавления обоих VLAN’ов будут созданы два виртуальных адаптера, которые уже можно будет забиндить виртуальным машинам.

В результате получится следующая картина:

На ней:

cbs и trunk – два физических адаптера. cbs – подключен к внутренней сети, trunk – к транковому порту на свитче.

cbs_virtual – виртуальный адаптер, созданный в диспетчере виртуальной сети Hyper-V, который подключается к виртуальным машинам.

VLAN_comcor и VLAN_tascom – соответственно виртуальные адаптеры, которые созданы при помощи PROSet на адаптере trunk и промаркированы соответствующими тегами.

virtual_comcor и virtual_tascom – также виртуальные адаптеры, созданные в диспетчере виртуальной сети Hyper-V, которые подключаются к виртуальным машинам.

Теперь приведу иллюстрацию глазами диспетчера виртуальной сети Hyper-V:

Таким образом, для Hyper-V существует три сетевых адаптера, которые он может дать виртуальным машинам.

И уже финальный шаг – привязка адаптера к виртуальной машине:

Здесь необходимо также указать VID того VLAN’а, к которому подключен данный интерфейс.

Таким образом, получается, что данный сетевой адаптер подключен к транковому каналу и на основе маркировки кадров он определяется как входящий в VLAN, к которому подключен провайдер Комкор. Однако виртуальная машина ничего об этом не знает, для нее существует только линк до роутера провайдера.

Данный подход, на мой взгляд, довольно прост и гибок, но при этом позволяет делать весьма сложные схемы коммутации.