一种开放的可互操作的云

2011-08-31 09:21:21来源：作者：

在这篇文章中我们会描述：在当下，怎么样通过利用成熟的开放标准（特定于云计算、网格与存储领域）创建具有可互操作性的云。我们会演示使用一些最新的具有创新性的主要云计算接口规范来实现一个开放的、基于标准的、

在这篇文章中我们会描述：在当下，怎么样通过利用成熟的开放标准（特定于云计算、网格与存储领域）创建具有可互操作性的云。我们会演示使用一些最新的具有创新性的主要云计算接口规范来实现一个开放的、基于标准的、具备可互操作性的云计算服务实例。

写作这篇文章的动机是为了说明这样一个事实，即当前由各种标准开发组织（SDO）提供的可用的云计算标准特性已经足够用于开发一个云计算服务实例，而这一点将在下面的章节中得到证明。这篇文章可以被视作探索云计算标准集成的工作的最初环节中的一个步骤，尤其是开放云计算接口（OCCI)^[1]、开放虚拟化格式（OVF）^[4]以及CDMI^[3]之间的集成。最后但很重要的是，在这篇文章里所讨论的详细内容能够驱动OCCI和云管理工作组（CMWG）^[10]，以及其他一些工作组织之间的协作，例如：cloud-standards.org、面向E基础设施的标准和互操作性推进组织（SIENA）^[5]、国家标准与技术研究所（NIST)^[6]等等。

为了描述怎么能够做到这种标准的集成，我们会以一个简单的情景为例。在这个情景中，设想有一个刚起步的服务提供商希望部署、扩充、移植以及重新部署他们新的基于Hadoop^[7]的MapReduce服务。

为了实现并能够执行这个情景，使用了下面所列用得到的标准：

来自DMTF的OVF——提供了一种能够打包开发虚拟基础设施的方法，这样开发成果可以导出或者导入到一个基础设施服务实例中。
来自SNIA的CDMI——提供了一种API，可以用于对存储基础设施服务实例进行运行时管理。
来自OGF的OCCI——提供了一种API，可以用于对基础设施即服务实例进行运行时管理。

需要指出的是，其他一些方面的问题如授权与验证等在这篇文章里没有涉及。这些问题可以说属于另一个维度，有其他的规范与技术（如OAuth、OpenID等）来对应。OCCI和CDMI借鉴了HTTP协议组中关于安全方面的设计思路。

情景

这个情景是关于一个新起步的公司，他们希望为他们的客户提供MapReduce服务。由于是新服务，它将仅对一些限定的试用用户开放。基于这样的限制的前提，这个新公司的架构师设计了一个初步的开发架构，以满足服务所需的起始资源需求。服务的这个部署架构如图所示：

服务一旦部署后，用户数就要求服务必须要进行扩充。这意味着必须要在不下线的情况添加额外的资源来满足需求。除了扩充，我们认为这个情景中也必须要考虑移植的情况。在基础设施提供商遭受严重的中断的时候，新公司被迫迁移服务。而这就是这个情景的最后一个情节，也就是服务提供商把整个开发移到一个新的更合适的基础设施供应商的平台上。

这个情景包括两个明显的阶段：

服务开发与扩充
服务迁移与重新部署

其中每个阶段各包括若干步骤，它们都会在下面详细展开，以介绍其中用到的标准。

起步阶段的总体目标是利用基础设施供应商的CDMI与OCCI接口，并向供应商提供其能够理解的OVF服务描述。正是这些供应商提供的能力让新公司获得了可互操作性。

服务部署与扩充

要进行如上图所示的最初开发并说明如何进行扩充，将使用OCCI和CDMI。这个阶段又由下列步骤组成：

基于服务架构进行最初开发，其中将使用OCCI和CDMI，或者是从OVF导入。
一旦服务足够成熟，用户增加，扩充服务开发。而使用OCCI可以做到渐增式扩充。

下图表示了在使用上述管理API时这个新服务的部署方式。

进行最初的开发

