 |
|
|
|
Разговор на «ты». Репликация Active Directory
Разговор на «ты» Одна из главных рекомендаций Microsoft касательно ADDS – необходимость развертывания в производственной среде не менее двух контроллеров домена. Однако их может быть гораздо больше Когда системный администратор начинает работать в крупной сети на базе Active Directory Domain Services (ADDS), его одной из важнейших забот становится репликация Active Directory. Даже если учесть, что этот механизм полностью автоматизирован и при правильной изначальной конфигурации редко требует вмешательства, не стоит забывать о таких реалиях жизни, как выключения света, медленные и нестабильные каналы, ошибки администраторов и просто внештатная работа службы, вызванная вспышками на Солнце или лунным затмением. Как раз для борьбы с вышеперечисленными недугами и необходимо понимание механизмов репликации, а также способов управления ею. База данных Active Directory
Впервые появившись в Windows Server 2000, технология Active Directory (это прежде всего транзакционная база данных, содержащая информацию об объектах вашей сети, глубоко интегрированная с системой безопасности Windows) более чем за девять лет претерпела некоторые изменения. Но даже в Windows Server 2008 R2 работает на хорошо зарекомендовавшем себя движке Extensible Storage Engine (ESE). Если верить расчетам масштабируемости, данного решения должно хватить даже сетям с несколькими миллионами объектов, а вырасти база может до 16 терабайт. Сердцем Active Directory является файл NTDS.DIT, в котором, собственно говоря, вся информация и хранится. При добавлении второго и последующих контроллеров домена происходит создание копии данного файла и размещение ее на введенном в строй новом контроллере. Можно сделать четкий вывод: каждый контроллер домена хранит свою версию файла NTDS.DIT. Важно понимать, что при открытии оснастки для работы с Active Directory, а это может быть «Active Directory Пользователи и Компьютеры» или, как вариант, «Active Directory Сайты и Сервисы», вы всегда подключаетесь к конкретному контроллеру домена. И при желании можете выбрать, с каким контроллером работать. Это означает, что вы работаете с конкретной версией базы данных, которая в настоящий момент может отличаться от других копий. Естественно, создавая учетную запись либо меняя конфигурацию, изменения вносятся только в один файл NTDS.DIT, который находится на контроллере, куда подключена оснастка (или любой другой инструмент управления). После внесения изменений критически важно оповестить другие контроллеры о них и новых данных и как можно скорее произвести синхронизацию. В Active Directory этот процесс синхронизации называется репликацией, в дальнейшем будет использован именно этот термин. Особенно важно помнить эти факты, когда вы занимаетесь решением проблем с репликацией Active Directory и вносите изменения в контекст конфигурации AD. Это происходит тоже на конкретном контроллере и с конкретным файлом NTDS.DIT. Физически NTDS.DIT – это просто один файл, но логически он состоит из нескольких разделов (иногда их называют контекстами именования или контекстами репликации), каждый из которых содержит определенную информацию и реплицируется по-своему. Раздел Schema хранит в себе схему Active Directory, которая описывает, какие объекты могут быть созданы и что они собой будут представлять. Меняется реже всего, как правило, при переходе контроллеров на новую операционную систему либо при установке в организации почтовой системы Exchange. Процесс изменения базы данных в контексте схемы чаще всего называют расширением схемы, и это не случайно, т.к. отменить данные изменения (например, удалить созданные в этом контексте объекты) невозможно. Репликация раздела осуществляется на все контроллеры домена в лесу Active Directory. Единственный раздел, чья репликация не является мультимастерной. Репликация раздела Schema всегда односторонняя и выполняется от контроллера домена, владеющего ролью FSMO «Хозяин Схемы», на все оставшиеся контроллеры домена (см. рис. 1). (Впоследствии оставшиеся контроллеры домена реплицируют информацию своим репликационным партнерам, но источником этой цепочки репликации всегда будет «Хозяин схемы».)
Посмотреть на каждый раздел каталога и данные, в нем хранящиеся, можно через утилиты ADSI Edit AdExplorer и LDP.exe (см. рис. 2). Утилиту (AdExplorer) можно скачать с сайта Microsoft, она входит в комплект утилит Sysinternals. А LDP.exe становится доступна после установки на контроллер домена Windows Support Tools. Следует отметить, что данный комплект не потерял своей актуальности и после выхода Windows Server 2008.
Рисунок 2. Выбор раздела для подключения в утилите LDP.exe Теперь важно уяснить следующее: когда клиент аутентифицируется на контроллере домена и применяются групповые политики, образуется трафик (85 Кб на вход станции в домен – с DefaultDomainPolicy и 75 Кб на вход пользователя – тоже с DefaultDomainPolicy). Более того, репликация изменений между контроллерами доменов порождает свой репликационный трафик. Этим трафиком нужно управлять. Представьте себе, что организация и, естественно, ваш домен Active Directory располагается в двух городах, связанных WAN-каналом. Однажды все пользователи филиала в Ростове-на-Дону начнут обращаться к контроллеру, расположенному в центральном московском офисе. А контроллеры домена начнут реплицировать информацию в любое время и по первому требованию. Минимум с чем вам придется столкнуться – это высокая утилизация WAN-канала и медленный вход пользователей в домен. Поэтому в Active Directory введено понятие сайтов. Репликация в рамках одного сайта Active Directory Сайт – это логическое объединение контроллеров домена и клиентов для управления служебным трафиком службы каталогов. Если ваш Лес Active Directory не распространяется за пределы одного сегмента локальной сети, следовательно, вы работаете с односайтовой структурой. Именно она является дефолтной, именно с нее мы начнем разговор. При создании Active Directory и поднятии (подразумевается процедура dcpromo) первого контроллера домена формируется сайт по умолчанию с именем Default-First-Site-Namе. Если не создавать дополнительных сайтов и придерживаться односайтовой структуры, все новые контроллеры будут попадать в данный сайт. После появления второго и последующих контроллеров должны образоваться Репликационные связи (connection objects), указывающие на то, какой контроллер и откуда должен реплицировать изменения. Посмотреть эти связи можно через оснастку «Active Directory Сайты и Службы». На рис. 3 открыта оснастка «ActiveDirectoryСайты и Службы». По имеющейся информации можно сказать, что в данном примере есть единственный сайт по умолчанию, в котором находятся два контроллера домена Server1 и Server2. А также что Server1 имеет партнера по репликации Server2 и реплицирует с него изменения. Без наличия данных связей репликации между контроллерами работать не будут.
Рисунок 3. Свойства репликационной связи Нередки случаи, когда системные администраторы, установив новый контроллер домена, не находят у него данных связей и начинают создавать их руками. Это распространенная ошибка. За создание связей, базируясь на определенной логике, отвечает служба KCC (Knowledge Consistency Checker). Самостоятельное создание связей чревато возникновением ошибок и дальнейшей путаницей. Для тех же, кто не хочет ждать, пока KCC справится с задачей, существует способ ее поторопить. Для этого необходимо использовать утилиту Repadmin с ключом kcc. Синтаксис будет выглядеть следующим образом: #Вместо server1.itband.ru вы укажете FQDN вашего сервера Если нужно запустить генерацию связей на всех контроллерах домена в сайте, то команда Repadmin принимает вид: #Если имя сайта было изменено, "Default-First-Site-Name" заменяется реальным именем Можно также запустить процесс генерации топологии на всех контроллерах леса командой repadmin /kcc *. Большинство опций команды repadmin поддерживают ключ /async, который дает задание контроллеру домена и при этом не ожидает его завершения. Без административного вмешательства служба KCC стартует на каждом контроллере домена раз в 15 минут, в случае необходимости добавляет или удаляет лишние репликационные связи (учтите, что связи, созданные вручную, не управляются KCC). Логика создания связей в рамках одного сайта кажется довольно простой. Каждый контроллер не реплицируется с каждым, служба KCC всегда пытается создать кольцо репликации, причем по мере добавления новых контроллеров кольцо будет расширяться. Расширение не бесконечно, при создании связей существует «правило трех прыжков». Это значит, что между двумя контроллерами домена при репликации не может быть больше трех посредников. Как только число контроллеров достигнет восьми, правило «трех прыжков» приведет к тому, что служба KCC выполнит «ход конем» и добавит дополнительные прямые связи, сокращая расстояние между двумя любыми контроллерами до допустимого значения «максимум в три прыжка». Данная ситуация хорошо проиллюстрирована на рис. 4. Создание связей между контроллерами, расположенными в разных сайтах, выполняется с учетом топологии сайтов, сайт-линков и мостов между сайт-линками. Подробнее о построении межсайтовой репликации читайте в следующей части статьи. Следует отметить, что кольцо при создании топологии репликации строится независимо для каждого контекста репликации (раздела Active Directory), далее эти кольца накладываются друг на друга, и выясняется, где можно вместо нескольких репликационных связей обойтись одной.
Рисунок 4. Принцип создания связей репликации службой KCC Внутрисайтовая репликация начинается, когда в Active Directory происходит изменение. Это может быть изменение атрибута или создание учетной записи. Контроллер домена, в базе которого произошли перемены, ожидает 15 секунд, а затем отправляет ближайшему партнеру репликации уведомление о том, что на нем произошло какое-то обновление. При наличии двух и более партнеров по репликации, последующие уведомления отправляются каждому партнеру с трехсекундной задержкой (верно для уровня леса Windows 2003 и выше, для Windows 2000 первичная задержка составляет 300 секунд, а последующие – 45 секунд). После получения уведомления об изменении партнер репликации проверяет возможность репликации и список обновлений и выполняет процесс репликации с тем контроллером, который прислал уведомление. Трехсекундная задержка предотвращает чрезмерную загрузку из-за одновременных запросов обновлений от множества партнеров по репликации. Периоды нотификаций можно настроить командой repadmin /notifyopt. Следует обратить особое внимание читателей, что процесс репликации всегда происходит в режиме pull, т.е. «стягивания» изменений и новых объектов, но не в режиме push. Это связано с тем, что только контроллер – хозяин файла NTDS.DIT – имеет право в нем что-то изменять, он отвечает за целостность своей БД. Из этого также следует, что все линки репликации, которые создаются вручную или службой KCC, имеют однонаправленную природу, т.е. логически обозначают входящий поток репликационной информации. Некоторые изменения реплицируются без пятнадцатисекундной задержки. Такая репликация называется срочной (urgent replication). В события, ее вызывающие, входят блокировки учетных записей, изменение пароля учетной записи. В официальных документах присутствует путаница. По сути, это не репликация вовсе, механизм передачи этих изменений в корне отличается от процесса репликации, хотя в качестве транспорта используется тоже протокол RPC. Такая репликация выполняется не обычным механизмом репликации, а специальными вызовами RPC. По сути, это запросы, аналогичные изменению объектов через ADSI. В зависимости от режима работы леса список событий может меняться. Если внимательно присмотреться к свойствам репликационной связи, то можно найти расписание репликации, по умолчанию оно установлено на ежечасный запуск. Возникает вопрос: зачем еще одно расписание, если есть система уведомлений? Данное расписание является основным и обязательным способом репликации (см. рис. 5). Несмотря на то что система уведомлений, описанная выше, в большинстве случаев обеспечивает синхронизацию до запуска этого расписания, она не гарантирует успеха. Возможна ситуация, когда контроллер домена будет занят on-line-дефрагментацией базы, пересчетом связей службой KCC и просто проигнорирует необходимость обработать пришедшие к нему уведомления об изменениях на партнерах по репликации. В такой ситуации изменения будут прореплицированы в течение часа.
Рисунок 5. Расписание репликации При возникновении трудностей с репликацией можно, используя утилиту replmon, вручную запустить процесс репликации, не дожидаясь расписания: repadmin /replicate server2.itband.ru server1. itband.ru dc=itband,dc=ru С ключем /replicate необходимо задать, куда (server2.itband.ru) и с какого контроллера (server1.itband.ru ) должны реплицироваться данные, а также какой раздел каталога нужно реплицировать (dc=itband,dc=ru). Запустить репликацию всех разделов Active Directory в рамках всего леса (в рамках существующей топологии) довольно легко, для этого следует выполнить: Repadmin /syncall /AeS Учтите, что в крупных сетях такой запуск репликации может вызвать серьезный поток трафика, который пойдет не только по скоростным каналам. Алгоритм распространения изменений Теперь необходимо разобраться, как после получения репликационного уведомления от партнера контроллер домена решит, есть ли изменения, необходимые для репликации? Если есть, то какие объекты или их отдельные атрибуты должны быть прореплицированы? Алгоритм выглядит следующим образом. Любой контроллер домена ведет некий счетчик, называемый highestCommittedUSN, который увеличивается на единицу при любом атомарном изменении базы Active Directory. При этом у каждого контроллера домена счетчик свой и между контроллерами его значения не совпадают. Например, в 9 утра значение highestCommittedUSN у контроллера DC1 было равно 14879, а в 6 вечера 14896. Это значит, что за прошедшее время в базе данного контроллера произошло 17 изменений. Посмотреть значение highestCommittedUSN можно с помощью утилиты ldp, просто подключившись к нужному контроллеру домена. При подключении выводится состояние динамического системного объекта RootDSE, среди атрибутов которого как раз и присутствует highestCommittedUSN (см. рис. 6).
Рисунок 6. Просмотр значения highestCommittedUSN на контроллере домена После проведенной репликации каждый контроллер домена кэширует значения highestCommittedUSN своих репликационных партнеров. И когда впоследствии контроллер домена DC1 получит уведомление от контроллера DC2, в нем будет информация о текущем highestCommittedUSN DC2. Контроллеру DC1 останется только сравнить текущий highestCommittedUSN с тем, который он закэшировал во время прошлой репликации. Если он вырос, значит, в базе DC2 произошли изменения и необходимо произвести репликацию. Если остался прежним, то в ней нет необходимости. Таблица, в которой хранится информация о highest CommittedUSN репликационных партнеров, называется вектором обновления, или up-to-date vector. Посмотреть ее можно с помощью утилиты repadmin. repadmin /showutdvec dc1 dc=lab,dc=itband,dc=ru
В данном примере результатом будет вывод значений highestCommittedUSN репликационных партнеров DC1 (а также актуальный USN его самого), это будут значения, о которых DC1 знает, в действительности они могли вырасти по причине внесения изменения в базу на тех контроллерах. Следует помнить, что highestCommittedUSN увеличивается как после изменений, внесенных в базу непосредственно на контроллере, так и после изменений, прореплицированных с других контроллеров (см. рис. 7).
Рисунок 7. Просмотр вектора обновлений на контроллере DC1 Есть одно «но». Сам по себе up-to-date vector отвечает на вопрос: были ли изменения? Этого недостаточно, необходимо вычислить, что изменилось. Давайте рассмотрим данный механизм на примере. В нашей сети находятся два синхронизированных контроллера домена (DC1и DC2). До изменений highestCommittedUSN у DC1 равен 20902, а у DC2 16940. На контроллере DC1 создается учетная запись пользователя Федя Рашпин. После создания учетной записи highestCommittedUSN на DC1 стал показывать 20909. Это говорит о том, что было произведено семь изменений. Напоминаем, что считаются атомарные изменения, т.е. создание учетной записи можно разложить на само создание плюс изменение ряда атрибутов, которые выполняет оснастка Active Directory Users and Computers. Если пользователь подключится через LDP.exe к нашему объекту, то можно увидеть два атрибута uSNCreated и uSNChanged (см. рис. 8).
Рисунок 8. Просмотр атрибутов uSNCreated и uSNChanged для учетной записи uSNCreated будет говорить, какой highestCommittedUSN был в момент создания объекта на данном контроллере, а uSNChanged – в момент последнего изменения. Получается, что первый показатель (uSNCreated) будет оставаться неизменным, а второй, в свою очередь, (uSNChanged) по мере обновления объекта будет расти. Важно понимать, что uSNCreated и uSNChanged на каждом контроллере домена у объекта будут свои. Посмотрим на пользователя Федя через утилиту repadmin. Для получения служебной информации, используемой при репликации, задействуем ключ /showmeta. repadmin /showmeta "CN=Федя Рашпин,OU=testou,DC=lab,DC=itband,DC=ru" При этом нас интересует информация с каждого контроллера. Но начнем с DC1. Какую же информацию нам дает repadmin (см. рис. 9)? Данный список – это объект пользователя, разложенный по атрибутам.
Рисунок 9. Вывод метаданных о созданном пользователе на DC1 По каждому атрибуту можно увидеть:
Взглянув на эту таблицу, можно сделать вывод, что пользователь «Федя Рашпин» был создан (или изменен) на контроллере домена DC1, при этом увидеть, что highestCommittedUSN DC1 в процессе создания учетной записи рос от 20904 до 20909 (Org.USN). Совпадение колонок Loc.USN и Org.USN говорит о том, что запуск repadmin /showmeta произведен на контроллере домена, который был автором изменений. Если выполнить то же самое на втором контроллере, результат будет несколько другой (см. рис. 10).
Рисунок 10. Вывод метаданных о созданном пользователе на DC2 На DC2 четко просматривается, что автором всех изменений (кроме одного) были DC1 и его highestCommittedUSN (Org.Usn) в момент изменения каждого атрибута. А также highestCommittedUSN в момент внесения обновлений в базу контроллера DC2 (Loc.USN). А вот теперь пора сделать небольшой вывод. Когда контроллер домена рассылает репликационным партнерам уведомления об обновлении базы, он сообщает свой текущий highestCommittedUSN. Партнер, получивший уведомление, сравнивает этот highestCommittedUSN с тем, что он запомнил с прошлой процедуры репликации. Если он вырос, значит, необходимо запускать репликацию. Например: DC2 получил от DC1 уведомление и текущий highestCommittedUSN, равный 20912, он сравнивает с известным ему значением 20850. Делает вывод о необходимости репликации и запрашивает изменения, произошедшие в период роста highestCommittedUSN с 20850 до 20912. DC1 осуществляет выборку из своей базы. Для этого просматривается Loc.USN, и те атрибуты, которые менялись в заданном диапазоне highestCommittedUSN, реплицируются на DC2. Решение конфликтов Не исключена ситуация, когда один и тот же атрибут будет меняться одновременно на двух и более контроллерах домена. Как быть в такой ситуации? Существует строгий механизм разрешения конфликтов. Правило первое. Можно было заметить в метаданных репликации параметр Ver. Как уже было сказано, он увеличивается на единицу каждый раз при изменении атрибута. Если сразу на двух контроллерах происходит изменение атрибута, в первую очередь будет произведено сравнение номера версии. Атрибут, имеющий более высокий номер версии, является приоритетным. Именно его значение будет использоваться. Правило второе. Если номер версии совпадает, учитывается время изменения атрибута. Значение, установленное по времени последним, выигрывает. В гипотетической ситуации, когда изменения атрибута на разных контролерах имеют один номер версии, да и сделаны в одно время, победит тот контроллер, который имеет больший номер GUID. Возможно несколько любопытных ситуаций. Один администратор решает удалить пустое организационное подразделение, другой же на соседнем контроллере в это время создает учетную запись. Получается явный конфликт интересов. В такой ситуации будет задействован скрытый контейнер LostAndFound, получить доступ к которому можно, только переключив оснастку «Active Directory – пользователи и компьютеры» в расширенный режим (см. рис. 11).
Рисунок 11. Контейнер LostAndFound Новый созданный пользователь будет перемещен в данный контейнер, а организационное подразделение удалено. Впоследствии администратор перенесет учетную запись в более подходящее место. Другой вид разногласий может возникнуть в случае одновременного создания объектов с одинаковыми именами, это может быть организационное подразделение или учетная запись пользователя. В такой ситуации принцип довольно простой: объект, созданный первым, переименовывается, точнее, к его имени добавляется objectGUID. Если необходимость в этом объекте впоследствии сохранится, ничто не мешает администратору дать ему новое имя (см. рис. 12).
Рисунок 12. Автоматическое разрешение конфликта Большим преимуществом с точки зрения репликации является переход на режим работы домена Windows Server 2003 и более поздние. В них изменилась процедура репликации атрибутов типа linked-valued (пример: «Членство в группах»). При добавлении разных пользователей на разных контроллерах в одну и туже группу результатом будет членство всех добавленных пользователей в составе этой группы. В случае с Windows 2000 состав группы при таком конфликте определялся бы по ее членству на том контроллере, на котором изменения в группе были бы сделаны позже по времени. На этом хотелось бы закончить первую часть статьи, в следующей части мы поговорим о построении сайтов и особенностях межсайтовой репликации. |
| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
