網管人雜誌
本文刊載於 網管人雜誌第 116 期 - 2015 年 9 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
1、前言2、vCenter Server的重要性
3、vCenter Server高可用性解決方案
高可用性方案 1、vSphere HA
高可用性方案 2、vSphere FT
高可用性方案 3、協力廠商工具
高可用性方案 4、vCenter Server Heartbeat
高可用性方案 5、Guest OS Cluster
4、各種版本對高可用性機制的支援
5、高可用性機制的優缺點比較
6、結語
1、前言
對於企業及組織來說，線上營運環境所追求的是能夠穩定運作的服務。因此，目前在企業內部的 VMware vSphere ESXi 虛擬化平台，主流版本應該是 VMware vSphere ESXi 5.x 版本（事實上，仍有部分企業或組織，仍使用更舊的 VMware vSphere ESXi 4.x 版本）。然而，以最後一版穩定的主流版本 ESXi 5.5 來說，也已經是在 2013 年 9 月時所推出的，雖然至目前為止仍持續不斷釋出相關更新當中。但是，相信企業及組織的 IT 管理人員，應該都已經紛紛評估 2015 年 3 月，正式發行的 VMware vSphere ESXi 6.0 最新版本。
在最新發行的 VMware vSphere 6.0 虛擬化架構版本中，除了整體支援度更加提升之外，最令大家期待的功能之一，應該是 vMotion 即時遷移機制的增強功能，因為此項即時遷移機制已經打破了地域及其它相關限制。
並且，在 vSphere 6.0 當中 vCenter Server 的運作架構也大肆翻新與過往不同，舉例來說，過去在 vCenter Server 5.5 版本時，除了 vCenter Server 本身的服務之外，還必須安裝其它協同運作元件如 Single Sign-On、Inventory Service、vSphere Web Client...等。但是，新版的 vCenter Server 6.0 將這些運作元件，全部整合在一起成為「PSC（Platform Services Controller）」。
圖 1、vCenter Server 協同運作元件升級示意圖
過去，在 Windows 作業系統平台上，所安裝的 vCenter Server 版本，內建的預設資料庫一律都是 SQL Server Express。但也因為採用的是 Express 的 SQL Server 版本，除了記憶體被限制只能使用 1 GB 之外，資料庫大小也被限制在 10 GB 大小，因此 VMware 官方在相關白皮書中，總是建議這樣的資料庫只能承載小於 5 台 ESXi 主機、50 台 VMs 的運作架構，一旦超過這樣的架構應該要採用正式版本的 SQL Server 或 Oracle 資料庫。
但是，額外在採購一套正式版本的 SQL Server 給 vCenter Server 使用，對於原本IT預算就吃緊的中小企業來說，是筆額外的負擔。現在，新版的 vCenter Server 6.0 已經將預設內建資料庫更改為 PostgreSQL。除了節省購買資料庫的費用之外，PostgreSQL 資料庫可以承載 1,000 台 ESXi 主機及 10,000 台 VM 虛擬主機的運作架構。
值得注意的部分是，若企業或組織舊有的 vCenter Server 運作架構，在建置時採用內建的 SQL Server Express 資料庫，那麼升級為最新版本的 vCenter Server 6.0 之後，原有的資料庫內容將會自動遷移轉換為 PostgreSQL 資料庫。
2、vCenter Server的重要性
在 VMware vSphere 虛擬化架構中，vCenter Server 的重要性不言而喻，當 vCenter Server 發生故障損壞事件無法正常服務時，雖然短期來看對於虛擬化架構的運作不會造成立即的影響，並且 vSphere HA 高可用性機制仍然持續運作，以因應發生非計劃性災難事件時，讓 VM 虛擬主機能盡量縮短停機時間。但是，失去了 vCenter Server 的虛擬化架構，管理人員將無法進行任何的管理作業，舉凡 部署 VM 虛擬主機、調整虛擬交換器、遷移 VM 虛擬主機...等。
因此，如何建構高可用性的 vCenter Server 運作架構，便成為非常重要的課題。本文，將要與大家討論各種 vCenter Server 高可用性的優缺點，舉凡 vSphere HA（High Availability）、vSphere FT（Fault Tolerance）、vCenter Server Watchdog、vCenter Server Heartbeat、WSFC（Windows Server Failover Cluster）等，以便IT管理人員可以選擇出對於目前的運作環境，最適合的 vCenter Server 高可用解決方案。
在建構高可用性的 vCenter Server 運作架構之前，我們先了解 vCenter Server 6.0 版本中，最重要的 3 個組成元件：
- vCenter Server： 包含絕大部分的管理及服務等功能（但不包括PSC所執行的服務）。
- 資料庫： 用來存放vCenter Server對於虛擬化環境的組態配置資料，資料庫若損毀也將造成vCenter Server無法啟動。
- PSC： 負責SSO、Licensing、Global Permissions...等服務，與vCenter Server協同運作。
3、vCenter Server高可用性解決方案
事實上，不管是 VMware 本身或其它協力廠商，都有針對 vCenter Server 高可用性部分推出解決方案，本文將會著重在討論 VMware 本身所提供的 vCenter Server 高可用性解決方案，進行功能性的討論以及優缺點比較。此外，你已經了解到 vCenter Server 整體服務的組成，除了資料庫之外還有 PSC 協同運作的部分。其實，在 PSC 的部分也可以打造出高可用性的運作架構，也就是建立多組 PSC 並透過「複寫 (Replicating)」的方式，讓多台 PSC 主機之間的資料能夠同步，同時配合負載平衡機制，即可建構出高可用性的 PSC 運作機制。
圖 2、PSC高可用性機制運作示意圖
高可用性方案 1、vSphere HA
第 1 種 vCenter Server 高可用性機制，為大家所熟知的 VMware vSphere High Availability （vSphere HA）機制。在 VI 3.x 及 vSphere 4.x 時代稱之為 VMware HA，它是由 EMC Autostart 產品（收購自 Legato Automated Availability Manager）所改寫而成的特色功能。運作原理是首先加入 HA Cluster 中的前 5 台 ESX/ESXi 主機，便會擔任 Primary Host 的角色，而之後加入的 ESX/ESXi 主機則擔任 Secondary Host 角色，同時 5 台 Primary Host 角色當中，會自動推舉出 1 台主機，擔任這整體 Primary/Secondary 運作架構中的 Active Paimary Host 角色，負責收集所有主機的運作狀態，並且回報給 vCenter Server。
圖 3、舊版 VMware HA 運作架構示意圖
圖片來源： VMware 官方文件 – High Availability and Data Protection
從 vSphere 5 版本開始，除了正式改名為 vSphere HA 之外底層的運作架構也整個翻新，新版的 vSphere HA 機制捨棄原本的 AAM(Automated Availability Manager) 運作架構，改為採用「Fault Domain」及 Master/Slave 的運作架構。它會在 HA Cluster 當中為每 1 台 ESXi 主機，安裝 FDM（Fault Domain Manager）代理程式，同時在 Fault Domain 的運作架構中，只會有 1 台 Master 主機其它則為 Slave 主機，只有當 Master 主機發生故障損壞事件後，才會從 Slave 主機中推舉出 1 台新的主機擔任 Master 主機的角色。
圖 4、新版 vSphere HA 運作架構示意圖
VMware 對於此需求的最佳做法及建議是，採用 vSphere HA 並結合 vSphere DRS 機制，以提供 vCenter Server 服務最佳可用性。並且，在這樣的虛擬化運作架構中，應該要注意及驗證相關項目，以便因應「所有可用路徑離線（All Paths Down，APD）」、「設備永久遺失（Permanent Device Loss，PDL）」等故障損壞事件：
- 驗證 vCenter Server 的組態配置，是否都存放於共享儲存資源當中。
- 驗證 HA Cluster 當中的 ESXi 主機，儲存網路及 VM 網路是否都有建立 NIC Teaming 機制。
- 驗證 HA Cluster 當中的 ESXi 主機，是否都能存取共享儲存資源以及所有的 VM 虛擬主機。
- 驗證 HA Cluster 當中的 ESXi 主機，是否建立管理網路的容錯線路（vSphere HA Heartbeat Redundant）。
- 驗證 HA Cluster 中是否至少存在 2 個共享儲存資源，以便達成 vSphere HA Datastore Heartbeat Redundant 架構。
- 驗證透過 vSphere Web Client 連線至 vCenter Server 的使用者帳號，是否具備 Cluster Administrator 的權限。
- 驗證 HA Cluster 當中是否啟用 Admission Controller 機制，以便觸發 vSphere HA 機制時，在 HA Cluster 當中其它存活的 ESXi 主機，具備足夠的硬體資源可承載其它的 VM 虛擬主機。
- 驗證是否為 vCenter Server 及 Database 虛擬主機，設定 VM Restart Prioirty 等級為 High，以便啟動 vSphere HA 機制時，確保優先啟動這 2 台 VM 虛擬主機。
圖 5、Admission Controller 運作示意圖
Watchdog for vCenter Server
事實上，熟悉 vSphere HA 機制的 IT 管理人員便知，vSphere HA 高可用性機制必須在 ESXi 主機，發生非計劃性的故障損壞事件時，才會透過 vSphere HA 機制在 HA Cluster 中其它存活的 ESXi 主機，將存放在共享儲存資源中的 VM 虛擬主機重新啟動。
若是底層的 ESXi 主機並未發生故障損壞事件，而是 vCenter Server 虛擬主機中本身所運作的服務停止時，那麼 vSphere HA 高可用性機制是幫不上忙的。
在 vCenter Server 6.0 中新增了「Watchdog」監控機制，採用「vCenter Server Processes （PID Watchdog）」或「vCenter Server API （API Watchdog）」的方式，來偵測 vCenter Server 虛擬主機中本身所運作的服務，當運作的服務發生故障事件而停止運作時，前 2 次發生時 Watchdog 會嘗試重新啟動服務，第 3 次若仍無法重新啟動服務時，便會將 VM 虛擬主機重新啟動。
在預設情況下，Watchdog 監控機制便會「自動啟用」，同時它支援 vCenter Server Appliance 以及 Windows vCenter Server 作業平台。此外，Watchdog 監控機制僅最新版本 vCenter Server 6.0 才支援，舊版 vCenter Server 4.x、5.x 並不支援此監控機制。
圖 6、整合 vSphere HA 及 Watchdog 機制保護 vCenter Server 服務示意圖
高可用性方案 2、vSphere FT
VMware vSphere Fault Tolerance（vSphere FT）特色功能，在過去舊版本中一直被 IT 管理人員所詬病的，就是 VM 虛擬主機的 vCPU 數量。現在，新版 vSphere 6.0 中的 FT 功能，VM虛擬主機最多可以支援至 4 vCPU。(請注意!! 只有採用 Enterprise Plus 版本才支援 4 vCPU，若採用的是 Standard 及 Enterprise 版本的話，VM 虛擬主機最多只能支援至 2 vCPU)同時，在舊版的 Fault Tolerance 運作環境中，欲啟用 FT 功能的 VM 虛擬主機，除了不能建立任何「快照（Snapshot）」之外，虛擬磁碟也只能使用「EZT（Eager Zeroed Thick）」格式。新版的 FT 功能，除了支援 VM 虛擬主機能夠建立快照之外，在虛擬磁碟的部分也支援所有格式，現在你可以使用「Thin、Thick、EZT」等 3 種格式的虛擬磁碟。
最後，在舊版的 Fault Tolerance 運作機制中，主要及次要 VM 虛擬主機之間，資料同步的方式稱之為「Record-Replay」。新版的 Fault Tolerance 將資料同步機制改變為「Fast Checkpointing」，它的運作機制是透過 xvMotion（Cross-vCenter vMotion），採用持續不斷且大量的 Checkpoints（Multiple/Sec）動作，以達成主要及次要 VM 虛擬主機之間的資料同步作業。
與 vSphere HA 高可用性機制不同的地方在於，當 Cluster 內的 ESXi 主機發生非計劃性故障損壞事件時，vSphere HA 所保護的 vCenter Server 虛擬主機，會從 Cluster 中其它存活的 ESXi 主機上「重新啟動」，因此 vCenter Server 服務的中斷時間大約會是 2 ~ 5 分鐘之間 (實務上，必須視儲存設備的運作效能而定)。
而 vSphere FT 高可用性機制，因為平時主要及次要 VM 虛擬主機之間，便已經透過 Fast Checkpointing 技術同步 2 台主機之間的資料，因此當 Cluster 內的 ESXi 主機發生非計劃性故障損壞事件時，雖然主要 VM 虛擬主機故障損壞無法服務，但次要 VM 虛擬主機將立即接手所有服務，並且將自身角色轉變成為主要主機，同時在另 1 台 ESXi 主機上再建立 1 台次要主機，將目前的資料透過 Checkpointing 技術再次同步，整個 vCenter Server 服務接手期間是沒有中斷時間的（Zero Downtime），同時也不會有任何資料遺失的問題（Zero Data Loss）。
雖然，相較於 vSphere HA 機制 vSphere FT 提供更即時的保護，但是仍有下列限制以及注意事項必須考量：
- 啟用 vSphere FT 機制的 vCenter Server 虛擬主機，最多僅支援至 4 vCPU 及 64 GB Memory，這樣的 VM 虛擬主機規模無法承受大型虛擬化架構的工作負載。
- 啟用 vSphere FT 機制的 vCenter Server 虛擬主機，vCPU 及 vRAM 虛擬資源將會重置為「保留（Reservation）」狀態且無法更改，虛擬磁碟也無法增加或刪除。
- vSphere FT 機制主要是因應 ESXi 主機發生硬體故障事件（Host Level），而無法因應 vCenter Server 應用程式發生的軟體故障事件（Application Level）。
- vSphere FT 機制無法因應主機進行更新或修復作業，所產生的停機時間。
- 啟用 vSphere FT 機制後，除了多出 1 台次要主機增加資源消耗之外，由於 2 台主機之間會有大量且頻繁的同步資料行為，因此需要專用 10Gbps 且低延遲的 VMkernel 網路環境。
- 驗證透過 vSphere Web Client 連線至 vCenter Server 的使用者帳號，是否具備 Cluster Administrator 的權限。
圖 7、整合 vSphere FT 機制保護 vCenter Server 服務示意圖
高可用性方案 3、協力廠商工具
VMware 在 vSphere HA 機制中，已經開放 Application Monitoring API 介面，讓協力廠商可以透過 API 與 vSphere HA 機制整合在一起，達到保護 VM 虛擬主機上運作的應用程式或服務（Application Level），以補足 vSphere HA 機制只有 Host Level 的缺口。舉例來說，Symantec ApplicationHA 便是這類的協力廠商工具。此類工具會在 VM 虛擬主機中，安裝代理程式並監控應用程式的健康情況，當應用程式或服務發生錯誤無法啟動時，代理程式會把狀態轉送及回報給 vSphere HA，以便透過 vSphere HA 機制將 VM 虛擬主機重新啟動。
圖 8、Symantec Application HA 運作示意圖
高可用性方案 4、vCenter Server Heartbeat
vCenter Server Heartbeat 在 2009 年 3 月時正式推出，它是結合 Neverfail 公司的技術而推出的產品。它可以配合運作在實體主機或 VM 虛擬主機的 vCenter Server，並且採用Primary/Secondary 的運作架構，2 台主機之間會透過 Heartbeat 通道，監控及交換主機之間的運作狀態及資料，一旦 Primary 主機發生故障事件而停止服務時，Secondary 主機將會立即接手相關服務。值得注意的是，此產品在 2014 年 6 月便進入 EOA（End Of Availability）狀態，也就是後續將不會再有這個產品出現了。因此，在新版 vCenter Server 6.0 當中，並不支援 vCenter Server Heartbeat 高可用性機制，只有舊版 vCenter Server 4.x、5.x 才有支援。
圖 9、vCenter Server Heartbeat 運作示意圖
高可用性方案 5、Guest OS Cluster
最後 1 種高可用性解決方案，則是透過 vCenter Server 虛擬主機中，所運作的 Guest OS 作業系統來達成，也就是結合「Windows 容錯移轉叢集（Windows Server Failover Cluster，WSFC）」高可用性機制，或稱之為 MicroSoft Cluster Service（MSCS），相關資訊可參考 KB 1004617。在運作 Windows 容錯移轉叢集架構中，必須要有共享磁碟來擔任「仲裁磁碟（Quorum Disk）」，而共享磁碟通常透過 FC（Fibre Channel）、FCoE、iSCSI...等來提供，同時叢集節點之間也必須建立 Heartbaet 專用網路。
圖 10、Windows 容錯移轉叢集運作架構示意圖
WSFC 高可用性解決方案為 Application Level 的保護機制，當主要叢集節點上不管是作業系統或服務發生故障事件，另 1 台叢集節點便會立即接手服務。此外，即使叢集節點進行修補或安全性更新作業，都不會影響到線上服務的運作，有效讓停機時間最小化。
目前，vCenter Server 支援建構的 WSFC 版本，為 Windows Server 2008 R2 SP2 以及Windows Server 2012 R2，同時在共享磁碟的部分必須採用 RDM（Raw Device Mapping）的方式進行掛載。
並且，在 vCenter Server 資料庫的部分，必須採用 SQL Server 2012/2014 資料庫而不能採用新版內建的 PostgreSQL 資料庫。當安裝好 vCenter Server 服務之後，必須把所有在安裝過程中建立的 VMware 系統服務，都將服務啟動類型設定為「手動」，並在設定高可用性叢集服務時選擇「一般服務」即可。
最後，記得設定 vSphere DRS 中的 Anti-Affinity 規則，將建立 WSFC 的 vCenter Server 叢集節點主機，強制分離在不同的 ESXi 主機上運作，避免叢集節點 VM 虛擬主機運作在同一台 ESXi 主機上，相關資訊可參考 KB 1037959。
圖 11、vCenter Server 整合 Windows 容錯移轉叢集運作架構示意圖
4、各種版本對高可用性機制的支援
至此，我們已經介紹多種 vCenter Server 高可用性解決方案。然而，對於追求穩定服務的企業或組織來說，並非會立即採用官方所發行的最新版本 vCenter Server，那麼該如何針對企業環境中現有的版本選擇最適合的解決方案呢？下列表格中，我們已經將上述所介紹的各種高可用性解決方案，以及各種 vCenter Server 版本的支援度進行整理：（相關資訊可參考 KB 1024051）
5、高可用性機制的優缺點比較
除了各種 vCenter Server 版本對高可用性解決方案的支援度之外，我們也為讀者整理出各種高可用性機制中，針對容錯移轉時間、成本、複雜度...等各項功能進行比較。舉例來說，vSphere HA 機制是所有高可用性機制中，在「成本及複雜度」上所花費的營運及管理成本是最低的，但是在容錯移轉時間的花費上卻也是最長的，而 Guest OS Failover（WSFC）高可用性機制，雖然在「容錯移轉時間」的花費上最短，但整體來看成本及複雜度卻是最高的。
