Облачные решения все плотнее смешиваются с привычными, и сегодня определить, на каком сервере запущено приложение, становится сложнее, да и ситуация может измениться в любой момент. Помимо физических сетей, в ЦОД присутствуют сотни виртуальных. Управлять этим зоопарком при помощи традиционных сетевых технологий все труднее. В Windows Server 2016 появился новый элемент Network Controller, реализующий концепцию программно определяемой сети (Software Defined Networking).

 

Возможности Network Controller

Network Controller — новая роль в составе Win 2016, пришедшая из Azure, обеспечивает единую точку управления и мониторинга для всех физических и виртуальных сетей домена, позволяя из одной точки настраивать IP-подсети, VLAN, маршрутизаторы и физические сетевые адаптеры Hyper-V-хостов. Используя Network Controller, мы можем управлять соединениями виртуальных машин Hyper-V, виртуальными коммутаторами, физическими сетевыми маршрутизаторами, настройками файрвола, VPN-шлюзами, в том числе и RRAS, и балансировкой нагрузки. Маршрутизацию обеспечивает использование протокола Border Gateway Protocol (BGP). Управление правилами брандмауэра позволяет контролировать трафик в любом направлении, используемом узлами кластера и отдельными VM. В качестве виртуальных сетей поддерживаются не только родные для MS NVGRE (Network Virtualization using Generic Routing Encapsulation, используется от Win 2012), но и VXLAN (Virtual Extensible LAN — VMware, Arista Networks, Cisco...). Функциональность, как мы видим, не ограничивается только виртуальными машинами, управлять можно также физическими серверами, являющимися частью кластера Windows Server. Для управления функциями Network Controller реализовано два API:

  • Southbound API. Используется для взаимодействия с сетевыми устройствами, службами и прочими элементами облака. Именно с его помощью обнаруживаются конфигурации и изменения, собираются данные о сети;
  • Northbound API. Представляет собой REST-интерфейс. Используется для мониторинга и управления сетью при помощи командлетов PowerShell, API REST или System Center 2016 Virtual Machine Manager (SCVMM 2016) и System Center 2016 Operations Manager (SCOM 2016). В последних двух вариантах доступен графический интерфейс.

Сетевой контроллер, используя SNMP и анализ сетевого потока, обнаруживает проблемы, связанные с задержками и потерями пакетов, и информирует о неправильно работающих устройствах в сети. Поддерживается новый инструмент Microsoft Message Analyzer, пришедший на замену Microsoft Network Monitor, он позволяет захватывать, отображать и анализировать трафик по различным протоколам, отслеживать и оценивать системные события, сообщения устройств, задержки и потери пакетов, искать и устранять неисправности. Ведется сбор SNMP-данных, определяется статус работы отдельных устройств. Есть возможность автоматического обнаружения и группирования устройств по некоторым характеристикам, с установлением зависимости между физическими и виртуальными устройствами. Например, в случае обнаружения проблем с определенными сервисами сетевой контроллер помечает все связанные серверы, VM, маршрутизаторы и прочее как неисправные. Для автоматического обнаружения физических и виртуальных серверов в сети используется механизм Data Center Bridging, реализующий несколько стандартов IEEE 802.1.

 

Установка роли Network Controller

Развернуть Network Controller можно как в доменной, так и в бездоменной сети. В первом случае аутентификация пользователей и сетевых устройств производится при помощи Kerberos, во втором потребуются сертификаты. Для знакомства и тестирования можно использовать единственный физический или виртуальный сервер. В промышленной среде для обеспечения высокой доступности следует развернуть кластер из нескольких серверов. Network Controller легко масштабируется, поэтому новые серверы добавляются в кластер очень просто. Клиенты для управления Network Controller могут использовать не только серверную ОС, но и Win 8/8.1/10.

Если узлы с ролью Network Controller развернуты в разных подсетях, следует в диспетчере DNS разрешить динамические обновления DNS для зоны, установив в свойствах зоны параметр Dynamic updates в Secure only. Тип зоны должен быть установлен в Primary или Active Directory-integrated. И установить разрешения для узлов в Security -> Advanced (Безопасность -> Дополнительно). Для тестовой среды с одним сервером это не нужно.

Каждый сервер и клиент, участвующий в соединении, потребует сертификат, содержащий в поле Subject имя компьютера. Это позволяет разрешить его через DNS. Сертификаты следует импортировать/экспортировать на остальные узлы и сделать доверенными для остальных участников. Будем считать, что все это уже сделано, и на управлении сертификатами останавливаться не будем. Для тестирования можно сгенерировать самоподписанный сертификат с помощью диспетчера IIS.

