網管人雜誌
本文刊載於 網管人雜誌第 158 期 - 2019 年 3 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言vCHA 高可用性運作架構
vCHA 硬體資源及軟體版本需求
vCHA 部署模式
實戰 vCHA 高可用性機制
準備 vCHA 部署環境
組態設定 vNetwork 虛擬網路環境
啟用 vCHA 高可用性機制
vCHA 高可用性機制的維運管理
結語
前言
在企業及組織資料中心內的 VMware vSphere 虛擬化架構中，vCenter Server 管理平台的重要性相信是不言而喻的，當 vCenter Server 管理平台發生故障損壞事件而無法正常提供管理服務時，對於 vSphere 虛擬化架構在運作上並不會產生立即的影響，但是管理人員將無法進行任何的 vSphere 虛擬化架構管理工作任務，例如，部署 VM 虛擬主機、調整 vSwitch 虛擬網路交換器，vMotion 線上遷移 VM 虛擬主機……等。
雖然，只要啟用 vSphere Cluster 當中的 vSphere HA 高可用性機制後，即可讓 vCenter Server 在短暫的停機時間後恢復正常運作，以便因應企業及組織的資料中心發生非計劃性災難事件時，能夠盡量縮短 vCenter Server 管理平台無法正常服務的時間，但是仍然會影響企業及組織當中營運服務的 SLA。
因此，在 2016 年 11 月發佈的 VMware vSphere 6.5 版本中，VMware 正式推出專門為 vCenter Server 管理平台量身打造的高可用性機制「vCHA（vCenter High Availability）」（如圖 1 所示）。
在過去的 vCSA（VMware vCenter Server Appliance）版本中，VMware 並沒有推出針對 vCSA 的高可用性機制，僅能搭配 vSphere Cluster 內建的 vSphere HA 高可用性機制，達成 vCSA 管理平台服務高可用性的目的。
圖 1、vCenter High Availability 高可用性運作架構示意圖
在本文中，將深入剖析及實作演練 vCenter High Availability 高可用性運作架構，以便協助管理人員了解 vCenter High Availability 高可用性的最佳建議作法，有效提升企業及組織當中營運服務的 SLA。
vCHA 高可用性運作架構
在管理人員動手建構及組態設定 vCHA 高可用性機制之前，應該先了解整個 vCHA 高可用性的運作架構及環境需求，舉例來說，採用的 vCSA 管理平台是採用「Embedded 或 External」方式進行部署、在啟用 vCHA 高可用性機制的 vSphere Cluster 中至少必須有 3 台 ESXi 6.5 的成員主機……等。
首先，在 vCHA 高可用性機制運作架構中，其實是由「Active、Passive、Witness」這 3 種不同節點的成員角色所組成（如圖 2 所示），當 vCHA 高可用性機制建立完成後，便會建構出「Active-Passive」的容錯移轉機制。
事實上，Passive、Witness 這 2 個角色，是由系統將擔任 Active 角色的 vCSA 進行「複製」（Clone）後，分別運作在其它 2 台 ESXi 虛擬化平台上。
下列便是條列不同角色的成員節點主機所負責的工作任務及功能：
- Active Node： 運作 vCSA 主要執行個體，同時使用 vCSA 對外服務共用 IP 位址。
- Passive Node： 運作 vCSA 備援執行個體，透過複寫機制不斷從 Active Node 接收變更內容及狀態，一旦 Active Node 發生災難事件時便會立即接手相關服務及共用 IP 位址。
- Witness Node： 擔任 vCHA 高可用性架構中的仲裁角色，當 Active Node 及 Passive Node 發生網路分區或中斷事件時，能夠有效避免 vCHA 高可用性機制發生「腦裂」（Split-Brain）的情況。值得注意的是，在 vCHA 高可用性運作架構中，僅負責仲裁的工作任務並不會接手 Active Node 及 Passive Node 的角色。
圖 2、vCHA 高可用性機制運作角色示意圖
因此，當擔任「vCenter（Active）」角色的 vCSA 所在的底層 ESXi 虛擬化平台發生災難事件時，便會觸發 vCHA 高可用性機制容錯移轉功能，由擔任「vCenter（Passive）」角色的 vCSA 接手原本的服務，並且繼承原本 vCenter（Active）角色所使用的 IP 位址。
由於 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」儲存資源中。請注意，在 VMware 最佳建議作法中，請勿在營運環境中部署最小型的 vCSA「Tiny（2 vCPU 及 10GB vRAM）」規模大小，因為這樣的 vCSA 硬體資源將無法滿足屆時基本的 RTO 需求。
- 採用隔離且專用的良好網路環境： 因為在 vCHA 高可用性機制運作架構中，Active Node 及 Passive Node 之間，必須不斷同步 PostgreSQL 資料庫的資料及相關運作資訊，倘若 2 台節點主機之間的網路頻寬無法達到資料同步要求時，那麼 vCHA 高可用性機制將會退化為「非同步」狀態，同時導致 PostgreSQL 資料庫內容相異。因此，除了必須採用與 vCSA 管理網路不同的子網路之外，在 Active、Passive、Witness 節點主機之外，必須採用小於「10 ms」延遲時間的網路環境（如圖 3 所示）。
圖 3、vCSA 高可用性機制採用隔離且專用的良好網路環境示意圖
除了上述 vCHA 高可用性機制的硬體資源及軟體版本需求之外，管理人員還應注意下列 2 項最佳建議作法，以確保 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 位址」。
圖 4、vCSA Embedded 部署模式啟用 vCHA 高可用性機制運作架構示意圖
當採用「vCSA External」部署模式時，管理人員必須確保 Platform Services Controller 受到負載平衡設備的保護。下列為建立 vCHA 高可用性機制的流程：
1. 採用 vCSA External 部署模式建立 vCSA 管理平台，請管理人員確保至少部署 2 個 External Platform Services Controller 執行個體。
2. 管理人員組態設定 vCSA 管理平台，指向至受到負載平衡設備保護的 Platform Services Controller（相關資訊請參考 VMware KB2147014、KB2147038、KB2147046）。
3. 啟用 vCHA 高可用性機制後，系統將會以 Active Node 為來源複製 Passive Node 及 Witness Node，此時 Platform Services Controller 及負載平衡資訊也會一併複製。
4. 確保 Active Node 與 Passive Node 完成「資料同步」作業，包括，PostgreSQL 資料庫、Platform Services Controller 及其它服務（如圖 5 所示）。
5. 當 Platform Services Controller 發生災難事件時，負載平衡設備會重新導向至備援用途的 Platform Services Controller，以便進行身份驗證及它服務。
圖 5、vCSA External 部署模式啟用 vCHA 高可用性機制運作架構示意圖
實戰 vCHA 高可用性機制
了解 vCHA 高可用性機制的基礎架構及最佳作法後，接著便是進行 vCHA 高可用性機制的實作演練。下列為整個建構 vCHA 高可用性機制的流程：
1. 準備 vCHA 部署環境。
2. 組態設定 vNetwork 虛擬網路環境。
3. 啟用 vCHA 高可用性機制。
4. vCHA 高可用性機制的維運管理。
準備 vCHA 部署環境
在本文實作環境中，將依據 VMware 最佳建議作法準備 3 台 ESXi 虛擬化平台，並且部署 1 台 vCenter Server 至其中 1 台 ESXi 虛擬化平台上，另外 2 台 ESXi 虛擬化平台屆時則部署 vCenter Server Passive 角色及 Witness 角色。此外，將採用 vCSA Small Size 及 Embedded 部署模式啟用 vCHA 高可用性機制（如圖 6 所示）。
圖 6、採用 vCSA Small Size 及 Embedded 部署模式
組態設定 vNetwork 虛擬網路環境
在本文實作環境中 vCenter Server 管理網路環境採用的網段為「10.10.75.0/24」，同時規劃 vCenter HA Network 專用的網段為「192.168.75.0/24」，並且分別採用不同的 vSwitch 虛擬網路交換器及 Port Group。
登入 vCenter Server 管理介面後，依序點選「ESXi Host > Configure > Networking > Virtual Switches > Add Networking > Virtual Machine Port Group for a Standard Switch > New standard switch > vmnic1」，接著在 Connection settings 視窗中 Network label 欄位填入名稱「vCHA HA Network」，這便是本文實作環境專用於 vCenter Server HA 虛擬網路的 Port Group 名稱（如圖 7 所示）。
圖 7、新增專用於 vCenter Server HA 虛擬網路的 Port Group
啟用 vCHA 高可用性機制
請在 vCenter Server 管理頁面中，依序點選「vCenter Server > Configure > Settings > vCenter HA > Set Up vCenter HA」項目。首先，在 Resource settings 頁面中，請按下「Browse」選擇剛才新增專用於 vCenter Server HA 虛擬網路的「vCHA HA Network」，並確認「Automatically create clones for Passive and Witness nodes」項目已勾選（如圖 8 所示）。
接著，分別為 Passive Node 及 Witness Node 選擇運作環境，本文實作環境中將 Passive Node 部署至第 2 台 ESXi 虛擬化平台，而 Witness Node 則部署至第 3 台 ESXi 虛擬化平台。值得注意的是，Witness Node 在 vNetwork 虛擬網路的部分，只要選擇 vCHA HA Network 即可而無須管理網路。
圖 8、啟用 vCenter HA 高可用性機制，組態設定管理網路及 HA 同步專屬網路
在 Set Up vCenter HA 第二階段中，將組態設定 Active Node、Passive Node、Witness Node 的 HA 同步專屬網路 IP 位址，本文實作環境依序為「192.168.75.31、192.168.75.32、192.168.75.33」（如圖 9 所示）。
圖 9、組態設定 vCenter HA 同步專屬網路 IP 位址
待系統複製完成 Passive Node 及 Witness Node，並且組態設定 vCenter HA Cluster 之後，vCHA 高可用性機制便正式成形且運作無誤（如圖 10 所示）。
圖 10、順利啟用 vCenter HA 高可用性機制
順利啟用 vCenter HA 高可用性機制後，我們可以「手動」進行 vCenter Server 容錯移轉，以便確認 vCenter HA 容錯移轉機制運作正常，或後續需要進行 Active / Passive 角色切換時使用。請在 vCenter Server 管理介面中，依序點選「vCenter Server > Configure > Settings > vCenter HA > Initiate Failover」項目即可，值得注意的是在切換期間 vCenter Server 及 vSphere Client 和其它服務，會有幾分鐘停止服務的空窗期（如圖 11 所示）。
在 Initiate vCenter HA failover 視窗中，「不」建議勾選 Force the failver to start immediately 選項，原因是強制立即執行容錯移轉的動作有可能會造成 vCenter Server 資料尚未同步完成，而導致資料遺失或發生不可預期的錯誤。
圖 11、管理人員手動進行 vCenter Server 容錯移轉
經過幾分鐘的 vCenter Server 容錯移轉程序後，可以看到 vCenter Server 高可用性機制重新運作，並且原本擔任 Passive Node 角色的主機成為 Active Node 角色，並且接手 vCenter Server 管理 IP 位址「10.10.75.31」（如圖 12 所示）。
.圖 12、原本 Passive Node 角色順利接手 Active Node 角色及管理用途 IP 位址
vCHA 高可用性機制的維運管理
分散運作在不同台 ESXi 主機
在正式營運環境中，除了確保 vCHA 高可用性機制運作正常且能夠順利切換之外，也應搭配 vSphere Cluster DRS 規則，確保 Active、Passive、Witness 角色這 3 台主機不會運作在「同一台」ESXi 虛擬化平台上。
請在 vCenter Server 管理介面中，依序點選「Cluster > Configure > Configuration > VM/Host Rules > Add」項目，在彈出的 Create VM/Host Rule 視窗中首先填入此規則名稱，本文實作名稱為「vCHA Separate」，在 Type 下拉式選單中請選擇至「Separate Virtual Machines」項目，以確保此規則套用後 Active、Passive、Witness 角色不會運作在同一台 ESXi 主機上，最後按下 Add 鈕加入 Active、Passive、Witness 角色主機即可（如圖 13 所示）。
圖 13、新增 Separate Virtual Machines 規則，確保 vCHA 主機不會運作在同一台 ESXi 主機上
vCenter HA 進入維護模式
當 vCenter Server 需要進行相關維運作業時，為了避免系統誤判而導致觸發 vCenter Server 容錯移轉機制，我們可以在進行 vCenter Server 維運作業前將 vCenter HA 機制進行「維護模式」（Maintenance Mode）。
請在 vCenter Server 管理介面中，依序點選「vCenter Server > Configure > Settings > vCenter HA > Edit」項目，在彈出的 Edit vCenter HA 視窗中選擇至「Maintenance Mode」項目即可。此時，可以管理介面中看到 vCenter HA 的 Mode 由原本的 Enable 轉換成「Maintenance」，並且系統也顯示「Automatic failover」機制已停用，但是管理人員仍然可以進行手動容錯移轉（如圖 14 所示）。
圖 14、組態設定 vCenter HA 高可用性機制進入維護模式
備份和還原 vCenter Server
即便建立 vCenter Server 高可用性機制，定期備份 vCenter Server 仍是必須的，下列便是建立 vCenter HA 高可用性機制後的備份還原注意事項：
1. 僅備份擔任 Active Node 角色的 vCenter Server 即可，無須備份 Passive Node 及 Witness Node。
2. 當災難事件發生必須執行還原作業時，請先關閉並刪除所有 vCenter HA 角色的節點主機。
3. 執行還原 Active Node 角色的 vCenter Server 即可，還原後為單台的 vCenter Server（如圖 15 所示）。
4. 重新組態設定 vCenter HA 高可用性機制。
圖 15、執行還原 Active Node 角色的 vCenter Server
因應各種災難情境
事實上，vCHA 高可用性機制針對不同的資料屬性採用不同的同步方式，以便保持 Active Node 及 Passive Node 節點主機狀態的一致性。首先，在 vCenter Server 資料庫部分預設採用內嵌「PostgreSQL 資料庫」，直接透過 PostgreSQL 資料庫原生的「複寫」（Replication）機制，保持 Active Node 及 Passive Node 節點主機資料庫同步及內容的一致性，在「組態設定檔」的部分則使用 Linux 作業系統中原生的「Rsync」複寫機制，達到 Active Node 及 Passive Node 節點主機組態設定檔內容一致性。
因為採用 PostgreSQL 資料庫原生複寫機制隨時保持資料一致性，所以發生災難事件時不會有資料遺失的情況發生（RPO=0）。
此外，在 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 將繼續保持 Active Node 的角色，繼續回應客戶端提出的請求。
- Witness Node 發生災難故障時： 只要 Active Node 與 Passive Node 能夠互相通訊，那麼 Active Node 將繼續保持原來的角色，並繼續回應客戶端提出的請求。同時，Passive Node 將會繼續偵測 Active Node 是否正常運作，以便隨時準備進行容錯移轉作業。
- 多台節點發生故障或發生網路隔離： 表示 Active、Passive、Witness 這 3 台節點主機彼此無法互相通訊。此時，vCHA 叢集無法正常運作並且高可用性也受到影響，因為在 vCHA 高可用性機制的設計中並無法容許同時發生多項故障。
- 節點隔離行為： 當單台節點主機發生網路中斷事件，在經過間歇性網路故障偵測程序及所有重試機制都耗盡後，系統才會將該台節點主機判定為隔離狀態，同時進入隔離狀態的節點主機將會自動停止所有服務。舉例來說，倘若 Active Node 發生隔離狀態時，那麼 Active Node 將會從叢集中移出並停止所有服務，以便確保 Passive Node 能夠接手角色成為 Active Node，並開始回應客戶端提出的請求。
