Cloudify从项目开发云端架构

4.5  Cloudify

       Cloud foundry作为业务第一个开源的paas，给我们带来了难得的学习和借鉴的机会，得以窥视paas的盒子内部的构造。Cloud foundry是基于ruby开发的，ruby相比之下比java开发的速度更快，这也是CF发展很快的原因之一把（原因之二，架构稳健，容易扩展）。如果把CF看作是大象，功能齐全，结构完整，那cloudify就是灵活的豹子，号称上手最快的平台。

       Cloudify是gigaspaces公司推出的基于java的paas平台。从语言习惯上看基于java的cloudify更贴近我们的开发习惯（其实我也愿意花点时间学点ruby或者groovy，赚点零花钱）。Gigaspaces是业界非常著名的paas提供商，也是高端产品XAP的厂家（eXtreme Application Platform，高端的Java 应用服务器）。有意思的是gigaspaces-cloudify-2.1.0-ga和gigaspaces-xap-premium-9.0.0-ga 的lib库是相同的。也就是说在同一个基本库的基础上开发了2套针对不同场景的应用。      

4.5.1            简单介绍

       Cloudify通过提供基于Groovy的领域特定语言，为创建部署脚本准备应用，同时基于out-of-the-box模式，从而推出云端Java元素，这个元素包括Apache服务器、Cassandra分布式数据库、Spring框架、XAP内存数据网格等。和CF相比，cloudify非常的精巧。那Cloudify提供了哪些功能呢：

• 在无需更改代码的情况下, 部署任何企业应用程序到任何虚拟环境
• 在云平台的应用程序提供企业级的生产环境:
  • 持续的可用性
  • 弹性和可扩展性
  • 完全自动化的部署
• 无与伦比的控制和可视化
  • 应用程序和群集感知的详细监测
• 无厂商锁定
  • 保持现有的软件开发方式和过程
  • 支持任何应用程序堆栈

 

1、基于资源定制的配置（Recipe-based configuration）:

       基于Groovy的领域特定语言，扩展和自定义很容易并直观，内部绑定了常用中间件组件，比如：JBoss, Tomcat, MySQL, Cassandra, MongoDB等。对于资源定制，CF有个概念：Droplet，指提交的源代码 + 配套好的运行环境 +管理脚本，在cloudify中这个概念被深化，Recipe包括的更多，包括应用生命周期脚本，服务的关联设定等。

 

 

 

图45-01： 内建的资源定制

2、通用服务适配器（USA，Universal Service Adapter）:

       该组件运行在每个节点上，并把recipe 在本地节点转化为动作来执行（比如安装，服务初始化，服务监控）。它可以被视为Cloudify的每个节点上的本地代表，只要在recipe文件中配置正确，不需要对服务进行特别管理（Tomcat, MySQL, Cassandra, JBoss, Apache with mod_php）。

 

3、插件式集群感知控制台（Pluggable cluster-aware monitoring）:

       监测框架是用来创建通用的监督协议插件集合（比如JMX, SNMP, JDBC/SQL）。USA激活在本地每个服务节点上的插件，然后插件连接到本地服务，并开始收集从它的信息。这些数据指标，会传递给Cloudify运行时环境，cloudify会根据recipe中的定义规则来控制系统的自动扩展能力，并通过各种用户接口暴露给用户。

 

4、移植性

       Cloudify 提供一个抽象能力功能：Cloud Driver，该层被设计成抽象方式来隔离我们的应用和云环境，并提供公用方法来集成了业界所有的主要云和虚拟机（采取的是jclouds的组件，支持业界众多的云环境）

       GigaSpaces Cloudify 已经集成了Microsoft Windows Azure 和 Amazon EC2 clouds，并且马上集成其他的云平台。 比如Citrix CloudStack，OpenStack，Rackspace，GoGrid，Citrix XenServer。

 

支持的IaaS平台

 

公开云	windows azure	amazon	rackspace	terremark	vmware vcloud
私有云	openstack	cloud.com	jcloud	eucalyptus	vmware vsphere

 

5、关键特征

 

	Any App, Any Stack	任何应用程序，任何堆栈 使用配方为基础机制, 部署任何中间件堆栈
	Automatic Self-Healing	自动自我修复 跟据配方定义, 宕机系统或机器能自动被新的取代
	Auto-Scale, Your Way	自动伸缩 根据框或自定的指标, 自动伸缩应用程序
	Any Cloud	任何云 支持所有主要的云计算和虚拟平台
	Automation of the Entire Life-Cycle	整个生命周期的自动化 使用一个单一的平台来部署, 管理和更新应用程序
	Cluster-Aware Monitoring & Management	群集感知的监控管理 可插拔的监控, 自定义的警报, 和应用程序感知的监视控制台
	Fully Testable on Your Laptop	在笔记本上就可以提供全套功能的云模拟环境：简单的开始，调试，测试。

 

