我们目前有许多Web应用程序使用LDAP进行身份validation。 为此，我们使用LDAPS端口（ 636 ）将Web应用程序指向我们的AD域控制器之一。
当我们必须更新域控制器时，这已经引起了我们的问题，因为更多的Web应用程序可能依赖于任何DC。
我们希望将我们的Web应用程序指向集群“虚拟”IP。 该群集将至less包含两台服务器（以便每个群集服务器可以被轮换出来并更新）。 然后，集群服务器将代理到DC的LDAPS连接，并能够找出哪一个可用。
对于任何具有为AD的LDAP接口创buildHA群集经验的人员：
也许我的问题最初不够清楚。 我为此道歉。
这些Web应用程序不是由我们开发的，也不是AD识别的。 他们只要求一个LDAP服务器的主机名/ IP地址。 不幸的是，我们必须处理这个限制。 我理解SRV records是如何工作的，但是，这些不是我们的应用程序，在这种情况下并不能帮助我们。
我们强迫开发人员修改他们的应用程序使其能够识别AD也是不现实的。
唯一的select是在基础设施内解决与软件相对的问题。 我的问题是针对任何具体做到的人。
我们使用Cisco IOS的服务器负载均衡器（SLB）来对付我们的OpenLDAP服务器。
LDAP是LDAP，它也适用于Microsoft的Active Directory。
其他制造商提供类似的产品/function。 平衡tcp 389/636与平衡tcp 80/443（或任何其他tcp）是一样的。
您可能有一些证书问题，但工作。 你可能会告诉应用程序不那么警惕。 （可能已经，不知道您的AD证书如何签名或您信任哪个CA.）或让您的AD服务器使用具有适当的subjectAlternativeName字段的证书。
您应该能够将您的Web应用程序服务器指向Active Directory域的FQDN。 这应该连接到一个可用的DC。
例如，您的域可能有几个DC：
dc1.example.com
dc2.example.com
不要直接将你的web服务器指向dc1或dc2，只需将它们指向example.com（尝试在端口636上telnet到example.com – 你将得到一个到DC的连接）。 我认为这基本上是循环赛DNS。
我必须承认，如果DC离线，我不知道会发生什么。 DNSlogging可能需要一些时间才能反映出来，如果确实是这样的话。 它可能是值得的testing，而不是把负载平衡器之间。
正确的方法是使用DNS SRVlogging来查找域控制器名称和端口，以及按照什么顺序查明要使用的服务器。 不幸的是，没有多lessLDAP应用程序似乎支持SRVlogging查找。
Active Directory域控制器的SRVlogging是_ldap._tcp.domain.tld 。 这将返回主机和端口的列表，以及每个的优先级和权重（可以使用组策略设置这些值），这些值一起指示要使用哪个服务器。
如果一个域控制器不可用，那么应用程序必须足够健壮以执行Windows客户端在内部执行的操作 – 它会尝试连接到另一个域控制器。
这种方式的工作方式是当应用程序启动时，应用程序的目录服务访问组件将执行以下操作：
然后在执行绑定时使用这些已知的良好服务器，将服务器embedded到绑定path中。 如果发生exception，并且是指示dc问题的types之一（服务器不可操作，繁忙，超时等），则将该dc添加到脱机列表中，并尝试使用其他dc中的一个进行操作。
一个可能的解决scheme是LDAP代理服务器。 那里没有很多，但肯定会做的。 这里有一个，有点矫枉过正 – http://www.unboundid.com/products/directory-proxy-server.php 。 确保这个LDAP代理服务器有更便宜的开源替代品。
编辑：只是一个想法，在你的应用程序你有一个位置inputLDAP URI？ 如果是这样，你能不能input一个由空格分隔的服务器序列：ldap：//123..456.789.111 ldap：//123.456.789.222 ldap：//123.456.789.444