我正在开发一个客户端-服务器系统，其中所有客户端目前都将其交易提交给一个西海岸 IP 地址，以到达所谓的“网关”应用程序。网关进行一些记账并将每个交易分派到多个数据库服务器中的任意一个进行最终处理。服务器将其结果直接返回给客户端（而不是通过网关返回）。
计划在东海岸增加第二个网关，用于冗余和故障转移。它通常只处于待命状态，旨在在工作网关发生故障时接管并成为实际网关，本质上是经典配置图示。
一些参与者认为，只有一个备用网关是不够的，我们还应该在中西部地区建立第二个备用网关。其他人则认为，两个备用网关的额外成本、复杂性和管理是不必要的，而且东西海岸网关同时不可用的可能性很小，因此不必担心。
什么被认为是最佳实践？通常认为多少冗余（就客户端可用的物理独立接入点而言）是名义上的？双重故障是否足够常见，以至于经常会后悔只有一个备用设备？
编辑：关于“计算”我需要或想要的冗余量的成本与收益，我想最好将我的问题重新表述为：
哪里有统计数据可以表明地理位置分散的 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.
可以相当容易地选择所需的冗余量，因为有实际的基础来计算成本与性能。（我猜“同时无法访问”意味着“对大量随机分散在全国各地的客户端”，因为单个客户端可能会因其本地网络故障而无法访问任何服务器，无论有多少服务器。）
但是，如果没有这样的表格，任何冗余与性能的计算都只是猜测。因此： 是否有任何真实可用性数据来源可以作为此类计算的依据？ 或者每个人只是猜测他们需要什么，并且一旦他们发现自己猜的低了就根据需要扩大，或者如果他们猜的高了就削减？
提供容错产品的公司似乎希望收集和推广此类数据。另一方面，数据可能表明 99.99% 的容错客户实际上根本不需要太多冗余。例如，如果我可以坚持一整年，而我的东部和西部 IP 地址永远不会同时无法访问，我就不会考虑添加中西部 IP。
我还意识到，由于外部因素导致 IP 地址无法访问与由于内部故障导致 IP 地址瘫痪之间存在区别。内部故障（在我这边的 IP 地址）相对容易处理。外部故障（在客户端的 IP 地址，例如加利福尼亚因地震而下线，纽约因飓风而下线）我只能通过在其他地理位置拥有额外的 IP 地址来处理。 那是我希望量化的概率。目前，我倾向于认为东、西 IP 地址同时无法访问的可能性太小，无需担心。
答案1
我们的第一个网络服务器于 1995 年在 X 市通过 Centrex 连接启动，该连接于 1998 年转换为 ISDN，然后于 2001 年转换为 DSL，当时我们还在几英里外的 Y 市启动了第二个静态地址作为备份。虽然我们使用了两个不同的 ISP，但底层网络都是 PacBell，现在是 ATT。我们的 X 市设施于 2003 年腾空，只有 Y 市运行我们的服务器，直到 2009 年，我们在 Z 市启动了另一个静态地址，距离 Y 市也只有几英里，现在 Y 和 Z 甚至都使用同一个 ISP。
在这些年里，据我们所知，我们的 IP 地址从未“从外部”（如您所说）无法访问。显然，PacBell/ATT 和我们的 ISP 一直具有足够的冗余，至少可以始终传递我们的数据包。“内部”我们遇到的唯一问题是电源故障，甚至不是机器故障，并且在发生此类事件时（几天，也许每隔几年一次）在两个位置之间临时切换 DNS 指针就足以满足我们的目的。
如果您获得西海岸 IP 和东海岸 IP，我预测您的客户（作为一个群体）可能永远不会看到这些地址同时无法访问。如果两个位置都无法访问（换句话说，数据包甚至无法发送到那里），那么世界末日可能已经到来，而且您无论如何都会遇到更大的问题。只要确保您有适当的政策和程序（并经过测试）以便在任一站点发生内部故障时尽快恢复，并且不要担心获取第三个中西部 IP，直到情况以某种方式证明它确实有必要。
答案2
@HopelessN00b 说的。你必须权衡一下成本对比益处为自己。
- 一些客户会在特定时间内关闭计算机以节省成本，因为在停机期间他们根本不会产生任何流量。
- 一些客户将需要一个负载平衡的集群，在单独的数据中心中有一个故障转移实例，再加上另一个数据中心的第三个网络作为见证，以及来自其提供商的 100％24/7/365 正常运行时间的保证，无一例外。
你必须计算：
- 我一天需要上网几个小时？
- 如果我们离线 X 小时/分钟，我们会损失多少钱？
- 如果我每小时仅损失 250 美元，并且预计每月仅会出现 5 小时的停机时间，那么每月再花 5000 美元进行 DR 是否值得？（可用性为 99.9926%）
- 等等
对此没有最佳实践。
哪里有统计数据可以表明地理位置分散的 IP 地址集合同时无法访问的频率？
这也取决于具体情况。例如，我们讨论的统计数据是否针对没有UPS或他们自己的发电机?或者甚至是来自不同变电站的两条独立电力线？
这也需要考虑。我们公司停电了，因为停电时间太长，我们的 UPS 没电了。
我们为整个数据中心购买了一台发电机，可以持续供电 X 小时，紧急情况下可以通过燃料供应进行充电，这样即使本地子系统完全瘫痪，我们也可以几乎无限期地继续运行。
也许数据会显示 99.99％ 的容错客户实际上根本不需要太多的冗余。
完全正确。
我有一些客户在一台服务器上、一个位置上运行关键 ($$$) 系统，他们的服务器非常稳定，因为它只执行一项功能。越简单越好。
这是一个具有讽刺意味的情况，当您添加 DR 解决方案时，您会遇到比以往更多的中断。
答案3
正如已经说过的，除了以下显而易见的事项外，在技术层面上没有通用的最佳实践不是去做。
很多信息都来自您与客户明确签订的 SLA 或可能在其行业内采用的 SLA - 您必须确保在除最特殊情况之外的所有情况下都能支持该 SLA，并在最特殊情况发生时提供所需的任何补偿。例如，对于我们的一些客户，我们有四小时的恢复窗口，24 小时的损失是“可以接受的”（这很容易确保），对于另一个实时性更强的项目，这些时间是十到三十分钟，我可以想象，关键任务和/或安全服务的期望要严格得多。
我能想到的唯一通用建议是，在花费时间和金钱在某一特定点上之前，请确保你已经掌握了一定程度的基础知识。当你的网络农场的一个公共链接失效时，拥有地球上最冗余的故障安全数据库层对你没有帮助。因此，尽量不要过度保护系统的某一部分而牺牲其他部分。