Web 应用程序的 100% 正常运行时间
Not*_*tMe 319 windows-server-2008 failover
我们今天从客户那里收到了一个有趣的“要求”。
他们希望在 Web 应用程序上实现100% 的正常运行时间和异地故障转移。从我们的 Web 应用程序的角度来看，这不是问题。它旨在能够跨多个数据库服务器等进行横向扩展。
但是，从网络问题来看，我似乎无法弄清楚如何使其工作。
简而言之，应用程序将存在于客户端网络中的服务器上。内部和外部人员都可以访问它。他们希望我们维护一个系统的异地副本，如果他们的场所发生严重故障，该副本将立即恢复并接管。
现在我们知道内部人（信鸽？）绝对没有办法解决它，但他们希望外部用户甚至不会注意到。
坦率地说，我对这可能是怎么做到的一无所知。似乎如果他们失去 Internet 连接，那么我们将不得不进行 DNS 更改以将流量转发到外部机器......当然，这需要时间。
想法？
更新
我今天与客户进行了讨论，他们澄清了这个问题。
他们坚持 100% 的数字，说即使发生洪水，应用程序也应该保持活动状态。但是，只有当我们为他们托管时，该要求才会生效。他们表示，如果应用程序完全存在于他们的服务器上，他们将处理正常运行时间要求。你可以猜到我的反应。
Gre*_*egD 369
这是维基百科的九点追求图表：
有趣的是，2007 年排名前 20 的网站中只有3 个能够达到神话般的 5 个 9 或 99.999% 的正常运行时间。它们是 Yahoo、AOL 和 Comcast。在 2008 年的前 4 个月，一些最受欢迎的社交网络甚至还没有接近这一点。
从图表中可以看出，追求 100% 正常运行时间是多么荒谬……
- Pingdom 也不会每秒检查一次。最重要的是，那些确实达到了 5 个 9 的那些可能仍然存在 Pingdom 可能没有检测到的局部中断，或者导致某些服务在仍然响应 ping 时不可用的故障。 (63认同)
- 很抱歉打扰正在进行的聊天，但 OP 的问题是如何在技术层面上努力实现 100% 正常运行时间的目标，而不是在概念上，我相信他知道这并不总是可能的，因为硬件会自然发生和环境。我们能帮他解决这个问题吗？ (43认同)
- 这本身就使五个 9 变得可疑…… (8认同)
- 恰恰。他们有数十亿美元可以使用！ (5认同)
- 对 OP：我已经看到在“正常维护之外”的情况下保证正常运行时间的 SLA。正常的维护当然是每月为更新、补丁等安排停机时间，这通常发生在当月最不忙的一天（通常在半夜）。他们必须为他们的业务制定某种类型的指标。您**可以**为他们提供更好的正常运行时间（4 个 9）**仅**在这些时间段内。 (5认同)
Pre*_*gha 190
让他们定义 100% 以及如何在什么时间段内测量它。他们可能意味着尽可能接近 100%。给他们算成本。
详细说明。多年来，我一直在与客户进行讨论，提出一些荒谬的要求。在所有情况下，他们实际上只是使用不够精确的语言。
很多时候，他们以看似绝对的方式来构建事物——比如 100%，但实际上，在更深入的调查中，他们足够合理地进行成本/收益分析，这在提供风险缓解数据的成本计算时是必需的。询问他们将如何衡量可用性是一个关键问题。如果他们不知道这一点，那么您就必须向他们建议这需要首先定义。
如果网站在以下情况下宕机，我会要求客户定义在业务影响/成本方面会发生什么：
- 在他们最繁忙的时间 x 小时
- 在他们最不忙的时间 x 小时
以及他们将如何衡量这一点。
通过这种方式，您可以与他们一起确定“100%”的正确水平。我怀疑通过询问这些类型的问题，他们将能够更好地确定其他需求的优先级。例如，他们可能希望支付一定级别的 SLA 并损害其他功能以实现这一目标。
- +1 不急于下结论，而只是要求客户解释他们的想法。 (33认同)
- 同意。它们可能只是意味着具有非常可靠的故障转移策略的“非常高”的正常运行时间（90 年代以上？）。如果没有，那么对所涉及的成本规模的解释有望说服他们...... (21认同)
- @ChrisLively 更有理由对风险有一个成熟的理解。安全工程的主要范式是[概率风险评估](http://en.wikipedia.org/wiki/Probabilistic_risk_assessment)。有些系统可以杀死（不仅仅是惹恼）成千上万的人，而且它们的失败概率仍然很低，希望很好理解，但不是零。 (7认同)
- 我回应了“不妄下结论”的说法……如果客户意味着 100% 的正常运行时间（减去定期维护），那么它*可能*是一个更合理的要求。 (4认同)
EEA*_*EAA 138
你的客户疯了。无论您花多少钱，100% 的正常运行时间都是不可能的。简单明了——不可能。看看谷歌、亚马逊等。他们有近乎无穷无尽的资金投入他们的基础设施，但他们仍然设法停机。你需要向他们传达这个信息，如果他们继续坚持提出合理的要求。如果他们没有意识到一定程度的停机时间是不可避免的，那就放弃他们。
也就是说，您似乎拥有扩展/分发应用程序本身的机制。网络部分将需要涉及到不同 ISP 的冗余上行链路，获得 ASN 和 IP 分配，并深入了解 BGP 和真正的路由设备，以便 IP 地址空间可以在需要时在 ISP 之间移动。
很明显，这是一个非常简洁的答案。您没有使用过需要这种正常运行时间的应用程序的经验，因此如果您想接近神话般的 100% 正常运行时间，您确实需要请专业人员参与。
- @TC1 我敢打赌你 [$200](http://xkcd.com/955/) 不会成功。 (9认同)
- 同意。完全。疯狂的。 (7认同)
- @ErikA 要求 100% 正常运行时间表明对系统技术特性的无知。没关系，因为客户的工作就是做他们所做的一切。您的工作是设计 IT 系统。像这样难缠的客户可能是噩梦，但他们也可能成为您最好的客户。 (5认同)
- 他们曾经？？ (2认同)
- @Sirex 参考最近的实验 @ CERN，其中发现中微子的传播速度超过光速。不过，结果尚未得到独立科学家的证实。 (2认同)
- +1 提到 BGP 和真正的路由设备。当我读到这个问题时，首先想到的是“任播”。即使是最好的分布式任播托管服务（例如 Google）仍然有停机时间，即使是本地而不是全球。 (2认同)
jdw*_*jdw 54
嗯，这绝对是一个有趣的。我不确定我是否想让自己在合同上有义务保证 100% 的正常运行时间，但如果我必须这样做，我认为它看起来像这样：
从完全脱离网络的负载均衡器上的公共 IP 开始，至少构建其中的两个，以便一个可以故障转移到另一个。像 Heatbeart 这样的程序可以帮助自动故障转移。
Varnish 主要被称为缓存解决方案，但它也做了一些非常不错的负载平衡。也许这将是处理负载平衡的好选择。它可以设置为有 1 到 n 个后端可选地分组在控制器中，这将随机或循环进行负载平衡。Varnish 可以变得足够智能，可以检查每个后端的健康状况，并将不健康的后端排除在循环之外，直到它重新上线。后端不必在同一网络上。
这些天我有点喜欢 Amazon EC2 中的弹性 IP，所以我可能会在 EC2 中的不同区域或至少在同一区域的不同可用区中构建我的负载均衡器。如果您必须将现有的 A 记录 IP 移动到新的盒子，那您可以选择手动（上帝保佑）启动一个新的负载均衡器。
但是，Varnish 不能终止 SSL，所以如果这是一个问题，你可能想看看像 Nginx 这样的东西。
您可以在您的客户端网络中拥有大部分后端，而在其网络之外拥有一个或多个后端。我相信，但不是 100% 肯定，您可以优先考虑后端，以便您的客户端机器获得优先权，直到它们全部变得不健康为止。
如果我有这个任务并且毫无疑问地随着我的进展不断完善它，我就会从那里开始。
但是，正如@ErikA 所说，它是互联网，并且网络中总会有一些不受您控制的部分。您需要确保您的法律只将您与您控制范围内的事情联系起来。
- +1 用于实际解决 OP 的主要问题。 (11认同)
- 如果您打算使用 Amazon，您肯定希望将您的机器分布在 5 个可用区周围。他们所有的区域都不太可能同时消失。 (3认同)
- 有一段时间我一直在考虑使用 Amazon 和 MS 进行云部署，但在过去的几个月里，它们都发生了重大中断。SSL 至关重要。 (2认同)
Nic*_*int 30
没问题——虽然稍微修改了合同措辞：
... 保证 100% 的正常运行时间（四舍五入到零小数位）。
- 根据某些惯例，“100%”只有一位有效数字，因此二分之一和一之间的所有数字都会四舍五入为“100%”；50% 将舍入为 100%。 (4认同)
- +1 注意，100% 不是 100,0% 或 100,000% 等。十进制数字很重要，它们表示精度；) (2认同)
Mik*_*ike 26
如果 Facebook 和亚马逊做不到，那你也做不到。就这么简单。
- 他可能比他们所有人加起来都聪明，谁知道呢：p (17认同)
- @DavidFreitas - 我认为在合同中通常是字面意思... (13认同)
- 100% 正常运行时间不一定是字面上的人 - 这意味着：在需要时100% 可用。例如，银行系统应该始终可用，而且它们做得很好。仅仅因为他们每年一次停机维护 1 秒并不意味着他们未能实现 100% 的正常运行时间目标。 (3认同)
- @Matt 仅仅因为 Facebook/Amazon 做不到，并不意味着较小的网站做不到。许多大型网站比小型网站面临更难克服的问题。 (2认同)
Jun*_*ter 25
从 Hacker News添加oconnore 的回答
我不明白这是什么问题。客户希望你为灾难做计划，而他们不是面向数学的，所以要求 100% 的概率听起来很合理。工程师，正如工程师们倾向于做的那样，记得他第一天的 prob&stat 101，没有考虑到客户可能不会。当他们这么说时，他们不是在考虑核冬天，而是在考虑 Fred 把他的咖啡倒在办公室服务器上、磁盘崩溃或 ISP 宕机。此外，您可以完成此操作。使用地理上不同的、独立的、自我监控的服务器，您基本上不会有停机时间。3 台服务器独立运行 (1) 三 9 可靠性，具有良好的故障转移模式，您的预期停机时间每年不到一秒 (2)。即使这一切一下子发生，您仍然处于 Web 连接的合理 SLA 范围内，因此实际上不存在停机时间。客户端仍然需要处理世界末日场景，但哥斯拉除外，他将拥有“永远”启动的服务。
(1) 洛杉矶的服务器与波士顿的服务器合理地独立，但是，是的，我知道存在一些涉及核战争、中国黑客破坏电网等的交叉点。我认为您的客户不会因为这个。
(2) DNS 故障转移可能会增加几秒钟。您仍然处于客户端必须每年重试一次请求的情况，这同样在合理的 SLA 内，并且通常不会被视为与“停机”相同的情况。对于在故障时自动重新路由到可用节点的应用程序，这可能不会引起注意。
- 问题是他们是用合同术语说的。这意味着如果灾难*确实*发生并且您需要超过十秒钟的时间才能通过备份使站点重新上线，他们将有资格提起诉讼。 (6认同)
- 我见过一个提供 100% 正常运行时间保证或退款的网站。诀窍是他们收取大量费用并分成几个月。所以有些月份没有支付，你围绕它安排一切，并用工作正常的月份来弥补损失。 (3认同)
vor*_*aq7 17
你被要求做一些不可能的事情。
在这里查看其他答案，与您的客户坐下来，解释为什么这是不可能的，并评估他们的反应。
如果他们仍然坚持 100% 正常运行时间，请礼貌地告知他们无法完成并拒绝合同。你永远不会满足他们的要求，如果合同不完全糟糕，你会受到惩罚。
- 需要定义 100%，即 100% 可用，除非在进行维护或升级时，并且该时间将被限制为每月最多几个小时的安静时间。在这种情况下，这一切都_取决于_网络应用程序的目的和用途是什么...... (2认同)
Bry*_*her 13
相应的价格，然后在合同中规定超过 SLA 的任何停机时间都将按他们支付的费率退还。
我上一份工作的 ISP 就是这样做的。我们可以选择一条正常运行时间为 99.9% 的“常规”DSL 线路，价格为 40 美元/月，或者是 99.99% 正常运行时间的绑定三条 T1 线路，价格为 1100 美元/月。每月经常中断 10 多个小时，这使他们的正常运行时间远低于 40 美元/月的 DSL，但我们只获得了大约 15 美元左右的退款，因为这就是每小时 * 小时的费率。他们从交易中弄得像土匪一样。
如果您每月支付 450,000 美元以获得 100% 的正常运行时间，而您只达到 99.999%，则需要向他们退还 324 美元。我敢打赌，假设完全分布式的主机、多个 1 级上行链路、花哨的硬件等，基础设施成本达到 99.999% 将在每月 45,000 美元左右。
- 如果您看到有人承诺 100% 正常运行时间，那么这正是他们正在做的。承诺 100% 正常运行时间和交付它之间存在差异。如果客户试图向您引用竞争对手的 SLA，最好向客户解释这一点。 (3认同)
Paw*_*cki 10
如果专业人士质疑99.999% 的可用性 [是] 实际或经济上可行的可能性，那么 99.9999% 的可用性甚至更不可能或不切实际。更别说100%了。
您将无法在很长一段时间内达到 100% 的可用性目标。您可能会在一周或一年内逍遥法外，但随后会发生一些事情，您将承担责任。后果可能从声誉受损（你承诺过，你没有兑现）到合同罚款导致的破产。
小智 10
有两种类型的人要求 100% 正常运行时间：
- 完全不了解计算机、计算机系统或 Internet 的人。*
- 那些故意自欺欺人的人，要么是为了测试你说“不”的能力（谷歌“橙汁测试”），要么是试图获得某种合同 SLA 杠杆，以便以后不再向你付款。
我的建议，在很多情况下都遭受过这两种类型的客户，是不要接受这个客户。让他们把别人逼疯。
*同一个人可能不会不好意思询问超光速旅行、永动机、冷聚变等。
- +1 橙汁测试.. 我喜欢但不知道它:) (2认同)
小智 8
我会与客户沟通，与他们确定 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 还是 100 万个 9 并不重要——问题是当/如果您无法交付时，他们会得到什么。显而易见的答案是以您想要收取的价格的 5 倍提供一个 100% 正常运行时间的订单项，然后如果您错过该目标，他们将获得 4 倍的退款。你可能会得分！
DNS 更改仅在配置为需要时间时才需要时间。您可以将记录的 TTL 设置为一秒 - 您唯一的问题是确保您及时响应 DNS 查询，并且 DNS 服务器可以处理该级别的查询。
这正是 GTM 在 F5 Big IP 中的工作方式 - 默认情况下 DNS TTL 设置为 30 秒，如果集群的一个成员需要接管，DNS 会更新，新 IP 几乎立即被占用。最多 30 秒中断，但这是边缘情况，平均为 15 秒。
- @Paul 无视现实是不可接受的做法，无论它让每个人多么生气。 (13认同)
- 根据我的经验，一些 DNS 服务器会忽略他们认为非常低的 TTL（尽管有 RFC）。在全球范围内，任何少于 5 分钟的时间都会变得有些不可靠。 (10认同)
- @Paul - OP 无法控制地球上每个 ISP 的 DNS 解析器。因此，他们无法选择说“如果您要使用我们的网站，请不要使用 Comcast/Roadrunner/任何人作为您的 ISP，因为他们会忽略我们的 TTL 设置”。这是他们无法控制的事情，因此太脆弱了，不能被视为解决这个问题恕我直言。该解决方案必须包括某种方式，以便能够在不依赖网络中可能不合作的其他位的情况下在内部强制使用 IP。 (6认同)
- 我在这方面与 jdw 在一起。我已经看到许多 DNS 服务器完全忽略了 TTL，即使是 1 小时的设置，并且默认恢复为 24 小时左右。 (5认同)
- 这有点像没有 UPS，因为电源“应该可以正常工作”。这不是构建系统的前瞻性思维方式。如果您知道系统中存在脆弱的部分，无论出于何种原因，您都应该尝试对其进行解释。 (3认同)
- 如果他们不遵守 TTL，他们就不会运行 DNS，因此可以被忽略——他们已经做出了自己的决定，为他们的用户“打破互联网”。许多故障转移解决方案依赖于遵守 TTL。 (2认同)
- @Paul：客户：“服务已关闭。” OP：“不，已经结束了。” 客户：“我无法访问它，但我可以访问 Google。”。从客户的角度来看，他们的连接“正常工作”，但也许他们的 ISP 的 DNS 忽略了低 TTL。仅仅因为他们的连接不符合标准的技术原因并不意味着他们会认为它“正常工作”。 (2认同)
| 归档时间： |
|
| 查看次数： |
65743 次 |
| 最近记录： |