第 4 章

? CloudStack架構分析 ?

本章將在篇的基礎上，結合雲計算技術本身的特點，從架構設計的角度上，對CloudStack進行詳細分析介紹。主要包括以下內容：
ClouStack功能及特點、CloudStack繫統的主要組成部分、CloudStack網絡通信架構分析，以及CloudStack軟件架構分析。

4.1  CloudStack的功能及特點

作為一種雲計算解決方案，如果想要提供服務，通常具有以下5個方面特點。

l        
支持多租戶。

l        
能夠按需提供自服務。

l        
寬帶網絡的接入。

l        
將所有物理資源池化。

l        
能夠進行彈性增減，自適用服務。

為滿足以上目標，CloudStack能夠提供基礎架構及服務（IaaS）的服務模型，建成一個硬件設備及虛擬化管理的統一平臺，將計算資源、存儲設備、網絡資源進行整合，形成一個資源池，通過管理平臺進行管理，彈性增減硬件設備。為滿足多租戶的要求，CloudStack進行了功能上的設計和優化，設計了用戶的分級權限管理機制，通過各種技術保證用戶數據的安全，保護用戶的隱私。用戶可以直接以瀏覽器的形式登錄繫統，自由管理繫統授權下的資源，從而實現自服務模式。在多租戶模式下，需要提供各個用戶的資源使用情況，便於計費，CloudStack通過多種手段記錄用戶使用的資源，並將其保存下來。整個CloudStack中用戶及權限如圖4.1所示。

圖4.1  CloudStack平臺基本概念

首先來看一下用戶管理方面。多租戶是雲計算框架的一個基本特點，支持多租戶是一個IaaS雲管理平臺應該具備的基本條件之一。從上圖中可以看出，在整個繫統中用戶可分為三類：普通用戶、用戶組和DEV。

l        
普通用戶是指以個體形式使用繫統服務的用戶，如一般的個人開發者租用服務等。

l        
用戶組是指以公司或者組織的名義使用繫統資源與服務的多個用戶。

l        
DEV則是一個開發模塊，用於開發計費、監控和統計報表，定制圖形界面的工作流等。

對於多租戶同時存在的復雜情況，CloudStack需要通過一定的手段保證了資源使用的限制和通暢。限制是指對於用戶，隻能訪問授權範圍內的合法資源，不能訪問其他的未授權的資源；而對於通暢，是指通過一些規則支持和兼容更多的用戶需求和使用場景。

對於限制。因為雲平臺上的多租戶可以開放給任意用戶訪問和使用，所以需要解決的問題就是如何保證用戶數據的安全；其次要考慮某一用戶申請的資源怎樣纔不會被其他用戶占用，即保證資源使用的有序性。對於這兩個需求，從技術角度考慮，就是指對網絡訪問方式的限制，以及對虛擬化資源和物理資源使用的隔離與限制。而對於網絡訪問的限制，可以通過網絡架構的設計及虛擬防火牆和安全組來實現。這也是CloudStack的一大特色。如果需求更進一步，某一個用戶需要獨占物理資源，比如某幾臺配置不同的服務器和存儲空間，甚至是一個或幾個集群，這些對於CloudStack來說，也可以做到。通過采用標簽的形式，在管理界面上將資源直接指定給某些用戶或者用戶組，就可以將用戶和應用場景的需求分割開來。

那麼對於同一個用戶組內的多個用戶的使用應該如何做到使用通暢呢？圖4.2給出對應的解決方案示意。

圖4.2  用戶組內管理及組間共享

在CloudStack的設計中，用戶組中可以設置管理員，進行一定權限的自治管理，這也是自服務的另一種體現。用戶組可以平級創建擴展，也可以在用戶組下建立子用戶組。而資源在指定給用戶組之後，用戶組內的用戶都可以共享這些資源。除此之外，CloudStack還有一種“項目”功能，通過創建一個項目，不同用戶組之間可以共享一個資源集合。

再看資源管理方面。CloudStack的管理比較全面，而且兼容性非常強，可以管理多種Hypervisor虛擬化程序，包括XenServer、VSphere、KVM、OracleVM，甚至裸設備，如圖4.3所示。凡是這些虛擬化程序支持的計算服務器，CloudStack也都可以正常支持。

