我知道，由于Kerberos和SPN问题，Windows域控制器上的LDAP负载均衡或故障转移通常不是一个好主意。
但是，我有很多使用LDAP进行身份validation和授权的非Windows应用程序。 他们只是指向一个单一的域控制器现在，将是很好的有一个VIP和一个与我所有的DC背后的池。
那么当我看到这个时，这个交易是什么？
https://devcentral.f5.com/questions/ad-dcs-behind-f5
F5做一些特别的事情吗？ 它是否会回落到NTLM？ 或者它只是使用简单的LDAP绑定到AD？ （或SLDAP绑定）。
什么是非Windows客户端使用LDAP的最佳方式？ 他们是否应该开箱即可使用DNS定位器SRVlogging？ AD-LDS应该部署和负载均衡吗？
有什么我失踪？
是的，想要与Active Directory进行交互的应用程序确实应该devise为使用适当的DC位置过程（这是有据可查的）; 不幸的是，他们往往不是。
您通常可以通过将LDAP应用程序指向Active Directory域名而不是特定DC来解决此问题，因为每个DC都会自动为指向其IP地址的域名注册AN Alogging，所以这将作为DNS循环; 但是，这会导致两个重要的问题：
稍微好一点的解决scheme是为LDAP应用程序创build自己的DNSlogging，作为指向特定DC的CNAMElogging，例如指向dc1.example.com ldap.example.com ，并设置一个缓慢的TTL（fe 60秒）; 您可以将您的应用程序configuration为使用ldap.example.com满足其所有LDAP需求。 如果/当DC1发生故障时，您可以将ldap.example.com重新映射到dc2.example.com ，慢速TTL将确保应用程序尽快知道更改，从而最大限度地减less停机时间。
无论如何，最好避免使用负载均衡解决scheme，因为LDAP根本没有devise成与他们一起工作，并且可能会加载任何问题。
几乎所有我见过的非Windows LDAPauthentication产品都能够使用DNS条目。 而不是指向一个特定的服务器，你可以指向你的域的根。 这应该在绝大多数情况下工作。
这是事实，因为如果你在你的域名的根目录（例如example.com）进行查找，它应该返回你域控制器的所有IP地址。 这允许标准的轮询DNS接pipe，而不需要任何专门的设置。
使用负载平衡器的一个挑战是，根据活动，一些应用程序可能会请求一个DirectoryEntry句柄。 DirectoryEntry包含服务器名称。 这对于更新更常见，但也可能发生读/查询。 在这种情况下显然你不通过负载平衡器。 对于authentication是否足够好？ 也许。
我了解到，如果您提供服务，人们可能会将其用于您所期望的以外。 那么你设置的“仅限authentication”VIP？ 也许有人决定用它来做别的事情。 这真的很重要。 如果爆炸会发生什么？
另一个问题是健康检查是什么？ 域控制器在端口389/636上运行并不罕见，但运行不正常。 所以直接的端口检查可能不够好。
传统上，Active Directory连接弹性（DC Locator进程）被推送到客户端。 当你开始修改它以使其“高度可用”时，你就拥有了问题的所有权。 而其中的一些问题可能难以诊断和解决。 谁会支持你？ F5？ 微软？ 祝你好运。
这是关于高可用性还是性能？
为了performance，我想强调一下：
我有很多非Windows应用程序使用LDAP进行身份validation和授权。 他们现在只是指向一个单一的域控制器。
这里明显的快速解决scheme是将您的一些应用程序指向您的其他DC。 当然，这并不理想，因为如果DC发生故障，它会使应用程序容易受到攻击，但这是帮助您立即分散负载的简单方法。
为了实现高可用性，您可以将应用程序指向域名或（甚至更好）域名的cname。 这不是很好，因为如果出现问题，这意味着需要手动调整dns，但是这会使响应变得更容易。
您可以通过使用cnamelogging将这些技术组合到多个DC中。 负载分散开来，您可以轻松调整每个DC发生中断时的cnamelogging。
在这种情况下，我有3台服务器。
此外，使用域名通常是不好的，因为如果应用程序不是站点感知的（大多数不是），它将命中返回列表中的第一个DC。 这可能在国内的任何地方，这将是广域网负载和延迟不好。