一种开放的可互操作的云

阅读数:2470 2011 年 8 月 22 日

介绍

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

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

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

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

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

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

情景

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

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

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

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

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

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

服务部署与扩充

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

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

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

进行最初的开发

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

  1. 建立内部 / 私有基础设施

        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
  2. 建立外部 / 公开基础设施

        a. 建立门户节点

                i. 使用门户操作系统模板与 OCCI 计算类请求

        b. 连接门户节点到私有网络

        c. 连接门户节点到公开网络

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

扩充服务部署

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

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

  1. 建立新的 Hadoop 从节点

        a. 使用 Hadoop 从节点模板

        b. 使用 OCCI 的 StorageLink 连接到存储 B(使用 CDMI 标识符来把 CDMI 资源关联到 OCCI 资源)
  2. 连接从节点到私有网络

        a. 使用 OCCI 的 IPNetworkLink

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

服务迁移和重新部署

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

  1. 服务查找和发现——一旦新公司决定更换服务商,需要了解新的替代供应商是否能够支持老供应商所提供的同样特性。这样一个过程可以使用 OCCI(查询接口)和 CDMI(元数据接口)的服务发现机制来完成。现在这个 CDMI 接口不是通过标准化的 URL 来提供。在这篇文章稍后的位置我们将给出解决这个问题的方案。只有在确认了替代供应商可以支持以前的特性之后,这个新公司才会执行服务导出、迁移和数据导入。
  2. 服务导出——可以用 OVF 格式来表示服务的内容,这需要做一个用 OVF 表示服务内容的请求。使用 HTTP 内容协商可以完成这个任务,这将得到一个 OVF 文件,外部连接到 CDMI 管理下的数据(应用数据、虚拟机映像等)。
  3. 迁移——CDMI 接口应该处理数据从云平台 A 到 B 的实际迁移过程。这个可以通过 CDMI 的序列化和反序列化特性来完成。
  4. 服务导入——服务导出成 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/occitext/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 类型。

相关工作和概况

在调查本文中所用的情景的时候,发现有某些课题在进一步的调查中特别值得注意:

  1. 服务等级协议(SLA)

       a. 一个 OCCI 的 SLA 扩展目前正在开发当中,可能会得到采用。

       b.SLA 可能被定义在 OVF 文件里,并使用这个 OCCI 扩展获得推行。

       c. 存储和数据的 SLA 的监督、施行和搭建可以用 OCCI 扩展通过 CDMI 集成。当与触发器和动作结合使用时,这个监督扩展让更加标准化的自动扩充成为可能。
  2. OCCI 应该从其他标准采用的特性

       a. 我们发现 CDMI 的队列和通知机制非常有用,应该进一步调查这些特性是否可以集成到 OCCI 中。

       b. 在 RFC 3986 中说明的 URI 转义可能需要加入到现在 OCCI 提交中。

       c. 在 OCCI 现在的文本和 HTTP 头提交中添加 JSON 提交扩展可能促进 OCCI 和 CDMI 的更加紧密的集成。

结论

从参加在 DMTF 联合伙伴技术讲坛(APTS)上 SDO 会议的协同工作中,本文记录了从 OCCI 工作组的视角出发的一些观察以及活动事项。DMTF 主持了这个面对面活动,以调查开放云计算可互操作性以及可迁移性标准工作两者集成的可能性,涉及的标准包括 OVF、CDMI 和 OCCI。

在第一节中描述的情景用于遍历服务的生命周期中不同过程,尤其是服务的迁移和扩充。它的目的在于反映真实世界里的一次尽管有些基本的服务发布,证明了应用当前的标准是可能实现这样一个工程的。

本文的随后章节讨论了这标准的三驾马车能够如何集成,哪里还存在未解决的问题。需要进一步的调查或改进的未解决的问题得到了展示和说明。总体的集成是可以达到的,从而足以使用目前可用的这些规范版本获得对“情景”一节中描述的服务完全的部署、迁移和扩充。

这里强调指出引入第四个可用的规范也许会有很好的效果。CSA 的 CloudAudit 已经在行业中获得了接受,并为本文的情景添加了重要的特性。审计云端和一致性等级没有在本文中进行讨论,但是会在未来的调查中有更大的作用。

虽然目前更专注服务开发的基础设施等级,一个使用云标准的更加基于 PaaS 的情景(如 Node.js 或 GAE 服务)可能在本文的未来修订版中获得说明。

鸣谢

作者希望感谢 Mark Carlson(Oracle)和 David Slik(NetApp) 的对 CDMI 和 OCCI 集成上的知识分享。

我们希望感谢 Winson Bumpus(VMware)和 Jeff Wheeler(华为)在有关 OVF 的课题上的帮助。

非常感激下列审核者在创作、编辑和审核这篇文档中的工作:

  • Alexis Richardson (RabbitMQ)
  • Lawrence Lamers (VMware)
  • Sebastian Schoenberg (Intel)
  • John Kennedy (Intel)
  • Finian Rogers (Intel)
  • Dr. Craig Lee (The Aerospace Corporation)

关于作者

Andy Edmonds是 Intel 的研究员。

Thijs Metsch是一位高级软件工程师,就职于 Platform Computing,专注于网格与云计算技术。

Eugene Luster是一位在 R2AD 工作的云计算推广专员,专注于云计算开放标准开发。

参考文献

[1] Open Cloud Computing Interface working group community website

[2] Distributed Management Task Force website

[3] Cloud Data Management Interface website

[4] Open Virtualization Format

[5] Standards and Interoperability for eInfrastructure Implementation Initiative website

[6] NIST Cloud Computing Program

[7] Apache Hadoop website

[8] Open Cloud Computing Interface - Infrastructure, Open Grid Forum, GFD-P-R.184, 2011

[9] Cloud Data Management Interface, Storage Network Initiative Alliance, 2010

[10] Cloud Management Working Group website


[注 1] 这里的含义是指把一个磁盘镜像绑定到一个虚拟机实例。

查看英文原文: An Open, Interoperable Cloud


给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论