圖4.3  CloudStack支持的設備類型

CloudStack可以使用的存儲類型也非常廣泛。虛擬機所使用的主存儲可以使用計算服務器的本地磁盤，也可以掛載iSCI、光纖、NFS。存放ISO鏡像及模板文件的二級存儲可以使用NFS，也可以使用OpenStack的Swift組件，如圖4.4所示。

圖4.4  CloudStack支持的存儲類型

CloudStack在網絡方面也擁有出色的設計。除了連接外界的各種網絡連接方式之外，其自身也提供了多種網絡服務，即使在不使用硬件的情況下，繫統內部就可實現網絡隔離、防火牆、負載均衡、VPN等功能，如圖4.5所示。

圖4.5  CloudStack支持的網絡功能

CloudStack通過將包括計算資源、存儲資源和網絡資源在內的硬件設備統一管理、統一池化，終抽像出了供上層平臺使用的、硬件透明的服務。因此，終用戶隻要在CloudStack的平臺上直接申請和使用虛擬機就可以了，無須關注底層硬件設備是如何被設計和使用的，也不用關心自己使用的虛擬機到底在哪個計算服務器或哪個存儲設備上。

4.2  CloudStack的主要組成部分

一個大型的雲計算服務平臺，必然包含許多重要的組成部分，了解這些部分之間的層次關繫及協作模式，對於理解該雲計算平臺的架構具有極其重要的意義。為加深對繫統的認識，本節將從部署架構的角度出發，詳細介紹CloudStack繫統中的主要組成部分。

從物理設備互相連接的角度看，CloudStack的結構其實並不復雜，可以簡單地理解為：在管理方面，一個CloudStack管理節點或集群，管理多個可以提供虛擬化計算能力的服務器；在存儲方面，服務器即可以使用內置磁盤或外接存儲，如圖4.6所示。

圖4.6  CludStack基本抽像結構

在虛擬化領域，尤其是在計算服務器和存儲方面，這樣一個抽像的架構是非常常用的，也是非常易於理解的。

然而，圖4.5雖然簡單明了，但是對於一個極為復雜，需求多樣的雲計算平臺來說顯然是不夠的。在雲環境中，由於應用場景和需求的復雜性，一個雲平臺必須保證其結構設計具有很好的適應性、通用性、異構的兼容性和靈活的可擴展性。

圖4.7所示為CloudStack的部署圖，主要展示了繫統中不同的部件及其之間的關繫。

圖4.7 
CloudStack架構部署圖

通過架構的部署圖，可以很好地理解CloudStack各個部件之間的關聯，其中的區域（Zone）、提供點（Pod）、集群（Cluster）等屬於邏輯結構，既可以對照實際環境進行理解，也可以按照需求靈活配置。下面將對這些概念按照逐層遞進的順序進行詳細的介紹。

1. 管理服務節點

管理服務節點（Management
Server）是CloudStack雲管理平臺的核心部分，對應於抽像結構中的管理節點，整個IaaS平臺的工作將統一彙總在服務管理節點中進行處理。管理節點的主要作用可以劃分為兩部分。

l        
，響應操作命令：接收來自用戶和管理員的命令，包括對硬件、虛擬機和網絡的全面管理操作指令。然後，管理節點會將操作命令發送給相應的計算節點或繫統虛擬機去執行。

l        
第二，管理與監控繫統：管理服務節點還會在MySQL數據庫中記錄整個CloudStack的所有信息，並監控計算節點、存儲及虛擬機的狀態，以及網絡資源的使用情況，從而實時地管理整個繫統各個部分的運行情況。

至於用戶如何查看繫統狀態以及如何與管理節點進行交互，CloudStack采用的是瀏覽器管理界面。CloudStack采用Java實現，前端界面使用JavaScript編寫，做成Web App的形式，然後通過Tomcat容器進行發布。在安裝CloudStack管理程序時，會自動配置Tomcat的相關參數，這樣就省去了讀者手動配置和發布Web頁面的相關操作了。在正確安裝CloudStack之後，可以打開瀏覽器，訪問CloudStack管理程序的頁面，在Web圖形化頁面上進行單擊和輸入等管理操作。後臺程序的邏輯和數據也通過Web界面展示給用戶，使整個命令操作和信息獲取過程簡單友好。

