Windows server 2016 nic teaming настройка

Обновлено: 04.07.2024

Новый DC на Windows 2016. Объединяем сетевые адаптеры.

В текущем исполнении у нас два контроллера домена:

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

Судя по логам, в пятницу вечером, «воткнул» основной контроллер. Не просто «воткнул» полностью, а «воткнул» как-то странно (продолжал пинговаться, но войти удаленно на него уже было нельзя и свою роль он уже также не выполнял). Вроде воткнул и воткнул, есть же второй контроллер. Но в воскресенье днем пропала доменная авторизация на всех устройствах, хотя второй контроллер был вроде как доступен. А далее интересный момент. Как только пропала авторизация, второй контроллер перестал удаленно пускать в систему по RDP, решили посмотреть, что происходит с ним через Vcenter, но тут тоже нас ждал «отлуп», авторизация также не проходила, а самое интересное никак невозможно было попасть на виртуальный второй контроллер. Получился некий замкнутый круг: PDC в «дауне», а что случилось с SDC, тоже невозможно посмотреть и понять, что с ним происходит.

Соответственно все виртуальные сервера продолжали работать, но уже не так хорошо, как были должны. Впервые за свою практику, столкнулся с похожей ситуацией.

Далее пошли по следующему пути:

До этого случая планировали приобрести более быстрый железный сервак и смигрировать, текущий PDC на него, а вот после него, пересмотрели свое первоначальное решение: PDC на новый смигрируем (перенесем роли и прочие дела), а избавляться от второго железного сервера пока не будем, оставим его третьим контроллером.

Наконец наш новый сервер DELL уже в стойке, Windows Server 2016 уже «залит», пришло время поэтапно приступить к поднятию третьего контроллера и дальнейшему PDC переносу на него.

Но сначала для отказоустойчивости имеет смысл объединить сетевые порты:

Соответственно из разных сетевых портов сервера включаем шнурки в разные коммутаторы, на этих портах коммутаторов, включаем LACP.


На втором аналогично.

Далее, переходим непосредственно к серверу.

По умолчанию режим NIC Teaming в Windows server 2016 (в 2012 аналогично) отключен. Для его активации открываем Server Manager и видим, что это действительно так.


В Задачах (Tasks) выбираем пункт Создать группу (New Team).


Далее именуем группу, выбираем отмечаем адаптеры и настраиваем дополнительные свойства группы.

Имеет смысл сказать несколько слов о дополнительных параметрах настройки NIC Teaming в Windows server 2016:

Режим поддержки групп (Teaming mode) определяет режим взаимодействия группы с сетевым оборудованием:

1. Не зависит от коммутатора (Switch Independent) — группа работает независимо от коммутатора, никакой дополнительной настройки сетевого оборудования не требуется. Этот режим позволяет подключать адаптеры одной тиминговой группы к разным свичам для защиты от сбоя одного из них. настройка по умолчанию;
2. Статическая поддержка групп (Static Teaming) — режим с зависимостью от сетевого оборудования. Все адаптеры группы должны быть подключены к одному коммутатору. Порты коммутатора, к которым подключены адаптеры группы, настраиваются на использование статической агрегации каналов;
3. LACP — режим с зависимостью от сетевого оборудования. Коммутатор настраивается на использование динамической агрегации каналов с использованием протокола Link Aggregation Control Protocol (LACP).

Режим балансировки нагрузки (Load Balancing mode) определяет, каким образом распределять сетевой трафик между адаптерами группы:

1. Хэш адреса (Address Hash) — при передаче сетевого трафика на основании MAC или IP-адресов отправителя и получателя вычисляется хеш (некое число). Это число привязывается к определенному физическому адаптеру и в дальнейшем весь трафик от этого отправителя будет идти через этот адаптер;
2. Порт Hyper-V (Hyper-V Port) — в этом режиме осуществляется привязка адаптера teaming группы к определенному порту виртуального свича в Hyper-V. Этот режим используется в том случае, если на сервере активирована роль Hyper-V.

Резервный адаптер (Standby adapter) позволяет назначить один из адаптеров группы в качестве резервного. В нормальном состоянии резервный адаптер не используется для передачи трафика, но при выходе любого адаптера группы из строя сразу занимает его место и трафик продолжает передаваться без перерывов. Но даже без резервирования выход из строя одного адаптера в NIC Teaming не приведет к прерыванию сетевого соединения, потому что, нагрузка будет автоматически распределена по оставшимся адаптерам.


