一种开放的可互操作的云

介绍

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

写作这篇文章的动机是为了说明这样一个事实，即当前由各种标准开发组织（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/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

主机名

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

详细

网络标记