Книги, научные публикации
Pages: | 1 | 2 | 3 | 4 | ... | 8 | С. Реймер, М. Малкер Active Directory для Windows Server 2003. Справочник администратора/Пер, с англ. Ч М.: СП ЭКОМ, 2004.Ч 512 с: ил. ...
-- [ Страница 2 ] --Глава 3. Active Directory и доменная система имен Служба каталога Active Directory Microsoft Windows Server 2003 при поиске ресурсов в сети полностью полагается на доменную систему имен (DNS). Без надежной инфраструктуры DNS контроллеры домена в сети не смогут делать реплики друг с друга, клиенты Microsoft Windows 2000 и Microsoft Windows XP Professional не смогут входить в сеть, а серверы, на которых выполняется приложение Microsoft Exchange Server 2000, не смогут посылать электронную почту.
По существу, если ваша реализация службы DNS нестабильна, то сеть Windows Server 2003 не будет работать. Это значит, что для управления средой Active Directory вы должны иметь глубокое знание концепций DNS и ее реализации в Windows Server 2003.
Данная глава начинается с краткого обзора DNS как службы. Далее подробно рассказывается, почему Active Directory зависит от DNS, и как работает процесс разрешения имен. Затем речь идет о службе DNS в системах Windows Server 2003, Standard Edition;
Windows Server 2003, Enterprise Edition;
Windows Server 2003, Datacenter Edition. В операционной системе Windows Server доменная система имен имеет свойства, которые делают весьма привлекательным развертывание Active Directory.
Примечание. Версия Windows Server 2003, Web Edition не требует и не поддерживает службу Active Directory.
Краткий обзор DNS DNS является службой разрешения имен. Если вы пытаетесь найти сервер в интернете, более вероятно, что вы помните его имя, например, www.microsoft.com, чем IP-адрес, который может выглядеть как 207.46.230.219. Однако вашему компьютеру для соединения с Web-сайтом Microsoft требуется знать его IP-адрес. Служба DNS выполняет этот перевод. Вы сообщаете своему браузеру имя компьютера, с которым вы хотели бы соединиться, a DNS превращает это имя в правильный IP-адрес.
Примечание. Поскольку доменная система имен важна для работы Active Directory, вы должны ознакомиться с концепциями службы DNS и знать, как она реализована. Если вы не знакомы с DNS, вам следует просмотреть некоторые ресурсы, имеющиеся на веб-сайте Microsoft по адресу library/en-us /dns/dns_concepts. asp.
Иерархическое пространство имен DNS использует иерархическое пространство имен для поиска компьютеров. На рисунке 3- показан пример организации пространства имен. Корневой домен обозначается точкой (л.). Он представляет собой верхний уровень DNS, остальное пространство имен располагается ниже. На следующем уровне под корневым доменом располагаются домены первого уровня, включая семь основных (generic) доменных имен (com, edu, mil, net, org), около двухсот сокращений названий стран (са, uk, fr, br), семь новых доменов (biz, info, pro и т.д.), которые были введены в 2001 году.
Рис. 3-1. Иерархическое пространство имен DNS Под доменами верхнего уровня расположены домены второго уровня, которые обычно относятся к названиям компаний и должны быть зарегистрированы властями интернета. Ниже доменов второго уровня располагаются поддомены. Поддомены обычно относятся к отделам или подразделениям в пределах компании. Эти поддомены регистрируются и управляются с DNS серверов, которые содержат информацию о доменах второго уровня.
Другим способом представления иерархического пространства имен является полностью определенное имя домена (FQDN Ч Fully Qualified Domain Name), например, www.NAmerica.Contoso.com. FQDN представ ляет собой полное имя, которое можно использовать для идентификации определенного компьютера в пределах всего пространство имен DNS. Чтобы понять, как FQDN идентифицирует компьютер в пространстве имен DNS, прочтите его справа налево. Справа находится точка (л.), которая идентифицирует корневой домен, она предшествует имени домена первого уровня. За ней следуют домен com первого уровня, домен Contoso второго уровня и поддомен NAmerica. Слева в имени FQDN находится www - имя определенного компьютера.
Распределенная база данных Поскольку DNS использует иерархическое пространство имен, то достаточно просто сконфигурировать его как распределенную базу данных. Прежде чем в интернете была реализована доменная система имен, вся информация, необходимая для разрешения имен, хранилась в единственном файле. Поскольку количество хостов в интернете увеличилось до сотен тысяч компьютеров, то управление одним файлом стало непрактичным. Была разработана система DNS, использующая распределенную базу данных. Использование распределенной базы данных означает, что информация DNS хранится на многих компьютерах во всем мире (в случае интернета) и повсюду в вашей сети (в случае внутренней сети). Каждый DNS-сервер обслуживает только одну маленькую часть базы данных DNS. Вся база данных разделена на зонные файлы на основе имен доменов. Зонные файлы распределены между несколькими серверами. К примеру, существует около дюжины серверов, которые содержат зонные файлы для корневого домена. Они хранят информацию о DNS-cep-верах, которые несут зонную информацию для доменов высшего уровня. Корневые серверы не содержат всю информацию о доменах высшего уровня, но они знают, какие серверы имеют эту информацию.
DNS-серверы, хранящие информацию о доменах высшего уровня, содержат также информацию о том, на каких серверах находятся зонные файлы для доменов следующего уровня. Например, сервер может содержать зонные файлы для домена сот, т.е. этот сервер знает обо всех доменах второго уровня, которые зарегистрированы с доменом сот, но он может не знать отдельные детали о домене второго уровня. Сервер домена высшего уровня знает, какой компьютер на следующем уровне содержит детали, касающиеся домена второго уровня, и так продолжается до самого низа пространства имен DNS. Сервер, ответственный за домен com, может иметь домен Contoso, зарегистрированный как домен второго уровня. Этот сервер может передавать любые запросы на информацию о домене Contoso на сервер, который содержит зонные файлы для Contoso.com.
Использование метода распределенной базы данных означает, что никакому серверу в интернете не требуется иметь всю информацию DNS. Большинство серверов хранят информацию о некоторой части дерева, но когда приходит запрос, который они не могут выполнить, им известно, какой DNS-сервер хранит необходимую информацию. DNS-серверы используют делегированные записи, ретрансляторы (forwarders) и корневые ссылки для определения того, какой DNS-сервер имеет необходимую информацию. Эти темы будут обсуждаться далее в главе.
Процесс разрешения имен Иерархическое пространство имен DNS и распределенная база данных используются тогда, когда клиент пробует найти IP-адрес ресурса в интернете. Используя пример из предыдущего раздела (см. рис. 3-1), предположим, что клиент DNS (назовем его преобразователем), расположенный в какой-то точке земного шара, хочет соединиться с веб-сервером, имеющим адрес www.NAmerica.Contoso.com. Для получения IP-адреса выполняются следующие действия.
1. Клиент-преобразователь посылает рекурсивный запрос об IP-адресе на свой сконфигурированный DNS-сервер (обычно это DNS-сервер провайдера службы интернета). Рекурсивный запрос может иметь только два возможных ответа: IP-адрес, запрашиваемый клиентом, или сообщение об ошибках, указывающее, что информация не может быть найдена.
2. Если DNS-сервер провайдера имеет необходимую информацию в своем кэше, то он возвращает IP-адрес пользователю. Если нужной информации нет, то он пробует найти информацию, посылая итерационный запрос на другой сервер. Ответом на итерационный запрос может быть или разрешенное имя, запрашиваемое клиентом, или переадресация на другой DNS-сервер, который сможет выполнить запрос. В нашем примере DNS-сервер провайдера посылает итерационный запрос корневому серверу об IP-адресе, который соответствует www.NAmerica.Contoso.com.
3. Корневой сервер не может ответить на запрос, но в ответ он присылает список серверов, ответственных за домен высшего уровня сот. Этот процесс предоставления списка альтернативных DNS-серверов для дальнейшего контакта называется направлением (referral). DNS-сервер интернет-провайдера посылает итерационный запрос одному из этих серверов с просьбой об IP-адресе.
4. Сервер сот дает в ответ список серверов, которые являются ответственными за домен Contoso.com. Далее DNS-сервер провайдера посылает запрос DNS-серверу Contoso.com, который дает в ответ имена DNS-серверов, управляющих доменом NAmerica.Contoso.com.
5. DNS-сервер NAmerica.Contoso.com содержит всю информацию об этом домене, и он посылает DNS-серверу провайдера IP-адрес нужного хоста.
6. DNS-сервер провайдера отвечает на рекурсивный запрос, который он получил от клиента преобразователя, и посылает IP-адрес запрошенного Web-сервера.
7. Компьютер клиента соединяется с www.NAmerica.Contoso.com.
8. Этот процесс происходит очень быстро и может не включать некоторые шаги. Когда DNS сервер разрешает любой тип имени, он сохраняет эту информацию в кэше в течение определенного периода. Если кто-то искал этот же сайт раньше в этот день и DNS-сервер провайдера разрешил это имя, то он просмотрит свой кэш и даст ответ немедленно.
9.
Записи ресурсов Текущие записи, хранящиеся в зонных файлах DNS, называются записями ресурсов (RR Ч Resource Records). Записи ресурсов содержат текущую информацию о домене. Вы можете создать двадцать два различных типа записей ресурсов на DNS-сервере системы Windows Server 2003.
Наиболее распространенные записи ресурсов перечислены в таблице 3-1.
Табл. 3-1. Наиболее распространенные записи ресурсов в доменной системе имен Windows Server Название Пояснение Start of Authority Идентифицирует основной сервер имен для (SOA) - начало зоны, устанавливает параметры, заданные по полномочий умолчанию для зонной передачи, параметры длительности хранения зонной информации и время жизни (TTL Ч Time to Live) (см. рис. 3-2).
Host (A) - хост Идентифицирует IP-адрес для определенного имени хоста. Это та запись, которую DNS-cep вер возвращает в процессе разрешения имен.
Mail Exchanger (MX) - Идентифицирует серверы передачи интернет коммутатор сообщений. Используется другими серверами электронной почты передачи интернет-сообщений для поиска аналогичных серверов в домене.
Name Server (NX) - Идентифицирует все серверы имен для домена.
сервер имен Pointer (PTR) - Идентифицирует имена хостов, отображаемых на указатель определенных IP-адресах. Хранится в зоне обратного просмотра.
Canonical Name Идентифицирует псевдоним другого хоста в (CNAME) - домене. Применяется в том случае, когда каноническое имя несколько имен хоста используют один и тот же Service Locator (SRV) IP-адрес.
- указатель служб Идентифицирует службу, которая имеется в домене. Active Directory широко использует записи SRV для поиска контроллеров домена.
Рис. 3-2. Запись SOA для домена Contoso.com Совет. На рисунке 3-2 показана запись SOA в инструменте администрирования DNS. Записи DNS могут быть сохранены в стандартном текстовом формате. Например, стандартная запись хоста для сервера по имени Webl.Contoso.com может быть записана как Webl.Contoso.com IN A 192.168.1.100.
DNS-домены, зоны и серверы Одним из важных аспектов изучения работы DNS является понимание терминологии, которая используется для описания компонентов DNS.
Сравнение доменов и зон Одна из проблем терминологии, которая может затруднять понимание, состоит в различии между доменами и зонами. С одной стороны, это различие состоит в том, что домен представляет часть пространства имен DNS, а зоны Ч это информация об этой части пространства имен. Например, компания может владеть именем домена второго уровня Contoso.com. Это означает, что компания владеет одной частью полного пространства имен DNS, т.е. это их домен. Когда компания реализует DNS-серверы для домена, то вся информация о домене DNS будет храниться на одном или нескольких DNS-серверах. Эта информация включает все записи ресурсов всех компьютеров в домене DNS. Она является зонной информацией и хранится в зонных файлах на серверах DNS.
Существует два различных типа зонных файлов в DNS: зоны прямого просмотра и зоны обратного просмотра. Зона прямого просмотра используется для разрешения имен хоста к IP адресам. Эти функциональные возможности обеспечивают записи хоста (А). Зона прямого просмотра может включать записи SOA и NS, а также записи MX, CNAME и SRV. Зона прямого просмотра используется всякий раз, когда клиент-преобразователь делает запрос DNS-серверу, чтобы найти IP-адрес сервера в сети.
Зоны обратного просмотра выполняют противоположную функцию. Она используется тогда, когда IP-адрес хоста известен, а имя хоста не известно. Зона обратного просмотра также имеет записи SOA и NS, остальная часть записей - это записи PTR. Формат записи PTR подобен записи хоста, но он обеспечивает ответ для обратного поиска. Для получения дополнительной информации о записях см. табл. 3-1.
Имя зоны прямого просмотра является именем домена. Имя зоны обратного просмотра определить более трудно, потому что она использует IP-адрес подсети, а не имя домена, в качестве границы зоны. Когда вы создаете зону обратного просмотра, вы должны дать ей имя, основанное на IP адресе подсети. Например, если вы создаете зону обратного просмотра для подсети 192.168.1.0, то зонное имя будет L168.192.in-addr.arpa. Имя in-addr.arpa специально зарезервировано в DNS для ссылок на зоны обратного просмотра. Первая часть зонного имени является сетевым адресом, записанным в обратном порядке. Если вы создаете зону обратного просмотра для подсети класса В (150.38.0.0), имя зоны обратного просмотра будет 38.150.in-addr.arpa.
Основные серверы имен Основным сервером имен (Primary Name Server) является единственный сервер, имеющий перезаписываемую копию зонных файлов (зона на основном сервере имен называется основной зоной - primary zone). Это означает, что DNS-администратор должен иметь доступ к основному серверу имен всякий раз, когда нужно внести какие-либо изменения в зонную информацию. После того как внесены изменения, эти данные автоматически копируются на дополнительные серверы имен с помощью процесса, который называется зонной передачей.
Дополнительные серверы имен Дополнительный сервер имен (Secondary Name Server) имеет копию зонных файлов, которая предназначена только для чтения. Единственный способ обновления зонной информации дополнительного сервера имен состоит в зонной передаче с основного сервера имен. В ранних версиях DNS каждая зонная передача была полной зонной передачей, т.е. все содержимое зонного файла DNS передавалось с основного сервера имен на дополнительный. Документ Request for Comment 1995 (Запрос на комментарии) представил более эффективный механизм зонной передачи, называемый добавочной зонной передачей (incremental zone transfers), в котором на дополнительный сервер копируются только изменения, сделанные в зонных файлах с момента последней передачи. Другое усовершенствование представлено в документе Request for Comment 1996. Это механизм уведомлений, который позволяет основному серверу предупреждать дополнительные серверы имен о том, что были сделаны изменения к зонным файлам. Без опции уведомления дополнительный сервер имен будет контактировать с основным сервером только через интервалы времени, определенные в записях SOA для каждой зоны.
Примечание. DNS-сервер Windows Server 2003 поддерживает как добавочную зонную передачу, так и уведомления. Он также поддерживает интегрированные (integrated) зоны Active Directory, в которых регулярная зонная передача заменена репликацией Active Directory.
Кэширующие серверы имен Третий тип сервера имен - это сервер, который только кэширует информацию (caching-only). Он не управляет зонными файлами, а только кэширует любые разрешения имен, которые он выполнял. Кэширующий сервер часто используется в удаленных офисах, подключенных к большому офису с ограниченной пропускной способностью. Поскольку кэширующий сервер не имеет никаких зонных файлов, то и трафик зонной передачи DNS через медленное сетевое подключение отсутствует. Кэширующий сервер должен конфигурироваться так, чтобы он переправлял все DNS-запросы на сервер, расположенный в главном офисе компании. Поскольку кэширующий сервер разрешает DNS-запросы, то он кэширует информацию в течение некоторого времени (по умолчанию -1 час). Это означает, что любой местный DNS-запрос той же самой информации может быть разрешен в местном масштабе.
Примечание. Все DNS-серверы Windows Server 2003, включая основной и дополнительные серверы имен, кэшируют информацию, но они не называются кэширующими (caching-only) серверами.
Различие между этими серверами и только кэширующими серверами состоит в том, что последний не имеет никакой зонной информации.
Зоны полномочий Чтобы полностью понимать DNS, вы должны познакомиться с зонами полномочий (zones of authority) и полномочными (authoritative) серверами имен. Каждый основной и дополнительный серверы имен являются полномочными для своего домена. Например, если DNS-сервер содержит зонные файлы для домена Contoso.com, то этот сервер является полномочным сервером имен для этого домена. Как полномочный сервер имен он не будет отправлять никаких запросов о хостах этой зоны другим DNS-серверам. Многие компании устанавливают конфигурацию DNS-сервера так, как показано на рисунке 3-3. В этом сценарии имеются два основных DNS-сервера, сконфигурированные для домена Contoso.com. DNS содержит запись хоста для сервера по имени Webl.Contoso.com, a DNS2-cepBep этой записи не имеет. Когда клиент соединяется с DNS1, он сможет разрешить IP-адрес для Webl. Когда клиент соединяется с DNS2 и запрашивает IP-адрес для Webl, сервер ответит, что хост не может быть найден. Поскольку DNS2 сервер является полномочным для домена Contoso.com, он не будет отправлять запросы серверу DNS1. Его поведение заложено в проекте и, как показывает обсуждение примера в разделе Практический опыт, это дает определенное преимущество в безопасности.
Рис. 3-3. Множество полномочных DNS-серверов Практический опыт. Использование нескольких полномочных серверов для одной зоны Иногда возникает ситуация, когда компания имеет два DNS-сервера, являющимися полномочными для одного домена, и интернет-имя DNS компании и ее внутреннее имя DNS идентичны (как показано на рис. 3-3). Сервер DNS1 находится с внутренней стороны брандмауэра, а сервер DNS2 - с его внешней стороны. Сервер DNS2 используется для разрешения DNS-запросов клиентов интернета, в то время как DNS1 используется для внутренних клиентов и для SRV-записей Active Directory.
Поскольку оба сервера полномочны для одной и той же зоны (Contoso.com), они не будут отправлять запросы об этом домене друг другу.
В этом случае необходимо поддерживать уникальную зонную информацию на каждом DNS-сервере. Внешний DNS-сервер, вероятно, будет иметь относительно маленький зонный файл, состоящий из веб-серверов и МХ-записей, которые должны быть доступны из интернета. Внутренний DNS-сервер будет иметь намного больший зонный файл, содержащий все записи контроллера домена, все внутренние записи сервера и, возможно, записи хоста для всех клиентских компьютеров в сети. Единственное дублирование между двумя зонными файлами может состоять из некоторых внешних записей DNS. Например, когда внутренние клиенты соединяются с www.Contoso.com, вы можете потребовать, чтобы они соединялись с тем же внешним веб-сервером, к которому обращаются интернет клиенты. Для этого нужно включить запись хоста для вебсервера в зонный файл на DNS1. Если вы не сделаете этого, то внутренние клиенты не смогут соединяться с веб-сервером.
Делегированные зоны Поскольку система DNS использует иерархическое пространство имен, должен существовать механизм соединения разных уровней иерархии. Например, если клиент соединяется с сервером, который является полномочным для домена первого уровня сот, и запрашивает сервер в домене Contoso.com, corn-сервер должен уметь определять, какой сервер имен является полномочным для домена Contoso.com. Это возможно при помощи записей делегирования (delegation records).
Запись делегирования представляет собой указатель на домен низшего уровня, который идентифицирует сервер имен для домена низшего уровня. Например, на рисунке 3-4 показано, что DNSl.Contoso.com является полномочным сервером имен для домена Contoso.com. DNS2 и DNS являются полномочными серверами имен для домена NAmerica.Contoso.com. Сервер DNS считается полномочным для домена NAmerica.Contoso.com, но он не имеет всех записей ресурса дочерних доменов. Однако сервер DNS1 использует запись делегирования, указывающую на DNS2 и DNS3 как на серверы имен для дочернего домена. Когда клиент соединяется с сервером DNS1, запрашивая информацию об NAmerica.Contoso.com, сервер перешлет клиента на сервера имен дочернего домена.
Ретрансляторы и корневые ссылки Второй способ соединения различных уровней иерархии системы DNS состоит в использовании корневых ссылок и ретрансляторов. В большинстве случаев ретрансляторы и корневые ссылки используются низкоуровневыми серверами пространства имен DNS для поиска информации, находящейся на высокоуровневых серверах DNS-иерархии. Ретрансляторы и корневые ссылки используются DNS-сервером для поиска информации, которая отсутствует в их собственных зонных файлах. Например, DNS-сервер может быть полномочным только для домена Contoso.com.
Когда он получит запрос от клиента, запрашивающего разрешение имени в домене Fabrikam.com (см. рис. 3-1), DNS-сервер Contoso.com должен иметь какой-то способ поиска этой информации.
Рис. 3-4. Делегированные зоны Одним из способов конфигурирования сервера для этих целей является использование ретрансляторов. Ретранслятор (forwarder) - это просто другой DNS-сервер, который используется определенным DNS-сервером, когда он не может разрешить запрос. Например, полномочный сервер имен для Contoso.com может получить рекурсивный запрос для домена Fabrikam.com. Если DNS-сервер Contoso был сконфигурирован с ретранслятором, то он отправит рекурсивный запрос ретранслятору, запрашивая эту информацию. Ретрансляторы часто используются во внутренней сети организации. Организация может иметь несколько DNS-серверов, главной задачей которых является внутреннее разрешение имен. Пользователям внутри организации может потребоваться разрешение IP-адресов интернета. Это можно выполнить, сконфигурировав все внутренние DNS серверы так, чтобы они могли разрешать адреса интернета. Более распространенным вариантом является конфигурирование внутренних DNS-серверов с ретранслятором, указывающим на DNS сервер, являющийся ответственным за разрешение имен интернета. Этот вариант показан на рисунке 3-5. Все внутренние DNS-серверы отправляют любой запрос для неполномочной зоны на один DNS-сервер, который разрешает интернет-адреса. Если DNS-сервер сконфигурирован с несколькими ретрансляторами, то он будет отправлять запросы всем ретрансляторам по порядку, прежде чем попытается использовать любой другой способ разрешения IP-адресов.
Рис. 3-5. Использование ретрансляторов для разрешения имен в Интернете Второй метод, который может применить DNS-сервер при ответе на запросы для тех зон, для которых он не является полномочным, состоит в использовании корневых ссылок. Когда вы устанавливаете DNS-сервер Windows Server 2003, имеющий доступ к интернету, он автоматически конфигурируется со стандартным списком корневых серверов. Корневые серверы - это серверы, которые являются полномочными для корня в пространстве имен интернета. Если DNS-сервер получает запрос о зоне DNS, для которой он не является полномочным, сервер посылает итерационный запрос одному из корневых серверов. Итерационные запросы будет инициироваться до тех пор, пока нужное имя не будет разрешено или пока сервер не подтвердит, что оно не может быть разрешено.
Примечание. Корневые серверы, которые автоматически указываются на DNS-сервере при его конфигурировании, копируются из файла Cache.dns, который поставляется с файлами установки DNS-сервера.
Вы можете добавлять дополнительные DNS-серверы к списку корневых ссылок, включая в него DNS-серверы, имеющиеся в вашей внутренней сети.
По умолчанию DNS-серверы Windows Server 2003 используют ретрансляторы и корневые ссылки, когда они пытаются разрешать имена. Если сервер конфигурирован с ретрансляторами, он сначала отправит рекурсивные запросы всем ретрансляторам. Если ни один из ретрансляторов не может обеспечить необходимую информацию, то DNS-cep-вер начнет посылать повторяющиеся запросы серверам, сконфигурированным как корневые ссылки. В некоторых случаях необходим DNS сервер, использующий только ретрансляторы и не использующий корневые ссылки. Чтобы сконфигурировать такой сервер, выберите опцию Do Not Use Recursion For This Domain (He использовать рекурсию для этого домена) на вкладке Forwarders (Передатчики) в окне Properties (Свойства) DNS-сервера. После этого DNS-сервер сначала будет пытаться разрешить любые запросы с помощью своей местной зонной или кэ-шированной информации, посылая рекурсивные запросы каждому из своих ретрансляторов. Если ретрансляторы не смогут обеспечить необходимую информацию, DNS-сервер не будет использовать другие средства, чтобы найти эту информацию. Он сообщит клиенту, что хост не может быть найден.
Примечание. В системе DNS Windows Server 2003 возможности традиционных ретрансляторов расширены за счет реализации условных ретрансляторов. Эта тема подробно рассматривается в разделе Условная ретрансляция далее в этой главе.
Динамическая система DNS В прошлом сложность работы с DNS состояла в том, что вся зонная информация должна была вводиться вручную. До выхода документа RFC 2136 не существовало никакого способа автоматического обновления зонной информации DNS-сервера. В документе RFC 2136 описано, как DNS-серверы должны быть сконфигурированы, чтобы автоматически принимать обновления к записям ресурсов в зонных файлах. Эта опция называется динамической службой DNS (DDNS).
DNS-серверы Windows Server 2003 поддерживают динамическую службу DNS. По умолчанию все клиенты Windows 2000 и Windows XP Professional, а также Windows 2000 Server;
Windows Advanced Server;
Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition;
Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition автоматически обновляют свои записи ресурсов в DNS. Windows 2000 и контроллеры домена Windows Server автоматически регистрируют SRV-записи на DNS-серверах, которые используются для поиска контроллеров домена. DNS-серверы Windows Server 2003 будут также принимать динамическую регистрацию записей с серверов динамической конфигурации хостов (DHCP). DHCP-сервер Windows Server 2003 может конфигурироваться для автоматического обновления DNS-записей для любого из его клиентов, включая Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Me или Microsoft Windows NT.
Одна из проблем динамической системы DNS связана с безопасностью. Без какого-либо контроля над тем, кому позволено обновлять записи ресурсов DNS, любой, имеющий доступ к вашей сети, потенциально может создать запись ресурса в ваших зонных файлах DNS, а затем использовать эту запись для переадресации сетевого трафика. Чтобы решить эту проблему в системе DNS Windows Server существуют безопасные обновления. Безопасные обновления имеются только в интегрированных зонах Active Directory. С помощью безопасных обновлений вы можете управлять тем, кому дается право регистрировать и обновлять DNS-записи. По умолчанию члены группы Authenticated Users (Уполномоченные пользователи) имеют право обновлять свои записи в системе DNS. Вы можете изменить это, изменяя список управления доступом ACL (ACL - Access Control List) для DNS-зоны.
Динамическая система DNS уменьшает объем работы, который должен делать администратор DNS. Далее вы узнаете, что Active Directory Windows Server 2003 требует присутствия SRV-записи каждого контроллера домена в зонной информации, поэтому поддержка динамических обновлений является важным свойством DNS-системы Windows Server 2003.
DNS и Active Directory Windows Server Active Directory не сможет функционировать без надежной конфигурации DNS. Контроллеры домена не смогут находить друг друга для репликации доменной информации, клиенты с системами Windows 2000 и Windows XP Professional будут очень медленно искать контроллеры домена для входа в систему. Без надежной DNS любые другие службы, которым требуется Active Directory, не смогут работать. Например, Exchange Server 2000 хранит всю свою конфигурационную информацию в Active Directory, поэтому если серверы, на которых выполняется Exchange Server 2000, не смогут найти контроллер домена при запуске, они не смогут запустить большинство служб Exchange Server 2000.
Совет. Клиенты, на которых выполняются системы Windows 95, Windows 98, Windows Me и Windows NT не полагаются на DNS в поиске контроллеров домена с Windows Server 2003. Они используют для поиска имена NetBIOS, а службу имен интернета для Windows (WINS - Windows Internet Naming Service) - для разрешения имен NetBIOS к IP-адресам. По умолчанию Windows Server 2003 поддерживает низкоуровневых клиентов, регистрируя необходимые имена NetBIOS с помощью WINS.
Служба DNS Locator Служба DNS Locator (Указатель DNS) очень важна для Active Directory, потому что DNS обеспечивает информацию, которая необходима клиентам для поиска контроллеров домена в сети.
Далее детально рассматривается процесс, которым пользуется клиент для поиска контроллеров домена.
Примечание. В Windows NT вход в систему домена был основан на именах NetBIOS. Каждый контроллер домена регистрировал имя NetBIOS Domainname с <1С> в качестве шестнадцатого символа имени в сети и в службе WINS. Когда клиент пробовал войти в сеть, он пытался найти серверы, которые имели зарегистрированное имя контроллера домена. Если клиент не находил ни один из этих серверов, то он не мог войти в систему. Записи SRV на Windows Server используются для поиска контроллеров домена клиентами, на которых выполняются системы Windows 2000 и Windows XP Professional. Без записей SRV эти клиенты не смогут войти на домен Windows Server 2003.
Записи ресурсов DNS, зарегистрированные контроллером домена Active Directory Чтобы облегчить нахождение контроллеров домена, Active Directory использует указатель служб (service locator) или записи SRV. Записи SRV - это новый тип DNS-записи, описанный в документе RFC 2782, он используется для идентификации услуг в TCP/IP-сети. На примере одной из записей, используемых службой Active Directory, показано, как каждая запись SRV использует стандартный формат (см. табл. 3-2).
_ldap._tcp.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com Табл. 3-2. Компоненты записи SRV Объяснение Компонент Пример _ldap Служба, которую идентифицирует запись.
Служба Дополнительные службы включают _kerberos, _kpassword и _gc.
Протокол _tcp Протокол, используемый для этой службы.
Может быть протоколом TCP или протоколом пользовательских датаграмм (UDP).
contoso.com Имя домена, на который ссылается запись.
Имя Время Заданное по умолчанию время жизни жизни (TTL записи (в секундах).
- Time to Live) IN Класс Стандартный DNS-класс интернета.
SRV Запись Идентифицирует запись как запись SRV.
ресурса Приоритет Идентифицирует приоритет записи для клиента. Если существует несколько SRV записей для одной и той же службы, клиенты будут сначала пытаться соединиться с сервером, имеющим самый низкий приоритет.
Вес 100 Механизм балансировки нагрузки. Если существует несколько SRV-записей для одной и той же службы, и приоритет всех записей одинаков, клиенты чаще выбирают записи с более высокими весами.
Порт Порт, используемый этой службой.
Адресат dc2.contoso.co Хост, который обеспечивает службу, m идентифицированную записью.
По сути, информация в этой записи говорит, что если клиент ищет сервер облегченного протокола службы каталогов (LDAP) в домене Contoso.com, он должен соединиться с dc2.contoso.com.
Контроллеры домена в домене Windows Server 2003 регистрируют много SRV-записей в системе DNS. Следующий список включает все записи, зарегистрированные первым сервером леса.
contoso.com. 600 IN A 192.168.1. _ldap._tcp.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRV 0 100 dc2.contoso.com.
_ldap._tcp.pdc._msdcs.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.gc._msdcs.contoso.com. 600 IN SRVO 100 3268 dc2.contoso.com.
_ldap._tcp. Default-First-Site-Name._sites._gc._msdcs.contoso.com. 600 IN SRV 100 3268 dc2.contoso.com.
_ldap._tcp.64c228cd-5f07-4606-b843-d4fd114264b7.domains._msdcs.contoso.com.
600 IN SRV 0 100 389 dc2.contoso.com.
gc._msdcs.contoso.com. 600 IN A 192.168.1. 175170ad-0263-439f-bb4c-89eacc410ab1._msdcs.contoso.com. 600 IN CNAME dc2.contoso.com.
_kerberos._tcp.dc._msdcs.contoso.com. 600 IN SRVO 100 88 dc2.contoso.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.contoso.com. 600 IN SRV 0 100 88 dc2.contoso.com.
_ldap._tcp.dc._msdcs.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.contoso.com. 600 IN SRV 100 389 dc2.contoso.com.
_kerberos._tcp.contoso.com. 600 IN SRV 0 100 88 dc2.contoso.com.
_kerberos._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRV 0 100 dc2.contoso.com.
_gc._tcp.contoso.com. 600 IN SRV 0 100 3268 dc2.contoso.com.
_gc._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRVO 100 dl2.contoso.com.
_kerberos._udp.contoso.com. 600 IN SRV 0 100 88 dc2.contoso.com.
_kpasswd._tcp.contoso.com. 600 IN SRV 0 100 464 dc2.contoso.com.
_kpasswd._udp.contoso.com. 600 IN SRV 0 100 464 dc2.contoso.com.
DomainDnsZones.contoso.com. 600 IN A 192.168.1. _ldap._tcp.DomainDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._lcp.Default-First-Site-Name._sites.DomainDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
ForestDnsZones.contoso.com. 600 IN A 192.168.1. _ldap._tcp.ForestDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
Примечание. Если на котроллере домена установлена система Windows Server 2003, все эти записи записываются в файл по имени Netlogon.dns, расположенный в папке %systemroot%\ system32\config. Если вы не хотите допускать динамические обновления на DNS-серверах, вы можете импортировать эти записи в зонные файлы DNS.
Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV.
Существуют следующие службы:
Х _ldap Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2003 или другими LDAP-серверами;
Х _kerberos - основной опознавательный протокол для всех клиентов Windows 2000 и Windows XP Professional. SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC - Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;
Х _kpassword Ч идентифицирует серверы изменения паролей kerberos в сети (это или контроллеры домена с Windows Server 2003 или с другими системами изменения пароля kerberos);
Х _gc - специфическая запись, относящаяся к функции глобального каталога в Active Directory. Сервер глобального каталога выполняет множество важных функций в Active Directory.
Многие из SRV-записей содержат идентификатор сайта в дополнение к компонентам, перечисленным в таблице 3-2. Сайт используется в Active Directory для идентификации одной или более IP-подсетей, которые связаны через высокоскоростные сетевые подключения. Одно из преимуществ использования сайтов состоит в том, что сетевые клиенты всегда будут пробовать войти на контроллер домена, который находится на том же самом сайте, что и клиент. Записи сайта нужны компьютерам для поиска контроллеров домена, расположенных в том же самом сайте, где находится клиент. Подробности механизма, который используется клиентом для поиска информации, касающейся сайта, обсуждаются в следующем разделе.
Другим необходимым компонентом SRV-записей является значение _msdcs, которое имеется во многих записях. Некоторые службы, предусмотренные записями SRV, не относятся к службам, разработанным компанией Microsoft. Например, могут встретиться LDAP или kerberos-cep-веры в реализациях, не принадлежащих Microsoft. Эти серверы также могут регистрировать записи SRV на сервере DNS. Контроллеры домена с Windows Server 2003 регистрируют как основные (generic) записи (например, _ldap._tcp.contoso.com), так и записи, содержащие ссылку на _msdcs. Они ссылаются только на роли, определенные продуктами Microsoft, т.е. на Windows Server 2003 или на контроллеры домена Windows 2000. Записи идентифицируют основную функцию каждого сервера: gc (глобальный каталог), dc (контроллер домена) или pdc (основной эмулятор контроллера домена).
Другая зарегистрированная запись содержит глобальный уникальный идентификатор (GUID globally unique identifier) домена. Запись GUID домена используется для поиска контроллеров домена в случае его переименования.
Примечание. Имеются записи, расположенные ниже поддоме-нов ForestDnsZones и DomainDnsZones. О них более подробно вы узнаете в разделе Раздел приложений каталога этой главы.
Поиск контроллера домена службы Active Directory Контроллеры домена, на которых выполняется Windows Server 2003, регистрируют некоторые (или все) записи, описанные выше. Эти записи играют важную роль, когда клиент, на котором выполняется система Windows 2000 или Windows XP Professional, пытается войти в домен. Далее описаны действия, которые выполняются при входе клиента в домен.
1. Во время входа пользователя компьютер клиента выполняет удаленный вызов процедуры (RPC) запроса местной сетевой службе входа в систему, которая инициирует сеанс входа в систему. Являясь частью RPC-запроса, клиент посылает такую информацию, как имя компьютера, имя домена и имя сайта, службе Net Logon (Вход в сеть).
2. Служба входа в сеть использует службу указателя доменов (domain locator), чтобы вызвать API-функцию DsGetDcName (), передающую одно из значений параметра флага, перечисленных в таблице 3-3.
Табл. 3-3. Значения параметра флага DsGetDcName Значения флага DsGetDcName Требуемая запись DNS DS_PDC_REQUIRED _ldap._tcp.pdc._msdcs.domainname DS_GC_SERVER_REQUIRED _ldap._tcp.sitename._sites.gc.
_msdcs.Forestrootdomainname DS_KDC_REQUIRED _kdc._tcp.sitename._sites.dc._msdcs.domainname DS_ONLY_LDAP_NEEDED _ldap._tcp.sitename._sites._ msdcs.domainname Примечание. Почти всегда функция DsGetDcName включает параметр sitename. Для всех запросов, кроме запроса DS_PDC_REQUIRED, клиент делает начальный запрос, используя параметр сайта. Если DNS-сервер не отвечает на запрос, клиент пошлет тот же самый запрос без параметра сайта. Например, если запрос DS_KDC_REQUIRED не выполнен, клиент пошлет запрос на запись _kdc._tcp.dc._msdcs.forestrootdomain. Это может случиться, если клиент находится на сайте, который не распознан серверами DNS. Клиент может также передать параметр DomainGUID вместо имени домена с помощью функции DsGetDcName (). В этом случае клиент запрашивает запись _ldap._tcp.domainGUID.domains._msdcs.forestname. Это случится только в том случае, если домен был переименован.
3. DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены. После отсылки каждого пакета клиент ждет в течение 0,1 с, если никакого ответа не получено, он посылает пакет следующему контроллеру домена. Клиент продолжает этот процесс до тех пор, пока не получит допустимый ответ или не перепробует все контроллеры домена.
4. Когда контроллер домена ответит клиенту, клиент проверяет ответ, чтобы удостовериться, что он содержит запрошенную информацию. Если информация имеется, клиент начинает процесс входа в систему с контроллера домена.
Клиент кэширует информацию контроллера домена, чтобы в следующий раз, когда ему потребуется обратиться к Active Directory, не нужно было снова проходить процесс обнаружения.
Как клиент определяет, какому сайту он принадлежит Наличие специфических для сайта записей важно для эффективной работы Active Directory, потому что поле деятельности клиента ограничено определенным сайтом. Например, в процессе входа в систему клиент всегда пробует соединиться с контроллером домена, расположенном в своем сайте, прежде чем соединяться с любыми другими сайтами. Как же клиент узнает, какому сайту он принадлежит?
Информация сайта для леса хранится в разделе конфигурации ката-, лога в Active Directory, она копируется на все контроллеры домена в лесу. Список IP-подсетей, которые связаны с определенным сайтом, включается в конфигурационную информацию. Когда клиент впервые входит в Active Directory, первый ответивший контроллер домена сравнивает IP-адрес клиента с IP-адресом сайта. Часть ответа контроллера домена клиенту составляет информация сайта, которую клиент затем кэширует. Любые последующие попытки входа в систему будут включать информацию сайта клиента.
Если клиент переместился между сайтами (например, портативный компьютер может быть подсоединен к сети в другом городе), он все еще посылает информацию сайта как часть входа в систему. DNS-сервер ответит с записью контроллера домена, который находится в запрашиваемом сайте. Однако если на основе нового IP-адреса клиента контроллер домена решит, что клиент не находится на первоначальном сайте, он пошлет новую информацию сайта клиенту. Затем клиент выполнит кэширование новой информации и попытается найти контроллер домена в правильной подсети.
Если клиент не находится ни в одном из сайтов, которые определены в Active Directory, то он не сможет выполнять запросы на специфическую для сайта информацию о контроллерах домена.
Интегрированные зоны Active Directory Одно из самых больших преимуществ выполнения DNS в операционной системе Windows Server 2003 заключается в использовании интегрированных зон (integrated zones) Active Directory.
Интегрированные зоны Active Directory дают множество преимуществ.
Х Зонная информация больше не хранится в зонных файлах на жестком диске DNS-сервера, она хранится в базе данных Active Directory. Это обеспечивает дополнительную защиту.
Х Процесс зонной передачи заменен репликацией Active Directory. Поскольку зонная информация хранится в Active Directory, то данные копируются через нормальный процесс репликации Active Directory. Это означает, что репликация происходит на уровне атрибутов так, что копируются только изменения зонной информации. Трафик репликации между сайтами можно сильно сжать, увеличив пропускную способность. Использование интегрированной зоны Active Directory дает возможность использовать разделы приложений для тонкой настройки репликации информации DNS.
Х Интегрированные зоны дают возможность конфигурирования DNS-сервера с несколькими хозяевами. Без Active Directory DNS может поддерживать только один основной сервер имен для каждого домена. Это означает, что все изменения в зонной информации должны быть сделаны на основном сервере имен, а затем переданы на дополнительные серверы имен. С интегрированными зонами Active Directory каждый DNS-сервер имеет перезаписываемую копию доменной информации, так что изменения зонной информации могут быть сделаны в любом месте в организации. Информация затем копируется на все другие серверы DNS.
Интегрированные зоны предлагают опцию безопасных обновлений. Если зона является интегрированной зоной Active Directory, вы можете сконфигурировать ее так, чтобы использовать только безопасные обновления. Это означает, что вы имеете больше контроля над тем, какие пользователи и компьютеры обновляют записи ресурсов в Active Directory.
Самым большим недостатком интегрированной зоны Active Directory является необходимость установки DNS на контроллере домена Windows Server 2003, что создает дополнительную нагрузку на него.
Совет. Возможно соединение интегрированных зон Active Directory с дополнительными.
Например, можно иметь три контроллера домена в центральном месте и несколько отдаленных офисов, в которых отсутствует контроллер домена. Если вы хотите иметь DNS-сервер в отдаленном офисе, вы можете установить DNS на сервере, на котором выполняется система Windows Server 2003, а затем сконфигурировать дополнительную зону на сервере DNS. Тогда дополнительный сервер будет принимать зонные передачи от интегрированной зоны Active Directory.
Когда зона сконфигурирована как интегрированная зона Active Directory, вы может просматривать информацию DNS в Active Directory (см. рис. 3-6). Для этого запустите консоль управления Microsoft (MMC -Microsoft Management Console) и убедитесь, что оснастка Active Directory Users And Computers (Пользователи и компьютеры Active Directory) была добавлена к консоли. Выберите папку Active Directory Users And Computers (Пользователи и компьютеры Active Directory) из меню View (Вид), выберите Advanced Features (Дополнительные свойства). Откройте папку с именем домена, затем откройте папку System (Система), затем - папку Microsof tDNS. Зонная информация для всех интегрированных зон Active Directory перечислена в каждой зонной папке.
Рис. 3-6. Просмотр информации интегрированной зоны Active Directory Практический опыт. Разрешение имен DNS без усовершенствованной службы DNS Windows Server Корпорация, состоящая из четырех различных компаний, каждая из которых была независимой до момента слияния, планировала развертывание Active Directory в системе Windows 2000 Advanced Server. Каждая компания настаивала на поддержке собственного пространства имен в пределах одного леса;
это означало, что должен быть развернут лес с назначенным (dedicated) корневым доменом и четырьмя доменами компании (см. рис. 3-7). Все компании были расположены в разных городах в Канаде.
Рис. 3-7. Проект леса Active Directory с несколькими деревьями Поскольку смежного пространства имен для всей компании не существовало, нормальный процесс делегирования дочерних доменов не применялся. Процесс конфигурирования ретрансляторов и корневых ссылок также оказался неэффективным, потому что не является достаточно отказоустойчивым. Например, если кому-то из Contoso.com требовалось найти ресурс в домене Fabrikam.com, клиент должен был запрашивать DNS-сервер Contoso. Поскольку сервер не был полномочным сервером для домена Fabrikam, он должен был разрешить имя, используя корневую ссылку или ретранслятор. Если DNS-сервер Contoso был сконфигурирован с ретранслятором на DNS-сервер в домене Fabrikam, имя могло быть разрешено. Однако эта запись ретранслятора не могла использоваться для разрешения компьютерных имен в домене TailspinToys.com или во внутренней сети.
Использование системы DNS Windows 2000 предложило несколько путей решения этой проблемы (см. ниже), но ни один из них не был достаточно удовлетворительным.
Х Создание дополнительной зоны на каждом сервере DNS для каждого из других доменов привело бы к возрастанию трафика зонной передачи.
Х Создание дополнительной зоны для каждого домена компании на серверах DNS в корневом домене и конфигурирование всех DNS-серве-ров домена так, чтобы они направляли запросы к серверам DNS корневого домена, создало бы существенную нагрузку на серверах DNS корневого домена.
Кроме того, поскольку все серверы DNS корневого домена были расположены в одном центре данных, разрешение имен привело бы к возрастанию сетевого трафика из других офисов.
Ни одно из этих решений не идеально. Операционная система Windows Server предлагает три варианта решения. В них используются условная переадресация, сокращенные зоны (stub zones) и разделы приложений каталога.
Совершенствование DNS Большинство опций DNS, которые обсуждались до этого, доступны в Windows 2000. В операционной системе Windows Server 2003 имеется, по крайней мере, три существенных улучшения DNS. Описание практического опыта (см. выше) иллюстрирует одну из типичнейших трудностей в конфигурировании DNS большой корпорации, с которой сталкивались администраторы до выхода операционной системы Windows Server 2003.
Условная переадресация Условная переадресация (conditional forwarding) значительно увеличивает возможности процесса переадресации. До выхода Windows Server 2003 в процессе переадресации нельзя было делать различий, основанных на именах домена. Когда клиент-преобразователь делал запрос, на который сервер не мог ответить с помощью своего кэша или зонных файлов, сервер посылал рекурсивный запрос по своему списку конфигурированных ретрансляторов. Не было возможности сконфигурировать ретранслятор так, чтобы он был чувствителен к специфике домена. Условная переадресация обеспечивает как раз такой тип осмысления: DNS-cep-вер может теперь передавать запросы домена на различные серверы DNS, учитывая имя домена.
Например, компания, о которой шла речь выше, имеет пять деревьев в единственном лесу. При репликации контроллеры домена должны суметь найти контроллеры домена в других доменах.
Пользователи также часто путешествуют между компаниями. Они должны иметь возможность входить на свой домашний домен независимо от того, с какой сетью они связаны физически.
Существует также значительное количество ресурсов, сконфигурированных для совместного использования между компаниями. Эти требования подразумевают, что информация DNS должна быть общедоступной для разных доменов.
С помощью Windows Server 2003 серверы DNS в каждом домене могут быть сконфигурированы с условным ретранслятором, переадресующим запросы на один или более серверов DNS в других доменах. Когда один из серверов DNS разрешает имя из другого домена, он может использовать только тот ретранслятор, который сконфигурирован для этого домена. Например, когда клиент в домене Contoso.com должен найти ресурс в домене Fabrikam.com, он делает запрос DNS-серверу домена Contoso.com. DNS-сервер проверяет свои зонные файлы, чтобы определить, является ли он полномочным сервером для этого домена, а затем проверяет свой кэш. Если он не сможет разрешить имя с помощью этих источников, он проверит список ретрансляторов. Один из ретрансляторов определен для домена Fabrikam.com, так что DNS-сервер Contoso.com пошлет рекурсивный запрос только этому серверу DNS. Если нет никаких условных ретрансляторов для домена Fabrikam.com, сконфигурированных на сервере DNS Contoso.com, то он отправит запрос любому ретранслятору, который сконфигурирован без каких-либо определенных параметров настройки домена, а затем попробует использовать корневые ссылки.
Предостережение. Обратите внимание, что DNS-сервер проверяет свои собственные зонные файлы, прежде чем использовать ретрансляторы. Если DNS-сервер является полномочным для данного домена, он не будет отправлять запрос условному ретранслятору.
Условная переадресация конфигурируется в окне Properties (Свойства) сервера в административном инструменте DNS (см. рис. 3-8). С его помощью вы можете сконфигурировать один или более контроллеров домена в качестве ретрансляторов для каждого имени домена. Если вы конфигурируете несколько серверов DNS для имени домена, то DNS-сервер будет пытаться использовать первый DNS-сервер в списке. Если этот сервер не отвечает в течение заданного значения интервала тайма -ута, которое устанавливается на вкладке Forwarders (Ретрансляторы), то сервер будет пробовать использовать следующий DNS-сервер из списка, пока не будут запрошены все имеющиеся в списке DNS-серверы. Если никаких условных ретрансляторов, сконфигурированных для имени домена, в списке нет, то сервер будет запрашивать серверы DNS, определенные в опции All Other DNS Domains (Другие домены DNS).
Рис. 3-8. Конфигурирование условных ретрансляторов При использовании условной переадресации DNS-сервер всегда будет пробовать найти соответствие наиболее точному имени домена. На пример, если имеются условные ретрансляторы, сконфигурированные для Fabrikam.com и для Europe.Fabrikam.com, а клиент делает запрос о сервере Webl.Europe.Fabrikam.com, то DNS-сервер отправит запрос на DNS-сервер для Europe.Fabrikam.com.
Сокращенные зоны Сокращенные зоны (stub zones) - это второе улучшение к службе DNS в Windows Server 2003. Они предназначены для упрощения конфигурирования разрешения имен между несколькими пространствами имен. Сокращенная зона подобна дополнительной зоне. При установлении сокращенной зоны вы должны определить IP-адрес основного сервера имен для зоны. Тогда сервер, владеющий сокращенной зоной, запрашивает зонную передачу у основного сервера имен.
Однако сокращенная зона отличается от дополнительной тем, что она содержит только записи SOA, NS и записи хоста (А) для сервера имен домена, а не все записи зоны.
Это улучшает процесс разрешения имен без необходимости использовать дополнительные серверы. Когда DNS-сервер сконфигурирован с сокращенной зоной, он не является полномочным для домена. Он эффективен при поиске полномочного сервера имен для указанной зоны. С помощью дополнительных зон DNS-сервер может найти полномочный сервер имен для зоны без необходимости контактировать с серверами корневых ссылок. Обратите внимание, как дополнительная зона может работать в лесу с одним деревом, т.е. с непрерывным пространством имен (см. рис. 3-9). Без дополнительных зон в случае запроса клиента из NAmerica.Contoso.com IP адреса хоста в домене SAmerica.Contoso.com DNS сервер в NAmerica. Contoso.com проверяет свои зонные файлы, кэш и ретрансляторы. Если ни один из этих источников не обеспечивает нужную информацию, он посылает итерационный запрос серверу корневых ссылок. В этом случае DNS сервер в корневом домене Contoso.com должен быть сконфигурирован как корневой сервер, чтобы DNS-сервер домена NAmerica. Contoso.com послал запрос ему. Корневой сервер проверяет свои записи делегирования и передает IP-адрес полномочного сервера имен домена SAmerica.Contoso.com серверу имен NAmerica. Contoso.com. Затем сервер имен NAmerica.
Contoso.com запрашивает у одного из серверов DNS домена SAmerica. Contoso.com IP-адрес сервера, который требуется клиенту.
Если имеется сокращенная зона, DNS-сервер домена NAmerica. Contoso.com не должен соединяться с сервером DNS корневого домена. Ему не нужно использовать свои корневые ссылки, чтобы найти сервер имен для домена SAmerica.Contoso.com. Когда клиент делает запрос, сервер проверяет свои зонные файлы, находит сокращенную зону и посылает итерационный запрос любому из серверов имен домена SAmerica. Contoso.com.
Использование сокращенной зоны особенно эффективно при наличии нескольких деревьев.
Возьмем предыдущий пример, в котором лес состоит из пяти деревьев. Использование записей делегирования в корневой зоне в этом случае не работает, потому что домены не используют общего пространства имен. Вы можете сконфигурировать сокращенную зону для каждого домена на серверах DNS в других доменах. Если в этом случае какой-либо запрос DNS нуждается в информации из другого домена, DNS-сервер может использовать информацию сокращенной зоны, чтобы немедленно соединиться с сервером имен в другом домене.
Рис. 3-9. Конфигурация DNS с одним лесом без использования сокращенной зоны Сокращенная зона поддерживает список серверов имен для делегированных зон. Когда вы устанавливаете делегированный поддомен, вы должны ввести IP-адреса всех серверов имен в делегированный домен. Если этот список серверов имен изменяется, например, один из серверов имен удален из сети, вам придется вручную обновить запись делегирования. Вы можете использовать сокращенную зону, чтобы автоматизировать процесс обновления списка серверов имен. Чтобы сделать это в домене Contoso.com, вы можете сконфигурировать сокращенную зону для домена NAmerica.Contoso.com на серверах DNS домена Contoso.com. Вы также можете сконфигурировать запись делегирования в зоне Contoso.com, указывающую на сокращенную зону.
Когда записи сервера имен изменятся в дочернем домене, они будут автоматически обновлены в сокращенной зоне. Когда серверы DNS Contoso.com будут использовать запись делегирования, они получат ссылку на сокращенную зону, так что у них всегда будет доступ к обновленной информации сервера имен.
Чтобы сконфигурировать сокращенную зону, используйте New Zone Wizard (Мастер новой зоны) в инструменте администрирования DNS. Щелкните правой кнопкой мыши на Forward Lookup Zones (Прямая зона просмотра) или на Reverse Lookup Zones (Обратная зона просмотра)) и выберите New Zone (Новая зона). Появится опция создания сокращенной зоны (см. рис. 3-10).
Рис. 3-10. Создание новой сокращенной зоны Раздел приложений каталога Третье улучшение DNS, помогающее разрешению имен хоста между несколькими доменами, состоит в использовании раздела приложений каталога.
DNS в Active Directory Windows Server 2003 использует раздел приложений каталога для облегчения репликации информации DNS в лесу. При установке DNS, когда вы назначаете первый сервер в лесу на роль контроллера домена, в Active Directory создаются два новых раздела каталога. Это разделы DomainDnsZones и ForestDnsZones. (Их не видно ни в одном из обычных инструментальных средств управления Active Directory, они отображаются при использовании ADSI Edit или Ldp.exe;
использование ADSI Edit показано на рисунке 3-11.) Каждый из этих разделов хранит разную конфигурацию репликации. Раздел DomainDnsZones реплицируется на все серверы DNS, выполняющиеся на контроллерах домена. Раздел ForestDnsZones реплицируется на все серверы DNS, выполняющиеся на контроллерах домена в лесу. Вы можете хранить информацию DNS в разделе каталога домена, т.е. она будет копироваться на все контроллеры домена в домене.
Необходимо выбрать место хранения информации DNS при создании новой зоны (см. рис. 3-12) в окне Zone Properties (Свойства зоны) в инструменте администрирования DNS. Имеются четыре варианта хранения информации DNS.
Х То All DNS Servers In The Active Directory Forest domainname (Ha все серверы DNS леса Active Directory). Информация хранится в разделе ForestDnsZones, откуда копируется на все серверы DNS контроллеров домена леса. Эта конфигурация задана по умолчанию для зоны _msdcs в интегрированной зоне Active Directory.
Рис. 3-11. Раздел приложений каталога DNS в инструменте ADSI Edit Х То All DNS Servers In The Active Directory Domain domainname (Ha все серверы DNS в домене Active Directory). Информация хранится в разделе DomamDnsZones, откуда копируется на все серверы DNS, выполняющиеся на контроллерах домена. Это конфигурация, принятая по умолчанию для интегрированной зоны Active Directory, созданной в процессе обновления контроллера домена.
Х То All Domain Controllers In The Active Directory Domain domainname (На все контроллеры домена в домене Active Directory). Информация хранится в разделе домена каталога, откуда копируется на все контроллеры домена. Различие между этой опцией и предыдущей состоит в том, что в этом случае все контроллеры домена получат информацию, в то время как раздел DomamDnsZones реплицируется только на контроллеры домена, являющиеся серверами DNS.
Х То All Domain Controllers Specified In The Scope Of The Following Application Directory Partition (На все контроллеры домена в пределах следующего раздела приложений каталога). Эта опция доступна только в том случае, если вы создаете дополнительный раздел приложений каталога с его собственной конфигурацией репликации. Информация DNS будет копироваться на все контроллеры домена, которые имеют реплику этого раздела.
Примечание. Раздел приложений каталога для DNS создается только в том случае, если выбрана установка DNS при назначении первого контроллера домена или леса. Если вы хотите воспользоваться преимуществами раздела приложений каталога для DNS после того, как обновили контроллер домена, необходимо вручную создать раздел перед его использованием. Для создания раздела применяется инструмент администрирования DNS или инструмент командной строки DNSCMD. При использовании инструмента администрирования DNS щелкните правой кнопкой мыши на имени сервера DNS и выберите Create Default Application Directory Partitions (Создание заданных по умолчанию разделов приложений каталога). При использовании инструмента DNSCMD откройте командную строку и напечатайте dnscmd DN S servername/CreateBuiltin-DirectoryPartitions /forest. В результате будет создан раздел ForestDnsZones. Чтобы создать раздел DomainDnsZones, используйте л/domain в качестве последнего параметра в команде. Поскольку эта команда изменяет раздел конфигурации каталога в Active Directory, вы должны входить в систему как член группы Enterprise Admins (Администраторы предприятия).
Рис. 3-12. Конфигурирование области репликации для зон DNS Обычно заданная по умолчанию конфигурация зон не изменяется. При наличии нескольких контроллеров домена в домене, причем только некоторые из них являются серверами DNS, использование раздела DomainDnsZones уменьшает количество репликаций на контроллеры домена, которые не являются серверами DNS. Зона _msdcs для каждого домена, которая включает только информацию о серверах Active Directory в домене, хранится в разделе ForestDnsZones. Эта информация реплицируется по всему лесу.
Резюме Служба DNS является необходимой сетевой службой для сетей Windows Server 2003. Без нее практически любой вход в систему и усилия по поиску расположения ресурсов потерпят неудачу в Windows Server 2003. Как сетевой администратор вы должны стать экспертом по службе DNS. В данной главе был дан краткий обзор того, как работает DNS в качестве сетевой службы в любой среде, показана специфика интеграции DNS с Active Directory. Наиболее важным компонентом интеграции является процесс поиска контроллера домена, при котором контроллеры домена в Active Directory регистрируют записи SRV в DNS, а затем клиенты используют эти записи для поиска контроллеров домена. Кроме того, было приведено описание некоторых улучшений DNS в Windows Server 2003.
Глава 4. Репликация Active Directory и сайты Каждая компания, реализующая службу каталога Active Directory Microsoft Windows Server 2003, развертывает несколько контроллеров домена. Они могут располагаться в одном центре обработки данных в главном офисе компании и связываться высокоскоростными сетевыми соединениями.
Они могут быть распределены по всему миру и использовать для связи глобальные сети (WAN).
Некоторые компании имеют единственный домен в лесу, другие компании - много доменов в нескольких доменных деревьях в общем лесу.
Независимо от того, сколько контроллеров домена имеет компания и где они расположены, контроллеры домена должны реплицировать информацию друг у друга. Если они не будут делать этого, каталоги на контроллерах станут противоречивыми. Например, если на одном контроллере домена будет создан пользователь и эта информация не скопируется на все другие контроллеры домена, то этот пользователь сможет входить только на один контроллер домена.
Служба Active Directory использует модель репликации с несколькими хозяевами, в которой изменения в каталоге могут быть сделаны на любом контроллере домена и скопированы на другие контроллеры. В данной главе описывается процесс репликации в Active Directory. Глава рассказывает о том, как работает репликация, как создается топология репликации, и как контроллеры домена копируют информацию друг у друга.
Модель репликации Active Directory В главе 2 говорилось о том, что Active Directory состоит из нескольких логических разделов.
Репликация информации между контроллерами домена с репликами всех разделов осуществляется одинаково для всех разделов. Когда изменяется атрибут в разделе конфигурации каталога, он реплицируется так же, как и в случае изменения атрибута любого другого раздела. Единственное отличие состоит в списке контроллеров домена, которые получат копию реплицируемого изменения. Репликация между контроллерами домена в одном и том же сайте обрабатывается иначе, чем между контроллерами домена различных сайтов, но основная модель не изменяется. В этом разделе описывается модель репликации, которая используется в Active Directory.
В отличие от модели репликации с единственным хозяином, которая используется в системе Microsoft Windows NT, Active Directory использует модель репликации с несколькими хозяевами.
В Windows NT основной контроллер домена (PDC Ч Primary Domain Controller) является единственным контроллером домена, который может принимать изменения информации домена.
После того как изменение сделано, оно реплицируется на все резервные контроллеры домена (BDC Ч Backup Domain Controllers). Недостатком модели репликации с единственным хозяином является то, что она не масштабируется для большой распределенной среды. Поскольку изменения (например, пароля пользователя) могут выполняться только на контроллере PDC, это может стать узким местом, если делаются сразу тысячи изменений. Контроллер PDC находится только в одном месте компании, и любые изменения информации домена, расположенного в удаленном месте, должны быть сделаны на этом контроллере PDC. Другая проблема заключается в том, что контроллер PDC является единственной точкой отказа. Если он недоступен, никаких изменений информации каталога сделать нельзя до тех пор, пока он не вернется в интерактивный режим или пока другой BDC-контроллер не будет назначен на роль контроллера PDC.
В Active Directory изменения информации домена могут быть сделаны на любом контроллере домена, т.е. каждый контроллер домена имеет перезаписываемую копию каталога, а контроллера PDC не существует. Как только изменение было сделано, оно копируется на все другие контроллеры домена. Такая модель репликации с несколькими хозяевами направлена на повышение надежности и масштабируемости, ведь изменения в каталоге можно делать на любом контроллере домена независимо от того, где он расположен. Поскольку все контроллеры домена обеспечивают одни и те же службы, отказ одного их них не является критичным для всей системы.
Примечание. В главе 2 говорилось о том, что в Active Directory имеются определенные роли хозяев операций, которые могут выполняться только одним контроллером домена. Эти роли представляют собой критическую точку отказа системы, но их можно легко передавать на другой контроллер домена.
Модель репликации, используемая в Active Directory, представляет модель с нежестким согласованием, обладающую сходимостью. Репликация не является жестко согласованной, так как контроллеры домена, содержащие реплику раздела, не всегда имеют идентичную информацию.
Например, если новый пользователь создан на одном из контроллеров домена, другие контроллеры домена не получат эту информацию до следующего цикла репликации. Процесс репликации всегда сходится, т.е. если система поддерживается в стационарном состоянии, без внесения новых изменений к каталогу в течение некоторого времени, то все контроллеры домена достигнут единообразного состояния и будут иметь идентичную информацию.
При репликации используется также процесс хранения и ретрансляции (store and forward). Это означает, что контроллер домена может получать изменение к каталогу, а затем отправлять его на другие контроллеры домена. Это выгодно в тех случаях, когда несколько контроллеров домена, находящихся в разных офисах компании, соединены медленными WAN-соединениями. Изменение к каталогу может реплицироваться с контроллера домена одного из сайтов на единственный контроллер домена второго сайта. Контроллер домена, который получает обновление, может затем переправить изменения на другие контроллеры домена во втором сайте. Контроллер домена, на котором были сделаны изменения каталога, не должен копировать изменения непосредственно на все контроллеры домена, как это имеет место в модели репликации с единственным хозяином.
Улучшение репликации Active Directory Windows Server Модель репликации Active Directory Windows Server 2003, по существу, совпадает с той, которая используется в системе Microsoft Windows 2000, но имеет ряд существенных улучшений.
Х Частичная репликация атрибутов, имеющих несколько значений. В системе Windows атрибут являлся самой маленькой единицей репликации. В некоторых случаях изменение одного из нескольких значений в атрибуте может создавать существенный трафик репликации. Типичный пример такой ситуации связан с универсальным членством группы. Поскольку полный список членства для универсальной группы является одним атрибутом, то добавление одного пользователя к универсальной группе приводит к значительной репликации, особенно когда группа уже содержит несколько тысяч членов. В Active Directory Windows Server 2003 атрибуты, имеющие несколько значений, подобные членству группы, могут быть обновлены путем репликации только модифицированного значения атрибута.
Х Поддержка групп, содержащих более 5000 членов. В системе Windows 2000 группы не могут содержать более 5000 членов из-за того, что репликации модификаций выполняется на уровне атрибутов. Практический предел передачи изменений в базу данных каталога в одной транзакции составляет 5000 значений. Этот предел определяет максимальное количество обновлений, которые могут реплицироваться в процессе одной репликации. В Active Directory Windows Server поддержка модификаций только одного значения для объектов, имеющих несколько значений, снимает эти ограничения.
Примечание. Описанные выше преимущества доступны только в том случае, если домен работает на функциональном или на временном (interim) функциональном уровне Windows Server 2003. Функциональный уровень Windows Server 2003 доступен только тогда, когда на всех контроллерах домена в лесу выполняется Windows Server 2003. Временный функциональный уровень Windows Server 2003 доступен в том случае, когда лес содержит контроллеры домена, на которых выполняются Windows Server 2003 и Windows NT. Для получения дополнительной информации о функциональных уровнях см. гл. 7.
Х Возможность отключать сжатие при репликации между сайтами. По умолчанию весь трафик репликации между сайтами сжимается как для Active Directory Windows 2000, так и для Active Directory Windows Server 2003. Это дает дополнительную нагрузку на процессор контроллера домена. Однако при наличии достаточной пропускной способности между сайтами сжатие в Active Directory Windows Server 2003 можно отключать.
Х Возможность уведомлений для репликации между сайтами. По умолчанию репликация между сайтами производится по графику с заданной частотой, сконфигурированной на связях сайта. В Active Directory Windows Server 2003 имеется опция, позволяющая включать уведомления для репликации между сайтами. Если уведомления включены, то сервер-плацдарм (bridgehead server) того сайта, где произошло изменение, уведомляет об этом сервер-плацдарм сайта адресата, и изменения передаются по связям сайта. Нотификация может значительно уменьшать время ожидания репликаций между сайтами, но при этом значительно увеличивается сетевой трафик.
Примечание. Чтобы отключить сжатие или включить процедуру уведомлений для репликации между сайтами, используется инструмент ADSI Edit для модификации атрибута Options (Опции) объекта-соединения сайта (site link object) или объекта-связи (connection object). Чтобы выключить сжатие, установите значение атрибута Options (Опции) равным четырем;
чтобы включить уведомления, установите это значение равным единице.
Х Улучшенная генерация топологии между сайтами. В системе Windows 2000 размер организации имел ограничение в 100 сайтов в лесу. Это ограничение связано со временем, которое требуется службе КСС (Knowledge Consistency Checker Ч модуль проверки целостности сведений), для того чтобы вычислить топологию маршрутизации для такого количества сайтов. Это ограничение в Active Directory Windows Server 2003 снято.
Внутренняя и внешняя репликация между сайтами Одна из главных причин создания дополнительных сайтов в Active Directory состоит в том, чтобы иметь возможность управления трафиком репликации. Поскольку предполагается, что все контроллеры домена в пределах сайта связаны высокоскоростными соединениями, то репликация между ними оптимизируется для получения максимальной скорости и уменьшения времени ожидания. Однако если трафик репликации пересекает низкоскоростное соединение, то сохранение пропускной способности сети становится серьезной проблемой. Создание нескольких сайтов позволяет сохранять пропускную способность сети.
Совет. Если вы работали с Microsoft Exchange Server 5.5 или более ранней версией, различия процессов репликации внутри и между сайтами вам знакомы. Служба Active Directory использует многие принципы управления репликацией в Exchange Server 5.5.
Репликация внутри сайта Основная цель репликации внутри сайта состоит в уменьшении времени ожидания репликации, т.е. все контроллеры домена сайта должны обновляться настолько быстро, насколько это возможно. Трафик внутренней репликации характеризуется следующим.
Х Репликация происходит сразу после того, как произошло изменение информации Active Directory. По умолчанию контроллер домена ожидает 15 с после того, как изменение было сделано, а затем начинает копировать это изменение на другие контроллеры домена в сайте. После завершения репликации с одним партнером контроллер домена ожидает 3 с, а затем начинает репликацию с другим партнером. Ожидание в 15 с необходимо для увеличения эффективности репликации в случае, если к информации раздела будут сделаны дополнительные изменения. Продолжительность периода ожидания может быть изменена через системный реестр Windows 2000 или Windows Server 2003 (обратитесь к соответствующим разделам в комплекте ресурсов Resource Kits за подробностями). На функциональном уровне Windows Server 2003 это значение можно изменить для каждого раздела каталога, используя инструмент ADSI Edit.
Х Трафик репликации не сжат. Поскольку все компьютеры в пределах сайта связаны высокоскоростными соединениями, данные посылаются без сжатия. Сжатие данных репликации добавляет дополнительную нагрузку на сервер контроллера домена. При отсутствии трафика репликации производительность сервера сохраняется за счет использования сети.
Х Процесс репликации инициируется в соответствии с уведомлением, пришедшим от контроллера-отправителя. После изменения в базе данных компьютер-отправитель обновлений уведомляет контроллер домена адресата о том, что произошло обновление.
Контроллер домена адресата забирает изменения с помощью процедуры удаленного вызова (RPC). После окончания репликации контроллер-отправитель уведомляет другой контроллер домена адресата, который также забирает изменения. Этот процесс продолжается до тех пор, пока все партнеры по репликации не будут обновлены.
Х Трафик репликации посылается нескольким партнерам в течение каждого цикла репликации. После любого изменения каталога контроллер домена будет копировать информацию всем прямым партнерам по репликации;
это могут быть все контроллеры домена в сайте или только некоторые из них.
Х Изменить трафик репликации в пределах сайта нетрудно. Можно сконфигурировать объекты-связи вручную через инструмент администрирования Active Directory Sites And Services (Сайты и службы Active Directory), изменить некоторые значения (например, начальное уведомление партнера по репликации) через системный реестр (обратитесь к соответствующим разделам документа Resource Kits за подробностями) или через объект Partition (Раздел), если ваш лес работает на функциональном уровне Windows Server 2003.
Но в большинстве случаев этого делать не придется.
Х Репликация между сайтами Основная цель репликации между сайтами состоит в том, чтобы уменьшить нагрузку на сеть, которая происходит из-за трафика репликации. Трафик репликации между сайтами характеризуется следующим.
Х Репликация инициируется согласно графику, а не тогда, когда сделаны изменения. Чтобы управлять репликацией между сайтами, нужно сконфигурировать канал связи, соединяющий эти сайты. Одной из опций является время, когда будут происходить репликации. Другая опция устанавливает интервал, показывающий то, как часто будут происходить репликации в течение намеченного времени. Если пропускная способность сети, соединяющей офисы компании, ограничена, репликации может быть намечена на нерабочие часы.
Х Трафик репликации сжимается приблизительно на 10 - 15 процентов от первоначального размера, если он составляет свыше 32 Кб. Чтобы сохранить пропускную способность сети, серверы-плацдармы каждого сайта сжимают трафик за счет дополнительного использования процессора.
Х Для предупреждения контроллеров домена другого сайта об изменениях каталога уведомления не используются. Вместо этого время репликации определяется по расписанию.
Х Подключения, которые выполняют репликацию между сайтами, могут использовать протокол интернета (IP) или протокол электронной почты (SMTP). Протокол, который используется при подключении, определяется пропускной способностью и надежностью сети, которая связывает разные офисы компании.
Х Трафик репликации посылается не партнерам по репликации, а через серверы-плацдармы.
Изменения каталога сайта реплицируются на единственный сервер-плацдарм (один на каждый раздел каталога) этого сайта, а затем Ч на сервер-плацдарм другого сайта. Далее изменения реплицируются с сервера-плацдарма второго сайта на все контроллеры домена этого сайта.
Х Вы можете легко изменять поток репликации между сайтами, изменяя практически каждый компонент репликации.
Планирование. Ключевым моментом в проектировании Active Directory является планирование количества сайтов и их месторасположения, конфигурирование подключений между сайтами, которые должны оптимизировать пропускную способность сети при уменьшении времени ожидания репликации. Опции конфигурирования подключений между сайтами обсуждаются далее в этой главе, а проблемы, связанные с проектированием структуры сайта, Ч в главе 5.
Время ожидания репликации Репликация в Active Directory Windows Server 2003 реализована таким образом, что копирование на другие контроллеры домена изменений, сделанных на одном из контроллеров, может занимать некоторое время. Эта временная задержка называется временем ожидания репликации (replication latency). В большинстве случаев время ожидания репликации легко вычислить, особенно в пределах сайта. Как уже говорилось, любое изменение, сделанное в базе данных каталога на одном из контроллеров домена, будет копироваться партнерам по репликации приблизительно через 15 с. Контроллер домена адресата задержит это изменение на 15 с, а затем передаст его своим партнерам по репликации. Время ожидания репликации в пределах сайта приблизительно равно 15-ти секундам, умноженным на количество ретрансляций, которые потребуются, прежде чем информация достигнет всех контроллеров домена. Топология репликации в пределах сайта никогда не требует более трех ретрансляций, так что максимальное время ожидания репликации в пределах сайта составляет примерно 45 с.
Определить время ожидания репликации между сайтами несколько труднее. Прежде всего, вы должны вычислить время ожидания репликации в пределах исходного сайта. Это то время, которое потребуется для копирования изменений, сделанных на контроллере домена сайта источника, на сервер-плацдарм того же сайта. Как только информация достигнет сервера плацдарма сайта-источника, время, которое потребуется информации для попадания на сайт адресата, определяется расписанием связи этого сайта и интервалом между репликациями. По умолчанию репликации выполняются каждые 3 часа в течение дня. Если это значение не изменено, то эти 3 часа можно добавить ко времени ожидания репликации. Когда информация достигает сервера-плацдарма на сайте адресата, то к общему времени ожидания нужно добавить еще и время ожидания репликации внутри сайта для сайта адресата. В некоторых случаях полученное время ожидания может быть достаточно велико. Чтобы уменьшить его, необходимо сократить интервал репликаций между сайтами до 15 минут (минимальное значение).
Управление временем ожидания репликаций предполагает балансирование между потребностью в коротком времени ожидания и ограничением пропускной способности сети. Если требуется очень короткое время ожидания, все контроллеры домена должны быть помещены в один и тот же сайт, в этом случае оно будет равняться примерно 45 с для всех контроллеров домена. Однако если офисы вашей компании соединены WAN-связями с ограниченной пропускной способностью, вам потребуется несколько сайтов, и время ожидания репликаций увеличится.
Срочная репликация Иногда время ожидания репликации может оказаться слишком большим, например, когда в каталоге меняется атрибут, связанный с защитой. Для этих ситуаций Active Directory использует срочную репликацию (urgent replication), при которой контроллер домена передает изменения своим партнерам по репликации немедленно. Любой контроллер домена, получивший срочное обновление, отправит изменение немедленно. Таким образом, все контроллеры домена в сайте обновят информацию в течение нескольких секунд. Срочные репликации могут быть вызваны следующими типами изменений.
Х Изменение политики блокировки учетных записей для домена.
Х Изменение политики паролей домена.
Х Перемещение роли хозяина относительного идентификатора (RID) на новый контроллер домена.
Х Изменение безопасности локальных средств защиты (LSA - Local Security Authority), например, когда изменяется пароль компьютера контроллера домена.
По умолчанию срочные обновления применяются только к внутренней репликации и не применяются к репликации между сайтами. Политика применения срочных обновлений может быть изменена путем разрешения уведомлений для репликации между сайтами.
Пользовательские изменения пароля реплицируются по другой модели. Когда пользователь изменяет пароль на контроллере домена, это изменение немедленно копируется прямо в PDC-эмулятор. Эта репликация пересекает границы сайта и не использует серверы-плацдармы сайтов. Вместо этого контроллер домена, на котором было сделано изменение, для обновления пароля использует RPC-подключение к PDC-эму-лятору.
Затем PDC-эмулятор обновляет все другие контроллеры домена через нормальный процесс репликации. Если пользователь попытается войти на контроллер домена, который еще не получил новый пароль, контроллер домена, прежде чем отклонить вход в систему, проверит PDC-эмулятор, на предмет наличия обновлений, касающихся изменения пароля этого пользователя.
Генерация топологии репликации Ключевым моментом репликации в Active Directory является создание топология репликации. По умолчанию процесс создания топологии репликации обрабатывается автоматически службой Active Directory. Можно сконфигурировать топологию репликации вручную, но в большинстве случаев конфигурация, заданная системой по умолчанию, является наилучшим вариантом.
Проверка целостности сведений (Knowledge Consistency Checker) КСС (Knowledge Consistency Checker) Ч это процесс, который выполняется на каждом контроллере домена, он ответствен за создание топологии репликации в пределах сайта и между сайтами. Как только к лесу Active Directory добавляется второй контроллер домена, служба КСС начинает создавать топологию репликации, которая является и эффективной, и терпимой к ошибкам. По мере добавления к сайту других контроллеров домена или новых сайтов КСС использует информацию о серверах, сайтах, связях сайта и расписаниях для создания оптимальной топологии репликации. Служба КСС динамически анализирует изменения или отказы, возникающие в пределах топологии репликации. Если один из контроллеров домена временно находится в автономном режиме, то КСС пересматривает топологию репликации, чтобы обойти неработающий контроллер домена. По умолчанию КСС каждого контроллера домена повторно вычисляет топологию репликации каждые 15 минут. Имеется возможность в любое время повторно вычислить топологию репликации с помощью инструмента администрирования Active Directory Sites And Services (Сайты и службы Active Directory). Найдя сервер, на котором вы хотите проверить топологию репликации, и щелкнув правой кнопкой мыши на NTDS Settings (Параметры настройки NTDS) в контейнере сервера, выберите опцию All Tasks (Все задачи), затем выберите Check Replication Topology (Проверить топологию репликации).
Объекты связи При создании топологии репликации служба КСС создает ряд объектов связи (connection object), которые хранятся в разделе конфигурации каталога Active Directory. Объекты связи являются прямыми логическими соединениями между контроллерами домена, которые используются для репликации информации каталога. Как уже говорилось, КСС создает топологию репликации, которая является эффективной и терпимой к ошибкам. КСС строит столько объектов связи, сколько для этого требуется.
Объекты связи всегда создаются как односторонние pull (лтянущие) соединения между двумя контроллерами домена, потому что нормальный процесс репликации является pull-операцией, в которой контроллер-адресат запрашивает данные у контроллера-отправителя информации. В большинстве случаев КСС строит два односторонних соединения между контроллерами домена так, чтобы информация могла реплицироваться в обоих направлениях.
Примечание. С помощью инструмента Replication Monitor (Монитор репликации) вы можете создать push (лтолкающую) репликацию для раздела каталога. Нормальный процесс репликации всегда является pull-операцией. (Смотрите детали, касающиеся установки и использования монитора репликации в разделе Мониторинг и поиск неисправностей при репликации далее в этой главе.) В большинстве случаев объекты связи, автоматически созданные КСС, оптимизированы, и вам не нужно делать никаких изменений. Однако, в некоторых случаях вы, возможно, захотите их изменить. Например, вы пожелаете, чтобы контроллеры домена хозяев операций всегда были прямыми партнерами по репликации тех контроллеров домена, которых вы назначили резервными хозяевами операций на случай отказа основного хозяина. Создавая соглашение о подключении, вы можете гарантировать оптимальную топологию репликации для некоторого определенного набора контроллеров домена.
Вы можете изменить заданные по умолчанию объекты связи двумя способами: изменяя некоторые параметры настройки на объектах связи, созданных КСС, и добавляя новые объекты связи.
Изменение объекта связи, созданного КСС Вы можете изменять график и контроллер-отправитель для объекта связи в пределах сайта, а также транспортный протокол для межсайто-вых объектов связи. По умолчанию контроллеры домена в пределах сайта каждый час проверяют всех своих партнеров по репликации, чтобы удостовериться, что обновления не были пропущены. Этот график можно изменить так, чтобы никогда не делать проверку, проверять каждые полчаса или каждые 15 минут. (Интерфейс связи показан на рисунке 4-1.) Когда вы производите изменения объекта связи, его имя (автоматически сгенерированный) заменяется на глобальный уникальный идентификатор объекта (GUID). После изменения объекта вы можете его переименовать.
Рис. 4-1. Конфигурирование существующего объекта связи Создание нового объекта связи Вы можете также создать совершенно новый объект связи, установив тем самым определенную топологию репликации. При создании объекта связи вы задаете, с какого контроллера домена будут браться обновления. Вы можете изменить любой параметр настройки в соглашении о связях.
Служба КСС не будет удалять или изменять связи, которые были изменены или созданы вручную.
КСС будет использовать созданные вручную объекты связи так, как использовал бы любую другую связь. КСС может реконфигурировать объекты связи в сайте, чтобы скомпенсировать объекты связи, созданные вручную.
Топология репликации внутри сайта Существует два варианта конфигурирования репликации между контроллерами домена в Active Directory. В первом варианте используется модель остовного дерева (spanning tree), когда создается топология репликации только с одним направлением репликации между контроллерами домена. Каждый контроллер домена, на котором размещается раздел каталога, будет иметь только одного партнера по репликации, передающего данные для этого раздела. Это гарантия того, что никогда не возникнут связи, по которым информация будет пересылаться на определенный контроллер домена более чем одним путем. Контроллеры домена никогда не получат одно и то же обновление дважды, потому что оно прибывает только из одного источника. Основной недостаток использования алгоритма spanning tree состоит в отсутствии избыточности. Если на одном из контроллеров домена произойдет сбой, то может потребоваться некоторое время на повторное вычисление пути репликации в обход неисправного контроллера.
Второй вариант создания топологии репликации должен включать избыточные связи. Основными целями разработки топологии репликации Active Directory являются работоспособность и устойчивость к отказам. Если отдельный контроллер домена недоступен для репликации, репликации Active Directory не должна оканчиваться неудачей. Недостаток использования избыточных связей состоит в том, что контроллер домена может получать одно и то же обновление несколько раз, потому что каждый контроллер домена имеет несколько партнеров по репликации. Чтобы избежать многократных модификаций одной и той же информации, при репликации Active Directory используется демпфирование распространения.
Как только к организации добавляются контроллеры домена с репликами определенного раздела Active Directory, KCC автоматически начинает создавать топологию репликации. Эта топология образует кольцо репликации. На рисунке 4-2 показан пример простой сетевой структуры с тремя контроллерами в одном домене и единственном сайте.
Рис. 4-2. Простое кольцо репликации КСС создает кольцо репликации (см. рис. 4-2), в котором каждый контроллер домена сконфигурирован с двумя входящими связями репликации. Если одна из связей недоступна, то обновление может передаваться по другой связи. Кроме того, каждый контроллер домена сконфигурирован как контроллер-источник для двух других контроллеров домена. Это создает избыточное кольцо для каждого контроллера домена.
По мере увеличения количества контроллеров домена с репликой определенного раздела становится важным второй принцип создания свя зей. Служба КСС всегда создает топологию репликации, в которой каждый контроллер домена в сайте удален от любого другого контроллера домена не более чем на три ретрансляции (hop).
Когда количество контроллеров домена в сайте становится больше семи, создаются дополнительные объекты связи для уменьшения потенциального числа ретрансляций до трех или меньшего количества. Например, сайт на рисунке 4-3 имеет девять контроллеров домена. Он будет иметь топологию репликации, включающую, по крайней мере, одну дополнительную связь.
Рис. 4-3. Кольцо репликации, включающее более семи контроллеров домена Кольца репликации основываются на разделах каталога. Это означает, что КСС вычисляет кольцо репликации для каждого раздела каталога. Например, организация имеет несколько доменов в единственном сайте и раздел приложений каталога, который копируется на несколько контроллеров домена в сайте. В этом случае конфигурация могла быть задана так, как показано на рисунке 4-4. В предложенном сценарии (см. рис. 4-4) возможно создание колец репликации, представленных в табл. 4-1.
Табл. 4-1. Кольца репликации в сложном сайте Раздел каталога Партнеры по репликации Раздел конфигурации Все контроллеры домена будут каталога, раздел схемы включены в кольцо репликации для каталога раздела конфигурации каталога и раздела схемы каталога, потому что они копируются на все контроллеры домена данного леса.
Раздел каталога домена DCl.Contoso.com, DC2.Contoso.com, Contoso.com DC3.Contoso.com, DC4.Contoso.com.
Раздел каталога домена DC5.Fabrikam.com, DC6.Fabrikam.com.
Fabrikam.com Глобальный каталог (GC) DCl.Contoso.com, DC4.Contoso.com, DC5.Fabrikam.com.
Раздел приложений каталога DC2.Contoso.com, DC6. Fabrikam.com.1.
AppPartitionl Дополнительную информацию смотрите в примечании ниже.
Рис. 4-4. Кольца репликации, созданные для каждого раздела каталога Примечание. Разделы приложений каталога DNS (ForestDnsZones и DomainDnsZones) также включены в топологию репликации. Чтобы не усложнять сценарий, эти разделы на рисунке 4-4 не обозначены и не приводятся в связанной с ним таблице. В главе 3 говорилось о том, что эти разделы обрабатываются так же, как другие доменные разделы каталога. По этой же причине на рисунке 4-4 не показана топология репликации глобального каталога GC. Процесс создания кольца репликации GC немного отличается от репликации других разделов и будет описан далее.
Разделы репликации и топологию можно просмотреть с помощью инструмента Replication Monitor (Монитор репликации). Монитор репликации Ч это одно из инструментальных средств поддержки, которые помещены на компакт-диск Windows Server 2003. Чтобы установить инструментальные средства поддержки, запустите файл Suptools.msi из каталога Support\Tools компакт-диска Windows Server 2003. Чтобы запустить монитор репликации, в окне Run (Выполнить) напечатайте replmon. На рисунке 4-5 показана конфигурация четырех серверов в лесу, отображаемая с помощью монитора репликации.
Рис. 4-5. Использование монитора репликации для просмотра раздела репликации Кольцо репликации - это логическая концепция, фактическая топология репликации, реализованная с помощью объектов связи. В то время как для каждого раздела каталога создается отдельное кольцо репликации, КСС не создает дополнительные объекты связи для каждого кольца репликации. Вместо этого КСС, насколько возможно, повторно использует одни и те же объекты связи для многих колец репликации. В примере на рисунке 4-5 DCl.Contoso.com имеет объект связи с DC4.Fabrikam.com.
Один из способов просмотра свойства объекта связи состоит в использовании монитора репликации. Чтобы рассмотреть свойства входящих связей сервера, добавьте сервер к контролируемому списку серверов. Затем щелкните правой кнопкой мыши на имени сервера и выберите Show Replication Topologies (Показать топологию репликации). Щелкните на View (Вид), далее Ч на Connection Objects Only (Только объекты связи), а затем щелкните правой кнопкой мыши на сервере и выберите Properties (Свойства). Вкладка Inbound Replication Connections (Входящие связи репликации) показывает все входящие связи для контроллера домена, а также разделы, реплицируемые через каждую связь. Как показано на рисунке 4-6, этот объект связи используется для реплицирования глобального каталога (показан как раздел Fabrikam.com), раздела схемы каталога и раздела конфигурации каталога. Всякий раз, когда это возможно, КСС создает объект связи, пригодный для реплицирования нескольких разделов каталога.
Рис. 4-6. Отдельный объект связи, использующийся для репликации нескольких разделов каталога Репликация глобального каталога Глобальный каталог отличается от других разделов тем, что он составлен из баз данных доменов целого леса. Каталог GC всех контроллеров домена предназначен только для чтения. Это означает, что информация в GC не может быть изменена администратором напрямую. Глобальный каталог GC представляет собой список всех атрибутов, переданных в него, атрибут isMemberOfPartialAttributesSet которых установлен на true (истину).
Тот факт, что GC создан из баз данных доменов, затрагивает также кольцо репликации для GC.
Каждый GC-сервер должен получить GC-информацию от контроллеров домена всех доменов. На рисунке 4-7 приведен пример компании, имеющей два домена с одним контроллером домена в каждом;
оба домена расположены в одном и том же сайте. Домен DCl.Contoso.com сконфигурирован как сервер глобального каталога. GC-сервер является также единственным контроллером домена для домена Contoso.com, поэтому он извлекает GC-информацию для Contoso.com из своей собственной базы данных домена. Контроллер домена в домене Fabrikam.com имеет единственную копию раздела каталога этого домена, поэтому DCl.Contoso.com собирает GC-информацию для домена Fabrikam.com из DC2.Fabrikam.com. Для извлечения информации из домена Fabrikam.com создан объект связи, направленный от DC2.Fabrikam.com к DCl.Contoso.com. В дальнейшем эта связь может использоваться для репликации GC-информации в DCl.Contoso.com.
Рис. 4-7. Пример простой репликации глобального каталога На рисунке 4-8 показан более сложный пример создания GC и его репликации. В этом случае сконфигурирован объект связи, направленный от контроллера домена каждого домена на каждый GC-сервер. DCl.Contoso.com имеет входящий объект связи от контроллеров DC2.Contoso.com, DC4.Fabrikam.com и DC6.NWTraders.com. Этот объект связи используется для создания глобального каталога на DCl.Contoso.com. Все другие GC-серверы имеют подобный набор объектов связи. Кроме того, создано также отдельное кольцо для репликации раздела GC между всеми GC серверами.
Топология межсайтовой репликации Когда к лесу добавляются дополнительные сайты, топология репликации становится более сложной. В сценарии, содержащем несколько сайтов, дол жна быть создана топология репликации для каждого сайта, а также топология репликации между сайтами. Чтобы справиться с этим, процесс создания объектов связи для репликации внутри сайта изменяется. В пределах сайта КСС на каждом контроллере домена ответственен за создание тех объектов связи, которые нужны для гарантии необходимой избыточности репликации для всех его разделов, затем он реплицирует информацию об объектах связи на другие контроллеры домена.
Кроме того, контроллер домена получает информацию об объектах связи, которые были созданы другими контроллерами домена. При следующем выполнении КСС объекты связи могут быть добавлены, изменены или удалены на основе информации, которую контроллер домена получил о других объектах связи сайта. В конечном счете, процессы КСС, выполняющиеся на всех контроллерах домена в сайте, определяют оптимальную конфигурацию репликации.
Рис. 4-8. Пример сложной GC-репликации Подобный подход используется также при определении топологии репликации между сайтами, за исключением того, что один контроллер домена в каждом сайте ответственен за разработку топологии между сайтами. КСС одного из контроллеров домена в сайте обозначается как генератор межсайтовой топологии (ISTG - Inter-Site Topology Generator) для сайта. Имеется только один ISTG-контроллер на сайте, независимо от того, сколько доменов или других разделов каталога находится в сайте. Контроллер ISTG ответственен за вычисление идеальной топологии репликации для всего сайта. Этот процесс состоит из двух частей.
Х Идентификация серверов-плацдармов (bridgehead server) для каждого раздела каталога, имеющегося в сайте. При репликации между сайтами информация всегда посылается с сервера-плацдарма одного сайта на сервер-плацдарм другого. Это означает, что по сетевой связи между сайтами информация реплицируется только однажды.
Х Создание объектов связи между серверами-плацдармами для гарантии репликации между сайтами. Поскольку репликация конфигурируется между серверами-плацдармами, то в пределах сайта отсутствуют избыточные объекты связи.
При добавлении к лесу нового сайта ISTG в каждом сайте определяет, какой раздел каталога в нем имеется. Затем ISTG вычисляет новые объекты связи, которые потребуются для репликации нужной информации с нового сайта. Кроме того, ISTG назначает один контроллер домена сервером-плацдармом для каждого раздела каталога. ISTG создает необходимое соглашение связи в своем каталоге, и эта информация копируется на сервер-плацдарм. Затем сервер-плацдарм создает подключение для репликации с сервером-плацдармом удаленного сайта, и начинается репликация.
На рисунке 4-9 показан пример топологии репликации, созданной между сайтами. В этом примере лес содержит два сайта и два домена с несколькими контроллерами домена в каждом сайте.
Имеется также, по крайней мере, один GC-сервер в каждом сайте. Это означает, что каждый сайт содержит раздел каталога для каждого из доменов, раздел GC, а также разделы схемы каталога и конфигурации каталога. В каждом сайте требуется назначить по два сервера-плацдарма, потому что каждый из этих разделов должен копироваться между сайтами. Один из серверов-плацдармов в обоих сайтах должен быть контроллером домена в домене Contoso.com. Другой сервер-плацдарм обоих сайтов должен быть контроллером домена в домене Fabrikam.com. В примере, показанном на рисунке 4-9, контроллеры DCl.Contoso.com и DC6.Fabrikam.com являются также GC-серверами.
Это означает, что они станут серверами-плацдармами при репликации GC-информации между сайтами. Поскольку раздел схемы и раздел конфигурации каталога являются общими для всех контроллеров домена, то для репликации этих разделов может использоваться один из существующих объектов связи.
Примечание. Приведенное обсуждение топологии репликации основано на заданном по умолчанию поведении для контроллеров домена Active Directory. Администраторы могут изменять это поведение, особенно для репликации между сайтами. Эти вопросы будут обсуждаться далее в этой главе.
Рис. 4-9. Межсайтовые объекты связи Процесс репликации Выше обсуждались детали создания топологии репликации в Active Directory. В данном разделе рассмотрим репликацию с другой точки зрения. Обратим внимание на то, как на самом деле передается модифицированная информация между двумя контроллерами домена, как контроллеры домена узнают о том, какую информацию они должны копировать партнерам по репликации, настроенным службой КСС.
Типы обновлений Существуют два типа обновлений информации Active Directory, касающейся определенного контроллера домена. Первый тип обновлений - исходное обновление (originating update). Исходное обновление выполняется при добавлении, изменении или удалении объекта на контроллере домена. Второй тип обновлений - реплицируемое обновление (replicated update). Репликация выполняется тогда, когда изменение, сделанное на одном контроллере домена, копируется на другой контроллер домена. По определению исходное обновление, касающееся любого конкретного изменения, только одно, оно выполняется на том контроллере домена, где было сделано. Затем исходное обновление копируется на все контроллеры домена, которые имеют реплику раздела Active Directory, затронутого обновлением.
Исходные обновления Active Directory происходят в следующих случаях:
Х к Active Directory добавлен новый объект;
Х из Active Directory удален существующий объект;
Х атрибуты существующего объекта изменены. Эта модификация может включать добавление нового значения атрибуту, удаление значения атрибута или изменение существующего значения;
Х объект Active Directory перемещен в новый родительский контейнер. Если изменяется имя родительского контейнера, то каждый объект контейнера перемещается в переименованный контейнер.
Все исходные обновления Active Directory являются элементарными операциями. Это означает, что в процессе передачи модификация должна быть передана полностью, как целая транзакция, и никакая ее часть не передается отдельно от других частей.
Репликация изменений После передачи исходного обновления изменение должно реплицироваться на другие контроллеры домена, которые содержат реплику этого раздела. В пределах сайта контроллер домена, на котором произошло исходное обновление, ждет 15 с перед началом копирования изменений своим прямым партнерам по репликации. Это ожидание предназначено для того, чтобы несколько модификаций к базе данных можно было реплицировать одновременно, что увеличивает эффективность репликации. Между сайтами исходное обновление будет копироваться партнерам по репликации в соответствии с графиком, сконфигурированным на связях сайта.
Для репликации изменений информации каталога контроллерам домена требуется механизм для управления потоком репликации. Для оптимизации репликации Active Directory следует пересылать только те изменения, которые должны реплицироваться между двумя контроллерами домена. Контроллеры домена должны уметь определять эти изменения, если таковые вообще имеются, а затем копировать только ту часть изменений, которая требуется. Для управления репликацией каталога в Active Directory используются порядковые номера обновлений (USN update sequence number), значения уровня (high-watermark value), векторы новизны (up-to-dateness vectors) и отметки об изменениях (change stamps). Эти компоненты обсуждаются далее.
Порядковые номера обновлений Когда объект базы данных модифицируется, то изменению присваивается порядковый номер обновления. Порядковые номера обновления (USN Ч update sequence number) являются спецификой баз данных сервера. Например, если изменению номера телефона одного из пользователей был назначен номер USN 5555, то следующее изменение базы данных, независимо от изменяемого объекта, будет иметь номер USN 5556. Один номер USN назначается для каждого совершенного изменения. Если в одной модификации изменено несколько атрибутов (например, адрес, номер телефона и местоположение офиса), то этой модификации назначается только один USN.
Существует три способа использования USN при выполнении модификаций. Во-первых, локальное значение USN сохраняется вместе с атрибутом, который был модифицирован.
Локальное значение идентифицирует USN измененного атрибута. Во-вторых, USN используется для атрибута uSNChanged объекта. Этот атрибут хранится с каждым объектом и идентифицирует самый высокий USN для атрибутов данного объекта. Рассмотрим пример. Предположим, что был изменен номер телефона пользователя, и этому изменению был назначен USN, равный 5556. И локальный USN, и атрибут uSNChanged будут установлены на 5556. Если следующая модификация, сделанная в каталоге на том же сервере, состоит в изменении адреса того же самого пользователя, то местный USN на атрибуте адреса и атрибут uSNChanged для пользовательского объекта будут изменены на 5557. Однако местный USN для атрибута номера телефона останется равным 5556, потому что это USN для последней модификации этого конкретного атрибута.
Локальный USN и атрибут uSNChanged относятся как к исходным, так и к реплицируемым обновлениям. В последнем способе USN используется как USN исходной модификации атрибута.
Это значение устанавливается только для исходных модификаций, оно копируется на все другие контроллеры домена как часть репликации атрибутов. Когда на сервере изменяется номер телефона пользователя, то USN этого изменения назначается равным исходному значению USN.
Когда измененный номер телефона копируется на другой контроллер домена, исходный USN посылается вместе с модификацией, и это значение не изменяется на контроллере домена адресата. Локальный USN и атрибут uSNChanged будут изменены на контроллере домена адресата, но исходный USN не изменится до тех пор, пока сам атрибут не будет снова модифицирован. Исходный USN используется для демпфирования распространения, которое рассматривается далее в этой главе.
Значения уровней Значения уровней (high-watermark values) используются для управления тем, какая информация реплицируется между контроллерами домена. Каждый контроллер домена поддерживает свой собственный набор уровней для каждого из своих прямых партнеров по репликации. Уровень -это последнее значение uSNChanged, которое контроллер домена получил от определенного партнера по репликации. Когда контроллер домена посылает модификацию партнеру по репликации, значение uSNChanged посылается вместе с модификацией. Контроллер домена адресата сохраняет его как значение уровня для партнера по репликации.
Значения уровней используются во время процесса репликации. Когда один контроллер домена запрашивает обновление у другого контроллера домена, то контроллер-адресат посылает свое значение уровня контроллеру-отправителю. Контроллер-отправитель использует значение уровня контроллера-адресата для фильтрации всех потенциальных обновлений и посылает только те изменения, которые имеют более высокое значение uSNChanged.
Примечание. Значение уровня поддерживается отдельно для каждого раздела каталога на контроллере домена и для каждого прямого партнера по репликации.
Векторы новизны и демпфирование распространения Векторы новизны (up-to-dateness vectors) также используются для управления тем, какая информация должна копироваться между контроллерами домена. Векторы новизны используются для отслеживания всех исходных модификаций, которые данный контроллер домена получил от какого-либо контроллера домена. Например, изменен номер телефона пользователя на контроллере домена DC1, и атрибуту назначен исходный USN, равный 5556. Когда этот атрибут реплицируется на контроллер DC2, исходный USN копируется с обновленным атрибутом. Кроме того, GUID контроллера DC1 реплицируется вместе с атрибутом. Когда DC2 получает это обновление, он модифицирует свой вектор новизны, показывая, что самое последнее исходное обновление, полученное от DC1, теперь равно 5556. Вектор новизны используется для ограничения трафика репликации между контроллерами домена. Когда контроллер-адресат запрашивает обновление у контроллера-отправителя, он включает в запрос свои векторы новизны.
Затем компьютер-отправитель использует эту информацию для фильтрации списка всех возможных модификаций, которые он может послать контроллеру-адресату. Такой выбор важен, когда имеется более двух контроллеров домена для данного раздела каталога. Например, если к сценарию, описанному в предшествующем параграфе, добавить контроллер DC3, то изменение номера телефона, сделанное на DC1, будет копироваться и на DC2, и на DC3. Теперь DC3 и DC будут иметь обновленный номер телефона, они изменят свои векторы новизны, показывая, что самая последняя модификация, которую они оба получили от DC1, имела исходный USN 5556.
Приблизительно через 15 с после получения этой модификации DC2 уведомит DC3, что у него есть обновленная информация. Когда DC3 будет запрашивать обновления каталога у DC2, он включит свой вектор новизны в запрос. В этом случае DC2 определит, что вектор новизны контроллера DC3 для DC1 уже имеет новейший исходный номер USN. Если модификация номера телефона была единственным изменением, сделанным к каталогу в этот временной период, то информация между контроллерами домена DC2 и DC3 реплицироваться не будет. Процесс ограничения модификаций, посылаемых во время репликации, с помощью вектора новизны называется демпфированием распространения. Как уже говорилось, служба КСС создает избыточные репли-кационные связи между контроллерами домена. Одна из проблем, связанных с этим, состоит в том, что одни и те же модификации могут посылаться контроллеру домена от нескольких партнеров по репликации. Это ведет к увеличению трафика репликации, а также потенциально приводит к ситуации, когда одна и та же модификация посылается неоднократно всем контроллерам домена. Демпфирование распространения, использующее вектор новизны, устраняет такую возможность.
Просмотр информации USN Номера USN (update sequence number) для любого объекта можно просмотреть с помощью средств администрирования, включенных в инструментальные средства поддержки Windows Server 2003.
Один из способов просмотра локального USN исходного контроллера домена, исходного USN и отметки времени (time stamp) для любого атрибута состоит в использовании инструмента командной строки Repadmin. (Полную инструкцию по установке Repadmin смотрите в разделе Мониторинг и поиск неисправностей репликации далее в этой главе.) Напечатайте repadmin /showmeta object distinguished name (отличительное имя объекта) в командной строке. Значения uSNCreated и uSNChanged можно увидеть в ADSI Edit через свойства объекта. Чтобы получить доступ к информации репликации через Ldp.exe, найдите объект, щелкните правой кнопкой мыши на объекте, выберите Advanced (Расширенный), затем выберите Replication Metadata (Мета-данные репликации). Значения USN также можно присмотреть через Монитор репликации (см. рис. 4-10).
Для этого добавьте сервер к списку мониторинга, а затем щелкните правой кнопкой мыши на сервере и выберите Show Attribute Meta-Data For Active Directory Object (Показать метаданные атрибута для объекта Active Directory). Введите мандат (credentials) для учетной записи с доступом к Active Directory, а затем напечатайте отличительное имя объекта. Часть USN-информации доступна также из обычных средств администрирования. Чтобы посмотреть текущие и исходные значения USN для объекта в инструменте администрирования Active Directory Users And Computers, включите Advanced Features (Расширенные функции) в меню View (Вид), а затем обратитесь к вкладке Object (Объект) в окне Properties (Свойства) объекта.
Уровень и вектор новизны используются для ограничения трафика репликации. Значение уровня представляет собой самое последнее изменение, которое контроллер домена получил от другого контроллера домена, так что контроллер-отправитель не должен снова посылать это значение.
Вектор новизны содержит самые свежие обновления, которые были получены от других контроллеров домена, содержащих реплику раздела, так что контроллер-отправитель не должен посылать такие модификации каталога, которые контроллер-адресат уже получил от другого партнера по репликации.
Рис. 4-10. Просмотр мета-данных репликации с помощью Replication Monitor (Монитор репликации) Отметки об изменениях и разрешение конфликтов И последнее, что используется для управления репликацией между контроллерами домена, Ч это отметка об изменении (change stamp). Всякий раз, когда атрибут модифицируется, эта модификация помечается отметкой об изменении. Затем отметка об изменении посылается вместе с модификацией, когда модификация копируется на другие контроллеры домена. Отметка об изменениях используется для того, чтобы определить, какое изменение будет принято в случае конфликта репликации. Отметка об изменениях состоит из трех компонентов.
Х Номер версии. Он используется для отслеживания количества изменений, которые были сделаны к атрибуту объекта. Когда объект создается, номер версии у всех атрибутов устанавливается на 1, даже если поле атрибута оставлено пустым. Когда происходит назначение пустого атрибута, значение номера версии остается равным 1. Однако когда атрибут обновляется после начального изменения, номер версии каждый раз увеличивается на единицу.
Х Время последней записи. Оно используется для отслеживания времени, когда произошла последняя модификация атрибута. Значение времени регистрируется на том сервере, где атрибут был модифицирован, и копируется вместе с объектом на другие контроллеры домена.
Х Исходный сервер (Originating server). Этот компонент представляет собой GUID сервера, на котором была применена последняя исходная модификация атрибута.
Эти три компонента формируют отметку об изменениях для каждой модификации атрибута. Когда атрибут копируется на другой контроллер домена, эта информация копируется вместе с атрибутом. Если один и тот же атрибут изменен на двух различных контроллерах домена одновременно, то отметка об изменениях используется для определения того, какой атрибут будет принят в качестве заключительного изменения. В случае конфликта решение относительно заключительного изменения делается в следующем порядке.
1. Номер версии. Всегда принимается изменение с самым высоким номером версии. Если изменение на одном контроллере домена имеет номер версии 3, а изменение на другом контроллере домена номер версии 4, будет всегда приниматься изменение с номером версии 4.
2. Время последней записи. Если номера версий идентичны, то будет принято изменение с самым недавним временем последней записи.
3. GXJID сервера. Если номера версий и времена последней записи идентичны, то используется GUID базы данных сервера для определения того, какое изменение должно быть принято. Будет принято изменение, прибывающее с сервера, имеющего более высокий GUID. Идентификаторы GUID назначаются при добавлении контроллера домена к домену, a GUID назначается произвольно.
Практический опыт. Конфликты репликации Некоторые сетевые администраторы, похоже, очень озабочены возможностью возникновения конфликтов репликации и потенциальной потерей или перезаписью данных. В большинстве компаний вероятность их возникновения невелика. Во первых, конфликты репликации касаются отдельных атрибутов. (Если номер телефона пользователя изменяется на одном контроллере домена в то же самое время, когда адрес пользователя изменяется на другом контроллере домена, никакой конфликт не возникает.) Во-вторых, большинство компаний имеют централизованный отдел, где делаются все изменения к учетным записям пользователя, так что вероятность того, что два человека сделают различные изменения к одному и тому же атрибуту одновременно, очень мала. Если администрирование учетных записей пользователя делегировано на уровень отдела, то каждый отдел делает изменения только к учетным записям пользователя своего отдела. Таким образом, в большинстве компаний, использующих структурированный способ работы с объектами Active Directory, конфликты репликации происходят очень редко.
Служба Active Directory способна разрешать конфликты, которые создаются, когда один и тот же атрибут объекта изменяется одновременно на двух контроллерах домена. Имеются два других типа конфликтов, которые могут возникать.
Х Добавление или изменение объекта на одном контроллере домена в то же самое время, когда контейнерный объект этого объекта удаляется на другом контроллере домена. Рассмотрим пример, в котором на одном контроллере домена был добавлен новый пользователь к организационной единице (OU) Accounting (Бухгалтерия). В это же время на другом контроллере домена другой администратор удаляет OU Accounting. В этом случае объект, который был добавлен к удаленному контейнеру, будет перемещен в контейнер Active Directory с именем LostAndFound.
Х Добавление объектов с одним и тем же относительным отличительным именем (relative distinguished name) в один и тот же контейнер. Такой конфликт возникает, когда администратор на одном контроллере домена создает пользовательский объект с относительным отличительным именем BDiaz в OU Accounting, в то же самое время на другом контроллере домена пользователь, имеющий такое же относительное отличительное имя, перемещается в ту же самую OU или создается в той же самой OU. В этом случае для определения того, какой объект будет сохранен, а какой переименован, в модели разрешения конфликтов будет использоваться GUID, назначенный модифицируемому каталогу. Объект, имеющий более высокий GUID, будет сохранен, а объект с более низким GUID переименован на BDiaz#CNF:userGUID, где значок номера (#) является символом дублирования. Если второй пользовательский объект потребуется, то его можно будет переименовать.
Репликация удалений объектов Репликация удалений объектов обрабатывается в Active Directory иначе, чем другие модификации каталога. Когда удаляется учетная записи пользователя, она не уничтожается немедленно. Вместо этого создается объект-памятник (tombstone). Объект-памятник является исходным объектом, у которого атрибут isDeleted установлен на true (истина), а большинство атрибутов объекта удалено.
Сохранены только несколько атрибутов, типа GUID, SID, USN и отличительного имени, которые требуются для идентификации этого объекта.
Объект-памятник затем копируется на другие контроллеры домена в домене. По мере того как каждый контроллер домена получает модификацию, модификации, которые были сделаны на исходном контроллере домена, применяются на всех остальных контроллерах. Объекты памятники остаются в базе данных домена в течение определенного периода времени, называемого временем жизни объекта-памятника (tombstone lifetime). В конце времени жизни объекта-памятника, установленного по умолчанию на 60 дней, каждый контроллер домена удаляет его из своей копии базы данных. Процесс удаления объектов-памятников из базы данных называется сборкой мусора (garbage collection). По умолчанию интервал времени, через который производится сборка мусора, для леса установлен на 12 часов. Каждые 12 часов выполняется процесс сборки мусора, и удаляются все объекты-памятники, время жизни которых истекло.
В главе 1 говорилось о том, что служба Active Directory Windows Server 2003 обеспечивает поддержку неактивных объектов в Active Directory. Неактивный объект (lingering object) Ч это объект, который не был удален из контроллера домена, потому что контроллер находился в автономном режиме или был не способен к репликации в течение всего времени жизни объекта памятника. Для удаления неактивных объектов используется инструмент Repadmin.
Совет. Время жизни объекта-памятника и интервал сборки мусора может быть изменен с помощью ADSI Edit или Ldp.exe. Эти свойства сконфигурированы в объекте CN=Directory Service,CN=Windows NT,CN=Services,CN = Configuration, DC=ForestRootDomain. Атрибуты garbageCollPeriod и tombstoneLifetime определяют эти параметры настройки. В большинстве случаев эти значения менять не требуется.
Конфигурирование репликации между сайтами Причина создания нескольких сайтов в Active Directory заключается в необходимости управлять трафиком репликации между несколькими офисами компании, особенно между теми, которые соединены низкоскоростными WAN-соединениями. Конфигурация сайта для вашей компании будет оказывать существенное воздействие на трафик репликации, идущий по сети.
Дополнительная информация. Сформулировать четкий критерий того, когда следует создавать дополнительный сайт, трудно из-за большого количества переменных, которые должны быть включены в этот критерий. В главе 5 приводится подробная информация о создании дополнительных сайтов. В этой главе далее рассмотрены другие вопросы построения Active Directory, которые нужно учитывать при проектировании топологии сайта.
Как сказано в главе 2, сайт в Active Directory Ч это место, в котором все контроллеры домена связаны друг с другом высокоскоростными соединениями. Одна из задач установки сети Active Directory состоит в определении того, где следует провести границы сайта, а затем соединить сайты вместе.
Создание дополнительных сайтов Когда устанавливается Active Directory, создается единственный сайт с именем Default-First-Site Name (в дальнейшем сайт можно переименовать). Если не создается дополнительных сайтов, то все последующие контроллеры домена будут добавляться к этому сайту по мере их установки.
Однако если ваша компания расположена в нескольких местах с ограниченной пропускной способностью между ними, то вы наверняка захотите создать дополнительные сайты.
Дополнительные сайты создаются с помощью инструмента администрирования Active Directory Sites And Services (Сайты и службы Active Directory). Чтобы создать новый сайт, щелкните правой кнопкой мыши на контейнере Sites (Сайты), затем выберите New Site (Новый сайт). В списке Link Name (Имя связи) вы должны выбрать ту связь сайта, которая будет использоваться для соединения этого сайта с другими сайтами. Каждый сайт связан с одной или более подсетями IP в Active Directory. Создайте дополнительные подсети в контейнере Subnets (Подсети) в инструменте Active Directory Sites And Services и свяжите подсети с новым сайтом. Каждый сайт должен иметь, по крайней мере, один контроллер домена и GC-сервер. Чтобы переместить существующий контроллер домена в сайт, вы можете щелкнуть правой кнопкой мыши на объекте контроллера домена в его текущем контейнере Servers (Серверы) и выбрать Move (Переместить). Затем вам будет предложен выбор сайта, в который вы хотите переместить контроллер домена. Если вы устанавливаете новый контроллер домена, то он будет автоматически расположен в том сайте, в котором подсеть IP соответствует IP-адресу контроллера домена. Возможно создание сайта без контроллеров домена, но этого делать не следует.
Связи сайта Соединения Active Directory, которые связывают сайты вместе, называются связями сайта (Site Links). При инсталляции Active Directory создается единственная связь сайта с именем DEFAULTIPSITELINK. Если вы не создадите никаких дополнительных связей сайта прежде, чем создадите дополнительные сайты, то каждый сайт включается в эту заданную по умолчанию связь сайта. Если WAN-связи между офисами вашей компании одинаковы по пропускной способности и стоимости, вы можете просто принять это заданное по умолчанию поведение. Если все сайты соединены одной связью, трафик репликации между ними будет иметь одинаковые свойства. При изменениях в связи сайта конфигурация репликации для всех сайтов будет изменена. Если вы хотите иметь возможность по-разному управлять репликацией между сайтами, вы должны создать дополнительные связи сайта и назначить им соответствующие сайты.
Создание связей сайта не заменяет работу ISTG. При этом происходит лишь создание возможностей для работы ISTG. Как только связь сайта установлена, ISTG будет использовать ее для создания необходимых объектов связи, предназначенных для репликации всех разделов Active Directory между всеми сайтами.
Ниже приведены опции конфигурации для всех связей сайта.
Х Стоимость (Cost) - это назначенное администратором значение, которое определяет относительную стоимость связи сайта. Стоимость обычно отражает скорость сетевой передачи и расходы, связанные с ее использованием. Стоимость становится важным параметром, если в организации имеются избыточные связи сайта, т.е. более одного пути для репликации между двумя сайтами. Во всех случаях в качестве пути репликации выбирается маршрут самой низкой стоимости.
Х График репликации (Replication schedule) Ч определяет, в какое время в течение дня связь сайта доступна для репликации. Заданный по умолчанию график репликации разрешает репликации в течение 24 часов в день. Однако если пропускная способность пути к сайту ограничена, репликация может происходить только в нерабочие часы.
Х Интервал репликации (Replication interval) - определяет интервалы времени, через которые серверы-плацдармы проверяют появление модификаций каталога на серверах плацдармах других сайтов. По умолчанию интервал репликации для связей сайта установлен на 180 минут. Интервал репликации применяется только в соответствии с графиком репликации. Если график репликации сконфигурирован так, чтобы позволять репликации с 22:00 до 5:00 по умолчанию, то серверы-плацдармы проверяют модификации через каждые 3 часа в этом промежутке времени.
Х Транспортные протоколы репликации (Replication transports). Для передачи репликации связь сайта может использовать или RPC по IP, или SMTP. Дополнительную информацию смотрите в разделе Протоколы транспортировки репликации далее в этой главе. Эти опции обеспечивают существенную гибкость в конфигурировании репликации между сайтами. Однако существуют также некоторые ошибки, которых следует избегать.
Чтобы понять, как эти опции работают вместе, рассмотрите сеть компании, показанную на рисунке 4-11.
В Active Directory Windows Server 2003 все связи сайта считаются транзитивными (transitive) по умолчанию. Как показано на рисунке 4-11, Sitel имеет связи с сайтами Site2 и Site4, a Site2 имеет связь с сайтами Site3 и Site5. Из-за транзитивной природы связей сайта это означает, что Sitel может также реплицировать информацию напрямую с сайтами Site3 и Site5.
Стоимость связей сайта определяет путь, по которому будет происходить трафик репликации по сети. Когда КСС создает топологию маршрутизации, он использует накопленную информацию о стоимости всех связей сайта для вычисления оптимальной маршрутизации. В примере, показанном на рисунке 4-11, есть два возможных маршрута между сайтами Sitel и Site5: первый маршрут Ч через Site2, второй маршрут Ч через Site4. Стоимость передачи через Site2 - 300 ( + 200), стоимость передачи через Site4 Ч 700 (500 + 200). Это означает, что весь трафик репликации будет направляться через Site 2, если это подключение функционирует.
Рис. 4-11. Конфигурация связи сайта Когда трафик репликации проходит по нескольким связям сайта, графики связей сайта и интервалы репликации объединяются для определения эффективного окна репликации и интервала. Например, эффективная репликация между сайтами Site1 и Site3 будет происходить только с 24:00 до 4:00 (это время перекрытия графиков) каждые 60 минут (интервал репликации для связи Site2-Site3).
Pages: | 1 | 2 | 3 | 4 | ... | 8 | Книги, научные публикации