> 專題報導

五種VMware自家HA機制建構高可用性vCenter服務

VMware vSphere ESXi 6.0將vCenter Server的運作架構大幅翻新，而其他協同運作元件也全部整合成單一的PSC，面對這些新變革，本文將針對VMware提供的諸多vCenter Server高可用性解決方案，說明其個別的功能性及採用時的要點，讓IT人員正確選出對自身最合適的方案。

vCenter Server 6.0新增了「Watchdog」監控機制，採用vCenter Server Processes（PID Watchdog）或vCenter Server API（API Watchdog）的方式，來偵測vCenter Server虛擬主機中本身所運作的服務。

當運作的服務發生故障事件而停止運作，前2次發生時，Watchdog會嘗試重新啟動服務，倘若第3次仍無法重新啟動服務，便會將VM虛擬主機重新啟動，如圖6所示。

▲圖6 整合vSphere HA及Watchdog機制保護vCenter Server服務示意圖。（圖片來源：VMware白皮書 – VMware vCenter Server 6.0 Availability Guide）

在預設情況下，Watchdog監控機制便會自動啟用，它也支援vCenter Server Appliance與Windows vCenter Server作業平台。

高可用性方案2：vSphere FT

VMware vSphere Fault Tolerance（vSphere FT）特色功能，在過去舊版本中一直被IT管理人員所詬病的就是VM虛擬主機的vCPU數量。現在，新版vSphere 6.0中的FT功能，其VM虛擬主機最多已經可以支援至4 vCPU。

同時，在舊版的Fault Tolerance運作環境中，欲啟用FT功能的VM虛擬主機，除了不能建立任何快照（Snapshot）外，虛擬磁碟也只能使用EZT（Eager Zeroed Thick）格式。新版的FT功能除了支援VM虛擬主機能夠建立快照之外，在虛擬磁碟的部分也支援所有格式，現在已經可以使用Thin、Thick、EZT等三種格式的虛擬磁碟。

最後，在舊版的Fault Tolerance運作機制中，主要及次要VM虛擬主機之間，資料同步的方式稱之為「Record-Replay」。新版的Fault Tolerance則將資料同步機制改變為「Fast Checkpointing」，其運作機制是透過xvMotion（Cross-vCenter vMotion），採用持續不斷且大量的Checkpoints（Multiple/Sec）動作，以達成主要及次要VM虛擬主機間的資料同步作業。

與vSphere HA高可用性機制不同的地方在於，當Cluster內的ESXi主機發生非計畫性故障損壞事件時，vSphere HA所保護的vCenter Server虛擬主機，會從Cluster中其他存活的ESXi主機上「重新啟動」，因此vCenter Server服務的中斷時間大約會是2?5分鐘之間（實務上視儲存設備的運作效能而定）。

而vSphere FT高可用性機制，因為平時主要及次要VM虛擬主機之間，便已經透過Fast Checkpointing技術同步兩台主機之間的資料，因此當Cluster內的ESXi主機發生非計畫性故障損壞事件時，雖然主要VM虛擬主機故障損壞無法服務，但次要VM虛擬主機會立即接手所有服務，並且將自身角色轉變成為主要主機，同時在另一台ESXi主機上再建立一台次要主機，將目前的資料透過Checkpointing技術再次同步，整個vCenter Server服務接手期間是沒有中斷的（Zero Downtime），同時也不會有任何資料遺失的問題（Zero Data Loss），如圖7所示。

▲圖7 整合vSphere FT機制保護vCenter Server服務示意圖。（圖片來源：VMware白皮書 – VMware vCenter Server 6.0 Availability Guide）

雖然，相較於vSphere HA機制，vSphere FT提供更即時的保護，但仍有下列限制及注意事項必須考量：

1. 啟用vSphere FT機制的vCenter Server虛擬主機，最多僅支援至4 vCPU及64GB Memory，這樣的VM虛擬主機規模無法承受大型虛擬化架構的工作負載。

2. 啟用vSphere FT機制的vCenter Server虛擬主機，vCPU及vRAM虛擬資源將會重置為「保留（Reservation）」狀態且無法更改，虛擬磁碟也無法增加或刪除。

3. vSphere FT機制主要是因應ESXi主機發生硬體故障事件（Host Level），而無法因應vCenter Server應用程式發生的軟體故障事件（Application Level）。

4. vSphere FT機制無法因應主機進行更新或修復作業所產生的停機時間。

5. 啟用vSphere FT機制後，除了多出1台次要主機增加資源消耗之外，由於2台主機之間會有大量且頻繁的同步資料行為，因此需要專用10Gbps且低延遲的VMkernel網路環境。

6. 驗證透過vSphere Web Client連線至vCenter Server 的使用者帳號，是否具備Cluster Administrator權限。

高可用性方案3：協力廠商工具

VMware在vSphere HA機制中，已經開放Application Monitoring API介面，讓協力廠商可以透過API與vSphere HA機制整合在一起，達到保護VM虛擬主機上運作的應用程式或服務（Application Level），以補足vSphere HA機制只有Host Level的缺口。

例如Symantec ApplicationHA便是這類的協力廠商工具，此類工具會在VM虛擬主機中安裝代理程式並監控應用程式的健康情況，當應用程式或服務發生錯誤無法啟動時，代理程式會把狀態轉送及回報給vSphere HA，以便透過vSphere HA機制將VM虛擬主機重新啟動，如圖8所示。