一種開放的可互操作的雲

由 webmaster 在 四, 2011/12/29 - 20:18 發表

 

介紹

在這篇文章中我們會描述:在當下,怎麼樣通過利用成熟的開放標準(特定於雲計算、網格與存儲領域)創建具有可互操作性的雲。我們會演示使用一些最新的具有創新性的主要雲計算接口規範來實現一個開放的、基於標準的、具備可互操作性的雲計算服務實例。

寫作這篇文章的動機是為了說明這樣一個事實,即當前由各種標准開發組織(SDO)提供的可用的雲計算標準特性已經足夠用於開發一個雲計算服務實例,而這一點將在下面的章節中得到證明。這篇文章可以被視作探索雲計算標準集成的工作的最初環節中的一個步驟,尤其是開放雲計算接口(OCCI) [1]、開放虛擬化格式(OVF)[4]以及CDMI [3]之間的集成。最後但很重要的是,在這篇文章裡所討論的詳細內容能夠驅動OCCI和雲管理工作組(CMWG)[10],以及其他一些工作組織之間的協作,例如:cloud-standards.org、面向E基礎設施的標準和互操作性推進組織(SIENA)[5]、國家標準與技術研究所(NIST) [6]等等。

為了描述怎麼能夠做到這種標準的集成,我們會以一個簡單的情景為例。在這個情景中,設想有一個剛起步的服務提供商希望部署、擴充、移植以及重新部署他們新的基於Hadoop [7]的MapReduce服務。

為了實現並能夠執行這個情景,使用了下面所列用得到的標準:

  1. 來自DMTF的OVF ——提供了一種能夠打包開發虛擬基礎設施的方法,這樣開發成果可以導出或者導入到一個基礎設施服務實例中。
  2. 來自SNIA的CDMI ——提供了一種API,可以用於對存儲基礎設施服務實例進行運行時管理。
  3. 來自OGF的OCCI ——提供了一種API,可以用於對基礎設施即服務實例進行運行時管理。

需要指出的是,其他一些方面的問題如授權與驗證等在這篇文章裡沒有涉及。這些問題可以說屬於另一個維度,有其他的規範與技術(如OAuth、OpenID等)來對應。OCCI和CDMI借鑒了HTTP協議組中關於安全方面的設計思路。

情景

這個情景是關於一個新起步的公司,他們希望為他們的客戶提供MapReduce服務。由於是新服務,它將僅對一些限定的試用用戶開放。基於這樣的限制的前提,這個新公司的架構師設計了一個初步的開發架構,以滿足服務所需的起始資源需求。服務的這個部署架構如圖所示:

 

服務一旦部署後,用戶數就要求服務必須要進行擴充。這意味著必須要在不下線的情況添加額外的資源來滿足需求。除了擴充,我們認為這個情景中也必須要考慮移植的情況。在基礎設施提供商遭受嚴重的中斷的時候,新公司被迫遷移服務。而這就是這個情景的最後一個情節,也就是服務提供商把整個開發移到一個新的更合適的基礎設施供應商的平台上。

這個情景包括兩個明顯的階段:

  1. 服務開發與擴充
  2. 服務遷移與重新部署

其中每個階段各包括若干步驟,它們都會在下面詳細展開,以介紹其中用到的標準。

起步階段的總體目標是利用基礎設施供應商的CDMI與OCCI接口,並向供應商提供其能夠理解的OVF服務描述。正是這些供應商提供的能力讓新公司獲得了可互操作性。

服務部署與擴充

要進行如上圖所示的最初開發並說明如何進行擴充,將使用OCCI和CDMI。這個階段又由下列步驟組成:

  1. 基於服務架構進行最初開發,其中將使用OCCI和CDMI,或者是從OVF導入。
  2. 一旦服務足夠成熟,用戶增加,擴充服務開發而使用OCCI可以做到漸增式擴充。

下圖表示了在使用上述管理API時這個新服務的部署方式。

進行最初的開發

