Выбор резервного DC для переключения запросов клиентов

Большинству администраторов известно, что удачный выбор топологии сайта Windows 2000 Active Directory (AD) почти так же важен, как хорошая организация домена. Благодаря продуманной топологии сайта до минимума снижается сетевой трафик AD, аутентификация пользователей выполняется ближайшим контроллером домена (DC) и более предсказуемым становится время репликации объекта в масштабе предприятия.

У сайтов AD есть еще одно важное, но не столь широко известное назначение: от них зависит процесс переключения клиента на другой DC в случае отказа текущего контроллера домена. В сайте AD с хорошо спроектированной топологией можно отметить DC в любой области сети как недоступный, и клиенты сайта безошибочно выберут наиболее подходящий контроллер из оставшихся.

Почему так важно обеспечить переключение на другой DC в случае отказа одного из контроллеров домена? От выбора DC для клиента в значительной степени зависит время регистрации пользователя и быстрота отклика системы. Например, в большинстве компаний используются сценарии регистрации, и расстояние по сети между DC, выполняющим аутентификацию, и клиентом сильно влияет на скорость выполнения сценария регистрации. Кроме того, как Microsoft Exchange 2000 Server, так и его клиенты активно задействуют глобальный каталог AD (Global Catalog, GC). Поэтому выбор DC для размещения GC заметно влияет на время отклика клиентов электронной почты.

Прежде чем приступить к проектированию механизма переключений DC, необходимо выяснить, как клиенты выбирают DC (процесс обнаружения, DC locator). При моделировании переключения DC (предполагается, что наиболее удобные DC недоступны) администратор проходит по этапам процесса обнаружения DC, чтобы выяснить, какие из альтернативных контроллеров будут выбраны клиентом. В идеальном случае клиент Windows, не имеющий возможности установить связь с локальным (расположенным в пределах того же сайта) DC, определяет ближайший из оставшихся сайтов, анализируя весовые коэффициенты соединений в топологии сайта AD, и пытается установить связь с его DC. Если контроллеры домена в этом сайте недоступны, то клиент отыскивает следующий ближайший сайт и предпринимает новую попытку. Процесс повторяется до тех пор, пока не будет найден подходящий DC. К сожалению, такой процесс обнаружения DC еще не реализован на практике. В Windows Server 2003 и Windows 2000 клиент запрашивает список DC в своем сайте и домене. Если эти DC недоступны, то клиент запрашивает список всех DC в домене.

Реорганизация списка DC

Наряду с другими записями контроллеры домена делают в DNS записи SRV для сайта и домена. В процессе поиска DC клиент получает из DNS список контроллеров домена, с которыми клиент может установить связь. Для оптимальной организации процесса переключения DC необходимо изменить порядок следования DC в списке, получаемом клиентом из DNS. Изменяя список, администратор указывает клиенту, какой DC следует выбрать, если основной DC недоступен. Почти во всех случаях в списке DNS сначала перечислены контроллеры домена в локальном сайте клиента, а затем — все DC в домене клиента. Чтобы получить информацию о порядке следования DC в списке, необходимо ввести одну из следующих команд:

nslookup -querytype=srv

_ ldap._tcp.sitename._sites.dc._msdcs

.domain.name

nslookup -querytype=srv _ldap._

tcp.dc._msdcs.domain.name

где sitename — имя сайта клиента, а domain.name — полное имя (Fully Qualified Domain Name, FQDN) домена клиента. Эти команды определяют, каким будет список DC, полученный из DNS клиентом в домене domain.name и сайте sitename. Первая команда возвращает список DC, доступных как в домене, так и в сайте клиента, а вторая команда выдает список DC во всем домене.

На экране 1 показана типичная радиальная конфигурация, в которой Hub — главный узел компании (и центр территориально распределенной сети, WAN), а Spoke1, Spoke2 и Spoke3 — малые периферийные сайты. Все периферийные сайты расположены в одном домене. В самом крупном сайте Hub содержится несколько DC; малые сайты включают лишь один или два DC. На экране 1 также приведен список DC для клиента Client1.

Рисунок 1. Примерная топология сайта AD.

Механизм переключения DC

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

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

Что происходит в сайте с типичной топологией при отказе DC? Если контроллер домена SPOKE1-DC1 недоступен, клиент пытается отправить запрос на следующий DC в списке контроллеров, где перечислены контроллеры сайта и домена. В сайте Spoke1 содержится только один DC, и, поскольку этот DC не отвечает на клиентские запросы Lightweight Directory Access Protocol (LDAP) через UDP, клиент начинает опрашивать доменные DC, указанные в списке. Оставшиеся DC в списке перечислены в случайном порядке, поэтому следующий DC, опрошенный клиентом, может находиться в любом месте домена. Клиент просматривает список до тех пор, пока один из DC не ответит на запрос.

Вероятность выбора клиентом оптимального DC при опросе контроллеров во всем домене невелика, так как ни один DC не имеет предпочтения перед другими, независимо от расстояния между каждым из них и клиентом. Дополнительные трудности связаны с интервалом опроса контроллеров в Windows 2003 и Windows 2000 (временем ожидания после отправки запроса, по истечении которого клиент переходит к следующему DC в списке). В Windows NT 4.0 операционная система направляет запросы немедленно, без паузы между ними; в результате устанавливается связь с DC, который ответит быстрее других (предполагается, что это будет ближайший контроллер домена). В Windows 2000 клиент делает между запросами к DC паузу в 100 мс. В Windows 2003 клиент ждет 400 мс между запросами к первым пяти DC, 200 мс между запросами к следующим пяти DC и 100 мс — между запросами к остальным DC. Как в Windows 2003, так и в Windows 2000 в результате такой процедуры велика вероятность выбора не самого оптимального контроллера.

Рисунок 2. Опрос DC домена.

На экране 2 показано, каким образом данная процедура влияет на выбор DC. Предположим, что задержка распространения сигнала по сети между клиентом с DC в сайте Spoke3 составляет 150 мс. Задержка при обращениях клиента к контроллерам домена в более близком сайте Hub составляет всего 75 мс. Поскольку Spoke3-DC2 занимает первую позицию в списке, клиент проверяет его первым. В сети Windows 2000 Spoke3-DC2 не успеет ответить в течение интервала в 100 мс, поэтому клиент перейдет к следующему DC в списке и проверит HUB-DC2 — более подходящий выбор. Но прежде чем успеет ответить HUB-DC2, клиент получит ответный сигнал от контроллера Spoke3-DC2, который имел преимущество в 100 мс, и клиент установит сеанс связи с этим DC. В сети Windows 2003 у Spoke3-DC2 есть достаточно времени для ответа до истечения интервала в 400 мс, когда клиент попытается установить связь со следующем DC в списке. В любой конфигурации, если клиент не обнаружит контроллер в собственном сайте или администратор не изменит список контроллеров домена вручную, выбор DC не будет оптимальным.

Организация переключений DC

Широко распространено заблуждение, что функция автоматического опроса сайта (AutoSiteCoverage) в составе службы каталогов Windows 2003 и Windows 2000 обеспечивает переключение DC при отсутствии доступных контроллеров в сайте клиента. При использовании AutoSiteCoverage контроллеры домена в сайте, ближайшем к клиентскому, могут автоматически зарегистрироваться в сайте, лишенном DC. Однако эти DC обслуживают клиентов, только если в клиентском сайте нет зарегистрированных DC. AutoSiteCoverage не действует, если DC в клиентском сайте существует, но не отвечает, поэтому данная функция для переключения DC бесполезна. Однако можно вручную заставить DC зарегистрироваться, чтобы предоставить службы DC или GC для другого сайта. Чтобы регистрация прошла корректно, необходимо ввести имена сайтов (разделенные пробелами) в параметр SiteCoverage типа REG_DWORD в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet Services NetlogonParameters и выполнить несколько дополнительных действий, которые будут описаны ниже.

Переключение DC в сети можно организовать одним из трех основных способов. В зависимости от требований компании, эти методы можно использовать отдельно или в комплексе.

Метод 1. Выборочная регистрация SRV. Как отмечалось выше, управляя списком DC, можно управлять процессом переключения клиентов между DC. В нашем примере доменный раздел списка DC содержит контроллеры из периферийных сайтов Spoke2 и Spoke3, а также более близкого сайта Hub. Можно ли запретить серверу DNS вносить в список контроллеры Spoke2 и Spoke3, но при этом записать в список контроллеры сайта Hub? Можно, запретив контроллерам периферийных сайтов регистрировать в домене SRV-записи. Другими словами, если периферийные сайты не зарегистрировали свои доменные SRV-записи (например, _ldap._tcp.dc._msdcs.domain.name), то сервер DNS исключит их из доменного раздела списка DC. В результате доменный раздел будет содержать лишь DC сайта Hub (экран 3). Однако данный метод не мешает контроллерам периферийных сайтов регистрировать сайтовые SRV-записи, поэтому, когда клиент периферийного сайта запрашивает список DC, контроллеры периферийных сайтов отображаются в разделе сайтовых DC списка.

Рисунок 3. Исключение контроллера сайта Spoke1 из списка

Более подробно о том, как запретить DC регистрировать определенные SRV-записи в DNS, рассказано в статье Microsoft Active Directory Branch Office Guide Series: Planning Guide, Chapter 2, «Structural Planning for Branch Office Environments» (http://www.microsoft.com/ technet/treeview/default.asp?url=/technet/prodtechnol/ ad/windows2000/deploy/ adguide/default.asp).

Метод 2. Приоритет DNS. Еще один способ обеспечить переключение периферийных сайтов не друг на друга, а на центральный сайт, заключается в манипулировании в DNS приоритетом SRV-записи контроллера домена. Приоритет, один из элементов SRV-записи, представляет собой произвольное число, и чем меньше это число, тем выше приоритет. По умолчанию приоритет в DNS контроллера домена равен нулю. При прочих равных условиях DC с небольшим значением приоритета будет в списке выше, чем DC с более высоким значением. Таким образом, администратор может реорганизовать список DC, используя поля приоритета SRV-записи.

Рисунок 4. Добавление приоритетов.

На экране 4 показана топология радиальной сети с приоритетами SRV. Контроллеры сайта Hub имеют высокий приоритет 10, а сайты Spoke1, Spoke2 и Spoke3 — более низкий приоритет 20. Эти приоритеты влияют на список DC, поэтому контроллеры домена высокоприоритетного сайта Hub всегда располагаются выше низкоприоритетных DC сайтов Spoke2 и Spoke3. Хотя DC в сайте клиента (Spoke1) также имеет низкий приоритет, DC Spoke1 расположен в списке контроллеров выше высокоприоритетных контроллеров сайта Hub, так как DC сайта клиента всегда расположены в списке выше всех остальных DC. Чтобы иметь возможность управлять полем приоритета SRV-записи для DC, необходимо добавить в раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNetlogonParameters параметр LdapSrvPriority типа REG_DWORD. Следует обратить внимание, что все DC сайта должны иметь одинаковый приоритет для равного представительства в списке DC.

Метод 3. Принудительный охват родственных сайтов. Метод родственных сайтов, который можно комбинировать с двумя другими методами, позволяет построить двухэтапную процедуру переключения DC для более сложных топологий. Например, сайты Spoke1 и Spoke3 расположены рядом друг с другом (экран 5) и соединены широкополосным каналом WAN. Сайт Hub соединен с сайтом Spoke3 узкополосным каналом связи (для простоты я исключил из примера сайт Spoke2, но оставил его контроллер домена в списке DC). Такая топология типична для американских компаний, работающих в Азиатско-Тихоокеанском регионе, где два соседних филиала соединены между собой широкополосным каналом, но связаны с Северной Америкой сравнительно узкополосной линией связи.

Рисунок 5. Подключение соседних контроллеров

В этой ситуации переключение должно осуществляться на ближний родственный сайт, а центральный сайт в Соединенных Штатах должен быть задействован лишь в том случае, если родственный сайт недоступен. Для переключения такого типа нужно сделать DC частью сайта с помощью раздела реестра SiteCoverage. Прежде чем приступить к проектированию, необходимо помешать клиентам выбирать резервный DC (который находится в другом месте и, скорее всего, имеет более длительное время отклика) вместо локальных DC; для клиента оба DC находятся в его сайте и поэтому одинаково доступны. Сделать это можно с помощью приоритета в DNS. Если назначить приоритету контроллеров сайта Spoke1 в DNS значение 15, а контроллерам сайта Spoke3 — 20, то DC родственного сайта будут менее предпочтительны, чем локальные DC. В такой конфигурации локальные DC во внутрисайтовом разделе списка DC всегда будут отображаться первыми.

Для тестирования конфигурации следует пройти по этапам процесса переключения DC. Если все DC доступны, то Client1 будет всегда выбирать Spoke1-DC1, так как он расположен в том же сайте и имеет самый высокий приоритет. Если Spoke1-DC1 недоступен, то Client1 выбирает Spoke3-DC1 или Spoke3-DC2, так как для клиента они находятся внутри его сайта; их низкие приоритеты не имеют значения, поскольку высокоприоритетный Spoke1-DC1 недоступен. Если как Spoke1-DC, так и контроллеры Spoke3 недоступны, то Client1 выберет один из DC сайта Hub, так как они имеют самый низкий приоритет среди доменных DC. Если Spoke1 и Spoke3 недоступны, то у Client1 появятся более важные проблемы, чем недостаточно высокий приоритет DC.

Метод родственных сайтов обеспечивает надежное многоуровневое переключение DC для сайтов с разнообразной топологией. Недостатки метода — трудности настройки конфигурации и обслуживания; кроме того, его трудно объяснить.

Другие факторы

Помимо описанных выше методов, необходимо учесть некоторые факторы, влияющие на выбор DC при переключении контроллеров. Выбор зависит от элементов реестра AutoSiteCoverage и GcSiteCoverage и веса записи SRV контроллера домена в DNS.

AutoSiteCoverage. Если построить сайты без DC для работы таких зависимых от сайта приложений, как DFS, то можно блокировать элемент реестра AutoSiteCoverage типа REG_DWORD, присвоив ему значение 0 для других периферийных DC. Данный параметр находится в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNetlogonParameters. Эта рекомендация основывается на предположении, что аутентификация из периферийного сайта на центральном почти всегда предпочтительнее, чем аутентификация из одного периферийного сайта на другом (за исключением случая с родственными сайтами). Если блокировать параметр AutoSiteCoverage только в периферийных сайтах, то действие параметра AutoSiteCoverage центрального сайта распространяется на лишенный DC периферийный сайт и не позволяет охватить его другому периферийному сайту. Если в сети существуют родственные сайты, то следует блокировать режим AutoSiteCoverage на контроллерах центрального сайта и вручную настроить охват сайтов там, где это необходимо.

GcSiteCoverage. С помощью параметра реестра AutoSiteCoverage можно заставить DC обслуживать сайт, присвоив параметру реестра GcSiteCoverage типа REG_DWORD значение 1. Таким же способом можно указать клиенту GC-сервер для переключения, если назначить элементу реестра GcSiteCoverage типа REG_DWORD значение 1. Этот параметр находится в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNetlogonParameters.

Веса DNS. Еще одно поле SRV-записи DC, с помощью которого можно управлять выбором DC, — вес (weight) DNS. С помощью этого параметра можно упорядочить список DC с одинаковыми приоритетами; DC с более высоким весом в DNS будет находиться выше в списке, чем другие DC с таким же приоритетом, но меньшим весом в DNS. По умолчанию значение веса DNS равно 100. Например, если HUB-DC2 значительно мощнее, чем HUB-DC1 и HUB-DC3, то HUB-DC2 можно присвоить вес 150, чтобы он всегда отображался в верхней части списка контроллеров домена Hub. За исключением случаев, когда между контроллерами доменов имеются существенные аппаратные различия, веса DNS добавляют еще один уровень ручного администрирования к сложной топологии сайта, не давая особых преимуществ. Возможность взвешивания еще не означает, что данный метод будет полезным в любых ситуациях.

Управление контроллерами доменов

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

Шон Дьюби — редактор журнала Windows & .NET Magazine, старший системный инженер компании Intel, специализирующийся на проектировании корпоративных сетей на базе Windows 2000. С ним можно связаться по электронной почте по адресу: spdeuby@winnetmag.com