Тоже самое можно сделать и через PowerShell:

New-NetLbfoTeam -Name LACP -TeamMembers ″Ethernet″,″Ethernet 2″ ` -TeamingMode SwitchIndependent -LoadBalansingAlgorithm TransportPorts

Далее в окне «Сетевые подключения» появиться еще один сетевой адаптер, который как раз и является виртуальным адаптером созданной группы.



При необходимости все это можно удалить:


Или через PowerShell: Remove-NetLbfoTeam -Name LACP

Порты объединены, можно будет приступить к следующим этапам, но это уже тема последующих постов…

Задача: Самостоятельно проработать, как поднять/организовать Nic Teaming средствами Windows Server 2016 в GUI составляющей. Ранее я уже делал, но использовал Windows Server 2008 R2, а тут хочу посмотреть также это все легко или есть определенные нюансы.

Итак, под Virtualbox развернута виртуальная система с осью на борту Windows Server 2016 Standard (Microsoft Windows [Version 10.0.14393]) с двумя сетевыми адаптерами.

Авторизуюсь в системе с правами, либо локального администратора, либо Администратора домена.

Win + R — cmd.exe с правами Администратора (Обязательно)

C:\Users\Администратор>netsh interface teredo set state disabled

C:\Users\Администратор>netsh interface isatap set state disabled

C:\Users\Администратор>netsh interface 6to4 set state disabled

Чтобы сделать объединение сетевых интерфейсов в один для увеличения пропускной способности:

Создаю группу объединяющую два интерфейса

именую группу, к примеру:

Имя группы: nic
и отмечаю галочками сетевые интерфейсы которые буду объединять, также нужно через «Дополнительные свойства» указать режим работы объединенных интерфейсов:

Основной групповой интерфейс: nic (виртуальная локальная сеть по умолчанию)
и нажимаю кнопку «ОК»

Итого объединение интерфейсов в системе сформировано:

Сетевые интерфейсы объединены в один

Если переключиться в оснастку: «Центр управления сетями и общим доступом», то будет видно, что сформировался/появился новый интерфейс, где уже ему Вы задаете либо статический IP-адрес (Маска, Шлюз), либо настройками коммутатора/маршрутизатора.

В случае если линк обрывается на одном сетевом интерфейсе, доступ к системе Вы не теряете.

Если обратить внимание на свойства первого и второго сетевого адаптера, то у них выставлена всего лишь одна настройка «Протокол мультиплексора сетевого адаптера», а у нового с именем группы nic:

  • Клиент для сетей Microsoft
  • Общий доступ к файлам и принтерам
  • Планировщик пакетов QoS
  • Microsoft Load Balancing/Failower Provider
  • IP версии 4 (TCP/IPv4)
  • IP версии 6 (TCP/IPv6) — снимаю галочку, так как не использую во всей сети.
  • Отвечающее устройство обнаружение топологии (делает компьютер видимым в сети)

Ответчик обнаружения топологии канального уровня (используется для обнаружения других компьютеров, устройств и компонентов в сети).

Win + R — cmd.exe с правами Администратора (Обязательно)

C:\Users\Администратор>ipconfig

Настройка протокола IP для Windows
Адаптер Ethernet nic:
DNS-суффикс подключения . . . . . :
IPv4-адрес. . . . . . . . . . . . : 172.40.40.6
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 172.40.40.1

Как видно, сетевой адрес получает лишь общий интерфейс, а не вспомогательные.

На заметку: Если Ваши наблюдения показываю, что объединение интерфейсов требуют изменения, то все также через оснастку «Объединения сетевых карт» можно поменять настройки. Вот только желательно это делать имея к системе еще один вид подключения, к примеру консоль Hyper-V, vSphere Client, iDRAC, IPMI и т. д. Чтобы если что не остаться у разбитого корыта и подстраховаться.
На заметку: Если физическое железо может на уровне железа объединять интерфейсы или использует специализированное программное обеспечение, то лучше делать через него, чем средствами Windows, а если не хочется от него зависить, то средствами операционной системы и не важно Windows это или Linux.

Вот на этом я прощаюсь, как я мог убедиться нет ничего сложно в настройке объединения сетевых карт в системе Windows Server 2016. Если у меня буду какие-либо дополнения и наблюдения, то я постараюсь отразить их в этой заметке. А пока у меня всё, с уважением автор блога Олло Александр aka ekzorchik.

в этом разделе представлен обзор объединения сетевых карт (NIC) в Windows Server. Объединение сетевых карт позволяет объединять один и 32 физических сетевых адаптеров Ethernet в один или несколько программных виртуальных сетевых адаптеров. Эти виртуальные сетевые адаптеры обеспечивают высокую производительность и отказоустойчивость в случае сбоя сетевого адаптера.

Сетевые адаптеры члена группы сетевой карты необходимо установить на одном физическом компьютере узла.

Группа сетевых адаптеров, которая содержит только один сетевой адаптер, не может обеспечить балансировку нагрузки и отработку отказа. Однако с помощью одного сетевого адаптера можно использовать объединение сетевых карт для разделения сетевого трафика при использовании виртуальных локальных сетей (VLAN).

При настройке сетевых адаптеров в команде сетевой карты они подключаются к общему ядру решения для объединения сетевых карт, который затем представляет собой один или несколько виртуальных адаптеров (также называемых сетевыми интерфейсами группы [Тникс] или командные интерфейсы) в операционной системе.

поскольку Windows Server 2016 поддерживает до 32 командных интерфейсов на одну группу, существует множество алгоритмов, которые распределяют исходящий трафик между сетевыми картами. На следующем рисунке показана группа сетевых адаптеров с несколькими Тникс.

Группа сетевых адаптеров с несколькими Тникс

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

Доступность

Объединение сетевых карт доступно во всех версиях Windows Server 2016. Для управления объединением сетевых карт с компьютеров, работающих под управлением клиентской операционной системы, можно использовать разнообразные средства, например:

  • Командлеты Windows PowerShell
  • Удаленный рабочий стол
  • Средства удаленного администрирования сервера

Поддерживаемые и неподдерживаемые сетевые карты

вы можете использовать любой сетевой адаптер Ethernet, прошедший проверку Windows оборудования и проверки логотипов (WHQL tests) в группе сетевых адаптеров в Windows Server 2016.

Вы не можете разместить следующие сетевые карты в группе сетевых адаптеров:

Виртуальные сетевые адаптеры Hyper-V, которые являются портами виртуального коммутатора Hyper-V, предоставленными в виде сетевых карт в разделе узла.

Не размещайте виртуальные сетевые карты Hyper-V, представленные в разделе узла (vNIC), в группе. Объединение vNIC внутри раздела узла не поддерживается ни в какой конфигурации. Попытки команды vNIC могут привести к потере связи, если произошел сбой сети.

Сетевой адаптер отладки ядра (КДНИК).

Сетевые карты, используемые для сетевой загрузки.

сетевые карты, использующие технологии, отличные от Ethernet, такие как WWAN, WLAN/Wi-Fi, Bluetooth и Infiniband, включая сетевые адаптеры по протоколу infiniband (IPoIB).

Совместимость

объединение сетевых карт совместимо со всеми сетевыми технологиями в Windows Server 2016 со следующими исключениями.

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

TCP Chimney. TCP Chimney не поддерживается при объединении сетевых карт, так как TCP Chimney разгружает весь сетевой стек непосредственно на сетевой адаптер.

Проверка подлинности 802.1 x. Не следует использовать проверку подлинности 802.1 X с объединением сетевых карт, так как некоторые коммутаторы не допускают настройку проверки подлинности 802.1 X и объединения сетевых карт на одном и том же порте.

Дополнительные сведения об использовании объединения сетевых карт в виртуальных машинах, работающих на узле Hyper-V, см. в статье Создание группы сетевых адаптеров на главном компьютере или виртуальной машине.

Очереди виртуальных машин (ВМКС)

ВМКС — это функция сетевого интерфейса, которая выделяет очередь для каждой виртуальной машины. Когда Hyper-V включен; также необходимо включить VMQ. в Windows Server 2016 вмкс использовать NIC Switch впортс с одной очередью, назначенной впорт, для предоставления тех же функций.

В зависимости от режима конфигурации коммутатора и алгоритма распределения нагрузки объединение сетевых карт представляет собой минимальное количество доступных и поддерживаемых очередей любым адаптером в группе (режим min-Queues) или общее число очередей, доступных для всех участников группы (режим SUM-of-Queues).

Если команда находится в режиме объединения Switch-Independent и вы устанавливаете распределение нагрузки в режим порта Hyper-V или динамический режим, число сообщаемых очередей — это сумма всех очередей, доступных для членов группы (режим SUM-of-Queues). В противном случае количество очередей в отчете является наименьшим числом очередей, поддерживаемых любым участником команды (режим min-Queues).

Далее описывается, почему это происходит:

Если независимая команда находится в режиме порта Hyper-V или в динамическом режиме, входящий трафик для порта коммутатора Hyper-V (ВМ) всегда поступает на один и тот же участник команды. Узел может предсказать или контролировать, какой член получает трафик для конкретной виртуальной машины, чтобы объединение сетевых карт было более продуманным, чем очереди VMQ, выделяемые для конкретного участника команды. Объединение сетевых карт, работа с коммутатором Hyper-V, устанавливает VMQ для виртуальной машины на точно одном члене команды и определяет, что входящий трафик поступает в эту очередь.

Если команда находится в любом режиме, зависимом от переключения (статическое объединение или объединение LACP), коммутатор, к которому подключена команда, управляет распределением входящего трафика. Программному обеспечению для объединения сетевых карт не удается предсказать, какой член команды получает входящий трафик для виртуальной машины. возможно, коммутатор распределяет трафик для виртуальной машины по всем членам группы. В результате работы программы объединения сетевых карт, работающей с коммутатором Hyper-V, программа программирует очередь для виртуальной машины на всех участниках группы, а не только на одном члене команды.

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

Большинство сетевых адаптеров используют очереди для масштабирования на стороне приема (RSS) или VMQ, но не в одно и то же время. Некоторые параметры VMQ выглядят как параметры для очередей RSS, но являются параметрами универсальных очередей, которые используются как для RSS, так и для VMQ в зависимости от того, какая функция используется в настоящее время. Каждая сетевая карта имеет в своих дополнительных свойствах значения * Рссбасепрокнумбер и * Максрсспроцессорс. Ниже приведены несколько параметров VMQ, обеспечивающих лучшую производительность системы.

В идеале для каждой сетевой карты необходимо, чтобы для параметра * Рссбасепрокнумбер было установлено четное число, большее или равное двум (2). Первый физический процессор, ядро 0 (логические процессоры 0 и 1) обычно выполняет большую часть системной обработки, поэтому сетевая обработка должна отойти от этого физического процессора. Некоторые архитектуры компьютеров не имеют двух логических процессоров на один физический процессор, поэтому для таких компьютеров базовый процессор должен быть больше или равен 1. Если вы сомневаетесь в том, что ваш узел использует 2 логических процессора на архитектуру физического процессора.

Если команда находится в режиме суммирования очередей, процессоры членов группы должны быть не перекрывающиеся. Например, в 4-ядерном хосте (8 логических процессорах) с группой из 2 10 Гбит/сетевых интерфейсов можно установить первый из них, чтобы использовать базовый процессор 2 и использовать 4 ядра; второй будет установлен для использования базового процессора 6 и 2 ядер.

Если команда работает в Min-Queues режиме, наборы процессоров, используемые членами команды, должны быть идентичны.

Виртуализация сети Hyper-V (HNV)

Объединение сетевых карт полностью совместимо с виртуализацией сети Hyper-V (HNV). Система управления HNV предоставляет сведения о драйвере объединения сетевых карт, который позволяет объединением сетевых карт распределить нагрузку таким образом, чтобы оптимизировать трафик HNV.

Динамическая миграция

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

Виртуальные локальные сети (VLAN)

При использовании объединения сетевых карт создание нескольких интерфейсов команды позволяет узлу подключаться к разным виртуальным ЛС одновременно. Настройте среду, следуя приведенным ниже рекомендациям.

Перед включением объединения сетевых карт настройте порты физического коммутатора, подключенные к узлу Teaming, для использования режима магистрали (неизбирательного). Физический коммутатор должен передавать весь трафик на узел для фильтрации без изменения трафика.

Не настраивайте фильтры VLAN на сетевых адаптерах с помощью параметров дополнительных свойств сетевого адаптера. Разрешите программе объединения сетевых карт или виртуальному коммутатору Hyper-V (при наличии) выполнить фильтрацию виртуальных ЛС.

Использование виртуальных ЛС с объединением сетевых карт в виртуальной машине

Когда команда подключается к виртуальному коммутатору Hyper-V, все разделение виртуальных ЛС должно выполняться в виртуальном коммутаторе Hyper-V, а не в группе объединения сетевых карт.

Запланируйте использование виртуальных ЛС на виртуальной машине, настроенной с помощью группы сетевых адаптеров, по следующим рекомендациям.

Предпочтительным способом поддержки нескольких виртуальных ЛС в виртуальной машине является настройка виртуальной машины с несколькими портами на виртуальном коммутаторе Hyper-V и связывание каждого порта с виртуальной ЛС. Никогда не указывайте эти порты на виртуальной машине, так как это вызывает проблемы с сетевым подключением.

Если виртуальная машина имеет несколько виртуальных функций SR-IOV (VFs), убедитесь, что они находятся в одной виртуальной ЛС, прежде чем они будут объединены в виртуальную машину. Вы можете легко настроить различные VFs в различных виртуальных ЛС, и это приведет к проблемам с сетевыми подключениями.

Управление сетевыми интерфейсами и виртуальными ЛС

Если в гостевой операционной системе необходимо предоставить более одной виртуальной ЛС, рассмотрите возможность переименования интерфейсов Ethernet для уточнения виртуальной ЛС, назначенной интерфейсу. Например, если вы свяжете интерфейс Ethernet с виртуальной ЛС 12 и интерфейсом Ethernet 2 с виртуальной ЛС 48, переименуйте интерфейс Ethernet в EthernetVLAN12 , а другой — на EthernetVLAN48.

переименуйте интерфейсы с помощью команды Windows PowerShell rename-NetAdapter или путем выполнения следующей процедуры:

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

Щелкните правой кнопкой мыши сетевой адаптер, который необходимо переименовать, и выберите команду Переименовать.

Введите новое имя для сетевого адаптера и нажмите клавишу ВВОД.

виртуальные машины;

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

объединение сетевых карт в Windows Server 2016 поддерживает команды с двумя членами виртуальных машин. Вы можете создавать крупные команды, но больше не поддерживаются крупные команды. Каждый член команды должен подключаться к другому внешнему коммутатору Hyper-V, а сетевые интерфейсы виртуальной машины должны быть настроены для поддержки объединения.

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

Сетевые адаптеры с поддержкой SR-IOV

Группа сетевых адаптеров в или на узле Hyper-V не может защищать трафик SR-IOV, так как он не проходит через коммутатор Hyper-V. С помощью параметра объединения ВИРТУАЛЬНЫХ сетевых карт можно настроить два внешних коммутатора Hyper-V, каждый из которых подключен к своей собственной сетевой карте с поддержкой SR-IOV.

Объединение сетевых карт с сетевыми адаптерами с поддержкой SR-IOV

Каждая виртуальная машина может иметь виртуальную функцию (VF) из одной или обеих сетевых адаптеров SR-IOV и, в случае отключения сетевого адаптера, отработки отказа из основного VF в адаптер резервного копирования (VF). Кроме того, виртуальная машина может иметь VF из одной сетевой карты и Вмник, отличной от VF, подключенной к другому виртуальному коммутатору. Если сетевая карта, связанная с VF, отключена, трафик может выполнить отработку отказа на другой коммутатор без потери подключения.

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

Связанные темы

Объединение сетевых карт. использование и управление MAC-адресами. при настройке группы сетевых карт с независимым режимом и при использовании хэша или динамического распределения нагрузки группа использует Mac-адрес основного члена группы сетевых адаптеров для исходящего трафика. Член группы основного сетевого адаптера — это сетевой адаптер, выбранный операционной системой из начального набора членов группы.

Параметры объединения сетевых карт. в этом разделе мы преддадим Обзор свойств группы сетевых адаптеров, таких как объединение и режим балансировки нагрузки. Кроме того, мы предоставляем подробные сведения о параметре адаптера ожидания и свойстве основного интерфейса группы. Если у вас есть по крайней мере два сетевых адаптера в группе сетевых адаптеров, не нужно назначать резервный адаптер для отказоустойчивости.

Создание группы сетевых адаптеров на главном компьютере или в виртуальной машине. в этом разделе вы создадите новую группу сетевых адаптеров на главном компьютере или на виртуальной машине Hyper-V, работающей Windows Server 2016.

Устранение неполадок объединения сетевых адаптеров. в этом разделе обсуждаются способы устранения неполадок объединения сетевых карт, таких как оборудование, безопасность физического коммутатора и отключение или включение сетевых адаптеров с помощью Windows PowerShell.

Переименование домена Active Directory

С выходом Windows Server 2012 технология NIC Teaming стала штатным средством серверной операционной системы. Долгое время решения по объединению (группировке) сетевых адаптеров для платформы Windows предоставлялись только сторонними производителями, прежде всего, поставщиками оборудования. Теперь Windows Server 2012 содержит инструменты, которые позволяют группировать сетевые адаптеры, в том числе, адаптеры разных производителей.

Что дает NIC Teaming?
Технология NIC Teaming, именуемая также как Load Balancing/Failover (LBFO), доступна во всех редакциях Windows Server 2012 и во всех режимах работы сервера (Core, MinShell, Full GUI). Объединение (тиминг) нескольких физических сетевых адаптеров в группу приводит к появлению виртуального сетевого интерфейса tNIC, который представляет группу для вышележащих уровней операционной системы.

Объединение адаптеров в группу дает два основных преимущества:

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

Включение и настройка
По умолчанию режим NIC Teaming отключен. Чтобы его активировать открываем Server Manager, заходим в свойства сервера и нажимаем ссылку Disabled напротив пункта Объединение сетевых карт (NIC Teaming). Далее , в открывшемся окне жмем на кнопку Задачи (Tasks) и выбираем пункт Создать группу (New Team).

Даем группе название и выбираем добавляемые адаптеры.

Затем настраиваем дополнительные свойства группы. Поскольку от этих параметров зависит эффективность работы NIC Teaming, стоит рассмотреть их поподробнее.

Режим поддержки групп (Teaming mode) определяет режим взаимодействия группы с сетевым оборудованием:

• Не зависит от коммутатора (Switch Independent) — группа работает независимо от коммутатора, никакой дополнительной настройки сетевого оборудования не требуется. Этот режим позволяет подключать адаптеры одной тиминговой группы к разным свичам для защиты от сбоя одного из них. Выбирается по умолчанию;
• Статическая поддержка групп (Static Teaming) — режим с зависимостью от сетевого оборудования. Все адаптеры группы должны быть подключены к одному коммутатору. Порты коммутатора, к которым подключены адаптеры группы, настраиваются на использование статической агрегации каналов;
• LACP — также зависит от сетевого оборудования. Коммутатор настраивается на использование динамической агрегации каналов с использованием протокола Link Aggregation Control Protocol (LACP).

Режим балансировки нагрузки (Load Balancing mode) определяет, каким образом распределять сетевой трафик между адаптерами группы:

• Хэш адреса (Address Hash) — при передаче сетевого трафика на основании MAC или IP-адресов отправителя и получателя вычисляется хеш (число). Это число привязывается к определенному физическому адаптеру и в дальнейшем весь трафик от этого отправителя будет идти через этот адаптер;
• Порт Hyper-V (Hyper-V Port) — в этом режиме осуществляется привязка адаптера тиминговой группы к определенному порту виртуального свича в Hyper-V. Этот режим используется в том случае, если на сервере активирована роль Hyper-V.

Резервный адаптер (Standby adapter) позволяет назначить один из адаптеров группы в качестве резервного. В нормальном состоянии резервный адаптер не используется для передачи трафика, но при выходе любого адаптера группы из строя сразу занимает его место и трафик продолжает передаваться без перерывов. Впрочем, даже без резервирования выход из строя одного адаптера в NIC Teaming не приведет к прерыванию сетевых операций, т.к. нагрузка будет автоматически распределена по оставшимся адаптерам.

Перейдем в окно «Сетевые подключения» панели управления и убедимся, что у нас появился новый сетевой адаптер (его иконка немного отличается). Это и есть виртуальный адаптер для нашей группы.

Если посмотреть свойства физических сетевых адаптеров, то мы увидим, что все компоненты кроме протокола мультиплексора сетевого адаптера отключены

Все настройки теперь производятся в свойствах виртуального адаптера.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

В прошлом году мы рассказывали о 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 2012R2 осуществлялось только через Virtual Machine Manager (VMM). Он был точкой хранения всех конфигураций виртуальной инфраструктуры и единой точкой отказа.
  • производители оборудования в качестве основного протокола использовали VXLAN, и лишь немногие внедрили поддержку NVGRE.

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-туннели.



Служба создания 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 и о некоторых интересных «подводных камнях», которые мы обнаружили в ходе тестирования.

Читайте также: