本文將深入剖析最新vCenter Server 8 U1版本中的vCHA高可用性機制和運作架構，並且進行實戰演練，依據VMware官方提出的最佳建議作法來示範說明，讓企業和組織能夠輕鬆地建構出高可用性並具備靈活應用的vCenter Server管理平台。
在VMware vSphere虛擬化架構中，vCenter Server在虛擬化架構內的重要性不言而喻，雖然vCenter Server發生災難事件的時候，ESXi主機上運作的VM虛擬主機或容器等工作負載並不會因此受到影響，然而管理人員將無法進行其他管理任務，例如無法線上遷移VM虛擬主機、無法再部署VM虛擬主機或容器等等。
過去，vCenter Server高可用性解決方案中，最簡單的方式是採用VM虛擬主機的方式來部署vCenter Server管理平台，並且運作在獨立且啟用vSphere HA的vSphere管理叢集中，一旦底層ESXi虛擬化主機發生災難事件時，便能夠依靠vSphere HA高可用性機制將vCenter Server主機重新啟動，繼續運作在其他仍然存活的ESXi虛擬化主機上。
現在，可以透過建構及部署vCHA（vCenter High Availability）機制，搭配原有的vSphere HA高可用機制，讓vCenter Server的整體SLA能夠更加提升。在vCHA高可用性機制運作架構中，將會由Active、Passive、Witness這三種不同角色所組成，當vCHA高可用性機制建構完成後，便會形成Active-Passive的容錯移轉機制。下列為不同角色成員主機負責的工作任務及功能：
‧Active Node：使用vCenter Server對外服務IP位址，並啟用vCenter Server系統服務，除了透過HA Network同步資料至Passive Node之外，也同時與Witness Node保持通訊。
‧Passive Node：運作vCenter Server備援主機，透過HA Network不斷接收Active Node主機所傳送過來的變更內容和狀態，當Active Node發生災難事件時，自動接手vCenter Server IP位址，並啟動vCenter Server系統服務。
‧Witness Node：擔任vCHA高可用性架構中的仲裁者角色，一旦Active Node或Passive Node主機發生網路分區或網路中斷隔離事件時，能夠有效避免發生「腦裂」（Split-Brain）的情況。
vCHA部署模式
建構及部署vCHA高可用性機制時，可以採用「自動」（Automatic）或「手動」（Manual）模式。這兩種部署模式最大的差別在於，採用「自動」模式部署vCHA高可用性機制時，系統將會透過vCenter HA精靈互動的方式，自動建立及組態設定Passive Node和Witness Node主機。採用「手動」模式時，則必須手動將Active Node主機，進行複製的動作後再組態設定Passive Node和Witness Node主機。
vCHA軟體需求
在建構和部署vCHA高可用性機制前，須確保採用的vCenter Server和ESXi版本支援vCHA高可用性機制並符合最低硬體資源需求。
‧ESXi虛擬化平台：至少為ESXi 6.0或更新版本，並且vSphere叢集建議至少有3台ESXi成員主機，以便每個vCHA角色運作在不同ESXi成員主機以確保高可用性，並建議為vSphere叢集啟用vSphere DRS負載平衡機制。
‧vCenter Server：至少為vCenter Server 6.5或後續版本，為了滿足vCHA高可用性機制的基本RTO需求，部署的vCSA規模大小至少要採用Small或更大規模，支援部署在VMFS、NFS、vSAN Datastore等儲存資源中。
‧軟體授權：建構vCHA高可用性機制，雖然運作3台不同角色的vCenter Server，但僅需要「1套」vCenter Server Standard軟體授權即可。值得注意的是，採用vCenter Server Foundation或vCenter Server Essentials版本，不支援建構vCHA高可用性機制。
vCHA網路需求
在vCHA高可用性運作架構中，至少應規劃兩種不同用途的網路環境，分別是「管理網路」（Management Network）和「vCenter高可用性網路」（vCenter HA Network）。
管理網路除了管理用途外，平時為Active Node主機使用vCenter Server IP位址，災難事件發生時，Passive Node接手後容錯移轉的vCenter Server IP位址。
而vCenter高可用性網路，主要用途為資料庫和組態設定同步作業，以及主機互相偵測是否存活的「心跳」（Heartbeats）。舉例來說，當vCHA高可用性機制建構完成後，Active Node和Passive Node主機之間，將會不斷地同步PostgreSQL資料庫內容和運作狀態等資訊。 值得注意的是，根據VMware最佳建議作法，vCenter高可用性網路必須小於10毫秒（ms）延遲時間的網路環境。倘若Active Node和Passive Node主機之間，網路環境無法達到資料同步的基本要求時，將會導致兩台主機之間的PostgreSQL資料庫內容不一致，並且vCHA高可用性機制會退化為「非同步」狀態，導致出現非預期的錯誤或容錯移轉失敗的情況，如圖1所示。
圖1 vCHA高可用性網路必須小於10ms延遲時間網路環境示意圖。 （圖片來源：VMware vSphere Blog - vCenter High Availability Deep Dive）
實作vCHA高可用性機制
理解vCHA高可用性機制基礎架構和最佳作法後，便開始進行vCHA高可用性機制的實作演練。值得注意的是，雖然可以在任何時間啟用vCHA高可用性機制，然而VMware最佳的建議是，在離峰時間再啟用vCHA高可用性機制比較妥當。
主要原因在於，當啟用vCHA高可用性機制時，系統會立即執行Active Node與Passive Node兩台主機之間的PostgreSQL資料庫同步作業，如果Active Node處於工作負載高峰期的話，有可能導致Passive Node的PostgreSQL資料庫無法即時同步完成，導致屆時vCHA高可用性機制發生非預期的錯誤。
部署vCenter Server管理平台
根據VMware最佳建議作法，管理人員應該為vCenter Server高可用性機制準備3台ESXi虛擬化平台，分別部署vCenter Server至其中1台ESXi虛擬化平台，另外2台ESXi虛擬化平台，屆時則分別運作備援角色的Passive Node主機，以及見證角色的Witness Node主機，如圖2所示。
圖2 vCHA高可用性運作架構示意圖。 （圖片來源：vCenter HA 架構概觀 | VMware Docs（vmware.com））
此外，在部署vCenter Server管理平台時，至少要採用Small或更大的部署規模大小，否則屆時將無法順利啟用vCHA高可用性機制。最新的vCenter Server 8 U1版本與過去舊版的vCenter Server相較之下，需要更多的硬體資源，例如Small部署規模大小需要4 vCPUs、21GB vMemory、694GB vStorage硬體資源，如圖3所示。
圖3 vCenter Server至少採用Small Size才能啟用vCHA高可用性機制。
值得注意的是，部署vCenter Server管理平台時，在vCenter Server Configuration頁面中，SSH Access欄位內將預設值Deactivated調整為Activated，組態設定vCenter Server啟用SSH Access功能，確保vCHA高可用性機制屆時能順利啟用。
如果在部署vCenter Server管理平台時，忘記為vCenter Server啟用SSH Access功能的話，在啟用vCHA高可用性機制之前，登入vCenter Server管理介面（Port 5480），依序點選「Access > Access Settings > Edit」，啟用「Activate SSH Login」項目，進行啟用SSH Access功能的動作，如圖4所示。
圖4 確保vCenter Server啟用SSH Login功能。
新增vCenter HA Network虛擬網路環境
在本文實作環境中，規劃vCHA管理用途網路的網段為「10.10.75.0/24」，而vCHA高可用性用途網路的網段為「192.168.75.0/24」，同時組態設定這兩個不同的虛擬網路環境，分別採用不同的vSwitch虛擬網路交換器，以及不同的實體網路卡，以避免SPOF單點失敗的情況發生。
登入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 Heartbeat」，這個新增的vSwitch虛擬網路交換器及Port Group，便是負責vCHA架構中高可用性用途的虛擬網路，如圖5所示。由於採用的是vSS虛擬網路交換器，因此依序為3台ESXi主機新增vCHA Heartbeat虛擬網路。
圖5 新增專用於vCHA架構中高可用性用途的虛擬網路。
啟用vCHA高可用性機制
前置作業準備完畢後，在vCenter Server管理頁面中，依序點選「vCenter Server > Configure > Settings > vCenter HA > Set Up vCenter HA」項目，準備正式啟用vCHA高可用性機制，如圖6所示。系統也在下方提醒管理人員預先建立vCenter HA Network，並且準備Heartbeat用途的固定IP位址，當這些前置作業已經完成，就可以放心按下〔Set Up vCenter HA〕按鈕。
圖6 準備部署並啟用vCHA高可用性機制。
在1. Resource Settings頁面中，按下〔BROWSE〕選擇剛才新增專用於vCenter高可用性虛擬網路的「vCHA Heartbeat」，並勾選「Automatically create clones for Passive and Witness nodes」項目。
接著，分別為擔任備援角色的Passive Node主機以及見證角色的Witness Node主機選擇運作環境，點選Passive Node區塊中的Edit，選擇將備援主機部署至「vcha02.lab.weithenn.org」虛擬化平台，而Witness Node則部署至「vcha03.lab.weithenn.org」虛擬化平台。值得注意的是，Witness Node在vNetwork虛擬網路的部分，只要選擇vCHA HA Network即可無須管理網路。
在本文實作環境中，vCHA運作架構的3台VM虛擬主機，都統一存放在vSAN超融合儲存資源當中，倘若企業組織因為預算的關係，無法建立集中式的儲存資源時，即便是採用ESXi本機儲存資源，也同樣支援啟用和運作vCHA高可用性機制，如圖7所示。
圖7 組態設定vCHA高可用性機制，管理網路和高可用性網路及儲存資源。
在2. IP Settings頁面中，必須組態設定Active Node、Passive Node、Witness Node這3台主機在vCHA高可用性網路中使用的IP位址，本文實作環境依序為192.168.75.31、192.168.75.32、192.168.75.33，如圖8所示。
圖8 組態設定vCHA同步和互相偵測的專屬網路IP位址。
一旦完成組態設定作業之後，系統將會自動執行複製和建立的工作任務，分別在剛才組態設定的ESXi主機當中部署Passive Node和Witness Node主機，組態設定vCenter HA Cluster後，vCHA高可用性機制便準備完畢，運作模式將會呈現「Enabled」且運作狀態為「Healthy」。
剛部署好vCHA高可用性機制時，會看到「PostgreSQL replication is not in progress」錯誤訊息，並且運作狀態為「Degraded」，這是因為Active Node和Passive Node主機之間才剛開始執行PostgreSQL資料庫的複寫作業，只要稍待幾分鐘，等PostgreSQL複寫作業執行完畢即可，如圖9所示。
圖9 剛開始執行PostgreSQL資料庫的複寫作業所導致的錯誤訊息。
PostgreSQL資料庫完成後，可以看到VM虛擬主機名稱「vCenter8」，目前擔任Active Node角色IP位址為「192.168.75.31」，並且這台vCenter8虛擬主機同時使用「10.10.75.30」IP位址，也就是運作環境中唯一的vCenter Server IP位址，而「vCenter8-Passive」虛擬主機則是擔任Passive Node角色，IP位址為「192.168.75.32」，「vCenter8-Witness」虛擬主機負責Witness Node角色，IP位址為「192.168.75.33」，如圖10所示。
圖10 順利建構和啟用vCHA高可用性機制。
手動觸發vCHA容錯移轉機制
成功啟用vCHA高可用性機制後，可以「手動」測試vCHA容錯移轉機制，測試Active Node和Passive Node角色進行切換，確保擔任備援角色的主機能夠順利接手並繼續運作，以便屆時災難真的發生時能夠順利進行容錯移轉。
事實上，在vCHA高可用性運作架構中，針對不同的資料屬性採用不同的同步方式，確保Active Node和Passive Node主機運作狀態一致。首先，在vCenter Server資料庫的部分，採用內嵌的「PostgreSQL資料庫」，並直接透過PostgreSQL資料庫原生「複寫」（Replication）機制，確保Active Node及Passive Node主機資料庫同步和內容一致，當災難事件發生時，便不會有資料遺失的情況發生（RPO=0）。
至於其他vCenter Server組態設定檔內容，則使用Linux作業系統中原生的「Rsync」複寫機制，即可確保Active Node和Passive Node主機組態設定檔內容一致，當災難事件發生時，便不會有組態設定檔內容不一致的問題。
在vCenter Server管理介面中，依序點選「vCenter Server > Configure > Settings > vCenter HA」項目，然後按下〔Initiate Failover〕按鈕，在彈出的Initiate vCenter HA failover視窗中，VMware建議除非有特殊情況，否則請勿勾選Force the failover to start immediately without waiting選項。
主要原因在於，強制且立即執行容錯移轉的動作，很有可能造成Active Node和Passive Node之間資料尚未同步完成，卻強制執行切換角色和接手vCenter服務動作，導致資料遺失或發生非預期的錯誤。確認進行容錯移轉的動作後，按下〔INITIATE FAILOVER〕按鈕即可，如圖11所示。
圖11 準備手動執行vCHA容錯移轉的動作。
開始執行vCHA容錯移轉動作後，由於Passive Node必須接手vCenter Server管理介面，以及相關的系統服務，例如Appliance Management Service、Content Library Service等等，所以將會有短暫幾分鐘停止服務的空窗期，可以嘗試持續偵測vCenter Server的IP位址，例如10.10.75.30。在本文實作環境中，容錯移轉動作執行後，大約掉了10～13個ping ICMP網路封包後，便能再次ping到vCenter Server的IP位址。
經過幾分鐘的容錯移轉程序後，便能重新連接至vCenter Server管理介面，可以看到原本的「vCenter8」虛擬主機，目前改為擔任Passive Node角色，IP位址為「192.168.75.31」，而「vCenter8-Passive」虛擬主機，改為擔任Active Node角色，IP位址為「192.168.75.32」，並且這台vCenter8-Passive虛擬主機，同時接手使用「10.10.75.30」的vCenter Server IP位址，至於Witness Node角色主機和IP位址則維持不變，如圖12所示。
圖12 原本的Passive Node角色主機順利接手Active Node角色和vCenter Server IP位址。
災難演練vCHA容錯移轉機制
目前，vCenter8-Passive虛擬主機擔任Active Node角色，並運作在「vcha02.lab.weithenn.org」的ESXi虛擬化平台上，直接將ESXi虛擬化平台關機，實際模擬災難事件發生並影響到Active Node角色，再次確認vCHA高可用性機制能否「自動」進行容錯移轉作業。同樣地，當災難事件發生時，Passive Node將會自動接手vCenter Server管理介面的IP位址，並且啟動相關的系統服務，因此會有幾分鐘無法服務的空窗期。
經過幾分鐘的容錯移轉程序後，便能重新連接至vCenter Server管理介面，可以看到「vCenter8」虛擬主機重新擔任Active Node角色，IP位址為「192.168.75.31」，並接手「10.10.75.30」的vCenter Server IP位址，而「vCenter8-Passive」虛擬主機，由於套用VM/Host Rule，所以並不會在其他台ESXi虛擬化平台上重新開機，至於Witness Node角色主機和IP位址則維持不變，如圖13所示。
圖13 實際模擬Active Node底層ESXi虛擬化平台發生災難事件。
vCHA高可用性機制的維運管理
接著，說明vCHA高可用性機制的維運管理。
確保不同角色運作在不同台ESXi主機
至此，已經順利建構及部署vCHA高可用性機制，並且成功驗證vCHA容錯移轉機制，能夠手動和自動進行切換。值得注意的是，根據VMware最佳建議作法，在企業組織的正式營運環境中，應搭配啟用vSphere Cluster DRS規則，確保擔任Active、Passive、Witness角色的這3台VM虛擬主機，能夠各自分散並運作在「不同台」ESXi虛擬化平台上，以避免災難事件發生時，因為角色運作在同一台ESXi虛擬化平台上，而喪失了vCHA高可用性的保護機制。
在vCenter Server管理介面中，依序點選「Cluster > Configure > Configuration > VM/Host Rules > Add」項目，在彈出的Create VM/Host Rule視窗中填入規則名稱，本文實作名稱為「Separate vCHA Roles」，在Type下拉式選單中選擇至「Separate Virtual Machines」項目，按下〔Add〕按鈕加入Active、Passive、Witness角色主機，以便此規則套用生效後，擔任Active、Passive、Witness角色的主機，不會運作在同一台ESXi主機上，如圖14所示。
圖14 新增VM虛擬主機分隔規則，確保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 is not allowed. Manual failover is allowed」，表示自動切換機制已經停用，但仍然能夠手動切換，如圖15所示。
圖15 組態設定vCHA高可用性機制進入維護模式。
下列為組態設定vCHA高可用性機制的時候，三種不同的運作模式分別有哪些影響：
‧Enable vCenter HA：啟用vCHA高可用性，此時Active Node和Passive Node之間的PostgreSQL資料庫，將會自動進行複寫作業，除了可以手動執行切換作業外，發生災難時系統將會自動進行容錯移轉作業。
‧Maintenance Mode：維護模式，PostgreSQL資料庫保持複寫作業，也可以手動執行切換作業，但目前vCHA機制處於維護模式，所以不會自動執行容錯移轉作業，以避免發生誤判的情況。
‧Disable vCenter HA：停用模式，PostgreSQL資料庫不會執行複寫作業，管理人員也無法手動執行切換，系統也不會自動進行容錯移轉作業，通常用於讓vCenter Server恢復單台運行時使用。
不同災難事件vCHA如何因應
部署vCHA高可用性機制後，必須了解當發生各種不同的災難事件時，例如伺服器硬體、實體網路環境等等，在何種災難的情況下，才會觸發Passive Node接手Active Node服務，以及vCenter Server的IP位址。
下列為列舉當發生各種不同的災難事件時，vCHA高可用性機制將如何因應：
‧Active Node發生災難時：只要Passive Node與Witness Node之間能夠正常通訊，那麼Passive Node將會接手Active Node角色，以及相關系統服務和vCenter Server IP位址，同時回應vSphere Client的操作請求。
‧Passive Node發生災難時：只要Active Node與Witness Node之間能夠正常通訊，則Active Node繼續保持原有角色，繼續回應vSphere Client的操作請求。
‧Witness Node發生災難時：只要Active Node與Passive Node之間能夠正常通訊，則Active Node繼續保持原有角色，繼續回應vSphere Client的操作請求。同時，Passive Node將會偵測Active Node是否正常運作，以便再次發生災難事件時，能夠自動進行容錯移轉角色切換作業。
‧主機發生網路隔離行為：當單台主機發生網路中斷事件時，在經過間歇性網路故障偵測程序，並且所有重試機制都執行完畢後，系統便會將該台角色主機判定為隔離狀態，一旦主機進入隔離狀態，系統將會把該台主機所有服務停止。舉例來說，倘若Active Node被判定為隔離狀態，那麼Active Node將會停止所有服務，以及使用的vCenter Server IP位址，確保Passive Node能夠順利接手為Active Node角色，並繼續回應vSphere Client的操作請求，如圖16所示。
圖16 原本的Active Node發生網路隔離後由Passive Node接手。
‧多台節點發生故障：原則上，vCHA高可用性機制只能因應「單台」角色主機發生故障，無法因應「多台」角色主機同時發生故障。例如，實體網路交換器發生嚴重災難事件，導致Active、Passive、Witness這3台主機無法互相通訊，此時vCHA高可用機制將無法正常運作，因為在vCHA高可用性機制的設計中，並無法容許同時發生多項故障。
結語
透過本文的深入剖析及實作演練，管理人員已經理解最新vCenter Server 8 U1版本中vCHA高可用性機制及運作架構，並且根據VMware官方提出的最佳建議作法，輕鬆地建構出高可用性並具備靈活應用的vCenter Server管理平台。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