对于针对 Active Directory DC 进行身份验证的应用程序，显然最好将它们指向主域 DNS 记录，而不是指向特定 DC 以进行故障转移、负载平衡等。
对于那些强制您对 DC 的 IP 进行硬编码的应用程序，最佳做法是什么？我们可以对负载平衡器的 IP 地址进行硬编码，这样如果一个 DC 出现故障，该应用程序仍将能够进行身份验证。有没有更好的替代方案？
答案1
Active Directory 已内置了负载平衡技术。您的 Windows 客户端知道如何在其自己的站点中定位冗余域控制器，以及在第一个域控制器不可用时如何使用另一个域控制器。只要您有冗余 DC，就无需执行额外的负载平衡，例如“群集”DC 等。
在某种程度上，您可以将 Active Directory 站点视为“负载平衡器”，因为该站点中的客户端将随机选择同一站点中的其中一个 DC。如果站点中的所有 DC 都发生故障或站点没有 DC，则客户端将选择另一个站点（下一个最近的站点或随机选择）。
您可以通过将 VIP 放在硬件负载平衡器上，并让该 VIP 在多个域控制器之间进行负载平衡，为加入域的客户端平衡 Active Directory 提供的 DNS 服务。然后在客户端上，将该 VIP 设置为 TCP/IP 配置中的首选 DNS 服务器。
我现在正在为全球基础设施做这件事，而且效果很好。
但那仅有的适用于DNS服务。
不要尝试对域控制器进行负载平衡以进行身份验证。这只会带来麻烦。您至少需要做大量复杂的自定义 SPN 工作，而且会超出 Microsoft 的支持范围。来自你应该阅读这个博客，我将引用他的话：
回到供应商那里并告诉他们您不认为他们是 AD 集成的，您会找到不同的解决方案。
现在对于要求您输入的应用程序IP地址域控制器？好吧，我再重申一下我的观点：
无论是谁编写了一个强制您将域控制器的 IP 地址硬编码到其中的应用程序，都不知道他或她在做什么。
答案2
从来没有一个好的理由对 IP 进行硬编码或使用 IP 来解决 AD 查询。对于不好的做法，没有最佳实践。
答案3
这个问题的其他几个答案似乎都假设除了 Microsoft 感知应用程序之外没有其他世界。不幸的是，事实并非如此，正如原始问题所证明的那样：
这些应用程序的最佳实践是什么强迫你进行硬编码DC 的 IP？
虽然 Microsoft 不支持或建议在 Active Directory 前使用 NLB 解决方案，但确实存在一些用于对非 Microsoft AD 感知应用程序进行身份验证的选项。
答案4
实际需要外部“负载平衡” AD 的情况很少，而且很难正确执行。典型查询的需求可能工作正常，但是典型的 Windows 客户端和应用程序需要执行更新。Windows 客户端尝试与特定 dc 建立亲和性，以便如果它更新某些内容并立即尝试后续操作，它会命中相同的 dc。应用程序开发人员做同样的事情。如果您编写创建用户帐户的代码，然后在 1 毫秒后尝试更改该帐户的密码，则需要命中相同的 dc。
如果您要使用某些负载均衡器解决方案对 AD 进行前端处理，则您有责任确保这些方法和亲和性不会中断。
如果需要的是可用性，而不是平衡负载，那么集群可能更合适（集群的麻烦除外）。
在大型 AD 实施中，更传统的方法是识别大多数消费者，并将他们放在具有自己的 dc 的站点中。例如，如果您有五台 Exchange 服务器，请为这些服务器的子网创建一个站点，并在该站点中放置专用 GC。这同样适用于 SharePoint 等其他服务器。