3
全球高可用性设置问题
我拥有并经营visualwebsiteoptimizer.com/。该应用程序提供了一个代码段，我的客户将其插入他们的网站中以跟踪某些指标。由于代码段是外部JavaScript（位于网站代码的顶部），因此在显示客户网站之前，访问者的浏览器会与我们的应用服务器联系。万一我们的应用服务器出现故障，浏览器将在超时之前（通常为60秒）继续尝试建立连接。您可以想象，在任何情况下我们都无法关闭我们的应用服务器，因为它不仅会对网站访问者产生负面影响，还会对客户的网站访问者造成负面影响！ 我们目前正在将DNS故障转移机制与位于不同数据中心（实际上是不同大陆）的一台备份服务器一起使用。也就是说，我们从3个不同的位置监视我们的应用服务器，并且一旦检测到它已关闭，我们就会更改A记录以指向备份服务器IP。这对于大多数浏览器都可以正常工作（因为我们的TTL为2分钟），但是IE会将DNS缓存30分钟，这可能会破坏交易。请参阅我们的visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-site-30分钟/的最新帖子/ 因此，在应用程序数据中心遭受严重故障的情况下，我们可以使用哪种设置来确保几乎即时的故障转移？我在这里阅读了www.tenereillo.com/GSLBPageOfShame.htm，它具有多个A记录是一种解决方案，但我们还无法负担会话同步的费用。我们正在探索的另一种策略是拥有两个A记录，一个指向应用服务器，第二个指向反向代理（位于不同的数据中心），该反向代理在启动时解析为主应用服务器，在启动时解析为备份服务器。您认为这种策略合理吗？ 为了确保我们的优先事项，我们有能力关闭我们自己的网站或应用程序，但由于停机时间，我们不能让客户的网站速度变慢。因此，万一我们的应用程序服务器出现故障，我们不打算使用默认的应用程序响应进行响应。即使是空白响应也已足够，我们只需要浏览器完成该HTTP连接即可（仅此而已）。 参考：我读了这个有用的线程serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin是确保的唯一方法