淺談vCloud Director虛擬資料中心的資源配置模型（ㄧ） Allocation Pool Model

幾乎沒有例外，每次當我們討論vCloud Director的三種不同資源配置模型時，每個人的臉上一定多少都充滿了疑惑和質疑，很多人會按照vCD畫面上的欄位說明嘗試著去了解該欄位所代表的意義，但應該輸入什麼數字，才是真正符合租戶的需求呢？

配置模型（Allocation Models）可決定您配置的提供者虛擬資料中心計算以及記憶體資源認可給組織虛擬資料中心的方式與時機。

個人覺得vCloud Director在資源配置這個部分的用詞是有一點奇怪，因為當在討論這些模型時，VMware把它區分為以下三種不同的Allocation Models，（詳細官方文件請看這裡 ):

1. Allocation Pool （中文翻作’配置集區’)
2. Pay-As-You-Go
3. Reservation Pool

所以會看到第一種Allocation Pool Allocation Model這種奇怪的名詞，我們此篇先來看一下比較常用也比較眾說紛紜的第一種，vCD到底是怎麼和底層的vCenter/RP協同合作，真的達到管理者當初分配資源的想法。

首先說明，依預設，配置集區組織虛擬資料中心會啟用具有彈性的(中文翻的比較怪，英文是Elastic)配置集區。當配置集區虛擬資料中心啟用具有彈性的配置集區功能時，組織虛擬資料中心會跨越並使用所有與其提供者虛擬資料中心相關聯的資源集區。

我們先來看一下以上說的所謂的啟用具有彈性的配置集區是在哪邊設定的，請看下圖

當我們將之勾選後，未來新增Allocation Pool資源型態時，在vCD的畫面中就會出現vCPU這個選項需要管理者輸入相關的數值，請看下圖所示，

新增一個型態為Allocation Pool，名為”Test Allocation VDC”的組織VDC:

請注意，”vCPU速度“現在是配置集區的強制參數。

新增完畢後對應的vCenter前後資源對照為下圖，我們看到vCenter自動幫我們建了一個名為”Allocation Test VDC”的資源池。

這裡看到的資源池對CPU是不可擴充且沒有限制的，RAM卻是可擴充，是因為之前一開始說的我們對整個PvDC的資源設定是Elastic的緣故。

在此組織VDC內新增虛機 (power off):

vCenter Web Client裡所顯示出來VM的內容

在此組織VDC內開啟剛剛新增的虛機，我們觀察此時該組織VDC在vCenter Resource Pool的資源數量有了變化，該RP只有在有虛機開啟時，CPU的”限制“數字自動和當初在vCD創建該組織VDC的”CPU配置”數字對齊。

由於組織VDC可以由多個資源池組成，這表示租戶CPU/Memory的管理就不能由底層的vCenter資源池這層來控管，vCD會將組織VDC的資源分散到屬於它的幾個資源池內，每個資源池裡的資源設定數值取決於當時有多少虛機跑在其中，記憶體比較容易計算，因為記憶體相對於CPU來說資源分配較為固定，你比較無法將配好給某台虛機的記憶體（當它處於Idle狀態時），拿去給其他台虛擬機使用，但CPU本來就可以，因它是分時的，所以在增加一個組織VDC時就要仰賴”vCPU速度“這個數值來計算每個資源池的CPU配置，確保所有資源池裡加總起來的CPU限制不會超過當初的OrgVDC CPU配額。

對照一下VMware官網的說明，是一致的:

 

大家應該看到資源池裡的記憶體的限制是”無限制”，這是因為關於記憶體的允許控制(Admission Control)是透過vCloud Director這一層來做的，無須再透過資源池層來把關，記憶體的使用統計可單靠虛機這一層就夠了。再說一次 ，因為CPU的使用是較為動態的，所以必須在資源池那層設定限制，不會在VM層加上限制，如下圖所示。

而在vCD裡的資訊會帶出全部開機的VM已使用的CPU/Memory資源配置總量。

注意，在此設定”vCPU速度“是用來計算在這個組織VDC裡中，總共可以讓我們部署幾顆vCPU，而不是指VM的vCPU實際運行時最大可以達到的速度限制。如上圖所示，整體VDC的CPU配置僅有0.26GHz，而在此vCPU速度也設為0.26GHz（此為可設定的最小值)，所以於此VDC中，僅能跑一個vCPU的VM。所以當我要啟動第二台規格一樣的虛機時，系統就報錯了，如下所示。

0.26GHz表示如果VM需要百分之百的單一顆vCPU運算資源時，系統一定要滿足的最小條件。

另外，此設定也幫助系統將資源池的“保留”數字確定下來，算法是:

• CPU保留= (所有已開機的虛機vCPU個數) x (vCPU速度) x (保證的CPU資源)
• RAM保留=(所有已開機的虛機RAM大小) x (保證的記憶體資源)

此模型是以vCloud Director為控制機制來決定是否有多餘資源可開啟虛機，整體vCD系統所產生的overhead並不會算在租戶的資源內，服務提供商需要自行吸收這些額外開銷。

另外，如果在同一層的其他虛機暫時不需要使用運算資源的情況下，虛機可以享用(搶佔)所有它需要的運算資源。

Elastic彈性擴充

現在來談一下何謂vCD裡的Elastic Allocation Pool?

試想，如果租戶需要更多的資源，但是當提供給Provider VDC的叢集資源都已經滿了，那該怎麼辦？

以前的作法是服務提供商必須另外從某一個Provider VDC裡的叢集尋找資源，再新增一個組織VDC給此租戶，但這樣的作法會非常的麻煩，畢竟雲端運算講求資源彈性擴充，目前vCloud Director可以支持動態增加多個資源集區（不同Cluster的Resource Pool）到同一個Provider VDC，這樣一來，租戶的使用資源便可跨多個資源集區而達到所謂的租戶運算資源可彈性擴充的目標。

結論：

• 服務供應商可以按照這種模型分配給某一租戶如下的雲端運算資源：

––> 總共多少”Ｘ”量的記憶體和”Ｙ”個可用的vCPU（保證最低時脈為”Y”GHz)

• 租戶能不能執行虛機取決於 vCloud Director組織VDC的總額設定和當時Provider VDC是否有足夠資源滿足該操作。
• 服務供應商可以建立多個組織VDC給不同的租戶使用，但這些組織VDC所有各類保證資源的總和非常有可能超過Provider VDC可以提供的資源（系統會有警告，但還是允許)，所以服務提供商必須做好容量規劃和管理，避免未來租戶因底層系統資源不足而無法運行虛機。如下圖:

因為有其他的組織VDC已經使用這個Provider VDC資源，雖然我們仍然可以在Provider VDC創建額外的組織VDC，但是如果Reservation over committed如上圖紅框所示，那未來勢必無法在此組織VDC再開啟任何虛機了，除非停用其他虛機釋放系統資源或調整組織VDC配置，才有可能開得了新增加的虛機。開啟虛機會看到如下報錯:

還有，租戶不能超用資源，意即在組織VDC分給他多少總量，就只能用多少。

• 設定“vCPU速度”時必須做好規劃，這取決於未來此VDC要跑哪類的應用，指定速度小的雖然可以布署多一點VM但有可能導致VM應用性能不彰。