В прошлом году мы рассказывали о Storage Spaces Direct? — ?программно-определяемом хранилище в Windows Server 2016. Сегодня поговорим еще об одной новинке Microsoft, на этот раз из области программно-определяемых сетей (SDN). Network Controller — это служба управления сетевой инфраструктурой в Windows Server 2016.

Содержание
Откуда пошли виртуальные сети?
Windows Server 2016: Network Controller
Службы Network Controller



Откуда пошли виртуальные сети?


VLAN. Первые виртуальные сети появились в 1998 году. Это были локальные виртуальные сети VLAN, работающие по протоколу IEEE 802.1Q. Технология позволяет разделять одну L2-сеть на множество логических L2-сетей. Но VLAN имеет ограничение, которое оказалось существенным с ростом количества сетей: максимальное количество соединений на одной L2-сети — 4096. Для его преодоления производители начали разрабатывать новые протоколы с большей масштабируемостью, например: IEEE 802.1ad и IEEE 802.1ah. Мы не будем останавливаться на них подробно и пойдем дальше.

VXLAN, STT и NVGRE. В 2011 году компании VMware, Arista и Cisco выпускают протокол VXLAN, позволяющий создавать до 16 миллионов логических L2-сегментов в одной сети. Параллельно с ними Microsoft создает протокол NVGRE похожей спецификации, который начинает развиваться в Windows Server 2012. Компания Nicira предлагает протокол STT. Вопрос с ограниченной масштабируемостью решен, можно создавать сколь угодно много сетей. С ростом сетей инфраструктура становится сложной в управлении, и появляется необходимость централизованной консоли для настройки виртуального и физического оборудования. Так возникает концепция программно-определяемых сетей (SDN) с централизованным управлением сетевой инфраструктурой.

SDN. Подход к управлению сетью при помощи унифицированных программных средств. Одной их первых технологию SDN представила компания Nicira. После покупки Nicira компания VMware создает продукт VMware NSX, используя протокол VXLAN.

В 2013 году Microsoft предлагает свою версию программно-определяемой сети в редакции Windows Server 2012R2 на базе протокола NVGRE. У протокола NVGRE было несколько недостатков:

  • управление виртуальными сетями в Windows Server 2012R2 осуществлялось только через Virtual Machine Manager (VMM). Он был точкой хранения всех конфигураций виртуальной инфраструктуры и единой точкой отказа.
  • производители оборудования в качестве основного протокола использовали VXLAN, и лишь немногие внедрили поддержку NVGRE.

В редакции Windows Server 2016 компания Microsoft представила новую реализацию программно-определяемых сетей уже на базе протокола VXLAN – Network Controller (NC). Доступна данная служба только в редакции Windows Server 2016 Datacenter. Давайте рассмотрим особенности Network Controller.

Windows Server 2016: Network Controller


Network Controller — единая точка управления и мониторинга для всех физических и виртуальных сетей домeна. С помощью него настраивается IP-подсети, VLAN, маршрутизаторы и межсетевые экраны. NС хранит информацию о топологии сети, балансирует трафик и задает правила NAT.

Глоссарий


Сервисы:

  • Virtual Network Management — служба управления виртуализованными сетями.
  • Software Load Balancer Management — служба балансировки трафика и правил NAT.
  • Firewall Management — служба настройки межсетевых экранов и листов контроля доступа к ВМ.
  • RAS Gateway Management — служба организации VPN-туннелей.
  • iDNS — служба создания виртуальных DNS-серверов.

Сети:

  • Backend Network (provider addresses, PA) — сеть с провайдерскими адресами. Здесь создаются виртуальные туннели и проходит трафик.
  • Management Network — сеть управления, через нее проходит трафик между компонентами SDN.
  • VM network (customer addresses, CA) — виртуализованная сеть, к которой подключены виртуальные машины.
  • Transit Network — транзитная сеть. По ней идет обмен трафиком между BGP и SLB Multiplexer/Gateway. По транзитной сети публикуются маршруты на BGP.

Службы на хосте:

  • Azure VFP Switch Extension — расширение свитча Hyper-V. Добавляет виртуальному свитчу функционал L3-коммутатора. Включает в себя distributed load balancer(DLB) и Distributed firewall (DFW).
  • Distributed load balancer — балансировщик трафика.
  • Distributed firewall — межсетевой экран, отвечает за выполнение правил доступа к ВМ.
  • Distributed router (vSwitch) — виртуальный маршрутизатор.
  • NC Host Agent — получает от NC информацию о виртуальных сетях и правилах Firewall.
  • SLB Host Agent — получает от NC правила балансировки.

