КАК: устранить задержки репликации Active Directory для удаленных сайтов
Многие крупные организации по-прежнему в значительной степени полагаются на платформу служб Microsoft Active Directory. Active Directory функционирует как центральный сторожевой механизм поиска и контроля доступа для вашей сети на базе Windows. Без надежно функционирующей службы Active Directory у пользователей возникнут проблемы со входом в систему на своих компьютерах и доступом к общим сетевым ресурсам, таким как файловые хранилища, принтеры и другие службы. Ключом к тому, как Active Directory работает в более крупной организации, является функция репликации, и нередко возникают задержки репликации Active Directory.
Хотя Active Directory представляется пользователям и устройствам как централизованная служба, на самом деле ее каталог объектов распределен по нескольким системам, называемым контроллерами домена. Каждый контроллер домена должен поддерживать актуальный и точный каталог объектов каталога, необходимых пользователям и устройствам, которые могут получить к нему доступ. Поэтому, когда репликация AD по какой-либо причине дает сбой или не работает должным образом, начинают происходить задержки репликации Active Directory, что влияет на пользователей, пытающихся выполнить свою работу.
По моему опыту и опыту моих коллег, которые работают консультантами в различных организациях, одной из самых больших проблем является обеспечение надежной репликации в больших средах Active Directory с центральным расположением луча. Подобные организации обычно имеют центр обработки данных в своей корпоративной штаб-квартире, который действует как концентратор или центр их инфраструктуры Active Directory. Затем эта штаб-квартира соединяется с помощью различных медленных каналов глобальной сети с удаленными филиалами, которые действуют как спицы в ступичном колесе того, как AD развертывается в компании.
Эта картина колеса с одной ступицей и спицами, выходящими к ободу, в общих чертах описывает более крупную топологию сети, которую организация использует для объединения локальных сетей в головном офисе и всех филиалах в единую большую сеть. И хотя лес Active Directory можно логически разделить на домены и деревья доменов различными способами, большинство организаций выбирают самый простой вариант развертывания одного домена на большинстве своих сайтов. Тем не менее, даже если вы пытаетесь максимально упростить развертывание AD, обеспечение надежной репликации на всех контроллерах домена может оказаться проблемой. Ситуация может стать еще более сложной, если организация использует более одного концентратора в своем развертывании AD.
Устранение задержек репликации Active Directory
Эта проблема недавно была поставлена передо мной моим коллегой, который поделился своим опытом помощи организации в решении периодически возникающих проблем, которые, как они подозревали, могли иметь какое-то отношение к репликации AD. Я изменил некоторые детали этого сценария, чтобы сделать организацию анонимной, но основная проблема заключается в следующем. Компания, которую мы назовем Contoso, имеет три центральных сайта и более 500 удаленных сайтов, связанных вместе с помощью Active Directory в Windows Server 2012 R2. Подозревая, что могут возникать ошибки репликации AD, администратор начал периодически запускать repadmin /replsummary, чтобы получить быстрые сводки о работоспособности репликации своей инфраструктуры AD. Эта команда предоставит вам полезную информацию, такую как общее количество попыток репликации, которые были предприняты за последнее время, сколько из этих попыток не удалось, а также самые большие дельты репликации. Она обнаружила, что в некоторых случаях время последней репликации составляло около 15 минут, а в других случаях оно могло составлять час или даже несколько часов. Поскольку ошибки репликации не отображались, а также с учетом большой распределенности инфраструктуры AD, более длительное время репликации не было слишком большой проблемой.
Однако после запуска repadmin /replsummary в течение нескольких недель администратор заметил кое-что странное: несколько блоков их контроллеров домена испытывали задержки репликации Active Directory на несколько дней или более, опять же без каких-либо сообщений об ошибках репликации. Затем она поговорила с руководителем группы сетевой инфраструктуры своей организации и обнаружила, что в настоящее время они занимаются проектом по реализации сетевого качества обслуживания (QoS) в сетевой инфраструктуре организации, и в рамках этой инициативы они присвоили более низкий приоритет Трафик репликации контроллера домена по сравнению с некоторыми другими типами сетевого трафика. Было высказано предположение, что в результате добавления этого QoS увеличилась задержка WAN для трафика репликации контроллера домена, поэтому сетевой группе был сделан запрос на повышение приоритета трафика репликации. Это был разумный шаг, но, к сожалению, он не решил проблему.
Пробуем другой подход
Поговорив с несколькими коллегами, имевшими опыт работы с Active Directory, администратор решил проверить, могут ли попытки репликации стоять в очереди на контроллерах домена, расположенных на центральных сайтах. Чтобы определить это, она использовала команду repadmin /queue, чтобы узнать, не перегружает ли AD контроллеры домена на узловых сайтах в отношении операций репликации. Результат выполнения этой команды показал, что длина очереди действительно сильно варьируется и колеблется от 50 до более чем 500 объектов в разное время, поэтому она попыталась принудительно выполнить репликацию между центральным сайтом и одним из удаленных сайтов, чтобы посмотреть, что произойдет — и еще раз обнаружил, что репликация в итоге завершилась без ошибок.
Следующее, что попытался сделать администратор, — это отследить некоторые счетчики производительности на контроллерах домена на центральных сайтах. Для этой цели использовался монитор производительности, встроенный в Windows Server инструмент, и за определенный период времени были собраны стандартные счетчики для процессора, сети, диска и памяти. Однако анализ полученных данных журнала показал, что центральные контроллеры домена явно не испытывают каких-либо узких мест в отношении какого-либо из этих ресурсов. Таким образом, то, что приводило к тому, что попытки репликации становились в очередь на центральных контроллерах домена, было явно не из-за того, что эти контроллеры домена были перегружены.
Решение проблемы
Чувствуя себя немного прижатым к стенке, администратор наконец обратился к другому администратору AD из другой крупной организации. Оказалось, что ее коллега тоже столкнулся с подобными проблемами и тщательно изучил их с помощью кого-то из Microsoft Consulting Services. Он обнаружил, что такой сценарий репликации оказался довольно распространенным в крупных распределенных развертываниях AD со звездообразной конструкцией и коренится в том, как репликация Active Directory происходит под капотом. Это связано с тем, что входящая репликация AD носит последовательный характер, а это означает, что только одна входящая комбинация DC/NC может быть активна в любой момент времени. А поскольку репликация является последовательной, ваши контроллеры домена будут проводить большую часть своего времени, просто ожидая завершения попыток репликации, поэтому мониторинг этих контроллеров домена не покажет значительной нагрузки на них.
Это также означает, конечно, что, если соединения WAN между вашим узловым и лучевым сайтами испытывают серьезные задержки, весь процесс репликации может начать испытывать значительные задержки. К этому добавляется проблема, заключающаяся в том, что разные разделы AD имеют разные приоритеты репликации, при этом схема имеет наивысший приоритет, а любые разделы приложений DNS имеют самый низкий приоритет. Из-за этого репликация DNS, выполняемая Active Directory в таких средах, иногда может настолько задерживаться, что не может произойти, что, конечно, может привести к различным проблемам, таким как сбой аутентификации TLS для веб-приложений.
Тогда решение проблемы оказалось довольно простым. Во-первых, администратор увеличил количество серверов-плацдармов AD. Когда вы связываете два сайта, таких как центральный сайт и лучевой сайт, для репликации AD между ними, AD использует специально назначенные контроллеры домена, называемые серверами-плацдармами, для эффективного сбора и управления изменениями репликации. Другими словами, серверы-плацдармы функционируют как точки контакта для обмена информацией о каталогах между сайтами в развертывании AD. Эти серверы-плацдармы могут быть выбраны либо автоматически с помощью функции Active Directory, называемой средством проверки согласованности знаний (KCC), либо они могут быть назначены администратором вручную. Администратор Contoso обнаружил, что в ее инфраструктуре AD не хватает плацдармов из-за очень высокого соотношения удаленных сайтов и узловых сайтов. Было обнаружено, что при удвоении числа узловых сайтов репликация происходит с несколько меньшей задержкой.
Второе, что сделал администратор Contoso, — увеличил расписание интервалов межсайтовой репликации до тех пор, пока не было обнаружено, что очереди репликации для всех плацдармов сократились до такой степени, что они достигают нуля по крайней мере один раз в день. Расписание межсайтовой репликации — важный параметр настройки репликации AD, который указывает, как часто контроллер домена, выступающий в роли сервера-плацдарма на сайте, запрашивает изменения у своего исходного партнера по репликации на другом сайте. Чтобы настроить частоту межсайтовой репликации для репликации AD, см. эту страницу TechNet.