Балансировка нагрузки при аутентификации Active Directory и отработка отказа

8

Для приложений, которые проходят аутентификацию на контроллере Active Directory, очевидно, что было бы лучше просто указать их на DNS-запись основного домена, а не на конкретный DC для восстановления после сбоя, балансировки нагрузки и т. Д.

Каковы лучшие практики для тех приложений, которые заставляют вас жестко кодировать IP-адрес DC? Вместо этого мы могли бы жестко запрограммировать IP-адрес балансировщика нагрузки, так что, если один DC отключится, это приложение все равно сможет аутентифицироваться. Есть ли лучшие альтернативы?

— вышка
источник

2

Кто бы ни написал приложение, которое заставляет вас жестко закодировать IP-адрес контроллера домена, оно не знает, что он или она делает.

— Райан Райс

1

Найдите разработчика приложения и попросите его исправить это.

— Майкл Хэмптон

Это в основном для некоторых старых приложений и старых блоков NAS, которые мы еще не готовы заменить.

— Деррик

8

Active Directory уже имеет встроенные методы балансировки нагрузки. Ваш клиент Windows знает, как найти избыточные контроллеры домена на своем собственном сайте и как использовать другой, если первый недоступен. Нет необходимости выполнять дополнительную балансировку нагрузки, например «кластерные» контроллеры домена и т. Д., Если у вас есть резервные контроллеры домена.

В некотором смысле вы можете рассматривать сайт Active Directory как «балансировщик нагрузки», потому что клиенты на этом сайте случайным образом выбирают один из контроллеров домена на одном сайте. Если все DC в сайте выходят из строя или если у сайта нет DC, клиенты выбирают другой сайт (ближайший ближайший сайт или случайный выбор).

Вы можете балансировать нагрузку службы DNS, предоставленной Active Directory для клиентов, присоединяющихся к домену, установив VIP на аппаратный балансировщик нагрузки и имея такой баланс нагрузки VIP между несколькими контроллерами домена. Затем на своих клиентах установите этот VIP в качестве предпочтительного DNS-сервера в конфигурации TCP / IP.

Я делаю это прямо сейчас для глобальной инфраструктуры, и она прекрасно работает.

Но это относится только к службе DNS.

Не пытайтесь загрузить баланс ваших контроллеров домена для аутентификации. Это напрашивается на неприятности. По крайней мере, вам придется выполнить много сложных пользовательских SPN-работ, и вы будете выходить за пределы поддержки Microsoft. Из этого блога, который вы должны прочитать , я процитирую его:

Вернитесь к поставщикам и скажите им, что вы не считаете их интегрированными в AD, и вы найдете другое решение.

Теперь что касается приложений, которые просят вас ввести IP-адрес контроллера домена? Хорошо, я просто повторю свой комментарий:

Кто бы ни написал приложение, которое заставляет вас жестко закодировать IP-адрес контроллера домена, оно не знает, что он или она делает.

— Райан Райс
источник

Первоначальный вопрос был «Каковы лучшие практики для тех приложений, которые заставляют вас жестко кодировать IP-адрес DC?». Предполагать, что нет законных приложений, которые не поддерживают динамическое обнаружение, является неверным предположением. Существует множество приложений, отличных от Windows, которые хотели бы выполнять аутентификацию в Active Directory. Итак, каков наилучший способ заставить эти приложения работать, когда динамическое обнаружение постоянного тока не вариант?

— Dscoduc

@ Dscoduc Получите лучшие приложения.

— Райан Райс

3

никогда не было веской причины жестко кодировать IP или использовать IP для разрешения запросов AD. Нет лучших практик для плохих практик.

— Джим Б
источник

1

«Нет лучших практик для плохих практик». Цитата дня, сэр.

— mfinni

1

Некоторые из других ответов на этот вопрос, похоже, предполагают, что нет другого мира, кроме приложений, знакомых Microsoft. К сожалению, это не так, как доказательство исходного вопроса:

Каковы лучшие практики для тех приложений, которые заставляют вас жестко кодировать IP-адрес DC?

Хотя Microsoft не поддерживает и не рекомендует использовать решение NLB перед Active Directory, на самом деле, по-видимому, существуют некоторые варианты аутентификации приложений, не поддерживающих Microsoft AD.

— Dscoduc
источник

В продолжение этого вопроса и моего опубликованного ответа - моя компания внедрила надежное решение F5 LDAP Local Traffic Manager, которое успешно работает с Active Directory для систем, отличных от Windows, неспособных использовать службу DCLocator. У нас есть шесть LTM, обрабатывающих трафик по всему миру без каких-либо проблем.

— Dscoduc

0

Фактическая потребность во внешней AD «Балансировка нагрузки» встречается редко, и это трудно сделать должным образом. Потребность в типичных запросах может работать нормально, однако типичный клиент Windows и приложения должны выполнять обновления. Клиент Windows пытается установить сходство с конкретным постоянным током, поэтому, если он что-то обновляет и сразу же пытается выполнить следующую операцию, он попадает в тот же постоянный ток. Разработчики приложений делают то же самое. Если вы пишете код, который создает учетную запись пользователя, а затем попытаетесь изменить пароль для этой учетной записи через 1 мс, вам нужно нажать тот же постоянный ток.

Если вы использовали интерфейс AD с каким-либо решением для балансировки нагрузки, вы берете на себя ответственность за обеспечение того, чтобы эти подходы и сходства не нарушались.

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

В крупных реализациях AD более традиционный подход заключается в идентификации большинства потребителей и размещении их на сайте с их собственными постоянными клиентами. Например, если у вас есть пять серверов Exchange, создайте сайт для подсетей для этих серверов и поместите выделенные GC на этот сайт. То же самое относится и к другим серверам, таким как SharePoint.

— Грег Аскью
источник