在这个时间点上，目标是基于设计好的架构进行最初的服务开发，这样就可以提供给试用用户。总的来说，如上图所示的搭建服务的过程分为下列步骤：

建立内部/私有基础设施
a. 上传可以运行的虚拟机映像（包括三个：门户、Hadoop主服务器与从服务器）
i.上传虚拟机映像到云供应商。这样就有了一个CDMI管理端点
ii.把这个虚拟机映像注册成OCCI操作系统模板
b. 建立私有网络
i.使用OCCI的IPNetWork Mixin（192.168.0.1/24）
c. 建立存储卷A（5GB）
i.使用CDMI接口来完成上述任务
d. 建立存储卷B（100GB）
i.使用CDMI接口来完成上述任务
e. 建立Hadoop主服务器节点
i.使用Hadoop主模板与OCCI计算类请求
ii.使用OCCI的StorageLink来连接到存储A（使用CDMI标识符来把CDMI资源关联到OCCI资源）
f. 建立Hadoop从服务器节点
i.使用Hadoop主模板与OCCI计算类请求
ii.使用OCCI的StorageLink来连接到存储B（使用CDMI标识符来把CDMI资源关联到OCCI资源）
g. 连接主节点到私有网络
i.使用OCCI的IPNetworkInterface
h. 连接从节点到私有网络
i.Use OCCI的IPNetworkInterface
建立外部/公开基础设施
a. 建立门户节点
i.使用门户操作系统模板与OCCI计算类请求
b. 连接门户节点到私有网络
c. 连接门户节点到公开网络

服务部署好后，会有一些RESTful资源可用（如这里），还可以通过他们各自的API来进行管理。而且总体的服务也可以通过一个RESTful资源使用，总体服务的表示方式遵守OCCI规范（活动、链接等）。

扩充服务部署

随着时间推移，部署的服务可能会需要进行横向扩充（如果是正面的话，就是增加节点；如果是负面的话就是减少节点）。在本情景的上下文中，扩充的原因可能是由于现有的试用用户集合在这个新服务中发现了巨大的价值，从而向服务投入了更大的任务量；也可能是由于随着服务的成熟，供应商增加了试用用户的数量。这意味着必须随需增加以OCCI管理的、附有Hadoop任务跟踪器和数据节点的虚拟机。Hadoop的命名节点和工作跟踪器贮存在主节点上，在这个阶段可能并不需要扩充。

在这个阶段只有一个步骤，也就是，添加新的计算实例到服务中的操作，这样就可以横向扩充服务。这可以通过下列对OCCI兼容接口的调用很简单地实现：

建立新的Hadoop从节点
a. 使用Hadoop从节点模板
b. 使用OCCI的StorageLink连接到存储B（使用CDMI标识符来把CDMI资源关联到OCCI资源）
连接从节点到私有网络
a. 使用OCCI的IPNetworkLink

这里假设Hadoop从节点已经在之前配置完成，也就是它已经注册到Hadoop主节点中。

服务迁移和重新部署

在这个情景中，由于不满他们当前的供应商的恶劣的服务质量，新公司决定把他们现有的开发迁移到一个新供应商的平台上。这时候，所有的三个标准需要协作来保证从云平台A到B的迁移和重新部署能够成功。总体过程分为四个步骤：

服务查找和发现——一旦新公司决定更换服务商，需要了解新的替代供应商是否能够支持老供应商所提供的同样特性。这样一个过程可以使用OCCI（查询接口）和CDMI（元数据接口）的服务发现机制来完成。现在这个CDMI接口不是通过标准化的URL来提供。在这篇文章稍后的位置我们将给出解决这个问题的方案。只有在确认了替代供应商可以支持以前的特性之后，这个新公司才会执行服务导出、迁移和数据导入。
服务导出——可以用OVF格式来表示服务的内容，这需要做一个用OVF表示服务内容的请求。使用HTTP内容协商可以完成这个任务，这将得到一个OVF文件，外部连接到CDMI管理下的数据（应用数据、虚拟机映像等）。
迁移——CDMI接口应该处理数据从云平台A到B的实际迁移过程。这个可以通过CDMI的序列化和反序列化特性来完成。
服务导入——服务导出成OVF表现方式，并且相关数据也迁移到新的服务提供商后，需要实例化原有的服务。实例化是使用导出的OVF表示文件来操作。这个OVF文件被交给服务供应商，由供应商代替客户来按照OVF文件的描述实例化资源（例如：计算、网络或辅助存储），并关联（由CDMI管理的）相关数据。

