云服务级别协议回顾与总结

来自 “云计算用例白皮书” 版本 4.0

本文是对 “云计算用例白皮书” 版本 4.0 中服务级别管理部分的回顾 —— 由云计算用例讨论组发布 —— 来重点介绍架构师和开发者向云迁移时所关注的 SLA 问题。

本文描述来自云计算用例组的 “云计算用例白皮书” 版本 4.0 —— 由开放 web 社区的 1,400 多位参与者(在版本 3.0 时为 900)所创建的信息仓库。它最初是由一组开放云宣言的支持者所创建,后来参与者增长到包括大小公司的代表、政府机构、咨询机构、以及供应商。

“云计算用例白皮书” 的范围非常全面,因此,我们没必要一次读完整个文档。在本回顾中,我们重点关注组织对云中服务级别管理问题的评价,这点很重要,因为 SLAs 描述了云提供者和云客户之间的关系,从本质上定义了,可信云服务客户的基础是具有云服务提供者交付基础设施服务的能力。

谁使得这一切成为可能?

为 “云计算用例白皮书” 版本 4.0 做出贡献的人们是 Dustin Amrhein、Patrick Anderson、Andrew de Andrade、Joe Armstrong、Ezhil Arasan B、James Bartlett、Richard Bruklis、Ken Cameron、Reuven Cohen、Tim M. Crawford、Vikas Deolaliker、Andrew Easton、Rodrigo Flores、Gaston Fourcade、Thomas Freund、Valery Herrington、Babak Hosseinzadeh、Steve Hughes、William Jay Huie、Nguyen Quang Hung、Pam Isom、Sam Johnston、Ravi Kulkarni、Anil Kunjunny、Thomas Lukasik、Bob Marcus、Gary Mazzaferro、Craig McClanahan、Meredith Medley、Walt Melo、Andres Monroy-Hernandez、Dirk Nicol、Lisa Noon、Santosh Padhy、Greg Pfister、Thomas Plunkett、Ling Qian、Balu Ramachandran、Jason Reed、German Retana、Bhaskar Prasad Rimal、Dave Russell、Matt F. Rutkowski、Clark Sanford、Krishna Sankar、Alfonso Olias Sanz、Mark B. Sigler、Wil Sinclair、Erik Sliman、Patrick Stingley、Robert Syputa、Doug Tidwell、Kris Walker、Kurt Williams、John M Willis、Yutaka Sasaki、Michael Vesace、Eric Windisch、Pavan Yara、以及 Fred Zappert。

什么是 SLA?

作者同意 SLA 应当包含:

  • 提供者所提供服务的列表,以及每个服务的完整描述。
  • 确定提供者正提供其所承诺服务的度量标准,以及用于监控服务的审计机制。
  • 供应者与消费者各自的职责,以及如果未达到 SLA 条款时,针对各方的补救措施。
  • 有关 SLA 随时间变化的描述。

作者讨论了两类 SLAs —— off-the-shelf 协议和定制,协商协议。注明了具有关键数据需求的客户不适合采用 off-the-shelf 协议,因此,迁移到云之前的第一步是确定您的数据及应用有多重要。

公共云经常提供非协商 SLA ,这是关键任务应用或数据无法接受的。

什么是 SLO?

SLA 包含服务级别目标(SLOs),其客观定义了服务的可测量条件;一些例子包括有关吞吐量的参数以及数据流的频率和时间,VMs 以及其他资源和实例的可用百分比,或者用于 SLOs 重要性分级的紧迫性评价(比如 “可用性比响应时间更重要”)。

SLO 期望应当依据应用及应用所访问的数据是否位于相同的云而不同。

监测与测量

服务级别管理,基于 SLOs,是如何搜集和处理云的性能信息。其使用方式为:

  • 云提供者利用服务级别管理来进行基础设施方面的决策;例如,如果吞吐量无法持续满足客户需求,提供者可以重新分配带宽或者增加更多硬件。或者决定通过牺牲其他客户来取悦这一客户。对于提供者,SLM 设计用于基于业务目标和先进技术,来辅助最优决策。
  • 云客户利用 SLM 来决定如何使用云服务;比如是否在该价位增加更多虚拟机,因为价格太高而不划算。有时候还涉及如何自动化这些决策。

