Windows Server 2019

---

29.01.2021

Проектирование базовых сервисов на основе Windows Server 2019

 

Часть 2. Репликация и отказоустойчивость.

 

Я снова всех приветствую. Продолжаем поднимать инфраструктуру на нашем воображаемом предприятии. В прошлой статье мы подняли базовые сервисы AD DS, DNS, DHCP. В этой статье мы возьмемся за второй железный сервер и сделаем так чтобы она повторял все роли первого сервера. То есть настроим репликацию и отказоустойчивость наших базовых сервисов. Не важно сколько учётных записей в организации 10 или 1000, в любом случае нельзя полагаться на один железный сервер. Для таких важнейших сервисов как AD DC, DNS и DHCP всегда должна быть дублирующая система. Если эти сервисы крутятся не на самом железе а на виртуальной машине, мы точно также реплицируем эти виртуальные машины на отдельном хосте. Отказоустойчивость должна быть обязательно, и не так важно дублируем ли мы зеркально сами виртуальные машины с сервисами, либо имеем параллельные аналогично настроенные виртуальные машины, в которых репликация настроена именно средствами самой windows, как в нашем случае. Проще говоря, имеем два железных сервера работающих как зеркало друг друга и в случае падения одного - пользователя даже не заметят что что-то из сервисов пропало так как всё обслуживание сразу на лету возьмёт на себя второй сервер. Ну а мы с вами, узнав от Zabbix что один сервер ушёл в офлайн, не спеша чиним его в то время как пользователи продолжают работать. Есть в мире рэйд массивов похожая тема - называется RAID 1 он  же зеркало. Это когда 2 одинаковых диска работаю в зеркальном режиме. При этом мы конечно имеем в распоряжении размер только одного диска, но зато если один диск погибает мы просто меняем его и зеркало восстанавливается без потери данных, и практически даже без простоя в работе. Но давайте за дело. На второй железный сервер точно также ставим операционную систему Windows Server 2019. Установка в том же порядке как на первом сервере. По завершению также как в предыдущей статье приводим в порядок определённые настройки:

- часовой пояс, 

- имя компьютера (dc02), 

- разрешаем RDP подключение, 

- назначаем статический адрес 10.101.0.252,

- Маска 255.255.255.0,

- Шлюз 10.101.0.254,

- DNS 10.101.0.253 и второй записью 127.0.0.1.

Естественно этот сервер для начала нужно ввести в наш домен. Давайте сделаем это. В Server Manager идём в пункт “Workgroup”:

 

Затем жмём кнопку “Change”

 

Имя компьютера оставляем, переставляем чек с Workgroup на Domain и прописываем наш домен “brn.mrstudio22.ru”.

 

Так как у нас ещё нет доменных пользователей, для авторизации используем нашего доменного администратора:

 

Сервер после перезагрузки станет частью домена:

 

Отлично! Первым сервисом репликацией которого мы займёмся будет конечно контроллер домена. Устанавливаем роль контроллера домена аналогично как мы делали на первом железном сервере dc01. Отличия начинаются при конфигурировании то есть после нажатия кнопки “Promote this server to a domain controller”. Что мы меняем в первом окне мастера - да собственно почти ничего, потому что этот сервер уже является частью домена и поэтому он сам определил что мы хотим развернуть контроллер в уже существующем домене, в существующем лесу. Так же сразу прописан и сам домен “brn.mrstudio22.ru”. Но вот данные пользователя нужно сменить на доменного администратора.

 

То есть чтобы вы понимали - я на втором сервере dc02 всё это время работал через локального администратора. Не доменного! То есть видите разницу, да? Есть сущность “DC02\Administrator” и есть “BRN\administrator” - в первом случае это локальная учётная запись а во втором доменная. Далее скрин с доменным администратором. 

 

Далее вбиваем пароль восстановления службы каталогов. И обратите внимание - он сам определил принадлежность к сайту “Barnaul”. Отметку на пункте “Global Catalog” можно оставить так как мы рассматриваем вероятность того что этот сервер может остаться единственным носителем контроллера в сети на какое-то время (пока чиним первый железный сервер).

 

Далее делегирование DNS мы пропускаем. А вот следующий диалог мастера очень интересен. Здесь мы собственно выбираем где основной контроллер с которого мы будем реплицироваться. И мы конечно выбираем наш первый сервер “dc01.brn.mrstudio22.ru”. Тут вы можете задаться вопросом - а почему такое длинное имя, почему просто dc01 нельзя? Тут по идеи надо углубиться в теорию о том что есть FQDN то есть полное доменное название компьютера. По сути это просто имя машины плюс полное имя домена, но всё вместе это более правильное название сущности в сети. 

 

Пути NTDS/SYSVOL оставляем по умолчанию. А вот на следующем этапе есть интересная кнопка “View Script”. 

 

 

И тут мы можем посмотреть скрипт PowerShell. То есть всё что мы делали через мастер этим скриптом можно сделать одной командой PowerShell. Полезно когда нужно поднять 50 контроллеров для репликации.

Жмём “next” и следом “install”. После чего сервер сообщает что он сконфигурирован как контроллер домена и непременно хочет перезагрузки:

 

 

После перезагрузки “внезапно” система уже предлагает авторизоваться под доменным администратором. 

 

После перезагрузки в Server Manager наблюдаем что и DNS тоже поднялся. И что особенно примечательно что он стянул данные с основного DNS сервера. То есть репликация DNS у нас уже есть! Обратите внимание что появилась запись типа (NS) и для второго сервера что означает, как раз, именно репликацию.  

 

