作為XenServer的管理工具集，XAPI管理XenServer的主機，網絡和存儲。不管是OpenStack還是CloudStack，如果使用XenServer作為虛擬化底層，其對XenServer的調用必然使用XAPI。真正意義上的XAPI在XenServer中主要提供XenCenter以及資源池中各個XenServer主機的通信的接口。
首先，資源池中的所有XenServer主機的操作請求都是通過XAPI傳遞給Dom0的，同時在池中的所有XenServer主機間的通信也是通過XPAI進行傳遞。例如：資源池中數據庫（XenServer配置數據庫）會通過XAPI在所有的XenServer主機之間進行同步，以便在資源池Master宕機之后，其他XenServer主機能夠正確而迅速的取代Master，并維持資源池的功能和服務。其簡要示意圖如下所示：
如上圖所示，在創建XenServer資源池的時候，默認會選定一臺XenServer主機作為Master，即所謂的資源池主。Master的作用是協調和鎖定資源池內的各種資源。默認情況下在創建資源池的時候，加入資源池的第一臺XenServer主機被默認推選為Master。當資源池的Master主機出現故障不在可用時，Master是可以進行角色轉移的。其轉移的情況有兩種：一是進行手動轉移，二是在開啟資源池高可用的情況下進行自動轉移。
在一個資源池中雖然所所有的XenServer主機都有XAPI，并在XML / RPC接口上運行了HTTP 80端口和TLS / SSL的443端口，但控制操作只會在Master主機上進行處理。如果將一個控制操作指令發送給資源池的Slave主機，Slave主機上的XAPI將會將該控制指令重定向到Master主機，并且Slave主機上的XAPI將會產生一個XAPI重定向的錯誤消息并將其存儲在日志中。為了提高效率以下操作被允許在Slave主機進行：
查詢性能計數器（以及主機的歷史）
連接到VNC控制臺
導入/導出（特別是本地存儲上的磁盤時）
由于Master主機充當協調和鎖管理器，其他主機在需要調用資源的時候就會經常和Master產生大量的交互。當然Slave主機之間也會進行彼此的交互，比如說：
轉移VM的內存映像（虛擬機遷移）
鏡像磁盤（存儲遷移）
其次，XenCenter通過XAPI來讀取XenServer主機的配置、管理、License信息、數據庫信息等，同時XAPI也通過和上篇文章我們所講述的XenServer核心運行的toolstack系列工具，包括如Xenopsd、Xcp-rrdd、Xcp-networkd、SM、perfmon、mpathalert、snapwatchd、stunnel、xenconsoled和xenstored等所有的組件進行交互，這些組件通過和XAPI進行通信并監控XAPI的命令接口，根據XAPI發送過來的命令執行相應的功能控制。
下圖顯示了一臺XenServer主機上運行的軟件。所有的主機上運行相同的軟件。我們可以看到XAPI和其他的Toolstack所處的一個關系。
下面的關系圖顯示了xapi內部運行關系及架構：
圖的頂部顯示連接XenAPI客戶端：XenCenter、XenOrchestra、OpenStack以及CloudStack。這些客戶端都是通過XenAPI(XenAPI的XMLRPC通過HTTP POST）和HTTP GET/PUT在端口80和443與XAPI建立通訊。并且雙方之間建立互信是通過使用PAM認證（默認情況下使用本地passwd和group文件）或通過Active Directory進行認證。
其中XAPI中的Xen API又細分為三類：
* master-only：這是最重要的API也是最常用的API類型，顧名思義，這種類型的API只有Master能夠接受并進行執行。
* normally-local：這些API是為了提高性能的前提下，允許Slave主機執行的特殊API，其往往和主機以及虛擬機的性能相關。如磁盤輸入/輸出和虛擬機控制臺連接這些接口控制的API，這些API直接有Slave主機在本地就進行控制執行，不需要再有Master記下來轉發，提高了訪問速度和性能。
* emergency：這些API歸類為緊急情況下的API處理方案，例如當Master主機脫機的情況下，對資源池的緊急修復等。
對于API的執行，在資源池正常的情況下，XAPI會首先判斷API的類型。如果用戶在XenCenter中對Slave的操作是需要通過Master來執行的API，那么Slave主機的XAPI就會將該API重定向到Master主機，交由Master主機進行執行控制。在確認了API類型之后，即通過了初步檢查，API調用就會進入“消息轉發”層—控制、鎖定資源（通過current_operations機制） - 決定哪些主機應該執行該請求。如果請求是在本地執行，主機直接調用函數或者進程使用功能即可；否則消息轉發層就會將該請求同步給其他需要一同執行的主機上。
注：XAPI目前使用“每個請求一個獨立線程”的模式，導致將為每個請求創建一個完整的POSIX線程。甚至當這個請求在這臺主機上創建后被轉發給其他的主機，這個創建的線程仍然存在在第一次被創建的主機上，毫無疑問，這種模式的弊端必然是在請求數量較多時，導致XenServer主機的處理阻塞，影響虛擬機的性能。
接下來API具體如何執行調用呢？如果XenAPI的調用是關于VM生命周期操作，那么它將會通過JSON-RPC（類似Unix域套接字）轉換成具體的負責VM生命周期管理的組件Xenopsd 的API調用。XAPI和Xenopsd組件之間，對于每一個調用采用類似異步消息隊列的概念，XAPI的每一個調用不需要Xenopsd立即返回執行結果。所以目前XAPI將每一個任務（所有操作在任務的上下文中運行）都綁定到Xenopsd任務上，XAPI在接受到調用時將其所對應的任務扔給對應綁定的Xenopsd之后就不在過問了。具體有無執行成功需要等待Xenopsd給它的反饋，所以我們在XenCenter中執行一個命令之后看見任務的進度條在走，但是什么時候走完進度條需要底層的執行組件給XAPI反聵，XAPI再其狀態更新在狀態數據庫中，XenCenter會與XAPI進行不斷的通訊以收取狀態更新。如果Xenopsd組件執行命令出錯，會返回相應的錯誤信息并存儲在日志中。
如果XenAPI的調用是存儲操作，那么“存儲訪問”層 -- 驗證存儲對象處于正確的狀態（SR連接/分離；VDI連接/活動狀態、只讀/讀寫），然后調用存儲管理API（SMAPI）V2接口中的相關操作；同時其中還存在著一個SMAPIv2到SMAPIv1轉換器，可以生成必要的命令去跟SMAPIv1插件（EXT，NFS，LVM等）并執行它這些插件支持的存儲類型。
在對存儲進行API調用的時候，其都是屬于Master類型的API調用，其Slave主機是沒有權限對磁盤進行執行操作的。因此在內部，SMAPIv1插件使用特權訪問XAPI的數據庫，會將被視為只讀權限的客戶端直接設置只讀字段屬性（例如VDI.virtual_size）。同時由于共享的存儲同時在資源池內被多個主機進行訪問，為了保證數據的安全性，只能允許同一時刻只有一臺主機對其進行對其進行訪問。因此該SMAPIv1插件還協同XAPI對存儲的訪問進行控制，其采用共享存儲常用的鎖機制來對多臺訪問共享存儲的主機進行控制。
XAPI的數據庫包含主機和虛擬機元數據和資源池信息。該數據庫被資源池的Master主機將其副本加載到內存中，與資源池的其他所有Slave進行共享，其他Slave主機通過遠程的方式訪問該數據庫，同時將其同步到本地主機。數據庫將每個API對象所實現的event.next和event.from的存儲在數據庫中。在接收到數據后是以XML格式并且是異步刷新的方式存儲到磁盤中的。如果“重做日志”被啟用，那么所有數據庫的寫入數據會被同步以增量的方式存儲到給出的共享的塊設備中。如果沒有啟用重做日志，那么XAPI在重啟之后，就可能會丟失最近的更新。
同時XAPI還在資源池內實現主機的高可用。高可用性是在資源池內當其中的一臺主機發生故障時，還能保證資源池內的正常運行意以外，還保證出現故障的主機上運行的虛擬機在其他主機上重啟。 XAPI和名為xhad的組件進行緊密集成，實現XenServer資源池的高可用。Xhad是一個主機活躍度監視器。當xhad確認主機發生故障時（其通過監視超時時間和主機與存儲等該設備的連接狀態來判斷），那么XAPI將重新啟動出現故障并且已被HA標記為 “受保護”的虛擬機。 XAPI還可以限制資源利用，以防止資源池變得過于超載，以應對有多個主機故障時沒有資源運行HA。
最后XAPI還承載了實現XE CLI的任務，其XE執行效率和XAPI直接關聯。XE程序遠程控制訪問XAPI命令行，XAPI則根據返回一Shell界面，顯示系列簡單的命令（提示輸入；打印屏幕；取文件；退出等等）。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
