分享

去年年底，我曾经与一位很资深的研究员对云计算这个话题进行非常深入的探讨，而且这场讨论使我对云计算有了新的认识。在那次讨论伊始，为了突显我对云计算的熟知，我连绵不绝地抛出诸如Google App Engine，Amazon EC2这类技术语，或者类似随需应变和动态扩展这类广告语。正当我心中暗暗得意，期望他能对我另眼相看时，他却报之以微微一笑，说道：“你所谈的那些东西，的确很吸引人，也非常不错，但无论是过去的PC时代，还是现在互联网时代，亦或是未来的云计算的时代，都是应用为王，也就是说，无论任何技术或者特性，它们存在都是为了如何更好地支撑应用”。当他提到“应有为王”这四个词，我不禁有点呆滞，因为这点不仅是我不曾想到的，而且一语中的。让我们回想一下，在PC刚诞生的年代，商业表格软件VisiCalc的发布使得Apple II 正式进入主流市场，从此PC不再仅是Geek的玩物，在互联网泡沫破灭的时候更是如此，Google的搜索应用不仅使人们能够轻松访问到全世界的信息，而且使这些各式各样的信息深深融入了我们的生活，从此我们无法离互联网五尺之外，难道在云计算时代，应用不再为王了吗？

云计算与应用

既然应用如此重要，那么在即将来临的新时代，云计算技术该怎么更好地为应有服务呢？

首先，思考一下在现有技术支撑下的应用有哪些不足之处？总体看来，在三个方面比较突出：

1. 开发麻烦，最明显的例子就是在一个普通应用的整个开发和测试过程中，不仅需要兼顾多个平台，比如Windows，Linux等，而且还要注意每个平台的多个版本，比如Ubuntu 9.10，Ubuntu 8.04 LTS等等。
2. 部署麻烦，因为一个应用的安装是很难离开艰涩的教程和繁琐的步骤， 而且缺乏安全和许可证的管理，使得使用者的利益很难保护，而且开发者的权益更难捍卫。
3. 维护麻烦，原因是一个应用不仅包括ISV（独立软件开发商）开发的软件，还包括其他供应商的操作系统，中间件和数据库等，使得其升级麻烦，寻求技术支持方面更麻烦。

其次，有那些云计算技术能帮助应用呢？虚拟器件（Virtual Appliance）应该是一个相当不错的帮手。虚拟器件，是一个预配置的软件堆栈，包括1个或多个虚拟机，而且其中每个虚拟机都是可以自运行，而且自带操作系统和相关应用，并明确其所需的虚拟资源。（如果大家想进一步了解虚拟器件，可查看《程序员》2010年4月刊的《虚拟器件 – 虚拟化技术的新利刃》），虚拟器件对应用的好处也体现在相似的三个方面：

1. 开发简单，因为开发人员能限定应用自带的操作系统，中间件和数据库等软件的版本，比如SLES 11，WAS 7和DB2 9.7等，这样将非常有效缩小开发和测试的范围，从而极大地减低开发测试的难度和复杂度。
2. 部署简单，首先，如果使用虚拟器件方式部署的话，能将本来需要几天的工作缩短到几分钟，能将本来几十步操作精简到轻轻一击。其次，能非常简单的将应用部署或者迁移到公有云上，以应对突发情况。
3. 3维护简单，因为整个虚拟器件都是来自于同一个ISV，所以任何软件升级和技术支持，都只要和一个ISV联系就可以了，不仅避免了常见的扯皮现象，而且简化了相关流程。

虽然虚拟器件这个想法不错，但是大家都知道“无以规矩不成方圆”的道理，所以VMware带领众虚拟化技术提供商提出了Open Virtualization Format （简称“OVF”）协议来规范虚拟器件的发展。

OVF协议

