五種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所示。


▲圖8 Symantec Application HA 運作示意圖。(圖片來源:VMware白皮書 – Virtualizing Business-Critical Applications with Confidence)


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!