假设您负责运行一组关键任务Web服务，目标时间为99.5％
为了达到这个目的，在两个完全独立的数据中心，有不同的带宽提供商，有两个相同的硬件集群。
在每个机架的顶部，需要有一些机架顶部的硬件（交换和防火墙设备）。
您的软件设置是这样的，在人为干预的情况下，如果其中一个群集处于脱机状态，则将所有服务从一个数据中心重新路由到另一个数据中心是非常容易的。 说这将需要大约15分钟。
现在的问题是：每个数据中心你会花费8k额外的机架设备（交换机和防火墙热故障）吗？ 通过参考，每个设备的机架中有大约50k的服务器。
冗余设置要复杂得多，有更多的故障模式，并且保证在初始购买价格方面以及在花费更多复杂设置的维护和故障排除时间方面都要付出代价。
而且，我们已经运行了8年多的（冗余）设置，并且从来没有（敲过木头）机架设备的顶端发生故障。 我们用3年的服务周期来replace所有的东西。
单点故障模型的缺点是，如果我们丢失交换机或防火墙，整个数据中心将会停止运行。 此外，人必须投掷一个开关将失败的服务路由到另一个数据中心（由于各种原因，没有可靠的方法来自动执行此操作）
我怀疑，因为它使用更less的硬件和更简单的单点故障选项将导致在现实世界更长的时间。 我的经验是，硬件故障发生的频率远远低于人们的故障，交换机/防火墙（没有旋转磁盘驱动器和安全操作系统等）很less失败。
服务器故障社区认为什么？
不pipe你做什么，硬件都会失败。 人们会犯错误。
没有任何疑问的影子，我会升级每个机架以拥有多个任务。
你说你在每个机架上有5万台服务器，但只有一台交换机连接到外部世界？ 我也假设一个单一的路由器和单一的防火墙。
如果我是系统pipe理员，我不确定自己能应付这个问题。 我需要多个不同的传输提供商，HA / HSRP模式下的一对边缘路由器，一对高可用性防火墙，至less2个交换机以及所有具有双NIC的服务器，在每个NIC上获得不同的交换机。
STP处理交换机或端口的故障，这是自动的。 路由器的故障由对的HA软件处理。 同上防火墙。 丢失一个数据中心，并切换它们之间的stream量，我假设你使用某种forms的GSLB设备？
我完全赞赏你的想法，但问题是，比如说DC1因为一个重大事件而离线，这将需要几天或几周才能再次出现（火灾，洪水，$ imaginary_deity行为）..然后你有一个路由器故障DC2。 这不是一个非常不可能的情况。 根据您所告诉我们的情况，您的整个基础架构现在无法从互联网上获得。
这是可接受的失败模式之一吗？ 当它很容易（不便宜）地避免时，我当然不会忍受这种停电。
我想，如果你做这种停电的风险评估，并考虑到你的雇主将遭受损失的业务，如果升级的成本低于一个星期的业务损失，那么这是一个很好的交易。