OVF协议是用于发布和部署虚拟器件的开放标准，被VMware CTO Steve Herrod喻为虚拟机的MP3格式，由业界著名DMTF(分布式管理任务组) 协会制定和发布，并且隶属于志在推动云计算互操作性的VMAN(Virtualization Management，虚拟化管理) 计划。OVF协议定义了一种开放、安全、可迁移、有效，跨平台以及可扩展的格式，以用于封装和分发将在虚拟机上运行的软件。

设计理念

OVF的设计理念主要体现在三个方面：

1. 便于分发，其支持虚拟器件的认证和完整性检验等安全措施，并提供软件许可的管理机制。
2. 支持多种架构，包括单个虚拟机，多个虚拟机或者多层（Multi-Tier）架构。
3. 开放程度高，因为OVF协议不依赖于特定的虚拟化平台，而且支持一定程度的扩展以满足虚拟器件技术不断发展和某些特殊的需求。

组成部分

主要有五种文件组成：

1. OVF 描述文件（.ovf）：通常称为“OVF信封”，是一个XML文档，用于定义整个虚拟器件的组成部分（比如虚拟机），及每个组成部分的特性和其资源需求。
2. 虚拟磁盘文件：其是虚拟机的二进制磁盘镜像。
3. 清单文件（.mf）：清单包含OVF包中各文件的 SHA-1 摘要，其作用是确保包的完整性。
4. 证书文件（.cert）：作用是通过对清单文件进行数字签名来确保整个虚拟器件的可信性，以 base64编码的X.509 证书形式存储。
5. OVF环境（Environment）文件 （.env）：一个Key-Value形式的XML文档，用于设定和维护虚拟机上软件的配置。

OVF信封

OVF信封是整个虚拟器件的核心文件，主要包括以下几个模块：

1. 磁盘（Disk）模块：用于描述存放在OVF包内的虚拟磁盘的信息，比如磁盘的大小和格式。
2. 网络（Network）模块：用于描述OVF包内虚拟机的网络拓扑结构。
3. 启动（Startup）模块：用于定义OVF包内多个虚拟机之间的启动顺序。
4. 虚拟系统（Virtual System）模块：用于描述一个虚拟机，并且作为一个容器，来包含多个隶属于这个虚拟机的模块，比如：许可协议模块，资源分配模块，操作系统模块和产品模块等。整个OVF信封可包括多个虚拟系统模块以支持多虚拟机部署。
5. 资源分配（Resource Allocation）模块：定义虚拟机所需要的资源量，比如vCPU的个数和内存的大小等。
6. 许可协议（Eula）模块：其包含这个虚拟机相关的许可协议和法律条款，并且在这些协议和条款都将在部署时被使用者确认。
7. 产品（Product）模块：用于描述安装在虚拟机上软件的信息，比如，软件的名字，版本号，供应商等，并定义一些重要的软件配置信息，比如，Web服务器和数据库的开放端口等，而且指定哪些配置是使用默认值，哪些配置是需要在部署时输入的。
8. 操作系统（Operating System）模块：其定义虚拟机内部操作系统的版本信息，比如Microsoft Windows Server 2008。

OVF环境文件

OVF 环境文件常用在部署阶段，里面主要存放并维护在信封内的产品模块里面定义的配置信息。此文件在部署时具体使用流程是：首先，部署工具会让用户回答并确认信封的产品模块内的软件配置选项，比如Linux 系统的IP地址。接着，部署工具会通过刚才的输入生成OVF环境文件，并通过虚拟光驱或者虚拟软驱将环境文件传入虚拟机中。最后，虚拟机上软件会读取这个环境文件，并执行相关操作。

使用流程

在这里，我们以一个典型的Lamp（Linux-Apache-MySQL-PHP）应用为例，来讲述如何利用OVF协议来部署应用。

