欧盟云计算项目(RESERVOIR)介绍word版本

欧盟云计算项目（RESERVOIR）介绍

作者:vcloud（中国云计算论坛）

邮箱:tangyong@https://www.360docs.net/doc/392875921.html,

本文主要介绍欧盟的一个云计算项目RESERVOIR FP7，既然是研究，那么必然要给出研究的背景，研究的原因以及项目的总体介绍，同时，也将给出该项目所涉及的关键技术，以便更好地进行知识准备和技术积累。以下的内容将分为三个部分：

●研究背景

●为什么要选择RESERVOIR

●RESERVOIR模型及核心的组件

●涉及的基本概念

●涉及的关键技术

●项目的代码签出和涉及的开发语言

1 研究背景

当前，出现的云计算的范型，如Amazon弹性计算云（EC2），为驻留和部署基于WEB的服务而呈现了一个很有前景的概念性的基础，同时理论上将服务提供商从提供支持这些服务所需的计算资源的职责中释放出来。

云计算提供了很多优点，它允许带有市场领域的专业知识的个人或公司花费很少

的软件开发成本去构建和运行他们的“软件作为服务（SaaS）”，并且不需要管理任何硬件操作。这就帮助降低了软件复杂度和成本，加速到市场的时间并且方便了消费者。

有了云计算，公司能够按照需要（on-demand）从一个虚拟的没有限制的资源池中租用基础设施的资源。这种“付费后使用（pay as you go）”的定价模型按照每单位时间实际使用的资源来收取费用。这样，一个业务可能将优化它的IT投资并提高可用性和可伸缩性。

尽管云计算为服务计算的未来做了很大的承诺，但是，在当前的基础设施中存在许多固有的缺陷:

单一的云提供商的有限的伸缩能力

当前，尽管绝大多数云提供商声称有无限的伸缩能力，但实际上，作出以下的假设是合乎情理的:

随着云计算使用率的增加，即便最大的云提供商也会开始面临伸缩性的问题。

从长远来看，随着云提供商中的在线服务数量日益庞大，而且每个服务总是被巨大的全球客户群访问，那么，伸缩性的问题也许将急剧恶化。

●在云提供商之间缺乏互操作（interoperability）

当前的云技术并没有设计带有互操作。这就导致了不能通过云提供商之间的业务合作来解决伸缩性问题。另外，它阻碍了小和中等规模的云基础设施提供商进入云供应市场。总体上，抑制了竞争并将云消费者锁定到单一的提供商。

●缺乏内置的业务服务管理（BSM）支持

业务服务管理（BSM）是一个管理策略，它允许多种业务将它们的IT管理和它们高级别的业务目标相吻合。BSM的关键点是服务级别协议（Service Level Agreement）。当前的云计算解决方案并没有设计支持BSM的一些行为，这些行为很好地被建立在企业IT部门的日常管理中。结果，那些试图改变它们的IT操作方式到基于云技术的企业将使前进的步伐面临着非增长性和具有潜在的破坏性。

我们坚信通过改进现有的架构能够修补上述的问题以及其它主要的问题（如安全性和可用性）。相反，这些问题应该根据基本的设计准则通过对云计算架构进行合理的设计来解决。

因此，RESERVOIR提出了一个引用模型和架构来系统地解决这些缺陷。

以上的这些问题和缺陷从下文中引用,由于翻译的质量和理解的差异，请大家自己去体会和消化:

“The RESERVOIR Model and Architecture for Open Federated Cloud Computing”

2 为什么要选择RESERVOIR

最重要的原因是RESERVOIR是开源的云计算基础设施（IaaS）项目，特别是RESERVOIR所使用的几个子项目都是非常活跃的开源云计算项目，得到了欧洲一些大型软件提供商以及一些大学科研机构的支持和协助。

其次，以下也是选择RESERVOIR作为研究的一些重要原因。

●RESERVOIR的设计准则之一以模块化为中心。

●RESERVOIR架构本身具有可扩展性。

●RESERVOIR支持业务服务管理（BSM），在当前的一些云基础设施中并不多

见，也为转化为工业应用提供了研究原型。

●RESERVOIR致力于研究云的联合（federation），也就是云的互操作。

●RESERVOIR使用的子项目的社区非常活跃。

3 RESERVOIR模型及核心的组件

1）RESERVOIR模型

RESERVOIR模型中，在服务提供商的功能角色和基础设施提供商的功能角色之间有一个清晰的分离。

服务提供商是一些实体，它们理解特定业务的需求并且提供服务应用程序来解决那些需求。服务提供商不拥有这些服务应用程序所需要的计算资源；相反，它们从基础设施提供商那里租用资源。

基础设施提供商操作一组RESERVOIR 站点，管理物理基础设施供服务应用程序执行。这些RESERVOIR 站点的联合形成了RESERVOIR 云。为了优化资源的利用，一个站点的计算资源通过一个虚拟层被划分成不同的虚拟执行环境（VEEs）。这些虚拟执行环境是完全隔离的运行时环境，它们抽取出资源的物理

特性并且能够共享物理资源。被虚拟的计算资源连同虚拟层和所有管理启用组件被称为VEE 宿主（Host）。

一个服务应用程序是一组通过协同工作来达到共同目标的软件组件的集合。这样的服务应用程序的每一个组件执行在一个专门的VEE中。这些VEE被放置在同一个RESERVOIR站点或不同的RESERVOIR站点中的相同或不同的VEE宿主中（参见下图1）。

图1 服务应用程序由一组VEE（图中以小的正方形表示）来执行，这组VEE分布在RESERVOIR 云的不同VEE宿主（Host）中。对于一个特定的服务应用程序，VEE也许都被放置在同一个VEE宿主（Host）中（如服务应用程序1）；但是也许被放置在同一个RESERVOIR站点的不同的VEE宿主（Host）中（如服务应用程序2）；甚至也有可能被放置在不同的RESERVOIR站点中（如如服务应

用程序3）

通过使用一个服务清单（manifest），服务应用程序被部署在RESERVOIR云中，这个服务清单正式地定义了在服务提供商和基础设施提供商之间的合同与SLA。关于服务清单，将在后续的帖子中进行介绍。

在每一个RESERVOIR站点中，资源利用被监控并且VEE的位置会被不断地更新以最低的成本来达到最佳地利用。类似地，服务应用程序的执行也被监控并且资源的使用情况会不断地被调整来满足清单中指定的需求和SLA。

重要的是资源分配的优化不需要人来干预，完全由安装在每个RESERVOIR站点上的RESERVOIR软件堆栈来完成。

2）RESERVOIR中的核心组件

RESERVOIR由三层组件构成（参见下图2）。

(摘自https://www.360docs.net/doc/392875921.html,/wiki/index.php/Image:RESERVOIRArchitecture.png)

图2 RESERVOIR三层架构

服务管理器（SM）- Claudia

服务管理器负责服务应用程序的初始化（控制服务生命周期）并且动态地向VEEM 请求虚拟资源，尽量避免过度提供资源和提供不足的资源。服务管理器的接口（SMI）允许服务提供商通过使用服务清单（基于Open Virtualization Format）来控制服务供应的生命周期，服务清单中申明了服务组件（包裹在虚拟机映像中），服务需求，服务的QoS（监控，SLA目标和弹性规则）以及业务要素（成本，安