在這個時間點上,目標是基於設計好的架構進行最初的服務開發,這樣就可以提供給試用用戶。總的來說,如上圖所示的搭建服務的過程分為下列步驟:

  1. 建立內部/私有基礎設施
        a.上傳可以運行的虛擬機映像(包括三個:門戶、Hadoop主服務器與從服務器)
                i.上傳虛擬機映像到雲供應商。這樣就有了一個CDMI管理端點
                ii.把這個虛擬機映像註冊成OCCI操作系統模板
        b.建立私有網絡
                i.使用OCCI的IPNetWork Mixin(192.168.0.1/24)
        c.建立存儲卷A(5GB)
                i .使用CDMI接口來完成上述任務
        d.建立存儲卷B(100GB)
                i.使用CDMI接口來完成上述任務
        e.建立Hadoop主服務器節點
                i.使用Hadoop主模板與OCCI計算類請求
                ii.使用OCCI的StorageLink來連接到存儲A(使用CDMI標識符來把CDMI資源關聯到OCCI資源)
        f.建立Hadoop從服務器節點
                i.使用Hadoop主模板與OCCI計算類請求
                ii.使用OCCI的StorageLink來連接到存儲B(使用CDMI標識符來把CDMI資源關聯到OCCI資源)
        g.連接主節點到私有網絡
                i.使用OCCI的IPNetworkInterface 
        h.連接從節點到私有網絡
                i.Use OCCI的IPNetworkInterface
  2. 建立外部/公開基礎設施
        a.建立門戶節點
                i.使用門戶操作系統模板與OCCI計算類請求
        b.連接門戶節點到私有網絡
        c.連接門戶節點到公開網絡

服務部署好後,會有一些RESTful資源可用(如這裡),還可以通過他們各自的API來進行管理。而且總體的服務也可以通過一個RESTful資源使用,總體服務的表示方式遵守OCCI規範(活動、鏈接等)。

擴充服務部署

隨著時間推移,部署的服務可能會需要進行橫向擴充(如果是正面的話,就是增加節點;如果是負面的話就是減少節點)。在本情景的上下文中,擴充的原因可能是由於現有的試用用戶集合在這個新服務中發現了巨大的價值,從而向服務投入了更大的任務量;也可能是由於隨著服務的成熟,供應商增加了試用用戶的數量。這意味著必須隨需增加以OCCI管理的、附有Hadoop任務跟踪器和數據節點的虛擬機。Hadoop的命名節點和工作跟踪器貯存在主節點上,在這個階段可能並不需要擴充。

在這個階段只有一個步驟,也就是,添加新的計算實例到服務中的操作,這樣就可以橫向擴充服務。這可以通過下列對OCCI兼容接口的調用很簡單地實現:

  1. 建立新的Hadoop從節點
        a.使用Hadoop從節點模板
        b.使用OCCI的StorageLink連接到存儲B(使用CDMI標識符來把CDMI資源關聯到OCCI資源)
  2. 連接從節點到私有網絡
        a.使用OCCI的IPNetworkLink

這裡假設Hadoop從節點已經在之前配置完成,也就是它已經註冊到Hadoop主節點中。

服務遷移和重新部署

在這個情景中,由於不滿他們當前的供應商的惡劣的服務質量,新公司決定把他們現有的開發遷移到一個新供應商的平台上。這時候,所有的三個標準需要協作來保證從雲平台A到B的遷移和重新部署能夠成功。總體過程分為四個步驟:

  1. 服務查找和發現——一旦新公司決定更換服務商,需要了解新的替代供應商是否能夠支持老供應商所提供的同樣特性。這樣一個過程可以使用OCCI(查詢接口)和CDMI(元數據接口)的服務發現機制來完成。現在這個CDMI接口不是通過標準化的URL來提供。在這篇文章稍後的位置我們將給出解決這個問題的方案。只有在確認了替代供應商可以支持以前的特性之後,這個新公司才會執行服務導出、遷移和數據導入。
  2. 服務導出 ——可以用OVF格式來表示服務的內容,這需要做一個用OVF表示服務內容的請求。使用HTTP內容協商可以完成這個任務,這將得到一個OVF文件,外部連接到CDMI管理下的數據(應用數據、虛擬機映像等)。
  3. 遷移 ——CDMI接口應該處理數據從雲平台A到B的實際遷移過程。這個可以通過CDMI的序列化和反序列化特性來完成。
  4. 服務導入 ——服務導出成OVF表現方式,並且相關數據也遷移到新的服務提供商後,需要實例化原有的服務。實例化是使用導出的OVF表示文件來操作。這個OVF文件被交給服務供應商,由供應商代替客戶來按照OVF文件的描述實例化資源(例如:計算、網絡或輔助存儲),並關聯(由CDMI管理的)相關數據。

