DNS负载平衡

我们使用dnsmadeeasy.com服务进行DNS负载平衡（共享是正确的话）和DNS故障转移。 所以我们有相同的DNS名称和DNS的多个logging，使您可以轻松configuration故障转移和监控，也是不昂贵的。 我们曾多次拯救过我们。

这里是一个问题：如果您在用户会话中使用会话持久性， 请不要使用DNS负载平衡 。 只使用DNS故障转移，这也很好。

为了回答Ladadadada的关切，你可以设定得很低。 我们使用60秒的ttl。

DNS轮询负载均衡有利于传播负载，但不利于故障转移或冗余。 这是因为DNSlogging被caching了，通常需要很多小时。 如果您的某个负载平衡器发生故障，则50％的用户将已经拥有该IP地址作为您域的结果，并将继续使用它，直到其caching过期。

我知道Cisco CSS负载均衡器可以configuration为冗余对，以便每个负载均衡器监控另一个的健康状况。 其中只有一个在任何时候处理stream量，但如果这个stream量下降，另一个立即接pipe。 这种设置只需要一个IP地址。

我不了解ACE产品线，但是如果他们不能做同样的事情，我会感到惊讶。 一个快速的谷歌build议它支持某种故障转移 。

思科ACE通常将（AFAIK）部署在主动 – 被动对中，所以如果一方出现故障，另一方应接pipe。 这是独立于DNS（DNS将只是通过ACE提供的另一种服务types）。 如果两台DNS服务器都在同一个数据中心（或者可能是城域数据中心），这将是合适的。

有一件事要记住ACE（我想这取决于你的部署），但是如果你需要知道客户端IP（也许你正在做不同的客户端视图的分裂DNS），那么你将失去这种可见性，您需要将内部和外部客户端指向不同的（负载平衡/共享/冗余）服务器（这更接近DNS的最佳实践，因为您希望内部（recursion，caching）服务器与您的外部服务器分离（权威）DNS服务器。

dynamicDNS更新也是需要考虑的事情（集群中的状态在哪里？）

不要使用DNS负载平衡，因为它不能对某些设备的（不可用）可用性做出反应。 使用VRRP代替它（这两个负载均衡器将共享一个IP，当主站死亡时，从站将使用此IP），并将您的DNSlogging指向该虚拟IP。