О некоторых нюансах настройки межсайтовой репликации AD или «Не все статьи от Microsoft одинаково полезны»

Одним прекрасным весенним утром, когда свежая почта уже была прочитана, а чашка с чаем еще не закончилась, я наткнулся на статью в блоге «Ask the Directory Services Team» под названием Configuring Change Notification on a MANUALLY created Replication partner. В ней сотрудник Microsoft Джонатан Стивенс описывает способ научить ваши контроллеры домена побыстрее реплицировать изменения в AD между сайтами (в определенных условиях).
«Клево! — подумал я тогда — надо попробовать.»

В сертификационных курсах по AD и в многочисленных статьях нам сообщают, что существует два вида репликации: внутрисайтовая (intrasite) и межсайтовая (intersite).

N.B. Надеюсь все понимают что мы говорим о репликации каталога AD, которая не имеет никакого отношения к репликации папки Sysvol. И еще, если вы никогда не слышали об USN, KCC, Up-to-dateness Vector и прочих гадостях терминах, то дальше можете не читать, будет непонятно.

Внутрисайтовая репликация происходит «почти мгновенно» (на самом деле 5 секунд), межсайтовая — «по расписанию», которое обычно задается в свойствах SiteLink. Недостаток расписания в том, что минимальный период межсайтовой репликации составляет 15 минут (четыре раза в час) и не может быть уменьшен стандартными средствами.

«А нестандартными может?» — сразу спросите вы. «Может» — отвечает нам Microsoft в статье Advanced Replication Management, опубликованной на technet.microsoft.com. Оказывается, что изменение определенного бита в атрибуте Options соответствующего SiteLink позволяет включить режим уведомления о появившихся изменениях (Notification) при межсайтовой репликации AD. А режим уведомления и определяет разницу между двумя видами репликации. Замечательно, у нас будет «мгновенная» репликация для всех контроллеров!

А вот и нифига! К сожалению, в описанном на Technet способе есть одно существенное ограничение: уведомления об изменениях начинают работать только если AD DS connection был создан автоматически, посредством KCC. Такие AD DS connections имеют имя <automatically generated>, это если вы вдруг не знали :). Если же в вашей организации KCC по какой-то причине не доверяют и создают соединения вручную, то увы и ах, в той статье нам предлагали довольствоваться 15-минутным интервалом репликации.

Теперь вернемся к статье Джонатана Стивенса. В ней он описывает причину такого ограничения и способ его обойти. Дублировать информацию здесь не буду, если интересно, то ссылку на статью я привел в самом начале.

Итак, у нас есть инструкция, шаловливые ручки энтузиазм и немного свободного времени. Давайте пробовать!

Собираем полигон из двух виртуальных контроллеров домена под управлением Windows Server 2012 Datacenter Edition.
Уровень леса и домена Windows Server 2012. Оба контроллера являются серверами DNS и серверами глобального каталога, находятся в одном сетевом сегменте.

Разносим контроллеры по разным сайтам:



После этого вручную создаем дублирующие AD DS Connections, подталкиваем репликацию и затем удаляем автоматически сгенерированные соединения.



Note! Настоятельно рекомендую заменять соединения в указанном порядке, чтобы в любой момент времени между контроллерами существовала как минимум одна пара AD DS Connections, иначе может порушиться репликация, во всяком случае на некоторое время. Для надежности после каждого изменения вручную подталкивайте репликацию.

На контроллере ReplTest-DC2 в окне PowerShell запускаем скрипт:

while ($true)
{repadmin /showutdvec ReplTest-DC2 "DC=Repltest,DC=local" | ?{$_ -match "ReplTest-DC1"};sleep 1}


Он позволит нам в реальном времени (раз в секунду) отслеживать изменение Up-To-Dateness vector контроллера ReplTest-DC2, выделяя из него строку, относящуюся к партнеру репликации с именем ReplTest-DC1.



Обратите внимание, в выделенной строке USN изменился с 12575 на 12605. Это произошло после того, как на ReplTest-DC1 был создан тестовый юзер и репликация была инициирована вручную.

Итак, мы убедились что репликация работает. Переходим непосредственно к проверке статьи Джонатана.

Устанавливаем четвертый бит атрибута Options в единицу для вручную созданного AD DS Connection (для верности я сделал это для обоих соединений: от ReplTest-DC1 и от ReplTest-DC2).



Не забываем подтолкнуть репликацию.

После этого редактируем произвольный атрибут произвольного объекта на ReplTest-DC1. Я, например, поменял поле Description у недавно созданного юзера.

Смотрим на состояние репликации на ReplTest-DC2:


Ноль реакции! USN не меняется!
Ждем пять секунд… ничего не меняется, ждем пять минут… опять не меняется!
Пытаемся проделать зеркальную операцию: вносим изменения в AD на ReplTest-DC2 и отлеживаем изменения на ReplTest-DC1. Тот же результат.

Несколько часов разнообразных тестов не изменили картины.

Признаюсь, я ожидал этого, потому что еще тогда, прекрасным весенним утром, я уже проделал те же самые действия для 2008 контроллеров.

Это печалит, но в данным момент я вынужден констатировать:

«Приведенный в статье Джонатана Стивенса метод включения уведомлений для созданных вручную AD DS Connections не работает»

Возможно, в статье опущен какой-то шаг или существуют дополнительные требования, но результат обескураживает. Я привык верить статьям команды AD DS.