如果遷移是“冷”遷移(在遷移過程中服務被終止活動並下線),可以使用OCCI的終止和重啟虛擬機、網絡資源等特性。目前,要支持很短或沒有服務停機的實時遷移,相比於對規範的支持來說更重要的是,在實時遷移中牽涉到的供應商需要支持(類似於對等協議/工具)相關的能力(例如:跨子網的實時遷移)。

集成雲標準

前面描述的這個情景說明了在幾個(現在可用)的雲標準之間需要一些相互作用。這個情景給出了需要擴充和遷移的例子,兩種情況下三個標準都起到了重要的作用。OCCI被用作引發操作的運行時管理API,OVF被用於可遷移性任務,而CDMI非常適合數據移動和格式遷移。雖然CDMI也可以用於一些管理任務(例如:使用CDMI來導入和上傳鏡像)——但是需要對現有的規範作出一些擴展。

要能夠保證這個情景可以實現,標準需要被集成。後面的部分關注這些標準怎麼樣相互作用,還有一些需要做的、或者說是有很大益處的標準變更。

集成需要面對的整體課題

一個現在已經發現的最大挑戰是數據的遷移。這不僅意味著把未經處理的數據從雲平台A搬運到B,還包括數據格式上可能有的轉換。例如說云服務供應商A所使用的VMware的文件格式可能需要轉換成雲服務供應商B所使用的VirtualBox的格式。

數據轉換和遷移問題現在並沒有很好地反映到文檔中,可能還需要進一步調查。雖然兩個雲平台之間的遷移過程可能是由OCCI引發,但實際上也會涉及CDMI和OVF。CDMI可以處理數據轉換,但這更偏向於服務實現的一個方面。在這個操作中,OVF格式中的定義有可能發生變化。

集成存儲管理API

OCCI有一個對存儲管理能力的簡單表現方式,可以實行大多數最為基本的存儲相關的操作。OCCI的一個目標就是集成現存的標準,同時也避免重新發明輪子。當某個供應商希望暴露更為豐富的存儲接口時,OCCI推薦使用SNIA的CDMI。在OCCI規範中給出了這樣建議,詳細說明了CDMI管理下的存儲是如何在OCCI基礎設施模型下進行表示(請參照OCCI 基礎設施模型規範[8]的3.4.3小節)。

集成OCCI和CDMI

既然兩個規範已經相互引用,兩者的集成也就可以在一個較高的層次達成。下面的章節給出了集成必要的信息,並引出了兩個標準的更加緊密集成的思想。

使用OCCI的StorageLink來訪問CDMI容器

OCCI 基礎設施擴展中所定義的一樣,OCCI可以結合SNIA雲存儲標準——CDMI——使用,以提供對雲計算存儲數據的更好的管理。為了集成二者,需要使用OCCI的StorageLink,這將把OCCI管理的資源連接到CDMI資源。

使用OCCI和CDMI的服務遷移

如果一個服務供應商實現了OCCI和CDMI接口兩者,用戶可以開始啟動和執行遷移的過程。如果服務供應商沒有提供OCCI和CDMI接口,就需要用戶的直接操作才能開始遷移。而要獲知供應商是否支持OCCI和CDMI就要使用/.well-known/接口。

這個遷移過程需要按照上面“服務遷移與重新部署”小節所描述的步驟來執行。另一個服務供應商(也暴露了OCCI和CDMI接口)會被問詢是否具有必要的能力以確保具備必須的服務能力。如果查詢成功且能力滿足,數據就需要在兩個雲平台間進行遷移,接下來就需要準備必要的資源。

