cloud foundry预研.doc

Cloud foundry PaaS平台预研1.Cloud Foundry介绍2.Cloud Foundry的架构分析和功能介绍3.Cloud Foundry总结1. Cloud Foundry介绍 全球虚拟化和云计算基础设施领导厂商VMware近日推出了首款开放PaaS平台Cloud Foundry。作为新一代云应用平台，Cloud Foundry专门服务于云计算环境、企业级数据中心和公有云服务提供商。Cloud Foundry通过集成各种开发和部署环境可以简化现代应用程序的开发、交付和应用过程，在面对多种共有云和私有云选择、符合业界标准的高效开发框架以及应用基础设施服务时，可以显著提高开发者在云环境中部署和运行应用程序的能力。Cloud Foundry作为一个开源的PaaS平台，它的特点主要如下：u 通过Cloud Foundry平台，开发人员可以建立和测试自己的应用程序，提高开发开发的效率，同时又可以保证开发环境和生产环境的一致性；u Cloud Foundry平台 能够广泛支持各种开发框架和编程语言以及多样的应用服务和云部署环境 。Cloud Foundry支持多种流行高效的编程框架，包括Spring for Java、Ruby on Rails、Sinatra for Ruby、Node.js和.net框架，也支持其他基于JVM的框架，例如Grails。Cloud Foundry还支持多种应用服务，包括MySQL、MongoDB、Redis以及VMware自己的vFabric应用服务。 u Cloud Foundry还可以交付高度的便携性，使开发者能够在云服务提供商和企业级数据中心之间自由移动自己的应用； u Cloud Foundry能够部署在私有云或公有云的环境中，既可以运行在vSphere和vCloud架构之上，也可以运行在其他云架构之上。例如：Cloud Foundry可以部署在Amazon Web服务之上，还可以部署在Eucalyptus和OpenStack等开源平台技术之上。 2. Cloud Foundry的架构分析和功能介绍 从总体上看，Cloud Foundry的架构如下图2-1所示：图2-1 Cloud Foundry的架构图 从图2-1的架构图可以看出CloudFoundry的主要有以下几大构件：2.1Router Router在Cloud Foundry中对所有的进入的Requsts进行路由。进入Router的Requsts主要分为两类：n 来自VMCClient或者STS的，由CloudFoundry使用者发出的，管理型指令，例如：列出你所有apps的vmcapps，提交一个apps等等。n 外界对你所部署的apps访问的request 针对以上两种Requsts，Router分别作出不同的反应。对于来自VMCClient或者STS的Requsts，Router将其路由至AppLife Management组件（又名：CloudController组件）；对于外界访问apps的Requsts，Router将其路由至Appexecution（又名：DEAs的组件）。由于所有的请求都需要Router组件，会造成很大的性能问题和单点失效问题，成为整个云的瓶颈。Cloud Foundry解决这个性能和失效问题的方法主要如下：l 系统允许部署多个Router组件共同处理进入Router的Requsts，但是Router上层的LoadBalance不在CloudFoundry的实现范围，CloudFoundry只保证所有的request是无状态的，这样就使上层均衡附载选择面非常非常大了，例如可以通过DNS做，也可以部署硬件的LoadBalancer，或者简单点，弄台ngnix作负载均衡器，都是可行的。l 新版的Router组件将逻辑和数据完美的分离，不再经过Router转发大量的数据，从而提高了Router组件的性能和稳定性。具体改变如下图2-2所示 图2-2 Router组件的内部逻辑在新版本的设计中，他们使用Lua脚本来代替原先的Ruby脚本。而Lua脚本会对请求加以分析，转发给Ruby程序，然后Ruby程序再将分析的结果返回。这样一来，proxied request已经不再经过Ruby代码。逻辑和数据完美分离。性能和稳定性都大幅提高了。在前版设计中，当Router接收到请求后，会随机分配一个Droplet来处理这个请求，这种方式使得用户没有办法使用Session，因为连续的HTTP请求会被分发到不同的应用实例上处理。外界httprequest进入CloudFoundry服务器，nginx会首先接到request，nginx通过sock与router.rb进行交互，于是真正处理请求的是Router组件。router.rb里面根据传入的url，用户名密码等，进行逻辑判断，到CloudController组件或者DEA组件取数据并且返通过与niginx连接的.sock文件返回。router.rb是对nginx进行了逻辑封装。 新版本设计中增加了对SESSION的支持，当Router发现用户的请求中带了cookie信息，它会在Cookie里暗藏一个Droplet的host,port地址。当有新的请求进来，Router通过解析Cookie得到上次的应用实例，然后尽量转发到同一台Droplet上。2.2 DEA（Droplet Execution Agency）Droplet在CloudFoundry的概念里面是指一个把你提交的源代码，以及CloudFoundry配套好的运行环境，再加上一些管理脚本，例如Start/Stop这些小脚本全部压缩好在一起的tar包。Stagingapp，就是指制作上面描述这个包，然后把它存储好的过程。这两个概念在DEA中时相当重要的。CloudFoundry会自动保存这个Droplet，当运行一个app应用时，一台部署了DEA模块的服务器会来拿一个Droplet的copy去运行。 DEA的架构图图2-3所示： 图2-3 DEA的架构图Cloud Controller模块（下面会介绍）会发送start/stop等基本的apps管理请求给DEA，dea.rb接收这些请求，然后从NFS里面找到合适的Droplet。前面说到Droplet其实是一个带有运行脚本的，带运行环境的tar包，DEA只需要把它拿过来解压，并即行里面的start脚本，就可以让这个app跑起来。到此，app算是可以访问，并start起来了，换句话说就是有这台服务器的某一个端口已经在待命，只要有request从这个端口进来，这个app就可以接收并返回正确的信息。接着dea.rb要做些善后的工作：u 把这个信息告诉Router模块。我们前面说到，所有进入CloudFoundry的requests都是由Router模块处理并转发的，包括用户对app的访问request，一个app起来后，需要告诉router，让它根据loadbalance等原则，把合适的request转进来，由这个app的instance进行响应。u 一些统计性的工作，例如要把这个用户新部署了一个app告诉CloudController，以作quota控制等。u 把运行信息告诉HealthManager模块，实时报告该app的instance运行情况。u DEA还要负责部份对Droplet的查询工作，譬如，如果用户通过CloudController想查询一个app的log信息，那DEA需要从该Droplet里面取到log返回等等。2.3 CloudController CloudController是CloudFoundry的管理模块。主要工作包括： n 对apps的增删改读；n 启动、停止应用程序；n Staging apps（把apps打包成一个droplet）；n 修改应用程序运行环境，包括instance、mem等等；n 管理service，包括service与app的绑定等；n Cloud环境的管理；n 修改Cloud的用户信息；n 查看Cloud Foundry，以及每一个app的log信息。VMC和STS与CloudFoundry通信采用的是restful接口，另一方面CloudController是一个典型的Rubyon Rails项目，从VMC或者STS接到JSON格式的协议，然后写入CloudController Database，并发消息到各模快去控制管理整个云。和其他ROR项目一样，CloudController的所有API可以从conf/routes.rb里看到。开放的Restful接口好处在于第三方应用开发和集成，企业在用CloudFoundry部署私有云的时候，可以通过这些接口来自动化控制管理整个Cloud环境。 CloudController的架构图如图2-4所示： 图2-4 CloudController的架构图图2-4中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个指令： l 发一个POST到”apps”，创建一个app;l 发一个PUT到”apps/:name/application”，上传app;l 发一个GET到”apps/:name/”，取得app状态，看看是否已经启动；l 如果没有启动，发一个PUT到”apps/:name/”，使其启动。如果第2和第4步由不同的Cloud Controller来处理，而又无法保证他们能找到同一个Droplet，那第4步将会因为找不到对应的Droplet而启动失败。使用NFS可以保证这一连串指令过来所指向的Droplet都是同一个，使CloudController共享存储是最简单的方法。但是这个方法在安全性等方面并不完美。2.4 HealthManager 它主要负责从各个DEA里面拿到运行信息，然后进行统计分析，报告等。统计数据会与CloudController的设定指标进行比对，并提供Alert等。HealthManager模块目前还不是十分完善，但是CloudManage栈里面，自动化health管理、分析是一个很重要的领域，而这方面可以扩展的地方也很多，结合OrchestrationEngine可以使云自管理、自预警；而与BI方面技术结合，可以统计运营情况，合理分配资源等。这方面CloudFoundry还在发展之中。2.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等。从架构了解上来说，只要知道服务间的关系，知道个服务与base间透过继承关系来横向扩充，而CloudFoundry与apps调用Service是通过base来完成这一简单的架构方法即可。 2.6 NATS(Message bus) 从CloudFoundry的总架构图看，位于各模块中心位置的是一个叫nats的组件。NATS是由CloudFoundry的架构师Derek开发的一个轻量级的，支持发布、订阅机制的消息系统。Github开源地址是：