您如何计算云服务的复合服务水平协议(SLA)?


27

通过托管云服务Amazon Web服务天青谷歌和其他大多数发布小号 ervice 大号埃维尔一个 greement或SLA,因为他们提供的个人服务。然后,架构师,平台工程师和开发人员负责将它们放在一起,以创建一个架构,为应用程序提供托管。

孤立地考虑,这些服务通常提供的可用性在三到四分之九的范围内:

  • Azure Traffic Manager:99.99%或“四个九”。
  • SQL Azure:99.99%或“四个九”。
  • Azure应用服务:99.95%或“三九五”。

但是,当在体系结构中组合在一起时,任何一个组件都可能会发生中断,从而导致总体可用性不等于组件服务。

系列化合物的可用性

批量供货

在此示例中,存在三种可能的故障模式:

  • SQL Azure已关闭
  • 应用服务已关闭
  • 都下来了

因此,此“系统”的总体可用性必须低于99.95%。我对这种思维的理由是,如果在这两项服务的SLA是:

该服务将在24小时中的23小时内提供

然后:

  • 应用服务可能在0100到0200之间
  • 数据库出在0500和0600之间

这两个组成部分均在其SLA内,但整个系统在24小时内无法使用2小时。

串行和并行可用性

串行和并行可用性

在这种体系结构中,主要有很多故障模式:

  • RegionA中的SQL Server已关闭
  • RegionB中的SQL Server已关闭
  • RegionA中的应用服务已关闭
  • RegionB中的应用服务已关闭
  • 流量管理器已关闭
  • 以上组合

由于流量管理器是断路器,因此能够检测任一区域的中断并将流量路由到工作区域,但是流量管理器仍然存在单点故障,因此“系统”的总可用性无法高于99.99%。

如果企业希望获得比架构所能提供的服务级别更高的服务水平,则如何为企业计算和记录以上两个系统的复合可用性,并可能需要重新配置?

如果您想注释图表,我已经在Lucid Chart中构建了它们并创建了一个多用途链接,请记住,任何人都可以对其进行编辑,因此您可能希望创建页面的副本以进行注释。


假设您的应用程序能够应对会话中断,则SPOF的最低SLA是多少?
2015年

1
@Tensibai-我认为这不可能,根据我的第一个示例,如果两种服务的SLA都可以在24小时中的23小时内可用,则App Service可能在0100和0200之间,而数据库在0500和0600,这两个组成部分都在其SLA内,但整个系统在24小时中有2个小时不可用。
理查德·斯莱特

是的,这是有道理的,但是在这种情况下,结果应该是所有否的乘积?
2015年

我的意思是应用99.95 x sql 99.95应该是该组的整体可用性
Tensibai

还请记住,通过重试或故障转移或降级而不是完全故障,您可以构建比其组件更可靠的系统。
熊加米奥夫

Answers:


19

我认为这是一个数学问题,而SLA可能会很好。

在这种情况下,我们可以依靠概率规则来获得总体。

对于第一种情况,App Service(A)和Sql Service(B)同时关闭的概率是它们的概率乘积:

P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025

其中之一发生故障的概率是它们的概率之和:

P(A)+P(B) = 0.001

当两个事件是独立的时,考虑到两个事件均发生的概率的公式为:

P(A,B) = P(A) + P(B) - P(A)*P(B) = 0.001 - 0,00000025 = 0,00099975

因此,总体SLA将以1 - 0,00099975 = 0,99900025百分比为单位99.900025 %

简化是第一个概率的乘积:0.9995 * 0.9995 = 0,99900025

应用于您的1h / 24h中断(一天中的4,166666%),得出的结果(十进制缩写):

0.0416 + 0.0416 - (0.0416 * 0.0416) = 0,081597222

因此,可以的概率1 - 0.0816 = 0.9184以百分比表示:91,84%

24 * 0.0816 = 1.95 h

这比2小时的最坏情况要少,因为两者都有可能同时停机。

请记住,您可能会注意到每个is的可用性95,84%0,958333333 * 0,958333333 = 0,918402778这是91.84%上面提到的(抱歉,此处为完整的小数,但演示时需要使用它们)

现在,对于第二种情况,我们将从每个区域的复合概率开始获益(对不起,我拒绝了SQL的更改以保持其合理性),假设该区域本身没有独立的概率,并且每个区域都是孤立的,因此数据库故障只会使区域失效。

我们有流量管理器的OK概率,P(T) = 0.9999并且每个app + DB夫妇都有P(G) = 0,99900025来自

我们必须应用故障概率乘积来获得两个区域同时下降的概率,所以我们发挥了多少作用?
0,00099975 * 0,00099975 = 0,0000009995000625这意味着至少一个区域的总体可用性99,049375 %

现在我们有了整个区域的可用性,带有流量管理器的产品为我们提供了系统的整体可用性:

0.9999 * 0,9999990004999375 = 0,99989900059988750625

总体可用性为 99.989900 %

可以从Azure的文档中获得另一个解释来源(链接由Raj Rao提供


总体可用性似乎很低-实际上,通过添加其他区域和流量管理器,SLA比仅单个区域要低一个数量级。我正在尝试从大脑的背面挖掘过去用于网络的方法。
理查德·斯莱特

!我确定我会生气。
理查德·斯莱特

@RichardSlater数学更正
Tensibai '17

2
@BruceBecker可能是的,似乎IEEE已经发表了有关该主题的研究,但是我怀疑,鉴于计算这些数字的目的,更多的是要具有具体的“证明”,即您是否需要高可用性功能添加到系统中-即我们使用这些数字根据公司的风险偏好来制定成本效益决策。建立贝叶斯模型可能并不代表我们时间的最佳利用。
理查德·斯莱特

1
@BruceBecker是的,问题的一部分被捆绑了(同一数据中心关闭,并且两个服务都在其中,这必须很低),其余的我认为我们可以安全地假设应用程序服务和sql服务运行在不同的系统上,并且不太可能由于相同的原因同时失败。进一步学习数学将需要有关Azure架构如何完成的精确文档,因此只能由Microsoft的人员来回答。
Tensibai

18

在阅读了Tensibai的出色答案之后,我意识到我曾经能够为网络分析目的而计算出这个值。我挖出了Chris Oggerino撰写的《高可用性网络基础知识》,并从最初的校长那里破解了这一过程。

直接从Tensibai的答案中得到我的系列示例只是一种情况,就是将每个组件彼此可用的可能性相乘:

批量供货

所以

99.95%* 99.95%= 99.9%

并行计算它有点复杂,因为我们确实需要考虑可用性的百分比:

串行和并行可用性

计算过程如下:

  1. 将两个区域的不可用状态相乘。

    0.1%* 0.1%= 0.0001%

  2. 将其转换回可用性

    100%-0.0001%= 99.9999%

  3. 将流量管理器的可用性乘以两个区域的可用性。

    99.99%* 99.9999%= 99.9899%

  4. 结果是整个系统的可用性。

    99.9899%接近99.99%

我最终使用Excel进行计算,这是值:

Excel值

...以及公式...

Excel公式


1
就是这样,比我的方法更直接(我觉得有必要证明背后的数学:))
Tensibai

同意,您的答案对数学真的很好。
理查德·斯莱特

SQL Azure是99.99%而不是99.95%
Jeffery Tang

1
@JefferyTang(可能)是在问题/答案撰写时(我不太记得),实际值并没有改变获取“如何从单个零件SLA计算复合SLA”答案的方法。是真正的问题。
Tensibai
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.