You are on page 1of 58

第 4 版新增内容 -SLA 服务等级协议简介

云计算用例白皮书
云计算用例研讨组

版本 4.0

2010 年 7 月 2 日
致 谢 : Miha Ahronovitz 、 Dustin Amrhein 、 Patrick Anderson 、 Andrew de Andrade 、 Joe
Armstrong 、 Ezhil Arasan B 、 James Bartlett 、 Richard Bruklis 、 Ken Cameron 、 Mark
Carlson 、 Reuven Cohen 、 Tim M. Crawford 、 Vikas Deolaliker 、 Pete Downing 、 Andrew
Easton 、 Rodrigo Flores 、 Gaston Fourcade 、 Thomas Freund 、 Tom Hanan 、 Valery
Herrington、Babak Hosseinzadeh、Steve Hughes、William Jay Huie、Nguyen Quang Hung、
Pam Isom、Shobha Rani J、Sam Johnston、Ravi Kulkarni、Anil Kunjunny、Edmond Lau、
Thomas Lukasik、Bob Marcus、Gary Mazzaferro、Craig McClanahan、Meredith Medley、
Walt Melo、Andres Monroy-Hernandez、Ayman Nassar、Dirk Nicol、Lisa Noon、Santosh
Padhy 、 Gilad Parann-Nissany 、 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、Phillip Straton、Robert Syputa、Robert J. Taylor、
Doug Tidwell 、 Kris Walker 、 Kurt Williams 、 John M Willis 、 Yutaka Sasaki 、 Michael
Vesace、Eric Windisch、Pavan Yara 和 Fred Zappert。

欢 迎 并 鼓 励 通 过 以 下 站 点 所 涉 及 的 讨 论 小 组 留 下 有 关 本 文 档 的 公 众 意 见 : http://
cloudusecases.org。

本作品基于 Creative Commons Attribution Share Alike 3.0 Unported License


获得许可。
云计算用例白皮书 版本 4.0

目录
1 简介......................................................................................................................................................4
2 定义及分类..........................................................................................................................................5
2.1 云计算概念的定义.......................................................................................................................5
2.2 分类...............................................................................................................................................8
2.3 标准和分类间的关系.................................................................................................................10
2.4 应用程序编程接口 (API)........................................................................................................12
3 用例场景............................................................................................................................................14
3.1 最终用户到云.............................................................................................................................16
3.2 企业到云到最终用户.................................................................................................................17
3.3 企业到云.....................................................................................................................................18
3.4 企业到云到企业.........................................................................................................................20
3.5 私有云.........................................................................................................................................21
3.6 更改云供应商.............................................................................................................................22
3.7 混合云.........................................................................................................................................24
3.8 交叉引用:需求和用例.............................................................................................................26
4 客户场景............................................................................................................................................28
4.1 客户场景:薪资的云处理.........................................................................................................28
4.2 客户场景:云物流和项目管理.................................................................................................29
4.3 客户场景:云中央政府服务.....................................................................................................31
4.4 客户场景:混合云中的地方政府服务.....................................................................................32
4.5 客户场景:天文数据处理.........................................................................................................32
5 开发人员需求....................................................................................................................................35
6 安全场景............................................................................................................................................37
6.1 法规.............................................................................................................................................37
6.2 安全控制.....................................................................................................................................38
6.3 安全联合模式.............................................................................................................................39
7 安全用例场景....................................................................................................................................41
7.1 云计算能力.................................................................................................................................41
7.2 基于云的开发与测试.................................................................................................................42
7.3 云存储.........................................................................................................................................43
7.4 交叉引用:安全控制和客户场景.............................................................................................45
7.5 交叉引用:安全联合模式和客户场景.....................................................................................45
8 服务等级协议 (SLA).........................................................................................................................46
8.1 什么是 SLA?............................................................................................................................46
8.2 服务等级目标.............................................................................................................................47
8.3 服务等级管理.............................................................................................................................47
8.4 SLA 的考虑因素........................................................................................................................48
8.5 SLA 需求....................................................................................................................................49
8.6 可靠性说明.................................................................................................................................52
8.7 交叉引用:服务等级协议 (SLA) 要求和云交付模型.............................................................52
8.8 交叉引用:SLA 要求和用例.....................................................................................................53
9 结论和建议........................................................................................................................................55
内容变更...............................................................................................................................................57

2010 年 7 月 2 日 2
云计算用例白皮书 版本 4.0

关于版本 4:在版本 4 中的新增内容是第 8 节服务等级协议 (SLA)。请参阅第 57 页的内


内容
变更
变更,了解详细信息。

2010 年 7 月 2 日 3
云计算用例白皮书 版本 4.0

1 简介

云计算用例研讨组汇集了云计算的用户和供应商,共同定义云计算中常见的使用场景。这
些场景尽可能建立在最广泛的用户需求之上,展示了云计算的性能和经济价值。

该白皮书旨在强调云计算环境中需要进行标准化的功能和要求,以确保其互操作性、易集
成性和便携性。在不使用封闭专利技术的情况下,必须能够实施本白皮书中的所有用例。
云计算必须逐步演变为开放式环境,最大程度的减少供应商锁定,扩大用户的选择空间。
用例将:

 提供实用的、基于用户使用经验的材料,便于读者针对互操作性和各种标准进行讨
论。

 明确哪些地方应使用现有标准。

 引发业界对开放式云计算重要性的关注。

 明确应对哪些地方进行标准化。假如某特定用例当前不能实现,或者只能通过专
有 API 和产品实现,业界就需要定义明确的标准,使之得以实现。

用例明确指出共同的任务,也概括了可能遇到的挑战,这是对任何的标准努力最有力的支
持。

《开放云计算宣言》(opencloudmanifesto.org) 阐释了维护云计算开放性的重要原则。在宣
言公布后的两个月内,已有 250 家企业作为支持者签署了该宣言。本研讨组的所有活动均
依照《开放云计算宣言》的六大原则进行:

 云计算提供者必须通力合作,确保通过公开合作和适度采用标准,解决采用云计算
的过程中可能遇到的挑战。

 云计算提供者应尽可能采用现有标准。IT 行业已在现有标准和标准组织中投入很
大,没有必要进行重复投入或重新改造。

 如果需要新的标准(或调整现有标准),我们必须谨慎、务实,避免定制过多的标
准。必须确保标准能够促进创新,而不是阻碍创新。

 围绕开放云计算的任何社区计划都应该由用户需求来主导,而不只是取决于云计算
提供者的技术需求,且应该根据实际的用户需求进行检测或验证。

 云计算标准组织、倡议团体与社区应该通力合作、保持协调一致,确保各项计划不
会互相冲突或重叠。

 云计算提供者不得利用自己的市场地位,将用户锁定于自己的特定平台,也不得限
制用户对云计算提供者的选择。

本白皮书将贯彻我们的长远计划,最终使这些原则得以实现。

2010 年 7 月 2 日 4
云计算用例白皮书 版本 4.0

2 定义及分类

本白皮书收录的下列定义和分类概述了云计算的概念。但本文的重点不是介绍云计算本
身,而是基于实际的应用和需求定义云计算场景和用例。不论这些场景在分类中的定义和
位置如何,我们都希望能为您提供清晰、有趣和实用的用例场景。

2.1 云计算概念的定义

云计算
云计算:云计算是一种能使用户便捷、随需应变地对共享的可配置计算资源共享池(如网
络、服务器、存储器1、应用程序和服务)进行网络访问的模型。该模型可在最少的管理
投入或服务供应商介入的情况下快速实现资源的提供与发布。(本定义来自于美国国家标
准和技术研究所颁布的最新版《NIST 云计算工作定义》试行稿 1。)

2.1.1 交付模型

云计算的 NIST 定义定义了以下三种交付模型:

 软件即服务 (SaaS):用户可以使用某应用程序,但不能控制运行该程序的操作系
统、硬件或网络基础设施。

 平台即服务 (PaaS):用户将托管环境用于其应用程序。用户能控制环境中运行的应
用程序(也可能对托管环境具有一定控制权),但不能控制运行应用程序的操作系
统、硬件或网络基础设施。平台通常是一个应用程序框架。

 基础架构即服务 (IaaS):
:用户可以使用“基本的计算资源”,如处理能力、存储
器、网络部件或中间件。用户能控制操作系统、储存器及部署的应用程序,也有可
能控制网络部件(如防火墙和负载均衡器),但不能管理或控制底层的云计算基础
设施。

2.1.2 部署
部署模模型
NIST 定义了以下四种部署模型:

 公有云
有云::简单来说,公有云服务指的是用户通过互联网从第三方供应商获取的云计
算服务。“公有”并不意味着这一服务无需付费,只是说服务可能免费或使用成本
比较低。公有云也不意味着用户的资料会公诸于众,因为服务供应商通常会为用户
设置一个访问控制机制。公有云提供了一种灵活、经济有效的部署解决方案。

1
在以下网址的“NIST 云计算”页面可找到完整文档:http://csrc.nist.gov/groups/SNS/cloud-computing/。文档声明:“
本材料虽属 NIST 但为公版著作。可自由复制和翻译。”本白皮书中所讨论的基本特征、交付模型和部署模型均基于09 年
8 月 9 日的本文档第 15 版。

2010 年 7 月 2 日 5
云计算用例白皮书 版本 4.0

 私有云
有云::私有云具备公有云计算环境的许多优点,如灵活性强、以服务为基础等。
两者的区别在于,基于私有云的服务中,在企业内部进行数据和流程管理时,可以
不受网络带宽、安全风险和法规要求等的限制,而使用公有云服务则受以上限制。
除此之外,鉴于私有云所使用的用户访问和网络都被严格控制和标识,因此,私有
云能为供应商和用户提供更好的云基础架构控制,同时提高了安全性和恢复能力。2

 社 区 云 : 社区云由一群共享利益(如特定安全需求或共同目标)的企业管理和使
用。社区的成员共享云中的数据和应用程序。

 混合云
合云::混合云是公有云和私有云的融合,且两者可互操作。在此模型下,用户通
常将非业务关键型信息和流程转移至公有云处理,而将业务关键型服务和数据留在
自己的掌控下。。3

2.1.3 基本特征
NIST 定义描述了云计算的五个基本特征:

 快速伸缩
快速伸缩:伸缩性是指根据需要向上或向下扩展资源的能力。对用户来说,云计算
的资源数量没有界限,他们可按照需求购买任何数量的资源。这是 NIST 定义中有
关云计算的一个主要特征。

 服务可度量:
服务可度量:在可度量服务下,由云计算供应商控制和监测云计算服务的各方面使
用情况。这对于计费、访问控制、资源优化、容量规划和其他任务具有重要的意
义。

 按需自助服务:
按需自助服务:云计算的按需服务和自助服务意味着用户可以在需要时直接使用云
计算服务,而不必与服务供应商进行人工交互。

 无所不在的网络访问
无所不在的网络访问:这意味着供应商的资源可以通过互联网获取,并可以通过瘦
客户端或富客户端以标准机制访问。4

 资源池:
资源池:资源池允许云计算供应商通过多用户共享模式服务于用户。物理和虚拟资
源可根据用户需求进行分配和重新分配。资源池具有地点独立性,客户一般无法控
制或了解所提供资源的确切位置,但可以在高端提取层面(如地区、国家或数据中
心)指定位置。5

2.1.4 其他术语
互操作性:
互操作性:互操作性讨论的是不同系统间的通信能力。接收系统必须能够识别通讯信息。
在云计算的世界里,这代表与多个云计算供应商合作时编写代码的能力(不考虑供应商间
的差异)。6