关于 SLA 条款,应考虑哪些要素?

作者提出在定义 SLA 条款时需要考虑的 10 个要素:

  1. 业务级别目标:组织在准确定义需要哪些服务之前必须先确定为何 要采用云服务。这一点不是技术问题,而是组织策略问题:一些组织将会削减经费或者放松对基础设施的控制。
  2. 双方的职责:平衡提供者与客户的职责很重要。例如,提供者将对 Software-as-a-Service 方面负责,但是,客户主要对其采用授权软件及处理敏感数据的 VM 负责。
  3. 业务连续性/灾难恢复:客户要确保提供者维持着足够的灾难恢复能力。有两个相关的例子:在云中存储有价值数据用于备份和云爆破 (当 in-house 数据中心无法处理进程负载时,进行切换)。
  4. 冗余:考虑提供者如何实现系统冗余。
  5. 维护:采用云的最大好处之一是,由提供者进行维护。但是,客户应当知道,提供者何时处理维护任务:
    • 在这期间服务是否可用?
    • 是否服务可用,但是提供较低吞吐量?
    • 客户是否有机会针对升级的服务进行应用测试?
  6. 数据位置:依照规则,不同类型的数据只能存储到特定的物理位置。提供者可通过一个保证来响应这些需求,该保证是,客户的数据将只存储在特定位置,并具有对该情况的审计能力。
  7. 数据索取:如果法律要求提供者的设备要能够捕获属于特定客户的数据和应用,该获取可能影响采用同一提供者的客户。考虑通过第三方来提供附加备份。
  8. 提供者失败:考虑提供者的财务状况,制定应变计划。
  9. 区域:再次强调,理解管理供应商以及管理客户的本地法律。
  10. 代理商和经销商:如果供应者是云服务的代理商或经销商,需要理解提供者的策略和实际提供者。

SLA 要求

作者提出在考虑 SLA 时,需要关注的 14 个职责:

  1. 安全:客户必须了解其安全需求,以及需要什么控制与联合模式来满足这些要求。提供者必须了解,他们需要向客户交付哪些内容,来确保相应的控制与联合模式。
  2. 数据加密:数据在活动以及闲置时必须进行加密。必须指定加密算法的细节以及访问控制策略。
  3. 隐私:基本隐私问题包括数据加密、保持、以及删除。SLA 要说清云提供者如何在多企业架构环境中隔离数据和应用。
  4. 数据保持、删除:提供者如何遵守保持规则和删除策略?
  5. 硬件擦除、销毁:与 #4. 同。
  6. 政府监管:如果由于数据类型的原因,必须执行法规,云提供者必须能够证明其对法规的遵守。
  7. 透明度:对于关键数据和应用,当违反了 SLA 条款时,提供者必须主动通知客户。这包括类似停电和性能问题之类的基础架构问题,以及安全事件。
  8. 证明:提供者应当负责所需的证明并保持其当前状态。
  9. 性能定义:运行时间 意味着什么?每个洲上的所有服务器是否可用?或者只有一个可用?有必要确定这些定义。(本文章的作者建议标准化性能术语,来方便使用。)
  10. 监测:对于潜在违反问题,您可能希望指定中立的第三方组织来检测供应者的表现。
  11. 可审计性:由于消费者负责任何导致数据或可用性缺失的违背,重要的是,消费者能够审计提供者的系统和程序。SLA 应当明确如何以及何时进行审计。这将给提供者带来破坏性和成本。
  12. 度量标准:这些是在事中可监测,事后可审计的有形事务。SLA 的度量标准必须进行客观而毫不含糊的定义。接下来是一列公共度量标准。
  13. 提供机器可读的 SLA:这允许自动、动态选择云代理商。换句话说,SLA 可能需要代理商为一些任务采用最廉价的可用提供者,而为另一些选择最安全的提供者,这一类自动化是可能的。(然而此类服务并不真实可用,而是在讨论云 SLA 标准化时要牢记在心的。)
  14. 人机交互:按需自服务是云计算的基本特性之一,但是 SLA 应当考虑在需要人员时,就有可用的人。

