我们有一些运行 Web 应用程序的服务器，所有服务器都在一个数据中心运行，我们从未遇到过任何问题。然而，随着我们开始变得越来越大，我不得不考虑如果我们的数据中心出现故障，我们该怎么办。对于我们来说，将服务器放在两个不同的数据中心，全天候运行并不划算，所以我目前的计划是让我们的主服务器正常运行，但在“云”/VPS 服务器提供商上运行的“热”数据库服务器不断与主数据库服务器保持同步，但没有应用程序服务器直接连接到它。然后，当我们的数据中心出现故障时，我们会克隆数据库服务器以提供足够的容量，并启动一些新的应用程序服务器，将停机时间降至几分钟。
我遇到的问题是弄清楚如何故障转移到云服务器。我不想使用 DNS 循环，因为在正常情况下，没有请求应该发送到我们的 VPS，我也想避免使用 DNS 故障转移（即，当我们的 DC 发生故障时，我们会更新 DNS 以指向新服务器），因为根据我的经验，一些 ISP 不遵守 DNS TTL 并且会缓存记录数天。
我并不是在寻找有关如何执行此操作的确切指南，只是一些我应该研究的主题。我查看了 IP {any,multi,broad}cast，但它们似乎与我们要做的事情无关（我不确定是否有可能让 IP 指向来自不同网络上的多个提供商的多个服务器，但我可能是错的）。我也不想在所有请求前面放置代理/负载平衡器，同样，这将需要在单独的数据中心中安装设备，并且可能会降低性能。
答案1
因此，如果您的站点可通过 www.example.com 访问，而您希望 www.example.com 在特定时间转到“其他地方”，则没有太多选择。正如您所说，dns 故障转移对您不起作用，因为您希望冷站点承载 0 流量并立即来回故障。因此，我们正在研究 1.2.3.4 的一些基于 IP 的故障转移。您可以在另一个 DC 中非常快速地为 1.2.3.4 做出另一个公告，但这需要路由器和 BGP，并且很可能不是您擅长的。因此，我能看到的唯一替代方案是将 1.2.3.4 设为将查询重定向到适当位置的“前端”设备。也许是这个产品系列中的某些东西：http://www.cisco.com/en/US/products/hw/contnetw/index.html（但我是思科人，所以我可能有偏见）。
答案2
有几家公司提供 DNS，当第一台机器不可用时，它们会将故障转移到第二台机器。
但在您出去查看所有这些之前，请先了解您当前数据中心的可靠性如何？
它是否具有来自不同提供商的冗余互联网连接？
它是否具有来自不同电源的冗余电源？
它是否有至少 N +1 的备用 UPS 和发电机？
这是什么级别的设施？是像 Terremark、Level 3 等设施，还是当地的小型 ISP？
停机每天/每小时/每分钟给您带来多少成本？缓解停机成本是否合理？
答案3
那么基于云的负载平衡解决方案如何有效地配置两个站点之间的负载平衡？
您应该能够从配置中拉出第二个位置，并让服务仅转发到您的主数据中心，并在发生故障时执行快速切换。
由于您已经将这部分基础设施外包，因此也消除了拥有多个物理设备的需要。