2
私有云可由第三方掌控,也可以不架构在企业内部。私有云不一定由使用该服务的企业管理或掌控。
3
混合云技术属社区云的范畴,因此,两种部署模式的需求将在本文第三节中的混合云部分中共同讨论。
4
这不一定仅指互联网访问。理论上来讲,只有越过防火墙才能访问私有云。不管所使用的网络类型如何,云计算服务的
访问不限于特定类型的客户。
5
大部分情况下,隐私法和其他法规要求云计算供应商的资源设在特定的地点。供应商和用户必须共同合作遵守这些则。
6
关于互操作性、便携性和易集成性的定义,请参见 http://www.testingstandards.co.uk/interop_et_al.htm。

2010 年 7 月 2 日 6
云计算用例白皮书 版本 4.0

便携性:
便携性:便携性指在某环境下运行另一环境中的组件和系统的能力。在云计算领域,这包
括软件和硬件环境(即物理环境和虚拟环境)。

整合性:
整合性:整合是把不同的组件和系统融合到一个整体系统的过程。基于云计算的组件和系
统的整合将受到多用户共享、云联合和政府法规等因素的影响。

服务 等级
服务等级 协议 (SLA):
等级协议 :服务等级协议是服务供应商与客户间的合同,它明确了用户的要求
以及网络服务供应商提供的具体服务。通常,服务等级协议包括服务正常运行时间、客户
隐私、安全性和备份过程等项目。

云联合:
云联合:云联合是在不同系统上将数据和用户身份相结合的操作。云联合可以由服务供应
商或云代理实现。

代理:
代理:代理没有自己的云资源,但能依据客户所需的服务等级协议在用户与服务商之间配
对。用户不了解代理不掌控资源的事实。

多用户共享:
多用户共享:多用户共享是指来自不同企业的多个系统、应用程序或数据托管在同一个物
理硬件的特性。这在大多数基于云计算的系统中非常普遍。

云爆发:
云爆发:云爆发是混合云根据需要向私有云提供多余资源的技术。私有云有足够的处理能
力应对工作负载时无需混合云。如果私有云的处理能力无法满足工作负载需要,混合云可
以自动将多余的资源分配给私有云。

策略 : 策略是操作过程的统称。例如,安全策略可能指定对某特定云服务的所有请求加
密。

监管:
监管:监管指确保所有策略均加以执行的控制和过程。

虚拟机 (VM):
:一个文件(通常称为映像),在执行时,对用户而言等同于真机。云基础
架构即服务可以作为虚拟机映像提供给用户,并能按照用户需求随时启动或停止。在虚拟
机运行时对其所作的更改能够储存在磁盘上并永久保留。

应用编 程接
用编程接
程接口口 (API):
:应用编程接口是指导开发人员如何编写代码以与某些系统进行交互
的合同。API 描述了系统所支持操作的语法。对于每一个操作,API 指定了应输入系统的
信息、系统应该输出的信息以及可能发生的错误情况。

 API 可以通过具体的编程语言定义或通过诸如 WSDL 或 IDL 的中性格式定义。


REST 规范通常没有机器可读语言,但也定义了 API。

 API 还可包含协议(如 HTTP 协议)和数据格式(例如 JSON 或 XML Schema)的


细节。

2010 年 7 月 2 日 7
云计算用例白皮书 版本 4.0

 API 需要人类智能来理解数据和操作符的意义。机器能够识别出完成方法 X 需要
两个整数作为参数,但只有开发人员(人类)才能辨别使用哪两个整数。

2.2 分类
下图定义了云计算的分类:

在该图表中,服务用户使用云计算提供的服务,服务供应商管理云基础架构,服务开发人
员自己创建服务。(注意以上角色的交互需要开放式标准。)每种角色都将在下文详细讨
论。

2.2.1 服务用户
服务用户指的是真正使用服务的终端用户或企业,不管所使用的服务是云计算
软件、平台还是基础架构。

根据服务的类型和用途,用户需要接触不同的用户界面和程序接口。某些用户
界面与其他应用程序类似,用户在使用时不需要了解云计算;另外一些用户界
面则提供了管理功能,如启动或停止虚拟机,或是管理云存储等。根据所编写
的应用程序不同,用户编写应用程序代码所使用的程序接口也不同。

用户还需要签署服务等级协议和合同。这些通常在用户和服务供应
商的协商下通过人工干预的方式完成。用户对产品的期望和供应商
的声誉是协商的关键部分。

2010 年 7 月 2 日 8
云计算用例白皮书 版本 4.0

2.2.2 服务供应商

服务供应商向用户提供服务。根据服务类型不同,供应商的任务也有所区别:

 对于云计算软件即服务,供应商安装、管理和维护软件。供应商并不一定拥有运行
软件的物理基础架构,但用户只能使用应用程序,无法接触到该基础架构。

 对于云计算平台即服务,供应商管理平台的云基础架构,通常是某特定类型程序的
框架。用户的应用程序不能访问平台下的架构。

 对于云基础架构即服务,供应商维护存储器、数据库、消息队列或其他中间件,或
者是虚拟机的托管环境。用户可以把服务作为磁盘驱动器、数据库、消息队列或机
器使用,但不能访问托管服务的架构。

在服务供应商图表中,堆栈最底层是固件和硬件,它们构成其他所有组件的基础。往上是
软件核,也就是操作系统或在云计算下托管基础架构的虚拟机管理员。虚拟资源和映像包
含了基本的云计算服务,诸如处理能力、存储器和中间件。虚拟机管理员控制的虚拟映像
包括映像本身和管理映像所需的元数据。

对服务供应商操作具有决定作用的是管理层。从低层次来说,管理层通过计量确定服务的
使用对象和使用程度,通过自动配置确定分配给用户的资源,通过监测跟踪系统的状态和
资源使用情况。

2010 年 7 月 2 日 9
云计算用例白皮书 版本 4.0

从较高层次上来说,管理层通过计费收回服务成本,通过容量规划满足客户的需求,通过
服务等级协议管理确保供应商和用户达成的服务条款已全部履行,并向管理人员进行汇
报。

服务供应商的所有操作都涉及安全性。(安全需求的不同等级超出本书讨论范围。)开放
式标准同样适用于这些操作。一套全面的标准能够简化供应商的操作,并与其他供应商实
现互操作。

2.2.3 服务开发人员
服务开发人员创建、发布和监管云计算服务。这些通常是直接通过
SaaS 模型交付给终端用户的“业务”应用程序。在 IaaS 和 PaaS 层次
编写的应用程序以后也能供 SaaS 开发人员和云计算供应商使用。

创建服务的开发环境多种多样。如果开发人员创建的是 SaaS 程序,


他们很可能为供应商托管的环境编写代码。在这种情况下,发布服务
就是将其部署到供应商的架构中。

在服务创建阶段,服务尚未发布给用户之前,分析包括进行远程调试
以测试服务。服务发布之后,分析允许开发人员监测服务性能,并在
必要时进行更改。

2.3 标准和分类间的关系

标准可通过四种方式对云计算用例场景产生影响。这四种方式分别是在每种类型的云计算
服务内、跨不同类型的云计算服务、在企业和云计算之间以及在企业的私有云内。

2010 年 7 月 2 日 10
云计算用例白皮书 版本 4.0

2.3.1 跨云计算服务类型的标准
随着云计算日渐普遍,应用程序很可能会使用不同种类的云计算服务。应用程序可能会利
用云存储服务、云消息队列并管理(启动/停止/监测)云中运行的虚拟机等。明确不同服
务间的协作标准具有重要的意义。

2.3.2 云计算服务类型内部标准
在每一类云计算服务内(IaaS、 PaaS 或 SaaS),开放式标准都能够避免供应商对用户的
锁定。

对于云基础架构即服务,用于处理云数据库的 API 标准集允许应用程序处理来自多个供应


商的数据。常用 API 能使用户无需做出重大改变即可自由迁移到其他云数据库供应商,也
能便于将新数据资源与现有应用程序的整合。针对其他云计算架构服务(如存储、消息队
列和 MapReduce)的常用 API 具备数据与数据交换通用格式相似的作用。对于虚拟机来
说,常用虚拟机格式意义重大。用户获取虚拟机将其部署在云计算供应商处之后,还能在
不进行任何更改的情况下将其部署给另一个云计算供应商。

对于云计算平台即服务,云计算中提供的大部分平台都是应用程序框架。框架通常提供了
常用的服务,如用户界面、存储和数据库等,但这些服务只能通过该框架的API 获得。

对于云计算软件即服务,开放式标准适用于应用程序层。这种类型的标准很少特定于云,
因此它们超出本文的讨论范围。例如,某基于云计算的文字处理程序应支持文档便携性标
准,而文字处理程序中的标准要求与程序是否在云中运行无关。

2010 年 7 月 2 日 11
云计算用例白皮书 版本 4.0

2.3.3 云计算与企业程序间的标准
尽管云计算逐渐兴起,企业架构诸如 Java EE 等并没有淘汰。定义企业程序如何与云数据
库或云消息队列等资源进行通讯的标准可使现有程序在无需重大更改的情况下利用云计算
服务。解决云计算与现有架构和开发范式之间的整合将成为这部分的主要挑战。

2.3.4 企业内部标准
企业内部标准的决定因素是互操作性、数据审计、安全性和管理等方面的需求,同时企业
内部标准还将构建适用于企业和云计算的标准。企业将与集合了私有云、公有云和混合云
的部署模式进行交互。

2.4 应用程序编程接口 (API)


构建云计算解决方案的主要机制是云计算供应商提供的 API。云计算 API 在四个不同的层
次上发挥作用,可分为五个基本类型。

2.4.1 API 层次

API 有四种不同的层次。每个层次都需要开发人员将重点放在不同的任务和数据结构上。

层 次 1 - 线 路 : 在本层次上,开发人员直接写入请求的有线格式。如果该服务基于
REST,则开发人员创建相应的 HTTP 标头,创建请求负载并打开一个到服务的 HTTP 连
接。REST 服务返回数据,同时返回 HTTP 响应代码。由于许多 REST 服务的直接性,在
这个层次编写代码相对比较有效。

如果该服务基于 SOAP,则开发人员创建 SOAP 封套,添加相应的 SOAP 标头,用数据载


荷填充 SOAP 封套主体。SOAP 服务通过包含请求结果的 SOAP 封套实现响应。使用
SOAP 服务需要解析封套的 XML 内容;出于这个原因,大多数 SOAP 服务通过更高层次
的 API 实现调用。

层次 2 - 特定语言工具
工具包包:本层次上的开发人员使用一个特定语言工具包来处理 SOAP 或
REST 请求。虽然开发人员仍将重点放在穿越线路的数据格式和结构上,但很多细节(例
如处理响应代码和计算签名)由工具包进行处理。

层次 3 – 特定 服务
特定服务 工具包
服务工具包
工具包::开发人员使用一个更高级别的工具包处理特定的服务。在这个
层次上工作时,开发人员能够专注于业务对象和业务流程。开发人员专注于对组织至关重
要的数据和程序时可以提高生产力,而不用将精力放在线路协议上。

层次 4 - 中立服务工具
工具包包:这是 API 的最高层次。在这一层次工作的开发人员使用连接多
个云计算供应商的通用接口。与层次 3 相同的是,开发人员仍将重点放在业务对象和业务
流程上。不同的是,在层次 4 工作的开发人员不必担心他们正在使用哪个云服务。使用中
立服务工具包编写的应用程序应该能够使用不同的云计算供应商(请参阅第 22 页的更改
云供应商),且尽可能减少对代码的改动。

2010 年 7 月 2 日 12
云计算用例白皮书 版本 4.0

2.4.2 API 分类

编程接口可分为五类:

分类 1 - 普通编程:
普通编程:C#、PHP、Java 等中通用的应用程序编程接口。此分类中没有特定的
云计算。

分类 2 - 部署:
部署:将应用程序部署到云计算的编程接口。除特定于云的包装技术外,此分类
中包括 .NET 程序集和 EAR/WAR 文件在内的传统包装机制。