1. 启动两个空白的虚拟机。首先，在第一台虚拟机上安装Linux系统，Apache Web服务器和用于设置网络和软件配置的激活软件（比如IBM Activation Engine），并加载PHP应用。其次，在另一台虚拟机上安装Linux 系统，MySQL数据库和激活软件，并创建应用的数据库表。最后，关闭这两台已经安装成功的虚拟机，并导出它们的磁盘镜像。
2. 在OVF工具（比如IBM OVF Toolkit）上创建和编辑Lamp应用的OVF 信封，并在工具上导入上步骤生成的两块磁盘镜像，最后在工具上生成文件名为Lamp.ova的OVF包。还有，清单文件和认证文件一般都由工具自动生成并放置在OVF包内。下图1为部署之前Lamp应用的内部结构。
3. 在虚拟化平台上面（比如VMware vSphere 4）部署这个OVF包，首先，在部署时，平台让用户回答并确认信封内的产品模块里面定义的软件配置选项，比如两个虚拟机的网络地址和Apache等软件的配置。接着，虚拟机平台会根据刚才的设置自动生成一个OVF环境文件，并为这个文件创建一个ISO。最后将生成的ISO做为虚拟的CD-ROM插入到虚拟机的虚拟光驱内。
4. 在两台VM启动的时候，激活软件会作为一个服务被启动，首先，它会读取虚拟光驱内的OVF环境文件。接着，它会根据OVF环境文件来设置虚拟机的网络地址和相关软件配置，最后，确保应用能正常运行。下图2为部署之后Lamp应用的内部结构。

图1.部署之前的Lamp应用

图2.部署之后的Lamp应用

OVF与云计算实践

虽然现在只是OVF 1.0协议正式发布半年之后，但是有许多厂商已经对OVF协议进行了一定的实践，并在自己的云计算产品中引入了OVF协议并将其作为核心的部署模型，其中包括开源的Xen Cloud Platform，VMware的vCloud Express和IBM的WebSphere CloudBurst Appliance等等，在这些产品中，对OVF最为重视的，非WebSphere CloudBurst Appliance莫属，因为它不仅将整个工作流程都围绕OVF展开，而且还在OVF的基础上加入预优化和自动激活等“灵丹妙药”来让用户更方便地部署应用。

OVF的不足之处

虽然OVF协议在很多方面都很优秀，但是还是存在一些不足之处：

1. 在跨平台方面存在缺陷，虽然OVF协议支持跨平台，但因为镜像格式的限制，所以现在部分虚拟器件无法跨平台，其原因是现有的虚拟器件主要使用VMware的VMDK作为镜像格式，而此格式在非VMware的平台缺乏支持。
2. 缺乏一部分业界巨头强力的支持。首先，Amazon已经在OVF协议之前推出了类似于OVF的私有格式AMI（Amazon Machine Images），同时使用者甚众，且短期内似乎没有支持OVF的迹象。其次，虽然微软已经表明了对OVF支持的态度，但可惜到现在还未推出相关的产品。
3. 体积庞大，因为OVF包需携带磁盘镜像的原因，使的OVF包常以GB为单位，导致其难于通过网络传输，这将影响其用户体验，虽然VMware已经提出了Delta Disk和Stream等技术，但在短期内这个问题很难被克服。

OVF的未来

谈到OVF的未来，首先，肯定是对现有功能的强化，就像OVF最近推出1.1版本那样，并没有在范围的扩展上做文章，而是增强其原有的部署功能，比如支持文件系统格式的镜像。其次，OVF协议身为VMAN计划的一个核心的组成部分，在将来会进一步为整个VMAN计划服务。

总结

在2007年10月初，当我第一次看到OVF协议初稿的时候，我不禁暗暗赞叹这奇思妙想，并深信它将有助于整个IT事业的发展。2年半后，当我看到OVF协议已经茁壮成长的时候，我不仅更坚定了当初对它的期望，更觉得在今后云计算的时代它将进一步推动应用的发展，使应用依旧为王。

参考资料

1. OVF 1.1 规范。
2. 使用 OVF Toolkit 构建虚拟工具。
3. Inside the OVF Package。
4. 《虚拟器件 – 虚拟化技术的新利刃》，《程序员》2010年4月刊
5. WebSphere CloudBurst Appliance 中的 “特殊原料”。

分享