Служебные виртуальные машины:

  • SLB multiplexer (MUX) — виртуальные машины Windows Server с ролью Software Load Balancing. На них содержится информация о правилах балансировки трафика. MUX публикуют маршруты на BGP и обрабатывают входящие пакеты.
  • Gateway — виртуальный шлюз.

В целом принцип архитектуры Network Controller такой: узлы контроллера размещаются на отдельных ВМ, а службы маршрутизации, балансировки трафика и межсетевого экрана — на серверах виртуализации.

Архитектура Network Controller.

Network Controller создан на базе программного коммутатора Open vSwitch. Этот коммутатор также используется в программно-определяемых сетях VMWare NSX и OpenStack Neutron. Он поддерживает протокол управления OVSDB (Open vSwitch Database), отвечающий за обмен информацией между сетевым оборудованием.

Разберем, как работает Network Controller. Серверы, виртуальные машины, виртуальные коммутаторы гипервизоров регистрируются в NC. После регистрации и настройки серверы устанавливают соединение с Network Controller и получают от него всю необходимую информацию о сетях виртуальных машин, правилах балансировки и VPN-туннелях.

Виртуальные сети на хостах подключены к виртуальному коммутатору Hyper-V с расширением Azure VFP Switch Extension. Через него происходит управление виртуальными портами, к которым подключены ВМ:

  • включение и отключение портов;
  • управление полосой пропускания в обе стороны;
  • назначение приоритетов пакетам по классам (COS);
  • назначение целей: ведение статистики и управление ACL на портах виртуального коммутатора.

Службы Network Controller


Разберем подробно, какие службы входят в Network Controller и чем они управляют.

Virtual Network Management. Это служба создания виртуальных сетей и управления ими. Она управляет виртуальными коммутаторами Hyper-V и виртуальными сетевыми адаптерами на виртуальных машинах. Virtual Network Management содержит настройки виртуальной сети, которые применяются другими службами Network Controller.

Firewall Management. Эта служба упрощает организацию межсетевого экранирования: не нужно настраивать межсетевые экраны на каждой ВМ вручную и запоминать конфигурации. Network Controller хранит все настройки Access Control Lists (ACL) для виртуальных машин и сетей. Distributed Firewall на хостах запрашивает у него информацию и применяет правила к нужным сетям и виртуальным машинам. Настройка на стороне виртуальных машин не требуется.

Ниже схема принципа работы межсетевого экранирования в Network Controller. На ней Northbound – интерфейс, через который производится управление Network Controller с использованием REST API. Southbound служит для связи с сетевыми устройствами, SLB-мультиплексорами, шлюзами и серверами, для сетевого обнаружения и других служб. Шлюзы определяют, для какой виртуальной сети требуется построить туннели. Затем они пересылают пришедшие пакеты по туннелю на серверы с виртуальными машинами, подключенными к нужной виртуальной сети.


Так устроена служба межсетевого экранирования в Network Controller.

Software Load Balancer Management. Служба работает на уровне виртуализованных сетей и балансирует трафик на уровне L4. Балансировка трафика происходит с помощью служебных виртуальных машин SLB Multiplexer (MUX) и BGP-маршрутизаторов. На один NC можно сделать 8 MUX. От Network Controller MUX получают правила маршрутизации. Мультиплексоры анонсируют маршруты /32 для каждого VIP через BGP-маршрутизаторы.

Пример
  1. На BGP-маршрутизатор приходит пакет для определенного виртуального IP-адреса.
  2. BGP-маршрутизатор проверяет, какой у пакета следующий узел. В данном случае это MUX.
  3. По таблицам правил балансировки, полученным от Network Controller, MUX определяет назначение пакета: виртуализованную сеть, хост и виртуальную машину.
  4. Далее MUX формирует VXLAN пакет и отправляет его хосту в сеть Backend.
  5. Хост принимает пакет и передает это виртуальному коммутатору (vSwitch), который определяет виртуальную машину для получения пакета.
  6. Пакет декапсулируется, анализируется и отправляется виртуальной машине.
  7. Виртуальная машина обрабатывает пакет. Адрес отправителя не изменяется после прохождения пакета через MUX. Поэтому виртуальная машина не видит за ним MUX балансировщика и считывает, что пакет пришел напрямую из интернета. Такая балансировка называется прозрачной (transparent load balancing).
  8. ВМ посылает ответ.
  9. Виртуальный коммутатор на хосте определяет, что это ответ на пакет, пришедший с балансировщика, и отправляет его обратно в Интернет. Причем не по той же цепочке, а переписывает адрес отправителя на IP балансировщика и отправляет его сразу в Интернет. Данный подход называется Direct Server Return (DSR). Это значительно ускоряет процесс обработки пакетов.


Балансировка трафика в Network Controller.

