Внутрисайтовая репликация ч.1 - теоретическая
Опубликовано ср, 08/17/2011 - 12:47 пользователем alex1812
По просьбе коллеги Eljor, рассмотрим такой вопрос как внутрисайтовая репликация (т.е. репликация внутри одного сайта). Т.к. тема достаточно объемная постараюсь быть краток и описать самое важное.
Итак, что же такое сайт?
Сайт – это представление сетевого расположения или группы сетевых расположений в виде объекта Active Directory, охватывающий один или несколько сегментов сети TCP /IP. Сайт является логической единицей матрицы контроллера домена на базе Windows Server. Проще говоря, сайт является логической совокупностью контроллеров домена и клиентов в пределах одного сегмента сети для управления служебным трафиком службы каталогов.
В зависимости от размера сети и ее сегментированности, структуры делятся на односайтовые и многосайтовые.
При настройке первого контроллера домена (процедура dcpromo) формируется сайт по умолчанию – Defaulf-First-Site-Name (просмотреть можно в меню Администрирование – Active Directory Sites and Services).
Рис.1
Также в данной оснастке (рис.1) можно увидеть объекты подсети (папка Subnets), который содержит IP адреса Вашей подсети.
И объекты связи сайтов (папка Inter-Site Transport), в нашем случае данный объект не рассматривается.
Небольшое отступление
Вся информация в Active Directory хранится в файле NTDS.DIT, при добавлении второго и последующих контроллеров домена, происходит копирование данного файла, т.е. каждый контроллер хранит свою копию файла NTDS.DIT
Важно знать и понимать, что при подключении к оснасткам Active Directory, будь то “Пользователи и Копьютеры или “Сайты и Сервисы”, вы всегда подключаетесь к конкретному контроллеру домена. Т.е. изменения вносятся только в один файл NTDS.DIT. При желании можно подключиться к другому контроллеру домена (правой кнопкой на самом верхнем пункте оснастки – сменить контроллер домена).
После внесения изменений необходимо оповестить другие контроллеры домена, т.е. провести синхронизацию или другими словами репликацию.
Репликация – процесс согласования данных между контроллерами домена.
Физически NTDS.DIT – это просто файл, но логически он состоит из нескольких разделов:
- Раздел «Schema» - хранит в себе схему AD, которая описывает какие объекты могут быть созданы и что они будут представлять.
- Раздел «Configuration» - содержит информацию о конфигурации AD (Домены, Сайты, сервисы и системные настройки).
- Раздел «Domain» - содержит информацию о пользователях, группах безопасности, организационных подразделениях, объектах компьютеров и принтеров.
- Разделы Application – опциональные разделы, зависит от настройки, но как правило содержит два раздела ForestDNSZones и DomainDNSZones.
Репликация этих разделов происходит по разному и выходит за рамки данной статьи, ознакомиться с данной темой можно в документации.
Итак, при добавлении второго и последующих контроллеров домена (если не создавать распределенную структуру сайтов) они попадают в сайт - Defaulf-First-Site-Name. После чего должны образоваться репликационные связи, указывающие откуда и куда должна происходить репликация.
Рис.2
Следует заметить, что не стоит добавлять связи вручную, это чревато возникновением ошибок и дальнейшей путаницей.
За создание связей отвечает служба KCC (Knowledge Consistency Checker), кому не дождаться может воспользоваться утилитой Repadmin –
repadmin /kcc server1.domain.local
Если нужно запустить генерацию связей на всех контроллерах домена в сайте, то команда Repadmin принимает вид:
repadmin /kccsite: "Default-First-Site-Name"
Как только число контроллеров достигнет восьми, правило «трех прыжков» приведет к тому, что служба KCC выполнит «ход конем» и добавит дополнительные прямые связи, сокращая расстояние между двумя любыми контроллерами до допустимого значения «максимум в три прыжка». Данная ситуация хорошо проиллюстрирована на рис.3 Создание связей между контроллерами, расположенными в разных сайтах, выполняется с учетом топологии сайтов, сайт-линков и мостов между сайт-линками. Подробнее о построении межсайтовой репликации читайте в следующей части статьи. Следует отметить, что кольцо при создании топологии репликации строится независимо для каждого контекста репликации (раздела Active Directory), далее эти кольца накладываются друг на друга, и выясняется, где можно вместо нескольких репликационных связей обойтись одной.
Рис.3
Обновление каталога внутри сайта в основном влияет на локальных клиентов, поэтому внутрисайтовая репликация оптимизирована по скорости. Репликация в пределах сайта происходит автоматически на основе уведомлений об изменении. Внутрисайтовая репликация начинается, когда на контроллере домена происходит обновление. По умолчанию исходный контроллер домена ожидает 15 секунд, а затем отправляет ближайшему партнеру репликации уведомление об обновлении. Если исходный контроллер домена имеет более одного партнера репликации, последующие уведомления отправляются каждому партнеру с 3-секундной задержкой. После получения уведомления об изменении контроллер домена, являющийся партнером репликации, отправляет исходному контроллеру домена запрос на обновление каталога. Исходный контроллер домена отвечает на этот запрос операцией репликации. Интервал уведомления в 3 секунды предотвращает чрезмерную загрузку исходного контроллера домена одновременными запросами обновлений от его партнеров по репликации.
К некоторым обновлениям каталога 15-секундная задержка не применяется, и репликация выполняется немедленно. Такая репликация, называемая срочной, применяется к критическим обновлениям каталога, включающим блокировку учетных записей и изменения в политике блокировки учетных записей, политике паролей домена или изменение пароля учетной записи на контроллере домена.
Как можно увидеть на рис.2 существует еще одно расписание (кнопка – изменить расписание). Это расписание является основным и обязательным, т.к. описанная выше схема обеспечивает синхронизацию до запуска этого, но не гарантирует успеха, например когда контроллер был занят и просто проигнорировал репликацию. В таком случае изменения будут прореплицированы в течение часа.
Рис.4
Следует обратить особое внимание, что процесс репликации всегда происходит в режиме pull, т.е. «стягивания» изменений и новых объектов, но не в режиме push. Это связано с тем, что только контроллер – хозяин файла NTDS.DIT – имеет право в нем что-то изменять, он отвечает за целостность своей БД. Из этого также следует, что все линки репликации, которые создаются вручную или службой KCC, имеют однонаправленную природу, т.е. логически обозначают входящий поток репликационной информации.
С теоретической частью вроде все, в следующей части статьи я рассмотрю возможные пути решения проблем.
Источники:
1. http://technet.microsoft.com
2. Системный администратор №1-2 2010г.
3. Дж. Шапироидр. Windows Server 2003 Библия пользователя
4. Уильям Р. Станек WindowsServer 2008 Справочник администратора
Интересное на сайте:
Голосов пока нет
Комментарии
С нетерпением жду
С нетерпением жду продолжения!!!
весьма неплохо. где нажать
весьма неплохо. где нажать плюс один? :-)
Можно на этой странице, а
Можно на этой странице, а можно и на главной ;)