据报道, Erlang已在生产系统中使用了 20 多年,正常运行时间百分比为 99.9999999%。
我做了以下数学运算:
20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s
这意味着系统在 20 年期间只有不到一秒的停机时间。我不是想挑战它的有效性,我只是好奇我们如何才能(有意或无意地)关闭系统仅 0.631 秒。有熟悉大型软件系统的朋友可以给我们解释一下吗?谢谢你。
有谁知道如何计算一组处理单元(或机器)上服务的停机时间?
据报道, Erlang已在生产系统中使用了 20 多年,正常运行时间百分比为 99.9999999%。
我做了以下数学运算:
20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s
这意味着系统在 20 年期间只有不到一秒的停机时间。我不是想挑战它的有效性,我只是好奇我们如何才能(有意或无意地)关闭系统仅 0.631 秒。有熟悉大型软件系统的朋友可以给我们解释一下吗?谢谢你。
有谁知道如何计算一组处理单元(或机器)上服务的停机时间?
可靠性数据不应该衡量AXD301
(有问题的项目)的任何部分被关闭超过 20 年的总时间。它代表了系统提供的服务在这 20 年中AXD301
一直离线的总时间。细微的差别。正如乔阿姆斯特朗在这里所说:
AXD301 达到了九个九的可靠性(是的,你没看错,99.9999999%)。让我们把它放在上下文中:5 个 9 被认为是好的(每年 5.2 分钟的停机时间)。7 个 9 几乎无法实现……但我们做到了 9 个。
为什么是这样?没有共享状态,加上复杂的错误恢复模型。
如果你再深入一点,在 Erlang 的原作者 Joe 写的博士论文中(其中包括一个案例研究AXD301
),你会读到:
本章研究的项目之一是爱立信 AXD301,这是 一款高性能、高可靠性的 ATM 交换机。
因此,只要交换机所属的网络在没有停机的情况下运行,作者就可以声明“九个九的可靠性” AXD301
(这是他曾经说过的,避免细节)。这并不一定意味着 Erlang 是这种高可靠性的唯一原因。
编辑:事实上,“20 年”本身似乎是一种误解。乔在同一篇文章中提到了 20 年的数字,但它实际上与九个九的可靠性数字无关,这可能来自一个更短的研究(正如其他人所提到的)。
虽然其他人已经解决了您所询问的具体案例,但您的问题似乎是基于误解。您提出问题的方式让我相信您认为有一个手动过程可以让系统在崩溃或因维护而停机后再次运行。
Erlang 有几个特性可以消除人工工作时间作为停机时间的来源:
热代码重载。在 Erlang 系统中,很容易为现有模块编译和加载替换模块。BEAM 仿真器会自动进行交换,而不会明显停止任何操作。毫无疑问,这种传输发生的时间很短,但它是在计算机时间内自动发生的,而不是在人工时间中手动发生的。这使得在基本为零停机时间的情况下进行升级成为可能。(如果替换模块存在导致系统崩溃的错误,您可能会遇到停机时间,但这就是您在部署到生产之前进行测试的原因。)
监事。Erlang 的 OTP 库有一个内置的监控框架,它可以让你定义系统在模块崩溃时应该如何反应。此处的标准操作是重新启动发生故障的模块。假设重新启动的模块不会立即再次崩溃,则对您的系统收取的总停机时间可能只有几毫秒。一个几乎从不崩溃的可靠系统在多年的运行过程中可能只累积总停机时间的一小部分。
进程。这些大致对应于其他语言中的线程,除了它们不共享状态,除非通过持久数据存储。除此之外,通信是通过消息传递发生的。因为 Erlang 进程非常便宜(比 OS 线程便宜得多),这鼓励了松散耦合的设计,因此如果一个进程死亡,只有一小部分系统会经历停机。通常,主管重新启动一个进程,对系统的其余部分几乎没有影响。
异步消息传递。当一个进程想要告诉另一个进程时,Erlang 语言中有一个一流的运算符可以让它这样做。消息发送过程不必等待接收者处理消息,也不必协调发送数据的所有权。Erlang 的消息传递系统的异步功能特性可以解决所有这些问题。这有助于保持较高的正常运行时间,因为它减少了系统某一部分的停机时间对其他部分的影响。
聚类。这源于上一点:Erlang 的消息传递机制在网络上的机器之间透明地工作,因此发送进程甚至不必关心接收者是否在单独的机器上。这提供了一种简单的机制,可以在多台机器之间分配工作负载,每台机器都可以单独关闭,而不会损害整个系统的正常运行时间。
99.9999999% 的可用性数字是一个经常被引用但从根本上误导的统计数据。AXD-301 团队成员之一的 Mats Cronqvist在旧金山举行的 2010 年 Erlang 工厂会议上发表了演讲 (视频) (我参加了),讨论了这个精确的可用性统计数据。据他介绍,英国电信声称使用 AXD-301 进行了“5 个节点年”的试用期(我相信是从 2002 年 1 月到 2002 年 9 月)。到试验结束时,有 14 个节点承载实时流量。
Cronqvist 特别指出,这并不代表整个 AXD-301 历史或 Erlang 的一般历史,他对 Joe Armstrong 一直引用这一点感到不高兴,导致对 Erlang 可靠性的期望过高。其他人写道,五个九是一个更现实的数字。
应该说我是一个狂热的 Erlang 支持者和开发者,我认为 Erlang 的专家使用确实可以带来非常高可用的系统,但只是想减少炒作。我当然假设 Cronqvist 对事实的陈述是准确的,并且没有理由不相信。
我对这些统计数据的理解是,它是在生产中的所有 AXD301 系统上计算的。我们可以预计,当 AXD301 出现严重问题时,它会停机超过 0.631 秒。在此期间,其他 AXD301 将接管以保持网络正常运行。
但是,当您将所有正在运行的 AXD301 的总小时数相加,计算出故障 AXD301 的比率时,您会发现 99.999999%
这就是我对这个数字的理解。
希望这有帮助。