l        版本功能

       虽然cloudify提供开源的是社区版本，一些高级功能（我们很想拥有的）并不提供，但这不妨碍我对cloudify敬意。除了CF，开源社区有了更多的选择，而且提供了新的思路和方式。CF也有2种版本，CF只是vmware的开源版本，vwmare也有商业版本。

 

功能	社区版功能	商业版本（技术层面）
Paas基础能力	任何语言任何技术栈	另外：大数据服务：Cassandra，MongoDB， 应用程序容器：Tomcat， Jboss，weblogic
部署结构	支持复合/多层结构的应用部署	同左
部署模式	连续部署支持	同左
Console控制台	交互式shell
负载均衡能力		动态负载均衡 / 动态HTTP负载均衡
高可用	高度可用的云控制器	同左
自我管理	自动自我修复	同左
监控	拓扑感知的监控和管理	同左
节点个数	无限制	同左
Cloud驱动	Amazon，Rackspace，Azure	还支持：OpenStack，vSphere，CloudStack
接口	Open cloud driver interface	同左
Api	Rich Management API	同左
源代码	社区版源代码和编译后的文件	不提供

4.5.2            总体架构

       Cloudify是基于java来实现的，在它的设计思想中，并没有一个paas平台的边界，而是把各种服务器理解为一个个的网格，然后有管理节点分别去关联计算节点，还是典型的C/S模式，这和它的设计它之前的XAP的设计理念一脉相承。

       这样的方式使得cloudify总工程很轻薄，但也具有相当的能力，抛去了硕大的PaaS支架的躯体，保留了paas最核心的本质。这种架构和之前的CF大相径庭，但这也是一种不错的思路，因为把这块撇给了DSL来定义，用人工定义的方式解决了服务和应用的定位和绑定功能，底层还是依赖iaas提供的对vm的控制能力，并把整体paas的管理功能封装在当前管理节点和与之相关的计算节点的管理。Cloudify抛弃了外壳，简化了架构，强化了DSL，终于换来了它轻盈的身姿。

 

 

 

图 45-02： Cloudify 体系结构

       在cloudify中，cloudcontrol处于绝对控制地位，解释dsl，调用jclouds，寻找合适的vm，根据规则部署应用，并对应用进行监控和管理。Cloudify cc和vm之间是有状态联系，这种关系和cf的无状态cc模式有极大的区别。

l         在cf中，cc是无状态的，可以有很多无状态CC节点，并通过一个消息机制和各个组件进行交互，其优势就是能构建巨大的云平台环境，从目前掌握的资料而言，一些公共开源云环境均采用这种模式，但结构复杂，运维和管理相对困难。

l         而在cloudify中，cc和vm/应用是有状态模式，这种方式劣势为不能管理数量众多的应用，优势是和vm/应用的关系很紧密，方便控制和管理，这点其实对于基于项目类型的云环境是有优势的，CC个数有限，每个CC对应N个vm/应用数量，分区画域，部署方便，管理容易。

4.5.3           组件说明

1.         dsl：脚本部署语言，解决部署依赖以及环境配置

 

 

 

图45-03：DSL描述（领域定义语言，用来部署云端应用）

 

2.         cli：提供基于console的客户端环境

 

 

 

图45-04：cli控制台（提供服务生命周期的管理）

 

3.         webui：提供for web的用户管理界面

 

 

 

图45-05：控制台界面

 

4.         usm：统一服务管理

5.         rest：对客户端提供基于rest的接口风格

6.         openapi：runtime的抽象层，用于2次开发使用

7.         runtime：核心包，实现agent,container，server manager

8.         jclouds：云端资源抽象层

 

4.5.4           业务流程

       Cloudify使用boostrapping进行管理，部署应用所需的服务机（vm或物理），安装需要提供的Cloudify组件。在Cloudify shell提示符运行相关的安装命令的时候初始化boostrapping。在一般来说，bootrapping的进程执行以下任务：

1.         在模板中定义中分配一台可用机器。有关模板的更多信息，参阅Cloudify驱动程序文件。

2.         连接到分配的机器通过SSH（* nix中）或WinRM的（WINDOWS）

