sla 可用性_使用数值性能数据标准化云SLA可用性

与√2的巴比伦近似一样，在实践中通常无法获得确切的答案。 作为云提供商服务水平协议的一部分，计算服务可用性保证时也是如此。 提供者/合作伙伴关系中的变量，四舍五入的累积和截断计算错误-有许多元素可以阻止确切的答案出现在顶部。

但是，您可以结合使用性能数据的数值分析和对错误的约束来创建在现实世界中运行良好的近似解决方案。 本文向您展示了如何开始。

数值分析的目标和期望

使用性能数据的数值分析进行SLA标准化的目的是，通过获取近似解决方案并同时保持合理的错误界限，确保至少有99.9％的时间可以使用云服务。 它应重点关注在云服务中运行的SaaS应用程序，PaaS环境或IaaS虚拟机如何从用于服务可用性计算的数据数值分析中受益。

换一种说法：

• 选择一种算法，该算法不会使误差在计算中变得更大。
• 通过将可用性服务分解为独立的池来构建算法。

让我们看一看客户从保证的服务可用性级别可以期望的每种云服务类型。

SaaS用户可以期望在总可用小时数，中断对小时和分钟的影响以及平均修复时间方面具有高可用性。 他们还可以期望将服务器故障转移到健康的数据中心将在几分钟内完成。

PaaS开发人员在与提供商协商后可以期望高可用性，以允许开发人员采取主动行动以制止对系统的损害。 这些措施包括构建由单个主机而不是多个主机组成的简单服务，以使开发人员能够创建复制的服务实例，这些实例可以在主机故障中幸免，并有助于实现高可用性。 PaaS开发人员使用数值分析来获得近似的保证服务可用性级别，同时保持合理的错误界限。

IaaS基础架构专家可以在与提供商协商以制定积极的行动以阻止对虚拟机系统的损害的同时保持高可用性的情况下期望高可用性。

由于合作伙伴关系会产生复杂的变量，因此接下来让我们来看一下。

伙伴之间的复杂关系

传统上来说，SLA是服务提供商和云服务客户（企业，企业或政府机构）之间的合同，而其他服务的价值链不断扩大，使得SLA对于合伙关系之间通常无数复杂的关系非常重要。

例如，同一服务提供商可以提供以下服务：

• 云服务客户（SaaS最终用户，PaaS开发人员和IaaS基础架构专家）
• 供应商
• 大型企业
• 业务领域
• 政府机构

同一供应商提供以下服务：

• 网络提供商
• 云服务提供商
• 网络服务提供商
• 企业企业
• 业务领域
• 政府机构

相同的网络提供商提供网络访问服务，并提供99.9％的有保证的服务可用性，以：

• 其他网络提供商
• SaaS提供商
• 州政府机构

同一家企业提供私有云服务，可保证99.999％的服务可用性：

• 适用于市政府机构的SaaS云服务
• PaaS云服务可开发新的SaaS应用程序
• 其他企业将运行私有IaaS云服务

为了成功竞争，公司必须积极管理服务质量。 由于提供这些服务取决于多个合作伙伴，因此SLA的管理对于成功至关重要。

如果术语未标准化，则在合作伙伴的复杂关系中管理SLA会变得更加困难。 让我们发现一些术语不一致的地方。

可用性是什么？

如果不分析系统的故障点，那么从一开始就计算出系统可用性（SLA）。 事情变得复杂的是，不同的人对可用性的定义不同。 例如：

• 计划的维护停机时间是否会计入系统可用性计算？
• 系统可用性计算涵盖哪些系统组件？ 数据库？ 应用？ 防火墙？
• 系统可用性计算中如何处理错误？ 在计算近似解的迭代过程中，能否保持误差的合理界限？

在其经典形式中，可用性表示为服务需要启动的总时间的一部分。 从理论上讲，它可以量化为故障恢复时间（也称为MTTR，平均恢复时间）与中断之间的时间间隔（MTBF或MTBI，故障或中断之间的平均时间）之间的关系。

对于全年的正常运行时间（365天X 24小时X 60分钟= 525,600分钟），正常运行时间可以表示为“精确度”（如本文中表1所示）。

但是，在达到可用性目标以及9的实际含义之前，让我们检查一下数值分析错误类型。

数值分析错误类型

许多数值方法是迭代的。 它们不应以多个步骤终止。 它们涉及多次重复计算。 从最初的猜测开始，迭代方法形成逐次逼近，仅在极限范围内收敛到精确解。 由于算法的限制或计算机硬件的物理限制，所有数值方法都涉及近似值。

在迭代过程的操作过程中，通常会引入两种类型的错误：截断和舍入。 这些误差可能会累积到一定程度，从而支配计算并使结果变得毫无意义。 或者它们可以保持在可接受的范围内，以使结果保持显着。

截断错误是由截断数学过程引起的。 通常使用泰勒级数来近似求解可以在不同级别截断的解。 在泰勒级数中保留的项越多，则近似值越好，截断误差也越小。

四舍五入错误是由近似表示数字引起的。 它是计算得出的数字近似值与其精确数学值之间的差。