分类 3 - 云服务:
云服务:与云服务协同工作的编程接口。正如上一节讨论,云服务 API 可以是特
定服务或中立服务。这些 API 分为云存储服务、云数据库、云消息队列和其他云服务等分
类别。使用云服务 API 编写代码的开发人员知道他们正在使用云。

分类 4 – 映像和基础架构管理:
映像和基础架构管理:管理虚拟机映像和基础架构细节的编程接口。映像的 API
支持上传、部署、启动、停止、重新启动和删除映像。基础架构管理 API 控制如防火墙、
节点管理、网络管理和负载平衡等细节。

分类 5 - 内部接口:云基础架构不同部分之间内部接口的编程接口。如果要改变云架构内
存储层的供应商,那么将用到这些 API。

2.4.3 开发人员角色

在讨论对开发人员的要求时,明确开发人员的角色十分重要。对 API 和云服务的要求会因


角色的不用而不同。下面是我们将要在本文档中讨论的角色,同时给出他们使用的API 的
类别:

客户端应用程序开发人员:
客户端应用程序开发人员:为最终用户编写基于云的客户端应用程序。这些开发人员使用
云服务的(分类 3)API。

应用程序开发人员:编写使用云的传统应用程序。这些开发人员使用普通 API(分类 1)
应用程序开发人员:
以及云服务的 API(分类 3)。

部署人员:
部署人员:包装、部署和维护使用云的应用程序。生命周期管理也是属于此处要考虑的问
题之一。这些开发人员使用 API 实现部署、云服务和映像管理(分类 2、3 和 4)。

管理员:
管理员:在多个层次处理应用程序,包括部署和基础架构管理。这些开发人员利用分类
2、3 和 4 中的 API。

云供应商:处理云产品下的基础架构。这些开发人员使用分类 5 中的 API。
云供应商:

2010 年 7 月 2 日 13
云计算用例白皮书 版本 4.0

3 用例场景

企业云使用场景旨在描述最为典型的云用例,而并非要列出云环境下的所有现实情况。

本节中的图形自始至终都有若干共同元素。如果某给定的元素不适用于某一特定用例,则
该元素变灰或以虚线绘制。例如,私有云用例不涉及最终用户或公有云,因此只有企业云
是彩色的。

应用程序在云上运行,由最终用
最终用户到云
户访问

企 业到 云到最 应用程序在公有云上运行,由员
终用户 工和客户访问

企业到云 云应用程序与内部 IT 功能集成

2010 年 7 月 2 日 14
云计算用例白皮书 版本 4.0

云应用程序在公有云上运行,与
企业到 云到企
业到云到企
合作伙伴的应用程序交互操作

(供应链)

私有云 由组织在其防火墙内托管的云

一个使用云服务的组织决定转换
更改云供应商
云供应商或使用其他供应商

多个云协同工作,由负责联合数
混合云 据、应用程序、用户身份、安全
和其他细节的云代理进行协调

2010 年 7 月 2 日 15
云计算用例白皮书 版本 4.0

3.1 最终用户到云

在该场景下,最终用户访问云中的数据或应用程序。这种类型的常见应用包括电子邮件托
管和社交网站。Gmail、Facebook 或 LinkedIn 用户可通过任何设备上的任何浏览器访问应
用程序和数据。用户不希望记住密码以外的任何信息;其数据的存储和管理都在云中进
行。

最重要的是,用户无需了解底层的基础架构是如何发挥作用的。只要可以访问互联网,他
们就可以得到期望数据。

3.1.1 要求

 身份:
身份:云服务必须验证最终用户。

 开放的客户端:
开放的客户端:对云服务的访问不应限制特定平台或技术。

 安全:
全:安全(包括隐私)是对所有用例的一个常见要求,尽管要求的细节会因用例
的不同而发生很大变化。对云计算中安全性的完整讨论不属于在本文范围。

 服务等级协议 (SLA):
:虽然最终用户的服务等级协议通常比企业的服务等级协议简
单得多,但云供应商必须清楚他们提供什么样的服务保证。

2010 年 7 月 2 日 16
云计算用例白皮书 版本 4.0

3.2 企业到云到最终用户

在这种情况下,企业利用云向最终用户提供数据和服务。最终用户与企业交互时,企业访
问云以检索数据和/或对其进行操作,并将结果发送到最终用户。最终用户可以是企业内
部人员或外部客户。

3.2.1 要求

 身份:
身份:云服务必须验证最终用户。

 开放的客户端:
开放的客户端:对云服务的访问不应限定于特定的平台或技术。

 联合身 份:
合身份:
份:除最终用户所需的基本身份外,企业用户很可能要有企业身份。理想状
态是企业用户管理单一身份标识,同时基础架构联合云服务可能需要的其他身份。

 位置感 知:
置感知:
知:根据企业代表用户管理的数据类型,对存储数据的物理服务器位置可能
存在法律限制。虽然这违背了用户不必知道物理基础架构细节这一云计算的理想状
态,但这一规定是必要的。云供应商提供 API 用于确定实现云服务的物理硬件的位
置之前,许多应用程序无法迁移到云中。

 计量和监测:
计量和监测:所有的云服务必须接受成本控制、退款和自动配置的计量和监测。

2010 年 7 月 2 日 17
云计算用例白皮书 版本 4.0

 管理和控制:
管理和控制:公有云供应商使账户的开通和启用更加便捷;这种易用性将带来风
险,因为企业中的个人将主动使用云服务。需要对虚拟机和诸如存储、数据库和消
息队列等云服务进行管理,以跟踪所使用的服务。

要确保无论何地使用云计算都遵守政策和政府法规,控制是关键。其他管理要求将
因行业和地域而异。

 安 全 : 任何涉及企业的用例都比涉及单一最终用户的用例具有更为复杂的安全要
求。同样,较先进的企业用例会有更高级别的安全要求。

 虚拟 机常
虚拟机常 见文件
机常见文件 格式
见文件格式
格式::为一个云供应商平台创建的虚拟机应该可以移植到另一个供
应商平台。针对这一需求的任何解决方案必须考虑云计算供应商向虚拟机分配存储
的方式上的差异。

 云存储和中间件的通用 API:
:企业用例需要通用 API 来访问云存储服务、云数据
库,以及其他云中间件服务,如消息队列。

编写仅供特定供应商的云服务使用的定制代码,将企业锁定在该供应商的系统之
中,失去了云计算提供的部分经济效益和灵活性。

 数据 和应
数据和应 用程序
和应用程序 联合
用程序联合
联合::企业应用程序需要结合多个基于云来源的数据,且它们需要
协调在不同的云内运行的应用程序活动。
 服务 等级
服务等级 协议和
等级协议和 基准
协议和基准
基准::除最终用户所需基本服务等级协议以外,以服务等级协议为
基础签订合同的企业需要一个衡量性能的标准方法。该方式必须能明确定义云供应
商将提供什么服务,并衡量实际交付的内容。(服务等级协议会对云安全产生附加
影响;详见第 6 节有关服务等级协议、审计和监测的讨论。)
 生命周 期管
命周期管
期管理理:企业必须能够管理应用程序和文档的生命周期。这项要求包括应用
程序的版本控制以及数据的保留和销毁。发现此类数据是许多组织面临的一个主要
问题。如果某些数据不再可用,则会导致重大的法律责任。除了数据保留外,在某
些情况下企业希望确保数据在某种程度上遭到破坏。

3.3 企业到云

这一用例涉及企业就其内部流程使用云服务。由于赋予了企业最大控制权,这可能是在云
计算早期阶段最常见的用例。

2010 年 7 月 2 日 18
云计算用例白皮书 版本 4.0

在这种情况下,企业使用云服务补充其所需要资源:

 使用云存储进行备份或存储很少用到的数据
 使用云中的虚拟机,增加在线处理器处理峰值负载(不再需要的时候关闭虚拟机)
 使用云中的应用程序 (SaaS),实现某些企业功能(电子邮件、日历、客户关系管理
等)
 将云数据库用作某一应用程序处理过程的一部分。与合作伙伴、政府机构等共享该
数据库时,这可能非常有用

3.3.1 要求

企业到云用例的基本要求与云到企业到云到最终用户的用例大致相同。开放的客户端、联 开放的客户端、联
合 身 份 、 位 置 感知 、 计 量 和 监 测 、 管 理 和 控 制 、 安全 、 虚 拟 机 通 用 格 式 、 云 存 储 和 中间
件通用 API、数据和应用程序联合、服务等级协议以及生命周期管理均适用
、数据和应用程序联合、服务等级协议以及生命周期管理均适用 。
该用例的其他要求是:

 部署:
署:创建虚拟机映像,必要时将其部署到云,应当比较简单。虚拟机映像一旦建
立,应该可以将其从一个云供应商转移到另一个云供应商,补偿厂商用以分配虚拟
机存储的不同机制。将应用程序部署到云也同样比较简单。

 特定行业标准 和协议:企业之间的许多云计算解决方案使用现有标准,如
RosettaNet 或 OAGIS。适用的标准将因应用程序和行业而异。

2010 年 7 月 2 日 19
云计算用例白皮书 版本 4.0

3.4 企业到云到企业

这个用例涉及使用相同的云的两个企业。此处重点是在云中托管资源,方便企业应用程序
交互操作。供应链是该用例中一个最明显的示例。

3.4.1 要求

企业到云到企业用例的基本要求与企业到云的用例大致相同。身份身份 开放的客户端、联合
身份、开放的客户端、联合
身份、位置感知、计量和监测、管理和控制、安全、特 特定行业标准、云云存 储 和 中 间 件 通
用 API、数据和应用程序联合、服务等级协议以及生命周期管理
、数据和应用程序联合、服务等级协议以及生命周期管理 均适用。

2010 年 7 月 2 日 20
云计算用例白皮书 版本 4.0

该用例的其他要求是:

 事务和 并发
务和并发
并发::对于不同企业间共享的应用程序和数据,事务和并发至关重要。如果
两个企业都使用相同的云托管应用程序、虚拟机、中间件或储存,任何一方企业所
做的更改都必须可靠,这一点很重要。

 互操作性:
互操作性:因为涉及到多个企业,所以企业之间的互操作性至关重要。

3.5 私有云

私有云用例与其他用例的不同之处在于,云包含于企业内部。这对大型企业而言非常有
用。例如,如果薪工管理部门在每月 15 日和 30 日的工作量激增,尽管该月其他时间他们
的日常工作量相当低,但仍需要足够的计算能力来处理峰值工作量。有了私有云,计算能
力可以分布于整个企业。薪工管理部门需要时,可获得额外的使用周期,如果其他部门需
要,也同样可以获得额外的使用周期。这样可以为整个企业节省大量资金。

3.5.1 要求

私有云用例的基本要求是开
开放的客户端、计计量和 监测、管
管理和控制、安
安全、部
部署、互
互操
作性 常用虚拟机格式
作性、常用虚拟机格式 服务等级协议
常用虚拟机格式和服务等级协议
服务等级协议。

2010 年 7 月 2 日 21
云计算用例白皮书 版本 4.0

请注意,私有云不需要身份、联合身份、位置感知、事务、行业标准、云中间件的通用
API 和生命周期管理。在许多情况下,用户须使用私有云,这样位置感知将不再是一个问
题。将云保留在企业内部可消除对身份管理、标准和通用 API 的许多要求。

3.6 更改云供应商

这用例涉及到与不同云供应商的协作,增加一个额外供应商或替换现有的供应商。该用例
适用于本文讨论的所有其他用例。开放和标准化的一个主要优点就是能够与其他供应商协
作而无需进行重大改变。

