我正在开发一个客户端 – 服务器系统，在这个系统中，所有的客户端目前都将他们的事务提交到一个单一的西岸IP地址，以达到所谓的“网关”应用程序。 网关执行一些记帐，并将每个事务分派到多个数据库服务器中的任何一个以进行最终处理。 服务器将结果直接返回给客户端（不通过网关返回）。
计划是在东海岸增加第二个网关，以实现冗余和故障切换。 它通常只会处于待命状态，旨在接pipe并成为工作网关出现故障时的实际网关，本质上是此处所示的经典configuration。
一些与会者认为，只有一个备用网关是不够的，我们还应该在中西部地区实施第二个备用网关。 其他人则认为，两个待机的额外成本，复杂性和pipe理是不必要的，同时在两岸同时无法使用网关是不太可能的，因此不会成为问题。
什么被认为是最佳实践？ 多less冗余（就客户端可用的物理上独立的接入点而言）通常被认为是名义上的？ 双重失败是否足够普遍，只有一个待机是经常后悔的？
编辑：关于“计算”成本与利益的冗余量我需要或想要的，我想这是最好重新措辞我的问题为：
哪些统计数据表明地理上分离的IP地址集合的频率同时不可达？
换句话说，就像一张桌子一样
On average, 1 west coast IP + 1 east cost IP are simultaneously unreachable 1 day/year. On average, 1 west IP + 1 east IP + 1 southern IP are simultaneously unreachable 1 hr/year. On average, 1 west IP + 1 east IP + 1 southern IP + 1 northern IP are simultaneously unreachable 1 minute/year. etc. 使得select期望冗余的数量相当容易，因为有一个实际的基础来计算成本与性能。 （我认为“同时无法达到”意味着“对大量随机散落在全国各地的客户”，因为一个客户端可能无法到达任何服务器，而不pipe因为她自己的本地networking故障而有多less客户端）。
但是，没有这样的表格，任何冗余性能和性能计算都只是猜测。 那么， 是否有这样的计算可以基于的实际可用性数据的来源？ 还是每个人都猜测他们需要什么，一旦发现他们猜测的不足，就会根据需要进行扩展，或者如果他们猜测的很高，就会削减呢？
看来，提供容错产品的公司希望收集和推广这些数据。 另一方面，也许数据显示99.99％的容错客户根本不需要太多冗余。 例如，如果我可以去一整年，我的东西方IP地址永远不可能同时到达，那么我不打算考虑增加一个中西部的IP。
我也意识到由于我的站点外部的力量而导致IP地址不可访问，以及因为我的站点内部失败而导致IP地址closures。 内部故障（在我的IP地址一侧）相对容易处理。 外部故障（在IP地址的客户端，如加利福尼亚因地震而下线，或纽约在飓风期间下线），我只能在其他地理位置使用额外的IP地址。 这是我希望量化的概率。 就目前而言，我倾向于声称东西IP地址同时无法访问的可能性太小而无法关心的阵营。
我们的第一台networking服务器于1995年开始在X市的Centrex连接上，1998年转换为ISDN，然后在2001年转换为DSL，同时我们还在几英里外的Y市启动了第二个静态地址进行备份。 虽然我们使用两个不同的ISP，但是底层networking是PacBell，现在是ATT。 我们的城市X设施在2003年腾出空间，只有Y城市运行了我们的服务器，直到2009年，当时我们在Z市又开了一个静态地址，离Y市几英里，现在Y和Z都使用同一个ISP。
在所有这些年里，我们所知道的IP地址从来都不是“外部的”（就像你说的那样）不可及的。 显然PacBell / ATT和我们的ISP总是有足够的冗余，他们总是可以至less提供我们的数据包。 “内部”我们遇到的唯一问题是电源故障，甚至机器故障，以及在这些事件期间（几天或许几年一次），只是临时切换两个地点之间的DNS指针已经足够我们的目的。
如果你得到西海岸IP和东海岸的IP，我预测你的客户（作为一个团体）可能永远不会看到这些地址同时无法到达。 如果两个地点都不可达（换句话说，包裹甚至不能送到那里），那么大决战可能已经到来了，无论如何，你将会遇到更大的问题。 只要确保有适当的政策和程序（以及经过testing）能够在任何一个站点发生内部故障时立即恢复，并且不必担心获得第三个中西部知识产权，直到情况certificate确实是必要的。
What @ HopelessN00b说。 你必须为自己衡量原始的成本 VS 收益 。
你必须计算：
对此没有最佳做法。
哪些统计数据表明地理上分离的IP地址集合的频率同时不可达？
这也取决于。 例如，我们是在谈论没有UPS的客户的统计数据，还是他们自己的Generator ？ 甚至两个独立的电力线来自不同的分站？
这也进入了等式。 我们公司因为停电时间太长而导致UPS停电，
我们为整个数据中心购买了一台能持续X小时的发电机，并且能够在紧急情况下通过燃料回收进行补给，即使本地子系统完全被淘汰，我们也可以无限期地继续下去。
也许数据显示99.99％的容错客户根本不需要太多冗余。
完全。
我有一个在单一服务器上运行关键（$$$）系统的客户，他们的服务器是坚如磐石的，因为它只执行一个function。 并发症越less越好。
这是您添加容灾解决scheme的一个古老的讽刺的情况，然后您比以前经历更多的中断。
正如已经说过的那样，在技术层面上没有一个通用的最佳实践，除了显而易见的不能做的事情之外。
很多情况下，您将明确与您的客户进行任何SLA通知，或者很可能会在其行业中使用SLA，因此您必须确保在最特殊情况下您可以支持这些SLA，并且能够承担任何所需的补偿使一个最特殊的情况发生。 例如，对于我们的一些客户，我们有一个四小时的恢复窗口，其中24小时的损失是“可以接受的”（这很容易确保），另一个更实时的项目是10分钟和30分钟，而且我可以想象任务关键和/或安全服务的期望远远高于此。
我能想到的唯一一个通用build议是确保您在将某个时间和金钱花费在某个特定点上之前，已经掌握了一定的基础知识。 拥有世界上最冗余的故障安全数据库层并不能帮助您，当一个公共链接到您的网上农场死亡。 所以尽量不要过分保护系统的一方而牺牲他人。