四舍五入错误源于以下事实：计算机只能使用固定数量的有效数字表示数字。 在算法中使用双精度可减少数值计算中舍入误差的影响。 双精度使用64位和52位数字来表示有效数字。 例如，这可以将be表示为3.141592653589793 ...，即16位数字。 使用双精度的数字表示的完整范围是±2.2250738585072020x10 ^-308至±1.7976931348623157x10 ³⁰⁸ 。

一旦产生错误，它通常会在整个计算过程中传播。 如果误差在可接受的范围内，并且在计算过程中不会变得太大，则该算法在数值上是稳定的。

可用性目标

九是设置可用性目标的诱人目标。 如表1所示，这9个数字包含所有数字9，其百分比表示系统可用的时间。 任何可用性目标（包括那些百分比不全为9的可用性目标）的问题在于，该目标并未揭示其代表的服务组件可用性。

顺便说一句，很可能九个数字最初是由长期运行的大型机上的计算机硬件问题造成的。 对于FORTRAN我数值分析的项目，我知道，当主机转换^1月 _10日至0.10，机器内部计算作为0.099999999 ......由于对寄存器的硬件限制。 我的程序将结果显示为0.10。

让我们看一下表格并假设网站每周7天，每天24小时都在运行电子商务。

表1.部分中断表：9

在365 x 24年中想到9的一种简便方法是数量级：

• 五个九代表五分钟的停机时间
• 四个九代表大约50分钟
• 三九，500分钟
• 等等

每年每十分之一百分点的停机时间约为500分钟。 当然，对于不需要每周24小时，每天7天运行的服务（例如在单个位置的工厂底层应用程序），停机分钟数将根据本地运行情况而有所不同。窗口。

很明显，每周超过一分钟的停机时间可能是一个非常昂贵的提议。 冗余系统将所需的硬件加倍（在极端情况下，可以降低到专门的容错过程，以比较每个时钟的指令），而可以处理冗余的复杂软件仅仅是开始。 处理复杂性的技能和系统无法处理变更的能力很容易提高成本。

此外，经验表明，此类环境中的人员和流程问题导致的停机时间远远超出了系统本身可以阻止的停机时间。 一些IT运营主管喜欢说提高可用性的最佳方法是锁住数据中心的大门。 尽管如此，对高可用性目标设定的任何尝试都应从仔细分析用户真正可以承受的停机时间以及任何中断的影响开始。

九是设定目标的诱人目标。 对于这九个数字中的任何休闲消费者，最常见的冲动就是选择其中的许多。 在屈服于诱惑之前，请记住一件事-如果不先询问“什么是可用性”，就无法决定所需的可用性。 和“每周/每年的停机时间代表什么？”。

例如，考虑以下内容：

Availability measure = 98%
Downtime per year = 7.3 days
Downtime per week = 202.15 minutes

计算如下：

525,600 minutes x 2 percent = 10512 minutes downtime per year
10512 minutes/52 weeks = 202.15385 minutes downtime per week

他们没有输入：

202.15385 minutes/7 days = 28.879121 minutes downtime per day

因为它将舍入到28.88分钟，所以会产生舍入错误：

365 days/52 weeks = 7.0192308
Round to 7 days
The difference is 0.0192308 X 52 = .99999952
 
Round to 1 day and then you get 8 days per week, which is impossible!

99.9是数字四舍五入或截断的结果吗？ 这取决于在计算可用性级别时使用了哪种数值方法。

等价的功能：注意重要性的降低

云提供商通常会提供冗余服务和服务器，以掩盖某些类型的系统故障。 一些提供程序没有提供算法来提供更有效的方法来获得近似可用性指标，同时又获得了在计算过程中生成的错误的可接受范围。 如果误差超出范围，则如此获得的度量将显示出重要性下降。

PaaS开发人员最有可能比提供方拥有更多的专业知识，来开发解决完好的条件的算法-这种算法在数值上可能是稳定的，或者在数值上是不稳定的。 数值分析的一种技术是找到一种稳定的算法来解决适当摆放的数学问题。

例如，计算2的平方根（大约为1.41421）是一个恰当的问题。 许多算法通过从x ₁到√2的初始近似值开始解决这个问题。 例如，从x ₁ = 1.4开始，然后计算改进的猜测x ₂ ，x ₃等。一种这样的方法是著名的巴比伦方法，它由x _{k + 1} = x _k / 2 + 1 / x _k给出 。 另一个迭代，我们称为方法X，由x _{k + 1} =（x _k ² -2） ² + x _k 。[3]给出。 我已经用初始猜测x ₁ = 1.4和x ₁ = 1.42计算了表2中每个方案的一些迭代。

表2.两种迭代方法

可以看到，无论初始猜测如何，巴比伦方法都收敛很快，而方法X在初始猜测值1.4时收敛得非常慢，而对于初始猜测值1.42则收敛得很慢。 这意味着巴比伦方法在数值上是稳定的，而方法X在数值上是不稳定的。

数值稳定性受机器保持的有效数字位数的影响。 如果我们使用保留前四个浮点数字的机器，则出于说明目的，这两个等效函数给出了一个重要意义的很好的例子：