一些公共的性能度量标准(关注 #12)包括

  • 吞吐量:系统响应速度。
  • 可靠性:系统可用性。
  • 负载均衡:有关弹性问题。
  • 耐久性:数据丢失的可能性如何。
  • 伸缩性:资源能增长多少。
  • 线性:系统性能随着负载的增加而增长。
  • 敏捷性:提供者响应负载变化的速度。
  • 自动化:不需人工干预的请求处理百分比。
  • 客户服务响应时间。

关于可靠性的一些规则

作者提供了简洁的论文,来描述云性能可靠性的可行定义。包括:

  • 多个 9 规则。是提供者所交付的关于可靠性的度量规则的多个 9(例如,如果服务的可用时间为 99.99999%,五个 9,那么整个系统每 12 个月的中断时间为 5 分钟)。问题在于,什么是中断?(如果提供者能决定什么是中断,那情况就很糟糕了。)
  • 云的层。很多云产品构建于其他云产品之上 —— 这有助于灵活性和能力,但是每个附加提供者都会降低系统的可靠性。(比如,如果每个产品都能达到五个 9,那么系统整体性能将会少于五个 9)
  • 应用与其数据之间的距离。同样,随着提供者数量的增加,其他影响可靠性的因素将会发挥作用。不仅任何系统宕机都会发生影响,而且系统间的网络失败也会产生影响。

这些都不是为了吓唬云使用者;这些只是在选择提供者时所要考虑的结构性事实。

需求与交付模式,用例

最初的文章中,作者提供了两个表格:

  • 表格 8.7:SLA 需求与云交付模式。此表交叉引用我们讨论的 SLA(数据加密、隐私、证明等等)与交付模式 PaaS、IaaS、以及 SaaS(在最初的文章中讨论过)。
  • 表格 8.8:SLA 需求与用例场景。此表交叉引用 SLA 需求及 7 个用例场景:
    1. 最终用户到云。
    2. 企业到云到最终用户。
    3. 企业到云。
    4. 企业到云到企业。
    5. 私有(on-premise)云。
    6. 改变云供应商。
    7. 混合云。

结束语

“云计算用例白皮书” 版本 4.0 中所得出的有关云服务级别管理的结论很清楚:

  • 如果缺少服务管理、治理、计量、监测、联合身份、SLAs 与基准、数据和应用联合、部署、以及生命周期管理,云计算将不可行。
  • 云提供者提供的有意义的透明度和信息披露很有必要。
  • 如果现有标准能够用于完成某个请求,则云用户必须要求提供者采用该标准;如果没有相关标准,要采用社区开发的相关标准。

作者声明:

当组织采用云服务时,客户与提供者各自的职责必须在服务级别协议中定义清楚。SLA 定义客户如何使用服务以及提供者如何交付服务。关键在于,云服务客户能够完全理解提供者 SLA 的所有条款,而且,在签署任何协议之前,客户要考虑其组织的需求。

此回顾与总结提供了基线,来阐述云服务客户和提供者所关注和考虑的、有关云服务级别协议的问题。我们建议您完整地学习初始的 “云计算用例白皮书” 版本 4.0,来了解云计算用例讨论组所分析的问题,即开发者和规划人员应当为其重要的数据和应用,要求云提供者提供可靠的环境。

参考资料

学习

获得产品和技术

  • 借助可直接从 developerWorks 下载的 IBM 试用软件,来构建您的下一个开发项目。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing, Open source
ArticleID=550050
ArticleTitle=云服务级别协议回顾与总结
publish-date=10112010