面向云架构的SLA体系概述

1、 Page * MERGEFORMAT 12面向云架构的SLA体系概述目 录 TOC o 1-3 h z u HYPERLINK l _Toc44450564 一、前言 PAGEREF _Toc44450564 h 3 HYPERLINK l _Toc44450565 二、企业级应用的SLA对云服务的挑战 PAGEREF _Toc44450565 h 4 HYPERLINK l _Toc44450566 1.可靠性和可用性 PAGEREF _Toc44450566 h 4 HYPERLINK l _Toc44450567 2.性能 PAGEREF _Toc44450567 h 5 HYPERL

2、INK l _Toc44450568 3.安全性 PAGEREF _Toc44450568 h 6 HYPERLINK l _Toc44450569 三、企业级应用对云服务的适应性 PAGEREF _Toc44450569 h 7 HYPERLINK l _Toc44450570 1.静态集成VS动态分布 PAGEREF _Toc44450570 h 8 HYPERLINK l _Toc44450571 四、云服务上企业级应用的 SLA PAGEREF _Toc44450571 h 9 HYPERLINK l _Toc44450572 1.软件定义的SLA PAGEREF _Toc444505

3、72 h 9 HYPERLINK l _Toc44450573 2.可能的实现 PAGEREF _Toc44450573 h 10 HYPERLINK l _Toc44450574 3.成本优化 PAGEREF _Toc44450574 h 10 HYPERLINK l _Toc44450575 4.软件定义SLA的限制 PAGEREF _Toc44450575 h 11 HYPERLINK l _Toc44450576 五、与云服务的同步成长 PAGEREF _Toc44450576 h 12前言云服务重塑了企业级应用的架构，公共云成为了集成企业应用、平台软件和服务的一个设计中心。API驱动

4、的资源按需分配，与传统的企业数据中心基础设施有着很大的不同。企业应用需要适应云服务的架构设计，同时又向云服务添加了企业属性和服务的等级。过去，企业级应用的主要体系结构是专用数据中心中构建的系统，其设计目的是为企业应用程序提供有保证的服务级别。这与公共云多租户体系结构是完全不同的，本质原因是应用程序和服务作为分布式系统构建在虚拟化的资源之上。而对于一些IT部门而言，云服务只是为了避免公司财务审核的麻烦。尽管许多大型公司已经成功地使用云服务交付了弹性而高效的应用，但是让企业应用使用公共云仍然并非易事。灵活性和自动化可以简化 IT 操作，云服务需要成为一个高性能的企业级平台，需要能够支持财务分析、

5、ERP系统和供应链管理等业务级应用。企业级应用的SLA对云服务的挑战企业级应用需要额外属性的业务环境，比如高可用性、安全性、可靠性或者性能，这些属性对新旧应用都是适用的。例如， 由于监管或业务原因，数据安全性可能很重要。数据完整性的漏洞，可能导致错误的业务决策或财务结果，使公司损失真金白银，甚至可能导致市场价值的损失。SLA是企业服务的需求，通常采用提供者和消费者之间的契约，并对不遵守的行为进行处罚。具体和可测量的 SLO是用于测试 SLA 是否满足的单个度量标准。在这里，云服务是指部署应用和服务的平台，许多IaaS和 PaaS提供商都提供了云服务。云服务通常包括按需分配的自助服务、广域网访问

6、、资源池、快速弹性等等。云服务交付的服务级别与企业期望的服务级别存在着普遍的差距。很多云服务的SLA一般在99.95% 99.99%之间，而且不保证性能。可靠性和可用性企业级应用 SLA 的可用性可能是技术上的挑战。例如，关键业务可能不能容忍每年超过5分钟的停机时间，这需要99.999% 的可用性。相比之下，云服务中的资源经济性可能有相对较高的预期故障率。例如，AWS的EBS服务大约每年的故障率为0.1%-0.5% ，这意味着可能每年高达1/200的故障率。关键业务对数据不一致和数据损坏的容忍度通常较低。许多企业应用可能要被重新实现，使用“最终一致性”的架构来优化性能和可用性。当业务风险或惩罚

