網管人雜誌
本文刊載於 網管人雜誌第 120 期 - 2016 年 1 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
1、前言2、VSAN 6.1 新功能概要
延伸叢集（Stretched Cluster）
支援 2 Nodes 運作架構
整合 vSphere Replication 及 SRM
支援 SMP-FT
支援 Microsoft WSFC 及 Oracle RAC
支援 DIMM / NVMe SSD
新式 On-Disk 格式
健康狀態檢查外掛程式
整合 vRealize Operations
3、VSAN 延伸叢集最佳實務建議
見證主機（Witness Host）
網路環境需求
ESXi Host 與 VM 虛擬主機
傳統叢集 vs 延伸叢集
4、結語
1、前言
在 2014 年 3 月時，VMware 官方正式釋出 vSphere 5.5 Update 1 版本，同時宣佈在此版本中的 vSphere 開始內建 VMware Virtual SAN 1.0 的版本。
隔年 2015 年 3 月時，隨著最新版本 VMware vSphere ESXi 6.0 的發佈，與 VMware vSphere Kernel 整合的 VSAN（Virtual SAN）技術，也從先前 VSAN 1.0 版本（原訂新版本為 VSAN 2.0），直接與 vSphere 最新版本對齊成為 VSAN 6.0 版本。
目前，最新的 VSAN 6.1 版本為 2015 年 9 月時推出，此版本當中的重要特色功能如下：
- 延伸叢集（Stretched Cluster）： 突破傳統的 VMware Cluster 限制，能夠建立延伸叢集以同步複寫資料至不同地點的兩個站台之間。
- 支援 2 Nodes VSAN 運作架構： 支援 2 Nodes VSAN 運作架構，以便企業或組織在遠端 IT 伺服器機房中，部署高可用性且具成本效益的「超融式（Hyper-Converged）」解決方案。
- 整合 vSphere Replication 及 SRM： 可以在延伸叢集運作架構當中，整合 vSphere Replication 及 SRM 特色功能提供異地備援機制。
- 支援 SMP-FT： 支援 vSphere 6.0 版本當中，VM 虛擬主機需要多顆 vCPU 並啟用 FT（Fault Tolerance）的 SMP-FT 機制。
- 支援 Microsoft WSFC 及 Oracle RAC： 支援 Microsoft WSFC（Windows Server Failover Clustering），以及 Oracle RAC（Real Application Clusters）等應用程式高可用性機制。
- 支援 DIMM / NVMe SSD： 支援 DIMM-Based 的 SSD 固態硬碟，提供小於 5 us 的資料寫入延遲時間，並且也支援新式的 NVMe SSD 固態硬碟。
- 新式 On-Disk 格式： 在舊有的 VSAN 版本中為 1.0，現在則採用新式的 2.0 格式。
- 健康狀態檢查外掛程式（Health Check Plug-in）： 有效協助管理人員進行硬體、韌體、驅動程式相容性檢查、網路即時診斷機制…等，同時能夠確保整個 VSAN 叢集內所有進階組態設定的一致性。
- 整合 vRealize Operations： 透過 VSAN Management Pack，便能與 vRealize Operations 整合在一起，提供管理人員對於 VSAN 叢集及運作狀態進行更進一步的監控作業。
- 支援 Docker / Containers： 現在，VSAN Datastore 資料儲存區，也可以支援 Docker/Containers 運作機制。
圖 1、Virtual SAN 6.1 新功能概要示意圖
2、VSAN 6.1 新功能概要
首先，VSAN（Virtual SAN）是由 VMware 所發展「軟體定義儲存（Software-Defined Storage，SDS）」技術，它能夠將多台 x86 伺服器上的「本機儲存資源（Local Storage）」，串連起來變成一個伺服器彼此之間共享的儲存空間，同時透過多台 x86 伺服器上的 SSD 固態硬碟快速存取特性，提升 VSAN 整體運作環境的資料 I/O 效能，然後以一般機械式硬碟大容量的儲存空間來儲存資料。
SDS 軟體定義儲存的一個關鍵因素，就是提供以原則為方式的儲存管理機制（Storage Policy-Based Management，SPBM）。事實上，在 vSphere 5.0 版本時，就已經導入到 VMware Storage Profile 儲存管理概念當中，並且在 vSphere 5.5 版本時成為關鍵性的特色功能，也是 VMware 達成軟體定義儲存的關鍵。
透過 SPBM 及 vSphere API 機制，將儲存資源抽象化並整合為資源池之後，便能提供 vSphere管理人員佈建 VM 虛擬主機的能力，佈建的機制包含 效能、可用性、儲存服務（精簡配置、壓縮、複本…等）。然後，針對不同的 VM 虛擬主機服務等級，採用不同的 VM 虛擬主機儲存原則（VM Storage Policy），進行 VM 虛擬主機的佈建動作，也就是透過 SPBM 儲存管理機制，將 VM 虛擬主機進行適當的擺放。
VSAN 已經深度整合在 vSphere 當中，並具備 SPBM 儲存管理機制，因此佈建後的 VM 虛擬主機，隨著時間及服務項目的增長，工作負載與資料 I/O 都逐漸成長而不敷使用時，只需要套用新的 VM 虛擬主機儲存原則之後，無須 vSphere 管理人員手動介入，便會在背景自動執行且無縫式的調整完畢（相較於傳統儲存設備，管理人員必須人為介入，為 VM 虛擬主機掛載及卸載虛擬磁碟…等手動作業）。
圖 2、VMware VSAN 軟體定義儲存概念示意圖
延伸叢集（Stretched Cluster）
從 VSAN 6.1 版本開始，正式支援「延伸叢集（Stretched Cluster）」運作架構。現在，管理人員可以在兩個不同的地理位置或站台之間，建立 VSAN 延伸叢集運作架構以便在這兩個站台之間同步彼此的資料，有效解決過去傳統 VMware Cluster 單一站台失敗的問題。
在過去傳統 VMware Cluster 運作架構中，若是發生大規模的故障損壞事件（例如，機房電力非預期斷電、人為操作疏失…等），或是遭遇到天然災害（例如，颱風、洪水、地震...等），造成企業或組織當中主要資料中心停止服務時，倘若平時並沒有做好異地資料同步及備援的工作時，將會嚴重影響企業及組織的 RPO（Recovery Point to Object）及 RTO（Recovery Time to Object）。
現在，透過 VSAN 延伸叢集機制，在平台除了可以透過 VMware vMotion 及 vSphere DRS 機制，進行兩地站台之間工作負載自動平衡的作業之外，在發生單一站台大規模的故障損壞事件時，也可以整合原有的 VMware vSphere HA 機制來進行因應，有效提升企業或組織整體的 RPO 及 RTO 表現。
圖 3、VMware VSAN 延伸叢集（Stretched Cluster）運作架構示意圖
支援 2 Nodes 運作架構
從 VSAN 1.0 版本開始，在 VSAN 的運作架構中一直以來節點主機的最小需求為「3 Nodes」，才可以建置 VSAN Cluster。(請注意!! 在 VSAN 1.0 版本當中，VSAN Cluster 規模最多支援至 32 台 Nodes。在 VSAN 6.0、6.1 版本當中，VSAN Cluster 規模最多支援至 64 台 Nodes)。
現在，最新版本的 VSAN 6.1 版本當中，為了因應 ROBO（Remote Office / Branch Office）需求，也就是企業或組織當中遠端辦公室或分支辦公室的小型儲存資源需求。因此，管理人員可以在各分支辦公室中建立「2 Nodes」的 VSAN Cluster，然後在母公司以 1 台 vCenter Server 統一進行管理。
圖 4、VMware VSAN ROBO 運作架構示意圖
整合 vSphere Replication 及 SRM
現在，在新式的 VSAN 延伸叢集運作架構當中，原有的 vSphere Replication 及 SRM（Site Recovery Manager）異地備援機制，也已經可以跟新式的 VSAN 延伸叢集協同運作，讓企業或組織不會因為採用新式的 VSAN 延伸叢集運作架構，而失去原有異地備援機制的彈性。
圖 5、VMware VSAN 延伸叢集與 vSphere Replication 及 SRM 協同運作架構示意圖
支援 SMP-FT
從 vSphere 6.0 版本開始，啟用「FT（Fault Tolerance）」特色功能的 VM 虛擬主機，其 vCPU的數量最多可以支援至「4 vCPU」，也就是「SMP-FT（Multi-Processor Fault Tolerance）」運作機制。(請注意!! 必須採用 ESXi Enterprise Plus 授權版本才能支援至最大 4 vCPU，若採用的是 ESXi Standard / Enterprise 授權版本的話，那麼最多只能支援至 2 vCPU 而已。)
但是，在 VSAN 6.0 版本中並無法與 vSphere 6.0 當中的 SMP-FT 機制協同運作。現在，最新的 VSAN 6.1 版本已經能夠與 SMP-FT 機制協同運作，順利運作 4 vCPU 的 VM 虛擬主機。
圖 6、VMware VSAN 與 SMP-FT 機制協同運作示意圖
支援 Microsoft WSFC 及 Oracle RAC
此外，在 VSAN 6.1 運作環境中運作的 VM 虛擬主機，現在也完全支援 Microsoft 及 Oracle 叢集技術。簡單來說，現在運作於 VSAN Datastore 的 VM 虛擬主機，可以順利建構 Microsoft WSFC（Windows Server Failover Clustering）及 Oracle RAC（Real Application Clusters）等叢集架構，達成 Application Level 的高可用性機制，以便補足 Host Level 高可用性機制 SMP-FT 的不足。
事實上，在 VSAN 6.0 版本時也有支援 Oracle RAC 高可用性機制，但是有較多的相關限制及注意事項，詳細資訊請參考 VMware KB 2121181，至於 Microsoft WSFC 的部分，詳細資訊請參考 VMware KB 1004617。
圖 7、VMware VSAN Datastore 支援 VM 虛擬主機建立 Microsoft WSFC 及 Oracle RAC
支援 DIMM / NVMe SSD
過去，在 VSAN 1.0 及 6.0 版本當中，擔任資料「讀取（Read）/寫入（Write）」快取角色的 SSD固態硬碟部分，支援採用 SAS / SATA / PCIe 介面的 SSD 固態硬碟。現在，最新的 VSAN 6.1 版本當中，支援兩種更快的傳輸介面分別是「NVMe（Non-Volatile Memory Express）及ULLtraDIMM」。
在 NVMe SSD 固態硬碟的部分，透過此新式通訊介面可以提供 VSAN 更佳的運作效能，在VMware 官方的測試結果當中，可達每台 VSAN Node「10 萬 IOPS」，也就是在 32 Nodes 的 VSAN Cluster 運作架構中，提供高達「320 萬 IOPS」的儲存效能。
在 ULLtraDIMM SSD 固態硬碟的部分，此項技術是透過伺服器的「記憶體插槽（Memory DIMM Slots）」，達成「< 5 us」非常低的資料寫入延遲時間，並且可以最大化空間密度（All Flash 運作架構 VSAN 運作節點，單台空間最大可達 12 TB）。
圖 8、ULLtraDIMM SSD 固態硬碟特色功能示意圖
新式 On-Disk 格式
在 VSAN 1.0 版本，也就是採用 vSphere 5.5 的虛擬化平台運作架構，在這樣的運作架構中On-Disk 格式版本同樣為「1.0」。但是，新的 VSAN 6.1 版本當中的 vSphere 6.x 虛擬化平台，已經轉換為 Virsto 技術的日誌型式檔案系統，來因應 VSAN 叢集高可擴充性、快照、複寫管理等需求。因此，你可以透過 vSphere Web Client 管理介面，將 On-Disk 磁碟格式線上升級為「2.0」版本。
圖 9、VSAN 6.1 版本 On-Disk 格式版本升級示意圖
此外，在 VSAN 節點主機當中硬碟宣告的部分，在 VSAN 6.0 時若採用 All-Flash 運作架構時，管理人員只能採用 CLI 指令的方式，手動指定採用的 Flash 裝置為「Capacity Tier」。現在，在 VSAN 6.1 版本當中，你在 vSphere Web Client 的管理介面中，便可以直接指定該硬碟是「Cache Tier 或 Capacity Tier」或者宣告該硬碟並非是 VSAN 的儲存資源。
圖 10、VSAN 6.1 可以管理介面中指定硬碟所擔任的儲存資源層級
健康狀態檢查外掛程式
在 VSAN 6.1 版本當中，管理人員可以在 vSphere Web Client 管理介面當中，查看 VSAN 組態設定、叢集、資料、網路、硬碟...等健康狀態。此健康狀態檢查外掛程式包含下列檢查項目：
- 硬體相容性檢查： 檢查 x86 伺服器底層的硬體類型、韌體、驅動程式相容性檢查…等，以協助管理人員在進行建置 VSAN 運作架構之前，確認目前所使用的 x86 伺服器硬體是否適合建置。
- 硬體診斷： 偵測在 VSAN 運作架構中是否存在硬體問題，例如，儲存設備的健康情況、VSAN節點的網路連接情況、ESXi Host 及 VSAN Cluster 的組態配置...等。
- 組態配置管理： 確保在 VSAN Cluster 運作架構中，每台 VSAN 叢集節點的組態配置是否一致。
- 主動測試機制： 提供管理人員隨時針對 VSAN Cluster 及運作元件進行測試作業。
- VM 虛擬主機建立測試： 測試在 VSAN Cluster 當中是否能順利建立 VM 虛擬主機。
- 多點傳播效能測試： VSAN Cluster 當中的叢集節點，採用「多點傳播（Multicast）」進行溝通及資料傳輸作業，此項測試可以提供 VSAN 叢集節點之間多點傳播的網路環境健康情況。
- 儲存資源效能測試： 針對 VSAN Cluster 在大量 I/O 工作負載的情況下，VSAN 叢集節點的運作穩定性。
圖 11、VSAN 6.1 健康狀態檢查外掛程式管理介面
整合 vRealize Operations
事實上，在 vCenter Operations 5.8 版本（vRealize Operations 舊稱）時，便開始支援 VSAN但並不完全，舉例來說，並無法看到 VSAN Datastore 的 Disk I/O。因此，在 VSAN 舊版的運作環境中，VMware 官方建議採用 RVC（Ruby vSphere Console）工具，來協助監控及分析 VSAN 運作狀態。
現在，在 VSAN 6.1 新版本中，已經可以透過 VSAN Management Pack for vRealize Operations，讓 vRealize Operations 可以完整支援及監控 VSAN 運作環境，舉例來說，支援針對 VSAN Cluster環境的「監控 / 告警 / 通知」、針對 VSAN 叢集節點進行「CPU / Memory / Network」等效能監控、針對 VSAN 儲存資源進行容量的「規劃 / 預測 / 監控」...等。
圖 12、VSAN Management Pack for vRealize Operations 管理介面示意圖
3、VSAN 延伸叢集最佳實務建議
事實上，在 VSAN 1.0 版本時，許多管理人員便開始討論及嘗試實作「VSAN 延伸叢集（Stretched Cluster）」的可能性。現在，VSAN 6.1 版本正式支援此 Site Level 的高可用性機制，這也是 VSAN 6.1版本中最亮眼的特色功能。
圖 13、VMware VSAN 延伸叢集及整合主機運作架構示意圖
見證主機（Witness Host）
那麼，在 VSAN 延伸叢集運作架構中，當其中一個站台發生重大故障損壞事件，導至該站台停止服務時系統是否何判斷的？ 若只是兩個站台之間發生網路中斷，但是兩個站台並沒有停止服務，此時會不會造成誤判產生「裂腦（Split-Brain）」的情況呢？
在 VSAN 6.1 的延伸叢集運作架構中，必須要在第三站台建立「見證主機（Witness Host）」，這台見證主機便是擔任兩個站台之間「仲裁（Quorum）」的角色，它可以是實體主機或 VM 虛擬主機，並且根據不同的運作架構規模大小，有不同的硬體需求建議：
小型規模（1 VMs ~ 10 VMs）
- 2 vCPU、8 GB vRAM
- Boot Disk： 8GB、SSD Disk： 10GB（1顆）、HDD Disk： 15GB（1顆）
- 支援最多 750 見證元件
中型規模（10 VMs ~ 500 VMs）
- 2 vCPU、16 GB vRAM
- Boot Disk： 8GB、SSD Disk： 10GB（1顆）、HDD Disk： 350GB（1顆）
- 支援最多 21,000 見證元件
大型規模（500 VMs以上）
- 2 vCPU、32 GB vRAM
- Boot Disk： 8GB、SSD Disk： 10GB（1顆）、HDD Disk： 350GB（3顆）
- 支援最多 45,000 見證元件
網路環境需求
在 VSAN 延伸叢集運作架構當中，VSAN Cluster 及 VSAN Node 所處位置稱之為「資料站台（Data Sites）」，而見證主機所處位置則稱之為「見證站台（Witness Site）」。
在資料站台當中 VSAN Cluster 的 VSAN Node 彼此之間，採用「多點傳播（Multicast）」來傳輸中繼資料及運作狀態，以及採用「單點傳播（Unicast）」來傳輸資料 I/O 的部分。此外，資料站台與見證站台之間，則是透過「單點傳播（Unicast）」來互相進行溝通及存活偵測作業。
因此，在資料站台之間可以規劃採用「Layer 2 或 Layer 3」的網路環境彼此連接，並且網路延遲時間必須在「5 ms RTT（Round Trip Time）」以下才行，也就是說單向的網路延遲時間必須小於 2.5ms才行，並且網路頻寬建議至少採用「10 Gbps」。
在資料站台與見證站台之間則僅建議採用「Layer 3」網路環境，並且網路延遲時間不可以大於「200 ms RRT」，也就是單向網路延遲時間必須小於 100ms 才行，並且網路頻寬建議至少採用「50 ~ 100Mbps」。
圖 14、VMware VSAN延伸叢集資料站台及見證站台的網路架構示意圖
ESXi Host 與 VM 虛擬主機
值得注意的是，在 VSAN 延伸叢集運作架構當中，因為必須考量到其中一座資料站台完全下線的情況，因此 VMware 建議每座資料站台應僅運作 VM 虛擬主機總數的 50% 即可，舉例來說，規劃的 VM 虛擬主機總數為 500 台的話，那麼每座資料站台應僅運作 250 台 VM 虛擬主機即可，以便發生災難事件時另一座資料站台，可以完成承載所有的 VM 虛擬主機工作負載。
在 VSAN 延伸叢集當中 ESXi Host 的數量，最少數量的情況下為「3 台（1 + 1 + 1）」ESXi Host，也就是資料站台 A 運作 1 台 ESXi Host 資料站台 B 運作 1 台 ESXi Host，見證站台也運作 1 台ESXi Host。目前，在 VSAN 6.1 版本當中，最大的運作規模則建議為「31 台（15 + 15 + 1）」ESXi Host，也就是資料站台 A 運作 15 台 ESXi Host 資料站台 B 運作 15 台 ESXi Host，見證站台也運作 1 台 ESXi Host。
圖 15、VMware VSAN 3+3+1 延伸叢集運作架構示意圖
傳統叢集 vs 延伸叢集
最後，管理人員應該會好奇，在採用 VMware 傳統叢集來運作 VSAN 運作架構，以及新式的VSAN 延伸叢集架構，在 IOPS 儲存效能的表現上到底哪一種叢集比較出色。
在 VMware 官方測試結果當中可以得知，在採用 VMware 傳統叢集來運作 VSAN 運作架構時，由於是 VSAN Node 彼此在近端因此 IOPS 表現較好。當採用 VSAN 延伸叢集架構時，若資料站台之間的網路延遲時間為「1 ms」時，則 IOPS 相較於傳統叢集來說大約「降低20%」，若資料站台之間的網路延遲時間為「5 ms」時，則 IOPS 相較於傳統叢集來說大約「降低 35%」。
在資料「寫入延遲（Write Latency）」的部分，同樣的傳統叢集因為主機之間彼此在近端因此為「2.9ms」，而採用新式的 VSAN 延伸叢集架構時則分別是「4.9ms 及 7.7ms」，至於資料「讀取延遲（Read Latency）」的部分，兩種叢集架構的表現則是差不多的。
圖 16、VMware VSAN 傳統叢集與延伸叢集 IOPS 效能比較統計表
4、結語
透過本文的說明，相信讀者已經了解到最新的 VSAN 6.1 版本多了哪些特色功能，能夠幫助企業或組織提供更佳的高可用性機制。此外，在本文的後半部則給予 VSAN 6.1 新式延伸叢集架構的最佳實務建議，以便管理人員在前置作業流程時能夠注意相關細節，以便規劃出來的 VSAN 延伸叢集架構能為企業或組織提供最佳的運作彈性。
