Сайты (v.1.6)

Автор Владислав Спектор

Сайт – территориально-географическое деление, создаваемое для управления трафиком репликации данных AD и DFS и для ускорения процесса пользовательских Logon.
Идея сайтов взята из Exchange Server, начиная с версии 4.0 , когда об Active Directory ещё и не думали. Оттуда же взята и идея механизма (engine) базы данных Active Directory. До появления Windows 2000, Exchange Server имел собственную, отдельную от домена (тогда ещё просто домена безо всякой Active Directory) базу данных пользователей почты. В Windows2000/Exchange2000 их DB слились в единую базу данных Active Directory с общим управлением пользователями (не только счета пользователей, но и почтовые ящики теперь создаются из ADUC).
Репликация, как известно, нужна для синхронизации информации Active Directory между разными DC (в предположении, что в домене будет больше, чем один DC). Идея множественности DC имеет множество плюсов и даже маленьким организациям не стоит иметь меньше двух DC.
Active Directory состоит из разделов (partitions) Домена, Схемы , Конфигурации и Приложений (Applications). Существует также Global Catalog, который разделом не считается, хотя информация о нём хранится в Active Directory аналогичным образом.
Синхронизация информации между DC осуществляется отдельно для каждого раздела, включая топологию (DC, которые в ней участвуют и пути репликации между ними). Active Directory использует модель репликации с несколькими хозяевами (Multi-master replication). Модель репликации Active Directory представляет собой модель с нежёстким согласованием, обладающую сходимостью. Нежёсткое согласование – это возможность временного несоответствия информации на разных DC, а сходимость – приход к соответствию, в случае отсутствия изменений в течении некоторого времени. Это очень напоминает поведение протоколов роутинга.
При репликации используется процесс хранения и ретрансляции (store and forward) или последовательная передача изменений каталога по цепочке DC. При данном способе исходный DC не должен самостоятельно копировать изменения на другие DC, а они передаются как эстафетная палочка. Существует правило: внутри сайта должно быть не более 3-х скачков (hops) для передачи изменений, а для этого (попробуйте нарисовать и проверить) в сайте должно существовать не более 7 DC. Если эти условия не соблюдаются, то потребуются дополнительные соединения между DC.
В прежней модели репликации с единственным хозяином (Single-master replication), которая существовала в Windows Server версий 3.1-4.0, единственный в домене DC, умевший производить изменения (он назывался PDC), должен был самостоятельно и без посредников распространять изменения на все DC в домене. Кроме минусов, здесь был и большой плюс с точки зрения структур баз данных: даже теоретически не должна была сложиться ситуация инконсистентности баз данных домена (имеется в виду несогласованность информации разных DC).
Среди определений сайта есть и такое – это собрание подсетей (скорее всего, в пределах локальной сети), связанных высокоскоростными соединениями. Там, где связь медленная, обычно и пролегает граница сайта.
Цель создания сайта – уменьшить нагрузку на низкоскоростные соединения. Нагрузка создаётся репликацией DC и трафиком Logon (особенно в утренние часы).
Репликация внутри сайта
Репликация происходит почти сразу после изменения информации AD. DC выжидает 15 секунд перед началом распределения изменений. После репликации с одним партнером DC ожидает 3 секунды, а затем начинает репликацию с другим партнером. Процесс репликации инициируется уведомлением DC-отправителя. DC-адресат забирает изменения при помощи RPC (процедуры удаленного вызова). Это тип pull replication или тянущей репликации.
Репликация между сайтами
Главная цель межсайтовой репликации та же, что и создания сайта – т.е., уменьшение трафика репликации. Репликация инициируется согласно расписанию, а не уведомлениями, как это происходит при репликации внутри сайта. Существует окно репликации и интервал. Окно м.б. установлено на нерабочие часы. Интервал действителен только на время окна.
Трафик репликации посылается через серверы плацдармы (Bridhead-servers). В каждом сайте существует один Bridhead-server, который, получив изменения, распределяет их в пределах своего сайта. Это сделано для того, чтобы по медленным связям между сайтами изменения посылались только один раз.
Иными словами Bridgehead-server – это сервер, специально предназначенный принимать трафик репликации с другого сайта и реплицировать его на DC's в локальном сайте. Хотя Bridgehead-servers создаются автоматически, их можно назначать вручную.
Bridgehead-servers общаются между собой при помощи Site-links. Их, в свою очередь, можно объединять Site-link bridges. Site-link bridges представляют собой коллекцию Site-links с целью роутинга между не соседними сайтами.
site bridges are a collection of links to allow routing between non-adjacent sites.
Время ожидания репликации (replication latency).
В пределах сайта время ожидания равно 15 сек * 3 хопа = 45 сек (мах.).
В репликации между сайтами вычисления зависят от множества факторов и потому сложнее.
Срочная репликация (Urgent replication) происходит при:
- изменении политики блокировки учетных записей.
- изменении политики паролей.
- перемещении хозяина RID на другой DC.
- изменении пароля DC.
Срочные обновления, как правило, применяются к репликации внутри сайта.
У этого правила есть исключение: когда пользователь меняет пароль на каком-либо DC, это изменение немедленно копируется прямо в PDC-эмулятор при помощи RPC-подключения и независимо от сайта, которому принадлежит исходный DC. Такая репликация пересекает границы сайта и не использует Bridhead Servers. Т.е. всё в этом случае происходит так, как будто сайтов вообще не существует. Затем PDC-эмулятор обновляет другие DC домена через нормальный процесс репликации. Это сделано для того, чтобы PDC-эмулятор мог служить арбитром конфликтных ситуаций с изменением пароля пользователя в домене. Конечно, такая ситуация может создаться только тогда, когда сайт меньше, чем домен (т.е., когда домен включает в себя несколько сайтов).
Топология репликации.
Топология репликации генерируется автоматически и обычно не требует вмешательства, хотя оно и возможно. На каждом DC выполняется KCC – процесс, ответственный за создание топологии репликации в пределах сайта и между сайтами. KCC начинает работать с момента добавления второго DC в лесу и срабатывает каждые 15 минут. Действия KCC напоминают автоматические вычисления таблиц маршрутизации в роутерах.
При помощи ADSS можно заставить контроллер пересчитать топологию репликации. Это выполняется следующим образом:
ADSS – Server – NTDS Settings – Right click – All Tasks (from menu) – Check Replication Topology.
KCC создаёт объекты связи (connection objects), которые хранятся в разделе конфигурации AD. Объект связи всегда создаётся как одностороннее тянущее (pull) соединение между двумя DC. Обычно создаётся два односторонних соединения, что напоминает создание отношений доверия.
Объекты связи можно менять, редактируя параметры настройки объектов, автоматически созданных KCC, или же добавляя новые объекты вручную. Служба KCC не трогает связи, созданные или изменённые вручную.
Для каждого DC создаётся избыточное кольцо репликации в противоположном направлении, и тогда каждый DC получает 2 входящие и 2 исходящие связи. Каждый DC в сайте может быть удалён от любого другого DC не более, чем на 3 скачка (прыжка, хопа, ретрансляции). Если в сайте существует более 7 DC, то невозможно соблюсти круговую связь с тремя скачками и тогда создаются дополнительные объекты связи.
Важный момент: KCC вычисляет отдельное кольцо топологии репликации для каждого раздела (Partition) каталога AD.
- Для разделов конфигурации и схемы – топология для всех DC в лесу
- Для раздела каталога домена – топология для всех DC в домене
- Для раздела приложений или Application Partition – топология для всех DNS, например
- Для Global Catalog – минимум один DC в каждом домене леса (хотя формально GC разделом и не считается).
Итого, мы насчитали 4 топологии. Для просмотра разделов репликации и топологии можно использовать Replication Monitor из набора Support Tools серверного CD:
X:\Support\Tools\Suptools.msi
После установки инструментов поддержки достаточно открыть Run – replmon.
Кольцо репликации реализуется с помощью объектов связи. KCC старается использовать одни и те же объекты связи для нескольких разных колец репликации различных разделов каталога. В каждом сайте один DC (он же KCC) является ответственным за разработку межсайтовой топологии. Такой DC/KCC обозначается как ISTG (Inter-Site Topology Generator) – генератор межсайтовой топологии. По сути, ISTG – это выделенный межсайтовый KCC, в задачи которого входит:
- - определить серверы-форпосты (Bridgehead Servers) отдельно для каждого раздела каталога в сайте
- - затем создать объекты связи между Bridgehead Servers.
Способы управления репликацией.
Для управления репликацией каталога в AD используются:
- порядковые номера обновлений USN (update sequence numbers)
- значения уровня (high-watermark values)
- векторы новизны (up-to-dateness vectors)
- отметки об изменениях (change stamps).
Способы разрешения конфликтов репликации.
В случаях, когда два или больше администратора одновременно производят изменения, касающиеся одних и тех же объектов, могут возникнуть конфликтные ситуации (хоть и не каждый день). Способы их разрешения следующие:
- Объект, добавленный к удаленному контейнеру, будет перемещен в контейнер LostAndFound.
- Добавление объектов с тем же RDN в тот же контейнер: объект с высшим GUID будет сохранен, а с низким GUID будет переименован.
Репликация удалений объектов.
При удалении аккаунта пользователя или компьютера, он не уничтожается немедленно, а создается объект памятник (tombstone object) с новым атрибутом isDeleted=true плюс старые атрибуты GUID, SID, RDN и USN. Остальные атрибуты удаляются. Tombstone objects хранятся 60 дней, а затем в процессе уборки мусора (garbage collection), которая производится каждые 12 часов, объекты уничтожаются. Если некий DC не реплицировался более 60 дней, он может содержать неактивные объекты (Lingering objects), которые на других серверах уже исчезли. Такие объекты иногда называют фантомами или зомби. Для предупреждения такого явления в Windows 2003, начиная с Service Pack 2, Tombstone objects хранятся 180 дней, т.е. в 3 раза больше прежнего. Время хранения Tombstone objects называется Default Tombstone Lifetime (TSL). Существует известный баг, когда после инсталляции Windows Server 2003 R2 значение TSL остается 60 дней. В таком случае нужно просто установить Service Pack 2 (SP2).