这里有四种不同的场景,每一种的要求略有不同。一般情况下,更改云供应商需要开放的 开放的
客 户 端 、 位 置 感知 、 安 全 、 服 务 等 级 协 议 、 虚 拟 机常 用 文 件 格 式 以 及 云 存 储 和 中 间 件通
用 API。下面的各节将讨论这些要求的细节。

2010 年 7 月 2 日 22
云计算用例白皮书 版本 4.0

3.6.1 场景一:更改 SaaS 供应商

在这种情况下,云客户更改 SaaS 供应商。两家 SaaS 供应商都提供相同的应用程序(客户


关系管理、会计、文字处理等)。使用其中一个供应商软件创建的文档和数据应该可以导
入至第二个供应商的软件。在某些情况下,客户可能需要交替使用这两家供应商。

3.6.1.1 要求

 特定行业标准
特定行业标准:将文档和数据从一个供应商的应用程序迁移至另一个供应商需要双
方应用程序支持通用格式。所涉及格式将取决于应用程序的类型。

在某些情况下,还需要不同应用程序类型的标准 API。值得注意的是,这些要求均
未涉及特定云。将一个文档从 Zoho 转移到 Google Docs 所依照的标准与将一个文件
从 Microsoft Office 转移到 OpenOffice 的标准相同。

3.6.2 场景二:更改中间件供应商

在这种情况下,云客户更改云中间件供应商。现有数据、查询、消息队列和应用程序必须
可从一个供应商导出,然后导入至另一个供应商。7

3.6.2.1 要求

 特定行业标准:
特定行业标准:将文档和数据从一个供应商的中间件迁移到另一个供应商中间件,
需要双方应用程序均支持通用格式。所涉及的格式将取决于应用程序的类型。

 云中间件的通用 API:
:包括现今的云服务支持的所有操作,包括云数据库、云消息
队列和其他中间件。API 用于连接、创建和删除数据库和表格。

云数据库供应商实施一定的限制,从而使其产品更有灵活性,并对查询大型数据集
占用大量资源进行处理加以限制。例如,某些云数据库不允许跨表联接,某些则不
支持真实的数据库模式。这些限制成为在供应商之间移动云数据库的主要挑战,对
构建于真实关系模型上的应用程序尤其如此。

其他中间件服务,如消息队列,则较为相似,因此在它们之间寻找共同点应该更加
简单。

3.6.3 场景三:更改云存储供应商

7
虽然云存储和云中间件都归类为 PaaS,但由于云存储的普及性,云中间件(数据库、消息队列及映射归并)和云存储被

2010 年 7 月 2 日 23
云计算用例白皮书 版本 4.0

在这种情况下,云客户更改云存储供应商。

3.6.3.1 要求

 云存储 通用 API:
存储通用 :在一个云存储系统读取或写入数据的代码,应以尽可能少的改动
实现与不同系统协同工作;这些改动应局限于配置代码。例如,在 JDBC 应用程序
中,不同的数据库供应商采用不同的 URL 格式和驱动程序,但与数据库交互的代
码是一样的。

3.6.4 场景四:更改虚拟机主机

在这种情况下,云客户希望获取内置于某云供应商系统的虚拟机,然后将其运行于另一个
云供应商的系统。

3.6.4.1 要求

 虚拟机通用格式
虚拟机通用格式:虚拟机格式应兼容任何操作系统。

此处假设虚拟机本身运行于某个操作系统,如 Windows 或 Linux。这意味着虚拟机


用户在针对云建立虚拟机之前已经选择了一个平台,因此对于运行在虚拟机内部的软
件特定于云的要求。

3.7 混合云

这一用例涉及包括公有云和私有云在内的多个云协同工作。联合云供应商将自身资源和其
他供应商资源相结合,实现混合云服务。代理也可以提供混合云服务;不同的是代理没有
自己的云资源。混合云供应商必须基于用户条件来管理云资源。

2010 年 7 月 2 日 24
云计算用例白皮书 版本 4.0

值得注意的是,对于混合云用户而言,该用例与前面讨论的最终用户到云的用例没有区
别。用户不知道混合云供应商实际所做的工作。

3.7.1 要求

 之前用例的所有要求(事务 事务 和并
事务和并
和并发发除外)在此处全部适用,尤其是安全
安全 、数
安全、数 据和应
、数据和应
用程序联合 互操作性
用程序联合以及互操作性
互操作性。
 服务等 级协
务等级协
级协议议(SLA)
):表述服务等级协议的机读标准格式。这允许混合云供应商
按照用户条件选择资源,不受人为干预。

正如在第 2 节所述,对社区云的要求是对混合云的要求的一个子集。社区云基础架构在企
业之间共享,有共同的目标。下面是一个社区云图解:

2010 年 7 月 2 日 25
云计算用例白皮书 版本 4.0

请注意,社区和社区云之间的通信通在内部网进行。可以是一个 VPN,但不通过公共互
联网访问。

3.8 交叉引用:需求和用例

下表总结了需求和用例之间的关系:

企业到云
最终用户 企业到 企业到
企业到云云到 私有 更改云 混合
到最终用
到云 云 企业 云 供应商 云

要求
身份    
开放客户端       
联合身份    
位置感知     
计量和监测     
管理和控制     
安全       
部署   
事务和并发 
互操作性  
特定行业标
  

虚拟机映像
     
格式
云存储 API     
云数据库     

2010 年 7 月 2 日 26
云计算用例白皮书 版本 4.0

API
云中间件
    
API
数据和应用
   
程序联合
服务等级协
      

生命周期管
   

2010 年 7 月 2 日 27
云计算用例白皮书 版本 4.0

4 客户场景

本节描述了用例的客户体验。下面是这些客户场景的摘要:

客户场景 所解决 的客
所解决的客 户问题
的客户问题 要求与功能 适用
适用用用例

薪资的云处  处理时间缩短 IaaS ( 虚 拟 企业到云


理  硬件需求降低 机)、云存储
 实现灵活性,便于将来扩

云物流和项目  缩短处理时间 PaaS ( 应 用 程 序 企业到云到最


管理  消除手动任务 框架)、云存储 终用户
 更新并简化了开发环境

中央政府  整合 IT 专业知识 IaaS、PaaS 私有云


 减少硬件需求

地方政府  整合 IT 专业知识 IaaS、PaaS 混合云


 减少硬件需求

天文数据处  硬件费用大大降低(处理 IaaS ( 虚 拟 企业到云到最


理 能力和存储) 机)、云存储 终用户
 能源成本大大降低
 简化了管理

4.1 客户场景:薪资的云处理

4.1.1 第 3 节中的适 用用
中的适用用 例场景
用用例场景
例场景::

企业到云

4.1.2 客户场景:

在这种情况下,薪资处理是一个复杂而费时的过程,由两台专用服务器处理。组织决定了
解在云中运行薪资处理的实际效果。现行的薪资系统按照分布式应用程序进行架构,所以
将其迁移到云中相对简单。

薪资应用程序使用 SQL 数据库处理雇员数据。使用云数据库服务时,部署带数据库服务

2010 年 7 月 2 日 28
云计算用例白皮书 版本 4.0

器的虚拟机,而不是重写应用程序。数据库服务器从云存储系统检索数据,并从中构造关
联表格。由于原(组织内部)数据库体积庞大,请使用提取工具仅选择对薪资处理必要的
信息。提取的信息被转移到云存储服务,供数据库服务器使用。

薪资应用程序部署到四个同时运行的虚拟机;这四个虚拟机与托管数据库服务器的虚拟机
协同工作。对薪资应用程序配置进行了更改,以使用托管数据库服务器的虚拟主机;否则
不对应用程序进行更改。

4.1.3 所解决的客户问题:

在以云为基础的应用程序版本中,处理薪资任务的时间减少了 80%。还有一个优点就
是,以前两台专门用于处理薪资的服务器可以腾出来处理其他任务。最后,以云为基础的
版本更具灵活性;随着组织的扩大,这将是一个重要优势。

4.1.4 需求和功能:

所用云服务为虚拟机和云存储 (IaaS)。不必对薪资应用程序进行修改,只是将其部署到
虚拟机。最初的应用程序使用关系数据库。为了避免因使用云数据库而改变数据结构和应
用程序,将关系数据库服务器部署到云。

唯一使用的 API 为 S3 云存储 API。

4.1.5 可移植性问题:

薪资应用程序运行于 Fedora 和 Java 1.5 上,因此可以在任何支持 Fedora 的云供应商平台


上运行,无需更改。如果其他供应商不支持用于薪资处理的特定 S3 API,那么要修改应用
程序以使用不同的云存储供应商可能存在问题。最后,更改应用程序以实现云数据库的使
用可能会非常困难,当涉及迁移到不支持关系模型的云数据库时,尤其如此。

4.2 客户场景:云物流和项目管理

4.2.1 第 3 节中适用 用例
中适用用例 场景:
用例场景:

企业到云到最终用户

4.2.2 客户场景:

一家拥有约 20 名行政人员的小型建筑公司需要一种方法来管理自身资源、优化项目调度

2010 年 7 月 2 日 29
云计算用例白皮书 版本 4.0

并跟踪工程费用。该公司提出非常具体的要求,常见系统无法处理,因此他们使用了
Quickbooks 和电子表格组合。该系统不够灵活,并且造成人力资源的巨大浪费。

该问题的解决办法就是建立一个定制的客户端应用程序。所有业务逻辑都驻留在客户端。
应用程序的数据来自谷歌应用引擎 (GAE) 的数据存储。尽管该数据存储本身不托管 RDF-
OWL 本体,但除 RDF 图外,它并不强制执行任何其他模式。客户端使用该本体对数据进
行验证,然后为用户显示数据或将数据发送回 GAE。

数据存储通过 HTTP 使用特定于应用程序的 RESTful 协议,实现与数据操作的通信。数据


存储维护在服务器管理的孤立库中提供的应用程序所特有的 RDF 图。根据使用特定数据
孤立库的应用程序要求,安全措施分别落实到每个库。使用这个系统时,任何数量的应用
程序都可以使用数据存储,无需为每个应用程序建立新的代码库。

通过使用一次性数据迁移脚本,数据从本地托管的 SQL Quickbooks 服务器和定制电子表


格迁移到 GAE。该脚本在数据上传之前对其进行调整。这样,数据集体积较小,便于利
用本地资源进行处理。

客户端应用程序维护一个包含数据最新更改的子集的本地数据存储。该应用程序的 REST
架构允许 HTTP 内置缓存支持将更改从主数据存储自动传递到到客户端。这种设计既使用
了数据子集,又简化了安全性。如果客户端应用程序并不需要访问某些领域或记录,那部
分的数据存储不会离开服务器。

4.2.3 所解决的客户问题:

数据从低效的软件系统和电子表格宏系统迁移到基于云的系统。由此产生的数据存储可以
用于诸多应用程序,使未来的开发和维护更加简单。

尽管最初的应用基础架构仍在使用之中,但是,建立在这一基础架构上的应用程序不再依
赖电子表格来分析和处理数据。由于不需要维护电子表格,可以大大节省费用。此外,处
理过程不再需要手工剪切和粘贴数据,从而省去了一项繁琐任务,消除了错误来源。

4.2.4 需求和功能:

云服务使用谷歌应用引擎,一种提供数据库支持的 PaaS 实施。RESTful API 和云数据存储


组合使得该应用程序较围绕传统关系数据库构建的应用程序更具灵活性。

4.2.5 可移植性问题:

该应用程序运行于谷歌应用引擎及其 BigTable 数据库上。BigTable 是稀疏、分散、持续、

2010 年 7 月 2 日 30
云计算用例白皮书 版本 4.0

多维的有序映射,通过将非规范化置于规范化之前优先考虑,从而实现灵活性。这是与大
多数数据存储的显著差异,需要从根本上重新考虑应用程序开发。移植应用程序使之运行
于更为传统的数据存储上,需要对应用程序架构进行重大改变。