根據之前的抽像結構和部署結構可以看出，CloudStack采用的是集中式管理結構，所有模塊都被封裝在管理節點的程序中，便於安裝和管理，安裝的時候隻需要簡單的幾條命令即可完成，所以在節點上隻需要分別安裝管理服務程序、MySQL數據庫和Usage服務程序（可選）即可。

在一個小規模的使用環境中，可以將以上所有的組件集中安裝在一臺物理服務器或虛擬機上。然而，在一個計劃上線的生產環境中，如果將所有的組件安裝在一臺服務器上，將會有很大的負載壓力。而我們知道，管理服務節點作為整個繫統的管理中心，將會接收到不同種類的多種請求，包括用戶門戶請求、管理員門戶請求以及各種API請求等。因此，可以設計在管理服務器模塊前加入一個負載均衡模塊，將不同的請求轉發定位到不同的服務器上。這樣就可以將管理模塊分到不同的服務器上，從而達到降低壓力的目的，如圖4.8所示。

圖4.8 
部署多臺管理服務器

在圖4.8中，除了使用負載均衡器將各種請求負載到多臺服務器之外，還要注意兩點：，將MySQL數據庫按照抽像結構中的分布，安裝在獨立的服務器中，並搭建主從方式的MySQL數據庫，使得繫統中存在多份數據的副本，保證數據的安全性；第二，如果需要安裝計費模塊Usage，則將其安裝在獨立的服務器上，其原因除了計費模塊本身在邏輯上相對獨立之外，還可以用來分擔管理服務器的壓力。

CloudStack在設計上還有一個優點，就是管理服務器本身並不記錄繫統本身數據信息，而是全部保存在MySQL數據庫中。這樣做的好處在於，當管理服務程序停止或所在的節點宕機，所有的計算節點、存儲及網絡功能會在維持現狀的情況下正常運行，隻是可能無法再接收新的請求，用戶所使用的虛擬機仍然可以在計算服務器上保持正常的通信和運行。

然而，這僅僅是對於管理程序來說，如果宕機對像換成數據庫，情況就另當別論了。MySQL數據庫作為整個繫統的存儲中心，記錄了整個雲平臺的全部數據，包括整個雲平臺的規劃、物理設備、虛擬機、存儲文件、IP使用信息等。對於可能的數據庫崩潰，目前的解決方案是為此數據庫搭建一個實時同步的從屬數據庫，使得繫統的數據副本數量始終大於或等於2。在主數據庫無法工作後，切換到從屬數據庫即可重新獲取繫統之前的數據信息。

2. 區域

區域（Zone）是CloudStack中的。一個區域通常代表一個獨立的數據中心，雖然在一個數據中心也允許有多個區域。一個區域內的組件如圖4.9所示。

圖4.9  區域內部件結構

由圖4.9可以看出，一個區域由提供點（Pod）、二級存儲（Secondary Storage）、網絡架構組成。在完成管理服務器的安裝後，登錄到CloudStack界面，步就是創建區域，從而完成在IaaS平臺上的初步規劃。在創建區域時，需要對區域內部件進行一繫列的選擇和配置，包括網絡架構的選擇、網絡的各種規劃與配置、添加計算服務與存儲等步驟。從管理員的角度來說，在進行區域配置時，必須盡可能詳盡地考慮整個區域內的計算、網絡以及存儲需求，提前進行一個很好的規劃，使得區域內的配置不僅可以滿足現階段的使用需求，還能夠適應未來的擴展需求。當然，區域內的配置還可以在以後的實際運行過程中繼續添加提供點、集群、計算服務器以及存儲等主要部件。值得一提的是，區域內設置的提供點的數量並沒有限制，可以根據實際需要進行自由配置。

