Внутрисайтовая и межсайтовая репликация.

Итак, продолжим тему репликации, которая обсуждалась в темах «Репликация» и «Какая информация подвержена репликации и механизмы репликации».

В ActiveDirectoryWindowsServer 2003 предусмотрены два механизма репликации данных а именно:

• Внутрисайтовая (intrasite) – действует внутри сайта;
• Межсайтовая (intersite) – действует между сайтами.

Напомню, сайт – это набор подсетей IP, связанных между собой высокоскоростными линиями (смотрите здесь).

Внутрисайтовая репликация.

Так же мы знаем из предыдущих тем, что такое встроенная в ActiveDirectory служба  КСС (Knowledge Consistence Checker) или служба проверки однородности (непротиворечивости) знаний.  А так же знаем, что КСС отвечает за топологию связи в сайте и между сайтами, то есть за пути прохождения наших данных репликации или реплик.

В масштабе сайта КСС всегда генерирует кольцевую топологию.

Рассмотрим  примеры и пойдем, следуя принципу нашей рассылки от простого к сложному.  Допустим у нас один сайт и один контроллер домена. В этом случае репликации нет, так как нет между кем реплицироватся по причине одного и единственного контроллера домена.

Усложним пример. Добавим в нашем домене второй контроллер домина. Естественно в этом случае будет необходимость в репликации.  В нашем случае пусть будут первый контроллер домена DC1 и второй DC2. Установятся две связи между DC1  и DС2 и наоборот.

Усложним еще. Добавим в наш домен построенный на одном сайте  еще один контроллер итак у нас будут следующие контролеры в домене DC1, DC2, и DC3. В этом случае КСС автоматически сгенерирует кольцевую топологию. Каждый из контроллеров связан с двумя другими четырьмя связями — по две связи на соединение смотрите рисунок 1.

Рисунок 1.

Допустим, наша фирма расширяется и нам необходим  четвертый контролер домена.  Естественно КСС начинает генерировать кольцевую схему. И исходя из выше показанной логики получаем,  как можно заметить из рисунка 2,  колец больше чем одно,  учитывая что DC1 может связаться с DC3 напрямую.

Рисунок 2.Если контроллеров домена всего три, то каждый связан с двумя другими. При добавлении четвертого контроллера он устанавливает связи с двумя контроллерами, непосредственные связи между которыми становятся лишними.

 В этом случае возникает так называемая  избыточность связей для контроллеров  DC1 и DC3. Они, конечно, могут продолжать репликацию напрямую, но есть и еще два пути: через контроллеры DC2  и DC4.

Но поскольку КСС стремится создать кольцо, то избыточные связи между DC2 и DC3 будут удалены.

Примечание.  В ряде случаев КСС не удаляет избыточные связи. Их можно удалить вручную.

Как же КСС знает, какой из контроллеров является ближайшем соседом? И действительно задача сложная, так как КСС оценивает все контроллеры домена одинаково, а также из логики построения сайтов – пропускная способность  внутри сайта так же одинакова.   Так вот,  КСС для оценки контроллеров домена внутри сайта использует номера GUID контроллеров.

Примечание.  GUID(GloballyUniqueIdentifier) (глобальный  уникальный идентификатор) - контроллера.  Этостатистически уникальный 128-битный идентификатор.  GUID идентификаторы если говорить вообще, имеют не только контроллеры домена. Microsoft применяет GUID в OLE, COM и DCOM и т.д.

КСС  определив число доступных в момент проверки контроллеров определенного домена, он строит (ранжирует)  их по возрастанию номера GUID. Логика в этом есть если подумать, ведь мы устанавливаем контролеры в домене по очереди, то есть сперва первый контроллер домена  который получает свои GUID, потом второй, который получает свои GUID который больше первого и так далее.   КСС, исполняемый на каждом контроллере домена, выбирает два контроллера с ближайшими номерами и создает для них односторонние связи.

Теперь усложним пример внутри сайта вообще.  Допустим,  мы все вносим и вносим в наш домен, построенный на одном сайте все новые контроллеры домена, так как наша фирма растет и растет, и есть необходимость в вводе новых контроллеров домена. Но в таком случае как можно заметить кольцо репликации расширяется в диаметре.  Но каких пределах (размерах)  возможен рост в диаметре,  и есть ли какие-то другие параметры, влияющие на рост диаметра кольца репликации.  Ответ есть!

В внутрисайтовой  репликации между любыми контроллерами одного домена  должны быть не больше трех шагов репликации или как еще их называют трех «хопов»  или прыжков   (от английского - hops) репликации.

То есть исходя из правила написанного выше (три хопа), топология в виде кольца  удовлетворяет критерию, если число контроллеров в домене не больше 7.  При добавление восьмого контроллера в наш домен ситуация усложняется.   В этой ситуации КСС в кольцевой структуре создает дополнительные соединения, исходя из логики - что если на одном из контроллере в домене с числом контроллеров больше семи произойдет сбой, то между оставшимися контролерами должно быть не более трех шагов репликации.  Давайте, что бы было понятнее,  проанализируем такую ситуацию.  Смотрим рисунок 3.

