Web应用程序的100％正常运行时间

今天，我们收到了一个来自客户的有趣的“要求”。

他们希望在Web应用程序上实现非现场故障转移的100％正常运行时间。从我们的Web应用程序的角度来看，这不是问题。它旨在能够在多个数据库服务器等之间扩展。

但是，从网络问题来看，我似乎无法弄清楚如何使其工作。

简而言之，该应用程序将驻留在客户端网络内的服务器上。内部和外部人员都可以访问它。他们希望我们维护该系统的异地副本，以便在其场所发生严重故障时能够立即接管并接管。

现在我们知道，绝对没有办法为内部人员（信鸽吗？）解决此问题，但是他们希望外部用户甚至不会注意到它。

坦率地说，我对如何做到这一点尚不了解。看来，如果他们失去了Internet连接，那么我们将不得不进行DNS更改以将流量转发到外部计算机……这当然需要时间。

有想法吗？

更新

我今天与客户进行了讨论，他们澄清了这个问题。

他们坚持使用100％的数字，说即使在发生洪水的情况下，应用程序也应保持活动状态。但是，只有在我们为他们托管时，该要求才会生效。他们说，如果应用程序完全位于服务器上，他们将满足正常运行时间的要求。你可以猜得出我的回应。

这是Wikipedia的简便易用图表：

有趣的是，在2007年排名前20位的网站中，只有3个能够达到神话般的5个9或99.999％的正常运行时间。它们分别是Yahoo，AOL和Comcast。在2008年前4个月，一些最受欢迎的社交网络甚至还没有达到这个水平。

从图表中可以明显看出，追求100％正常运行时间是多么可笑...

要求他们定义100％以及如何在什么时间段内进行测量。它们可能意味着尽可能承受接近100％的费用。给他们成本。

详细说明。这些年来，我一直在与客户讨论可能有荒谬要求的问题。在所有情况下，它们实际上只是使用不够精确的语言。

他们经常以看起来绝对的方式来构架事物，例如100％，但实际上，在更深入的研究中，它们足够合理，可以进行成本/收益分析，而成本/收益分析则需要对降低风险的数据进行成本计算。问他们如何衡量可用性是一个至关重要的问题。如果他们不知道这些，那么您必须向他们建议这需要首先定义。

我会请客户定义如果站点在以下情况下发生故障，将会对业务影响/成本产生什么影响：

• 在他们最忙的时间x个小时
• 至少在x个小时的繁忙时间

以及他们如何衡量这一点。

通过这种方式，您可以与他们一起确定“ 100％”的正确水平。我怀疑通过问这些问题，他们将能够更好地确定其他需求的优先级。例如，他们可能想要支付一定级别的SLA并损害其他功能才能实现此目的。

您的客户很疯狂。无论您花多少钱，都不可能实现 100％的正常运行时间。简单明了-不可能。看一下Google，Amazon等。他们几乎无休止地投入基础设施，但他们仍然设法停机。您需要向他们传达此信息，如果他们继续坚持要求他们提出合理的要求。如果他们没有意识到一定程度的停机是不可避免的，那就放弃他们。

也就是说，您似乎具有扩展/分发应用程序本身的机制。网络部分将需要涉及到不同ISP的冗余上行链路，获取ASN和IP分配，并深入了解BGP和实际路由设备，以便IP地址空间可以在需要时在ISP之间移动。

显然，这是一个非常简洁的答案。您没有需要这种正常运行时间的应用程序的经验，因此，如果您想获得接近神话般的100％正常运行时间的信息，则确实需要聘请专业人员。

好吧，那绝对是一个有趣的话题。我不确定我是否想让自己按合同规定必须100％正常运行时间，但是如果我必须这样做，我会看起来像这样：

从完全不在网络上的负载均衡器上的公共IP开始，并构建至少两个公共IP，以便一个可以故障转移到另一个。诸如Heatbeart之类的程序可以帮助自动进行故障转移。

Varnish主要被称为缓存解决方案，但它也实现了非常不错的负载平衡。也许这将是处理负载平衡的好选择。可以将其设置为具有1到n个后端（可选地按控制器分组），以随机或循环方式负载均衡。可以使Varnish足够聪明，以检查每个后端的运行状况，并将不正常的后端退出循环，直到它重新联机。后端不必位于同一网络上。

这些天，我有点喜欢Amazon EC2中的Elastic IP，因此我可能会在不同区域或至少在同一区域的不同可用性区域中的EC2中构建负载均衡器。如果需要的话，您可以选择手动（禁止上帝使用）旋转新的负载平衡器，然后将现有的A记录IP移到新的盒子中。

不过，Varnish无法终止SSL，因此，如果您担心这一点，则可以改用Nginx之类的东西。

您可以将大多数后端都放在客户网络中，而将一个或多个后端放在他们的网络之外。我相信，但不是100％肯定，您可以确定后端的优先级，以便您的客户端计算机将获得优先级，直到它们全部不正常为止。

如果执行此任务并毫无疑问地完善它，那就是从那里开始的。

但是，正如@ErikA指出的那样，这是Internet，并且总会有部分网络不受您的控制。您需要确保您的法律只将您与您所控制的事物联系在一起。

没问题-合同措词略有修改：

...确保正常运行时间为100％（四舍五入到小数点后零位）。

如果Facebook和Amazon无法做到这一点，那么您就无法做到。就这么简单。

从黑客新闻中添加oconnore的答案

我不明白问题是什么。客户希望您为灾难做计划，而他们并不是以数学为导向，因此要求100％的概率听起来是合理的。就像工程师一样，这位工程师想起了prob＆stat 101的第一天，却没有考虑到客户可能不会这样做。当他们这么说的时候，他们并没有考虑核冬天，而是在考虑Fred将咖啡倒在办公室服务器上，磁盘崩溃或ISP崩溃了。此外，您可以完成此操作。借助地理位置不同，独立的自我监控服务器，您基本上不会停机。3台服务器以独立（1）的速度运行，三台9台可靠性，并具有良好的故障转移模式，因此您的预期停机时间不到每年一秒钟（2）。即使这一次发生 您仍处于合理的Web连接SLA范围内，因此实际上不存在停机时间。客户仍然必须处理世界末日的情况，但是哥斯拉将其排除在外，他​​将获得“始终”运行的服务。

（1）洛杉矶的服务器与波士顿的服务器相当独立，但是是的，我知道有一些涉及核战争，中国黑客使电网崩溃的交叉路口等。我不认为您的客户会因为这个。

（2）DNS故障转移可能会增加几秒钟。您仍然处于客户必须每年重试一次请求的情况，这又是在合理的SLA范围内，并且通常不将其与“停机时间”联系在一起。使用在故障时自动重新路由到可用节点的应用程序，这可能不会引起注意。

您被要求做一些不可能的事情。

在此处查看其他答案，与您的客户坐下，并解释为什么这是不可能的，并评估他们的反应。

如果他们仍然坚持100％的正常运行时间，请礼貌地告知他们无法完成，并拒绝合同。您将永远无法满足他们的需求，如果合同不能完全解决您的问题，您将被罚款。

相应地定价，然后在合同中规定，超过SLA的任何停机时间将按其支付的价格退款。

我上一份工作的ISP就是这样做的。我们可以选择正常运行时间为99.9％的“常规” DSL线路，价格为$ 40 / mo，或者是T1s的绑定三人组，正常运行时间为99.99％，价格为$ 1100 / mo。每月经常发生10个小时以上的停机，这使他们的正常运行时间大大低于40美元/月的DSL，但我们只退还了大约15美元左右，因为这就是每小时*小时的费用。他们从这笔交易中弄得像土匪。

如果您每月为$ 450,000支付100％正常运行时间的费用，而您只达到99.999％，则需要向他们退还$ 324。我愿意打赌，假设完全分布式的colos，多个1层上行链路，fantpant硬件等，基础设施成本达到99.999％的水平大约为每月$ 45,000。

如果专业人士质疑99.999％的可用性是否切实可行或在财务上可行，那么99.9999％的可用性就更不可能或不可行。更不用说100％了。

您将无法长时间满足100％可用性的目标。您可能会花上一周或一年的时间，但是随后会发生某些事情，您将承担责任。支出的范围可能从声誉受损（您答应过，没有兑现）到因合同罚款而破产。

有两种类型的人要求100％的正常运行时间：

1. 完全不了解计算机，计算机系统或Internet的人。*
2. 有意冒充自己的人，要么测试您说“不”的能力（Google“橙汁测试”），要么尝试获得某种合同SLA杠杆，以免日后付钱给您。

我的建议在很多情况下都遇到了这两种类型的客户，我的建议是不要选择此客户。让他们发疯。

*同一个人可能会毫无疑问地询问光速旅行，恒动，冷聚变等问题。

我会与客户沟通以确定他们100％正常运行时间的含义。他们可能没有真正看到99％正常运行时间和100％正常运行时间之间的区别。对于大多数人（即不是服务器管理员），这两个数字是相同的。

100％正常运行时间？

这是您需要的：

多个（＆冗余）DNS服务器，指向世界各地的多个站点，并且每个ISP都具有正确的SLA。

确保DNS服务器设置正确，并且可以有效识别TTL。

这很容易。Amazon EC2 SLA明确指出：

“年度正常运行时间百分比”是通过从100％中减去Amazon EC2处于“区域不可用”状态的服务年中5分钟的百分比得出的。

http://aws.amazon.com/ec2-sla/

只需将“正常运行时间”定义为相对于整个服务包，您实际上可以100％地保持运行时间，并且应该没有问题。

另外，值得指出的是，SLA的全部要点是定义您的义务是什么以及如果您不能履行这些义务会发生什么。客户是否要求3个9或5个9个或一百万个9个都没关系-问题是他们在何时/是否无法交付时会得到什么。显而易见的答案是为订单项提供100％正常运行时间，价格是您要收取的价格的5倍，如果您错过了该目标，他们将获得4倍的退款。您可能会得分！

只有将DNS更改配置为花费时间，DNS更改才会花费时间。您可以将记录上的TTL设置为一秒钟-唯一的问题是确保您及时响应DNS查询，并且DNS服务器可以处理该级别的查询。

这正是GTM在F5大IP中的工作方式-默认情况下，DNS TTL设置为30秒，如果集群的一个成员需要接管，则DNS将被更新，新IP几乎立即被占用。最大中断时间为30秒，但这是边缘情况，平均中断时间为15秒。

您知道这是不可能的。

毫无疑问，客户专注于看到“ 100％”，因此，除了[不是您的错的所有合理原因]之外，您可以做的最好的事情就是保证100％。

虽然我怀疑100％是否可行，但您可能需要考虑使用Azure（或具有类似SLA的产品）。怎么回事：

您的服务器是虚拟机。如果一台服务器上出现硬件问题，则您的虚拟机将移至新计算机。负载平衡器负责重定向，因此客户不应看到任何停机时间（尽管我不确定您的会话状态将如何受到影响）。

即便如此，即使进行了故障转移，精神错乱也要达到99.999和100的界限。

您必须完全控制以下因素。
-内部和外部的人为因素，包括恶意和阳imp。这样的一个例子是有人将某些东西推入生产代码中，从而使服务器瘫痪。更糟的是，破坏活动如何？
-业务问题。如果您的提供商失去了业务或忘记支付电费，或者只是在没有充分警告的情况下决定停止支持您的基础架构，该怎么办？
-大自然 如果无关的龙卷风同时袭击了足够多的数据中心以致使备份能力不堪重负怎么办？
-完全没有错误的环境。您确定没有第三方或核心系统控件没有出现但仍可以在将来出现的极端情况吗？
-即使您完全控制了上述因素，您确定在监视系统是否正常运行时，确定要进行监视的软件/人员也不会带来假阴性吗？