CDMI可以用於解決數據遷移的問題。新的數據對象可以創建在目的雲供應商平台上。新的數據對像一經創建成功,源數據對象就成為原始數據對象。請參照CDMI 規範[9]的第15節。

關於CDMI的思考

對於進一步集成OCCI和OVF到CDMI,建議對下列課題進行進一步探討。

通過CDMI(使用OVF)導入和上傳虛擬機鏡像

當通過CDMI接口導入OVF文件時,應該可以根據OVF中的定義來分配網絡和計算資源,但目前OVF規範並不允許這樣做。CDMI關注云平台的存儲需求,但是如果導入OVF文檔,它不僅能處理存儲資源分配,還可以與OCCI接口交互,並滿足所有OVF文檔的資源需求。

從CDMI容器鏈接回OCCI接口

目前的使用OCCI和CDMI的過程在CDMI規範的第13節中給出了說明。現在OCCI基礎設施模型的資源實例可以鏈接到CDMI模型。正是使用OCCI的StorageLink把計算資源連接到它們的存儲[注1],這樣當前的鏈接就具有了從OCCI模型實例指向CDMI容器的方向。

讓這種集成更為強大的是,讓連接從CDMI指向OCCI模型的資源實例(補充的反向鏈接)會非常有用。從語義上來說,這意味著把CDMI的存儲資源連接回它們綁定的OCCI計算與/或存儲資源。一般來說,CDMI用戶就可以看到哪些服務綁定到他們的數據對像上。在本文的情景中,這能夠找到哪些磁盤用於虛擬機,還有哪些數據是用於MapReduce服務本身。

通過Well-Known地址暴露能力的查詢接口

RFC 5785中所描述的那樣,我們推薦把CDMI能力接口(同時)暴露在“/.well-known/com/snia/cdmi”路徑之下,而現在它是通過“cdmi_capablities”路徑暴露出來。OCCI也使用了這個方法,可以把自己的查詢接口暴露到“/.well-known/org/ogf/occi”路徑。用這個方式客戶端就有一種統一的方式來訪問和查詢服務供應的能力。最終這些命名空間應該被註冊IANA。

集成標準以保證可遷移性

除了 ​​雲端的存儲與數據方面之外,服務的可遷移性必須得到確保。DMTF的OVF規範給出了一種以可遷移的方式描述完整服務的方法。OCCI接口可以用於以OVF格式導入和導出服務定義。後面的章節會更詳細的討論這些想法。

集成OCCI和OVF

OCCI和OVF完全可以互不影響地共存,目前只需要添加MIME類型的支持,這樣可以告訴OCCI服務供應商客戶端想要取得或者提供OVF格式的信息。在OCCI規範沒有包括這個新MIME類型的規範,現在它只支持text/occitext/plain以及text/uri-list

把OVF映射到OCCI基礎設施模型

下表概括了OCCI屬性如何與OVF屬性雙向映射。

OCCI的計算資源

 

說明

OVF

OCCI

詳細

CPU架構(86,x64)

<vssd:VirtualSystemType>[...String...]</vssd:VirtualSystemType>

occi.compute.architecture

見VirtualHardwareSection

核心數量

<rasd:ResourceType>3</rasd:ResourceType>

<rasd:VirtualQuantity>1</rasd:VirtualQuantity>

occi.compute.cores

見VirtualHardwareSection

主機名

<Property ovf:key="hostname" ovf:type="string">

</Property>

occi.compute.hostname

ProductSection的一部分

處理器速度

<rasd:ResourceType>3</rasd:ResourceType>

<rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits>

<rasd:Reservation>500</rasd:Reservation>

occi.compute.speed

見VirtualHardwareSection

內存容量

<rasd:ResourceType>4</rasd:ResourceType>

<rasd:VirtualQuantity>512</rasd:VirtualQuantity>

occi.compute.memory

見VirtualHardwareSection

資源狀態

N/A

occi.compute.state

 

 

OCCI的網絡資源

 

說明

OVF

OCCI

詳細

網絡標記

<Property ovf:key="label" ovf:type="string">

occi.network.label

定義於Properties,見ProductSection

廣域網名

<Property ovf:key="vlan" ovf:type="string">