Установить роль Network Controller (Сетевой контроллер) можно при помощи диспетчера сервера, выбрав его в ролях сервера и подтвердив установку инструментов управления или PowerShell. Команда здесь проста:

PS> Install-WindowsFeature -Name NetworkController –IncludeManagementTools
Установка роли «Сетевой контроллер»
Установка роли «Сетевой контроллер»

По окончании установки в диспетчере сервера появится новая вкладка Network Controller, позволяющая просмотреть события. Управлять же основными функциями, как уже говорилось, можно при помощи командлетов PowerShell, решений SCVMM 2016 и SCOM 2016, предлагающих графический интерфейс. Последние трогать не будем, разберем PowerShell.

Модуль NetworkController содержит 45 командлетов. Получить их полный список можно при помощи

PS> Get-Command -module NetworkController

Все командлеты разбирать точно нет смысла, тем более примеры будут большие, рассмотрим основные моменты, позволяющие понять суть настроек. К сожалению, документация MS в части использования Network Controller с PowerShell пока весьма скудна, некоторые моменты приходится уточнять экспериментально, но разобраться путем проб и ошибок можно. Будем надеяться, что к окончательному релизу эта проблема будет решена.

Командлеты модуля NetworkController
Командлеты модуля NetworkController

Основой всего является приложение (объект) Network Controller, уже на котором строится кластер, обеспечивающий высокую доступность и масштабируемость. Причем кластер устанавливается всегда, даже в случае единственного экземпляра NetworkController.

 

Создание Network Controller

Для первого конфигурирования сетевого контроллера используется командлет New-NetworkControllerNodeObject, создающий объект узла сетевого контроллера узла. В качестве параметров необходимо указать имя, REST-интерфейс (должен выводиться в Get-NetIPConfiguration, иначе получим ошибку в последующем), сервер и отказоустойчивый домен (FaultDomain). Последнее — это еще одна фишка, пришедшая с Azure, позволяющая «распределить» установки NetworkController по разным стойкам. В случае выхода из строя одной стойки работоспособность сервиса не будет нарушена. Также опционально можно указать сертификат при помощи опции NodeCertificate.

PS> $NodeObject = New-NetworkControllerNodeObject -Name "Node1" -Server "example.org" -RestInterface "Ethernet0" -FaultDomain "fd0:/rack1/host1"
Создаем новый объект
Создаем новый объект

Повторяем эту операцию на всех узлах с ролью NetworkController. Этот объект используется для создания кластера. В параметрах необходимо указать вид аутентификации (в случае Active Directory — Kerberos, иначе x509 или None). Опционально указывается группа безопасности, пользователи которой могут управлять настройками NetworkController, расположение журналов, использование SSL и, при необходимости, сертификаты.

PS> Install-NetworkControllerCluster -Node $NodeObject -ClusterAuthentication "Kerberos" -ManagementSecurityGroup Example\NCAdmins -LogLocation "\\example.org\nc"

Для проверки параметров следует использовать командлет Get-NetworkControllerCluster. Теперь пришла очередь установки собственно сетевого контроллера. Параметры Install-NetworkController практически совпадают с параметрами предыдущего командлета, необходимо обязательно указать сертификат. Список всех сертификатов и их свойств можно получить при помощи Get-ChildItem и Get-Item. Предположим, у нас уже есть сертификат с именем сервера.

PS> $Certificate = Get-Item Cert:\LocalMachine | Get-ChildItem | where {$_.Subject -imatch "example.org" }
PS> Install-NetworkController -Node $NodeObject -ClientAuthentication "Kerberos" -ServerCertificate $Certificate -EnableAllLogs
Устанавливаем сетевой контроллер
Устанавливаем сетевой контроллер

Установка может занять некоторое время. По окончании будет выведена таблица настроек, просмотреть которую впоследствии можно, запустив Get-NetworkController. Изменить в дальнейшем можно при помощи Set-NetworkController.

В документации не сказано, но последующие настройки у меня заработали только после перезагрузки сервера, до нее командлеты постоянно выдавали ошибку. Для управления сетевым контроллером нужны учетные данные. Причем потребуется два типа: учетные данные пользователя (обычные или доменные) — для управления и учетные данные SNMP — для получения информации о конфигурации по соответствующему протоколу. В качестве параметров нужно указать URI, свойства и идентификатор учетных данных.