坦白地说，就黑客攻击而言，至少没有动摇，100％完全是疯了。最好的选择是做Google和Amazon所做的事情，因为您有一个地理分布式主机解决方案，您可以在多个地理位置的多个服务器之间复制站点和数据库。这将确保它不会发生任何重大灾难，例如将互联网骨干网切断到某个区域（确实会不时发生）或近乎世界末日的灾难。

我将针对此类情况（DDOS，Internet骨干网削减，世界末日的恐怖袭击或大战等）添加一个条款。

除此之外，还要研究Amazon S3或Rackspace云服务。本质上，云设置不仅会在每个位置提供冗余，而且还会提供流量的可伸缩性和地理位置分布，以及在发生故障的地理区域周围重定向的能力。虽然我的理解是，地理分布要花费更多的钱。

我只是想另一种声音添加到“它可以（理论上）来完成”党。

无论他们付给我多少钱，我都不会签有这份合同，但作为研究问题，它有一些相当有趣的解决方案。我对网络的概述步骤还不熟悉，但是我想将与网络相关的配置+电气/硬件布线故障转移+软件故障转移结合起来，可能会在某些配置或其他工作中实际完成。

任何配置中的某处几乎总是存在单个故障点，但是如果您努力工作，则可以将故障点推向可以“实时”修复的状态（即，根dns掉了，但值仍被缓存）其他地方，以便您有时间修复它）。

再次，不是说它是可行的。我只是不喜欢没有一个答案能解决这个问题“不在外面”的事实-如果他们考虑透彻，那不是他们真正想要的东西。

重新考虑衡量可用性的方法，然后与客户一起制定有意义的目标。

如果您经营的是大型网站，则正常运行时间根本没有用。如果您在客户最需要查询（流量高峰）的情况下放弃查询10分钟，那么与周日凌晨3点长达一个小时的停机相比，这可能对企业造成更大的破坏。

有时，大型网络公司使用以下指标来评估可用性或可靠性：

1. 成功回答的查询的百分比，没有服务器端错误（HTTP 500）。
2. 在特定目标延迟以下回答的查询百分比。
3. 删除的查询应计入您的统计信息（请参阅下文）。

可用性应该不使用样品的探针，而这正是外部实体如Pingdom的和pingability能够报告进行测量。不要仅仅依靠它。如果您想做对，则每个查询都应计数。通过查看实际获得的成功来衡量您的可用性。

最有效的方法是从负载均衡器收集日志或统计信息，并根据上述指标计算可用性。

查询删除的百分比也应计入您的统计信息。可以将其与服务器端错误归为同一类。如果网络或DNS或负载平衡器之类的其他基础结构存在问题，则可以使用简单的数学方法来估算丢失的查询数量。如果您希望在一周中的这一天进行X次查询，但获得X-1000，则可能会丢弃1000条查询。将您的流量绘制成每分钟（或每秒）图表的查询次数。如果出现间隙，则删除查询。使用基本几何形状来测量这些间隙的面积，这将为您提供删除查询的总数。

与您的客户讨论此方法并解释其好处。通过测量其当前可用性来设置基准。他们将清楚地知道100％是不可能的目标。

然后，您可以根据基准上的改进签订合同。假设，如果他们目前正在经历95％的可用性，则可以保证将情况提高到98.5％，从而将这种情况提高十倍。

注意：这种测量可用性的方法有一些缺点。首先，除非您使用现有工具来完成日志收集，处理和生成报告，否则可能并不容易。其次，应用程序错误可能会损害您的可用性。如果应用程序质量低劣，它将产生更多错误。解决方案是仅考虑由负载平衡器创建的500，而不考虑来自应用程序的500。

这样可能会使事情变得有些复杂，但这仅是衡量服务器正常运行时间的第一步。