區域作為整個CloudStack中的的基本單位，但並不是的，也就是說，一個CloudStack繫統可以劃分多個區域。區域之間可以完全實現物理隔離，硬件資源、網絡配置、虛擬機等設備或資源也是相互獨立的。在建立一個區域，選擇網絡配置時，有兩種選擇：基本網絡（Basic Zone）或是高級網絡（Advanced Zone）。因此，如果繫統中同時存在多個區域，那麼根據網絡資源獨立的條件，各個區域可以配置不同的網絡，互相之間也不會產生影響。根據區域的這一特點，可以將不同的物理機房劃分為不同的區域，從而實現CloudStack對於多個物理機房的統一管理。再者，還可以從實際業務需求的角度進行考慮，當需要兩個甚至多個相互獨立的區域，而隻有一個物理機房時，可以將該機房劃分為兩個獨立的區域，供兩個獨立繫統使用。那麼，如果區域之間需要進行通信，采用什麼樣的方式？因為區域之間是相互獨立的，因此，區域之間的網絡通信隻能通過外界配置的公共網絡來提供。而區域之間支持的操作也隻有復制ISO和模板文件，虛擬機無法在區域之間實現遷移。如果實在需要實現虛擬機之間的遷移，那麼隻能將虛擬機轉換為模板文件，然後復制到另一個區域中。

另外，在用戶可見性方面，管理員在創建區域時，可以配置該區域為對所有用戶可見的公共區域，或者隻是對某些用戶組可見的私有區域。如果一個區域對某個用戶可見，那麼該用戶就可以選擇在該區域中創建虛擬機或者某些已授權操作。

3. 提供點

提供點（Pod）是CloudStack區域內的第二級邏輯，可以理解為一個物理機架，其中包含了交換機、服務器和存儲設備。因此，參照物理機架的概念，在CloudStack的提供點中也有網絡邊界的概念，即可以認為所有在一個提供點中的計算服務器、虛擬機都在同一個子網中，這些設備之間可以進行通信互聯，如圖4.10所示。

圖4.10  提供點內組件關繫

從圖4.10可以看出，提供點內部組件連接在同一個或者一組二層（Layer2）交換機上，所以在很多實際部署中基本也都是以一個物理機架進行規劃的。同時，在提供點內部，由多個集群構成，一個提供點內部的集群數量也沒有限制。而區域內，提供點與提供點之間、提供點與二級存儲之間是通過一個三層（Layer3）交換機進行連接與通信的。為實現網絡的靈活擴展，提供點是CloudStack中不可或缺的一個層級，另外，機架對於終用戶而言是不可見的。

4. 集群

集群（Cluster）是CloudStack繫統中小的邏輯，是由一組計算服務器及一個或多個主存儲組成。和集群內的計算服務器有關的一個概念是Hypervisor。Hypervisor可以理解為一種運行在物理服務器與操作繫統之間的中間軟件層，可允許多個操作繫統和應用共享同一套基礎物理硬件。而CloudStack中同一個集群中的計算服務器恰恰需要Hypervisor的管理和協調：同一集群中的計算服務器必須使用相同的Hypervisor虛擬化管理程序，硬件型號也必須相同（如果是帶有高級功能的XenServer和vSphere，則可以兼容異構的CPU）。而在提供點內，不同集群間則可以使用任意的計算服務器、任意的Hypervisor管理程序，而不會相互影響，所以一個提供點內可以包含使用不同的Hypervisor的集群。再回到集群內部，集群內的虛擬機可以在集群中的不同主機之間實現動態遷移（Live Migrate）。雖然CloudStack不限制集群的數量，但由於提供點所劃分的子網範圍有限，所以提供點內集群和主機的數量實際上不會是完全無限制的。對於存儲問題，集群內部可以添加多個作為共享存儲所使用的主存儲（Primary Storage），主存儲的類型並沒有特別的限定，隻要能夠與計算服務器進行正常的通信即可。

5. 主機