如果迁移是“冷”迁移（在迁移过程中服务被终止活动并下线），可以使用OCCI的终止和重启虚拟机、网络资源等特性。目前，要支持很短或没有服务停机的实时迁移，相比于对规范的支持来说更重要的是，在实时迁移中牵涉到的供应商需要支持（类似于对等协议/工具）相关的能力（例如：跨子网的实时迁移）。

集成云标准

前面描述的这个情景说明了在几个（现在可用）的云标准之间需要一些相互作用。这个情景给出了需要扩充和迁移的例子，两种情况下三个标准都起到了重要的作用。OCCI被用作引发操作的运行时管理API，OVF被用于可迁移性任务，而CDMI非常适合数据移动和格式迁移。虽然CDMI也可以用于一些管理任务（例如：使用CDMI来导入和上传镜像）——但是需要对现有的规范作出一些扩展。

要能够保证这个情景可以实现，标准需要被集成。后面的部分关注这些标准怎么样相互作用，还有一些需要做的、或者说是有很大益处的标准变更。

集成需要面对的整体课题

一个现在已经发现的最大挑战是数据的迁移。这不仅意味着把未经处理的数据从云平台A搬运到B，还包括数据格式上可能有的转换。例如说云服务供应商A所使用的VMware的文件格式可能需要转换成云服务供应商B所使用的VirtualBox的格式。

数据转换和迁移问题现在并没有很好地反映到文档中，可能还需要进一步调查。虽然两个云平台之间的迁移过程可能是由OCCI引发，但实际上也会涉及 CDMI和OVF。CDMI可以处理数据转换，但这更偏向于服务实现的一个方面。在这个操作中，OVF格式中的定义有可能发生变化。

集成存储管理API

OCCI有一个对存储管理能力的简单表现方式，可以实行大多数最为基本的存储相关的操作。OCCI的一个目标就是集成现存的标准，同时也避免重新发明轮子。当某个供应商希望暴露更为丰富的存储接口时，OCCI推荐使用SNIA的CDMI。在OCCI规范中给出了这样建议，详细说明了CDMI管理下的存储是如何在OCCI基础设施模型下进行表示（请参照OCCI 基础设施模型规范^[8]的3.4.3小节）。

集成OCCI和CDMI

既然两个规范已经相互引用，两者的集成也就可以在一个较高的层次达成。下面的章节给出了集成必要的信息，并引出了两个标准的更加紧密集成的思想。

使用OCCI的StorageLink来访问CDMI容器

如OCCI 基础设施扩展中所定义的一样，OCCI可以结合SNIA云存储标准——CDMI——使用，以提供对云计算存储数据的更好的管理。为了集成二者，需要使用OCCI的StorageLink，这将把OCCI管理的资源连接到CDMI资源。

使用OCCI和CDMI的服务迁移

如果一个服务供应商实现了OCCI和CDMI接口两者，用户可以开始启动和执行迁移的过程。如果服务供应商没有提供OCCI和CDMI接口，就需要用户的直接操作才能开始迁移。而要获知供应商是否支持OCCI和CDMI就要使用/.well-known/接口。

这个迁移过程需要按照上面“服务迁移与重新部署”小节所描述的步骤来执行。另一个服务供应商（也暴露了OCCI和CDMI接口）会被问询是否具有必要的能力以确保具备必须的服务能力。如果查询成功且能力满足，数据就需要在两个云平台间进行迁移，接下来就需要准备必要的资源。

