我对Web应用程序的cross-colo故障切换策略感兴趣，例如，如果主站点无法将用户无缝地连接到另一个colo的故障切换站点。Cross-colo故障切换设计，DNS级别故障切换？
事情的应用程序端看起来主要是在colos和服务之间建立主 - 从数据库的基础上进行设计的，旨在恢复并能够在中途获取。我试图找出将流量从主站点转移到故障转移站点的策略。 DNS故障转移，即使是低TTL，似乎也带有fair bit of latency。
假设主colo中的服务器无法访问，您建议如何快速移动colos之间的流量？
如果您有关于cross-colo故障转移的其他有趣的经验/智慧话语，我很乐意听到这些。
DNS机制是麻烦的，即使你把低TTL值的区域文件。
原因是许多应用程序（例如MSIE）维护自己的缓存忽略TTL。其他软件将执行一次gethostbyname()或同等调用并存储结果，直到程序重新启动。
更糟糕的是，许多ISP的递归DNS服务器已知忽略低于其自己偏好最小值的TTL并施加自己的更高TTL。
最终如果网站要从两个数据中心运行而不是更改其IP地址，那么您需要查看通过全局BGP4路由通告安排“多宿主”。
使用多宿主时，您需要至少获得/ 24个“提供程序独立”（又名“PI”）IP地址空间的网络块，然后让它只从备份站点向全局路由表发布，网站下线。
如果可以的话，多播 - http://en.wikipedia.org/wiki/Multicast或任 - 基于http://en.wikipedia.org/wiki/Anycast
至于DNS，我喜欢引用，"Why DNS Based Global Server Load Balancing Doesn't Work"。对于其他事情 - 使用BGP。为了使用BGP进行负载均衡，设计网络仍然不是一件容易的事，我自己也不是这方面的专家。它也比维基百科可以告诉你更复杂，但也有在网络上一对夫妇有趣的文章，详细介绍了如何可以做到：
总是有更多，如果你搜索BGP和负载平衡。网络上还有一些白皮书，描述了Akamai如何进行全球负载平衡（我相信它也是BGP），这对阅读和了解总是很有趣的。
除了您可以使用软件和硬件实现的显而易见的概念之外，您可能还需要检查ISP /提供程序/ colo是否可以设置。
此外，没有冒犯您的colo选择（谁是供应商？），但大多数地方应该设置为处理停机时间等，他们不应该要求你采取行动。当然，洪水或外星人总是可以罢工，但在这种情况下，我想还有更重要的问题。 :-)
多播是没有用的 - 互联网的其余部分将无视它 – Alnitak 2008-12-30 20:49:30
多播将取决于colos的对等。 Anycast可以在整个互联网上运行。你可能错过了我的帖子的那一部分，但是我在完成之前意外地保存了帖子...... :-) – 2008-12-30 20:50:42
确实 - 那不是那里。然而，任播通常用于无状态的UDP服务，并且与TCP不兼容（请参阅维基百科文章中的注意事项）。 – Alnitak 2008-12-30 20:55:36