主機，又稱為計算節點，計算服務器，是CloudStack中的基本的硬件模塊之一。它用於提供虛擬化計算能力和計算資源，運行用戶創建的虛擬機，同時根據不同的運算需求與壓力，可以進行彈性的增減。主機上需要安裝Hypervisor程序用以實現虛擬化管理。以CloudStack4.0.2版本為例，主要支持CitrixXenServer、VMware ESXi、KVM（包括RHEL和Ubuntu）、Oracle VM等Hypervisor，具體支持的Hypervisor程序及其版本可以在圖形界面上找到，如圖4.11所示。

圖4.11  Hypervisor程序與版本

作為為繫統提供計算能力和計算資源的基本的硬件單位，計算服務器應具有以下特點。

l        
提供虛擬機所需的CPU、內存、存儲和網絡資源，形成一個完備的計算單位。

l        
互相之間使用高速網絡實現互通互聯，並與Internet連接。

l        
不一定是集中式的，可以分散在不同地理位置的不同數據中心。

l        
可以具有不同的規格，如不同的CPU速度、內存大小等。

l        
高性能通用x86兼容服務器，自身相對可靠，但規模較大時允許出現個別服務器故障的情況。

在之前已經簡要介紹了Hypervisor程序，CloudStack可以兼容絕大多數硬件設備，其實就是指絕大多數的硬件能夠被Hypervisor程序兼容。因此，在安裝Hypervisor程序之前，必須確定該服務器的CPU所能夠支持的虛擬化技術，並在BIOS中打開CPU對虛擬化技術的支持功能。同時，如果想知道服務器上的所有硬件是否與Hypervisor程序兼容，可以查閱Citrix、VMware的官方文檔。

6. 主存儲

主存儲（Primary Storage）一般作為每個集群中多臺計算服務器共同使用的共享存儲存在。在一個集群中，可以有一個或多個不同類型的存儲，主存儲用於存放虛擬機內部數據的鏡像文件和數據卷文件。當然，作為存儲設備，主存儲的位置距離宿主機越近效果越好。主存儲分為兩種，分別是共享存儲和本地存儲。 

共享存儲一般是指將存儲設備集中、獨立存放，對所屬集群中的所有計算節點開放，集中存儲該集群中的所有虛擬機的數據。使用共享存儲可以實現虛擬機的在線遷移（Live Migrate）和高可用（High Available），通過專業的存儲設備或技術可以保證較高的數據安全性，但相應地在讀寫性能方面會有所犧牲。 

本地存儲是指使用計算節點服務器內置的磁盤來存儲虛擬機的運行數據文件，可以使虛擬機擁有很高的讀寫性能，但無法解決因主機或磁盤故障導致的虛擬機無法啟動或者數據丟失等嚴重問題。 

7. 二級存儲

二級存儲（Secondary
Storage）是CloudStack根據IaaS平臺的架構和使用特點專門劃分出來的一種存儲。二級存儲是和區域相關聯的，並且一個區域中隻有一個二級存儲。在二級存儲中主要存儲以下內容。

l        
模板：可以用來啟動虛擬機和包括附加配置信息的操作繫統鏡像。

l        
ISO鏡像：包含數據或引導操作繫統媒介的磁盤鏡像。

l        
磁盤卷快照：可用來進行數據恢復或創建模板的虛擬機數據副本。

二級存儲可以支持兩種存儲方式：NFS和OpenStack的Swift組件。對於以上的三種文件形式，同樣可以存儲在主存中，為什麼要單獨設計這樣一種存儲呢？這與以上三種類型的文件的特點有關繫。這三種類型的文件具有如下特點。

（1）占用很大的空間。安裝用的操作繫統的ISO一般來說都在GB字節，而除了操作繫統文件之外，還包含一些應用程序與數據，加起來大概在10GB以上。

（2）讀寫頻率很低。細心的讀者可能會發現，二級存儲中的三種文件基本是一次性寫入後隻有讀取操作，使用也不會非常頻繁，與終用戶使用虛擬機數據卷文件的頻率相比，讀寫頻率幾乎可以忽略不計。

（3）文件單獨存放在二級存儲，而不存放在主存中。當文件損壞或丟失既不會影響現有繫統的運行，也不會影響用戶所使用的虛擬機。

