EMC中国研究院高级研究员 彭麟
今年4月份,VMware突然发布了业内第一个开源的PaaS——CloudFoundry。几个关键字:开源、PaaS、VMware,如果你对云计算感兴趣,就冲着它的ApacheV2协议,如果不去GitHub拿它的代码好好研读一下,真有点对不起自己。笔者当时就是以这样的心态去研究它的代码,并把它部署在我们labs里面。发布至今的这几个月里,笔者一直关注它的演进,并从它的架构设计中获益良多,觉得有必要写出来与大家分享一下。由于个人知识、认知等原因,其中有些看法难免不成熟,大家可以直接批评、指教。
本文会分为两个部份:第一部份主要介绍CloudFoundry的架构设计,从它所包含的模块介绍起,到各部份的消息流向,各模块如何协调合作;第二部份会在第一部份的基础上,以如何在你的数据中心里面用CloudFoundry部署一个私有PaaS为目标,把第一部分介绍到的架构知识使用起来。在本文,我不想简单的介绍如何使用CloudFoundry,这方面的文章,在SpringSource的官方博客里面有具体的介绍。如果需要这方面的介绍,笔者强烈建议到SpringSource或者CloudFoundry的官博找资料。另外,本文也不会具体介绍如何“贡献”Cloud Foundry,例如添加自己的Runtime,添加第三方的Service,这将会是两个很大的话题,以后我们会有专门的文章介绍,本文更多的算是入门级的架构介绍,可能会涉及到具体代码,但是只为更好地理解架构而服务。在第二部份,会简单介绍到如何用OrchestrationEngine来把CloudFoundry部署到IaaS上面,但是具体的实现方法将会放到介绍OrchestrationEngine的文章上面去,这里更多的是一种思想和BestPractice的分享。
第一部份讲的很多内容,会引用Pat在10月12日的VMwareCloud Forum上面关于CloudFoundry架构的演讲。Pat是CloudFoundry Core的负责人,他的那次演讲很值得一听。如果你当时在场,并且理解他所说的内容,本部份可以选择直接跳过。我除了会把说的内容讲具体点外,不太可能可以讲得比他好。
一、架构及模块
从总体地看,CloudFoundry的架构如下:
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dmgbe6ogebj.jpg)
这个架构图以及下文所用到的各模块架构图均来自Pat的PPT。从上图能够看到CloudFoundry主要有以下几大组件组成:
1、 Router:顾名思义,Router组件在CloudFoundry中是对所有进来的Request进行路由。进入Router的request主要有两类:首先是来自VMCClient或者STS的,由CloudFoundry使用者发出的,管理型指令。例如:列出你所有apps的vmcapps,提交一个apps等等。这类request会被路由到AppLife Management组件,又叫CloudController组件去;第二类是外界对你所部署的apps访问的request。这部份requests会被路由到Appexecution,又或者叫做DEAs的组件去。所有进入CloudFoundry系统的requests都会经过Router组件,看到这里可能会有朋友会担心Router成为单点,从而成为整个云的瓶颈。但是CloudFoundry作为云系统,其设计的核心就是去单点依赖,组件平行扩充,且可替代的以保证扩展性,这是CloudFoundry,甚至所有云计算系统的设计原则,后文会讨论CloudFoundry如何做到这点,目前只要知道,系统可以部署多个Routers共同处理进来的requests,但是Router上层的LoadBalance不在CloudFoundry的实现范围,CloudFoundry只保证所有的request是无状态的,这样就使上层均衡附载选择面非常非常大了,例如可以通过DNS做,也可以部署硬件的LoadBalancer,或者简单点,弄台ngnix作负载均衡器,都是可行的。
Router组件,目前版本是对nginx的一个简单封装。熟悉ngnix的朋友应该知道,它可以一个套接字文件(.sock文件)作为输入输出。所有安装CloudFoundry的Router组件服务器都会安装一个nginx,其ngnix.conf文件有以下配置:
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dmgbh0xa3fj.jpg)
从整体的来看,Router组件的结构如下:
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dmgbqbvur5j.jpg)
外界httprequest进入CloudFoundry服务器,nginx会首先接到request,nginx通过sock与router.rb进行交互,于是真正处理请求的是Router组件。router.rb里面根据传入的url,用户名密码等,进行逻辑判断,到CloudController组件或者DEA组件取数据并且返通过与niginx连接的.sock文件返回。router.rb是对nginx进行了逻辑封装。熟悉CloudFoundry的朋友肯定知道,CloudFoundry给每一个app分配了一个url访问,如果直接使用VMware所托管的CloudFoundry.com的话,那你的app的url可能就是xxx.cloudfoundry.com,无论通过命令给你的app扩展了多少个instances,都是从这个url访问的,这里面的url转换路由就是由router.rb实现的。
2、 DEA(Droplet Execution Agency): 首先要解析下什么叫做Droplet。Droplet在CloudFoundry的概念里面是指一个把你提交的源代码,以及CloudFoundry配套好的运行环境,再加上一些管理脚本,例如Start/Stop这些小脚本全部压缩好在一起的tar包。还有一个概念,叫做Stagingapp,就是指制作上面描述这个包,然后把它存储好的过程。CloudFoundry会自动保存这个Droplet,直到你start一个app的时候,一台部署了DEA模块的服务器会来拿一个Droplet的copy去运行。所以如果你扩展你的app到10个instances,那这个Droplet就被会复制十份,让10个DEA服务器拿去运行。
下图是DEA模块的架构图:
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dmgbr2nq1vj.jpg)
Cloud Controller模块(下面会介绍)会发送start/stop等基本的apps管理请求给DEA,dea.rb接收这些请求,然后从NFS里面找到合适的Droplet。前面说到Droplet其实是一个带有运行脚本的,带运行环境的tar包,DEA只需要把它拿过来解压,并即行里面的start脚本,就可以让这个app跑起来。到此,app算是可以访问,并start起来了,换句话说就是有这台服务器的某一个端口已经在待命,只要有request从这个端口进来,这个app就可以接收并返回正确的信息。接着dea.rb要做些善后的工作:1、把这个信息告诉Router模块。我们前面说到,所有进入CloudFoundry的requests都是由Router模块处理并转发的,包括用户对app的访问request,一个app起来后,需要告诉router,让它根据loadbalance等原则,把合适的request转进来,使这个app的instance能够干起活;2、一些统计性的工作,例如要把这个用户又新部署了一个app告诉CloudController,以作quota控制等;3、把运行信息告诉HealthManager模块,实时报告该app的instance运行情况。另外DEA还要负责部份对Droplet的查询工作,譬如,如果用户通过CloudController想查询一个app的log信息,那DEA需要从该Droplet里面取到log返回等等。
3、CloudController:CloudController是CloudFoundry的管理模块。主要工作包括:
a) 对apps的增删改读;
b) 启动、停止应用程序;
c) Staging apps(把apps打包成一个droplet);
d) 修改应用程序运行环境,包括instance、mem等等;
e) 管理service,包括service与app的绑定等;
f) Cloud环境的管理;
g) 修改Cloud的用户信息;
h) 查看Cloud Foundry,以及每一个app的log信息。
这似乎有点复杂,但简单的说,可以很简单:就是与VMC和STS交互的服务器端。VMC和STS与CloudFoundry通信采用的是restful接口,另一方面CloudController是一个典型的Rubyon Rails项目,从VMC或者STS接到JSON格式的协议,然后写入CloudController Database,并发消息到各模快去控制管理整个云。和其他ROR项目一样,CloudController的所有API可以从conf/routes.rb里看到。开放的Restful接口好处在于第三方应用开发和集成,企业在用CloudFoundry部署私有云的时候,可以通过这些接口来自动化控制管理整个Cloud环境。这部份内容将在第二部份论述。
下图是Cloud Controller的架构图:
![](http://ww3.sinaimg.cn/mw600/88ca09aajw1dmgbucgyz2j.jpg)
图中Health Manager和DEA是外部模块,CCDatabase就是CloudController Database,这个是整个CloudFoundry不能做HP的地方。CloudController Database的并发性不会很多,应用级别的数据库访问是由底下的Service模块处理的,这个数据库存的是Cloud的配置信息。读操作主要来自DEA启动,作为初始化DEA的依据;以及healthmanager模块会从这里读取预期的状态信息,这部份数据会与从DEA得到的实际状态信息进行比对。NFS是多个CloudController的共享存储,CloudController其中一个重要工作就是StagingApps。Droplets的存储是在集群环境的唯一的。而CloudController是集群运行,换言之,就是每一个控制Request可能由不同的CloudController处理,假设一个简单的用户场景:我们需要部署一个app到CloudFoundry中。我们在敲完那条简单的push命令后,VMC开始工作,在做完一轮的用户鉴权、查看所部署的apps数量是否超过预定数额,问了一堆相关app的问题后,需要发4个指令:
1.发一个POST到”apps”,创建一个app;
2.发一个PUT到”apps/:name/application”,上传app;
3.发一个GET到”apps/:name/”,取得app状态,看看是否已经启动;
4.如果没有启动,发一个PUT到”apps/:name/”,使其启动。
如果第2和第4步由不同的Cloud Controller来处理,而又无法保证他们能找到同一个Droplet,那第4步将会因为找不到对应的Droplet而启动失败。如何保证这一连串指令过来所指向的Droplet都是同一个呢?使用NFS,使CloudController共享存储是最简单的方法。但是这个方法在安全性等方面并不完美。在10月12日的VMwareCloud Forum上,Pat告诉我们下一版本的CloudFoundry这里将会有大调整,但是在那部份代码公开前,我不方便在这评价太多。
4、 HealthManager: 做的事情不复杂,简单的说是从各个DEA里面拿到运行信息,然后进行统计分析,报告等。统计数据会与CloudController的设定指标进行比对,并提供Alert等。HealthManager模块目前还不是十分完善,但是CloudManage栈里面,自动化health管理、分析是一个很重要的领域,而这方面可以扩展的地方也很多,结合OrchestrationEngine可以使云自管理、自预警;而与BI方面技术结合,可以统计运营情况,合理分配资源等。这方面CloudFoundry还在发展之中。
5、 Services:Cloud Foundry的Service模块从源代码控制上看就知道是一个独立的、可Plugin的模块,以方便第三方把自己的服务整合入CloudFoundry生态系统。在Github上看到service是与CloudFoundry Core项目vcap独立的一个repository,为vcap-service。Service模块其中设计原则是方便第三方服务提供商提供服务。在这方面CloudFoundry做得很成功,从Github上看,已经有以下服务提供:a)MongoDB; b) mysql; c) neo4j; d) PostgreSql; e) RabbitMQ; f) Redis; g)vBlob。基类都是放在base文件夹中。 第三方如果需要自己开发CloudFoundry的服务,需要继承改写它里面的两个基础类:Node和Gateway;而里面一些操作,如:Provision,可以在base的provisioner.rb基础上加入自己的逻辑,同样的还有Service_Error和Service_Message等。关于如何写自己的Service,ELC的博客会推出相应文章详细论述,并不在本文的讨论范围里面,从架构了解上来说,只要知道服务间的关系,知道个服务与base间透过继承关系来横向扩充,而CloudFoundry与apps调用Service是通过base来完成这一简单的架构方法即可。
6、 NATS(Message bus): 从CloudFoundry的总架构图看,位于各模块中心位置的是一个叫nats的组件。NATS是由CloudFoundry的架构师Derek开发的一个轻量级的,支持发布、订阅机制的消息系统。Github开源地址是:https://github.com/derekcollison/nats。其核心基于EventMachine开发,代码量不多,可以下载下来慢慢研究。CloudFoundry是一个多模块的分布式系统,支持模块自发现,错误自检,且模块间低耦合。其核心原理就是基于消息发布订阅机制。每个台服务器上的每个模块会根据自己的消息类别,向MessageBus发布多个消息主题;而同时也向自己需要交互的模块,按照需要的信息内容的消息主题订阅消息。譬如:一个DEA被加入CloudFoundry集群中,它需要向大家吼一下,以表明它已经准备好服务了,它会发布一个主题是”dea.start”的消息:
![](http://ww3.sinaimg.cn/mw600/88ca09aajw1dmgc7tbng2j.jpg)
@ hello_message_json中包括DEA的UUID,ip, port, 版本信息等内容。
再例如,CloudController需要启动一个Droplet的instance:
a) 首先一个DEA在启动的时候,会首先会对自己UUID的消息主题进行订阅。
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dmgc990xa1j.jpg)
其他模块需要通过’’dea.#{uuid}.start”这个主题发送消息来使它启动,一旦这个DEA接收到消息,就会触发process_dea_start(msg)这个方法来处理启动所需要的工作。
b) Cloud Controller或者其他模块发送消息,让UUID为xxx的DEA启动。
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dmgc9x3v6oj.jpg)
c) DEA模块接收到消息后,就会触发process_dea_start(msg)方法。msg是由其他模块发送过来的消息内容,包括:droplet_id,instance_index, service, runtime等内容,process_dea_start会取得这些启动DEA必须的信息,然后进行一系列操作,例如从NFS中取得Droplet,解压,修改必要环境配置,运行启动脚本等等。等一切都准备好后,然后需要给Router发个消息,告诉它这个Droplet已经随时准备好报效国家,以后有相应的request记得让它来处理。
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dmgcessdizj.jpg)
d) Router模块在启动时就已经订阅”router.register”消息主题。
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dmgcfbftntj.jpg)
收到前面DEA发出的信息后,会触发register_droplet方法,去绑定Droplet。到此启动一个Droplet的instance工作完成。
我们可以看到整个CloudFoundry的核心就是一套消息系统,如果想了解CloudFoundry的来龙去脉,去跟踪它里面复杂的消息机制是非常好的方法。另一方面,CloudFoundry是一套基于消息的分布式系统,面向消息的架构是它节点横向扩展,组件自发现等云特性的基础。
Cloud Foundry的架构简单介绍至此,其实作为第一款开源的PaaS,CloudFoundry架构有很多可以学习借鉴的地方,很多细节上的处理是很精妙的,这些内容如果有可能会在后续文章继续探讨,本文题虽为深入CloudFoundry,其实也只是浅尝即止,把总体架构介绍一下,目标在于使我们有足够的背景知识去用CloudFoundry搭建企业内部的私有PaaS。总结一下,笔者从CloudFoundry的结构中学到的东西:
1、 基于消息的多组件架构是实现集群的简单、且有效方法。消息可以使集群节点间解耦,使自注册,自发现这些在大规模数据中心中很重要的功能得到实现;
2、 适当的抽象层,模板模式的使用,方便第三方可以方便在CloudFoundry开发扩展功能。CloudFoundry在DEA及Service层都做了抽象层处理,相对应地使开发者可以容易地为CloudFoundry开发Runtime和Service。例如,在CloudFoundry刚推出的时候,只支持Node.js,Java, Ruby,但第三方提供商、开源社区快速跟进,为CloudFoundry添加了PHP,Python的支持。这得益于CloudFoundry精巧的DEA架构设计,如何开发新的Runtime支持,会在后续博文中有所论述.
二、源码导读
笔者一直觉得深入理解一个技术的最好方法就是读它的源码,而CloudFoundry是完全开源的PaaS平台,而因为刚发展起来,代码量不多,主要作者们的代码功力也相当不错,读起来很舒服,很适合研读。而不得不再次表扬一下它完全基于消息机制的架构设计,对组件扩展性,第三方接入等方面做得很好,读者可以从中学到不少思想性的东西。笔者很推荐大家去读一下它的源代码。你可以在Github上找到CloudFoundry的全部代码:https://github.com/cloudfoundry,你会看到几个不同的Repositories,它们分别是:
1、vcap: Cloud Foundry的Core,又或者称作Kernel;
2、vcap-service: Cloud Foundry的Service组件。Cloud Foundry的service是作为插件提供的,这出于它方便第三方开发service而设计的;
3、vmc: VMware Cloud CLI. 是一个Ruby应用,与Cloud Foundry的CLI交互。主要通过分析用户输入的CLI,向CloudFoundry发送Restful请求;
4、vcap-java: 如果你的app是用java开发,且需要与Cloud Foundry交互,例如取得当前serviceserver的ip地址等,你可能需要这个jar,里面对我们Java开发常用框架有所支持,它底层也是对CloudFoundry的Restful请求的包装;
5、vcap-java-client: Cloud Foundry的Restful API的Java封装,与上面的项目不一样,它只是个简单的读取CloudFoundry信息,并放如JavaBean中;
6、vcap-test: Cloud Foundry的test cases;
7、vcap-test-assets: Cloud Foundry一些apps示例。
本文第一部分介绍了CloudFoundry的整体架构,并在最后花了一点篇幅简介CloudFoundry的代码组织情况,以便于读者自己去研究源代码。笔者认为开源项目最大的好处在于:当你读懂源代码、理解总体架构后,能够成竹在胸,并吸收为己用(有点类似武侠小说中的“北冥神功”)。“为己用”就是本篇要说的内容:我们使用CloudFoundry搭建自己的私有PaaS平台。
在介绍CloudFoundry之前,先说明一下,VMware在企业云应用平台的产品线上,有另外一款产品,叫做VMwarevFabric Cloud Application Platfor[1],这和Cloud Foundry属于两个产品,分别由两批团队开发。相比较来说,选择vFabric会更令人省心省力,毕竟作为商业产品,完善很多,而且发展已久,和STS[2]深度整合。如果企业以应用为目的,不希望开发上面耗费太多人力物力,不妨考虑一下;如果选择Hard模式,打算以CloudFoundry为基础搭建私有云,那就开始吧!
第二部份 基于CloudFoundry的私有云实践本文内容所提到的CloudFoundry版本较早,,所以不可能一直紧跟着CloudFoundry的更新,造成有些内容并不是针对最新代码库,虽然我会比较新代码库来写这篇文章,但是请一定不要把本文当作按部就班的安装说明书。
去年10月份开始,CloudFoundry的主代码vcap里面新增加了个目录叫做dev_setup,Cloud Foundry大方地公开了他们的部署代码,这样大大简化了我们把CloudFoundry部署在自建数据中心的难度。如之前Figo在VMwareCloud Forum提到的一样,CloudFoundry官方用Chef[3]作为部署工具 。Chef是OrchestrationEngine的一种,可以自动化管理、部署复杂的云环境。工作过程大概就是我们需要写一系列的“recipes”,这些“recipes”描述我们需要把我们的服务器部署成什么(Apache,Mysql还是Hadoop?),然后Chef可以自己执行这些配置。现在数据中心变得越来越庞大,原来那种通过自己写脚本完成自动部署的IT管理方式日渐不堪重负,帮助管理、部署数据中心服务器集群的中间件变得越来越重要,我们统称这类型工具为OrchestrationEngine.
回到正题,如果使用了新版的CloudFoundry,可以参考dev_setup目录和dev_setup/deployments目录下面的两个README文件。基本上使用提供的脚本来部署不同的CloudFoundry组件就是一条命令的事情。
但是既然我们命题为深入CloudFoundry,那就必须深入地了解整个CloudFoundry的部署过程。 在这之前让我们先回顾第一部分里面的CloudFoundry总体架构图:
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowh8jk1acj.jpg)
从图1中可以看出两点:
1、 CloudFoundry是完全模块化的设计,每个模块单独存在、运转。CloudFoundry是基于Ruby开发的,那每个部分可以认为拿来即可运行,不存在编译等过程;
2、 我们需要配置换的应该是图中的箭头部分。换句话说就是如何把每个模块连接起来,使其成为一个完整的、分布式的系统。这点就是我们现在要做的事情。
如果你是用:
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowhaahmy2j.jpg)
安装的CloudFoundry,那你的系统里面就应该包含了所有的子模块。
DEA, Health_Manager, Router这三个模块,代码结构比较接近:都有一个bin目录,毫无疑问里面就是可执行文件,但是打开着个文件会发现它只是个简单的link,真正的执行文件在lib下面,有对应的rb文件;而这几个模块的根目录下面都有一个config目录,里面有以模块命名的yml文件,这就是他们的配置文件。
而cloud_controller模块,之前已经说过它是个典型的RoR项目,里面的文件结构有点复杂,文件有点多,但是还是能找到config/cloud_controller.yml这个文件的;
接着就是service模块,这里会看到很多似曾相识的子目录,比如mysql,redis, rabbit, mongodb。专业人士一看就知道是不同的服务,每个服务一个文件夹,点进这些目录看,又看到熟悉的结构了,比如bin,config, lib,很简单,和前面的DEA,Router等模块的结构一样。但是打开bin后,发现执行文件有点多,有个gateway,还有个node。(如果你是新的代码库,可能还看到个backup,顾名思义就是配置service备份工作的,不难理解,这里就不叙述了)
我们来聊聊Service模块的gateway和node。Gateway在一个servicenode里面负责处理restfulapi的相关事情,负责读入并初始化messagebus。Node是service的具体执行者,包括响应message,与底层service的交互等等。但是从配置文件来说,因为gateway负责解析初始化messagebus,所以与messagebus相关的配置信息反而放在了xxx_gateway.yml里面;而xxx_node.yml则是一些关于底层配置的信息,拿mysql_node.yml来说,就是一些max_long_query,max_long_tx这些信息。
如果我们要架构分布式的云环境,不应该选择在一台服务器里面安装所有的模块,下面简单介绍下做法:
通过研究源代码,我们知道CloudFoundry的主安装文件vcap_setup里是可以选择安装哪些组件的。所以安装全部组件应该是install这个脚本搞的鬼,我们去看看install[4]里面做了什么?
通过略读install脚本,发现它不难理解,且每一个步骤都有一个echo来说明。它分别做了以下动作:
1、 检测是否是Linux或者MacOS环境;
2、 安装依赖包;
3、 安装并启动RVM;
4、 安装Ruby;
5、 下载vcap;
6、 安装配置vcap;
7、 重启Nginx;
8、 安装Bundler。
其中注意这一行命令:
![](http://ww4.sinaimg.cn/mw600/88ca09aajw1dowhbki23lj.jpg)
这里面的参数–a与-s。在vcap_setup的comments里面有如下定义,
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowhcd69erj.jpg)
也就是说,install脚本为了省去安装时的提问过程,剥夺了我们的自主选择权!那么解决方法就简单了——把这句改了,然后执行install,我们应该能看到安装脚本询问要不要安装Router?要不要安装CloudController?同样的,因为去掉了-s参数,所以在安装过程中会提示需要安装的Service类型。
下面是我们实验室中服务器的具体配置图,
![](http://ww4.sinaimg.cn/mw600/88ca09aajw1dowhcxpugbj.jpg)
Figure 2 Cloud Foundry 在ELC 实验室中的部署图
首先,我们手上没有硬件LoadBalancer,而且为了节约ip资源,我们决定只用一个外部ip,使用桥接,然后用Ngnix来做loadbalancer,所有的requests会转向4台Router。
我建议Router宜多一点,因为CloudFoundry当前的设计,Router的资源会很紧张,但是如第一部分说到那样,这问题会在以后的版本改善。目前还是多加点Router服务器吧。
然后CloudController我们用了3台,并且这三台也同时兼了Health_Manager的功能,因为CloudController主管的是控制流,资源占用不会太大。我一开始也觉得CloudController会很耗资源,因为从上一部分的工作描述来看,它负责的工作还是比较多的,但实际应用下来,结果和笔者想的相差很远。这部分需要的资源其实并不多,可能因为我们不是经常需要启动/关闭/删除instance。
后面是一个单独的数据库服务器。在生产环境里用的是postgresql,用其他也是可以的,在cloud_controller.yml里面修改就好。这是整套系统的单点,我也一度担心过,但据说CloudFoundry.com用的也是单点数据库,没存在太大问题。据说CloudFoundry在设计的时候已经注意到这里的数据流量问题。
接着是5台服务器用于Health-Manger,其中3台与CloudController公用。因为我希望多检测一点数据,用于后面的管理,所以在这里狠下了心。
DEA模块,也是5台服务器。这里算是app的主场,建议根据资源需求动态增加,CloudFoundry有很好的扩展性设计,如果某一模块吃不消了,都可以动态添加。
Service模块,同样给了5台。我们目前只用到Mysql,Postgresql和MongoDB。同样按照项目需要来加。其他Service暂时还没用上。
接着就是贯穿这套系统的MessageBus模块。CloudFoundry的所有模块都需要指定到这个MessageBus。它是基于NATS的,轻量级,很好用,但是有个问题是不支持HA/HP集群,也就是说无法配成多台Messagebus hosts。这部份据说正在开发,而既然CloudFoundry.com都能应付得了,我们私有云,一台server,应该足矣!
后面我们选几个模块看看具体的配置修改:
1. /etc/nginx/nginx.conf前面说到,我们用一台nginx来作为loadbalancer。我们整个服务器集群用的是虚拟机,这台虚拟机配双网卡,分别设为privatenetwork和vmnetwork,两网卡间采用桥接。这台服务器有双ip:10.32.105.165和192.168.1.178。我们进入这台机器,选择Nginx的一个原因是,只要安装CloudFoundry,因为Router组件是基于Nginx的,所以都会安装这个HttpServer,减少了我的工作。配置Nginx没什么特殊之处,我用了最简单的方法,设置一个upstream,采用RR来均衡负载。
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dowhfxl9waj.jpg)
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dowhh3k40vj.jpg)
Load balancer出来的request就会流到Router组件,Router.yml的配置相当简单:
![](http://ww3.sinaimg.cn/mw600/88ca09aajw1dowhj6mifgj.jpg)
唯一需要改的只有mbus,就是把mbus指到我们的mbus服务器去。
3. cloud_controller.ymlCloud_controller.yml看起来相当复杂,我们可以选择需要的配置修改:
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowhknn9xvj.jpg)
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dowhlxjfr8j.jpg)
按照配置文件里面的介绍,说这个可以不修改,默认为nil,我配置成了CloudController的ServerIp,用起来没出问题。
接着有两个重要的配置:
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dowhmo23e8j.jpg)
这两个目录是关于用户上传的apps(在Cloud Foundry里叫做Droplets),以及相关资源的目录。上一部分说到,在CloudController的当前实现,是采用一个NFS来存储这些Droplets,使它全局唯一。所以我们在此之前,需要建立一个NFS,并且每个安装Cloud_Controller的服务器把这个NFSmount到/var/vcap/shared下。这点非常非常重要,否则会出现上文说的启动失败问题!
接下去,我们需要配一个,所有CloudFoundry组件都要配置的内容,mbus:
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dowi0fz640j.jpg)
后面有很长的一段是关于Rails的环境配置,这里就不啰嗦这些内容了。再往后,有一些单个账户资源限制问题,可以留意一下:
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowi0sd5vbj.jpg)
4. health_manager.yml
接下去就该配置health_manager.yml。一开始看到的就是两个所有模块都要修改的内容,local_route和mbus:
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowi15smlnj.jpg)
Local_route还是填本机的ip,mbus填的都一样,就是mbus服务器的ip和端口。
然后,从本文第一部分所描述的health_manager的职责可知道,该模块和CloudController数据库有交互,所以需要配置database_enviroment信息。这部份需要和CloudController吻合。
health_manager.yml还有一些关于healthcheck频率等的配置,这部份可以选择不用修改。如果需要具体定制,可以参考yml文件中的comments。
5. DEA.yml一如既往地需要修改local_route和mbus。
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowi1fnjvoj.jpg)
这里有一个配置需要注意一下:
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowi1owrp2j.jpg)
DEA模块会自己host一个thin服务器用来处理发送到以下URL的请求,让用户可以直接访问到app的files。
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowi1xo2kbj.jpg)
换句话说,如果需要自己开发一些应用对app进行文件级管理的话,可以通过上面这个URL。另外,这个URL也是我们访问app文件的一个选择。或者我们可以从CloudContorller的API进入也是可以的,后面关于如何管理我们搭建的私有云时,会讨论到这个话题:
![](http://ww1.sinaimg.cn/mw600/88ca09aajw1dowi2f5ibsj.jpg)
除此之外,其它配置如果没有特殊要求,可以保持默认。
6. Service层配置在Service层,每种service的配置都略有不同,但是大同小异,需要修改的地方也不多。在这里,我举Mysql为例子。和所有的Service一样,mysql分为了两个配置文件(最新版本会多一个backup,共三个):mysql_gateway.yml和mysql_node.yml。
对于mysql_gateway.yml,需要改的,只有:
host: 192.168.1.193
和
mbus: nats:// 192.168.1.177:4222
对于mysql_node.yml,这里比较多的是mysql调优参数,按照需要修改。但同样有两处需要修改:
Ip_route: 192.168.1.193
和
mbus: nats:// 192.168.1.177:4222
到此为止,所有的安装配置完成。如果一切顺利的话,重新启动component后,CloudFoundry应该就可以用了。再强调一次,这篇博客并不是一个可按部就班的安装指南。CloudFoundry在一直发展,代码变动很大。如果不指定某一版本,很难保证所写就一定适合。我觉得更多的应该是在通读本文第一部分后,对CloudFoundry的整体架构有个了解,然后前面的描述可以看作是一些可具体理解CloudFoundry的切入点。通过去修改配置文件,保证系统如第一部份描述那样来运转。
CloudFoundry的架构并不复杂,其主要思想就是messagebus的配置,使异构的、分布式的组件可以互相通信合作。我浏览了下CloudFoundry的最新代码,很多新增配置配置是控制component如何运转的配置,保持默认状态即可。如果大家在配置过程中有什么问题,很欢迎直接@我的微博(@Layne_Peng)进行讨论,我会尽量帮忙。
二、下一步?要搭建一个完整的私有云系统,还有很多缺少的地方,譬如下层的IaaS如何集成?如果CloudFoundry一个组件负载过高,应该如何扩容?能否做到自动化?如何检测、管理CloudFoundry的服务器集群?这些都是需要解决的问题。
首先,CloudFoundry是与底层IaaS无关的,我们可以用vSphere或者OpenStack来作为IaaS方案。为了实现云计算的可伸缩性,IaaS层需要提供如下两个功能:
1、 当CloudFoundry某些组件的发出性能警报,或者到达我们设定的某些指标时,我们需要用IaaS创建部署该组件的虚拟机,并把它启动加入CloudFoundry集群中(由OrchestrationEngine来做);
2、 当某些组件有大量资源盈余,而物理资源出现紧张情况的时候,IaaS需要删除虚拟机,把计算资源归还到资源库;
3、 IaaS需要提供虚拟机的注册、存储、查找、导入、启动等功能。
而OrchestrationEngine在我们Lab中负责把由IaaS导入并已经启动的虚拟机,按照前面章节介绍的“安装配置CloudFoundry”配置好,以保证新加入的虚拟机资源可以被CloudFoundry使用。
我们的私有云有了IaaS和PaaS,有了自动化管理工具(也就是OrchestrationEngine),但中间还缺少监控管理工具。有了监控管理工具,我们才可以知道现在CloudFoundry每个服务器的资源使用情况,才可以向IaaS请求计算资源。这一块要做得非常完善并不容易,但是我们可以按照我们的需要,去做一些必需的。实现自己的监管工具,第一件要做的事就是认识CloudFoundry提供的API,以便我们获得PaaS的运行信息。
前面多次提及,CloudFoundry的管理是由CloudController负责,并对外提供RestfulAPI,供VMC和STS使用。另外,CloudController是典型的RoR项目,所以我们需要的一切API都可以在vcap/cloud_controller/Router.rb文件找到。
打开Router.rb文件,我们可以发现这里基本可以得到部署在CloudFoundry上apps和services所有信息,包括app的统计信息、app的crashlogs、service node所提供的服务、servicenode的资源情况等等。再配合Linux本身的一些基本命令,我们可以知道服务器节点的资源情况。
另外,我们在Router.rb还能发现以下API,
![](http://ww3.sinaimg.cn/mw600/88ca09aajw1dowi2u3tfrj.jpg)
通过它们,我们可以拿到每个apps的所有file文件。也就是说,我们可以拿到Webserver(假设是Java的instance,那WebServer就是Tomcat)的logfiles。通过分析这些logfiles,我们可以得到目前部署在我们PaaS上的app运行情况。
这里面的话题很多,可以发挥的地方也很大。我是先分析Router.rb可以提供哪些信息,然后觉得哪些比较有价值,可以联系到我们业务的哪些需要,来设计的。分析这些API的比较好办法就是直接Query这些API,然后看看返回数据。
我用的是Chrome浏览器,只需要装个AdvancedREST client插件,我们就可以直接访问这些RestAPI了。访问大部份CloudFoundry的RestfulAPI,都首先需要拿到授权Token,我这里直接用http://api.cloudfoundry.com为例。
我们用VMC的时候,先需要把Target设定为http://api.cloudfoundry.com,这一步其实就是给VMC设定了Restful的访问BaseURL,属于本地操作。
第二步就是执行login,并输入email和password,我们可以通过研究VMC的源代码,或者直接看VCap源代码,得知,这个login其实是发向:
post 'users/*email/tokens' => 'user_tokens#create', :as => :create_token
所以,我们可以用AdvancedREST client往上面的URL发送POST请求,并把email和password的JSON格式放到Body里面,
![](http://ww4.sinaimg.cn/mw600/88ca09aajw1dowi38hjjfj.jpg)
从服务器返回了一串Token,这就是我们需要拿到的授权Token,后面的所有操作都需要用到。
接着我们就可以慢慢尝试CloudController能为我们提供什么信息了。举个最简单的例子,我想看当前email账户下的所有apps列表,只需要把以上的Token放到请求的header里面,并把name设为AUTHORIZATION,然后GET http:// api.cloudfoundry.com/apps:
![](http://ww4.sinaimg.cn/mw600/88ca09aajw1dowi47e8pcj.jpg)
返回信息就是该账户下所有的apps列表:
![](http://ww4.sinaimg.cn/mw600/88ca09aajw1dowi4eif2xj.jpg)
从这里可以得到这个用户的apps的一些基本情况,包括appname、url、所使用的技术、instance数目、资源情况等等。
再举一个简单的例子,如果我想做一个Portal列出部署在我的PaaS里面的所有应用,这个API或许可以派上用场。
开发一个完善的PaaS不是我们研究院的主要任务,而且搭建一个私有云需要大量的开发量,我只是简单实现了一小部分。如果真打算搭建私有云平台,要做的工作还有很多。譬如ActiveState就基于CloudFoundry,做了一个商业版的PaaS,叫做Stackato[5],它们也是在Monitor和Manage上面做了很多工作,值得参考一下。
结束语上下两部分的深入CloudFoundry到这里就写完了。虽然命名为深入,其实很多地方只是简单带过,对CloudFoundry的分析也只到架构一层,还有很多内容可以挖掘,譬如开发自己的Runtime,嵌入新的Service等等,以后如果必要,我可以再写文章聊聊相关内容。第二部分简单介绍了CloudFoundry的安装,以及我们实验室里面的使用,希望对大家有帮助。
Cloud Foundry作为业内第一个开源的PaaS,我觉得它给我们打开了一扇研究云计算环境下平台架构设计的窗户,我相信围绕它的周边开发会有一片很大的空间可以让开源界进入,这篇文章只不过是抛砖引玉。
关于作者
![](http://ww2.sinaimg.cn/mw600/88ca09aajw1dowi5vbwjij.jpg)
彭麟,EMC中国研究院高级研究员,关注云计算平台架构设计、分布式计算原理等领域。
微博:http://www.weibo.com/laynepeng
Reference:
[1]http://www.vmware.com/products/vfabric
[2]SpringSource Tool Suite: http://www.springsource.com/developer/sts
[3]http://www.opscode.com/chef
[4]https://raw.github.com/CloudFoundry/vcap/master/setup/install
原文:http://qing.weibo.com/2294942122/88ca09aa330004r8.html http://qing.weibo.com/2294942122/88ca09aa33000975.html