Управление трафиком репликаций в Windows 2000

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

Разделы Active Directory

Репликация данных AD представляет собой достаточно сложный процесс, так как AD имеет сегментную структуру, причем каждый из множества разделов может включать в себя несколько реплицируемых элементов, зависящих друг от друга. В Microsoft для обозначения компонентов AD используют термины directory partition - раздел каталога или naming context - контекст имен (в соответствии со стандартом x.500 Directory Services). Проще всего сформировать разделы, разбив AD на домены. В этом случае количество разделов будет равно количеству доменов в лесу. Репликация информации между контроллерами домена не будет выходить за границы заданного домена.

В системе AD имеются другие разделы (контекст имен), в которых происходит репликация информации. Контекст имен конфигурации содержит информацию о структуре леса и его доменов, что позволяет осуществлять репликацию данных для всего леса. Контекст schema содержит информацию обо всех классах и атрибутах (т. е. о структуре базы данных AD) для леса. Таким образом, информация реплицируется по всему лесу. Разделы configuration и schema не слишком часто вызывают процесс репликации данных, так как их содержимое изменяется очень редко. Кроме того, эти контексты имен реплицируют данные по всему лесу, поэтому их можно группировать в одной топологии.

Еще один элемент реплицирования, с которым необходимо познакомиться, - это глобальный каталог (Global Catalog, GC). Глобальный каталог представляет собой подобие телефонного справочника. Как в телефонном справочнике индексируются абоненты, так в глобальном каталоге индексируются объекты в лесу. Глобальный каталог содержит наиболее общую информацию об объекте AD (такую, как имя пользователя, номер телефона, адрес электронной почты), а также данные о том, где можно найти этот объект, если требуется более подробная информация.

Хотя в Microsoft глобальный каталог не относят к разделам AD, он имеет свою топологию репликации данных, которую следует учитывать при проектировании структуры узлов и размещении контроллеров доменов. Глобальный каталог устанавливается только на тех контроллерах, которые помечены как серверы GC. Чтобы обеспечить доступность серверов GC во всем лесу, информация реплицируется от одного сервера к другому. На серверах GC хранится лишь небольшое количество атрибутов, однако они содержат данные обо всех объектах AD. В результате трафик от репликаций, создаваемый этими серверами, оказывается значительно больше, чем аналогичный трафик от других серверов. При удалении, изменении или добавлении любого объекта в лесу это действие отражается на всех серверах GC.

Теперь о том, что же представляет собой информация AD. AD включает в себя все объекты в лесу и их атрибуты. Если в системе имеется более одного домена, то ни один из контроллеров не будет содержать все эти объекты. Каждый контроллер домена хранит лишь часть информации AD, а именно: объекты и атрибуты, принадлежащие сегменту данного домена, копию контекста имен конфигурации (доступную только для чтения) и копию контекста имен схемы. Если контроллер домена является еще и сервером GC, то он содержит информацию обо всех объектах леса (но лишь небольшую часть их атрибутов). Крупные организации с большими доменами могут использовать серверы GC со значительным объемом информации, но ни один сервер не может содержать все данные Active Directory.

Методы репликации данных

В операционной системе Windows NT 4.0 для обновления данных применяется модель master-slave («главный-подчиненный»). При этом только основной контроллер домена (т. е. PDC) хранит доступную для записи копию информации о домене. Данные резервного (т. е. BDC) периодически обновляются. В этой модели синхронизация необходима только между PDC и BDC. В системе AD для обновления данных применяется модель multiple-master, в которой все контроллеры хранят доступную для записи копию информации AD. Поскольку обновление данных может производиться на любом из контроллеров домена, требуется специальный метод для репликации изменений от одного контроллера к другому. В AD используется два метода репликации: один - для репликаций внутри узла (intrasite), другой - для репликаций между узлами (intersite).

Репликации внутри узла. Изменения, которые вносятся в информацию на контроллере домена, должны реплицироваться на все контроллеры, входящие в данный сегмент Active Directory. В большинстве случаев (за исключением ситуаций, связанных с блокировкой учетных записей, изменением паролей и т. д.) для репликации данных используется модель, называемая loosely consistent. Данная модель репликации предполагает, что передача изменений на соседний контроллер домена и по всему сегменту происходит в течение определенного временного интервала (по умолчанию он равен 5 мин). Например, если пользователь изменил номер своего пейджера, то время распространения подобного изменения по всему домену будет зависеть от того, какое количество контроллеров имеется в данном узле, какое количество других узлов покрывает данный домен и сколько в этих других узлах имеется контроллеров. В некоторых случаях требуется немедленное реплицирование изменений, тогда контроллеры домена передают их, не выжидая обычных 5 мин.

Рисунок 1. Два объекта связи.