f(x) = x(√x+1 - √x)
 
            AND
 
                x
   g(x) =  -----------
            √x+1 + √x

如果比较这两个的结果：

f(500) = 500(√501 - √500)
  f(500) = 500(22.3830 - 22.3607)
  f(500) = 500(0.0223) = 11.15
 
          AND
 
                    500
  g(500) =    ---------------
                √501 + √500
 
                    500
  g(500) =  -------------------
             22.3830 + 22.3607
 
                    500
  g(500) =       ---------
                  44.7437
 
  g(500) =        11.1748

您意识到，即使两个函数都是等效的，重要性的损失（也称为减法消除）对结果有巨大影响。 为了表明它们是等效的，您需要从f（x）开始：

f(x) = x(√x+1 - √x)
 
                       (√x+1 + √x)
  f(x) = x(√x+1 - √x) -----------
                       (√x+1 + √x)
 
            ((√x+1)2 - (√x) 2 )
  f(x) = x ------------------
               (√x+1 + √x)
 
               x
  f(x) = -------------
          (√x+1 + √x)

并以g（x）结尾，如下所示：

f(x) = 99.99991846
   g(x) = 99.99988723

结果的真实值为11.174755，将结果四舍五入为十进制数字后为（500）= 11.1748。

现在假设您为f（x）和g（x）输入不同的x值； 用于与可用性指标一起使用的一组等效功能，显示以下结果：

f(x) = 99.99991846
g(x) = 99.99988723

误差差为.00006879。

问题是要使用哪个函数：f（x）或g（x）。 为了使舍入和截断误差在计算期间不会变得更大，一个伙伴可以使用f（x），而另一个伙伴可以使用g（x）。 第三伙伴可以在计算的不同步骤中交替使用f（x）和g（x）。

作为最佳实践工作的一部分，合作伙伴应商定与使用的功能相比，在功能上可能比另一功能更稳定的功能。

在我从事的Fortran项目中，我通过比较以下内容评估了不同的功能：

• 例如，每个小数点后六个位的结果是什么。
• 计算中误差增加了多少。

我选择了在计算100个小数位时数值上最稳定的函数，这样在计算过程中舍入和截断误差不会太大。

减少故障转移对高可用性的影响

高可用性计算是系统组件（例如数据库服务器，应用程序服务器和防火墙）的可用性级别的组合。 每个组件都附带有冗余服务器，以减少故障转移对高可用性的影响。 更好的是，进取的PaaS开发人员可以构建算法以将服务分解为独立的池。

发生故障时，开发人员的软件应快速识别那些故障并开始故障转移过程。

有三种获取可靠和数值稳定的可用性指标的方法：

• 将可用性指标分解为可以衡量的可用性服务。
• 提供额外的冗余服务器和服务，而不会产生高昂的成本。
• 构建一种算法，将服务分解为独立的池，而不是多个冗余服务。

让我们关注第三种选择。 假设开发人员的计费应用程序由业务逻辑组件A，B和C组成，那么他可以组成一个服务组，如下所示：

(A1, B1, C1), (A2, B2, C2) ... (An, Bn, Cn)

其中n是表示服务组类别编号的组件类型编号。

对于服务类别1：

• A1是查找服务代码的逻辑
• B1是将服务类别插入帐单的逻辑
• C1是检查邮政编码准确性的逻辑

对于服务类别2：

• A2是查找服务代码的逻辑
• B2是将服务类别插入帐单的逻辑
• C2是检查邮政编码准确性的逻辑

对于服务类别n：

• 查找服务代码的逻辑是
• Bn是将服务类别添加到帐单中的逻辑
• Cn是检查邮政编码准确性的逻辑

如果运行PaaS的单个虚拟机发生故障，则该故障将导致整个系统组丢失。 这意味着，如果一个系统组中的组件A1发生故障，则其他两个组件B1和C1发生故障。 如果有多个服务组，则整个系统将失败。

为了解决此问题，开发人员将组件分解成这样的独立池，以便他可以在运行状况良好的数据中心创建多个冗余服务副本：

(A1, A2,...An ), (B1, B2...Bn ), (C1, C2, ...Cn)

这意味着，如果组件A1发生故障或变慢，则同一独立池中的所有其他组件A2，... An都不会发生故障。 组件B1，B2 ... Bn的第二个独立池和组件C1，C2 ... Cn的第三个池都不会失败。

当计费应用程序的所有独立服务池正在进行故障转移时，开发人员使用快速超时和慢速服务重试。 开发人员需要确定何时暂停超时和重试，以避免因等待缓慢或失败的服务而消耗所有资源而导致系统锁定。

结论

在规划SLA标准化时，请考虑开发和遵循多个合作伙伴可以使用的标准做事方式的最佳做法。 除了新的术语外，还应考虑对性能数据进行数值分析，以获取更可靠的可用性指标，同时保持合理的误差范围。 当合作伙伴就协商SLA时使用性能数据数值分析的标准方法达成共识时，他们将为SLA标准化过程做出贡献

翻译自: https://www.ibm.com/developerworks/cloud/library/cl-SLAloadbalance-numanalysis/index.html