我们正在运行相当大的 LAMP 网站，这些网站在软件方面具有很好的扩展性。我们在大量 Web 服务器前面使用冗余负载平衡器，通过主从从从从代理使用 MySQL。
我们使用的是美国一家大型供应商。他们的价格不算便宜，但也不是最贵的。
上周，他们的网络遭受了非常大的 DDOS 攻击，我们的集群受到了影响；我们的网络一度中断，导致停机。
使用 2 家供应商（例如一家在欧盟，一家在美国）的标准流程是什么？我知道如何进行软件复制等。
我想知道当美国网络瘫痪时，数据是如何发送到欧盟网络的；DNS 是唯一的选择吗？如果是，如何设置？因为当服务器瘫痪时切换 DNS 似乎太慢了，除非 TTL = 0，这意味着我们将使用 DNS 作为故障转移系统。我理解（例如从 Serverfault 理解），这不是首选的工作方法。
那么，在接近 100% 正常运行时间的情况下，解决这个问题的首选方法是什么（我们的集群已经实现了这一点，但网络还没有）。丢弃 1000 个请求是可以的，但丢弃更多请求就不好了，不应该发生。
答案1
假设我正确理解了你的问题，你希望你的客户在主数据中心因任何原因停机时，能够故障转移到辅助数据中心。可以处理这种情况的产品之一是BIG-IP 全局流量管理器来自 f5 Networks。本质上，当检测到中断时，它会立即更新您的 DNS，以开始将客户端重定向到辅助网络。
另一个选择可能是使用类似任播将路线广播到您的数据中心。
补充一下，我们确实在多个数据中心运营，最终决定最好的方法是让工程师根据中断的原因手动将 DNS 指针移动到备用位置。最坏的情况是，如果一个数据中心完全离线，我们可能会停机 1 小时。但是，当我们确实必须切换数据中心时（最近的活动将无法在备用位置获得），这会与客户的影响相权衡。
最后一个选择是不要依赖数据中心提供 IP 连接和带宽。相反，您可以与 Global Crossing 或 Level 3 等全球 IP 提供商联系，让他们负责将您的入站流量路由到任一数据中心。这样做的风险在于您只与一家提供商合作，但好处在于他们的路由选项可以更加灵活（您可以在他们的网络上使用 MPLS 进行后端复制，也可以使用相同的连接进行公共 IM 连接）。
答案2
本质上，有两种技术可供选择（据我所知）：
- 正如 OP 指出的那样，通过更新 DNS 将故障转移到另一个 DC，以便记录指向操作数据中心中的地址。
- IP任播即 DNS 发布 IP 地址，并且该 IP 地址是任播的，并且在两个数据中心都在使用，从而导致客户的路由器选择最近的数据中心。请注意，如果一个数据中心发生故障，那么距离此 DC“最近”的客户仍将出现短暂中断，直到 BGP 路由重新调整。
因为当服务器宕机时切换 DNS 似乎太慢了，除非 TTL = 0
您可以将 TTL 设置为零，但不要指望所有网络都遵循您的设置。实际上，TTL 的最低值约为 10 分钟。当然，这意味着基于 DNS 的故障转移对于每个客户将花费 0 到 10 分钟的时间，具体取决于其缓存中的 TTL。
删除 1000 个请求还可以，但删除更多就不好了，而且不应该发生。
据我所知，这远远超出了当今技术所能实现的范围。即使是最大的网站也使用基于 DNS 或任播的技术，并努力保持其数据中心接近 100% 的正常运行时间，因为在全球互联网层面上无法实现即时故障转移。
在 LAN 内部，您可以使用 VMWare VMotion 之类的工具实现快速切换，但这取决于您自己的端到端控制的 LAN。
我的看法是除了拥有大量技术专业知识的超大型网站外，全局负载平衡是不切实际的：
- 许多负载平衡设备都以地理分布作为功能要点，但如果整个 DC 瘫痪，那么您的负载平衡器也会瘫痪？（编辑：我刚刚重读了 DLux 的答案，我想我现在明白了……你有两个负载平衡器，每个 DC 中各放一个。它们之间建立了心跳。当活动 DC 中的 LB 注意到其在死 DC 中的同事已脱离网络时，活动 LB 会更新 DNS 以促进故障转移。）
- 我个人不会尝试使用 Anycast——该技术已经存在并可操作，但如果出现奇怪的、罕见的路由问题怎么办？排除网络故障本身就够难的了，BGP 上的“优化”应该留给真正的专家。
- 因此剩下的就是基于 DNS 的故障转移，最好使用提供水平分割 DNS 服务的全球复制 DNS 提供商。这样可以，部署也相当简单。但是，它无法满足 OP 的近乎即时的故障转移目标。
免责声明，我希望得到一位真正的专家的意见/纠正，他之前曾多次部署过全球冗余系统... :-)
答案3
您也可以研究内容分发网络（例如 Akamai）。卸载静态内容并将动态内容缓存到 CDN 可以显著减少集群的负载。
Akamai 尤其如此真的昂贵，但还有其他更便宜的替代品。