網管人雜誌
本文刊載於 網管人雜誌第 178 期 - 2020 年 11 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
從最新 Flexera 2020 State of the Cloud Report 市調報告中可知（如圖 1 所示），VMware vSphere 虛擬化基礎架構，在企業和組織的私有雲市佔率中仍然穩居首位。因此，可想而知在 VMware vSphere虛擬化架構中，擔任整個虛擬化基礎架構管理中心 vCenter Server 的重要性，雖然在 vCenter Server 發生故障損壞導致無法進行管理工作任務時，在 ESXi 主機上運作的 VM 虛擬主機或容器並不會受到影響，然而管理人員將無法進行任何跟 vSphere 虛擬化架構有關的管理任務，例如，線上遷移 VM 虛擬主機、組態設定 vDS 或 vSS 虛擬網路交換器、部署 VM 虛擬主機或容器……等。
圖 1、市調結果顯示 VMware vSphere 穩座私有雲市佔率首位
在過往的 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 分鐘」的時間。
由於，採用 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 高可用性機制。
採用 vSphere Standard 和 Enterprise 版本，啟用 vSphere FT 的 VM 虛擬主機僅支援「2 vCPU」，必須採用 vSphere Enterprise Plus 版本才支援至「8 vCPU」。
在過去的版本中，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 高可用性運作架構示意圖
在本文中，我們將會深入剖析和實作演練 vCHA 高可用性架構，以協助企業和組織的 IT 管理人員，深入理解 vCHA 高可用性運作機制，搭配 VMware 官方的最佳建議作法，建構出靈活且高效能的 vCHA 高可用性架構，有效提升企業和組織私有雲環境中營運服務的 SLA 服務層級。
vCHA 高可用性基礎架構
在開始建構和組態設定 vCHA 高可用性機制之前，建議管理人員先了解 vCHA 高可用性基本架構及運作環境需求。首先，在 vCHA 高可用性機制運作架構中，將會由「Active、Passive、Witness」這 3 種不同角色所組成（如圖 3 所示），當 vCHA 高可用性機制建構完成後，便會形成「Active-Passive」的容錯移轉機制。下列，為條列擔任不同角色成員主機所負責的工作任務及功能：
- 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）的情況。
請注意，在 vCHA 高可用性運作架構中，Witness Node 僅負責「仲裁」的工作任務，當災難發生時並不會接手 Active Node 或 Passive Node 角色和相關服務。
圖 3、vCHA 高可用性運作架構角色示意圖
簡單來說，當擔任「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 為 Active-Passive 容錯移轉架構，因此故障主機數量無法超過「單台」。在 VMware 最佳建議作法中，應將不同 vCHA 角色的主機部署在不同的 ESXi 虛擬化平台，以及不同的 Datastore 儲存資源中，避免發生雞蛋放在同一個籃子內的災難事件。
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 軟體授權即可。
請注意，vCenter Server Foundation 或 vCenter Server Essentials 版本，不支援建構 vCHA 高可用性機制。
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 高可用性網路必須為小於 10 ms 延遲時間的網路環境示意圖
實戰 vCHA 高可用性機制
理解 vCHA 高可用性機制基礎架構和最佳作法後，便開始進行 vCHA 高可用性機制的實作演練。我們將採用自動組態設定的方式部署 vCHA 高可用性機制，下列為建構 vCHA 高可用性機制的流程說明：
- 部署第一台 vCenter Server 主機，屆時將擔任 Active Node 角色。
- 管理人員為每台 ESXi 虛擬化平台，新增擔任 HA Network 用途的 Port Group 。
- 啟用 vCenter HA 組態設定精靈，在自動化工作流程中提供 IP 位址、目標 ESXi 主機或 vSphere 叢集、目標 Datastore 儲存資源。
- 系統自動複製 Active Node 主機後，產生 Passive Node 角色的主機並套用相關組態設定。
- 系統再次自動複製 Active Node 主機後，產生 Witness Node 角色的主機並套用相關組態設定。
- 系統組態設定 3 台主機透過 HA Network 進行通訊，確保資料交換和「心跳」（Heartbeats）及其它通訊作業運作正常。
- 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 7 規模大小和舊版有所差異，舉例來說，vCenter Server 6.7 版本的 Small 規模大小，硬體資源需求為 4 vCPU、16 GB vRAM、340 GB vDisk，而 vCenter Server 7 版本的 Small 規模大小，硬體資源需求提升為 4 vCPU、19 GB vRAM、480 GB vDisk 。
值得注意的是，於部署第一台 vCenter Server 的第二階段時，在 vCenter Server Configuration 頁面中，請記得啟用「SSH Access」功能，因為這是 vCHA 高可用性功能的必要需求之一（如圖 5 所示）。
倘若，安裝過程中忘記啟用 vCenter Server 的 SSH Access 功能，也可於安裝完成後透過 vCenter Server 系統管理介面（Port 5480），登入後進行 SSH Access 特色功能啟用的動作。
圖 5、建構 vCHA 高可用性機制，vCenter Server 至少要採用 Small 規模大小
新增 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 所示）。
接著，分別為 Passive Node 及 Witness Node 選擇運作環境，本文實作環境中將 Passive Node 部署至「esxi7-n02」虛擬化平台，而 Witness Node 則部署至「esxi7-n03」虛擬化平台。值得注意的是，Witness Node 在 vNetwork 虛擬網路的部分，只要選擇 vCHA HA Network 即可無須管理網路。
圖 7、組態設定 vCHA 高可用性機制中，管理網路和 vCenter 高可用性網路
在第二階段 IP Settings 頁面中，管理人員必須組態設定 Active Node、Passive Node、Witness Node，這 3 台主機在 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 之間資料尚未同步完成，導致資料遺失或發生非預期的錯誤。
在 vCHA 容錯移轉期間 vCenter Server 管理介面和相關服務，將會有幾分鐘停止服務的空窗期。
圖 10、準備手動執行 vCHA 容錯移轉的動作
事實上，vCHA 高可用性機制針對不同的資料屬性採用不同的同步方式，以便保持 Active Node 及 Passive Node 主機狀態的一致性。首先，在 vCenter Server 資料庫部分，採用內嵌的「PostgreSQL 資料庫」，並直接透過 PostgreSQL 資料庫原生「複寫」（Replication）機制，保持 Active Node 及 Passive Node 主機資料庫同步和內容的一致性，至於「組態設定檔」的部分，則使用 Linux 作業系統中原生的「Rsync」複寫機制，達成 Active Node 及 Passive Node 主機組態設定檔內容的一致性。
因為採用 PostgreSQL 資料庫原生複寫機制，所以能夠隨時保持資料庫內資料的一致性，因此當災難事件發生時，便不會有資料遺失的情況發生（RPO = 0）。
經過幾分鐘的 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 容錯移轉機制能夠順利切換。然而，在正式營運環境中，應搭配啟用 vSphere Cluster DRS 規則，確保 Active、Passive、Witness 這 3 台主機，各自分散運作在「不同台」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 這 3 台主機無法互相通訊，此時 vCHA 高可用機制將無法正常運作，因為在 vCHA 高可用性機制的設計中並無法容許同時發生多項故障。
