我正在构build一个正常运行时间很关键的Web应用程序。 我明白，100％的正常运行时间是不现实的，但我想达到五个九。 我不确定如何做到这一点的最谨慎的方式。
我的初步计划是在两个地理上分开的数据中心运行的Web应用程序。 “主”数据中心将包含主服务器，这将复制到其他地方未使用的“从服务器”服务器。 如果主数据中心发生停机，DNS故障切换会将stream量转移到“从属”服务器。 这种技术存在挑战，包括一些用户由于奇怪的DNSloggingcaching等而无法访问网站一段时间。
但是，我已经阅读了很多意见，指出DNS故障切换不是一个很好的解决scheme，您应该将所有内容都保存在一个数据中心，并将重点放在冗余。 我看到的问题是，即使是良好的数据中心似乎也有networking问题，可以导致足够的停机时间，打破五个九的期望。
我应该使用DNS故障转移选项吗？ 有更好的select吗？
我对客户的经验法则是：免费获得两个九（即，没有花费任何专门的高可用性）。 每增加九个，总成本就会增加一个数量级。
也就是说，只需将您的应用程序放在公司互联网连接上的半个体面的服务器上，即可拥有99％的正常运行时间。 为了改善这一点，你可以同心协力。 您可以使用负载平衡和快速故障转移。 您可以使用负载平衡，快速故障转移和冷备用灾难恢复站点。 您可以使用负载均衡，热备用站点，PI地址空间，运行您自己的ASN，并configurationBGP对等布局，以确保您的地址空间始终是全局可路由的。 您可以调查高可用性硬件，其中包括内存和CPU的所有内容都可以静止并热插拔。 如果您的应用程序支持它，则可以运行完全分布式托pipe，或外包给高度可用的内容提供networking。 你可以而且将会需要五倍的人员来pipe理这24 * 365的全部，包括节假日和疾病覆盖，以及频繁的实时DRtesting，你需要做的就是对所有这些都有信心。
你可以做很多聪明的东西。 但这一切都需要花费，而且大部分都花费了大量的资金。
所以我诚挚的build议是：弄清楚在公司办公室的一台服务器上托pipe应用程序会花费多less钱。 如果你的雇主不愿意花费上千倍，那就忘了五个九。 这是不现实的。
如果五个九是容易的，Twitter，Facebook，Gmail，Azure和亚马逊可能已经在那里。 他们肯定有钱和最有效的商业案例。 相反，我build议您的目标是与提供可靠基础架构方面的专业知识的云提供商进行托pipe，以便在您开发产品时可以担心这一点。
对于五个九，你看到更多的参与，而不仅仅是一个故障转移解决scheme。 您需要在一个数据中心内部安装一个HA（或者至less是温暖的）备用数据中心，这个数据中心在地理位置上远离主数据中心。 而这只是一个开始…
我想在这里有一个老板想要的powerpoint兼容卖点的东西，但得到五个九或真正接近它是可能的 – 虽然你必须小心确定是什么，需要有五个九正常运行时间。
我正在编写一个应用程序，从物联网（也是boss / powerpoint兼容）设备收集数据，并将收集的数据呈现给最终用户，使用MongoDB等进行数据挖掘等。
我们实际上已经知道至less有99.9的正常运行时间。 怎么样？ 那么，我们的正常运行时间被定义为用户前端应用程序的可用性。 这部分在GAE上运行，而其他部分（如MongoDB）在我们自己的服务器上运行。 沟通是通过REST和很多encryption。 GAE现在有99.45％的正常运行时间 – 但实际上，对于我们正在使用的部分来说，它更高 – 我们还没有logging任何types的中断。
另一方面，MongoDB有时是一个小片 – 不多 – 但是正常运行时间达到98-99％是我们现在可以做的最好的。 在MongoDB之上，我们有一个生成JSON化数据块的引擎 – 这些引擎可以根据请求生成，但也是周期性生成的。 caching这些对于维护整个系统的正常运行时间非常有帮助。 最终用户不知道某些设备是否刚刚将数据发送到后端，或者一小时前。 因此，caching的数据看起来与“实际”新数据一样新鲜。
所以 – 如果你擅长隔离实际需要高运行时间的位，那么获得真正高的正常运行时间肯定是可能的。 正如其他人所指出的那样，整个系统的正常运行时间是十分艰辛的。 但是，你或许可以less花钱，而且还能让老板高兴。