3.         安装并启动相关的组件

 

       一旦的boostrapping连接到分配的机器，它上传来引导机器所需的文件。这些通常包括一个启动脚本和上传文件夹中的任何所需的文件，如SSH密钥文件。一旦文件被上传，有关bootstrap脚本运行。

       在启动cloudify的控制进程，Bootstrapping开始管理机器，并推出Cloudify agant。Cloudify代理程序激活Cloudify controller去使用服务实例节点的机器去安装或者扩展服务。

 

Cloudify管理机的配置

       当有关的云驱动程序接收到一个请求启动云，它执行以下任务：

1.         在管理节点模板定义中的资源池中，分配一台可用的机器（使用特定的cloud api）

2.         通过SSH（* nix中）或WinRM的（WINDOWS）连接到分配的机器。

3.         安装和开始的Cloudify的管理组件（Cloudify controller和cloud driver）

 

 

 

 

图45-06： Cloudify管理节点的调用时序

 

应用服务的配置

       当Cloudify controller接受请求去安装一个应用，就会要求cloud driver提供机器以便运行该应用所需的服务。为了获取到具体的节点，cloud driver需要行以下任务：

1.         在管理节点的模板定义中的资源池中，分配一台可用的机器（使用特定的cloud api）

2.         连接到分配的机器通过SSH（* nix中）或WinRM的（windows）

3.         安装和启动Cloudify agent

4.         启动服务的安装，使用有关服务​​的安装脚本

 

 

 

图45-07： Cloudify计算节点的调用时序

 

下面用一张图来示意cloudify的内部工作流程。

1.         用户提交写好recipe的应用，cc根据recipe的配置，通过cloud dirver寻找需要的vm。

2.         cloud diriver透过jclouds调用iaas api，通过iaas的计算服务得到新的vm。

3.         cc通过安装程序把agent部署在新的vm上，并执行一系列引导处理，使得该vm成为新的计算节点，并被cc所监控。

4.         透过计算节点的agent，安装应用，启动服务，新的节点启动完毕。

 

 

 

图45-08： cc启动应用服务

 

4.5.5           安装部署

 

       相对其他的paas平台来说，Cloudify的安装和配置较为简单，一般来说分为4个步骤：

l         配置底层云平台（Configure Clouds）

   每个云的实现是不同的。因此，为Cloudify工作与你的云，你可能需要配置您的云，如SSH安全方面。有关配置云提供商与Cloudify工作的信息，是指对有关主题，从下面的列表支持云： Azure，EC2，OpenStack，Traditional Data Center等。

 

l         创建云端镜像盘（Create Cloud Images）

   Cloudify在启动过程中需要配置机器的时候，就需要使用云端镜像。根据配置，由cloud service为某台机器创建特定的云端镜像盘，当然了镜像盘需要满足起码的最低要求。

   软件方面：

ü         每个镜像盘预必须安装JDK 1.6或更高，

ü         以及SSH守护进程必须启动并运行22端口；

   网络方面：

ü         在相同的服务，彼此之间的机器端口要开放；

ü         管理机和节点机之间的所有端口打开；

ü         管理虚拟机上，8099和8100端口必须是从互联网开放的沟通，通过虚拟机的公网IP地址。以便允许Cloudify shell与REST服务器交互，并允许用户访问管理Web应用程序。

 

l         配置云端驱动（Configure Cloud Drivers）

   Cloudify通过抽象层来屏蔽底层云平台的差异，所以在不同的云平台进行切换的时候，不必改变我们为应用写的资源定制（recipe）。但是在私有云上工作，需要在配置云端驱动之前额外做点工作。

 

1.         在私有云Cloudify分布文件存储。由于私有云经常断开与互联网连接，或者是加快Cloudify配置过程，cloudify推荐在本地存储Cloudify分发文件。分发文件引导Cloudify管理机时，使用的Cloudify云端驱动时安装上的应用机器Cloudify代理。一些私有云平台提供了存储服务，从中获取分发文件，在云端驱动的序配置文件中指定此服务的URI位置即可。如果使用Cloudstack，必须创建一个虚拟机上存储Cloudify的分发文件。

2.         需要创建镜像盘。Cloudify分发文件带有内置在Cloudify镜像盘。如果应用需要额外的图像，你可以创建它们使用私有云的控制台。

 

l         创建资源定制（Create Recipes）

       在部署应用程序之前，用Recipes对应用进行配置并部署

 

 

Cloudify的快速范例，参看《补充资料_cloudify快速上手.doc》

 

4.5.6           开发方式

 

参看《补充资料_Cloudify开发上手.doc》

 

4.5.7            后续工作