我们目前正在使用DNS故障转移机制,其中一个备份服务器位于不同的数据中心(实际上是不同的大陆).也就是说,我们从3个不同的位置监控我们的应用服务器,一旦检测到它关闭,我们将A记录更改为指向备份服务器IP.这适用于大多数浏览器(因为我们的TTL是2分钟),但IE缓存DNS 30分钟,这可能是一个交易杀手.见最近我们visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/的帖子
那么,如果应用程序数据中心遭遇重大中断,我们可以使用哪种设置来确保几乎即时的故障转移？我在这里读到www.tenereillo.com/GSLBPageOfShame.htm,有多个A记录是一个解决方案,但我们还不能提供会话同步.我们正在探索的另一个策略是拥有两条A记录,一条指向应用服务器,另一条指向反向代理(位于不同的数据中心),如果启动则解析为主应用服务器,如果启动则解析为备份服务器.你认为这个策略合理吗？
为了确定我们的优先事项,我们可以保留自己的网站或应用程序,但由于我们的停机时间,我们不能让客户的网站放慢速度.因此,如果我们的应用服务器已关闭,我们不打算使用默认的应用程序响应进行响应.即使是空白的响应也足够了,我们只需要浏览器完成HTTP连接(而不是其他任何东西).
参考：我读过这个有用的线程serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure
解决方法
如果你有足够的预算,那么你想要的是两个数据中心,每个数据中心有多个IP传输,一对边缘路由器与你的传输提供商进行BGP会话,将你的IP地址通告给全球互联网.
这是进行真正故障转移的唯一方法.当路由器注意到到您的服务器的路由不再有效时(您可以通过多种方式进行),那么它们就会停止宣传该路由,并且流量会转到另一个站点.
问题是,对于一对边缘路由器,您最初需要考虑相当高的成本才能实现此设置.
然后,您需要设置所有这些背后的网络,并且您可能希望将站点之间的某种Layer2连接视为点对点链接,以便您能够将流量路由到一个数据中心,在主站点部分失败的情况下直接与另一个站点相连.
BGP Multihomed/Multi-location best practice和Best way to improve resilience?是我询问类似问题的问题.
GSLB页面的耻辱确实提出了一些重要的观点,这就是为什么我个人从不愿意选择GSLB来完成BGP路由的工作.
您还应该查看网络中的其他故障点.确保所有服务器都有2个NIC(连接到2个独立的交换机),2个PSU,并且您的服务由多个后端服务器组成,如冗余对或负载平衡群集.
基本上,通过多个A记录的DNS“负载平衡”只是“负载共享”,因为DNS服务器没有关于每个服务器上有多少负载的概念.这很便宜(免费).
GSLB服务有一些关于如何加载服务器及其可用性的概念,并提供一些更大的失败抵抗力,但仍然受到与dns缓存和挂钩相关的问题的困扰.
这样便宜,但略好一些.
由坚实的基础设施支持的BGP路由网络是恕我直言,这是真正保证良好正常运行时间的唯一方法.您可以通过使用路由服务器而不是Cisco / Juniper / etc路由器来节省一些资金,但在一天结束时,您需要非常小心地管理这些服务器.这绝不是一个廉价的选择,或者是一件轻松的事情,但它是一个非常有益的解决方案,并将您作为提供商带入互联网,而不仅仅是消费者.
