本文將實際操作演練vCHA高可用性架構，協助IT管理人員深入了解vCHA的高可用性運作機制，並搭配VMware官方的最佳建議作法，建構出靈活且高效能的vCHA高可用性架構，有效提升企業私有雲環境中營運服務的SLA服務層級。
從最新Flexera 2020 State of the Cloud Report市調報告中可知，VMware vSphere虛擬化基礎架構在企業和組織的私有雲市占率中仍然穩居首位，如圖1所示。因此，可想而知在VMware vSphere虛擬化架構中，擔任整個虛擬化基礎架構管理中心vCenter Server的重要性。
圖1 市調結果顯示VMware vSphere穩座私有雲市占率首位。 （圖片來源：Flexera 2020 State of the Cloud Report）
當vCenter Server發生故障損壞導致無法進行管理工作任務時，在ESXi主機上運作的VM虛擬主機或容器並不會受到影響，然而管理人員將無法進行任何與vSphere虛擬化架構有關的管理任務，例如線上遷移VM虛擬主機、組態設定vDS或vSS虛擬網路交換器、部署VM虛擬主機或容器等等。
在過往的vCenter Server高可用性解決方案中，最簡單又有效率的方式便是vCenter Server管理平台採用VM虛擬主機的部署方式，並且讓vCenter Server運作在獨立的管理叢集中，同時為管理叢集啟用vSphere HA（High Availability）高可用性機制，如此一來，當vCenter Server運作的底層ESXi虛擬化主機發生故障，便能透過vSphere HA高可用性機制，將vCenter Server重新啟動在管理叢集中其他仍然存活且正常運作的ESXi虛擬化主機上。
由於採用vSphere HA高可用性機制，災難發生時仍會導致vCenter Server產生3～5分鐘的中斷服務時間，因此管理人員倘若不希望災難發生時vCenter Server產生服務中斷情況的話，可以進一步為vCenter Server啟用vSphere FT（Fault Tolerance）高可用性機制。
然而，即便採用最新的vSphere 7版本，啟用vSphere FT機制的VM虛擬主機，最高僅支援至「8 vCPU」處理器，也就是僅能運作「Medium」規模大小的vCenter Server，對於中大型組織來說，常用「Large或X-Large」規模大小的vCenter Server則無法啟用vSphere FT高可用性機制。
在過去的版本中，VMware僅針對運作在實體主機上的vCenter Server推出vCenter Server Heartbeat高可用性機制，而運作在Windows Server VM虛擬主機上的vCenter Server，則是搭配微軟WSFC/MSCS容錯移轉叢集機制，來達成vCenter Server高可用性的目的。
因此，從VMware vSphere 6.5版本開始，VMware官方正式推出專為vCSA（vCenter Server Appliance）管理平台所量身打造的高可用性機制稱為「vCHA（vCenter High Availability）」，如圖2所示。有關vCenter Server管理平台支援的HA高可用性機制詳細資訊，可參考VMware KB 1024051知識庫文章內容。
圖2 vCenter High Availability高可用性運作架構示意圖。 （圖片來源：VMware vSphere Blog - New Walkthroughs for vCenter High Availability）
在本文中，將會深入剖析和實作演練vCHA高可用性架構，以協助企業的IT管理人員深入理解vCHA高可用性運作機制搭配VMware官方的最佳建議作法，建構出靈活且高效能的vCHA高可用性架構，有效提升企業和組織私有雲環境中營運服務的SLA服務層級。
vCHA高可用性基礎架構
在開始建構及組態設定vCHA高可用性機制之前，建議先了解vCHA高可用性基本架構和運作環境需求。首先，在vCHA高可用性機制運作架構中，將會由「Active」、「Passive」、「Witness」這三種不同角色所組成，如圖3所示，當vCHA高可用性機制建構完成，便會形成「Active-Passive」的容錯移轉機制。下列為條列擔任不同角色成員主機所負責的工作任務及功能：
圖3 vCHA高可用性運作架構角色示意圖。 （圖片來源：VMware vSphere Blog - Handling the Lifecycle of a vCenter HA Environment）
‧Active Node：使用vCHA對外服務IP位址並運作vCSA主要執行個體，除了透過HA Network同步資料至Passive Node外，也同時與Witness Node保持通訊確認運作狀態。
‧Passive Node：運作vCSA備援執行個體，透過HA Network不斷接收Active Node傳送過來的變更內容和狀態，當Active Node發生災難事件時，立即接手相關服務和對外服務IP位址。
‧Witness Node：擔任vCHA高可用性架構中仲裁者的角色，當Active Node與Passive Node發生網路分區或中斷隔離事件時，能夠有效避免發生「腦裂」（Split-Brain）的情況。
簡單來說，當擔任「Active Node」角色的vCenter Server，底層的ESXi虛擬化平台發生災難事件時，便會觸發vCHA高可用性機制容錯移轉功能，由擔任「Passive Node」角色的vCenter Server繼承相關服務，並且接手原本Active Node角色所使用的對外服務IP位址。
由於vCHA高可用性機制屬於「Active-Passive」容錯移轉解決方案，所以當災難事件發生時，透過API機制存取的服務可以在2分鐘內繼續使用，而透過GUI圖形介面存取的使用者可在4分鐘內繼續使用。
因此，vCHA高可用性機制的RTO原則上在「5分鐘」之內，便能完成相關服務和對外服務IP位址的容錯移轉工作任務，雖然實際上仍必須視底層硬體資源的工作負載情況而定。
vCHA部署模式
建構vCHA高可用性機制時，管理人員可以採用「自動」（Automatic）或「手動」（Manual）模式。這兩種部署模式最大的差別在於，採用「自動」模式部署vCHA高可用性機制時，系統會透過vCenter HA精靈互動的方式，自動建立和組態設定Passive Node和Witness Node主機。
而採用「手動」模式部署vCHA高可用性機制時，則必須由管理人員手動將Active Node主機進行複製的動作，再組態設定Passive Node與Witness Node主機。
值得注意的是，VMware官方已經宣佈，目前主流的vSphere 6.7版本是最後一版支援「External」PSC部署模式。因此，企業和組織倘若採用External的PSC部署模式，準備建構vCHA高可用性機制的話，請管理人員確保至少部署2個External PSC執行個體，並且搭配負載平衡設備指向至PSC執行個體，相關詳細資訊請參考VMware KB 60229、KB 2147014、KB 2147038、KB 2147046知識庫文章。
vCHA軟體版本需求
正式建構vCHA高可用性機制前，必須確保採用的vCenter Server和ESXi版本，正確支援vCHA高可用性機制並符合最低硬體資源需求：
‧ESXi虛擬化平台：至少採用ESXi 6.5或後續版本，並且vSphere Cluster建議至少有3台ESXi成員主機，同時讓每個vCHA角色運作在不同的ESXi成員主機上以確保高可用性，並建議為vSphere Cluster啟用vSphere DRS負載平衡機制。
‧vCenter Server：至少採用vCenter Server 6.5或後續版本，同時為了滿足vCHA高可用性機制的基本RTO需求，部署的vCSA規模大小至少要採用「Small」或更大規模，並支援部署在VMFS、NFS、vSAN Datastore等儲存資源中。
‧軟體授權：建構vCHA高可用性機制，雖然運作3台不同角色的vCenter Server，但僅需要「1套」vCenter Server Standard軟體授權即可。
vCHA網路環境需求
在vCHA高可用性運作架構中，至少應規劃兩種不同用途的網路環境，分別是「管理網路」（Management Network）和「vCenter高可用性網路」（vCenter HA Network）。管理網路除了管理用途外，也是屆時Active Node和Passive Node使用對外服務IP位址的網段。
在vCenter高可用性網路的部分，主要用途為同步資料和組態設定以及「心跳」（Heartbeats）。舉例來說，當vCHA高可用性機制建構完成後，Active Node和Passive Node主機之間，將會不斷同步PostgreSQL資料庫內容和運作狀態等資訊。
值得注意的是，根據VMware最佳建議作法，vCenter高可用性網路必須為小於「10毫秒（ms）」延遲時間的網路環境，如圖4所示。倘若Active Node和Passive Node主機之間，網路環境無法達到資料同步的基本要求時，將會導致兩台主機之間的PostgreSQL資料庫內容不一致，並且vCHA高可用性機制會退化為「非同步」狀態，導致出現非預期的錯誤或屆時造成容錯移轉失敗的情況。
圖4 vCenter高可用性網路必須為小於10ms延遲時間的網路環境示意圖。 （圖片來源：VMware vSphere Blog - vCenter High Availability Deep Dive - Part 1）
實戰vCHA高可用性機制
了解vCHA高可用性機制基礎架構和最佳作法後，接著開始進行vCHA高可用性機制的實作演練。這裡將採用自動組態設定的方式部署vCHA高可用性機制，下列為建構vCHA高可用性機制的流程說明：
1. 部署第一台vCenter Server主機，屆時將擔任Active Node角色。
2. 管理人員為每台ESXi虛擬化平台，新增擔任HA Network用途的Port Group。
3. 啟用vCenter HA組態設定精靈，在自動化工作流程中提供IP位址、目標ESXi主機或vSphere叢集、目標Datastore儲存資源。
4. 系統自動複製Active Node主機，產生Passive Node角色的主機並套用相關組態。
5. 系統再次自動複製Active Node主機，然後產生Witness Node角色的主機並套用相關組態設定。
6. 系統組態設定3台主機透過HA Network進行通訊，確保資料交換和「心跳」（Heartbeats）及其他通訊作業運作正常。
7. vCHA高可用性機制建構完成。
值得注意的是，雖然管理人員可以在任何時間啟用vCHA高可用性機制，但是根據VMware最佳建議作法，應該在離峰時間才啟用vCHA高可用性機制。主要原因在於，當啟用vCHA高可用性機制時，系統會立即執行Active Node和Passive Node兩台主機之間的PostgreSQL資料庫同步作業，倘若Active Node處於工作負載高峰期間的話，有可能導致Passive Node的PostgreSQL資料庫無法即時同步，而造成vCHA高可用性機制發生非預期的錯誤。
部署第一台vCenter Server
在本文實作環境中，採用VMware最佳建議作法準備3台ESXi虛擬化平台，並且部署第一台vCenter Server至其中的ESXi虛擬化平台上，另外2台ESXi虛擬化平台屆時將負責運作Passive Node和Witness Node主機。除此之外，部署的第一台vCenter Server採用「Small」規模大小，以及vCenter Server 7預設採用的Embedded部署模式。
必須注意的是，於部署第一台vCenter Server的第二階段時，在vCenter Server Configuration頁面中，記得啟用「SSH Access」功能，因為這是vCHA高可用性功能的必要需求之一，如圖5所示。
圖5 建構vCHA高可用性機制，vCenter Server至少要採用Small規模大小。
倘若安裝過程中忘記啟用vCenter Server的SSH Access功能，也可於安裝完成後透過vCenter Server系統管理介面（Port 5480）來設定，在登入後進行SSH Access特色功能啟用的動作。
新增vCenter HA Network虛擬網路環境
在本文實作環境中，規劃vCenter Server管理網路的網段是「10.10.75.0/24」，而vCenter高可用性網路的網段則為「192.168.75.0/24」，並且這兩個虛擬網路環境分別採用不同的vSwitch虛擬網路交換器。
登入vCenter Server管理介面後，依序點選「ESXi Host > Configure > Networking > Virtual Switches > Add Networking > Virtual Machine Port Group for a Standard Switch > New standard switch」，選擇專屬用於vCenter高可用性網路的實體網路卡，本文實作環境為「vmnic1」。
緊接著，在Connection Settings視窗之中，於Network Label欄位內填入名稱「vCHA HA Network」，這個新增的vSwitch虛擬網路交換器以及Port Group，便是負責vCenter高可用性虛擬網路用途，實際結果如圖6所示。
圖6 新增專用於vCenter高可用性的vSwitch和Port Group。
啟用vCHA高可用性機制
相關前置作業都已準備完成，接著在vCenter Server管理頁面中依序點選「vCenter Server > Configure > Settings > vCenter HA > Set Up vCenter HA」項目，準備正式啟用vCHA高可用性機制。
首先，在Resource Settings頁面中，按下「BROWSE」選擇剛才新增專用於vCenter高可用性虛擬網路的「vCHA HA Network」，並確認「Automatically create clones for Passive and Witness nodes」項目已勾選，如圖7所示。
圖7 組態設定vCHA高可用性機制中，管理網路和vCenter高可用性網路。
接著，分別為Passive Node和Witness Node選擇運作環境，本文實作環境中將Passive Node部署至「esxi7-n02」虛擬化平台，而Witness Node則部署至「esxi7-n03」虛擬化平台。必須注意的是，Witness Node在vNetwork虛擬網路的部分只要選擇vCHA HA Network，即可無須管理網路。
在第二階段IP Settings頁面中，管理人員必須組態設定Active Node、Passive Node、Witness Node這三台主機在vCHA高可用性網路中使用的IP位址，本文實作環境依序為192.168.75.21、192.168.75.22、192.168.75.23，如圖8所示。
圖8 組態設定vCenter HA同步專屬網路IP位址。
待系統完成自動複製及建立Passive Node、Witness Node，並且組態設定vCenter HA Cluster之後，vCHA高可用性機制便正式完成，並且運作模式為「Enabled」，運作狀態為「Healthy」，如圖9所示。
圖9 順利建構和啟用vCHA高可用性機制。
驗證vCHA容錯移轉機制
成功啟用vCHA高可用性機制後，管理人員可以先手動測試vCHA容錯移轉機制，將Active Node和Passive Node角色進行切換，確認屆時災難發生時能夠順利進行容錯移轉。
在vCenter Server管理介面中，依序點選「vCenter Server > Configure > Settings > vCenter HA > Initiate Failover」項目，在彈出的Initiate vCenter HA failover視窗中，如圖10所示，VMware建議除非有特殊情況，否則請勿勾選「Force the failover to start immediately withou waiting ...」項目，原因在於若強制執行容錯移轉的動作，Active Node和Passive Node之間資料有可能尚未同步完成，而導致資料遺失或發生非預期的錯誤。
圖10 準備手動執行vCHA容錯移轉的動作。
事實上，vCHA高可用性機制針對不同的資料屬性採用不同的同步方式，以便保持Active Node和Passive Node主機狀態的一致性。
在vCenter Server資料庫部分，採用內嵌的「PostgreSQL資料庫」，並直接透過PostgreSQL資料庫原生「複寫」（Replication）機制，保持Active Node與Passive Node主機資料庫同步以及內容的一致性。至於「組態設定檔」的部分，則使用Linux作業系統中原生的「Rsync」複寫機制，達成Active Node和Passive Node主機組態設定檔內容的一致性。
經過幾分鐘的vCHA容錯移轉程序後，重新連接至vCenter Server管理介面，可以看到原本擔任Passive Node角色的主機，已經切換成Active Node角色，並且接手原本的vCenter Server對外服務的IP位址「10.10.75.20」，如圖11所示。
圖11 原本Passive Node角色主機順利接手Active Node角色和對外服務IP位址。
vCHA高可用性機制的維運管理
以下分成確保運作在不同台ESXi主機、vCHA進入維護模式、vCHA如何因應不同的災難事件等三部分來做說明。
確保運作在不同台ESXi主機
雖然已經順利建構vCHA高可用性機制，並且驗證vCHA容錯移轉機制能夠順利切換，但是在正式營運環境中應搭配啟用vSphere Cluster DRS規則，確保Active、Passive、Witness這三台主機能夠各自分散運作在「不同台」ESXi虛擬化平台上。
在vCenter Server管理介面中，依序點選「Cluster > Configure > Configuration > VM/Host Rules > Add」項目，在彈出的Create VM/Host Rule視窗中填入此規則名稱，本文實作名稱為「vCHA Role Separate」。
然後，在Type下拉式選單中選擇至「Separate Virtual Machines」項目，確保此規則套用後，Active、Passive、Witness角色主機不會運作在同一台ESXi主機上，最後按下〔Add〕按鈕，加入Active、Passive、Witness角色主機即可，執行過程如圖12所示。
圖12 新增Separate Virtual Machines規則，確保不同vCHA角色主機不會運作在同一台ESXi主機上。
vCHA進入維護模式
當vCenter Server需要進行相關維運工作時，為了避免系統誤判，導致觸發vCHA容錯移轉機制，管理人員可以在維運工作進行之前，設法先讓vCHA高可用性機制進入「維護模式」（Maintenance Mode）。
依序點選「vCenter Server > Configure > Settings > vCenter HA > Edit」項目，然後在彈出的Edit vCenter HA視窗中選擇「Maintenance Mode」項目。
此時，在管理介面中，將看到vCenter HA運作模式由原本的Enabled轉換為「Maintenance」，同時系統資訊也顯示「Automatic failover」機制已經停用，但管理人員仍然可以進行手動容錯移轉，如圖13所示。
圖13 組態設定vCHA高可用性機制進入維護模式。
vCHA如何因應不同的災難事件
事實上，在vCHA高可用性機制的運作架構下，當發生各種不同的災難事件時，例如硬體、軟體、網路環境等等，在什麼情況下才會觸發Passive Node接手Active Node服務以及對外服務IP位址？以下將列舉當發生各種不同的災難事件時，vCHA高可用性機制將如何因應：
‧Active Node發生災難事件時：只要Passive Node與Witness Node能夠正常通訊，那麼Passive Node將會提升為Active Node角色，接手相關服務和對外服務IP位址並回應客戶端提出的請求。
‧Passive Node發生災難事件時：只要Active Node與Witness Node能夠正常通訊，那麼Active Node將持續保持原有角色，繼續回應客戶端提出的請求。
‧Witness Node發生災難事件時：只要Active Node與Passive Node能夠正常通訊，那麼Active Node將持續保持原有角色，繼續回應客戶端提出的請求。同時，Passive Node將會偵測Active Node是否正常運作，以便隨時進行容錯移轉角色切換作業。
‧主機隔離中斷行為：當單台主機發生網路中斷事件，在經過間歇性網路故障偵測程序及所有重試機制都耗盡後，系統才會將該台角色主機判定為隔離狀態，同時進入隔離狀態的主機將會自動停止所有服務。例如，當Active Node被判定為隔離狀態，那麼Active Node將從vCHA中移出並停止所有服務，確保Passive Node能夠接手成為Active Node角色，並開始回應客戶端提出的請求。
‧多台節點發生故障：原則上，vCHA高可用性機制只能因應「單台」角色主機發生故障，無法因應「多台」角色主機同時發生故障。舉例而言，當實體網路發生嚴重的災難事件而導致Active、Passive、Witness這三台主機無法互相通訊，此時vCHA高可用機制將無法正常運作，因為在vCHA高可用性機制的設計中並無法容許同時發生多項故障。
結語
透過本文的深入剖析及實作演練，管理人員應該理解在最新vCenter Server 7版本中，vCHA高可用性機制和基礎架構，同時搭配VMware最佳建議作法，將可為企業和組織建構出高效能、高可用性和高靈活性的vCenter Server管理平台。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