一種開放的可互操作的云

2011-08-31 09:21:21來源：作者：

在這篇文章中我們會描述：在當下，怎么樣通過利用成熟的開放標準（特定于云計算、網格與存儲領域）創建具有可互操作性的云。我們會演示使用一些最新的具有創新性的主要云計算接口規范來實現一個開放的、基于標準的、

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

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

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

為了實現并能夠執行這個情景，使用了下面所列用得到的標準：

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

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

情景

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

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

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

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

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

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

服務部署與擴充

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

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

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

進行最初的開發

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

建立內部/私有基礎設施
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
建立外部/公開基礎設施
a. 建立門戶節點
i.使用門戶操作系統模板與OCCI計算類請求
b. 連接門戶節點到私有網絡
c. 連接門戶節點到公開網絡

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

擴充服務部署

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

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

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

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

服務遷移和重新部署

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

服務查找和發現——一旦新公司決定更換服務商，需要了解新的替代供應商是否能夠支持老供應商所提供的同樣特性。這樣一個過程可以使用OCCI（查詢接口）和CDMI（元數據接口）的服務發現機制來完成。現在這個CDMI接口不是通過標準化的URL來提供。在這篇文章稍后的位置我們將給出解決這個問題的方案。只有在確認了替代供應商可以支持以前的特性之后，這個新公司才會執行服務導出、遷移和數據導入。
服務導出——可以用OVF格式來表示服務的內容，這需要做一個用OVF表示服務內容的請求。使用HTTP內容協商可以完成這個任務，這將得到一個OVF文件，外部連接到CDMI管理下的數據（應用數據、虛擬機映像等）。
遷移——CDMI接口應該處理數據從云平臺A到B的實際遷移過程。這個可以通過CDMI的序列化和反序列化特性來完成。
服務導入——服務導出成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/occi，text/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類型。