7、足够高时，一些企业应用更喜欢停机或数据丢失，而不是提供错误的结果。如果可用性足够严格，它会给软件施压，使其实现快速恢复。云服务鼓励将“为失败而设计”作为正常操作来实现高可用性。这就需要容错软件来补偿那些不可靠的基础设施，就像 RAID补偿不可靠的物理介质一样。可靠性和可用性已经成为了软件的问题。或许，这是一个构建健壮软件的机会。性能企业应用的性能需求各不相同。面向最终用户的应用可能被管理为特定的响应时间。重要的业务，如 ERP 和财务分析，可以同时管理响应时间和面向吞吐量的 SLO，以支持特定的业务目标，例如隔夜交易策略的优化。在云服务中，许多性能挑战都是多租户的副产品。实际上，物理资源成为了

8、排队系统: 多租户的云设施超订可能导致性能的巨大变化。无论存储的性能，还是网络的带宽，都可能存在着“吵闹的街坊”。计算的超订也会对IO延迟产生负面影响，性能和成本之间存在着权衡。多租户公提高了物理基础设施的利用率，优化了云服务的成本，但无法以尽可能低的固定成本来保证共享物理资源的性能。超订物理资源的性能可以随机波动，而静态物理资源的性能可以得到保证，但是成本更高。如果要保证性能，灵活地使用虚拟资源是云服务中的一个需求，必须对分布式系统进行积极管理才能实现性能目标。安全性安全需求随企业应用的类别而定，应用或数据的业务价值越高，安全需求就越严格。除了避免DDOS，以及“数据泄露” ，还要实施多层次

9、的安全控制，因为没有一个单独的系统是完全安全的。从企业安全的角度来看，云服务是一个有趣的环境。一方面，多租户被认为是一种新的令人担忧的环境。另一方面，跨负载实施的逻辑安全控制和自动化策略管理提供了一个增加安全性的机会。逻辑控件比物理控件更加灵活、可审计和可执行。网络访问的控制规则是逻辑控制的一个典型例子，可以直接应用于虚拟机，可以动态地提供逻辑分区，可以缩小适应工作负载中的准确资源，并在工作负载移动时移动逻辑分区。云服务需要新的安全工具和技术，并重新思考传统的安全技术，可能需要以编程的方式表示安全性的 SLO。用户、应用和以数据为中心的探索，是应对实现更高级别安全SLA的挑战。企业级应用对云服

10、务的适应性企业级的数据中心通常针对预定的用例集进行优化。专用系统通过预集成组件实现具体的服务水平，具有固定的价格成本和性能，包括硬件设备、备份系统，以及私有云等。供应商垂直集成硬件和软件组件以提供服务级属性(例如，I/O速率、物理资源配置、故障隔离等)。通过将供应商的部署与性能和可靠度的最佳实践相结合，可以满足更高等级的 SLA。专用系统需要高带宽的节点间通信，并提供了非常高的性能级别。企业可能会为特定的用例支付额外费用。静态集成VS动态分布当然，专用系统和公共云之间的硬件差距正在缩小。云服务已经创造了适合大规模部署和运营的硬件设计，这种趋势可能会持续下去，因为合理规模的虚拟机资源具有实际的好

11、处，例如，简单的可扩展性问题、节点间数据移动的成本降低，或者价格/性能/功耗效率等等。此外，一些云服务厂商还提供了具有一定服务级别的专用系统。云服务是动态的和分布式的，专用系统是静态的和集成的。虚拟化资源针对自动化、成本和规模进行了优化，还拥有平台和硬件抽象层。抽象是提供更高级别SLA的一个挑战，由于不知道哪些虚拟资源位于相同的性能和故障域中，因此很难保证服务级别。企业的基础设施有机会进行转换。在实现高可用性分布式系统这一具有挑战性的工作中，应用程序将能够抵御组件故障，并且对高可用性基础设施的需求将随着时间的推移而减少。SLA 可以在云服务上的软件中交付，为企业应用提供企业属性和服务级别。云服

12、务上企业级应用的 SLA相对于企业的需求，云服务中的按需资源实际上是无限的。虽然很少公开披露，但据保守估计，单个公有云的服务器数量达到了数十万，而且还在快速增长。这已经比一个拥有数万台服务器的大企业数据中心大了一两个数量级。与大型网站上的数百万最终用户相比，50000最终用户对于企业业务、批处理或分析应用来说都是一个不小的数字。云服务从根本上改变了当今企业应用和基础设施的体系结构，资源不再是固定的， 甚至有额外的CPU和 RAM 供应给企业应用。资源只受预算的限制。虽然 云服务提供了有限的SLA，但通常需要应用和平台软件围绕着应用的特性(如性能、弹性、可用性和成本)来提供保证。由于与多租户相关

