建構高效靈活vCenter　提升企業營運服務SLA層級

由於vCHA高可用性機制是屬於「Active-Passive」的容錯移轉解決方案，所以災難事件發生時透過API存取的使用者在2分鐘內便可以繼續使用，而透過UI存取的使用者在4分鐘就能夠繼續存取，原則上，vCHA高可用性機制的RTO通常在「5分鐘」之內便可完成所有容錯移轉作業。當然，實際上還必須視底層硬體資源的工作負載情況而定。

vCHA硬體資源及軟體版本需求

在組態設定vCHA高可用性機制之前，管理人員必須確保採用的是支援vCHA機制的vCenter Server和ESXi版本，並且也須符合最低硬體資源需求，例如擁有足夠的CPU與Memory運算資源。

‧ESXi虛擬化平台：至少採用ESXi 6.0或後續版本，並且vSphere Cluster建議至少擁有3台ESXi主機，且讓每個vCHA角色分別運作在不同的ESXi主機上以確保高可用性。同時，建議為vSphere Cluster啟用vSphere DRS負載平衡機制。

‧vCenter Server Appliance：至少採用vCSA 6.5或後續版本，同時為了滿足基本的RTO需求，所以vCSA部署大小至少需要採用Small（4 vCPU及16GB vRAM）或更大規模。此外，vCHA高可用性機制支援管理人員將vCSA部署在VMFS、NFS、vSAN Datastore儲存資源內。

‧採用隔離且專用的良好網路環境：因為在vCHA高可用性機制運作架構中，Active Node與Passive Node之間，必須不斷同步PostgreSQL資料庫的資料和相關運作資訊，倘若2台節點主機之間的網路頻寬無法達到資料同步要求時，那麼vCHA高可用性機制將會退化為「非同步」狀態，同時導致PostgreSQL資料庫內容相異。因此，除了必須採用與vCSA管理網路不同的子網路之外，在Active、Passive、Witness節點主機之外，必須採用小於「10ms」延遲時間的網路環境，如圖3所示。

除了上述vCHA高可用性機制的硬體資源及軟體版本需求外，管理人員還應注意下列兩項最佳建議作法，以確保vCHA高可用性機制的運作效能及穩定性：

‧在離峰時間啟用vCHA機制：事實上，管理人員可以在任何時間啟用vCHA高可用性機制，但根據VMware最佳建議作法則是應在離峰時間再進行啟用。主要原因是，一旦啟用vCHA高可用性機制之後，系統將會立即執行Active Node及Passive Node的PostgreSQL資料庫同步作業，此時如果正處於工作負載的高峰時間，有可能會導致Passive Node的PostgreSQL資料庫無法即時同步，造成後續容錯移轉時發生非預期的錯誤。

‧僅容許單台節點發生故障：由於目前的vCHA高可性機制為Active-Passive容錯移轉架構，所以容許故障的節點主機數量無法超過「單台」。因此每台節點主機的角色應部署在不同的ESXi虛擬化平台上，以避免單一ESXi虛擬化平台發生災難事件時直接影響所有角色的運作。此外，每台vCHA節點主機也應部署在獨立且隔離的Datastore儲存資源中，避免將3台vCHA節點主機都部署在同1個Datastore儲存資源中，導致發生SPOF單點失敗的問題，進而影響vCHA高可用性機制。

vCHA部署模式

vCHA高可用性機制，可以搭配vCSA「embedded或external」的Platform Services Controller部署模式。

值得注意的是，倘若vCSA採用「external Platform Services Controller」部署模式時，就必須要置於負載平衡設備「後面」，以便Platform Services Controller發生災難事件能夠進行容錯移轉。

首先，說明採用vCSA Embedded部署模式時建立vCHA高可用性機制的流程：

1. 採用vCSA Embedded部署模式建立vCSA管理平台。

2. 登入vCSA管理平台管理介面，並啟用「vCenter HA」機制。

3. 啟用vCHA高可用性機制後，系統將會以Active Node為來源複製出Passive Node和Witness Node。

4. 確保Active Node與Passive Node完成「資料同步」作業，包括PostgreSQL資料庫、Platform Services Controller及其他服務，如圖4所示。

5. 當Active Node發生災難事件時，Passive Node將使用同步後的所有資料、服務以及原本Active Node的「服務IP位址」。