本文將介紹vSphere 6.5內的VCHA高可用性運作架構，提出原廠的最佳建議作法，並說明在這個新版本中如何針對vMotion即時遷移流量進行加密，避免遭受中間人攻擊，預防被竄改記憶體，以保護VM虛擬主機進行vMotion遷移時的安全性。
‧ Witness Node故障損壞時：只要Active Node與Passive Node能夠互相通訊，那麼Active Node將繼續保持Avtive Node的角色，並且繼續回應客戶端提出的請求。同時，Passive Node將繼續偵測Active Node是否正常運作，以便隨時準備進行故障切換作業。
‧ 多台節點發生故障或發生網路隔離：表示Active、Passive、Witness這三台節點主機彼此無法互相通訊。此時，VCHA叢集將無法正常運作並且可用性也受到影響，因為VCHA高可用性機制的設計無法容許同時發生多項故障。
‧ 節點隔離行為：當單一節點主機發生網路中斷事件，在經過間歇性網路故障偵測程序及所有重試機制都耗盡後，系統才會將該台節點主機判定為隔離狀態，同時進入隔離狀態的節點主機會自動停止所有服務。舉例來說，倘若Active Node發生隔離狀態時，那麼Active Node將會從叢集中移出並停止所有服務，以便確保Passive Node能夠接手角色成為Avtive Node，並且開始回應客戶端提出的請求。
部署VCHA高可用性的最佳作法
在vCSA 6.5版本中，每台vCSA支援管理最多64叢集、2,000台ESXi主機、35,000台註冊的VM虛擬主機、20,000台開機的VM虛擬主機。同時，不同運作規模大小，對於vCSA硬體資源的配置建議也不同，表1便是VMware官方針對不同運作規模的vCSA硬體資源建議。
表1 針對不同運作規模的vCSA硬體資源建議
雖然，VMware建立的VCHA高可用性機制運作架構非常簡單易用，但是vSphere管理人員應該遵循最佳作法，以便讓VCHA高可用性機制運作效能更佳之外也更穩定：
‧ 離峰時間才啟用VCHA機制：雖然可以在vCenter Server運作的任何時間啟用VCHA高可用性機制，但是VMware強烈建議在工作負載的離峰時間再啟用。主要原因在於，建立VCHA高可用性機制後，系統便會立即執行PostgreSQL資料庫同步作業，倘若在工作負載高峰時啟用的話，那麼Passive Node的PostgreSQL資料庫有可能會來不及同步。
‧ 僅容許單台節點發生故障：在VCHA高可性機制的運作架構下只有3台節點主機，所以容許故障的節點主機數量不能超過「單台」。因此，每台節點主機的角色應部署在不同x86硬體伺服器上，以避免硬體伺服器發生故障損壞事件時直接影響所有角色。另外，每台節點主機也應部署在獨立且隔離的Datastore儲存資源中，以避免將3台節點主機都部署在同一個Datastore儲存資源中，導致發生SPOF單點失敗的問題，進而影響VCHA高可用性機制。
除此之外，在VCHA高可用性運作架構中，網路環境應該具備低延遲時間、高傳輸頻寬、隔離且專用的網路，以避免因為不適當的網路環境而影響VCHA高可用性機制的運作及效能。下列為VCHA高可用性網路環境規劃設計的最佳建議作法：
‧ 採用隔離且專用的網路：因為在VCHA高可用性機制運作架構中，Active Node與Passive Node之間必須不斷同步PostgreSQL資料庫的資料，倘若2台節點主機之間的網路頻寬無法達到資料同步要求時，那麼將會退化為非同步並導致PostgreSQL資料庫內容相異。
‧ 支援高達10毫秒的低延遲網路：在VCHA高可用性機制運作架構中，可以支援高達10毫秒（ms）網路環境延遲時間。倘若，網路環境的延遲時間高於10毫秒時，那麼VCHA高可用性機制仍然能夠順利運作，但是將會產生延遲操作、低輸送量、效能損失等運作不佳的情況。
圖3是VMware官方透過VCbench壓力測試軟體針對VCHA高可用性運作環境進行壓力測試的結果。其中採用64-clients方式為最貼近實務應用的工作負載，當延遲時間高達5毫秒時那麼傳輸量將會下降9%，倘若延遲時間高達10毫秒時傳輸量更會下降15%。
 |
| ▲ 圖3 透過VCbench針對VCHA網路環境進行壓力測試的統計數據。（資料來源：VMware白皮書 – vCenter Server High Availability Performance and Best Practices） |
若是更進一步，採用256-clients方式以更極端的工作負載方式進行壓測時，當延遲時間高達5毫秒，傳輸量會下降23%，倘若延遲時間高達10毫秒時，傳輸量更會下降27%。
VCHA vMotion即時遷移的安全性
過去，在VMware vSphere虛擬化運作環境中，針對vMotion線上遷移傳輸流量的規劃及設計，除了應規劃獨立專用的網路環境以便快速遷移線上運作的VM虛擬主機外，規劃獨立專用網路環境的另一個考量便是「安全性」。
因為，在預設情況下，當vSphere管理人員透過vMotion線上遷移機制，將線上運作中的VM虛擬主機從來源端ESXi主機傳輸至目的端ESXi主機的過程中，vMotion傳輸流量並「未進行加密」。
同時，透過vMotion所傳輸的是VM虛擬主機的「記憶體狀態」，惡意攻擊者有可能在傳輸期間修改記憶體狀態內容，進而達到破壞VM虛擬主機應用程式或作業系統的目的，所以規劃獨立專用網路環境時，除了網路頻寬獨享之外，同時也達到vMotion傳輸流量安全性隔離的效果。
在2015年3月推出的VMware vSphere ESXi 6.0版本中，vMotion線上遷移傳輸機制打破地域及環境的限制。新版vMotion即時遷移機制不只可以跨越vSwitch虛擬交換器以及跨越不同的vCenter Server伺服器外，更能夠跨越地域的限制。只要執行vMotion線上遷移的網路環境，能夠支援封包延遲時間在100毫秒之內的話，那麼就能達成跨越地域限制的vMotion即時遷移。