У меня есть два сервера Active Directory с репликацией, ad2 и ad4.
У ad4 более высокая задержка, чем у ad2, поскольку он находится вне офиса.
Все клиенты должны войти в систему и пройти аутентификацию на сервере ad2.
Проблема в том, что время от времени ad4 будет сервером входа в систему.
обслуживание запроса на вход.
Я могу сказать, потому что сценарий входа в систему показывает диалоговое окно сообщения с
сервер объявлений, обслуживающий запрос на вход.
Есть ли какие-то настройки порога (количество пользователей, время ожидания)
что я могу изменить на ad2 и ad4, чтобы всегда использовать ad2
запросы на вход / аутентификация?
Похоже, вам нужно использовать оснастку «Active Directory - сайты и службы», чтобы определить подсети, физические местоположения (известные как «сайты») с хорошо связанными подсетями и соединения между сайтами (известные как «ссылки сайтов») которые составляют физическую сеть, лежащую в основе вашей Active Directory (AD), чтобы контроллеры домена могли принимать правильные решения о репликации, а клиенты могли принимать правильные решения о том, какой серверный компьютер (-ы) использовать для обслуживания входа в систему. Без описания физической топологии вашей сети все различные части серверных и клиентских операционных систем, которые полагаются на связь с компьютерами контроллера домена (DC), в основном «летают вслепую» и не имеют возможности судить о том, какие DC находятся физически близко и , таким образом, более эффективно общаться с.
Как только вы проинформируете AD о физическом расположении сети, вы обнаружите, что все «просто работает» намного эффективнее. Не беспокойтесь слишком сильно о балансировке нагрузки для "количества пользователей" - это не будет иметь значения, если вы определите сайты и подсети (если только у вас нет действительно очень плохого соотношения количества пользователей и контроллеров домена. или очень высокая частота входов в систему). Я думаю, что большинство ваших проблем связано с тем, что вы ничего не сказали AD о физической топологии вашей сети. (Есть несколько более глубоких «настроек», которые можно выполнить в DNS, чтобы повлиять на выбор контроллеров домена на данном сайте, но, в основном, клиенты «бросают кости» и общаются с любым контроллером домена на своем сайте. Для меня этого всегда было достаточно. производственные развертывания.)
Вся эта настройка сайтов, ссылок на сайты и подсетей на самом деле просто меняет то, что хранится в DNS. Клиенты используют DNS, чтобы определить, на каком сайте они находятся (просматривая свою подсеть), и, как только они это узнают, они используют DNS для поиска контроллеров домена для связи. Фактические записи DNS, которые выполняют эту работу, - это записи ресурсов (RR) «SRV», хранящиеся в зоне DNS «_msdcs.domain.com». Очевидно, что для того, чтобы все это работало, клиенты должны иметь доступ к DNS-серверу, который может возвращать записи для DNS-зоны «_msdcs.domain.com». Обычно предпочтительнее использовать DC в качестве DNS-сервера (поскольку Microsoft сделала эту конфигурацию «просто работающей» очень хорошо), чтобы не указывать какие-либо DNS-серверы, отличные от DC, в конфигурациях клиентской сети (т. Е. Не помещайте DNS-серверы ISP в качестве «вторичных» DNS-серверов в области DHCP или «жестко запрограммированных» на клиентах / серверах), и всегда убедитесь, что в каждом физическом месте есть DNS-сервер на месте, так что сбой WAN / VPN не удаляет все службы DNS для клиентов в этом физическом месте.
Здесь я предполагаю, что вы не соединили одну IP-подсеть в нескольких местах. Если вы это сделали, вам будет лучше изменить топологию сети для использования нескольких подсетей, чем пытаться «взломать» AD для обработки такой странной топологии.
Роберт Мойр написал хороший обзор того, что «означают» сайты Active Directory по другому вопросу. Я бы посмотрел там.
Помимо этого, вам нужно подумать о том, чтобы хотя бы один DC на каждом сайте был отмечен как Глобальный каталог (GC), а также. Процедура установки DC в качестве GC действительно прост, и вы должны иметь по одному на каждом сайте (даже если вы не обязательно понимаете, для чего они нужны). Пометить каждый DC как GC - не лучшая идея, хотя в такой маленькой среде, как ваша, это не сильно изменится. Однако в более крупных средах больше не обязательно лучше, когда речь идет о репликах GC.
То, что вы описываете, скорее всего, совершенно нормально. Если локальный DC не отвечает в течение короткого периода времени, клиент свяжется с любым другим DC в домене, независимо от местоположения. (В Windows 2008 есть новый параметр, который делает следующее ближайшее местоположение более эффективным). На самом деле существует очень сложный алгоритм, которому следуют клиенты Windows, который называется DC Locator.
Можно сделать процесс более детерминированным, настроив стоимость сайтов и ссылок на сайты (если вы этого не сделали), а также используя приоритет и вес записей DNS SRV в поддомене _msdcs. Клиенты пытаются связаться с сервером с самым низким приоритетом. Вес - это механизм балансировки нагрузки, который используется при выборе целевого хоста из тех, которые имеют такой же приоритет. Клиенты случайным образом выбирают записи SRV, которые определяют целевые хосты, с которыми необходимо связаться, с вероятностью, пропорциональной весу.
DNS возвращает список IP-адресов, которые соответствуют целевому домену в записях SRV (то есть IP-адреса контроллеров домена в указанном домене), которые отсортированы по приоритету и весу. Клиент проверяет каждый IP-адрес в возвращенном порядке. Ping - это запрос UDP LDAP на порт 389. Клиент проверяет каждый контроллер домена из списка. После каждого эхо-запроса клиент ждет одну десятую секунды ответа на эхо-запрос (или любой предыдущий эхо-запрос), а затем пингует следующий контроллер домена. Случайный выбор контроллеров домена обеспечивает первый уровень балансировки нагрузки. Выполнение нескольких запросов ping в быстрой последовательности гарантирует, что алгоритм обнаружения завершится через конечный промежуток времени.
Обратите внимание, что когда клиент устанавливает соединение с контроллером домена, он создает сродство (иногда называемое «закреплением») с этим контроллером домена. По умолчанию клиенты Windows Vista / 2008 и более поздних версий будут пытаться повторно обнаруживать контроллеры домена каждые 12 часов, и это можно настроить с помощью групповой политики. Существует также исправление, позволяющее включить такое поведение в Windows XP / 2003.
Больше информации:
Как оптимизировать расположение контроллера домена или глобального каталога, который находится за пределами сайта клиента http://support.microsoft.com/kb/306602
Записи ресурсов SRV
http://technet.microsoft.com/en-us/library/cc961719.aspx
Процесс определения местоположения контроллера домена
http://technet.microsoft.com/en-us/library/cc978011.aspx
Функция DsGetDcName
http://msdn.microsoft.com/en-us/library/windows/desktop/ms675983%28v=vs.85%29.aspx
Предоставление клиентам возможности найти следующий ближайший контроллер домена
http://technet.microsoft.com/en-us/library/cc733142%28WS.10%29.aspx
Типы локаторов
http://technet.microsoft.com/en-us/library/cc978019.aspx
Я собираюсь предположить (возможно, ошибочно), что у вас есть клиенты AD на удаленном сайте, и именно поэтому у вас есть DC на этом сайте. Если это так, то, как заявил Эван, вы захотите настроить сайты и службы Active Directory для обоих сайтов / подсетей. Затем KCC построит топологию репликации между контроллерами домена на основе конфигурации ADS&S. В нынешнем виде у вас, вероятно, есть трафик репликации, проходящий через глобальную сеть, основанный на топологии внутрисайтовой репликации, а не на топологии межсайтовой репликации.
Затем локатор DC на каждом клиенте найдет DC на ближайшем к нему сайте для аутентификации. Обязательно настройте контроллер домена на удаленном сайте как GC (или включите кэширование универсального членства в группе в настройках сайта NTDS для удаленного сайта).
Если я ошибаюсь и у вас нет клиентов AD на удаленном сайте, почему у вас есть DC на удаленном сайте?