Active Directory Sites

by Vladislav Spector (v 2.5)

Сайт – территориально-географическое деление, создаваемое для управления трафиком репликации данных Active Directory и DFS и для ускорения процесса пользовательских Logon.
Зачем нужны сайты? Ну, например, если пользователь находится в Хабаровске, а Logon делает на DC сервер в Москве, причем соединенный медленным каналом связи, то это не самый быстрый Logon в мире! Напоминает старую шутку: На XXV съезде КПСС с трибуны говорят о том, что через 5 лет у каждого советского человека будет собственный самолет. Из зала раздается вопрос: “А зачем каждому советскому человеку свой самолет ”. “Ну, представьте себе, вы живете в Хабаровске, а масло дают в Москве”! То есть, уже понятно, что сайты – это физика, а не логика.

Идея сайтов взята из реализации почтового сервера Exchange Server, начиная с версии 4.0, когда об Active Directory ещё и не думали. Оттуда же взята и идея механизма (engine) базы данных Active Directory. До появления Windows 2000, Exchange Server имел собственную, отдельную от домена (тогда ещё просто домена безо всякой Active Directory) базу данных пользователей почты. Аккаунты пользователей Exchange создавались из Exchange, а пользователей Домена – из средств управления Доменом.
В Windows2000/Exchange2000 их DB слились в единую базу данных Active Directory с общим управлением пользователями. Теперь не только счета пользователей, но и почтовые ящики стало возможным создавать из ADUC, но при этом исчезла возможность создавать почтовые ящики из Exchange. Если раньше один пользователь Домена мог иметь несколько почтовых ящиков, то теперь только один ящик, т.е., соотношение стало: один аккаунт - один почтовый ящик.
Интересно, что в будущем произойдет еще одно изменение в подходе к созданию почтовых ящиков. В Exchange2010 снова исчезнет возможность создавать ящики из ADUC в пользу сервера Exchange, но на этот раз появится возможность создавать из Exchange и ящик и пользователя. Понятно, что из Exchange нельзя создать пользователя без ящика, ведь на то он сервер почты.

Зачем еще, кроме быстрого пользовательского Logon, нужны сайты? Проблемы скорости и надежности возникают при репликации между сайтами, необходимость в которой появилась впервые в Windows 2000 Server, одновременно с сайтами (ранее сайты существовали тольжко на уровне Exchange).
Репликация, как известно, нужна для синхронизации информации Active Directory между разными DCs (в предположении, что в домене будет больше, чем один DC). Физически, Active Directory находится на каждом из DCs в файле %SystemRoot%\ntds\NTDS.DIT. Но реплицируются не сами файлы, а логическая информация, которая в них находится. Бинарно эти файлы могут отличаться. Мало того, в течении коротких отрезков времени информация в файлах тоже может немного отличаться. Для устранения различий и существует механизм репликации, но он не действует моментально.

Ну, а сайты делят нашу сеть таким образом, чтобы серверы и пользователи, близкие территориально, “общались” прежде всего между собой. Это ускоряет и репликацию между близкими DC, и вход пользователей в сеть. Т.е. пользователи совершают Logon на серверы в своем сайте, а репликация происходит между DCs, расположенными в своем же сайте часто.

Итак, зачем нужны сайты и репликация между ними, нам уже понятно, не так ли?
Теперь осталось поговорить о том, как реально осуществляется репликация.
Возьмите в расчет, что, несмотря на понятность цели, технически это не самый простой процесс. Существует несколько понятий, которыми нужно овладеть для полного понимания процесса репликации. Это:
Active Directory Partitions (Разделы),
Replication Topology (Топология Репликации),
Replication Мodels (Single-master/Multi-master) и т.д.

Active Directory состоит из Разделов или Partitions имеющих названия: Схемы, Конфигурации, Домена и Приложений (Applications). Существует также Global Catalog, который разделом не считается, но информация о нём хранится в Active Directory аналогичным образом.

Синхронизация информации между DC осуществляется отдельно для каждого раздела, включая топологию. Топология – это DCs, участвующие в репликации и пути репликации между ними. Active Directory использует модель репликации с несколькими хозяевами (Multi-master replication). Иными словами, изменения возможно производить на любом DC, а затем они распространяются на все другие DCs в домене или даже в лесу.

Сейчас дадим определение модели репликации, существующей в Windows 2000/2003/2008 (только не пугайтесь его кажущейся сложности).
Итак, модель репликации Active Directory представляет собой модель с нежёстким согласованием, обладающую сходимостью. Нежёсткое согласование – это возможность временного несоответствия информации на разных DC (ведь на распространение изменений нужно какое-то время), а сходимость – итоговый приход к соответствию (конечно, в случае отсутствия изменений в течение некоторого времени).
Это, кстати, очень напоминает поведение протоколов роутинга в процессе распространения информации о маршрутах.

