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            後續工作


發佈了32 篇原創文章 · 獲贊 3 · 訪問量 52萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章