網管人雜誌
本文刊載於 網管人雜誌第 136 期 - 2017 年 5 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言VCHA 高可用性機制
VCHA 高可用性運作架構
部署 VCHA 高可用性的最佳作法
vMotion 即時遷移的安全性
vMotion 加密技術運作架構
組態設定加密 vMotion 機制
部署加密 vMotion 的最佳作法
結語
前言
VMware 官方，在 2016 年 11 月 VMware VMworld 2016 大會上，宣佈 VMware vSphere 6.5 及 VMware vSAN 6.5 正式推出，並且 VMware 官方在最新版本 vCSA 6.5 當中，為 vCSA 管理平台打造「原生 HA 高可用性」機制。在過去的 vCSA（VMware vCenter Server Appliance）版本中，並沒有原生 vCSA HA 高可用性機制，只能搭配 VMware 叢集內建的 vSphere HA 高可用性機制，來達到 vCSA 服務高可用性的目的。
在本文中，除了介紹 VCHA 高可用性運作架構及最佳建議作法之外，同時也會介紹在 vSphere 6.5 版本當中的另一個亮點功能，也就是針對 vMotion 即時遷移流量進行加密，避免遭受中間人攻擊甚至被竄改記憶體狀態導致資安事件，有效保護企業及組織線上營運的 VM 虛擬主機進行 vMotion 遷移時的安全性。
VCHA 高可用性機制
新版的原生 vCSA HA 機制（簡稱 VCHA），是由「Active、Passive、Witness」成員節點角色所組成。當 VCHA 叢集中某台成員節點主機發生災難事件時（例如，擔任 Active Node 角色的成員節點主機發生硬體故障），將會觸發 VCHA 高可用性機制然後透過 API 存取的使用者在 2 分鐘內便可以繼續使用，而透過 UI 存取的使用者在 4 分鐘便可以繼續存取，原則上 VCHA 機制的 RTO 預計在「5 分鐘」之內便可完成，當然實際上必須視底層硬體資源的工作負載情況而定。
圖 1、VCHA 高可用性機制運作示意圖
VCHA 高可用性運作架構
在實作 VCHA 高可用性機制的部分，必須保持 Active Node 及 Passive Node 節點主機狀態的一致性。首先，在 vCSA 資料庫部分預設採用內嵌「PostgreSQL 資料庫」，所以透過 PostgreSQL 資料庫原生的「複寫」（Replication）機制，保持 Active Node 及 Passive Node 節點主機資料庫同步及內容的一致性。接著，在「組態設定檔」的部分則使用 Linux 作業系統中原生的「Rsync」複寫機制，達到 Active Node 及 Passive Node 節點主機組態設定檔內容一致性。在 VCHA 高可用性機制運作架構中，高可用性叢集是由 Active、Passive、Witness 成員節點主機所組成，每台成員節點主機的功能如下：
- Active Node： 運作 vCenter Server 主要執行個體，啟用及使用 VMware 叢集的共用 IP 位址。
- Passive Node： 運作 vCenter Server 備援執行個體，透過複寫機制不斷從 Active Node 端接收變更內容及狀態，倘若 Active Node 發生故障事件時將會立即接手相關服務。
- Witness Node： 擔任仲裁角色，當 Active Node 及 Passive Node 發生網路分區或中斷事件時，能夠有效避免 VCHA 高可用性運作架構發生腦裂的情況。在整個 VCHA 運作架構中，使用最少的硬體資源同時也不會接手 Active Node 及 Passive Node 的角色。
圖 2、VCHA 高可用性機制運作架構示意圖
那麼，在 VCHA 高可用性機制的運作架構下，當發生不同的災難事件時（例如，硬體、軟體、網路環境），Passive Node 如何接手 Active Node 服務及叢集公用 IP 位址，並且繼續回應客戶端提出的請求。此外，在 VCHA 高可用性機制中因為 PostgreSQL 資料庫將會進行同步，所以發生災難事件時也不會有資料遺失的情況（RPO=0）。
下列，我們將列舉當 VCHA 高可用性機制發生各種災難事件時，系統將如何進行因應措施：
- Active Node 故障損壞時： 只要 Passive Node 與 Witness Node 能夠互相通訊，那麼 Passive Node 將會提升自己的角色為 Avtive Node，並且開始回應客戶端提出的請求。
- Passive Node 故障損壞時： 只要 Active Node 與 Witness Node 能夠互相通訊，那麼 Active Node 將繼續保持 Avtive Node 的角色，並且繼續回應客戶端提出的請求。
- Witness Node 故障損壞時： 只要 Active Node 與 Passive Node 能夠互相通訊，那麼 Active Node 將繼續保持 Avtive Node 的角色，並且繼續回應客戶端提出的請求。同時，Passive Node 將會繼續偵測 Active Node 是否正常運作，以便隨時準備進行故障切換作業。
- 多台節點發生故障或發生網路隔離： 表示 Active、Passive、Witness 這 3 台節點主機彼此無法互相通訊。此時，VCHA 叢集將無法正常運作並且可用性也受到影響，因為 VCHA 高可用性機制的設計並無法容許同時發生多項故障。
- 節點隔離行為： 當單台節點主機發生網路中斷事件，在經過間歇性網路故障偵測程序及所有重試機制都耗盡後，系統才會將該台節點主機判定為隔離狀態，同時進入隔離狀態的節點主機將會自動停止所有服務。舉例來說，倘若 Active Node 發生隔離狀態時，那麼 Active Node 將會從叢集中移出並停止所有服務，以便確保 Passive Node 能夠接手角色成為 Avtive Node，並且開始回應客戶端提出的請求。
部署 VCHA 高可用性的最佳作法
在 vCSA 6.5 版本中，每台 vCSA 支援管理最多 64 叢集、2,000 台 ESXi 主機、35,000 台註冊的 VM 虛擬主機、20,000 台開機的 VM 虛擬主機。同時，不同運作規模大小對於 vCSA 硬體資源的配置建議也不同，在下列表格中便是 VMware 官方針對不同運作規模的 vCSA 硬體資源建議：事實上，vCSA 還支援更小型的運作規模稱為「Tiny」，只需要 2 vCPUs 及 10 GB RAM 的硬體資源，可以管理 10 台 ESXi 主機及 100 台 VM 虛擬主機。但是，VCHA 高可用性運作機制不支援 Tiny 運作規模，所以要啟用 VCHA 高可用性機制至少需要採用 Small 運作規模才行。
圖 3、針對不同運作規模的 vCSA 硬體資源建議
雖然，VMware 建立的 VCHA 高可用性機制運作架構非常簡單易用，但是 vSphere 管理人員應該遵循最佳作法，以便讓 VCHA 高可用性機制運作效能更佳之外也更穩定：
- 離峰時間才啟用 VCHA 機制： 雖然，可以在 vCenter Server 運作的任何時間啟用 VCHA 高可用性機制，但是 VMware 強烈建議在工作負載的離峰時間再啟用。主要原因在於，建立 VCHA 高可用性機制後系統便會立即執行 PostgreSQL 資料庫同步作業，倘若在工作負載高峰時間啟用的話，那麼 Passive Node 的 PostgreSQL 資料庫有可能會來不及同步。
- 僅容許單台節點發生故障： 在 VCHA 高可性機制的運作架構下只有 3 台節點主機，所以容許故障的節點主機數量不能超過「單台」。因此，每台節點主機的角色應部署在不同 x86 硬體伺服器上，以避免硬體伺服器發生故障損壞事件時直接影響所有角色。此外，每台節點主機也應部署在獨立且隔離的 Datastore 儲存資源中，以避免將 3 台節點主機都部署在同 1 個 Datastore 儲存資源中，導致發生 SPOF 單點失敗的問題進而影響 VCHA 高可用性機制。
此外，在 VCHA 高可用性運作架構中，網路環境應該具備低延遲時間、高傳輸頻寬、隔離且專用的網路，以避免因為不適當的網路環境進而影響 VCHA 高可用性機制的運作及效能。下列，為 VCHA 高可用性網路環境規劃設計的最佳建議作法：
- 採用隔離且專用的網路： 因為在 VCHA 高可用性機制運作架構中，Active Node 及 Passive Node 之間，必須不斷同步 PostgreSQL 資料庫的資料，倘若 2 台節點主機之間的網路頻寬無法達到資料同步要求時，那麼將會退化為非同步並導致 PostgreSQL 資料庫內容相異。
- 支援高達 10 ms 的低延遲網路： 在 VCHA 高可用性機制運作架構中，可以支援高達 10 ms 網路環境延遲時間。倘若，網路環境的延遲時間高於 10 ms 時，那麼 VCHA 高可用性機制仍然能夠順利運作，但是將會產生延遲操作、低輸送量、效能損失……等運作不佳的情況。
下列是 VMware 官方透過 VCbench 壓力測試軟體，針對 VCHA 高可用性運作環境進行壓力測試的結果。其中採用 64-clients 方式為最貼近實務應用的工作負載，當延遲時間高達 5 ms 時那麼傳輸量將會下降 9 %，倘若延遲時間高達 10 ms 時傳輸量更會下降 15 %。若是更進一步，採用 256-clients 方式以更極端的工作負載方式進行壓測時，當延遲時間高達 5 ms 時那麼傳輸量將會下降 23 %，倘若延遲時間高達 10 ms 時傳輸量更會下降 27 %。
圖 4、透過 VCbench 針對 VCHA 網路環境進行壓力測試的統計數據
vMotion 即時遷移的安全性
過去，在 VMware vSphere 虛擬化運作環境中，針對 vMotion 線上遷移傳輸流量的規劃及設計，除了應規劃獨立專用的網路環境以便快速遷移線上運作的 VM 虛擬主機之外，規劃獨立專用網路環境的另一個考量便是「安全性」。因為，預設情況下當 vSphere 管理人員透過 vMotion 線上遷移機制，將線上運作中的 VM 虛擬主機從來源端 ESXi 主機，傳輸至目的端 ESXi 主機的過程中 vMotion 傳輸流量並「未進行加密」。同時，透過 vMotion 所傳輸的是 VM 虛擬主機的「記憶體狀態」，惡意攻擊者有可能在傳輸期間修改記憶體狀態內容，進而達到破壞 VM 虛擬主機應用程式或作業系統的目的，所以規劃獨立專用網路環境除了網路頻寬獨享之外，同時也達到 vMotion 傳輸流量安全性隔離的效果。
在 2015 年 3 月推出的 VMware vSphere ESXi 6.0 版本中，vMotion 線上遷移傳輸機制打破地域及環境的限制。新版 vMotion 即時遷移機制不只可以跨越 vSwitch 虛擬交換器，以及跨越不同的 vCenter Server 伺服器之外更可以跨越地域的限制，只要執行 vMotion 線上遷移的網路環境，能夠支援封包延遲時間在 100 ms 之內的話，那麼就能達成跨越地域限制的 vMotion 即時遷移。
現在，最新 VMware vSphere 6.5 版本當中，支援將 vMotion 線上遷移傳輸流量「加密」機制，透過 AES-GCM 加密標準將 VMkernel 的 vMotion 即時遷移流量，進行加密的動作達到高安全性的 vMotion 即時遷移。
圖 5、加密 vMotion 即時遷移傳輸數據運作示意圖
vMotion 加密技術運作架構
在 VMware vSphere 6.5 運作環境中，加密 vMotion 運作機制採用內嵌於 ESXi 主機 VMkernel 當中，並整合通過 FIPS 密碼模組檢測標準的 vmkcrypto 模組及搭配 AES-GCM 標準加密演算法，然後透過 TCP 通訊協定傳輸「vMotion 中繼資料」（vMotion Metadata）。事實上，加密 vMotion 運作機制並未依賴 SSL 或 IPSec 技術來加密 vMotion 即時遷移流量，相反的它著重在 TCP 通訊協定層級中達到加密的目的，主要原因在於考量 vMotion 即時遷移的運作效能。舉例來說，倘若採用 SSL 加密技術保護 vMotion 即時遷移流量時，因為 SSL 加密為「計算密集型」（Compute Intensive）的運作機制，所以 vMotion 即時遷移流量採用 SSL 加密技術的話，將會導致 ESXi 主機運算效能過多的額外開銷。
倘若採用 IPSec 加密技術保護 vMotion 即時遷移流量時，將會讓 vMotion 即時遷移受到限制，因為 ESXi 主機「僅」支援在 IPv6 網路環境中採用 IPSec 加密技術，在 IPv4 網路環境中並不支援 IPSec 加密技術。
因此，採用 VMkernel 內 vmkcrypto 模組的加密機制，除了有效讓 vMotion 避免發生效能損失的情況之外，透過 TCP 通訊協定傳輸的方式能夠讓加密 / 解密的工作負載，平均分散到 CPU 處理器的多個運算核心上。
當 vCenter Server 準備遷移線上運作的 VM 虛擬主機時，將會隨機產生 1 個「One time 256-bit」的加密金鑰，同時除了隨機 256-bit 加密金鑰之外還會搭配「64-bit 隨機數」成為 vMotion 遷移規範，然後將這個 vMotion 遷移規範傳遞給來源端及目的端 ESXi 主機，所以在進行 VM 虛擬主機 vMotion 線上遷移作業時，便會透過「256-bit 加密金鑰+ 64-bit 隨機數」的 vMotion 遷移規範，在 2 台 ESXi 主機之間以 vMotion 專屬網路環境進行傳輸，確保 2 台 ESXi 主機之間傳輸的遷移流量無法被惡意人士所複製或竄改。
值得注意的是，這個 256-bit 的加密金鑰並非採用 vCenter Server Key Manager 產生，而是 vCenter Server 會為每次的 vMotion 即時遷移工作任務，自動產生 1 個新的 256-bit 加密金鑰，並且在 vMotion 線上遷移任務結束後便會「捨棄」該加密金鑰。同時，剛才已經提到加密 vMotion 運作機制，是採用 VMkernel 內的 vmkcrypto 模組達成，因此並不需要專用的硬體設備即可達成。
倘若，執行 vMotion 即時遷移工作任務並非 2 台 ESXi 主機，而是「跨越」不同台 vCenter Server 時則會有些許不同。簡單來說，在執行跨 vCenter Server 進行加密 vMotion 即時遷移時，與剛才說明的加密 vMotion 即時遷移運作原理相同，唯一不同的部分在於「256-bit 加密金鑰 + 64-bit 隨機數」的 vMotion 遷移規範，將會從來源端 vCenter Server 透過「SSL」傳送到目的端 vCenter Server。
圖 6、跨 vCenter Server 執行加密 vMotion 即時遷移傳輸數據運作示意圖
組態設定加密 vMotion 機制
由於加密 vMotion 即時遷移機制不需要專用的硬體設備即可達成，因此可以隨時針對希望保護的 VM 虛擬主機進行啟用的動作即可。在實務應用上，通常會針對重要工作任務或存放企業及組織機敏資料的 VM 虛擬主機進行套用，例如，負責線上營運服務 SQL 資料庫伺服器。請透過 vSphere Web Client 管理工具登入 vCenter Server 管理平台後，依序點選「首頁>主機和叢集」圖示，點選欲啟用加密 vMotion 即時遷移機制的 VM 虛擬主機後，按下滑鼠右鍵並於右鍵選單中選擇編輯設定，此時在彈出的 VM 虛擬主機組態設定視窗中，點選至「虛擬機器選項」頁籤後於「Encrypted vMotion」子項目中，在下拉式選單內看到下列 3 種加密 vMotion 即時遷移機制設定值：
- Disabled： 停用加密 vMotion 即時遷移機制，有可能導致 VM 虛擬主機在執行 vMotion 即時遷移的過程中，遭受中間人攻擊讓惡意攻擊者在傳輸期間修改記憶體狀態內容，進而達到破壞 VM 虛擬主機應用程式或作業系統的目的。
- Opportunistic： 預設值，當來源端及目的端 ESXi 主機都支援加密 vMotion 即時遷移機制時，也就是 2 台 ESXi 主機皆為 ESXi 6.5 版本，那麼在執行 vMotion 即時遷移的過程中便會加密傳輸流量。倘若有任何一端不支援，例如，目的端 ESXi 主機採用 ESXi 6.0 或更舊的版本，那麼在執行 vMotion 即時遷移的過程中便不會加密 vMotion 傳輸流量。
- Required： 來源端及目的端 ESXi 主機都必須支援加密 vMotion 即時遷移機制，倘若有任何一端不支援便無法執行 vMotion 即時遷移機制。同時，當 VMware 叢集啟用 DRS 自動化負載平衡機制後，那麼 DRS 便僅會選擇支援加密 vMotion 即時遷移機制的目的端 ESXi 主機。
圖 7、組態設定 VM 虛擬主機啟用加密 vMotion 即時遷移機制
部署加密 vMotion 的最佳作法
雖然，採用加密 vMotion 即時遷移機制，能夠達到保護 vMotion 即時遷移流量並對於 ESXi 主機的工作負載影響最小，舉例來說，在 20 GbE 的網路環境中執行 vMotion 即時遷移作業，「來源端」ESXi 主機上倘若未啟用 vMotion 加密機制僅需 1 Core 運算核心資源，倘若啟用 vMotion 加密機制則需要 2.2 Cores 運算核心資源，相較之下在「目的端」ESXi 主機上的工作負載差距更小，倘若未啟用 vMotion 加密機制需 2.5 Cores 運算核心資源，倘若啟用 vMotion 加密機制則需要 3.3 Cores 運算核心資源。從測試結果可知，在執行 vMotion 即時遷移時來源端比目的端需要更多的 CPU 運算資源開銷，因為 vMotion 接收程式碼路徑比起傳輸程式碼路徑需要更多 CPU 運算資源，同時在加密及解密 vMotion 即時遷移流量的開銷也不同。事實上，從測試結果可以看到開啟加密 vMotion 即時遷移機制後，每增加 10 Gb/s 的網路流量對於 CPU 運算資源開銷，在來源端或目的端 ESXi 主機都只需要增加 1.x Core 運算核心資源。
圖 8、啟用及停用加密 vMotion 即時遷移機制 CPU 運算資源開銷比較圖表
同時，為了確保在 VMware vSphere 6.5 運作環境中，啟用加密 vMotion 即時遷移機制時能夠得到最佳效能，VMware 的最佳建議作法如下：
- 雖然，啟用加密 vMotion 即時遷移機制並不需要任何硬體設備，但是在選擇 ESXi 主機硬體伺服器的 CPU 處理器時，VMware 強烈建議選擇具備「高階加密標準新指令」（Advanced Encryption Standard New Instruction，AES-NI）指令集功能，以便啟用加密 vMotion 即時遷移機制時，能夠對來源端及目的端 ESXi 主機的 CPU 工作負載降至最低。
- 雖然，在剛才啟用及停用加密 vMotion 即時遷移機制 CPU 運算資源開銷比較圖表中，我們已經知道每增加 10 Gb/s 網路頻寬，對於來源端及目的端 ESXi 主機的 CPU 運算資源開銷僅約增加 1.x Core。但是，這僅用於處理 vMotion 網路流量的 CPU 使用率，對於 ESXi 主機整體處理 vMotion 工作任務來說至少需要 2 Cores 運算資源，因此應確保 ESXi 主機具備足夠的 CPU 運算資源，以便確保 vMotion 即時遷移工作任務能快速且順利執行。
- 不管啟用或停用加密 vMotion 即時遷移機制，對於 vMotion 即時遷移運作效能的最佳建議作法都是相同的。有關 VMware vSphere 6 效能調校最佳實務的詳細資訊，請參考本雜誌<第 118 期 - VMware vSphere 6.0 效能調校最佳實務>文章內容。
圖 9、啟用及停用 AES-NI 加密指令集對於工作負載的效能影響比較圖表