Для поддержки репликаций между контроллерами доменов в системе AD используются объекты связи (connection object). Объект связи представляет собой построенный на механизме RPC односторонний маршрут для репликаций, поступающих от соседних контроллеров домена. Для таких контроллеров в Microsoft используется термин replication partner (партнер по репликации). Аналогично тому, как в NT 4.0 двусторонние доверительные отношения формируются из двух односторонних, в Windows 2000 контроллеры доменов для осуществления двунаправленной репликации данных используют два объекта связи, как показано на Рисунке 1.

С помощью модуля Active Directory Sites and Services (консоли MMC) можно посмотреть, как используются объекты связи на контроллерах домена. Для этого следует дважды щелкнуть мышью на контейнере узла, чтобы получить список его контроллеров домена. Каждый контроллер имеет свой объект NTDS. Чтобы увидеть такой объект, нужно щелкнуть два раза на соответствующем контроллере домена, а затем дважды - на объекте NTDS. При этом должен открыться список объектов связи, используемых для передачи репликаций от других контроллеров домена к данному контроллеру. Теперь следует щелкнуть правой кнопкой мыши на объекте связи для входящих репликаций, и в открывшемся меню выбрать Replicate Now. При этом будет выдан запрос на немедленное обновление информации от соседних контроллеров домена.

Управление объектами связи AD - очень трудоемкая задача, если выполнять ее вручную. К счастью, в системе AD имеется механизм Knowledge Consistency Checker (KCC), который производит динамическое конфигурирование и обновление объектов связи для контроллеров домена и создает маршруты репликации данных. Механизм KCC работает на всех контроллерах и «цементирует» всю систему Active Directory. KCC нельзя рассматривать как обычную службу Windows 2000, но результаты его работы отображаются в журнале событий хранилища каталога DS.

Рисунок 2. Двунаправленная кольцевая топология.

KCC использует специальный алгоритм для связи контроллеров домена внутри узла. Он формирует список серверов узла для данного раздела AD (т. е. контекста имен текущего домена) и применяет объекты связи для объединения этих серверов в двунаправленное кольцо, как показано на Рисунке 2. Такая кольцевая топология гарантирует, что в случае выхода из строя одного из серверов, информация будет реплицироваться по всем оставшимся серверам, обходя вышедший из строя.

При увеличении числа контроллеров домена в узле продолжительность процесса репликации данных может возрасти, если каждый контроллер будет передавать информацию соседнему. Поэтому в таких случаях KCC изменяет алгоритм работы. При этом используется «правило трех переходов» (three-hop rule): каждый из контроллеров домена не может находиться далее, чем через три точки пересылки от другого контроллера. Таким образом, обновление информации должно передаваться от одного контроллера к другому не более трех раз, прежде чем оно достигнет контроллера домена, который уже получил это обновление по другому маршруту.

Рисунок 3. Контроллер домена, оптимизирующий связь.

Соблюдать правило трех переходов позволяет формирование оптимизирующих связей (т. е. коротких путей) между контроллерами домена, передающими репликации, как показано на Рисунке 3. Оптимизирующие связи создаются случайным образом (совсем не обязательно на каждом третьем контроллере). Можно, используя оснастку Active Directory Sites and Services, щелкнуть мышью на контейнере NTDS каждого из контроллеров домена и вручную задать топологию репликации данных, установив связи между контроллерами. Это достаточно сложная задача, поэтому для ее решения целесообразно применять утилиту Replmon, позволяющую в деталях отображать топологию репликаций. (Эту утилиту можно загрузить из каталога support ools на диске Windows 2000 Advanced Server.) Механизм KCC работает на всех контроллерах домена, используя один и тот же алгоритм для создания топологии узла. Следовательно, репликация данных между контроллерами будет происходить до тех пор, пока все они не будут содержать одну и ту же информацию.

Правильная конфигурация узла позволяет прогнозировать время задержек, связанных с распространением изменений от контроллера домена до любой другой точки в лесу. Например, если контроллер A (см. Рисунок 3) инициирует передачу обновления данных, то максимальное время распространения этой информации по всему узлу (до контроллера B) составит 15 мин, так как принятый по умолчанию в AD интервал равен 5 мин, и действует правило трех переходов.

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

Репликации между узлами. Управление репликациями данных между узлами AD в Windows 2000 осуществляется при помощи специальных серверов-мостов (bridgehead). (В данном случае мы предположим, что для связи между узлами используется только транспорт IP. Тем, кто использует транспорт SMTP, советую обратиться к Microsoft Windows 2000 Resource Kit.) Серверы назначаются службой KCC автоматически. Однако иногда лучше назначать такие серверы вручную, так как через них передается значительно больший сетевой трафик, чем через другие контроллеры домена.

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