CDMI可以用于解决数据迁移的问题。新的数据对象可以创建在目的云供应商平台上。新的数据对象一经创建成功，源数据对象就成为原始数据对象。请参照CDMI规范^[9]的第15节。

关于CDMI的思考

对于进一步集成OCCI和OVF到CDMI，建议对下列课题进行进一步探讨。

通过CDMI（使用OVF)导入和上传虚拟机镜像

当通过CDMI接口导入OVF文件时，应该可以根据OVF中的定义来分配网络和计算资源，但目前OVF规范并不允许这样做。CDMI关注云平台的存储需求，但是如果导入OVF文档，它不仅能处理存储资源分配，还可以与OCCI接口交互，并满足所有OVF文档的资源需求。

从CDMI容器链接回OCCI接口

目前的使用OCCI和CDMI的过程在CDMI规范的第13节中给出了说明。现在OCCI基础设施模型的资源实例可以链接到CDMI模型。正是使用OCCI的StorageLink把计算资源连接到它们的存储^[注1]，这样当前的链接就具有了从OCCI模型实例指向CDMI容器的方向。

让这种集成更为强大的是，让连接从CDMI指向OCCI模型的资源实例（补充的反向链接）会非常有用。从语义上来说，这意味着把CDMI的存储资源连接回它们绑定的OCCI计算与/或存储资源。一般来说，CDMI用户就可以看到哪些服务绑定到他们的数据对象上。在本文的情景中，这能够找到哪些磁盘用于虚拟机，还有哪些数据是用于MapReduce服务本身。

通过Well-Known地址暴露能力的查询接口

如RFC 5785中所描述的那样，我们推荐把CDMI能力接口（同时）暴露在“/.well-known/com/snia/cdmi”路径之下，而现在它是通过 “cdmi_capablities”路径暴露出来。OCCI也使用了这个方法，可以把自己的查询接口暴露到“/.well-known/org/ogf /occi”路径。用这个方式客户端就有一种统一的方式来访问和查询服务供应的能力。最终这些命名空间应该被注册到 IANA。

集成标准以保证可迁移性

除了云端的存储与数据方面之外，服务的可迁移性必须得到确保。DMTF的OVF规范给出了一种以可迁移的方式描述完整服务的方法。OCCI接口可以用于以OVF格式导入和导出服务定义。后面的章节会更详细的讨论这些想法。

集成OCCI和OVF

OCCI和OVF完全可以互不影响地共存，目前只需要添加MIME类型的支持，这样可以告诉OCCI服务供应商客户端想要取得或者提供OVF格式的信息。在OCCI规范没有包括这个新MIME类型的规范，现在它只支持text/occi，text/plain以及 text/uri-list。

把OVF映射到OCCI基础设施模型

下表概括了OCCI属性如何与OVF属性双向映射。

OCCI的计算资源

说明	OVF	OCCI	详细
CPU架构（86，x64）	<vssd:VirtualSystemType>[...String...]</vssd:VirtualSystemType>	occi.compute.architecture	见VirtualHardwareSection
核心数量	<rasd:ResourceType>3</rasd:ResourceType> <rasd:VirtualQuantity>1</rasd:VirtualQuantity>	occi.compute.cores	见VirtualHardwareSection
主机名	<Property ovf:key=”hostname” ovf:type=”string”> </Property>	occi.compute.hostname	ProductSection的一部分
处理器速度	<rasd:ResourceType>3</rasd:ResourceType> <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits> <rasd:Reservation>500</rasd:Reservation>	occi.compute.speed	见VirtualHardwareSection
内存容量	<rasd:ResourceType>4</rasd:ResourceType> <rasd:VirtualQuantity>512</rasd:VirtualQuantity>	occi.compute.memory	见VirtualHardwareSection
资源状态	N/A	occi.compute.state

OCCI的网络资源

说明	OVF	OCCI	详细
网络标记	<Property ovf:key=”label” ovf:type=”string”>	occi.network.label	定义于Properties，见ProductSection
广域网名	<Property ovf:key=”vlan” ovf:type=”string”>	occi.network.vlan	定义于Properties，见ProductSection
资源状态	N/A	occi.network.state

