hosteons中文网

不同于传统的位于单位组织内部的 IT 基础设施，云计算的诞生给单位组织的 IT 资源供给带来了前所未有的灵活性——可以瞬时增加、转移或者减少计算资源来快速响应动态的资源需求变化，能在几个小时而不是几周内部署一个新的应用来满足业务需求。

为了达到这种更具弹性的计算能力，在设计任何云系统时必须要考虑互操作性与可移植性。

• 互操作性规定，IT 系统中应用软件层以下各层采用开放的通用型组件，杜绝使用云服务提供商各自内部的封闭组件。
• 可移植性规定，IT 系统中应用软件层和数据信息层应采用开放的通用数据格式和软件运行环境，保证同一个应用和数据能随意迁移到其他地方。

一方面，互操作性与可移植性能让你把服务扩充到多个由不同云服务提供商提供的云端，在操作层面就像一个系统；另一方面，互操作性与可移植性能在不同平台或者不同云端之间轻松移动数据和应用。

互操作性与可移植性不是随云计算出现而产生的新概念，也不只是在云计算环境中人们才考虑互操作性与可移植性，只不过与传统 IT 系统相比，具备开放和共享处理能力的云计算更需要考虑互操作性与可移植性。多租户意味着多个单位组织的数据和应用并存，并且不排除能通过共享平台、共享存储和共享网络访问（有意或无意）他人机密数据的可能性。

下面重点介绍在设计互操作性与可移植性时必须考虑的关键因素。

互操作性

互操作性是云计算生态系统中各个协同工作的组件应具备的特征，这些组件可能来自各种云端和传统 IT 系统。互操作性使得我们可以随时使用新的或者来自不同云服务提供商的组件来替换已有的组件，而不会中断云中的任务，也不影响数据在不同系统之间进行交换。

单位组织在使用云服务的过程中可能会考虑更换云服务提供商，常见的原因如下：

• 续签合同时，云服务提供商的报价令消费者难以接受。
• 消费者发现有价格更便宜的同类型云服务产品。
• 云服务提供商停止了业务运营。
• 云服务提供商在没有给出合理的数据迁移计划之前，关停了企业正在使用的服务。
• 云服务提供商的服务质量难以令消费者满意，如未能达到服务水平协议（SLA）中规定的一些关键性能指标。
• 云服务供/需双方之间存在商业纠纷。

如果缺少互操作性（与可移植性），就会出现消费者被云服务提供商捆绑的现象，最终会损害消费者的利益。

一个云端互操作性的优劣程度往往取决于该云服务提供商是否使用开放的或者公开发布的架构和标准协议及标准的 API 接口。许多云服务提供商（如 Eucalyptus）喜欢在标准组件的基础上添加非公开的钩子和扩展，以及一些增强功能，显然这些都会降低互操作性与可移植性。

可移植性

可移植性是指能把应用和数据迁移到其他地方而不用理会云服务提供商、平台、操作系统、基础设施、地点、存储、数据格式或者 API 接口如何。

在选择云服务提供商时，可移植性是需要考虑的一个重要方面，因为可移植性既能防止云服务提供商锁定客户，又允许我们把相同的云应用部署到不同的云服务提供商那里，如建设灾备中心、同一应用全球分布式部署等。

如果未能妥善解决云迁移中的可移植性与互操作性，那么可能会无法实现迁移到云计算后的预期效益，并可能导致成本上升或项目延期，这是因为本该避免而未能避免的如下因素：

1）云服务代理商或提供商锁定——一个特定的云解决方案的选择可能会限制以后转移到另一个云服务提供商。

2）处理不兼容和冲突造成服务中断——云服务提供商、云平台和应用的差异可能会引发不兼容性，这种不兼容性会导致应用系统在不同的云基础架构中发生不可预料的故障。

3）不可预料的应用系统重新设计或者业务流程更改——当迁移到一个新的云服务提供商时，可能需要重新审视程序的功能或者要求修改代码，以确保其最初的执行行为。

4）高昂的数据迁移或数据转换成本——由于缺乏互操作性与可移植性，当迁移到新的云服务提供商时，可能会导致计划外的数据变化。

5）数据或应用程序安全的丧失——不同的云服务提供商可能采用不同的安全控制、密钥管理或者数据保护策略，当迁移到一个新的云服务提供商或云平台时，可能会暴露原先未被发现的安全漏洞。

把应用迁移到云端是外包的一种形式，而外包的金科玉律是“了解前期并做好如何退出合同的计划”。因此，可移植性（和在一定程度上互操作性）应该是任何单位组织计划迁入云端时必须考虑的关键标准，同时开发好一个切实可行的退出方案。

实施建议

1. 关于互操作性方面的建议

1）物理计算设备

同一个云服务提供商在不同时期的硬件或者同一时期不同云服务提供商的硬件差别很大，如果直接让消费者访问硬件设备（如物理服务器），则会存在巨大的互操作性鸿沟。建议：