occi.network.vlan

定義於Properties,見ProductSection

資源狀態

N/A

occi.network.state

 

 

OCCI的存儲資源

 

說明

OVF

OCCI

詳細

存儲設備大小

<Disk ovf:diskId="vmdisk2" ovf:capacity="536870912"

occi.storage.size

見DiskSection

資源狀態

N/A

occi.storage.state

 

 

其他的OCCI資源可能也需要映射,例如某些Link和Mixin,它們是由OCCI基礎設施模型擴展所定義。這些映射很簡單,與上面的表相類似。

服務供應商現在自由決定如何處理沒有映射的屬性,這樣有可能當客戶端以OVF格式去獲取OCCI管理的服務時,結果是只能導出一個最小化的OVF文件,僅包括了OCCI基礎設施表示方式中定義了的屬性。但是服務提供商可以選擇在OCCI基礎設施模型的服務部署之外同時保存OVF表示格式,這樣整個OVF表示都可以取得。我們現在推薦後者這種形式。

保證橫向/縱向擴充

橫向和縱向的擴充現在並沒有在OVF規範裡得到充分覆蓋,不過範圍可以在服務描述裡定義。範圍的應用讓客戶端能夠為一個屬性指定有效的範圍集合,然而(就像虛擬機的數量一樣),這對於擴充來說並不足夠,因為擴充應該有邏輯基礎。橫向和縱向的服務擴充只能通過合併使用OCCI和OVF才能實現。

從OCCI資源模板到OVF的映射

OCCI基礎設施擴展描述了讓用戶定義資源和操作系統模板的方法。模板讓OCCI實現的客戶端能夠快速便捷地應用預定義的配置到OCCI基礎設施中定義的類型,他們通過OCCI的Mixin的實例實現。而操作系統和資源模板則相輔相成:

  • 操作系統模板讓客戶端指定在請求的計算資源上必須安裝什麼樣的操作系統。
  • 資源模板Mixin建立在操作系統模板之上。一個資源模板是一個供應商定義的Mixin實例,指向預設定的資源配置(類似於亞馬遜的EC2實例類型[小、大、超大])。

最好也在OVF表現方式下定義這些模板。

OCCI的思考

下面兩個課題與作為邊界協議的OCCI並不直接相關,他們主要是關於實現OCCI的服務提供商應該如何處理某些操作。

根據OVF描述中的選項來配置OCCI實體

OVF格式可以配置某些操作——如描述開機和關機時的動作,未來版本的OVF甚至可能會詳細說明ActivationEngines以及其他一些方面,這樣OVF就能夠某種程度上說明處理服務的語義。那些允許在OCCI上使用OVF準備整個服務的服務供應商就需要處理這些配置和細節,並據此配置資源管理框架。

確保OVF中描述的一致性等級在OCCI的搭建時得到滿足

與前一個課題密切相關的是OVF描述的一致性等級。支持在OCCI上使用OVF準備服務的服務供應商需要注意滿足這些等級要求。在實例化服務的時候一致性等級必須得到滿足。如果等級沒有滿足,客戶端應該將此視作對服務等級協議(SLA)的違背。這樣,如果一個服務供應商不能實現OVF描述裡要求的一致性等級,對於服務準備的請求應該被否決。

關於OVF的思考

為了讓OVF和OCCI進一步集成應該考慮下面的課題。

像OVF中的虛擬開關一樣描述網絡設備

網絡特性已經可以在OVF中得到定義,不過如果能夠像前面“情景”一節中在服務描述裡所用的那樣,描述整個網絡的搭建,那就更好了。這裡我們指出OVF的2.x版對這種描述會有更加好的支持。

為OVF定義MIME類型

在從服務請求操作或接收信息的時候,OCCI客戶端依賴於正確的mime-types。服務供應商會使用(內容協商)MIME類型信息來了解它所接受到信息的種類。客戶端則永遠可以按他們希望接受的請求信息的mime-type來請求信息。由於OVF文件的導入導出特性,客戶端會傳回OVF文件到OCCI服務,或者以OVF格式來請求當前狀態。為了達到最佳的互操作性,我們建議註冊OVF的MIME類型。