В Windows Server 2016 правила NAT теперь также задаются через Software Load Balancer Management. Network Controller знает, для какой сети организован NAT. MUX содержит информацию о хостах и виртуальных машинах, подключенных к сети, для которой организуется NAT.
NAT в Network Controller реализован путем балансировки трафика для группы из одного хоста. На данный момент поддерживается балансировка только TCP- и UDP-трафика.

RAS Gateway Manager. Эта служба создания VPN-туннелей для связи облачной инфраструктуры с физической. В Network Controller можно строить VPN любым удобным способом:

  • через IPsec, который теперь работает и с IKEv1, и с IKEv2;
  • создавать SSTP-туннели;
  • создавать GRE-туннели.

Конечной точкой туннеля выступает виртуальный шлюз Gateway. Он организует туннель, инкапсулирует трафик в VXLAN-пакеты и пересылается его хостам.


Служба создания VPN-туннелей RAG Gateway Management.

iDNS: Internal DNS. Служба позволяет создавать виртуальные DNS-сервера. На данный момент существует как реализация концепции и поддерживает работу только с одной DNS-зоной, что неудобно для клиентов. Мультитенантный режим будет добавлен в следующей редакции Windows Server 2016.

Рассмотрим, как работает служба iDNS. Организуется DNS-зона, в которой будут создаваться клиентские зоны. Настраивается Network Controller: указывается обслуживаемая DNS-зона и вышестоящие DNS-серверы, которые будут обрабатывать запросы, приходящие от клиентов.
После настройки iDNS Network Controller распространяет информацию по хостам. Служба iDNS proxy на хостах обрабатывает DNS-запросы от клиентов. Работает это так:

  1. Клиент посылает запрос на разрешение имени.
  2. iDNS-proxy смотрит, обслуживает ли он запросы, исходящие из данной виртуальной сети. Это определяется по первичному DNS-суффиксу у сетевого адаптера. Он должен совпадать с зоной, обслуживаемой iDNS. Если iDNS-proxy обслуживает запросы из этой сети, то отправляет запрос вышестоящему DNS-серверу.
  3. DNS-сервер проверяет, относится ли запрос к внутренним зонам. Если клиент пытается разрешить внутреннее имя, то DNS-сервер его обрабатывает. Если нет – отправляет запрос дальше.



Принцип работы службы iDNS в Network Controller.

Пример
Есть виртуальная сеть, для которой доступна служба iDNS. При подключении виртуальных машин к этой сети, в корневой зоне DNS, указанной при настройке, будет создана зона с именем, совпадающим с ID виртуальной сети. В этой зоне будут создаваться А-записи для виртуальных машин.


А-записи виртуальных машин в службе iDNS.

Все, о чем мы подробно рассказали выше, — это службы Network Controller, которые вошли в официальный релиз Windows Server 2016. Нам также удалось протестировать службы, вошедшие в Technical Preview, но изъятые из релиза. Одна из таких служб — Canary Network Diagnostics для мониторинга производительности сети, сбора статистики по работе физического и виртуального сетевого оборудования и обнаружения ошибок. Дополнения должны войти в релиз Windows Server 2016R2, и о них мы поговорим в будущем.

В следующей части мы расскажем, как развернуть Network Controller и о некоторых интересных «подводных камнях», которые мы обнаружили в ходе тестирования.

Пишите вопросы в комментариях.
Поделиться с друзьями
-->

Комментарии (4)


  1. GebekovAS
    04.02.2017 11:01

    Службы Canary Network Diagnostics на узлах работают изолированно (по аналогии мониторинга ресурсов), или умеют взаимодействовать друг с другом? Возможно ли с одного узла получать и просматривать данные других узлов?


    1. 5000shazams
      06.02.2017 12:25

      Canary Network Diagnostics работает в связке с Network Controller. Через NC происходит обмен данными. Более подробно о том, как работает Canary Network Diagnostics, можно будет сказать, когда появится официальный релиз


  1. cyreex
    07.02.2017 12:18

    управление виртуальными сетями в Windows Server 2012R2 осуществлялось только через Virtual Machine Manager (VMM)


    Нет, через  PowerShell тоже можно управлять. Без VMM, прямо на хостах. Пример. Да, с юзабельностью огромный вопрос, но все же.

    Он был точкой хранения всех конфигураций виртуальной инфраструктуры и единой точкой отказа


    Не совсем так. Информация хранится в таблицах HNV на хостах. Если мы выключим VMM, ничего страшного не произойдет. Но это только до тех пор, пока мы не решим мигрировать какую-либо ВМ. Тогда да, lookup запись никто не обновит и машина будет изолирована.

    Но это так, мелкие придирки. Статья мне понравилась, спасибо. Жду вторую часть!


    1. 5000shazams
      08.02.2017 17:01

      Спасибо!