• 尽可能采用虚拟化来屏蔽底层硬件的差异，但是要注意虚拟化并不能屏蔽全部的硬件差异，特别是目前的系统。
• 如果消费者必须要直接访问硬件，那么从一个云服务提供商迁移到另一个云服务提供商时，选择相同或更好的物理硬件和管理安全控制就显得至关重要。

2）物理网络设备

不同的云服务提供商使用的网络设备（包括安全设备）也不尽相同，包括它们的 API 和配置流程也不尽相同。为了保证互操作性，网络硬件设备应该虚拟化，并尽可能使得 API 具备相同的功能。

3）虚拟化

虽然虚拟化有助于消除物理硬件的差异，但是常用的虚拟机管理程序（如 Xen、VMware、KVM 等）之间存在明显的差异。建议：

• 利用开放虚拟化文件格式，如 OVF，以确保互操作性。
• 了解并记录使用了哪些特定的虚拟化扩展钩子（Hook），虽然这些钩子与虚拟化文件格式无关，但是仍然存在这种可能性：在其他虚拟机管理程序中不起作用。

4）框架

不同的平台提供商提供了不同的云应用程序框架，而且这些框架之间确实存在影响互操作性的差异。建议：

• 在迁移到一个新的云服务提供商时，先搞清楚API的不同之处，然后拟定修改应用系统的计划。
• 使用公开发布的API以保证各组件之间具备最佳的互操作性，为了便于迁移应用和数据，有时很有必要变更云服务提供商。
• 云端的应用系统一般通过因特网交互，可能随时发生各种故障（如组件运行失败、网络中断等）。

我们要做的是，确定一个组件发生故障（或反应慢）将如何影响其他组件，而且当一个远程组件出现故障时，要尽量避免可能会破坏系统的数据完整性的状态依赖——依赖另一个组件对数据的修改。

5）存储

数据类型不同对存储的要求也不同，结构化数据通常保存在关系数据库系统中，非结构化数据通常是按照应用程序（如微软的 Word 文字处理程序、Excel 表格程序和 Powerpoint 程序）所要求的格式存放。为了无缝地在不同云服务提供商之间移动数据，建议如下：

• 以一个被广泛接受的可移植的格式存放非结构化数据。
• 评估数据在传输过程中是否需要加密。
• 检查各种兼容的数据库系统，如果需要，再评估不同数据库之间进行数据移植的难易程度。

2. 关于可移植性方面的建议

把应用迁入云端的过程中会遇到很多问题，在可移植性方面的建议如下。

1）服务水平

不同云服务提供商的SLA也不同，所以有必要了解清楚SLA会如何影响你将来更换云服务提供商。

2）不同的架构

云中的应用系统可以驻留在不同的平台架构中。通过了解应用与平台的依赖性，我们就能搞清楚这些（包括API、虚拟机管理程序、应用程序逻辑等）将如何影响可移植性。

3）安全集成

在维护安全性方面，云系统引入了独特的可移植性担忧，具体包括：

• 现在云系统中的所有组件都会使用认证和身份机制，使用诸如SAML这种开放标准的身份机制将有助于提高可移植性，开发遵循SAML协议的内部IAM系统有助于系统将来移植到云中。
• 加密密钥应该托管在本地，并尽可能地在本地维护。
• 元数据是数据信息的一部分，但经常容易被忽视，因为我们在操作文件和文档时不能直接看到元数据。在云端，我们必须重视元数据，因为元数据随着文件一起移动，当移动文件和文件的元数据到一个新的云端时，要确保安全地删除了源文件元数据的全部副本，否则遗留下来的元数据可能会成为一个安全隐患。

用户自由度

互操作性与可移植性都是为了保障用户能自由使用云服务，这里的“自由”体现在以下几方面。

1）用户可以自由地迁入、迁出云计算，不花或者花费很少的时间和金钱成本。

2）用户能自由访问其他云应用：每个云端都是开放的，在这个云端中的用户能访问其他云端中的应用和资料。坚决杜绝运营商出于利益的考量封闭自身的云应用来黏住用户。

3）用户能自由选择云服务提供商：买方能自由选择卖方是完全竞争市场的一个重要特征。为了保证自由度，政府应该努力营造完全自由竞争的云计算市场，坚决打击运营商“捆绑”用户的不正当竞争行为。

4）用户能自由地把应用和数据从一个云服务提供商迁移到另一个云服务提供商：云端保存了用户的资料并安装用户需要的软件，当用户想更换云服务提供商时不应该存在障碍。扫除人为的障碍，杜绝不兼容性。所以，政府应该制定合理的云计算标准，并提供简单易用的迁移工具。

5）云服务提供商能自由选择云组件：云服务提供商搭建云端，涉及很多技术和软/硬件产品，规划之初就要充分考虑伸缩性、开放性、标准性，杜绝被组件产品厂商捆绑。现在的很多云服务提供商热衷于采用开源的软/硬件产品，这是对的。

6）云终端可以自由接入任何云端：一台终端设备成为人们的云计算总出入口。