Для приложений, которые проходят проверку подлинности с помощью контроллера домена Active Directory, очевидно, было бы лучше просто указать им на DNS-запись основного домена, а не на конкретный контроллер домена для переключения при отказе, балансировки нагрузки и т. Д.
Каковы лучшие практики для тех приложений, которые заставляют вас жестко кодировать IP-адрес контроллера домена? Вместо этого мы могли бы жестко запрограммировать IP-адрес балансировщика нагрузки, чтобы в случае отказа одного из контроллеров домена это приложение все еще могло аутентифицироваться. Есть ли лучшие альтернативы?
Active Directory уже имеет встроенные методы балансировки нагрузки. Ваш клиент Windows знает, как найти избыточные контроллеры домена на собственном сайте и как использовать другой, если первый недоступен. Нет необходимости выполнять дополнительную балансировку нагрузки, например «кластеризованные» контроллеры домена и т. Д., Если у вас есть резервные контроллеры домена.
В некотором смысле вы можете думать о сайте Active Directory как о «балансировщике нагрузки», поскольку клиенты на этом сайте случайным образом выбирают один из контроллеров домена на том же сайте. Если все контроллеры домена на сайте выйдут из строя или если на сайте нет контроллеров домена, то клиенты выберут другой сайт (либо следующий ближайший сайт, либо случайным образом).
Вы можете распределить нагрузку на службу DNS, предоставляемую Active Directory, для присоединенных к домену клиентов, поместив виртуальный IP-адрес в аппаратный балансировщик нагрузки и обеспечив балансировку нагрузки этого виртуального IP-адреса между несколькими контроллерами домена. Затем на своих клиентах укажите этот VIP в качестве предпочтительного DNS-сервера в конфигурации TCP / IP.
Я делаю это прямо сейчас для глобальной инфраструктуры, и она отлично работает.
Но это только относится к службе DNS.
Не пытайтесь балансировать нагрузку на контроллеры домена для аутентификации. Это напрашивается на неприятности. Вам, по крайней мере, придется выполнять много сложной работы с пользовательским SPN, и вы выскочите за рамки поддержки Microsoft. Из этот блог, который вы должны прочитатьЯ процитирую его:
Вернитесь к поставщикам и скажите им, что вы не считаете их интегрированными с AD, и вы найдете другое решение.
Теперь что касается приложений, которые просят вас ввести айпи адрес контроллера домена? Что ж, я просто повторю свой комментарий:
Кто бы ни написал приложение, которое заставляет вас жестко закодировать в него IP-адрес контроллера домена, не знает, что он или она делает.
никогда не было веских причин для жесткого кодирования IP или использования IP для разрешения запросов AD. Лучших практик для плохих практик не существует.
Некоторые другие ответы на этот вопрос, похоже, предполагают, что нет другого мира, кроме приложений, поддерживающих Microsoft. К сожалению, это не так, о чем свидетельствует исходный вопрос:
Каковы лучшие практики для тех приложений, которые заставить вас жестко кодировать IP DC?
Хотя Microsoft не поддерживает и не рекомендует использовать решение NLB перед Active Directory, действительно, похоже, существуют некоторые варианты аутентификации приложений, не поддерживающих Microsoft AD.
Фактическая потребность во внешнем AD с «балансировкой нагрузки» возникает редко, и ее сложно выполнить должным образом. Обычные запросы могут работать нормально, однако типичный клиент Windows и приложения должны выполнять обновления. Клиент Windows пытается установить связь с определенным постоянным током, так что если он что-то обновляет и сразу же пытается выполнить следующую операцию, он попадает в тот же постоянный ток. Разработчики приложений делают то же самое. Если вы напишете код, который создает учетную запись пользователя, а затем попытаетесь изменить пароль для этой учетной записи через 1 мс, вам нужно будет нажать тот же постоянный ток.
Если вы использовали интерфейс AD с помощью некоторого решения для балансировки нагрузки, вы берете на себя ответственность за то, чтобы эти подходы и сходства не нарушались.
Если необходима доступность, а не балансировка нагрузки, кластеризация может быть более подходящей (не говоря уже о кластере, который может содержать червей).
В крупных реализациях AD более традиционным подходом является определение большинства потребителей и размещение их на сайте с их собственными DC. Например, если у вас пять серверов Exchange, создайте сайт для подсетей для этих серверов и разместите на этом сайте выделенные GC. То же самое применимо и к другим серверам, таким как SharePoint.