Рисунок 3. Основное правило при генерации топологии репликации  не более 3 «прыжков» между любым из контроллеров домена.

Предположим, что первый запустился КСС находящимся на контроллере DC1. Проанализировал всю сеть,  выяснив число контроллеров в сайте,  он принял решение, что для репликации данных с него, то есть с DC1 на самый дальний от него контроллер DC5 необходимо четыре прыжка, что не подходит ему исходя из правила 3-х «хопов». Но так как КСС обучен строить соединения по кольцевой схеме то он создает  соединения с ближайшими  соседями,  и  прямое соединение  с  DC5 тем самым создавая кольцо. DC5 в свою очередь создает так же три соединения:  два соединения (по обе стороны от него) с ближайшими соседями, и одно с DC1.

Далее предположим запустится КСС находящийся на DC3. Анализируя число контроллеров в домене, он увидит что самый удаленный от него контроллер будет DC7. DC3 создает соединения с ближайшими соседями,  а так же принимает решение создать прямое соединение с DC7.  В ответ на созданное соединение с DC3 на DC7, DC7 создает встречное соединение на DC3, а так же пары соединений с ближайшими соседями.  Проснувшиеся остальные КСС домена после анализа домена уже будут знать о существующих соединениях и примут решение что им не требуются дополнительных соединений кроме пары соединений с ближайшими соседями. На этом формирование топологии репликации окончится.

На самом деле совершенно не обязательно, что будет сформирована именно такая топология, мы здесь просто привели ее для примера и предположили для наглядности, что сперва запустится КСС на  DC1, потом КСС на DC5, потом КСС на DC3, а в свою очередь КСС на DC7, потом по очереди DC2, DC4, DC6, DC8. Ели допустим после КСС на  DC1, запустится КСС на DC 4 и так далее то топология будет совершенно другая, но главное что при все при этом критерии репликации все равно будут строго соблюдены.

Основное правило, которым пользуется КСС  при генерации топологии репликации  не более 3 «прыжков» между любым из контроллеров домена.

Межсайтовая репликация.

Исходя изтого что все домены нельзя иногда расположит в одном сайте (что весьма желательно) по причине плохой и медленной связи, сайт приходится разделить на дав сайта и обеспечить связь между сайтами.

Для того что бы обеспечить возможность репликации между несколькими сайтами к примеру расположенными графически в разных местах, допустим в Антарктике, Европе и Москве, нам необходимо связать эти сайты вручную. Наличие межсайтовых связей, представляющих из себя IP соединения, являются необходимыми условиями для репликации. Минимальным условием для генерации всех межсайтовых соединений есть то что на каждом сайте должна функционировать хоть одна служба КСС.

При конфигурированние межсайтовых связей от сетевого администратора требуется указать транспорт репликации, стоимость межсайтовой связи (это не деньги, но конкретно конфигурацию мы рассмотрим позже), периоды связи (интервал времени на протяжении которого связь находится в состоянии готовности)  и регулярность ее применения. Исходя из этой информации КСС выбирает топологию межсайтовой связи для репликации.

Нужно подчеркнуть что в случае межсайтовой репликации следует четко различать межсайтовые связи (site links) и объекты соединений (connection objects) рассмотренных в предыдущей теме. Межсайтовые связи нужны КСС для установления путей репликации между двумя сайтами. Их необходимо создавать вручную. Объекты соединений (connection objects)с помощю которых фактически устанавливается соединения между контроллерами домена создаются КСС в автоматическом режиме (но можно создать и самим).

По умолчанию все межсайтовые связи характеризуются транзитивностью. Что понимать под таким понятием как транзитивность? А понимать это надо так (смотрите рисунок 4). Если сайт А связан с сайтом В с одной стороны, а сайт В имеет связь с сайтом С с другой стороны, то сайты А и С связываются автоматически. Транзитивность можно запретить сняв флажок Bridge All Site Links (Установит мост для всех связей сайтов) в диалоговом окне "Свойства" протокола применяемого для межсайтовой репликации (IP или SMTP) но об этом поговорим когда будем делать непосредственно конфигурированние  сайтов и репликации.

Серверы плацдармы (bridgehead server) . 