4.3 客户场景:云中央政府服务

4.3.1 第 3 节中的适 用用
中的适用用 例场景
用用例场景
例场景::

私有云

4.3.2 客户场景:

日本政府各部委在其基础架构上设置有数千台服务器。中央政府已宣布使用私有“霞关”
云环境,为托管政府应用程序提供安全、集中的基础架构。

薪资、会计和人事管理等现有的后台办公系统将在私有云中实现虚拟和托管。一些前端办
公系统,如电子采购,将通过公有云实现虚拟化,但这不属于本项目范围。本项目的最终
目标是通过消除冗余系统,在无需增设各部委管理员的情况下,减少总体拥有成本。

4.3.3 所解决的客户问题:

霞关云方案解决了三个问题,即节省成本、降低能耗以及减少 IT 人员。

4.3.4 需求和功能:

云基础架构将以日本电信公司构建的专用网络为基础构建。由于隐私和安全是主要问题,
因此私有云是必需的。将某些个人资料存储在日本以外的服务器上是非法的。

4.3.5 可移植性问题:

由于政府正在建设自己的私有云来托管其应用程序,因此可移植性已不是问题。政府不打
算将集中应用程序和数据从私有云迁移至公有云。

2010 年 7 月 2 日 31
云计算用例白皮书 版本 4.0

4.4 客户场景:混合云中的地方政府服务

4.4.1 第 3 节中适用 用例
中适用用例 场景:
用例场景:

混合云

4.4.2 客户场景:

日本各地有超过 1800 个地方政府,每个地方政府都有自己的服务器和 IT 人员。霞关云方


案的第二个目标是提供混合云环境。除霞关云方案外,日本中央政府决定将地方政府按辖
区分组。每个辖区将拥有一个私有云和一个到霞关混合云的连接。内部任务和一些数据将
本辖区私有云中托管,而其他数据将在本地存储。只要有可能,现有系统将在霞关云方案
中进行虚拟和托管。

4.4.3 所解决的客户问题:

混合云解决了三个问题,即节省成本、降低能耗,同时减少了 IT 人员。

4.4.4 需求和功能:

在这种情况下,隐私和安全至关重要。日本法律禁止将某些类型的数据存储在当地政府以
外的服务器上,因此不可能将应用程序和数据迁移至霞关云。由于有些处理过程将在地方
政府的基础架构上完成,混合云内部的应用程序和数据联合至关重要。

4.4.5 可移植性问题:

与之前的客户场景一样,由于政府正在构建自己的私有云,因此可移植性不是问题。政府
不打算将集中应用程序和数据从私有云迁移至公有云。

4.5 客户场景:天文数据处理

4.5.1 第 3 节中的适 用用
中的适用用 例场景
用用例场景
例场景::

最终用户到云

2010 年 7 月 2 日 32
云计算用例白皮书 版本 4.0

4.5.2 客户场景:

Gaia8 是欧洲航天局的一项任务,旨在对银河系 10 亿颗恒星开展一次调查。在 5 年时间


内,对每个目标恒星监测约 70 次,精确绘制它们的位置、距离、运动和亮度变化。预计
将发现数十万个新天体,如太阳系外行星和被称为褐矮星的失败恒星。

本次任务将收集大量必须进行分析的数据。欧空局决定制作一个以云为基础的原型系统对
数据进行分析。目的是确定利用云计算处理庞大数据集的技术和财政方面的问题。

该原型系统包含科学数据和用来发布计算工作的白板。分布式计算框架(组织内部开发)
用于工作执行和数据处理。该框架配置为运行 AGIS(天体测量全球迭代求解)。该进程
在数据上运行多次迭代,直到收敛。

处理时,每个工作节点从数据库获得工作说明,检索数据,对数据进行处理,然后向中间
服务器发送结果。中间服务器更新数据以进行下列迭代。

原型对 200 万颗恒星 5 年的数据进行评估,占实际工程必须处理的总数据量的一小部分。


该原型每 100 分钟处理 24 次迭代,相当于 40 小时连续运行一个由 20 台虚拟机组成的网
格。对于整个上亿的恒星项目而言,将用 6 年的数据对 1 亿颗主恒星进行分析,将需要
20 台虚拟机组成的集群连续运行 16200 小时。

为了评估云解决方案的灵活性,该原型通过 120 台高负荷 CPU 特大型虚拟机运行第二次


试验。每台虚拟机运行 12 个线程,有 1440 个进程并行工作。

4.5.3 所解决的客户问题:

基于云的解决方案的预计成本不到组织内部解决方案费用的一半。这一成本估算不包括内
部解决方案所需的额外用电或系统管理成本,因此实际节省会更多。数据集的存储同样将
以云为基础。

在第二次试验中,发现并解决了 SQL 查询和数据库锁争用的若干性能问题。目前的内部


系统无法检测到这些问题。该原型使组织能够在投产之前发现并解决性能和灵活性问题。

4.5.4 需求和功能:

这个原型使用虚拟机处理 AGIS 软件和数据库。该数据库为运行在虚拟机内部的传统数据

8
有关本项目的概述,请参阅 http://www.esa.int/esaSC/120377_index_0_m.html。

2010 年 7 月 2 日 33
云计算用例白皮书 版本 4.0

库,它是一个完整的关系数据库,而不是云数据库服务。对存储而言,五个基于云的存储
卷(每个 100GB)连接到数据库服务器以供存储之用。

4.5.5 可移植性问题:

所有的虚拟机都运行标准操作系统,本项目没有使用特定于云的软件。此应用程序的可移
植性问题是如何将虚拟机映像迁移到另一个供应商,而不必重建或重新配置映像。

2010 年 7 月 2 日 34
云计算用例白皮书 版本 4.0

5 开发人员需求

开发人员的需求跨越所有用例和客户场景。为了简化讨论过程,在此将所有的开发人员需
求列举如下。

 高速缓存:一个支持云资源高速缓存的编程工具包将提高云应用程序的性能。开
发人员需要一个 API 来刷新缓存,还可能需要一个 API 将具体对象或资源放入缓
存中。

 集中日志记录:无论开发人员的角色或他们编写的应用程序类型是什么,日志记
录是所有开发人员的共同需求。API 应该支持编写日志、检查条目、创建日志以及
打开和关闭日志文件。

 数据库:开发人员需要通过某种方法来访问云数据库。云数据库在设计上千差万
别(有些是模式驱动且关联,有些二者皆无),所以编写云应用程序的开发人员
将根据各个应用程序的需要,选择云数据库供应商。该数据库 API 必须支持基本
的 CRUD 操作。

 身份管理:开发人员需要通过某种方式管理身份。最简单的情况下,这需要一种
方法来验证给定用户的证书。如果一个应用程序通过多个数据源和应用程序工
作,那么开发人员需要一种方法来联合用户的身份。联合身份管理系统能生成证
书,即使服务和用户彼此互不了解,也允许特定用户访问特定的服务。身份管理
API 应该视情况缓存并删除相应证书。

 消 息 传 递 - 点 对 点 : 开发人员需要一个 API 向消息队列发布消息并使用这些消


息。API 还必须允许开发人员预览消息(查看消息内容而不使用消息)。

 消 息 传 递 – 发 布 -订
订 阅 : 开发人员需要一个 API 处理消息队列系统中的主题。该
API 应该允许开发人员对某一主题发布消息,以及从主题中检索消息。

 原始计算/作
作业处 理:开发人员需要一个 API 完成大型处理作业,例如 Hadoop 式
的数据挖掘。该 API 应该允许开发人员启动、停止、监测和暂停处理作业。

 会 话 管 理 : 管理用户会话的能力至关重要,在云环境下尤其如此。面对机器故
障,云的基础架构冗余且具灵活性,因此即使某一云节点出现故障也必须对会话
进行维护。会话 API 必须方便访问或操纵用户会话的当前状态。

 服务发现:开发人员需要某种方法来发现可用的云服务。云服务应该可以按照服
务类型搜索,同时 API 提供了适用于各服务类型的附加功能。

 服务等级协议:使用服务发现的开发人员需要某种自动化方式来确定其代码发现
的服务受何种政策约束。有了这样的 API,开发人员可以编写应用程序,用于查询
云服务并选择最符合应用程序服务等级协议的服务。

2010 年 7 月 2 日 35
云计算用例白皮书 版本 4.0

 存储:开发人员需要某种方法来访问云存储服务。该 API 必须能够提供存储和检


索数据及元数据的能力。

下表交叉引用了第 2.4.2 节中讨论的五种不同类别 API,同时附上开发人员需求。

映像与基础 内部
普通编程 部署 云服务
架构管 理
架构管理 接口

开发人员需求
高速缓存  
集中日志记录     
数据库  
身份管理    
信息传递 – 点对点 
信息传递 – 发布/订阅 
原始计算/作业处理   
服务发现    
会话管理  
服务等级协议     
存储    

2010 年 7 月 2 日 36
云计算用例白皮书 版本 4.0

6 安全场景

无论在云计算中或其他任何地方,安全都是一个至关重要的话题,内容之广泛可能超出本
文篇幅。此处主要强调架构师和开发人员在向云迁移过程中应考虑的安全问题。

需要牢记的重要一点是,云本身不会带来任何新的安全威胁或安全问题。客观地看待安全
问题,那么云计算作为整体可被认为是理想的用例,强调对一致、透明、基于标准的安全
框架的需求,而不论使用何种云部署模型。随着企业逐步向云迁移或构建云解决方案,拥
有这种一致的安全模型对于简化开发、避免供应商锁定并保留其 IT 投资至关重要。

从云角度考虑安全问题时,最显著的差异就是企业失去控制权,而不是要面对任何特定的
技术挑战。对内部应用程序而言,对访问敏感数据和应用程序的控制至关重要。对于基于
云的应用程序,访问控制同样重要,但基础架构、平台和应用程序的安全性则由云供应商
直接控制。

本章将以下列顺序讨论安全话题:

 法规:法规不是技术性问题,但必须解决。法律和法规将决定安全要求,该要求
优先于功能上的要求。

 安全控制:尽管某一特定用户可能需要所有这些安全控制,但对作出安全相关承
诺却不具备实现这些承诺的基础架构的云供应商,用户应提高警惕。

 安全联合模式:要实现这些安全控制,将需要若干联合模式。云供应商应该通过
现有的安全标准提供这些模式。

本信息为下一章讨论用户场景定下基调。

6.1 法规

使用云计算时,除了技术上的问题外,就是严峻的法规现实。(这些已经在前文提到过,
但是在安全方面仍需要更多讨论。)

出于各种原因,世界各国政府都在关注云计算的使用。许多国家或地区都有严格的隐私
法,禁止将某些数据存储在本国或本地区外的物理机器上。对违反这些法律的组织(在某
些情况下,对其管理层)通常将进行严厉处罚。任何在云中存储敏感数据的组织必须能够
证明其云供应商从不将数据存储在某个特定地理区域以外的物理服务器上。

除了政府机构,许多贸易和行业团体也制定规章制度。虽然这些规章制度不是法律所要求
的,但它们代表了最佳实践。

类似问题同样适用于在云中运行的应用程序。如果一台虚拟机在云中运行,那么在这台虚
拟机上运行的应用程序是否可以访问敏感数据?这是一个灰色地带,尽管新的法律和法规

2010 年 7 月 2 日 37
云计算用例白皮书 版本 4.0

不断出台,许多国家仍对此没有明确规定。

对这些法律法规的遵守优先于任何其他要求。一项新的法律可能需要组织花费其资源来更
改应用程序的基础架构,而不是给它添加新的功能。CIO 的办公室必须应对这些变化,并
时刻关注新出台的法律法规。