При репликации используется процесс хранения и ретрансляции (store and forward) или последовательная передача изменений каталога по цепочке DC. При данном способе исходный DC не должен самостоятельно копировать изменения на все другие DC - изменения передаются как эстафетная палочка от DC к DC. Существует правило: внутри сайта должно быть не более 3-х скачков (hops) между DCs для передачи изменений, а для этого в сайте должно существовать не более 7 DC. Это не какое-то условное ограничение фирмы Microsoft, а простая геометрия - закон природы. Попробуйте нарисовать это проверить! Если вышеизложенные ограничения не соблюдаются, потребуются дополнительные соединения между DC (наподобие модели mesh в сетевой топологии).

В прежней модели репликации с единственным хозяином (Single-master replication), которая существовала в Windows Server вплоть до версии 2000 (не включая), единственный в домене DC, умевший производить изменения, должен был самостоятельно и без посредников распространять изменения на все DC в домене. Такой сервер назывался PDC (Primary Domain Controller), а все другие серверы назывались BDCs. Кроме минусов, здесь был и большой плюс с точки зрения структур баз данных - даже теоретически не могла сложиться ситуация несогласованности базы данных домена (имеется в виду несогласованность или инконсистентность информации разных DCs как результат задержек или неточностей репликации).

Среди определений сайта есть и такое: Сайт – это собрание подсетей (очевидно, в пределах локальной сети), связанных высокоскоростными соединениями. Там, где связь медленная, обычно и пролегает граница сайта.
Цель создания сайта – уменьшить нагрузку на низкоскоростные соединения и повысить скорость процессов репликации между DCs и трафиком Logon (особенно в утренние часы), которые эту нагрузку и создают. В идеальном мире, где связь между компьютерами всегда быстрая и стабильная, сайты нам бы не понадобились.

Репликация внутри сайта
Репликация происходит почти сразу же после изменения информации AD. DC выжидает 15 секунд перед началом распределения изменений. После репликации с первым партнером DC ожидает еще 3 секунды, а затем начинает репликацию с другим партнером. Процесс репликации инициируется уведомлением DC-отправителя. DC-адресат забирает изменения при помощи RPC (процедуры удаленного вызова). Это тип Pull Replication или тянущей репликации.

Репликация между сайтами – межсайтовая репликация
Главная цель межсайтовой репликации та же, что и существования сайта – т.е., уменьшение трафика репликации. Репликация инициируется согласно расписанию, а не уведомлениям, что происходит при репликации внутри сайта. Существует окно репликации и интервал. Окно (время, суток, в течение которого возможно осуществление реплиокации) скорее всего будет установлено на нерабочие часы. Интервал (частота репликаций) действителен только на время окна. Запомните понятия окна и интервала и поймите в чем их различие, т.к. это важно для экзамена, а также может пригодиться для работы.

Трафик репликации посылается на другие сайты не всем DCs подряд, а через Bridhead-servers (серверы-плацдармы). В каждом сайте существует хотя бы один Bridhead-server, который, получив изменения, распределяет их в пределах своей области действия - своего сайта. Это сделано для того, чтобы по медленным связям между сайтами изменения посылались только один раз.
Иными словами, Bridgehead-server – это сервер-посредник, связывающий сайты с точки зрения репликации. Он специально предназначен принимать трафик репликации с другого сайта и реплицировать его на DC's в локальном сайте и наоборот. Хотя Bridgehead-servers создаются процессом ISTG (Inter-Site Topology Generator) автоматически, их можно назначать и вручную.

Bridgehead-servers общаются между собой при помощи Site-links. Последние, в свою очередь, можно объединять при помощи Site-links bridges. Site-links bridges представляют собой коллекцию Site-links с целью роутинга между несмежными сайтами.

Время ожидания репликации (replication latency).
В пределах сайта время ожидания равно 15 сек * 3 хопа = 45 сек (мах.).
В репликации между сайтами вычисления зависят от множества факторов и поэтому трудно дать четкую формулу на все возможные случаи.

Срочная репликация (Urgent replication)
Существует также так называемая срочная или неотложная репликация (Urgent replication). Она происходит при:
- изменении политики паролей.
- изменении политики блокировки учетных записей.
- изменении пароля DC.
- перемещении хозяина RID на другой DC.

Срочные обновления, как правило, применяются к репликации внутри сайта.
У этого правила есть исключение: когда пользователь меняет пароль на каком-либо DC, это изменение немедленно копируется прямо в PDC-эмулятор при помощи RPC-подключения и независимо от сайта, которому принадлежит исходный DC. Такая репликация пересекает границы сайта и даже не использует Bridhead Servers. Т.е., всё в этом случае происходит так, как будто сайтов не существует вообще или же все сайты являются одним большим сайтом.

Затем PDC-эмулятор обновляет другие DC домена при помощи нормального процесса репликации. Это сделано для того, чтобы PDC-эмулятор мог служить арбитром конфликтных ситуаций с изменением пароля пользователя в домене. Конечно, такая ситуация может создаться только тогда, когда диаметр сайта меньше, чем домена (т.е., когда домен включает в себя несколько сайтов).