類似這種占用空間大、讀寫頻率低的數據文件，我們稱之為冷數據。這些數據對整個繫統而言並不是關鍵數據，所以使用配置不高、簡單的NFS來存儲就足夠了，隻需要很低的成本就能滿足繫統使用的需求。

4.3  CloudStack網絡通信架構分析

在上一節介紹了CloudStack中的主要部件，按照層級關繫進行了詳細說明，為了讓讀者加深了解整個繫統的運行，下面將從繫統動態運行的角度對架構進行分析。

從網絡通信和數據交換的角度進一步分析CloudStack的架構，如圖4.12所示。

圖4.12  CloudStack網絡通信架構

從圖4.12 可以看出，在左邊，用戶按照不同角色通過界面登錄，然後向後端發送操作命令。前端界面與後端管理程序之間的交互采用的是目前流行、通用的做法：完全調用RESTful風格的API來實現。用戶所使用的Web界面上的任意功能，都由Web轉移為API命令發送至相應的API服務，API服務接收請求後交由管理服務進行處理，然後根據不同的功能將命令發送給計算節點或繫統虛擬機去執行，並在數據庫中進行記錄，完成後將結果返回給前端界面。而使用RESTful API接口也是出於對兼容性的考慮，既可以使用CloudStack本身進行統一管理，也支持用戶根據需求開發全新的界面或者通過其他平臺調用CloudStack的API來管理，通用性強，在對編程語言的支持上也沒有任何的障礙。除此之外，如果有計費的需要，則通過API調用CloudStack
Usage程序所統計的監控數據即可。

下面分析一下CloudStack管理服務是如何管理物理基礎設施的。簡單、直接的辦法就是調用設備開放的API命令，比如XenServer的XAPI、vCenter的API。而對於有些不方便直接調用API的設備（如KVM），會采用安裝代理程序（Agent）的方式協助進行管理，如圖4.13所示。

圖4.13  CloudStack與KVM的部署架構

從圖4.13可以看出，對於使用KVM設備，管理程序無法直接通過API的方式進行調用，而是在每一臺KVM虛擬機上安裝代理程序Agent，然後管理服務器將命令發送給代理，由代理完成調用任務並將結果返回給管理服務器，終實現協助管理。

在CloudStack中有極其豐富的網絡功能，這些網絡功能是由繫統虛擬機完成的。但是繫統虛擬機畢竟隻是一個虛擬機器，不管再如何提高其資源配置，對其性能的提升也是有限的，一旦實際需求中對網絡有極高的需求，就會出現瓶頸。從CloudStack4.0開始，支持使用其他物理設備擴展網絡功能來代替虛擬路由器的對應功能，既保持了CloudStack的原有架構，又提升了性能，滿足了應用需求。

除了以上介紹的設備之外，在圖4.12中還存在防火牆（目前使用Juniper
SRX）、NetScaler和負載均衡模塊（F5）。這些設備的使用極大地提升了CloudStack的實際應用能力。而對於這些設備的管理也都是采用API的方式來進行控制和調用的。

在存儲方面。圖4.13中並未畫出管理節點到存儲設備的連接線，也沒有說明管理節點是使用何種方式調用存儲設備的。其實，CloudStack並不是直接對存儲設備進行管理。在4.2節曾介紹過，存儲作為繫統的主要硬件設備和資源，按照分類的不同，扮演了不同的角色，提供了不同的功能。

主存儲通過調用計算節點所使用的Hypervisor程序進行管理，如在存儲上創建磁盤或執行快照功能等，其實都是通過調用Hypervisor程序的API進行的。也就是說，管理程序並不直接管理主存儲，而是通過Hypervisor程序進行管理。這樣做的優點是，這些Hypervisor程序能支持什麼樣類型的存儲，CloudStack就能直接配置和使用而不需要進行更多的兼容性開發；其缺點是，的存儲技術（如分布式存儲或對像存儲等）就沒有辦法在XenServer和vSphere這樣的商業產品上支持了。雖然使用KVM在理論上可以使用新的分布存儲，但使用效果是否能夠滿足虛擬化生產的需要，還沒有定論。二級存儲是一個獨立的存在，它不在某一個計算節點或集群的管理下，而是屬於整個區域。二級存儲的管理目前在CloudStack中是使用二級存儲虛擬機掛載此存儲並進行管理。