PS> $cred = New-Object Microsoft.Windows.NetworkController.CredentialProperties
PS> $cred.type = "usernamepassword"
PS> $cred.username = "domain\admin"
PS> $cred.value = "passwd"

В случае SNMP в качестве $cred.type используется

PS> $cred.type = "snmpCommunityString"

И указываем свой пароль. Создаем:

PS> New-NetworkControllerCredential -ConnectionUri "https://example.org" -Properties $сred –ResourceId "Cred1"
Настраиваем учетные данные
Настраиваем учетные данные

Соответственно, для SNMP укажем свой Properties и ResourceId. Сразу же и проверим:

PS> Get-NetworkControllerCredential -ConnectionUri "https://example.org" -ResourceId Cred1

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

PS> $config = New-Object Microsoft.Windows.Networkcontroller.ConfigurationProperties
PS> $config.DiscoverHosts = "true"

По умолчанию интервал обнаружения установлен в 1440 минут, для тестирования лучше его уменьшить, иначе информацию ждать будем долго:

PS> $config.DiscoveryIntervalInMinutes = "10"

Подсети, в которых будет производиться обнаружение устройств:

PS> $config.DiscoveryScopes = "10.0.0.0/24,192.168.0.0/24"

Получаем учетные данные, созданные ранее. Если создано несколько пользователей, то задаем их здесь, а при опросе устройств они будут перебираться до совпадения.

PS> $credential = Get-NetworkControllerCredential –ConnectionUri https://example.org –ResourceId Сred1
PS> $config.Credentials = $credential

IP-адрес устройства, которое будет использовано в качестве отправной точки для поиска в сети:

PS> $config.DiscoverySeedDevices = "192.168.0.1"

Ограничение по глубине поиска устройств:

PS> $config.HopLimit = "3"
PS> $config.ActiveDirectoryDomains = "example.org"

Применяем установки:

PS> Set-NetworkControllerTopologyConfiguration –ConnectionUri https://example.org –Properties $config

Проверяем настройки:

PS> $topology = Get-NetworkControllerDiscoveredTopology -ConnectionUri https://example.org
PS> $topology.Properties

Запускаем процесс поиска и идентификации сетевых устройств:

PS> $discovery = New-Object Microsoft.Windows.NetworkController.NetworkDiscoveryActionProperties
PS> $discovery.Action = "start"
PS> Invoke-NetworkControllerTopologyDiscovery –ConnectionUri https://example.org –Properties $disсovery
Настраиваем процесс обнаружения
Настраиваем процесс обнаружения

Некоторое время ждем, чтобы просмотреть результат. По каждому узлу собираются данные об имени, ОС, типе, модели, состоянии и прочему. В Windows для возможности обнаружения систем следует включить DCB, установив соответствующий компонент:

PS> Install-WindowsFeature Data-Center-Bridging

После этого нужно проверить в свойствах сетевых устройств, чтобы был установлен флажок в параметрах Microsoft LLDP Protocol Driver и QoS Packet Scheduler. Включить также можно при помощи командлета:

PS> Enable-NetAdapterQoS "Ethernet0"

Состояние DCB выводится при помощи Get-NetQoSDCBxSetting. Статистика по обнаружению устройств и времени последнего запуска просматривается при помощи командлета Get-NetworkControllerTopologyDiscoveryStatistics:

PS> Get-NetworkControllerTopologyDiscoveryStatistics -ConnectionUri https://example.org

Теперь смотрим информацию о топологии, обнаруженных узлах и связях:

PS> $topology = Get-NetworkControllerDiscoveredTopology -ConnectionUri https://example.org

Получим массив узлов.

PS> $topology.Properties

Свойства одного узла:

PS> $topology.Properties.TopologyNodes[0].Properties

Просмотр связей:

PS> $topology.Properties.TopologyLinks[0].Properties

Есть и специальные командлеты, позволяющие получить те же данные более просто: Get-NetworkControllerDiscoveredTopologyLink, Get-NetworkControllerDiscoveredTopologyNode и Get-NetworkControllerDiscoveredTopologyTerminationPoint.

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

Добавить данные о сетях и IP-пуле позволяют командлеты New-NetworkControllerLogicalNetwork, New-NetworkControllerLogicalSubnet и New-NetworkControllerIpPool.

 

Вывод

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

2 комментария

  1. Аватар

    v0scndy

    03.03.2016 в 19:58

    Куда катится мир…

Оставить мнение