6.2 安全控制
很多控制对于充分保障系统安全十分必要。下面的章节介绍了几种用例及每种用例的安全
要求。关于用例的讨论与此处定义的控制需求相关。

安全控制 描述
必须能够管理构成云基础架构的全部硬件、网络和软件资产(物理
资产管
产管理理 或虚拟)。包括能够对任何基于物理或网络资产访问行为负责,以
符合审计和要求和合规性。
加 密 : 密 钥 和 证 任何安全系统都需要一个基础架构来使用和管理密钥和证书。这包
书管理 括采用基于标准的加密功能和服务,以支持静态和动态信息安全。
必须能够以加密格式存储数据。此外,某些用户需要单独存储其数
数据/存储安全
存储安全
据,从而与其他用户数据分开。
用户必须能够确保连接云资源的端点的安全。这包括能够通过网络
端点安
点安全全
协议和设备类型限制端点。
用户必须能够访问云中所发生事件的有关数据,特别是系统故障和
安全漏洞。对事件的访问包括能够了解过去的事件并报告最新发生
事件审 计和报
件审计和报
计和报告 告
的事件。如果云供应商不能及时报告事件,那么他们的声誉就会遭
受重大损害。
必须能够以一致、机器可读的方式定义身份、角色、权利和个人及
身份、角色、访
服务的任何其他属性,从而有效地实施访问控制,对以云为基础的
问控制 和属性
控制和属性
资源强制执行安全策略。
必须能够在交换机、路由器和数据包层面确保网络通信的安全。IP
网络安
络安全全
堆栈本身也应确保安全。
必须能够定义策略,解析并强制执行安全策略,从而以一致、机器
安全策
全策略略 可读的方式支持访问控制、资源分配和任何其他决策。定义策略的
方法应该足够强健,可以使服务等级协议和许可证自动执行。
必须有一种自动化的方式来管理和分析安全控制流程和步骤,支持
服务自 动化
务自动化 安全合规审计。这也包括报告任何违反安全策略或客户使用许可协
议的事件。
工 作 量 和 服 务 管 必须能够根据安全策略和客户使用许可协议对服务进行配置、部署
理 和检测。

2010 年 7 月 2 日 38
云计算用例白皮书 版本 4.0

