В прошлом году мы рассказывали о Storage Spaces Direct? — ?программно-определяемом хранилище в Windows Server 2016. Сегодня поговорим еще об одной новинке Microsoft, на этот раз из области программно-определяемых сетей (SDN). Network Controller — это служба управления сетевой инфраструктурой в Windows Server 2016.
Содержание
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 2016 компания Microsoft представила новую реализацию программно-определяемых сетей уже на базе протокола VXLAN – Network Controller (NC). Доступна данная служба только в редакции Windows Server 2016 Datacenter. Давайте рассмотрим особенности Network Controller.
Network Controller — единая точка управления и мониторинга для всех физических и виртуальных сетей домeна. С помощью него настраивается IP-подсети, VLAN, маршрутизаторы и межсетевые экраны. NС хранит информацию о топологии сети, балансирует трафик и задает правила NAT.
В целом принцип архитектуры 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. Через него происходит управление виртуальными портами, к которым подключены ВМ:
Разберем подробно, какие службы входят в 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-маршрутизаторы.
Пример
Балансировка трафика в 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 любым удобным способом:
Конечной точкой туннеля выступает виртуальный шлюз 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-запросы от клиентов. Работает это так:
Принцип работы службы iDNS в Network Controller.
Пример
Все, о чем мы подробно рассказали выше, — это службы Network Controller, которые вошли в официальный релиз Windows Server 2016. Нам также удалось протестировать службы, вошедшие в Technical Preview, но изъятые из релиза. Одна из таких служб — Canary Network Diagnostics для мониторинга производительности сети, сбора статистики по работе физического и виртуального сетевого оборудования и обнаружения ошибок. Дополнения должны войти в релиз Windows Server 2016R2, и о них мы поговорим в будущем.
В следующей части мы расскажем, как развернуть Network Controller и о некоторых интересных «подводных камнях», которые мы обнаружили в ходе тестирования.
Пишите вопросы в комментариях.
Содержание
Откуда пошли виртуальные сети?
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-маршрутизаторы.
Пример
- На BGP-маршрутизатор приходит пакет для определенного виртуального IP-адреса.
- BGP-маршрутизатор проверяет, какой у пакета следующий узел. В данном случае это MUX.
- По таблицам правил балансировки, полученным от Network Controller, MUX определяет назначение пакета: виртуализованную сеть, хост и виртуальную машину.
- Далее MUX формирует VXLAN пакет и отправляет его хосту в сеть Backend.
- Хост принимает пакет и передает это виртуальному коммутатору (vSwitch), который определяет виртуальную машину для получения пакета.
- Пакет декапсулируется, анализируется и отправляется виртуальной машине.
- Виртуальная машина обрабатывает пакет. Адрес отправителя не изменяется после прохождения пакета через MUX. Поэтому виртуальная машина не видит за ним MUX балансировщика и считывает, что пакет пришел напрямую из интернета. Такая балансировка называется прозрачной (transparent load balancing).
- ВМ посылает ответ.
- Виртуальный коммутатор на хосте определяет, что это ответ на пакет, пришедший с балансировщика, и отправляет его обратно в Интернет. Причем не по той же цепочке, а переписывает адрес отправителя на 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-запросы от клиентов. Работает это так:
- Клиент посылает запрос на разрешение имени.
- iDNS-proxy смотрит, обслуживает ли он запросы, исходящие из данной виртуальной сети. Это определяется по первичному DNS-суффиксу у сетевого адаптера. Он должен совпадать с зоной, обслуживаемой iDNS. Если iDNS-proxy обслуживает запросы из этой сети, то отправляет запрос вышестоящему DNS-серверу.
- 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)
cyreex
07.02.2017 12:18управление виртуальными сетями в Windows Server 2012R2 осуществлялось только через Virtual Machine Manager (VMM)
Нет, через PowerShell тоже можно управлять. Без VMM, прямо на хостах. Пример. Да, с юзабельностью огромный вопрос, но все же.
Он был точкой хранения всех конфигураций виртуальной инфраструктуры и единой точкой отказа
Не совсем так. Информация хранится в таблицах HNV на хостах. Если мы выключим VMM, ничего страшного не произойдет. Но это только до тех пор, пока мы не решим мигрировать какую-либо ВМ. Тогда да, lookup запись никто не обновит и машина будет изолирована.
Но это так, мелкие придирки. Статья мне понравилась, спасибо. Жду вторую часть!
GebekovAS
Службы Canary Network Diagnostics на узлах работают изолированно (по аналогии мониторинга ресурсов), или умеют взаимодействовать друг с другом? Возможно ли с одного узла получать и просматривать данные других узлов?
5000shazams
Canary Network Diagnostics работает в связке с Network Controller. Через NC происходит обмен данными. Более подробно о том, как работает Canary Network Diagnostics, можно будет сказать, когда появится официальный релиз