Теперь когда на сервере dc02 есть репликация DNS мы можем вписать дополнительный DNS на сервере dc01:

Отлично! Но давайте проверим что у нас реплицируется сам контроллер. Мы создадим доменного пользователя и проверим появится ли он на втором сервере. Идём на первый сервер “dc01” -  далее в Server manager - tools - Active Directory Users and Computers.

 

 

В разделе Users мы видим кучу групп, доменного админа и отключенного гостя. Это всё здорово но нам же надо заводить своих пользователей. 

 

 

Тут надо остановиться и крепко задуматься! О чём? Жмём правой кнопкой, да создаём Васю Пупкина и дело в шляпе? Нет! Нужно подумать о многих вещах. Например о том что у нас могут быть филиалы в разных городах и поэтому надо делать каталог отдельно для каждого города. И в каждом таком отдельном каталоге уже будут пользователи и компьютеры именно этого филиала. Ещё надо подумать о том что мы захотим распространять на отдельные филиалы групповые политики. То есть на какие-то будем а на какие-то нет, и поэтому нельзя всё складывать в один каталог. И ещё обратите внимание на сами каталоги, у одного другой значок.

 

 

И тут просто дело в том что “Domain Controllers” это организационная единица а остальные это контейнеры. И важно знать что групповые политики распространяются только на организационные подразделения. Поэтому, хорошо обдумав всю нашу филиальную инфраструктуру, с вероятной моделью расширения, мы начинаем с того что что создадим OU (Organizational Unit) с названием города.

 

 

 

И в этой OU мы создаём OU “Users” и OU “Computers”:

 

 

Вот теперь порядок. Создадим пользователя “Елисеева Анна Петровна”. 

 

Имя пишем латиницей, Last name пишем латиницей. Зачем? Потому что когда начнете поднимать какие-то сервисы, которые будут сами брать учётные данные из домена - они ничего не смогут взять если эти данные будут на кириллице. А вот строчка “Full name”, она же в свойствах учётки “Display name”, можно писать на русском - именно эти буквы увидит пользователь на экране приветствия.

 

Обратите внимание на то что у пользователя также как и у компьютеров есть тоже полное доменное имя:

 

Ждём несколько минут, затем переходим на сервер dc02 и наблюдаем что все данные о подразделениях, которые мы создали на dc01 и пользователе успешно реплицировались. И если вам не хочется ждать можно в командной строке сервера dc02 набрать команду repadmin /kcc * да там есть  звёздочка на конце. Данная команда форсирует репликацию по всем контроллерам.

 

 

команда  repadmin /replsummary покажет когда была репликация по расписанию (не форсированная) и были ли ошибки в процессе.

 

Будучи на самом первом сервере dc01, для форсирования репликации можно также использовать команду repadmin /syncall /aes.

 

 

Либо мы можем в оснастке “Active Directory Sites and Services” сделать это в NTDS Settings каждого контроллера. Почему бы и нет если у вас всего пара контроллеров.

 

Теперь давайте сделаем репликацию DHCP. Вообще-то в рамках сервиса DHCP не происходит именно дублирование самой службы. Тут больше речь об отказоустойчивости методом “на подхвате”. Для достижения цели мы естественно поднимаем роль DHCP Server.

 

 

Также как и при установки на первом сервере dc01 мы жмём на “Complete DHCP configuration”.

 

 

И также проводим авторизацию через учётную запись BRN\administrator. Открыв оснастку DHCP мы разумеется не видим область которую мы создавали на первом сервере.

 

 

Идём на первый сервер dc01 там где мы создавали область (scope) - Жмём правой кнопкой по области и выбираем “Configure Failover...”

 

Запустится мастер настройки отказоустойчивости DHCP роли. На первом этапе мастер спрашивает какую именно область мы будем делать отказоустойчивой, и предлагает выбрать адрес сети закрепленный за этой областью. Так как область у нас одна мастер по умолчанию поставил галочку “все области”. Просто жмём next.

 

Далее выбираем сервер dc02.

 

Хотя проще было просто набрать полное доменное имя второго сервера:

 

Жмём next. Небольшое отступление - я словил вот такую ошибку:

 

Такое может произойти если на серверах часы идут в разнобой с разницей в 60 сек и более. У меня вообще на dc01 стоял вчерашний день. Но если у вас с синхронизацией часов между серверами всё хорошо, то вы увидите это:

 

Мастер нас спрашивает как назвать отношения между этими двумя DHCP серверами - давайте сделаем покороче но так чтобы мы понимали какие сервера тут участвуют, например вот так “dc01-dc02.brn”. Далее режим “Mode” меняем на “Hot standby” - то есть второй сервер dc02 будет “на подхвате”. Режим “Load balance” - это полноценная работа двух серверов сразу, с настраиваемым балансом нагрузки - такой цели мы не преследуем, мы хотим просто страхующий второй сервер. Убираем галочку “Enable Message Authentication” - хотя можете и использовать парольную фразу для аутентификации, это на ваш выбор. Остальное оставляем как есть и жмём Next.

 

Далее жмём “Finish”:

 

Идём на сервер dc02 и в оснастке DHCP видим налу область “brn01”. Отлично!

Мы настроили базовые сервисы и сделали отказоустойчивость. Самое время идти на рабочие станции и вводить их в домен. Предварительно создав всех пользователей конечно. Но об этом в следующей статье.