以下是适用于上述控制的一些标准:
安全控制 相关
相关标 标准
加 密 : 密 钥 和 证 KMIP,OASIS 密钥管理互操作协议
书管理 (http://www.oasis-open.org/committees/kmip/)
IEEE P1619,IEEE 存储安全工作组制定
数据 存储安全
数据/存储安全
(https://siswg.net/)
安全控制 相关
相关标 标准
身 份 、 角 色 、 访 SAML, ,OASIS 安全声明标记语言
问控制和属性 (http://saml.xml.org/)
X.509 Certificates,国际电联公共密钥和属性证书框架建议的一部
身份、角色、访

问控制和属性
(http://www.itu.int/rec/T-REC-X.509)
XACML,OASIS 可扩展访问控制标记语言
安全策略
(http://www.oasis-open.org/committees/xacml/)
工 作 量 和 服 务 管 SPML,OASIS 服务提供标记语言
理 (http://www.oasis-open.org/committees/provision/)

6.3 安全联合模式

联合是多个独立资源充当单一资源的能力。云计算本身就是一种资源联合,因此众多资
产、身份、配置和云计算解决方案的其他细节必须联合起来才能实现云计算。

上一节所述要求通过以下联合模式得以实现:

 信任:双方能够通过身份验证机构定义信任关系的能力。这一身份验证机构能够
交换凭证(通常为 X.509 证书),然后使用这些证书确保消息安全,创建署名安
全令牌(通常为 SAML)。联合信任是所有其他安全联合模式的基础。

 身份管理:定义接受用户凭证(用户名和密码、证书等)的身份提供者并返回可
以识别用户的署名安全令牌的能力。信任身份提供者的服务供应商可以使用该令
牌给予用户适当的访问权限,即使在服务供应商对用户并不了解的情况下也是如
此。

 访问 管 理 :编写用于检查安全令牌以管理云资源访问的策略(通常为 XACML)
的能力。对云资源的访问可以由多个因素控制。例如,对资源的访问可限于特定
角色的用户,但只有在一定协议的基础上且仅为一天中某些时段。

 单点登录/退
退出:根据来自可信机构的凭证进行联合登录的能力。对于一个经验证
且具有特定角色用户,联合单点登录允许用户登录到一个应用程序,并访问信任
相同机构的其他应用程序。联合单点退出也是这一模式的一部分;在许多情况
下,用户退出一个应用程序时同时也退出了其他所有应用程序,这一点至关重
要。单点登录模式通过身份管理模式启用。

2010 年 7 月 2 日 39
云计算用例白皮书 版本 4.0

 审计和合规:收集分布在多个域(包括混合云)的审计和合规数据的能力。联合
审计对于确保和记录服务等级协议和法规要求的合规性非常必要。

 配置管理:为服务、应用程序和虚拟机联合配置数据的能力。该数据可以包括跨
越多个域的访问策略和许可信息。

由于现有的关于安全的最佳实践适用于云,因此供应商应使用现有的标准来提供这些联合
模式。

2010 年 7 月 2 日 40
云计算用例白皮书 版本 4.0

7 安全用例场景

本节描述了使用云计算,同时满足安全要求的客户体验。有了明确的要求和模式,我们就
可以考察现实世界的场景,阐述云安全如何发挥作用。所涉及的场景涵盖不同的应用程序
类型、部署模型、模式和角色。

7.1 云计算能力

7.1.1 客户场景:

某保险公司拥有一套索赔应用程序,用于收集保单持有人及其财产损失的相关数据。一场
飓风预计将袭击美国的墨西哥湾地区,有可能造成巨大财产损失。这将导致索赔诉求急剧
增加,反过来对企业 IT 基础设施带来巨大的负担。

该公司决定利用公有云供应商提供虚拟机来处理预期需求。公司必须在企业系统和云供应
商托管的虚拟机之间控制访问,仅允许公司授权代理人访问。此外,公司必须在公司防火
墙内安全传输应用程序云实例创建的任何数据。最后,云供应商必须确保关闭虚拟机时,
不留任何应用程序或数据的痕迹。

7.1.2 所解决的客户问题:

使用公有云使公司能够处理比平常更多的工作量。购买、维护额外的系统并对其进行供电
和冷却从而处理可能的最大工作量并不符合成本效益。公司拥有处理日常运作的内部能
力,但他们还可以根据需要自动分配更多的计算能力。

7.1.3 要求和控制

以下是本用例的要求及相关控制:
要求 控制
 身份、角色、访问控制和属性
访问仅限于特定角色的视频  资产管理
 网络安全
虚拟机关闭时,必须删除所有的应用程序
 工作负载和服务管理
或数据痕迹

7.1.4 联合模式:

信任、访问管理、配置管理

2010 年 7 月 2 日 41
云计算用例白皮书 版本 4.0

7.1.5 角色

理赔员、保险代理人、稽核员

7.2 基于云的开发与测试

7.2.1 客户场景:

一家在线零售商需要开发一种新的 Web 2.0 店面应用程序,但不希望给 IT 人员和现有资


源增加负担。该公司选择云供应商,通过托管的开发工具及源代码库提供基于云的开发环
境。同时选择另一家云供应商提供测试环境,这样新的应用程序可以与许多不同类型的机
器和大量的工作负载进行交互。

选择两家供应商来处理基于云的开发和测试意味着联合将变得至关重要。

7.2.2 所解决的客户问题:

从开发的角度来看,利用云托管开发工具无需在每个开发人员的机器上安装、配置和管理
工具。工具更新只需在云供应商的网站上安装一次,然后所有开发人员会自动转移到同一
版本的工具。

产品构建的速度会快很多,大型构建可以利用云供应商基础架构的可扩展性。此外,基于
云的构建可以从以云为基础的资料库检索最新源代码。

从测试的角度来看,随着公司从传统接口向 Web 2.0 接口转移,在服务器上形成的额外负


担是一个未知数。与静态网页相比,Web 2.0 接口与服务器的交互要多得多,因此在云中
测试新的应用程序可以让测试团队衡量新接口所带来的影响。

在云中对新应用程序进行压力测试要容易得多。如果测试团队希望查看应用程序如何执行
每秒来自 500 台不同机器的请求,那么云可以允许他们启动 500 台虚拟机并运行这些测
试。有了不同的虚拟机映像,通过许多不同类型的机器(操作系统、版本、协议等)对应
用程序进行测试就变得非常简单。如果测试团队希望在 1000 或 10000 台机器上运行相同
的测试,在云中进行这样的测试符合成本效益;而在组织内部创建基础构件来完成上述任
务则昂贵低效。

2010 年 7 月 2 日 42
云计算用例白皮书 版本 4.0

7.2.3 要求和控制

以下是本用例的要求及相关控制:
要求 控制
在一个中心位置安装并维护的开发工具  资产管理
虚拟机关闭时,必须删除所有的应用程序
 工作负载和服务管理
或数据痕迹
要求 控制
 加密
 端点安全
开发和测试云单点登录
 身份、角色、访问控制和属性
 网络安全
 资产管理
对源代码和测试计划的受控访问
 身份、角色、访问控制和属性
构建与测试必须自动启动和关闭虚拟机  服务自动化
构建与测试必须报告虚拟机使用情况和性
 事件审计和报告
能的统计信息

7.2.4 联合模式:

信任、身份管理、访问管理、单点登录、审计和合规性、配置管理

7.2.5 角色

开发人员、测试人员、管理员、稽核员

7.3 云存储

7.3.1 客户场景:

某金融投资公司向其代理人和分支机构推出新的投资产品。制作了许多视频教公司代理人
和分支机构认识新产品的收益和特征。这些视频体积庞大,需要按需即时提供,因此将其
存放在云中可以减轻公司基础设施的负担。但是,必须严格控制这些视频的访问权限。出
于竞争的原因,只有通过认证的公司代理才可以观看视频。另一个更为严格的限制就是,
按规定,要求公司在产品上市前的平静期,对包括视频在内的产品细节保密。

该公司决定利用公有云存储供应商,扩展视频的安全托管和串流。云解决方案必须通过强
制执行公司安全策略的可稽核访问控制机制,对视频进行控制。

2010 年 7 月 2 日 43
云计算用例白皮书 版本 4.0

7.3.2 所解决的客户问题:

使用公有云存储服务允许客户管理大量数据文件和带宽需求,而无需增加数据中心的物理
资源。然而,政府法规和组织要求意味着安全至关重要。不能保证合规的公有云存储供应
商,无论其提供什么样性能、价格或可扩展性功能,都不予考虑。

7.3.3 要求和控制

以下是本用例的要求及相关控制:
要求 控制
对应用程序的访问仅限于特定角色  身份、角色、访问控制和属性
 资产管理
 网络安全
 策略
存储在云中的数据必须受到保护  加密
 数据/存储安全
存储在云中的数据必须在公司防火墙内传  加密
回  数据/存储安全
 端点安全
 网络安全

7.3.4 联合模式:

信任、身份管理、访问管理、审计和合规

7.3.5 角色

视频制作人、公司代理、公司分支机构、稽查员、监管机构

2010 年 7 月 2 日 44
云计算用例白皮书 版本 4.0

7.4 交叉引用:安全控制和客户场景

下表总结了安全控制和客户场景之间的关系:
基于云
基于云的的开发
安全控制 云计算能力 与测试 云存储
资产管理   
加密:密钥和证书管理  
数据 存储安全
数据/存储安全 
端点安全  
事件审计和报告 
身 份 、 角色 、 访 问 控 制
  
和属性
网络安全  
策略 
服务自动化 
工作负载和服务管理  

7.5 交叉引用:安全联合模式和客户场景

下表总结了安全联合模式和客户场景之间的关系:

基于云 的开发
于云的开发
安全联 合模式
全联合模式 云计算 能力
云计算能力 与测试 云存储
信任   
身份管理  
访问管理   
单点登录 
审计与合规  
配置管理  

2010 年 7 月 2 日 45
云计算用例白皮书 版本 4.0

8 服务等级协议 (SLA)

云供应商和云用户之间的关系必须通过《服务等级协议》来描述。由于云用户希望云供应
商交付某些基础架构服务,因此,定义这类服务及其交付方式和使用方式至关重要。

SLA 是用户对供应商产生信任的基础。一份书写完善的 SLA 可为供应商带来良好的声


誉。

除了定义云用户与云供应商之间关系的字句之外,SLA 中还包含定义可对服务进行客观衡
量条件的服务等级目标 (SLO)。用户必须考虑 SLA 中的各项条款并针对业务目标对其
SLO 进行衡量,以选择合适的云供应商。

重要的是,云服务用户应当完全理解供应商提供的 SLA 的各项条款,并且应在签署任何


协议之前考虑机构自身的需求。

8.1 什么是 SLA?

SLA 定义云服务供应商与云服务用户之间的互动关系。SLA 包含以下事项:

♦ 供应商所提供的一套服务

♦ 对每项服务的完整且详细的定义

♦ 供应商与用户的责任

♦ 一套确定供应商是否按承诺交付服务的标准体系

♦ 一种监测服务的审核机制

♦ 在不满足 SLA 中条款的情况下,用户及供应商可采用的补救措施

♦ SLA 如何随时间发生变化

市场上有两种类型的 SLA:现成协议以及为满足用户的特殊需求由供应商和用户共同协商
制定的协议。然而,并不是任何拥有重要数据和应用程序的用户都能够使用第一种类型的
协议。因此,用户在开始制定 SLA(通常包括云)时第一个步骤就是确定其数据及应用程
序的重要程度。

多数公有云服务提供的是不可协商的 SLA。与此类供应商合作时,可针对需求未能得到满
足的用户采取以下两种补救措施:

1. 接受下月账单的赊欠(在完全支付本月账单之后),或

2. 终止使用该服务。

2010 年 7 月 2 日 46
云计算用例白皮书 版本 4.0

显然,任何任务关键型应用程序或数据都不接受拥有这些条款的 SLA。而另一方面,拥有
这些条款的 SLA 与协商制定的 SLA 下提供的云服务相比,价格是相当低廉的。

8.2 服务等级目标

SLO 以精确可度量的术语定义服务特征。此处提供一些 SLO 实例:

♦ 系统中的待定请求绝不应多于十条;

♦ 一条请求的写入时间不应超过三秒;

♦ 一条读请求的数据流应在两秒之内开始;

♦ 虚拟机中至少有五个实例在 99.99999% 的时间内可用,每位供应商的三个


数据中心中至少有一个实例可用。

显而易见,不同的服务等级目标适用于不同的用例、应用程序以及数据类型。SLO 亦可
包含一个用以指示不同 SLO 的相对重要性的紧急比率。在运供应商无法交付两个 SLO
时,用户可使用紧急比率来指示此时的可用性远比响应时间重要。

不同的角色亦可影响适用的 SLO。比如,考虑由云用户编写,云供应商托管而终端用户
访问的某应用程序。假如应用程序及其数据由同一个云供应商托管,那么该供应商可在不
离开数据中心的情况下访问数据。每当应用程序访问其数据时,该云用户都将希望响应时
间尽可能短;而另一方面,每当最终用户通过 Web 访问该应用程序时,该云用户对响应
时间的期望值又很低。

8.3 服务等级管理

如果并未对服务表现进行监测和测量,那么该服务是否符合 SLA 中的条款便无从知晓。


服务等级管理可提供与服务表现相关的信息收集及处理方法。服务测评则以 SLA 中的服
务等级目标作为基础。

云供应商利用服务等级管理来制定有关其基础架构的决策。比如,供应商可能注意到一项
特殊服务的吞吐量几乎无法满足其用户的需求。此时,供应商可通过重新分配宽带流量或
提供更多的在线物理硬件来应对这种状况。然而,假如将相对较多的资源给予某位用户将
使另一位用户 SLA 中的条款无法得到满足,那么供应商可能决定以牺牲某位用户的利益
来博取另一位用户的欢心。服务等级管理的宗旨是根据供应商的业务目标和技术现实来帮
助其作出明智的决策。

云用户利用服务等级管理来制定有关如何使用云服务的决策。比如,用户可能已注意到,
某特定虚拟机上的 CPU 负载总是在 90% 以上。作为响应,该用户可能启动另一台虚拟
机。然而,假如按照用户 SLA 中所述,首批 100 台虚拟机按某一比率定价,而更多的虚
拟机则以另一更高比率定价,那么该用户可能会决定不再创建其他虚拟机以免引发额外费
用。就供应商而言,服务等级管理将帮助用户作出(可能自动作出)关于使用云服务方式
的决策。

2010 年 7 月 2 日 47
云计算用例白皮书 版本 4.0

8.4 SLA 的考虑因素

鉴于 SLA 中所需条款是由用户自行确定的,因此有诸多因素需要考虑。

8.4.1 业务等级目标

假如机构并未对其业务等级目标作出定义,那么讨论 SLA 中的条款是毫无意义的。用户


必须根据机构目标来选择供应商和服务项目。如果不是该机构已明确其首先使用服务的原
因,那么精确定义要使用哪些服务的做法也是没有意义的。

这是云计算的一个方面。而在此方面中最棘手的问题是机构策略而非技术问题。要使某机
构中的所有部门都赞同其目标,则将导致某些团体被动接受预算削减,某些团体对其基础
架构和其他艰难选择失去控制。即使不顾及这些问题,机构在明确其业务等级目标之前也
不能充分利用云计算(或就这方面的任何技术)。

用户在决定如何使用云计算之前应当明白其使用云计算的原因。

8.4.2 供应商与用户的责任

尽管 SLA 通常会被认为用于确定供应商的责任,然而其对用户责任的确定也不应忽视。
用户责任可能包括对系统使用的限制,对可存储数据类型的约束或具备确保可在供应商系
统中使用任何软件的有效许可。供应商和用户之间责任的平衡将根据服务类型的不同而发
生变化。比如,对于云计算软件即服务,云供应商将承担绝大部分的责任。另一方面,包
含许可软件和敏感数据的虚拟机会使构建并管理该虚拟机的用户承担更多的责任。

8.4.3 业务连续性与灾难恢复

许多用户将云用于其业务连续性。而有些用户会将有价值的数据副本存储在多个云中以作
备份。当内部数据中心无法应对处理负载量时,其他用户将使用云爆发来处理该状况。当
内部系统出现故障时,云可以作为保持机构正常运行的宝贵资源使用,而此做法的前提是
云供应商自身具备完备的连续性及灾难恢复程序。此外,用户应确保其云供应商在面对灾
难时具备充分的保护措施。

8.4.4 系统冗余

许多云供应商利用大量冗余系统来提供各种服务。这些系统的设计使得即使在硬盘驱动、
网络连接或服务器无法正常运行时,用户也不会遭遇任何中断。用户在移动必须始终可用
的数据及应用程序时,应当考虑其供应商系统的冗余状况。

8.4.5 维修

供应商会自行处理其基础架构的维护问题,因而无须用户亲自进行维护。但是,用户应当
知道其供应商将在何时以及如何完成维护工作。在此维护期间,其服务是否持续可用?即
使服务仍可用,吞吐量是否会明显下降?假如该维护会对用户的应用程序造成影响,那么
用户是否有机会针对已更新服务对其应用程序进行测试?请注意,维护可能会对任何类型
的云产品均造成影响,而且,维护同时适用于硬件和软件。

2010 年 7 月 2 日 48
云计算用例白皮书 版本 4.0

8.4.6 数据定位

许多数据类型的物理定位是受限制的。比如,许多国家或地区禁止在其境外的任何机器上
存储其公民的个人信息。如果云供应商无法保证其用户数据只会存储于某个特定位置,那
么该用户便不能使用此供应商提供的服务。假如云服务供应商承诺加强数据定位的规范,
那么用户必须能够对供应商进行审核,以保证该供应商确实遵照规范提供服务。

8.4.7 数据扣押

如今,已有一些广为人知的有关执法人员扣押托管公司资产的实例出现。即使某法律是针
对与某特定用户关联的数据和应用程序而实施的,云计算的多用户共享本质可能会使其他
用户同样受到此执法的影响。尽管对 SLA 可涉及的范围已有所限制,用户也应将适用于
供应商的法律款项纳入考虑范围。此外,用户还应考虑利用第三方来为其数据和应用程序
进行备份。

8.4.8 供应商的失职

任何云供应商都存在破产或被其他公司收购的可能性。因此,用户应当考虑其供应商的财
务健康状况,并制定应急计划以防供应商倒闭。另外,当用户账户有欠债未还或存在争议
时,应弄清楚供应商所制定的有关用户数据及应用程序的使用策略。

8.4.9 管辖范围

用户应了解对其所考虑的任何云供应商适用的法律款项。比如,云供应商可能将其总部设
在保留对使用供应商服务的任何数据或应用程序进行监测的权利的国家或地区。根据用户
数据及应用程序的性质,这种做法可能无法被接受。

8.4.10 云代理和分销商

假如某云供应商实际上是另一个云供应商的代理或分销商,那么 SLA 中的条款应对在代


理人、分销商或供应商提供服务过程中与所出现的任何差错相关的任何责任或义务问题作
出明确说明。

8.5 SLA 需求

8.5.1 安全性

安全性作为一项普通需求,总会在本文章节 和 中得到详述,在本文也不例外。SLA 中与
安全相关的内容应当在充分考虑章节 中的安全控制和联合模式的情况下进行撰写。云用
户必须明白其安全要求,并弄清哪些控制和联合模式对于达到这些要求十分必要。反过
来,云供应商则必须明白必须提供哪些服务给用户才能实现适当控制和联合模式。

8.5.2 数据加密

如果用户在云中存储了十分重要的数据,那么非常有必要在数据处于运动状态或静止状态
时对其进行加密。数据加密算法及存取控制策略的详细情况应在 SLA 中有所规定。

2010 年 7 月 2 日 49
云计算用例白皮书 版本 4.0

8.5.3 隐私

基本的隐私问题在诸如数据加密、保留及删除的要求中解决。此外,SLA 应当解释清楚云
供应商将如何把多用户共享环境中的数据和应用程式隔离出来。

8.5.4 数据保留与删除

许多机构都有在某特定期间保留数据的合法要求。有些机构还要求在某特定时间段之后将
数据删除。云供应商必须能够证明其对这些策略的合规性。

8.5.5 硬件清除与破坏

数据泄漏的来源通常是由于对硬件不恰当的处理造成的。假如云供应商的硬盘驱动出现故
障,磁盘的盘片信息应在处理或回收该驱动之前彻底清零。与此相似,许多云供应商应在
用户关闭虚拟机之后对清零的记忆空间提供额外保护。

8.5.6 法规

许多类型的数据和应用程序都受制于各种法规。有些法规即是法律(美国针对病历记录
制定的责任法案),而其他法规则为行业特定规范(针对接受信用卡付款的零售商制定
的支付卡行业数据安全标准)。假如法规必须得以实施,那么云供应商必须能够证明其
合规性。

8.5.7 透明度

在某些云计算供应商的 SLA 中,用户有责任证明供应商未能履行 SLA 中的条款。某供应


商的服务可能关闭了若干小时,但是用户因不能证明其关闭时间而无法得到任何类型的赔
偿。

对于关键的数据和应用,供应商若有违背 SLA 中条款,必须主动通知用户。这包括如供


应中断、性能问题和安全事故等基础架构问题。

8.5.8 认证

适用于某些数据和应用程序类型的不同认证为数不少。例如,用户可能会要求他们的云计
算供应商通过 ISO 27001 认证。供应商将有责任证明他们认证的真实性,并且保持最新。

8.5.9 关键性能指标术语

“正常运行时间”这个术语可以有很多定义。该术语的定义通常特定于供应商架构。如果
某供应商在六个大洲都设有数据中心,服务正常运行时间指的是一个特定的数据中心还是
任何一个数据中心呢?如果唯一有效的数据中心在另一个大洲,则服务正常运行时间是不
可接受的。更糟的是,其他云计算供应商将会使用针对其自身构架的定义。这就使得对比
云计算服务变得异常困难。

一套由产业行业定义的针对不同关键性能指标的术语将会为对比提供极大方便,尤其针对
服务等级协议对比(以及整体云计算服务)。

2010 年 7 月 2 日 50
云计算用例白皮书 版本 4.0

8.5.10 监测

如果因未能遵守 SLA 条款而产生经济或法律后果,应该由谁来检测供应商的服务表现


(以及用户是否尽到应尽的责任)至关重要。尽可能广泛地定义服务正常运行时间对于供
应商受益匪浅,但是用户会倾向于将任何系统问题归咎于供应商。该问题的最佳解决办法
就是寻找中立的第三方组织来监测供应商的服务表现。这避免了以下情况下可能发生的利
益冲突:供应商自行报告中断,或者用户负责证明发生了供应中断。

8.5.11 数据审计

很多用户需求都包括遵守法律规定或者行业标准。因为用户要对任何违反行为负责,所以
用户能够审计供应商的系统和程序十分关键。SLA 清楚说明审计进行的方式和时间。由于
审计具有破坏性且价格昂贵,供应商很有可能要对其设限和收费。

8.5.12 度量标准

监测和审计需要一些有形资产,以便发生时进行监测,事后可供审计。SLA 的度量标准必
须是客观的,并且界定清楚、毫不含糊。根据所使用的应用程序和数据的本质,云计算用
户将会有众多不同的度量标准。虽然列出所有度量标准并不可能,但是最常见的一些标准
将列出如下:

♦ 吞吐量 —— 服务的响应速度

♦ 可靠性 —— 可获得服务的时间间隔

♦ 负载均衡 —— 当出现弹性时(例如,启动或者终止新的虚拟机)

♦ 耐用性 —— 数据丢失的可能性

♦ 弹性 —— 明确说明限制的情况下(例如,最大存储量或者带宽),给定资源无限增长
的能力

♦ 线性度 —— 负载增加时系统的运作情况

♦ 敏捷度 —— 随着用户资源负载的增加和减少,供应商的响应速度如何变化

♦ 自动化程度 —— 无人工干预的情况下,对供应商的请求得以处理的百分比

♦ 用户服务响应次数 —— 供应商对用户请求的响应速度。这里指的是云计算按需服务和
自助服务方面出现问题时需要的人工干预。

8.5.13 可机读 SLA

SLA 的可机读语言使得自动云计算代理能够动态地选择云计算供应商。云计算基本特征之
一就是按需自助服务;自动云计算代理可以通过按需选择云供应商将此特征扩展。代理可
以根据用户定义的业务标准来选择云计算供应商。例如,用户的策略可能指定代理应该为
某些任务选择最便宜的供应商,而对其他任务选择最安全的供应商。虽然对这一要求的实

2010 年 7 月 2 日 51
云计算用例白皮书 版本 4.0

质性市场需求将需要一些时间形成,进行 SLA 标准化的任何工作中应该牢记这一点。

8.5.14 人工干预

虽然按需自助服务是云计算的基本特征之一,但总会有些问题必须通过人工干预的方式来
解决。这种情况是比较少见的,但是在很多 SLA 中,供应商保证对用户的帮助请求做出
积极响应。典型的保证包括用户可提出帮助请求的次数,这些请求的花费,以及供应商的
响应速度。

8.6 可靠性说明

谈及可靠性时,一个较常出现的度量标准就是供应商提供的服务有几个“9”。例如,五个
“9”的可靠性意思是在 99.99999% 的时间里都能够提供服务,也就是说整个系统大约每
12 个月中有 5 分钟的停机时间。该度量标准的问题在于,如果没有对停机进行清晰的界
定,这一标准很快就会失去意义。(更严重的情况是,由云计算供应商来决定哪种情况算
是停机。)

除了模糊的度量标准“9”之外,需要考虑的很重要一点是很多云计算的报价是建立在其他
云计算报价的基础之上。将多重基础架构相结合的能力可以提供超大的弹性和强大的功
能,但是每增加一个供应商都会使得系统的可靠性下降。如果一个云计算供应商提供的服
务是建立在另外一个供应商存储服务和第三个供应商数据库服务的基础上,并且所有供应
商都能提供五个“9”的可靠性,那么,整个系统的可靠性将达不到五个“9”。当第一个供
应商的系统关闭时,服务就不可用了;当第二个或者第三个供应商的系统出现问题时,服
务也同样不可用。涉及的云供应商越多,整个系统的停机时间越长。

最后,随着云计算供应商数量的增加,外部因素的数量也随之增加。如果一个虚拟机和一
个云计算数据库处在同一数据中心,那么虚拟机和数据库的通信不需要网络接入。相反,
如果云计算数据库由另外的供应商提供,那么虚拟机和数据库之间的可用带宽就影响到整
个系统的表现和可靠性。两个云计算供应商的系统都很健全,可以正常运行,但是一旦它
们之间的网络连接中断,整个系统就会停止服务。

总之,欲评估云服务的可靠性,用户应尽可能直接或间接地深入了解交付服务的云计算供
应商。

8.7 交叉引用:服务等级协议 (SLA) 要求和云交付模型

下列表格交叉引用第 2.2.1 节中的三个 NIST 交付模型,同时列出了 SLA 的要求。

基础架构即服务
平台即服务
平台即服务(PaaS) 软件即服务 (SaaS)
(IaaS)
要求

数据加密  
隐私   

2010 年 7 月 2 日 52
云计算用例白皮书 版本 4.0

基础架构即服务
平台即服务
平台即服务(PaaS) 软件即服务 (SaaS)
(IaaS)
要求

数据保留与删除  
硬件擦除与破坏  
合规性   
透明度   
认证   
关键性能指标术语  
度量标准   
审计   
监测   
可机读 SLA 

8.8 交叉引用:SLA 要求和用例

在理想状态下,SLA 同时保护云计算用户和供应商的利益。仅给出一个 SLA 并不能够满


足所有用户的需求,此处谈及的每项要求并不适用于所有的用户场景。下列表格交叉引用
了第 节中的七种用例场景,此处也列出了 SLA 的要求。

最终用 企业到云到 企业到 企业到云到 私有 更改云


混合云
户到云 最终
最终用用户 云 企业 云 供应商

要求

数据加密 
隐私       
数据保留与删
除   
硬件擦除与破
坏   

2010 年 7 月 2 日 53
云计算用例白皮书 版本 4.0

最终用 企业到云到 企业到 企业到云到 私有 更改云


混合云
户到云 最终
最终用用户 云 企业 云 供应商

要求

合规性       
透明度       
认证      
关键性能指标
术语     
测量标准      
审计 
监测      
可机读 SLA 

2010 年 7 月 2 日 54
云计算用例白皮书 版本 4.0

9 结论和建议

云计算的构建顺应了业内众多趋势,包括虚拟化、SOA 和 Web 2.0。因此,对本文概述的


许多要求已经存在现行标准。随着不断前进,我们将作为一个社区共同努力,细化满足客
户需求的现有标准,利用正在使用的标准,对现有标准尚未涉及到的地方查漏补缺,填补
空白。

本白皮书由开放式 Web 社区的超过 900 名参与者撰写而成。最初的研讨组成员只是《开


放云计算宣言》的支持者,但这一队伍迅速壮大,目前成员遍布世界各地。其中社区成员
包括来自各大中小型公司、政府机构、咨询公司和服务供应商的代表。

在本白皮书撰写过程中,宣言中的三个原则至关重要:1) 用户应通力合作;2) 保持云计


算开放的任何行动应以客户利益为导向;3) 尽可能沿用现行标准。本白皮书验证了这些原
则的适用性,并且这些原则将是任何后续工作的核心。

此处描述的用例显示了对用户的一般要求,内容如下:

 通用虚拟机格式、 数据格式和 API:


:为某一云供应商创建的虚拟机、数据和应用
程序应可以运行于另一云供应商,无需改动。

 云 管 理 : 若没有服务管理、控制、计量、监测、联合身份、服务等级协议和基
准、数据和应用程序联合、部署和生命周期管理,云计算是不可行的。第 3 节对
这些要求作了定义。

 安全:尽管对安全的要求会因应用程序和数据类型的不同而有很大差异,但安全
在云计算中仍至关重要。

 位置感知:一种用以确定托管云基础架构的物理机器位置的方法,这是许多政府
法规的绝对要求。

用户必须可以执行此处介绍的任何一种用例,而无需依赖导致供应商锁定的封闭、专有解
决方案。

此处讨论的开发人员需求可分为两大类:

 服务 API:对数据库、消息传递(包括点对点和发布订阅)、原始计算能力和存储
的 API 要求都直接涉及到云服务。

 支持 API:对高速缓存、日志记录、身份管理、服务发现、会话管理和服务等级协
议的 API 要求是有效使用云服务所必需的。

开发人员必须可以执行本文介绍的任何一种用例,而无需依赖导致供应商锁定的封闭、专
有解决方案。

2010 年 7 月 2 日 55
云计算用例白皮书 版本 4.0

当用户期望将其数据和应用程序向云迁移时,安全始终是最受关注的问题。云计算本身不

会引入任何安全问题。向云迁移的顾虑是,现在执行和实施安全策略需要涉及第三方。这
种控制权的丧失加强了对云供应商透明度的要求。此处讨论的安全包括云供应商必须提供
的安全控制、联合模式和标准。

企业使用云服务时,必须在服务等级协议 (SLA) 中对用户及供应商职责予以清晰界定。


SLA 规定了用户使用此类服务的方式及供应商交付此类服务的方式。在签订任何协议前,
云服务用户应完全理解供应商 SLA 的所有条款,且用户要考虑其所属企业的需求,这一
点十分关键。

纵观云计算各个方面,只要现有标准符合要求,我们必须确保持久深入地执行这些标准。
如果现有标准不符合要求,我们必须制定并实施所需标准来满足这些要求。这一由社区编
写的白皮书旨在为建立一个真正开放的云计算环境提供参考。

2010 年 7 月 2 日 56
云计算用例白皮书 版本 4.0

内容变更

2009 年 10 月 30 日第 2 版:

 新增开发人员需求一节。增加关于不同的 API 层次、API 类别和开发人员角色的讨


论,作为第 2.4 节。开发人员及其要求是第 2 版内新增内容的重点。
 在适当情况下用“灵活性”代替“可扩展”。
 更新第 2.1 节中的分类讨论,以反映云计算 NIST 定义的变化。
 更新第 4.4 节客户场景。
 对统一部署和通用虚拟机格式的要求展开讨论,范围延伸至云供应商将存储连接
到虚拟机的不同方式。

2010 年 2 月 2 日第 3 版:

 考虑到安全问题,对第 3.2.1 节中关于服务等级协议的讨论稍作调整。


 新增第 6 节关于安全场景和要求的讨论,以及第 7 节“安全用例”。
 结论和建议部分中新增安全简述。

2010 年 6 月 30 日第 4 版:

 新增第 8 节服务等级协议 (SLA)。


 结论和建议部分中新增服务等级协议简述。

2010 年 7 月 2 日 57