OCCI的存储资源

说明	OVF	OCCI	详细
存储设备大小	<Disk ovf:diskId=”vmdisk2″ ovf:capacity=”536870912″	occi.storage.size	见DiskSection
资源状态	N/A	occi.storage.state

其他的OCCI资源可能也需要映射，例如某些Link和Mixin，它们是由OCCI基础设施模型扩展所定义。这些映射很简单，与上面的表相类似。

服务供应商现在自由决定如何处理没有映射的属性，这样有可能当客户端以OVF格式去获取OCCI管理的服务时，结果是只能导出一个最小化的OVF文件，仅包括了OCCI基础设施表示方式中定义了的属性。但是服务提供商可以选择在OCCI基础设施模型的服务部署之外同时保存OVF表示格式，这样整个 OVF表示都可以取得。我们现在推荐后者这种形式。

保证横向/纵向扩充

横向和纵向的扩充现在并没有在OVF规范里得到充分覆盖，不过范围可以在服务描述里定义。范围的应用让客户端能够为一个属性指定有效的范围集合，然而（就像虚拟机的数量一样），这对于扩充来说并不足够，因为扩充应该有逻辑基础。横向和纵向的服务扩充只能通过合并使用OCCI和OVF才能实现。

从OCCI资源模板到OVF的映射

OCCI基础设施扩展描述了让用户定义资源和操作系统模板的方法。模板让OCCI实现的客户端能够快速便捷地应用预定义的配置到OCCI基础设施中定义的类型，他们通过OCCI的Mixin的实例实现。而操作系统和资源模板则相辅相成：

操作系统模板让客户端指定在请求的计算资源上必须安装什么样的操作系统。
资源模板Mixin建立在操作系统模板之上。一个资源模板是一个供应商定义的Mixin实例，指向预设定的资源配置（类似于亚马逊的EC2实例类型[小、大、超大]）。

最好也在OVF表现方式下定义这些模板。

OCCI的思考

下面两个课题与作为边界协议的OCCI并不直接相关，他们主要是关于实现OCCI的服务提供商应该如何处理某些操作。

根据OVF描述中的选项来配置OCCI实体

OVF格式可以配置某些操作——如描述开机和关机时的动作，未来版本的OVF甚至可能会详细说明ActivationEngines以及其他一些方面，这样OVF就能够某种程度上说明处理服务的语义。那些允许在OCCI上使用OVF准备整个服务的服务供应商就需要处理这些配置和细节，并据此配置资源管理框架。

确保OVF中描述的一致性等级在OCCI的搭建时得到满足

与前一个课题密切相关的是OVF描述的一致性等级。支持在OCCI上使用OVF准备服务的服务供应商需要注意满足这些等级要求。在实例化服务的时候一致性等级必须得到满足。如果等级没有满足，客户端应该将此视作对服务等级协议（SLA）的违背。这样，如果一个服务供应商不能实现OVF描述里要求的一致性等级，对于服务准备的请求应该被否决。

关于OVF的思考

为了让OVF和OCCI进一步集成应该考虑下面的课题。

像OVF中的虚拟开关一样描述网络设备

网络特性已经可以在OVF中得到定义，不过如果能够像前面“情景”一节中在服务描述里所用的那样，描述整个网络的搭建，那就更好了。这里我们指出OVF的2.x版对这种描述会有更加好的支持。

为OVF定义MIME类型

在从服务请求操作或接收信息的时候，OCCI客户端依赖于正确的mime-types。服务供应商会使用（内容协商）MIME类型信息来了解它所接受到信息的种类。客户端则永远可以按他们希望接受的请求信息的mime-type来请求信息。由于OVF文件的导入导出特性，客户端会传回OVF文件到 OCCI服务，或者以OVF格式来请求当前状态。为了达到最佳的互操作性，我们建议注册OVF的MIME类型。