網管人雜誌

本文刊載於網管人雜誌第 214 期 - 2023 年 11 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。

本文目錄

前言

vCHA 部署模式

vCHA 軟體需求

vCHA 網路需求

實戰演練 - vCHA 高可用性機制

部署 vCenter Server 管理平台

新增 vCenter HA Network 虛擬網路環境

啟用 vCHA 高可用性機制

手動觸發 vCHA 容錯移轉機制

災難演練 vCHA 容錯移轉機制

vCHA 高可用性機制的維運管理

確保不同角色運作在不同台 ESXi 主機

vCHA 進入維護模式

不同災難事件 vCHA 如何因應

結語

前言

在 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」這 3 種不同角色所組成，當 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 高可用性網路必須小於 10 ms 延遲時間網路環境示意圖

圖片來源： 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 高可用性機制的維運管理

確保不同角色運作在不同台 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 所示）。

下列為組態設定 vCHA 高可用性機制時，三種不同的運作模式分別有哪些影響：

Enable vCenter HA：啟用 vCHA 高可用性，此時 Active Node 和 Passive Node 之間的 PostgreSQL 資料庫，將會自動進行複寫作業，管理人員除了可以手動執行切換作業之外，發生災難時系統將會自動進行容錯移轉作業。
Maintenance Mode：維護模式，PostgreSQL 資料庫保持複寫作業，也可以手動執行切換作業，但目前 vCHA 機制處於維護模式，所以不會自動執行容錯移轉作業，以避免發生誤判的情況。
Disable vCenter HA：停用模式，PostgreSQL 資料庫不會執行複寫作業，管理人員也無法手動執行切換，系統也不會自動進行容錯移轉作業，通常用於讓 vCenter Server 恢復單台運行時使用。

圖 15、組態設定 vCHA 高可用性機制進入維護模式

不同災難事件 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 所示）。
多台節點發生故障：原則上，vCHA 高可用性機制只能因應「單台」角色主機發生故障，無法因應「多台」角色主機同時發生故障。舉例來說，實體網路交換器發生嚴重災難事件，導致 Active、Passive、Witness 這 3 台主機無法互相通訊，此時 vCHA 高可用機制將無法正常運作，因為在 vCHA 高可用性機制的設計中，並無法容許同時發生多項故障。