Объяснить, как происходит процесс репликации данных между узлами, можно на примере модели, использующей методы репликаций внутри одного узла, в которой контроллеры доменов представляют собой объекты внутри узла, причем каждый из них содержит механизм генерации топологии (т. е. KCC). Если взять метод репликации данных внутри одного узла и поднять его на один уровень вверх, мы получим алгоритм репликации между узлами. С точки зрения топологии репликаций между узлами каждый из узлов рассматривается как объект внутри леса, содержащий механизм для формирования этой топологии. Такой механизм называется генератором межузловой топологии (Inter-Site Topology Generator, ISTG). Его функции выполняет один из контроллеров домена в каждом из узлов (как правило, первый контроллер узла). Сервер ISTG нельзя назначить вручную, но можно настраивать параметры репликации данных между узлами. Служба KCC контроллера ISTG создает соединения между контроллерами домена внутри данного узла и контроллерами в других узлах. Эти соединения содержат объекты связи для входящих репликаций для всех мостов в узле данного контроллера домена.

Если сервер ISTG выходит из строя, его функции берет на себя контроллер домена, имеющий следующий наибольший идентификатор GUID (globally unique ID). GUID представляет собой 128-разрядное значение, идентифицирующее каждый объект в AD. Чтобы посмотреть, какой сервер выполняет функции ISTG, в приложении Active Directory Sites and Services нужно щелкнуть мышью на объекте узла. Выбрав в правой панели объект NTDS Site Settings, следует щелкнуть на нем правой клавишей мыши и в открывшемся меню выбрать Properties. Имя сервера, исполняющего роль ISTG, отображается в окошке Server в группе Inter-Site Topology Generator.

Проектирование узлов При проектировании узлов необходимо задать четкие критерии для создания узла на определенном участке сети. Затем эти критерии применяются для всех участков сети организации, и формируется список узлов. Начать следует с создания одного узла, охватывающего всю сеть предприятия. Затем, проводя тестирование, нужно формировать новые узлы. Предположим, у нас имеется высокоскоростная сеть, объединяющая множество пользователей. Чтобы определить границы узла, необходимо соблюдать следующее важное правило: нельзя использовать кажущиеся очевидными простые решения, нужно убедиться, что выполняется установленное для узла требование. Таким требованием является то, что регистрация пользователей в сети должна происходить быстро. В нашем примере очевидным решением представляется создание собственного узла для этих пользователей. Границы узла, полученные на основе данного решения, не будут соответствовать границам, построенным в соответствии с изложенным выше требованием для узла AD. Чтобы оценить, выполняется ли заданное требование, для начало стоит решить для себя, нужно ли, чтобы пользователи, размещенные в одной части сети, регистрировались на контроллере домена, расположенном в другой ее части? В случае положительного ответа, можно предположить, что между этими двумя участками сети имеется хорошее высокоскоростное соединение, и их стоит поместить в один узел. При отрицательном ответе указанные два участка должны образовать отдельные узлы (или войти в состав узлов большего размера).

Правило быстрой регистрации пользователей в сети нужно применять для всех участков сети предприятия. Если организация является многонациональной, то необходимость в создании нескольких узлов очевидна. По крайней мере, по одному узлу на каждый регион. Дополнительные узлы AD необходимы, если используются медленные каналы WAN (например, в Азиатско-Тихоокеанском регионе в основном применяются каналы с пропускной способностью 512 Кбайт/с). Для определения границ узлов нужно снова ответить на вопрос, хотите ли вы, чтобы пользователи, размещенные в одной части сети, регистрировались на контроллере домена, расположенном в другой ее части? Едва ли целесообразно разворачивать сеть так, чтобы пользователи регистрировались в системе через каналы, пересекающие Атлантический или Тихий океан. Даже если такая регистрация возможна, вряд ли стоит увеличивать загрузку дорогостоящих каналов связи ради уменьшения числа узлов.

Далее следует применить второй тест для определения границ узла: имеются ли на данном участке сети клиент-серверные приложения, поддерживающие AD? Например, будут ли пользователи применять систему Dfs для работы с локальной копией данных, размещенных в том же узле? Если приложения используют узлы AD для выяснения того, какую информацию следует считать расположенной локально, то, возможно, имеет смысл создавать узлы меньшего размера с высокоскоростными каналами связи. Например, можно не принимать во внимание то, что пользователи регистрируются в системе на удаленном контроллере домена, но вряд ли допустимо, чтобы они использовали приложения SAP (Source Access Point) с удаленной базой данных.

Рисунок 4. Топология полносвязных узлов.

Определив границы узлов, нужно объединить их при помощи связей. Конфигурация узла зависит от допустимых временных задержек. Например, если система состоит более чем из двух узлов и время задержки должно быть минимальным, необходимо использовать полносвязную топологию (т. е. каждый узел должен иметь связи со всеми другими узлами, как это показано на Рисунке 4). Такая модель, подобно доменной полнодоверительной модели NT, плохо масштабируется. Чтобы обеспечить малое время задержек при достаточно большом числе узлов, лучше всего применить схему издатель-подписчик (hub-and-spoke), представленную на Рисунке 5.