Когда КСС занимается настройкой сайтов и межсайтовых связей она автоматически выбирает в каждом сайте один контроллер и назначает его сервером плацдармом (bridgehead server). Что следует понимать под термином "сервер плацдарм"? Сервер плацдарм - это контроллер домена, через который в каждом сайте происходит межсайтовая репликация. Объекты соединений  (connection objects) между серверами плацдармами так же создаются автоматически службой КСС. Получив с внешнего сайта в процессе репликации данные, сервер плацдарм тиражирует их среди всех контроллеров доменов своего сайта. Служба КСС автоматически после проведения анализа сайта и получения нужных данных от сетевого администратора описанных выше, автоматически назначает сервер плацдарм. Кроме того при наличие компьютера с достаточной для отправки и принятия даных пропускной способностью сетевой админ может назначить основной сервер плацдарм (prefferred bridgehead server). В этом случае он применяется вместо сервера назначенный службой КСС. И еще в каждом сайте можно назначит несколько основных серверов плацдармов, но в активном состоянии будет только один из них, остальные про запас в случае чего.

Механизмы межсайтовой репликации выглядит следующем образом. Смотрите рисунок 4.

Рисунок 4.

Допустим у нас фирма "рога и копыта" имеет филиалы в Европе и в Антарктике. Естественно учитывая такие расстояния и качество связи сетевой админ решил поделить сайт на два сайта А в Антарктике и В в Европе.Пошаговый процесс репликации будет такой.

1. По истечении некоторого периода времени который определяется  установленной частотой репликации, сервер плацдарм (на рисунке это DC1) в Европе с сайта В  проводит опрос сервера плацдарма в Антарктиде находящимся в сайте А (на рисунке это DC4) на наличие обновленных данных.

2. Если на сайте А в Антарктиде есть в наличие объявления ActiveDirectory, они (в случае когда их размер  превышает 50 Кбайт) подвергаются сжатию и отсылаются на сервер плацдарм сайта В в Европе.

3. Получив все данные репликации с сайта А, сервер плацдарм сайта В в Европе реплицирует их в несжатом виде среди остальных контроллерах домена в рамках своего сайта.

Как можно заметить в ходе межсайтовой репликации в процессе  взаимодействия серверов плацдармов вместо метода "извещения и отправки", применяется метод "опроса и запрашивания". Межсайтовая репликация с запросом в данном случае более эффективна так как контроллер домена назначения знает, какие именно данные нужно запрашивать. Метод "извещения и отправки", напротив лучше себя проявляет в ходе внутрисайтовой репликации, когда контроллеры имеют надежную связь между собой и не ограничены графиками установления межсайтовых связей. 

Сравнение внутрисайтовой и межсайтовой репликации дано в таблице 1.

Таблица 1.    Сравнение внутрисайтовой и межсайтовой репликации

Внутрисайтовый транспорт

Как видно из таблицы 1, при внутрисайтовый  передачах используется RPC  поверх IP. Это быстрый механизм, способный с небольшими интервалами пересылать обновления внутри сайта. Так как в самом сайте, по определению  следует, что все связи между контроллерами имеют большую полосу пропускания, нет смысла выполнять сжатие передаваемых данных. При обычной частоте репликации  внутри сайта это приведет к дополнительному расходу ресурсов процессора.

Удаленный вызов процедур RPC использует динамическое назначение портов TCP. Обращаясь к Active Directory, клиент подключается по RPC к порту  135, также известный RPC Locator service  (этот порт так же используется службами удалённого обслуживания, такими как DHCP, DNS и WINS). Сервер запрашивает у локатора RPC порт, назначенный в данный момент для репликации Active Directory. По умолчанию этот порт назначается динамически при старте Active Directory и может быть любым среди портов с высокими номерами.

Номер порта можно зафиксировать. Для этого надо в ветви реестра -

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters  

изменить параметр TCP/IP Port. Значение может быть любым, кроме зарезервированных за другими службами.

Особенности  межсайтового  транспорта

Если мы говорим о межсайтовом транспорте, то и здесь  обычно предпочтение отдается  RPC поверх IP. Протокол  SMTP сетевые администраторы предпочитают не применять. Во-первых, это часто связано с тем, что в разных сайтах располагаются контроллеры из одного домена, что автоматически исключает использование SMTP.  Во-вторых, асинхронная природа SMTP не позволяет гарантированно реплицировать изменения в течение заданного интервала. Если в удаленном сайте есть глобальный каталог GC, изменения до него могут доходить с большим опозданием, что при неудачном стечении обстоятельств может воспрепятствовать доступу пользователей к ресурсам или, наоборот, предоставить его в тот момент, когда он уже запрещен.

Но недостатки асинхронной природы SMTP  полностью компенсируются при плохом канале связи.   При репликации процесс может затянуться, так как из-за постоянных тайм-аутов транзакции будут  незавершенными, и, следовательно, потребуется выполнять многократные откаты, и т.д . Поэтому на плохих линиях SMTP как транспорт репликации имеет преимущество.

Конечно, было бы самое время перейти к конкретной настройке на конкретном примере репликацию используя консоли WindowsServer 2003 предоставленные в наше расположение, но не спешите, мы даже пока не поговорили как устанавливается сама АД, так что об этом чуть позже.