13、，需要通过设计来容忍任意的失败，并实现自己的 SLA。Software defined everything(软件定义一切）。软件定义的SLA软件定义的SLA可能是个潜在的解决方案，提供了一种新的设计模式，将 SLA和 SLO形式化为云服务软件组件中的可配置参数。然后，这些组件管理基础资源，以满足特定的SLO 需求。使用按需分配的资源，可以通过系统层来满足某些 SLO，而这些 SLO 以前需要进行规划、静态分区和超额供给。最后，云服务的API将软件定义的SLA合并为运行时配置。软件定义的SLA可以为基本服务级别指定度量，如响应时间、I/O吞吐量和可用性，还可以指定抽象但可衡量的属性，如地理分布

14、或负载约束。软件定义的SLA应该是独立于供应商和技术，在逻辑单元中指定，并且是客观可测量的。可能的实现软件定义的SLA需要在云服务中实现，用于运行时可配置的 SLOs扩展，用于高可用性和容错，以及用于按需分配计算能力和 I/O资源。鉴于分布式系统开发的挑战，不太可能对软件定义的SLA采用一刀切， 可以在应用服务、平台组件中实现各种编程式的 SLO。特定应用的上下文确定了哪些组件适合给定的用例，由于云服务和企业应用都是动态目标，可能会迭代云服务提供的属性与企业应用提供的属性，以及介于两者之间的软件组件和服务。运行时重新配置非常具有挑战性。QoS技术是必要的，但还不够，动态提供 RAM、 CPU

15、和存储资源以满足不断变化环境条件下的 SLO是必需的。然而，软件定义SLA的价值会证明重大的工程努力和成本是合理的。在考虑性能和数据可用性时，必须考虑计算能力和数据存储的配置，这些可以减轻与多租户网络相关的一些性能问题。一般来说，可以使用标签来确定资源，特别是实现安全性的SLO。基于主机的虚拟网络和 OpenFlow 提供了更多的机会来标记网络流中的用户和组。安全性的 SLO可以通过将用户和组标记与访问控制关联来实现。类似地，存储服务元数据中的数据集标记有助于实现数据相关的 SLO(例如，数据可用性、复制、访问控制和加密密钥管理策略)。成本优化即使使用私有云技术，过度供应仍然是保证服务级别的标

16、准方法。专用系统的整个成本必须预先支付，包括SLA和随时间推移不断增加的超量供应开销。公共云服务中的资源可以根据需要分配和释放，因此可以根据实际使用情况计费。就可变工作负载的运行效率而言，这是公共云服务超越专用系统的一个机会。由于实现不同的 SLO可能需要可变资源，因此软件定义的SLA与成本函数相关联。面对不断变化的基本条件(例如，不可预测的多租户资源) ，成本是一个随机变量，即使所有其他 SLO 都是固定的。软件定义SLA的限制软件定义的SLA在理论和实践上都可能有着局限性。由于成本始终是需要管理的系统级参数，因此有些组合可能不起作用。即使给定无限的成本，有些 SLO也可能在物理上无法实现。

17、此外，设计糟糕的云服务可能不适合软件定义的SLA。在动态资源管理领域， 物理属性可以分解为单独的可消费单元。例如，计算资源可以独立于 I/O、 I/O 吞吐量独立于容量，CPU 和 RAM 独立于彼此。这削弱了专用系统的纵向一体化优势。公共云服务引入了根本的经济转变价格/性能指标需要考虑到工作负载和运行时间。由于公共云服务具有随需应变的特性，价格是随时间分配资源的函数，以工作负载运行后的小时或天计算，而不是标准的企业硬件生命周期。还有更多机会通过自动化测试基础设施和分析来验证软件定义的SLA，这为第三方验证SLA和适当评估惩罚提供了可能。与云服务的同步成长对于公共云服务来说，处理大量的企业计算用例将是一次有益的旅程。与过去一样，企业应用模型的转换可以逐步进行，从非关键的应用程序开始，并随着生态系统的成熟而向上构建。公共云创新的步伐是无情的，大量的能源