Рисунок 5. Топология издатель-подписчик.

При такой схеме требуется не более двух переходов для передачи информации между любыми двумя узлами сети. Если предполагаемая временная задержка внутри узла равна 15 мин, и задержка для каждой из линий связи между узлами также равна 15 мин, то максимальная задержка для всего леса (для системы, включающей три узла) составит 1 ч 15 мин (около 15 мин внутри узла A, в зависимости от числа контроллеров в узле; плюс 15 мин между узлами A и B; плюс 15 мин внутри узла B; плюс 15 мин между узлами B и C; плюс 15 мин внутри узла C). Возможно, придется добавить поправку (около 5 мин) на передачу информации между узлами по каналам WAN. Общее время распространения репликации данных может быть и значительно меньше, все зависит от числа контроллеров доменов в узлах, от того, каким образом выбраны мосты и от местоположения контроллера, который инициирует репликацию изменений.

Несколько советов по проектированию узлов AD Помимо понимания основных концепций проектирования узлов, для построения оптимальной структуры узлов AD необходимо следовать еще нескольким правилам. Во-первых, чтобы контролировать маршруты репликаций и обеспечить отказоустойчивость, нужно устанавливать стоимости для связей между узлами. Стоимости связей назначаются в пределах от 1 до 100 и используются серверами ISTG для определения приоритетов связей при выборе маршрута. Можно создать дополнительные связи между узлами и установить их стоимость выше, чем у основных. Репликация данных всегда выполняется по связям, имеющим минимальную стоимость, но если они выйдут из строя, то более «дорогостоящие» связи примут на себя этот трафик. Например, если имеется две связи со стоимостями 10 и 50, то для репликации данных будет всегда использоваться связь со стоимостью 10. Если же она разорвется, то информация станет передаваться по связи со стоимостью 50.

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

Целесообразно разместить в каждом узле как минимум один сервер GC. Серверы GC необходимы для обеспечения успешной регистрации пользователей. Если такой сервер расположен вне узла, то трафик, связанный с регистрацией, пойдет в другой узел. Это нивелирует преимущества, получаемые от использования узлов AD. По той же причине нужно установить в каждом узле по крайней мере один сервер DNS.

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

Нужно ограничить количество узлов, включающих в себя несколько доменов. Если несколько доменов входят в один и тот же узел, то общая топология системы значительно усложняется, так как каждый раздел (контекст имен) AD имеет свою собственную топологию репликации данных. Так, например, если в состав узла входит два домена, то придется отслеживать четыре топологии репликации данных: два контекста имен доменов, контексты имен конфигурации и схемы, и глобальный каталог. Каждая из этих топологий (кроме глобального каталога) может включать в себя сервер-мост. Вместо создания нескольких доменов, в целях повышения уровня безопасности и делегирования административных прав, можно использовать организационные единицы (organizational unit, OU). Это позволяет избежать проблем, связанных с наличием нескольких доменов в одном узле.

Чтобы проектировать узлы AD, необходимо хорошо представлять себе физическую структуру сети предприятия. Кроме того, нужно обеспечивать баланс между используемыми возможностями системы и стоимостью их поддержки. Если поддержка какой-либо возможности обходится дороже самой проблемы, которая при этом решается, лучше от нее отказаться. Например, если имеется относительно небольшая сеть с хорошими каналами связи, то применение стоимостей для связей между узлами излишне.

При тестировании узлов AD следует запастись терпением, так как система репликации данных в Active Directory значительно сложнее, чем в NT 4.0. В NT 4.0 изменения распространяются по всему домену очень быстро. Тот же самый процесс в Windows 2000 протекает значительно медленнее.

При проектировании узлов AD приходится постоянно балансировать между различными возможными решениями. Если создать несколько маленьких узлов, то снижается трафик по каналам WAN и локализуется процесс выбора контроллера домена. Если же использовать меньшее количество более крупных узлов, то такой системой будет проще управлять. Кроме того, меньшее количество узлов большего размера позволяет сократить временные задержки и обеспечить участие в процессе репликации данных, сосредоточенных внутри одного узла, большего количества серверов. В окончательной реализации проекта, по-видимому, будет выбран компромиссный вариант между этими двумя способами построения структуры узлов AD.

ОБ АВТОРЕ

Шон Дьюби, старший системный инженер компании Intel. Занимается вопросами использования Windows 2000 и NT Server в крупномасштабных проектах. Автор книги «Windows 2000 Server: Planning and Migration». С ним можно связаться по адресу: spdeuby@mail.com.