Если у уважаемых коллег есть замечания к проведенному тесту или их результаты отличаются от моих, то прошу указать в комментариях кто редиска ошибся ли я и если да, то в каком месте.

Надеюсь что сообща мы докопаемся до истины.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 10

    0
    А что в сырцах по этому поводу? Я обычно когда вижу поведение приложения, отличающегося от ожидаемого, лезу в сырцы и там обычно быстро становится понятно, что происходит и кто не прав.
      0
      «Доступ к исходным кодам продуктов Microsoft предоставляется, в соответствии с Законодательством Российской Федерации, только лицам имеющим соответствующий допуск и работающим в государственных проектах по совершенствованию защищенных информационных систем.

      Более подробно об этом можно прочесть здесь: www.microsoft.com/rus/government/certificate/»

      Еще, говорят, доступ к исходникам могут получить MVP, но мне до этого статуса как до Луны :)
        +1
        Именно по этой причине я в своё время и решил расстаться с майкрософтсковскими продуктами. Как только выходишь за пределы мануалов, руководств и howto, то оказываешься в мире сплетен, слухов и абсолютного бессилия понять, что там происходит «под капотом».

        В сравнении с этим самое унылое расковыривание «ну почему у нас в этой ситуации начинают теряться пакеты» в ситуации с opensource'ом всего лишь означает несколько дней медитации над исходниками и пачки printk'ов вокруг спорного места.
          +1
          Мы очень рады за Вас. Продолжайте заходить в каждую статью где увидите слово Microsoft и писать откровения. Скоро просветлятся все.

          по топику.
          в статье линк на которую Вы даете написано:
          To enable change notification between sites
          In ADSI Edit, expand the Configuration container.
          Navigate to the Inter-Site Transports container, and select CN=IP. (You cannot enable change notification for SMTP links.)
          Right-click the site link object for the sites for which you want to enable change notification, and then click Properties.
          In the Select a property to view box, select options.
          In the Edit Attribute box, if the Value(s) box shows, type 1 in the Edit Attribute box. If the Value(s) box contains a value, you must derive the new value by using a Boolean BITWISE-OR calculation on the old value, as follows: old_value BITWISE-OR 1. For example, if the value in the Value(s) box is 2, calculate 0010 OR 0001 to equal 0011. Type the integer value of the result in the Edit Attribute box; for this example, the value is 3.
          Click OK.

          либо я чего-то не понимаю, либо информация слегка противоречит сама себе.
            0
            В технетовской статье изменяется атрибут Options для Site Link (первый бит устанавливается в 1, то есть для включения Notification значение Option должно стать нечетным). Это работает для всех AD DS Connection, дочерних для этого SiteLink, автоматически созданных при построении топологии службой KCC. Это действительно работает, я проверял. В принципе это давно известная и проверенная инфа.

            Если же вы не используете automatically generated connections, то, согласно статье Джонатана, должны менять атрибут Options уже не для Site Link, а для каждого созданного вручную Connection в отдельности. Причем уже не первый бит, а четвертый. И вот это не работает.
              0
              Наверное вы правы и оно не работает, с другой стороны описывать логическую топологию именно сайтлинками как-то правильнее чем прямыми связями между контроллерами, пусть даже он у вас один в сайте будет. В нашем случае 12 сайтов, под 30 DC, включен USE_NOTIFY только на сайтлинках (DEFAULTIPSITELINK при этом удален вообще), всё остальное KCC само построило. Причем не все сайты друг друга видят напрямую но за счет site link bridging все вполне хорошо.
                0
                Вы зря так полагаетесь на KCC.

                Ваш сценарий (Bridge All Site Links и отсутствие connectivity между некоторыми сайтами) часто приводит к неработающим Connections. Вполне возможна ситуация, когда Bridgehead Server одного из сайтов уже полгода безуспешно пытается вытянуть реплику из контроллера другого сайта (KCC искренне предполагает, что каждый контроллер должен видеть все остальные). Если это вовремя не отследить, а потом спохватиться и вручную восстановить репликацию, то вы можете даже подхватить USN Rollup и много-много гемора.

                Я не утверждаю, что у вас что-то неправильно работает, но все равно бы порекомендовал вам воспользоваться утилитой AD Replication Status Tool для проверки работоспособности вашей текущей топологии репликации.
                  0
                  Собственно раньше у нас и были «ручные» соединения, текущая конфигурация получилась после консультации со специалистом Microsoft при проведении AD RAP (Risk and Assesment Program). Если не выставлять preferred bridgehead (это важно), то автоматический failover будет происходить на другой и 2 площадки друг без друга не останутся (если конечно физический линк есть хотя бы между двумя контроллерами). KCC как раз не обязательно предполагает что «все видят всех», он в процессе построения топологии учитывает кто кому доступен. Например может быть достижимость сайтов A<->B и A<->C, при этом B<->C будут реплицироваться через сайт-бриджинг и KCC нормально «знает» такую ситуацию. Вообщем его основная рекомендация по best practices была — назначайте правильные сайт-линки в соответствии с физическими линками и больше ничего вручную не настраивайте (ручные connections или preffered bridgehead действительно ситуацию только ухудшают).
                  Полгода где-то уже с такой конфигурацией полёт нормальный. Тулзу нам после AD RAP на год оставили внутреннюю от MS, она там намного больше показывает чем предложенная вами, все хорошо.
      +1
      Да, некоторые статьи как рисование совы.
        0

        Only users with full accounts can post comments. Log in, please.