Назад | Перейти на главную страницу

AD LDS Высокая доступность

В настоящее время мы используем CAS для аутентификации в нескольких каталогах. AD для внутренних пользователей, AD LDS для внешних пользователей. Я читал, что NLB - возможное решение, но мне интересно, возможно ли это с записями SRV, и как насчет того, чтобы вы правильно это настроили. С нашим каталогом AD я могу выполнить привязку к olddomain.local и попасть на любой из контроллеров домена в домене. Мы не хотим жестко кодировать имена серверов в CAS, поэтому конечная цель - связать с LDSdomain.gov.

nslookup -type=srv _ldap._tcp.LDSdomain.gov

возвращается

_ldap._tcp.LDSdomain.gov SRV service location:
      priority       = 0
      weight         = 100
      port           = 1025
      svr hostname   = server01
_ldap._tcp.LDSdomain.gov SRV service location:
      priority       = 0
      weight         = 200
      port           = 1025
      svr hostname   = server02

NLB - ваш лучший вариант здесь. С DNS или SCP клиенты могут выбирать случайный сервер для подключения. При необходимости LBS можно настроить на аварийное переключение. Хотя вы можете настроить несколько экземпляров AD LDS как один набор конфигурации, иногда (чаще, чем хотелось бы) приложения будут использовать «случайный сервер» для выполнения нескольких обновлений атрибутов в форме. Например, я добавляю пользователя jsmith. Если кто-то еще добавляет пользователя jsmith, не будет сообщений о конфликте, потому что я нахожусь в другом экземпляре. Когда происходит репликация, один из них переименовывается в cnf: GUID, и теперь его нужно разобрать. Это то же самое, что и в обычном AD, однако, как правило, некоторые администраторы замечают, что пользователь jsmith не может войти в систему. Я видел дрянные приложения, использующие LDS с DNS, в которых из-за отсутствия обслуживания остается много объектов cnf. NLB решает эту проблему, позволяя переключаться при отказе вместо циклического перебора. Как правило, перегрузить LDS довольно сложно.