Метод предотвращения бесконечных циклов репликации AD
В статье «Tracking AD Replication» (статья «Отслеживание репликаций AD» была опубликована в предыдущем номере журнала - прим. ред.) я рассказывал о том, как последовательные номера обновления (update sequence number, USN) используются для отслеживания изменений в копии Active Directory (AD), хранящейся на каждом контроллере домена (DC). Каждый сервер «помнит» последний USN, полученный от партнеров по репликации, и использует его для управления репликацией. Например, DC1 может запросить у DC2 информацию об изменениях, сделанных после того, как значение USN контроллера DC2 превысило 10 000.
Если администратор создает новую учетную запись пользователя на DC1, то значение USN контроллера DC1 увеличивается на 1; в результате DC2 запрашивает об изменениях в AD, связанных с этим событием. Когда DC2 записывает информацию об этом событии и увеличивает собственный USN, то изменение USN контроллера DC2 заставляет DC1 запросить информацию об изменениях в DC2, в том числе и о новой учетной записи пользователя, о которой DC1 уже знает. Запись этого обновления приведет к бесконечному циклу перезаписи одной и той же информации.
Чтобы прервать цикл перезаписи, AD запоминает не только локальный USN, который генерирует изменение, но и глобальный идентификатор (GUID) DC, инициировавшего изменение. Таким образом, AD отличает «первичное» изменение, которое вызывает контроллер домена, от изменения, просто передаваемого одним DC другому. Каждый DC помнит не только последний USN, полученный от партнера по репликации, но и USN, связанный с последним изменением, произведенным на каждом из остальных DC в домене. Таблица, в которой хранятся самые свежие «первичные» USN, называется вектором обновления (up-to-date vector).
Вектор обновления позволяет контроллерам домена избежать бесконечных циклов. Предположим, что последним сообщением о «первичном» изменении, полученным DC2 от DC1, было USN 9871, а последним изменением, которое генерировал DC2, было USN 1500. DC2 просит DC1 сообщить об изменениях, полученных DC1 после отправки последнего изменения в DC2, пропустив любые генерированные DC1 изменения с номерами, не превышающими USN 9871, и все изменения с номерами не более USN 1500, которые генерировал DC2. Предположим, что DC1 имеет одно новое изменение с номером USN 10 001. Когда DC1 посылает данное изменение в DC2, то DC2 сохраняет эту информацию под номером USN 1553 и запоминает, что первичное изменение имело номер USN 10 001 и вызвано контроллером DC1. DC2 меняет запись в векторе обновления для DC1 на 10 001 (DC1 также изменяет собственный вектор обновления, чтобы показать, что он равен 10 001).
Когда DC1 вновь запрашивает DC2 об изменениях, он узнает об изменениях DC2 благодаря USN 1552, и знаком со всеми изменениями, которые были сгенерированы DC1, вплоть до USN 10 001, и всеми изменениями, вызванными DC2, вплоть до USN 1500. DC2 обнаруживает, что располагает USN, превыщающим значение 1552, но «первичным» контроллером был DC1, а USN «первичного» контроллера равен 10 001. Поскольку вектор обновления DC1 содержит все «первичные» записи DC1 вплоть до USN 10 001, то DC1 «знает» о USN 1553 контроллера DC2 и не записывает новое изменение.
Вектор обновления DC можно увидеть с помощью команды Repadmin /showvector. Чтобы получить вектор для dc1.acme.com в домене с названием acme.com, необходимо ввести следующие команды:
repadmin /showvector dc=acme,dc=com dc1.acme.com
На Экране 1 показано примерное содержимое таблицы. Следует обратить внимание, что в последней строке показано не имя DC, а GUID: записи удаленного из домена DC по-прежнему хранятся в векторах обновления других DC, но они показаны под GUID бывшего DC, а не под его именем.
Site1DC1 @ USN 21595 Site1DC2 @ USN 162530 Site2DC3 @ USN 118741 c4c0767b-d99d-474c-bfcf-8e562d43d0e7 @ USN 73180
Экран 1. Просмотр таблицы с помощью команды Repadmin /showvector.
Марк Минаси - редактор Windows NT Magazine, MCSE и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com.