下面介紹繫統虛擬機。繫統虛擬機是整個CloudStack架構中很有特色且非常重要的組成部分，在繫統的管理中承擔了很多重要的功能。在CloudStack中，繫統虛擬機有三種類型，分別是二級存儲虛擬機（Secondary Storage VM）、控制臺代理虛擬機（Console Proxy VM）、虛擬路由器（Virtual Router VM）。

繫統虛擬機有特別制作的模板，使用的操作繫統為Debian6.0，隻安裝的程序用以減小繫統虛擬機所消耗的資源，安裝較新的補丁以防止可能存在的漏洞，針對不同的Hypervisor有不同格式的模板文件，並安裝支持此Hypervisor的驅動和支持工具來提高運行性能。CloudStack使用同一個模板來創建繫統虛擬機，它會根據不同角色的繫統虛擬機進行特殊配置，當繫統虛擬機創建完成後，每種繫統虛擬機會安裝不同的程序，使用不同的配置信息。

在保證數據安全性方面。為保證繫統的正常運行，所有的繫統虛擬機都是無狀態的，不會獨立保存繫統中的數據，所有相關信息都保存在數據庫中，繫統虛擬機內存儲的臨時數據也都是從數據庫中讀取的，方便繫統虛擬機的運行及任務的執行。繫統虛擬機作為繫統管理和運行的重要基本單位，必須保證其高可用性（HA）。CloudStack自身有一定的自檢測和恢復功能。當管理節點檢測到繫統虛擬機出現問題時，將自動重啟或重建繫統虛擬機（繫統會通過數據庫中的記錄的配置信息進行重建）。管理員也可以隨時手動刪除繫統虛擬機，然後由繫統自動重建（除虛擬路由器外），無須擔心刪除繫統虛擬機會造成數據的丟失或功能錯誤。繫統虛擬機對於普通用戶而言是透明的、不可直接管理的，隻有繫統管理員可以檢查及訪問繫統虛擬機。下面對三種繫統虛擬機進行詳細的介紹。

1. 二級存儲虛擬機（Secondary Storage VM）

二級存儲虛擬機用於管理二級存儲，每個區域（Zone）內有一個二級存儲虛擬機。二級存儲虛擬機通過存儲網絡連接和掛載二級存儲，直接對其進行讀寫操作，如果不配置存儲網絡，則使用管理網絡進行連接。在數據存儲方面，二級存儲虛擬機使用公共網絡實現ISO和模板文件的上傳和下載、用戶虛擬機的卷下載、將用戶虛擬機的快照存放在二級存儲上、多區域之間ISO和模板文件的復制等重要功能。在數據安全性方面，可以通過配置SSL加密訪問，從而達到保護用戶數據的目的。

2. 控制臺代理虛擬機（Console Proxy VM）

控制臺代理虛擬機用於支持用戶使用瀏覽器在CloudStack的Web界面上打開虛擬機的圖形界面。初始化時，每個區域默認生成一個控制臺代理虛擬機。當CloudStack平臺上有較多用戶打開虛擬機的Web界面時，繫統會自動建立多個控制臺代理虛擬機，用於分擔大量用戶訪問帶來的壓力，其對應配置可以在全局變量中找到。在用戶界面訪問控制臺上，默認使用域名realhostip.com進行訪問，DNS會自動將該域名解析為控制臺代理虛擬機的公共網絡地址。同時，控制臺代理虛擬機同樣可以通過配置SSL加密的方式保護用戶。用戶虛擬機的圖像通過管理網絡從所在的主機獲取，而不必關心用戶虛擬機的網絡架構，這樣便實現了代理的目的。

3. 虛擬路由器（Virtual Router）

虛擬路由器可以為用戶提供虛擬機所使用的多種功能，它在用戶次創建虛擬機時自動創建。虛擬路由器作為網絡結構與通信的重要部分，將在第5章網絡功能分析的相關章節中詳細介紹，現在先給出虛擬路