Одной из главных компонент нового Hyper-V в Windows Server 2012 является Hyper-V Extensible Switch. Hyper-V Extensible Switch представляет собой программный управляемый коммутатор второго уровня, обладающий рядом интересных возможностей, среди которых поддержка технологии Private VLAN (PVLAN). Я вкратце опишу реализацию PVLAN в свиче Hyper-V и в большей степени сосредоточусь на вопросах настройки частных VLAN-ов для виртуальных машин (ВМ). Посмотреть технологию в действии вы можете в первой демонстрации веб-каста, посвященного новым возможностям Hyper-V в Windows Server 2012.
Суть PVLAN-ов уже обсуждалась на Хабре, в частности здесь. Применительно к Hyper-V вы можете присвоить каждому порту Hyper-V Extensible Switch один основной (первичный или Primary VLAN ID) идентификатор и один или несколько вторичных (Secondary VLAN ID). В отличие от аппаратного свича с конкретным количеством портов, порт на свиче Hyper-V идентифицируется виртуальной машиной, а еще точнее сетевым адаптером (поскольку их может быть несколько) виртуальной машины, подключенным к этому порту. Поэтому здесь и далее, задать настройки для порта Hyper-V Extensible Switch = задать настройки для соответствующей виртуальной машины.
Итак, при настройке PVLAN-ов и указании Primary и Secondary VLAN ID соответствующий порт может быть сконфигурирован в одном из трех режимов:
- promiscuous (смешанный) – в этом режиме ВМ может обмениваться пакетами с любыми портами у которых совпадает Primary VLAN ID;
- community (общий) – в этом режиме ВМ может обмениваться пакетами с любыми другими портами, сконфигурированными в community режиме, у которых совпадают и Primary, и Secondary VLAN ID; кроме того (см. выше), ВМ может взаимодействовать с promiscuous-портами, у которых такой же Primary VLAN ID;
- isolated (изолированный) – в этом режиме ВМ может взаимодействовать только с promiscuous- портами c таким же Primary VLAN ID.
Кроме того надо отметить, что Hyper-V Extensible Switch переводит в режим trunk порт, который «смотрит» на физический сетевой адаптер хоста. При условии, что ваши аппаратные свичи не блокируют тегированные пакеты, логика работы рассмотренных режимов не зависит от того, запущены ли ВМ на одном физическом хосте с Windows Server 2012 или на разных.
Одним из основных вариантов применения PVLAN является дополнительная изоляция ВМ, запущенных в вашем ЦОД-е и принадлежащих разным отделам, департаментам или организациями. Поясню на примере. Предположим, на одном хосте запущено четыре ВМ (см. рис. ниже). SRV1 и SRV2 принадлежат, скажем, отделу продаж, в них запущены какие-либо компоненты приложения, например в одной SharePoint, в другой SQL Server с базой данных SharePoint. SRV4 принадлежит финансовому департаменту и должна быть изолирована от ВМ других отделов. Наконец, в SRV3 запущены сервисы, которые необходимы всем ВМ данного хоста или нескольких хостов. Возможный вариант решения этой задачи с помощью PVLAN:
- Конфигурируем SRV1 и SRV2 в community-режиме с Primary VLAN ID = 2 и Secondary VLAN ID = 5; разумеется, конкретные значения идентификаторов определяете вы сами;
- Конфигурируем SRV4 в режиме isolated с Primary VLAN ID = 2 и Secondary VLAN ID = 4;
- Конфигурируем SRV3 в режиме promiscuous с Primary VLAN ID = 2 и Secondary VLAN ID = 4 и 5.
Теперь давайте реализуем эту задачу в Windows Server 2012. Начнем с SRV4. Настройка PVLAN осуществляется командлетами PowerShell. Как отмечалось, порт свича Hyper-V идентифицируется сетевым адаптером ВМ, подключенной к этому порту. Проще всего получить информацию о сетевых адаптерах ВМ с помощью команды Get-VMNetworkAdapter, указав в качестве параметра имя ВМ:
Как видно, в SRV4 существует единственный сетевой адаптер с именем, совпадающим с именем самой виртуальной машины – SRV4. Текущие настройки VLAN соответствующего порта Hyper-V Extensible Switch можно увидеть с помощью Get-VMNetworkAdapterVlan:
Сейчас SRV4 находится в режиме Access с единственным VLAN ID, равным нулю. Это настройка по умолчанию для ВМ равносильная тому, что нет вообще никаких VLAN-ов. И в таком же состоянии находятся пока все остальные ВМ: SRV1, SRV2, SRV3. Включаем нужный нам режим для SRV4 командой Set-VMNetworkAdapterVlan:
Set-VMNetworkAdapterVlan -VMName srv4 -VMNetworkAdapterName srv4 -Isolated -PrimaryVlanId 2 -SecondaryVlanId 4Параметрами -VMName и -VMNetworkAdapterName указываем имена ВМ и сетевого адаптера соответственно, остальными параметрами указываем режим и Primary и Secondary VLAN ID. Проверяем настройки:
Обратите внимание, что начиная с этого момента, SRV4 не может взаимодействовать с другими ВМ, пока мы не настроим должным образом PVLAN и для них. Сделаем это соответствующими командами, используя конвейер команд PowerShell, где результат выполнения одной команды передается на вход следующей:
Get-VMNetworkAdapterVlan -VMName srv3 | Set-VMNetworkAdapterVlan -Promiscuous -PrimaryVlanId 2 -SecondaryVlanIdList 4-5
Get-VMNetworkAdapterVlan -VMName srv2 | Set-VMNetworkAdapterVlan -Community -PrimaryVlanId 2 -SecondaryVlanId 5
Get-VMNetworkAdapterVlan -VMName srv1 | Set-VMNetworkAdapterVlan -Community -PrimaryVlanId 2 -SecondaryVlanId 5Замечу, что в первой команде список Secondary VLAN ID задан диапазоном. Кроме того, можно задать различные значения идентификаторов, перечислив их через запятую и заключив в кавычки: -SecondaryVlanIdList “4,5”.
В любой момент можно вернуть настройки в исходное состояние, например для SRV4 выполнив:
В заключение, несколько слов о режиме trunk. Как я упоминал выше, Hyper-V переводит в режим trunk порт, к которому подключен физический сетевой адаптер. Но если необходимо, в trunk-режим можно переключить любую ВМ, чтобы она могла принимать пакеты с различными VLAN ID. Для все той же SRV4 команда будет выглядеть как:
Здесь -AllowedVlanIdList задает список разрешенных VLAN ID, как Primary, так и Secondary, а параметр -NativeVlanId указывает, к какому VLAN-у будут относиться нетегированные пакеты.
Таким образом, поддержка технологии PVLAN наряду с другими возможностями Hyper-V Extensible Switch поможет обеспечить дополнительный уровень изоляции ВМ в рамках мультитенантной архитектуры.
Автор: ashapo