尽管有人在这里指出100％疯狂或不可能，但他们还是以某种方式错过了真正的意义。他们认为，这样做的原因是即使最好的公司/服务也无法实现这一目标。

好吧，这比这简单得多。从数学上讲这是不可能的。

一切都有可能。您存储服务器的所有位置可能同时发生地震，从而破坏了所有服务器。可以接受的是，这是一个非常小的概率，但它不是0。所有互联网提供商都可能同时面临恐怖分子/网络攻击。同样，可能性也不大，但也不是零。无论您提供什么，都可以得到非零概率的情况，这会使整个服务瘫痪。因此，您的正常运行时间也不可能是100％。

阅读有关使用统计抽样的制造质量控制的书。本书中的一般性讨论（在大学的一般统计课程中，任何管理者都会接触到的概念）规定了从花费从千分之一到百万分之一到百万分之一到十亿分之一的指数增长。本质上，达到100％正常运行时间的能力将花费几乎无限量的资金，有点像将物体推向光速所需的燃料量。

从性能工程的角度来看，我会拒绝这种要求，因为它既不可测试又不合理，因为这种表达更多的是渴望，而不是真正的需求。由于存在任何应用程序依赖关系，而这些依赖关系存在于任何应用程序之外，无法用于联网，名称解析，路由，底层架构组件或开发工具传播的缺陷，因此任何人都不可能保证100％的正常运行时间。

我认为客户实际上并没有要求100％的正常运行时间，甚至没有要求99.999％的正常运行时间。如果您查看他们的描述，那么他们正在谈论的是如果流星取出其现场数据中心，则从中断的地方接起。

如果要求外部人员甚至不注意，那么必须有多大？发出Ajax请求重试并向最终用户显示微调器30秒是否可以接受？

这些就是客户关心的事情。如果客户实际上是在考虑精确的SLA，那么他们将足以将其表示为99.99或99.999。

我的2美分。我负责一家财富5强公司的非常受欢迎的网站，该网站将为超级碗广告。我不得不应对巨大的流量高峰，而解决问题的方法是使用Akamai之类的服务。我不在Akamai工作，但是我发现他们的服务非常好。他们拥有自己的，更智能的DNS系统，该系统知道特定的节点/主机处于高负载状态或处于关闭状态，并可以相应地路由流量。

关于他们的服务的整洁之处在于，我真的不需要做任何非常复杂的事情即可将自己数据中心中服务器上的内容复制到其数据中心。此外，通过与他们的合作，我知道他们大量使用了Apache HTTP服务器。

虽然不是100％的正常运行时间，但您可以考虑使用这些选项在全球范围内分发内容。据我了解，Akamai还具有对流量进行本地化的功能，这意味着如果我在密歇根州，我从密歇根州/芝加哥的服务器中获得了内容，而如果我在加利福尼亚州，那么我应该是从加利福尼亚州的服务器中获得了内容。

无需异地故障转移，只需从内部和外部两个位置同时运行应用程序。并同步两个数据库...如果内部发生故障，内部人员仍然可以工作，而外部人员仍然可以使用该应用程序。内部重新联机后，请同步更改。您可以为一个域名有两个DNS条目，甚至可以是具有轮询机制的网络路由器。

对于外部托管的网站，您最接近100％正常运行时间的是将您的网站托管在Google的App Engine上，并使用其高复制数据存储区（HRD）来自动在至少三个数据中心之间实时复制数据。同样，App Engine前端服务器会自动为您缩放/复制。

但是，即使拥有Google的所有资源和世界上最复杂的平台，App Engine SLA正常运行时间的保证也只有“每个日历月中99.95％的时间”。

简单直接：Anycast

http://en.wikipedia.org/wiki/Anycast

这就是cloudflare，Google和其他任何大公司用于冗余，低延迟，跨大陆故障转移/平衡的功能。

但也要记住，不可能有100％的正常运行时间，而且从99.999％降低到99.9999％的成本要大得多。