Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

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


Предыстория…

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

— Primary AD железный (достаточно старый еле ползущий сервак HP, от которого мы планировали избавиться)

— Secondary AD виртуальный (уже все как положено, быстрый на Windows 2012).

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

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

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

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

— Ребутнули железный PDC, он благополучно перезагрузился и поднялся, стал работать по-прежнему, как надо, но репликации со вторым контроллером так и не появилось. Это нам говорило о том, что второй контроллер хоть и пингуется, но тоже в анабиозе.

— Далее авторизуемся локально на Vcenter понимаем на каком хосте крутится SDC, далее уже принудительно ребутаем SDC, он благополучно поднимается, поднимается репликация с PDC, но авторизация на всех остальных (файл-серверах, терминальных серверах и прочих серверах…), так и не работает.

— Пришлось принудительно перезагрузить все виртуальные сервера, чтоб полноценно восстановить работу и вернуть их в строй.

Неприятный момент.

До этого случая планировали приобрести более быстрый железный сервак и смигрировать, текущий 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

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

Всем хорошей работы!!!

 

 

Реклама

28.03.2018 - Posted by | ms windows 2016

1 комментарий

  1. […] прошлом посте, рассказал, как объединить порты для […]

    Уведомление от Новый DC на Windows 2016. Устанавливаем контроллер. « Blog of Khlebalin Dmitriy | 29.03.2018


Sorry, the comment form is closed at this time.

%d такие блоггеры, как: