Поделиться через

Правильное размещение контроллеров домена и рекомендации по сайту

Правильное определение сайта имеет решающее значение для производительности. Клиенты, выпадающие из сайта, могут испытывать низкую производительность для проверки подлинности и запросов. Кроме того, при внедрении IPv6 на клиентах запрос может поступать из IPv4 или IPv6-адреса, а Active Directory должен иметь сайты, правильно определенные для IPv6. Операционная система предпочитает IPv6 для IPv4 при настройке обоих.

Начиная с Windows Server 2008 контроллер домена пытается использовать разрешение имен для обратного поиска, чтобы определить сайт, в который должен находиться клиент. Это может привести к нехватке пула потоков ATQ и привести к тому, что контроллер домена не отвечает. Соответствующее решение заключается в правильном определении топологии сайта для IPv6. В качестве обходного решения можно оптимизировать инфраструктуру разрешения имен, чтобы быстро реагировать на запросы контроллера домена. Дополнительные сведения см. в разделе Windows Server 2008 или Windows Server 2008 R2, отложенный ответ на запросы LDAP или Kerberos.

Дополнительное внимание заключается в поиске контроллеров данных чтения и записи для сценариев, в которых используются контроллеры домена. Для некоторых операций требуется доступ к записываемому контроллеру домена или нацеливать на контроллер домена, доступный для записи, если достаточно контроллер домена только для чтения. Оптимизация этих сценариев займет два пути:

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

Дополнительные сведения см. в справочнике по следующим причинам:

Оптимизация для рефералов

Ссылки — это перенаправление запросов LDAP, когда контроллер домена не размещает копию запроса секции. При возврате ссылки он содержит различающееся имя секции, DNS-имя и номер порта. Клиент использует эти сведения для продолжения запроса на сервере, на котором размещается секция. Это сценарий DCLocator, и все определения сайтов рекомендаций и размещение контроллера домена поддерживаются, но приложения, которые зависят от рефералов, часто упускаются из виду. Рекомендуется убедиться, что топология AD, включая определения сайтов и размещение контроллера домена, правильно отражает потребности клиента. Кроме того, это может включать в себя наличие контроллеров домена из нескольких доменов на одном сайте, настройку параметров DNS или перемещение сайта приложения.

Рекомендации по оптимизации доверия

В сценарии внутри леса отношения доверия обрабатываются в соответствии со следующей иерархией домена: Дочерний домен — дочерний домен> —> корневой домен леса —> дочерний домен — дочерний домен —> домен Grand-Child. Это означает, что защищенные каналы в корневом каталоге леса и каждый родительский элемент могут быть перегружены из-за агрегирования запросов проверки подлинности, передаваемых контроллерам домена в иерархии доверия. Это также может привести к задержкам в активных каталогах крупной географической дисперсии, если проверка подлинности также должна передавать весьма скрытые ссылки, чтобы повлиять на приведенный выше поток. Перегрузки могут возникать в сценариях доверия между лесами и нижнего уровня. Следующие рекомендации применяются ко всем сценариям:

  • Правильно настройте MaxConcurrentAPI для поддержки нагрузки по защищенному каналу. Дополнительные сведения см. в разделе "Настройка производительности для проверки подлинности NTLM" с помощью параметра MaxConcurrentApi.

  • Создайте ярлыки доверия в соответствии с нагрузкой.

  • Убедитесь, что каждый контроллер домена в домене может выполнять разрешение имен и взаимодействовать с контроллерами домена в доверенном домене.

  • Убедитесь, что рекомендации по локальности учитываются для доверия.

  • Включите Kerberos, где это возможно и свести к минимуму использование безопасного канала, чтобы снизить риск возникновения узких мест MaxConcurrentAPI.

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

  • Убедитесь, что разрешение имен DNS и WINS, которые используют доверенные контроллеры домена, могут разрешать точный список контроллеров домена для доверенного домена.

    • Статически добавленные записи имеют тенденцию к устареванию и повторному добавлению проблем с подключением со временем. Dns-пересылки, динамические DNS-серверы и объединение инфраструктуры WINS/DNS более поддерживаются в долгосрочной перспективе.

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

  • Контроллеры домена в доверенном домене попытаются найти контроллеры домена в доверенном домене, которые находятся на том же сайте, а затем вернуться к универсальным указателям.

    • Дополнительные сведения о работе DCLocator см. в разделе "Поиск контроллера домена" на ближайшем сайте.

    • Конвергентные имена сайтов между доверенными и доверенными доменами, чтобы отразить контроллер домена в том же расположении. Убедитесь, что сопоставления подсетей и IP-адресов правильно связаны с сайтами в обоих лесах. Дополнительные сведения см. в разделе "Указатель домена в лесу".

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

    • Используйте DnsAvoidRegisterRecords для устранения плохой работы или контроллеров домена с высокой задержкой, таких как на вспомогательных сайтах, от рекламы до универсальных указателей. Дополнительные сведения см. в статье "Оптимизация расположения контроллера домена или глобального каталога, который находится за пределами сайта клиента".

      Примечание.

      Существует практический предел около 50 до количества контроллеров домена, которые клиент может использовать. Они должны быть самыми оптимальными и самыми высокими контроллерами домена.

    • Рассмотрите возможность размещения контроллеров домена из доверенных и доверенных доменов в том же физическом расположении.

Для всех сценариев доверия учетные данные направляются в соответствии с доменом, указанным в запросах проверки подлинности. Это также верно для запросов к API LookupAccountName и LsaLookupName (а также другим пользователям). Когда параметры домена для этих API передают значение NULL, контроллер домена попытается найти имя учетной записи, указанное в каждом доступном доверенном домене.

Дополнительные справочники