Par*_*pra 10 domain-name-system failover high-availability bgp
我拥有并经营visualwebsiteoptimizer.com /。该应用程序提供了一个代码片段，我的客户将其插入到他们的网站中以跟踪某些指标。由于代码片段是外部 JavaScript（位于站点代码的顶部），因此在显示客户网站之前，访问者的浏览器会联系我们的应用服务器。如果我们的应用服务器出现故障，浏览器将在超时（通常为 60 秒）之前继续尝试建立连接。可以想象，在任何情况下我们都不能让我们的应用程序服务器停机，因为这不仅会对我们的网站访问者的体验产生负面影响，还会对我们客户的网站访问者的体验产生负面影响！
我们目前使用 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 多宿主/多位置最佳实践和提高弹性的最佳方法？是我就类似问题提出的问题。
GSLB 的耻辱页面确实提出了一些重要的观点，这就是为什么我个人永远不会愿意选择 GSLB 来完成 BGP 路由的工作。
您还应该查看网络中的其他故障点。确保所有服务器都有 2 个 NIC（连接到 2 个独立的交换机）、2 个 PSU，并且您的服务由多个后端服务器组成，作为冗余对或负载平衡集群。
基本上，通过多个 A 记录的 DNS“负载平衡”只是“负载共享”，因为 DNS 服务器不知道每个服务器上有多少负载。这很便宜（免费）。
GSLB 服务有一些关于服务器负载情况及其可用性的概念，并提供了更大的抗故障能力，但仍然受到与 dns 缓存和挂钩相关的问题的困扰。这是不那么便宜，但稍微好一点。
一个 BGP 路由网络，由坚实的基础设施支持，恕我直言，这是真正保证良好正常运行时间的唯一方法。您可以通过使用路由服务器而不是 Cisco/Juniper/etc 路由器来节省一些钱，但归根结底，您确实需要非常小心地管理这些服务器。这绝不是一个便宜的选择，也不是一个可以轻率地进行的事情，但它是一个非常有益的解决方案，并将您带入互联网作为提供者，而不仅仅是消费者。