我对Web应用程序的跨结构故障转移策略感兴趣，这样如果主站点失败，用户将无缝地降落到另一个colo中的故障转移站点。
事情的应用程序方面看起来主要是通过colos和服务之间的主从数据库设置来设计，以便恢复并能够在中流中获取。我正在试图找出将流量从主站点转移到故障转移站点的策略。即使TTL较低，DNS故障转移也似乎带有fair bit of latency。
如果主colo上的服务器无法访问，您会建议在colos之间快速移动流量的策略是什么？
如果你有其他有趣的经验/关于跨colo故障转移的智慧的话，我也很乐意听到这些。
答案 0 :(得分：3)
基于DNS的机制很麻烦，即使您在区域文件中放置了低TTL。
这样做的原因是许多应用程序（例如MSIE）维护自己的缓存，忽略TTL。其他软件将执行单个gethostbyname()或等效调用并存储结果，直到程序重新启动。
更糟糕的是，众所周知，许多互联网服务提供商的递归DNS服务器会忽略低于其自身首选最低限度的TTL，并强加自己更高的TTL。
最终，如果该站点要从两个数据中心运行而不更改其IP地址，那么您需要通过全局BGP4路由公告来查看“多宿主”的安排。
使用多宿主，您需要获得至少一个“24个”独立于提供商“（也称为”PI“）IP地址空间的网络块，然后只有主站点才能从备份站点通知全局路由表离线。</ p>
答案 1 :(得分：3)
至于DNS，我想参考"Why DNS Based Global Server Load Balancing Doesn't Work"。其他一切 - 使用BGP 。
设计网络以便使用BGP进行负载平衡仍然不是一件容易的事，我自己肯定不是这方面的专家。它也比维基百科告诉你的更复杂，但网上有一些有趣的文章详细说明了如何做到这一点：
如果您搜索BGP和负载平衡，总会有更多。网上还有一些白皮书描述了Akamai如何进行全局负载均衡（我相信它也是BGP）。这一点总是很有趣，可以阅读和了解。
除了可以使用软件和硬件实现的显而易见的概念之外，您可能还需要咨询您的ISP /提供商/ colo是否可以为您设置。
此外，对于您选择colo（谁是提供者？）没有任何冒犯，但是大多数地方应该设置为处理停机时间等等，他们不应该要求您采取行动。当然洪水或外星人总是可以攻击，但在这种情况下，我猜有更重要的问题。 ： - ）
答案 2 :(得分：0)
如果可以，多播 - http://en.wikipedia.org/wiki/Multicast或AnyCast - http://en.wikipedia.org/wiki/Anycast