相關工作和概況

在調查本文中所用的情景的時候,發現有某些課題在進一步的調查中特別值得注意:

  1. 服務等級協議(SLA)
       a.一個OCCI的SLA擴展目前正在開發當中,可能會得到採用。
       b.SLA可能被定義在OVF文件裡,並使用這個OCCI擴展獲得推行。
       c.存儲和數據的SLA的監督、施行和搭建可以用OCCI擴展通過CDMI集成。當與觸發器和動作結合使用時,這個監督擴展讓更加標準化的自動擴充成為可能。
  2. OCCI應該從其他標准採用的特性
       a.我們發現CDMI的隊列和通知機制非常有用,應該進一步調查這些特性是否可以集成到OCCI中。
       b.在RFC 3986中說明的URI轉義可能需要加入到現在OCCI提交中。
       c.在OCCI現在的文本和HTTP頭提交中添加JSON提交擴展可能促進OCCI和CDMI的更加緊密的集成。

結論

從參加在DMTF聯合夥伴技術講壇(APTS)上SDO會議的協同工作中,本文記錄了從OCCI工作組的視角出發的一些觀察以及活動事項。DMTF主持了這個面對面活動,以調查開放雲計算可互操作性以及可遷移性標準工作兩者集成的可能性,涉及的標準包括OVF、CDMI和OCCI。

在第一節中描述的情景用於遍歷服務的生命週期中不同過程,尤其是服務的遷移和擴充。它的目的在於反映真實世界裡的一次儘管有些基本的服務發布,證明了應用當前的標準是可能實現這樣一個工程的。

本文的隨後章節討論了這標準的三駕馬車能夠如何集成,哪裡還存在未解決的問題。需要進一步的調查或改進的未解決的問題得到了展示和說明。總體的集成是可以達到的,從而足以使用目前可用的這些規範版本獲得對“情景”一節中描述的服務完全的部署、遷移和擴充。

這裡強調指出引入第四個可用的規範也許會有很好的效果。CSA的CloudAudit已經在行業中獲得了接受,並為本文的情景添加了重要的特性。審計雲端和一致性等級沒有在本文中進行討論,但是會在未來的調查中有更大的作用。

雖然目前更專注服務開發的基礎設施等級,一個使用雲標準的更加基於PaaS的情景(如Node.js或GAE服務)可能在本文的未來修訂版中獲得說明。

鳴謝

作者希望感謝Mark Carlson(Oracle)和David Slik(NetApp)的對CDMI和OCCI集成上的知識分享。

我們希望感謝Winson Bumpus(VMware)和Jeff Wheeler(華為)在有關OVF的課題上的幫助。

非常感激下列審核者在創作、編輯和審核這篇文檔中的工作:

  • Alexis Richardson (RabbitMQ)
  • Lawrence Lamers (VMware)
  • Sebastian Schoenberg (Intel)
  • John Kennedy (Intel)
  • Finian Rogers (Intel)
  • Dr. Craig Lee (The Aerospace Corporation)

關於作者

Andy Edmonds是Intel的研究員。

Thijs Metsch是一位高級軟件工程師,就職於Platform Computing,專注於網格與雲計算技術。

Eugene Luster是一位在R2AD工作的雲計算推廣專員,專注於雲計算開放標准開發。

參考文獻

[1] Open Cloud Computing Interface working group community website

[2] Distributed Management Task Force website

[3] Cloud Data Management Interface website

[4] Open Virtualization Format

[5] Standards and Interoperability for eInfrastructure Implementation Initiative website

[6] NIST Cloud Computing Program

[7] Apache Hadoop website

[8] Open Cloud Computing Interface - Infrastructure, Open Grid Forum, GFD-PR.184, 2011

[9] Cloud Data Management Interface, Storage Network Initiative Alliance, 2010

[10] Cloud Management Working Group website


[注1]這裡的含義是指把一個磁盤鏡像綁定到一個虛擬機實例。

查看英文原文:An Open, Interoperable Cloud

本文來自:http://www.infoq.com/cn/articles/open-interoperable-cloud 

Read more >>

關於EC ONE ECONE-top-right.png