Топология репликации и KCC .
Топология репликации генерируется автоматически и обычно не требует вмешательства, хотя оно возможно. На каждом DC выполняется KCC (Knowledge Consistency Checker) – процесс, ответственный за создание топологии репликации в пределах сайта и между сайтами. KCC начинает работать с момента добавления второго DC в лесу и срабатывает каждые 15 минут.

Действия KCC напоминают автоматические вычисления таблиц маршрутизации в роутерах.
При помощи ADSS можно заставить контроллер пересчитать топологию репликации.
Технически это выполняется следующим образом:
ADSS – Server – NTDS Settings – Right click – All Tasks (from menu) – Check Replication Topology.

KCC создаёт объекты связи (connection objects), которые хранятся в Разделе Конфигурации AD. Объект связи всегда создаётся как одностороннее тянущее (pull) соединение между двумя DC. Обычно создаётся два односторонних соединения, что напоминает создание отношений доверия между доменами или лесами Active Directory.

Объекты связи (connection objects) можно менять, редактируя параметры настройки объектов, автоматически созданных 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 сервера 2003:
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 будет переименован.
DN (Distinguished Name) - every object in AD has a DN. DN follows X.500 naming conventions. The DN is made up of the nodes from the root domain down through the container hierarchy to the object. Using my FQDN name and putting it into ND form:
DC=com, DC=Specter, OU=Expert, CN=Users CN=Pupkin
RDN (Relative Distinguished Name) - must be unique in an OU but do not have to be unique in a domain.
GUID (Globally Unique Identifier) is an 128-bit number guaranteed to be unique within a forest. The GUID never changes even though the DN or RDN may. The GUID is W2K's extension of the SID to the AD environment.

Репликация удалений объектов.
При удалении аккаунта пользователя или компьютера, он не уничтожается немедленно, а помечается для удаления. Почему объект просто не уничтожается? Дело в том, что если его удалить на некоем определенном сервере, то при следующей репликации он будет восстановлен с других серверов, т.к. сервер “забудет” об объекте и будет “думать”, что правильная информация существует на других серверах. Это проблема Multimaster-replication, когда нет единого арбитра и все верят всем.

Чтобы избежать такой ситуации, вместо удаления объект помечается как удаленный при помощи маркера “tombstone”, что значит памятник. Такой объект-памятник (tombstone object) имеет новый атрибут isDeleted=true. Вдобавок он сохраняет некоторые основные атрибуты - GUID, SID, RDN и USN. Остальные атрибуты объекта удаляются.

Объекты, помеченные как «tombstone», перемещаются в контейнер Deleted Objects, где хранятся 60 дней (в Windows 2000 и 2003, включая SP1), а затем в процессе «сборки мусора» (garbage collection), которая производится каждые 12 часов, объекты окончательно уничтожаются.

Если некий DC не реплицировался более 60 дней в результате отсутствия в сети, он может содержать неактивные объекты (Lingering objects), которые на других серверах уже исчезли. Такие объекты иногда называют фантомами или зомби. Для предупреждения такого явления, начиная с Windows 2003 Service Pack 2 (и вплоть до Windows 2008 R2 на момент написания этой статьи), время хранения Tombstone objects увеличено до 180 дней, т.е. в 3 раза больше прежнего.

Время хранения Tombstone objects называется Default Tombstone Lifetime (TSL). Существует известный баг, когда после инсталляции Windows Server 2003 R2 значение TSL остается 60 дней. В таком случае нужно просто установить Service Pack 2 (SP2).

Существует разница между восстановлением объекта, который был полностью удален и больше не существует в базе Active Directory и объектом «tombstone». Восстановление объектов «tombstone» называют реанимированием. В Windows Server 2003 SP1 появилась функция Directory Service Backup Reminders, которая в случае наличия “tombstone objects” и отсутствия Active Directory Backup генерирует сообщения “Event ID 2089” просматриваемые в Event Viewer.

В Windows Server 2008 R2 появилась новая функция "Active Directory Recycle Bin" (корзина для AD) для восстановления удаленных объектов AD. После включения ADRB все атрибуты удаленных объектов начинают сохраняться, что позволяет после восстановления получить объект в том же состоянии, в каком он был непосредственно перед удалением. Например, при восстановлении пользователя он автоматически получает членство в группах, в которых он был и соответствующие полномочия, которыми обладал в момент удаления в домене. Прежде чем включить эту функцию (by default она выключена), вам необходимо будет поднять функциональный уровень леса до уровня Windows Server 2008 R2, что в свою очередь требует иметь Windows Server 2008 R2 на всех контроллерах домена в лесу.

Более подробно почитать о новой возможности и о том, как ее задействовать практически вы можете на странице: http://itew.ru/2009/07/17/685
Или перепечатку статьи на моем блоге:
http://spector-training.blogspot.com/2010/09/active-directory-recycle-bin-ad.html
Или другая статья на ту же тему из хорошего блога Blog of Khlebalin Dmitriy:
Восстановление удаленных объектов AD в Windows 2008.