網管人雜誌
本文刊載於 網管人雜誌第 108 期 - 2015 年 1 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
1、前言2、VMware VSA 與 VSAN 有何不同？
3、如何挑選建置 VSAN 環境的 x86 伺服器？
4、如何規劃及估算 VSAN 的儲存空間？
5、建置 VSAN 環境時，SSD 無法被正確辨別？
6、建置的 VSAN 環境運作效能極差？
7、VSAN 環境，ESXi 應該裝在 SD/USB 或硬碟內？
8、將 ESXi 安裝在 USB 當中，卻發生系統日誌為暫存？
9、結語
1、前言
隨著虛擬化技術的普及，許多企業及組織都已經建立虛擬化運作環境。熟悉 VMware 虛擬技術的 IT 管理人員都知道，若要建置高可用性的 VMware 虛擬化環境，必須協同使用如 vSphere HA（High Availability）、VMware vSphere DRS（Distributed Resource Scheduler）、VMware vSphere vMotion…等相關進階功能，但使用這些進階功能有個很重要的前提，那就是必須要先建置「共享儲存設備（Shared Storage）」才行。但是，具備高穩定高效能的傳統儲存設備往往所費不貲，舉例來說 儲存設備上一顆 SATA 硬碟的採購價格，便會比 x86 伺服器上的 SAS 硬碟價格來得昂貴。那麼，有沒有可能將一群 x86 伺服器上的本地儲存空間串連起來，變成一個共享的儲存空間，打造出相對於傳統儲存設備較便宜的儲存資源呢？
本文便要討論，由 VMware 所發展的「軟體定義儲存（Software-Defined Storage，SDS）」技術，也就是「VSAN（Virtual SAN）」。簡單來說 VSAN 的運作架構，便是將一群 x86 伺服器上的一般機械式硬碟串連起來變成一個共享的儲存空間，同時透過 SSD 固態硬碟的快速存取特性，來提升 VSAN 整體運作環境的資料 I/O 效能。
圖 1、VSAN 運作架構示意圖
此外，VSAN 除了可將 x86 伺服器本地儲存資源串連起來之外，也具備如同傳統儲存設備的擴充特色。它支援「垂直擴充（Scale-Up）」的運作機制，每台 ESXi 主機最多可以配置 5 顆 SSD 固態硬碟，以及 35 顆機械式硬碟（SAS/NL-SAS/SATA），也就是建立「最多 5 組」的磁碟群組（每組 1 顆 SSD 固態硬碟加 7 顆機械式硬碟）。
圖 2、VSAN Scale-Up 架構運作示意圖
VSAN 運作架構，也支援「水平擴充（Scale-Out）」機制，除了最初組成的 VSAN Cluster 必須至少 3 台 ESXi 主機之外，後續只要運算或儲存空間不足時可以逐台擴充，最多可擴充至 32 台主機。
圖 3、VSAN Scale-Out 架構運作示意圖
2、VMware VSA 與 VSAN 有何不同？
Q： VSAN 與 VMware VSA（Virtual Storage Appliance）有哪些不同之處？ 我該選擇哪一種方式來建立虛擬化共享儲存環境？
A : 首先，VSA 它是以「VM 虛擬主機（VA，Virtual Appliance）」的方式運作在 ESXi 虛擬化平台上，而 VSAN 則是直接整合在「Hypervisor（vSphere ESXi）」當中，相較之下不管是運算或儲存的 I/O 開銷來說，VSAN 所表現出來的整體執行效率比較亮眼。此外，在運作架構規模方面也有所不同，VSA 運作規模最少 2 台 ESXi 主機，最多只能 3 台 ESXi 主機。而 VSAN 運作規模最少 3 台 ESXi 主機，最多可達 32 台 ESXi 主機。
圖 4、VSAN 架構運作示意圖
3、如何挑選建置 VSAN 環境的 x86 伺服器？
Q： 我有興趣建置 VSAN 環境，可不可以用資料中心內現有的 x86 伺服器？ 如果需要重新採購 x86 伺服器的話，該如何選擇相關零組件如 SSD 固態硬碟、RAID Card...等？
A : 目前，你可以有「三種」方式來選擇要建立 VSAN 環境的 x86 伺服器，第一種方式是自行參考 VMware VSAN 的硬體相容性清單，然後選擇通過相容性驗證的硬體，這種方式適合 IT 管理人員可以將資料中心內現有的 x86 伺服器，對照 VSAN 硬體相容性清單內容後，增加或更換某些零組件即可。
圖 5、VMware VSAN 硬體相容性清單
自行選擇相關伺服器零組件時，值得注意的地方有二個小部份，首先是「SSD 固態硬碟」的選擇方面，有許多 IT 管理人員第一個會疑惑的地方是，一般市面上常見的 MLC（Multi Level Cell） / TLC（Triple Level Cell） SSD 固態硬碟，是否能夠用於 VSAN 運作環境？
若你只是想要測試 VSAN 運作機制的話是可以的，但是若要用於正式營運環境則非常不建議，主要的原因在於 VSAN 運作環境中，所有的資料 I/O 動作都必須先經過 SSD 固態硬碟處理，所以效能不好的 SSD 固態硬碟會連帶影響 VSAN 運作效率，再來是非企業等級的 SSD 固態硬碟，通常無法承受長時間龐大的資料 I/O 工作負載。所以，將 VSAN 用於營運環境的 SSD 固態硬碟，建議採用至少具備 20,000 IOPS 等級的 MLC 或 SLC SSD 固態硬碟。
第二個值得注意的地方是「RAID Card」，許多 IT 管理人員第一個疑惑是，能否使用 x86 伺服器上內建的 RAID Controller？ 目前的 VSAN 為 1.0 版本，在 VMware 的官方測試結果當中，採用 x86 伺服器內建的 RAID Controller，除了會發生效能低落的情況之外，還有可能會造成資料遺失或損壞的情況發生。
此外，在挑選時必須選擇支援 Pass-Through Mode（或稱 JBOD、HBA Mode），或者是 RAID-0 Mode 的 RAID Card；當挑選的是支援 RAID-0 Mode 時，假若採用的 x86 伺服器安裝了 8 顆硬碟，則必須針對「每一顆」硬碟建立 RAID-0，而非 8 顆硬碟一起建立 RAID-0，因為 VSAN 主要功能之一便是掌管所有資料 I/O 行為，而非底層建立好 RAID 之後才給 VSAN 使用，這部份必須特別注意。
那麼，採用 Pass-Through Mode 或 RAID-0 Mode 運作 VSAN 時，哪一種模式的執行效能會比較好呢？ 經過 VMware 官方測試的結果顯示，二種運作模式下的執行效能幾乎相差無幾。
第二、第三種挑選硬體的方式，便是採用相關硬體廠商所整合完成的硬體架構。你可以選擇通過 Virtual SAN Ready Node 認證的 x86 伺服器後，自行安裝 vSphere ESXi 並建立 VSAN Cluster 運作環境；或者採用已經將 VSAN 運作環境，預先安裝並載入完成的「超融合基礎架構（Hyper-Converged Infrastructure）」，也就是通過 EVO RAIL 認證的硬體設備即可。
4、如何規劃及估算 VSAN 的儲存空間？
Q： 我已經知道 VSAN 是將 x86 伺服器的本地儲存空間，全部串連起來變成一個儲存資源池的概念，那麼我該如何規劃及估算屆時所建立的 VSAN 儲存空間？
A : VMware 官方在 2014 年 8 月時，正式發佈了一個 VSAN 資源線上估算的網站（Virtual SAN Sizing Tool），方便您將屆時規劃在 VSAN 上的運作環境進行線上估算。當您連上該網站之後，您會看到網頁左邊有二個估算區塊分別是「VM 虛擬主機（Virtual Machine）」、「ESXi 主機（Host Hardware）」，顧名思義在 VM 虛擬主機的區塊部份，請填入屆時運作在 VSAN 環境中，VM 虛擬主機所會使用到的運算及儲存資源部份，而 ESXi 主機區塊則是填入 x86 伺服器的硬體資源。
在 Virtual Machine Characteristics 區塊中，相關欄位的說明及範例說明如下：
- Number of VMs： VM 虛擬主機數量，在屆時的 VSAN 環境中預計運作幾台 VM 虛擬主機，此實作設定為 100 台 VMs。
- Size of VMDK（GB）： 虛擬磁碟大小，屆時每台 VM 虛擬主機的虛擬磁碟空間大小（單位為 GB），此實作設定為 50GB。
- Number of VMDKs per VM： 虛擬磁碟數量，屆時每台 VM 虛擬主機的虛擬磁碟數量，此實作設定每台 VM 虛擬主機擁有 1 顆 VMDK 虛擬磁碟。
- Number of snapshots per VM： 快照數量，屆時每台 VM 虛擬主機的快照數量，此實作設定每台VM虛擬主機建立 1 份快照。
- VM Memory size （GB）： 虛擬記憶體空間，屆時每台 VM 虛擬主機的虛擬記憶體空間大小（單位為 GB），此實作設定每台 VM 虛擬主機擁有 4GB 記憶體。
- Number of failures to tolerate： 容許的故障次數，在屆時的 VSAN 環境中所套用的儲存原則設定數值，此實作設定屆時將建立 FTT=1 的 VSAN 儲存原則，並套用至所屬的相關 VM 虛擬主機。
- Number of disk stripes per object： 條帶數量，在屆時的 VSAN 環境中所套用的儲存原則設定數值，此實作設定屆時將建立 Stripe=1 的 VSAN 儲存原則，並套用至所屬的相關 VM 虛擬主機。
圖 6、VSAN 資源線上估算，VM 虛擬主機區塊
在 Host Hardware Characteristics 區塊中，相關欄位的說明及範例說明如下：
- HDD Size： 硬碟空間，屆時 VSAN 運作環境中，每台 ESXi 主機所採用的機械式硬碟（SAS/NL-SAS/SATA）空間，下拉式選單中容量可選擇 300GB ~ 6TB，此實作選擇採用 SAS 600GB。
- Extra Usable Storage Capacity： 額外使用儲存空間，屆時 VSAN 所建立的儲存空間，預估會隨著時間日益增加的儲存空間百分比，此實作設定為 50%（預設值為 30%）。
- Magnetic Disks per Disk Groups： 機械式硬碟數量，每一組磁碟群組當中的機械式硬碟數量，此實作設定為一組磁碟群組當中，擁有 7 顆 SAS 介面的機械式硬碟。
- Disk Groups per Host： 磁碟群組數量，每台 x86 伺服器主機的磁碟群組數量，此實作設定的情境採用 2U 高度的 x86 伺服器，可以擁有 16 顆硬碟（或更多），因此設定每台主機 2 組磁碟群組。
- System Memory （in GB）： 實體記憶體空間，每台 x86 伺服器主機所配置的實體記憶體空間（單位為 GB），此實作設定每台 x86 伺服器擁有 256GB 記憶體空間。
- Number of cores per host： 核心數量，每台 x86 伺服器主機所配置的 CPU 處理器所擁有的核心數，此實作採目前市面上主流規格，也就是每顆 CPU 處理器擁有 8 核心。
- Maximum VMs/core： 每顆核心服務多少台 VM，屆時的 VSAN 運作環境運算資源，每顆處理器核心最多服務多少台 VM 虛擬主機，此實作設定每顆處理器核心最多服務 4 台 VM 虛擬主機。
圖 7、SAN 資源線上估算，ESXi 主機運算及儲存資源
當您在 VSAN 線上估算網站中，填妥相關的估算數據之後，在網站的右方便會立即估算出相關的建議值。首先，我們點選「Virtual SAN Cluster Planner」頁籤，在此頁籤中將立即估算出相關數據，以此次實作的情境來說，預估運作 100 台 VM 虛擬主機，以及每台 ESXi Host 所擁有的運算及儲存資源後，估算出屆時的 VSAN 運作環境只要至少四台 x86 伺服器便可建立，而 SSD 固態硬碟的空間建議採用至少 210GB...等資訊。
圖 8、填入 VSAN 相關預估數據後，立即線上估算出所需資源數值
切換至「Virtual SAN Storage & Memory Usage」頁籤後，可以看到在屆時所建立的 VSAN 運作環境中，儲存資源的耗用情況例如 可用空間、複本空間...等，以及運作資源的耗用情況例如 Virtual SAN 所佔用的記憶體空間（因為 Virtual SAN 是整合至 vSphere ESXi 5.5 update1 當中）。
圖 9、預估屆時 VSAN 運作環境儲存及運算資源的耗用情況
5、建置 VSAN 環境時，SSD 無法被正確辨別？
Q： x86 伺服器安裝了 SSD 固態硬碟，但是安裝好 ESXi 5.5 update1 之後，因為 SSD 固態硬碟無法被正確辨識，所以無法建立磁碟群組，導致無法建立 VSAN Cluster？
A : 在建立 VSAN 運作環境的過程中，如果挑選的 SSD 固態硬碟不在硬體相容清單內，或者 x86 伺服器所採用的 RAID Card 僅支援 RAID-0 Mode 時，就有可能發生 SSD 固態硬碟無法被辨識的情況。此次的實作環境當中，採用的 x86 伺服器所安裝的二顆 120GB SSD 固態硬碟，就因為不在硬體相容清單內而無法被正確辨識，所以登入 vSphere Client 管理視窗中，在 Drive Type 欄位可以看到顯示為「Non-SSD」。
圖 10、SSD 固態硬碟無法被正確辨識
當 SSD 固態硬碟無法被正確辨識時，除了無法建立 VSAN 磁碟群組及 VSAN Cluster 之外，若要用於其它用途也不建議（例如，Swap to Host Cache），主因是 ESXi（Hypervisor）針對 SSD 固態硬碟與機械式硬碟，有著不同的延遲時間控制及資料 I/O 行為（詳請參考 VMware KB 1008205），因此即使不是建置 VSAN 環境，用於其它需求也應該讓 SSD 固態硬碟能被正確辨識才對。
整個操作的流程為先把 ESXi 主機開啟 SSH 服務（詳請參考 VMware KB 2013188），接著登入後以「esxcli storage core device list」指令，加上「--device=」參數及 SSD 固態硬碟的Device ID（例如，naa.600605b005e398101bd9e0518914260a）。指令執行後應該可以看到其中有一欄為「Is SSD :false」，表示該 SSD 固態硬碟無法被正確辨識。
~ # esxcli storage core device list --device=naa.600605b005e398101bd9e0518914260a
naa.600605b005e398101bd9e0518914260a
Display Name: Local IBM Disk(naa.600605b005e398101bd9e0518914260a)
Has Settable Display Name: true
Size: 113487
...略...
Is Removable: false
Is SSD: false
Is Offline: false
...略...
No of outstanding IOs with competing worlds: 32接著，執行指令「esxcli storage nmp satp rule add --satp VMW_SATP_LOCAL --device」加上 SSD 固態硬碟的 Device ID，指令結尾加上「--options=enable_ssd」告知 Hypervisor 此顆硬碟為 SSD 固態硬碟，最後再執行「esxcli storage core claiming reclaim -d」重新宣告硬碟的動作即可，再次執行上述查詢指令後，便會發現該欄位變更為「Is SSD :true」。
此時，再次切換回 vSphere Client 管理畫面，在 Drive Type 欄位可以看到顯示為「SSD」，表示 SSD 固態硬碟已經被正確辨識。
圖 11、SSD 固態硬碟正確被辨識
6、建置的 VSAN 環境運作效能極差？
Q： 已經按照硬體相容性清單，挑選適合的 SSD 固態硬碟以及 RAID Card，但是建立好的 VSAN 運作效率並不如預期？
A : 雖然您依照硬體相容性清單，挑選通過驗證的 SSD 固態硬碟及 RAID Card，但其實在挑選建立 VSAN 環境的 RAID Card 時，有一個數值必須特別注意就是「佇列深度（Queue Depth）」。為何這個數據如此重要並影響效能？ 在說明之前，我們先來看看，從 x86 伺服器底層、硬碟、Hypervisor、到 VM 虛擬主機，資料 I/O 必須要經過多少個佇列關卡。
圖 12、實體伺服器至 VM 虛擬主機之間，資料 I/O 所要經過的佇列關卡
你可以為 ESXi 主機開啟 SSH 服務後，登入主機鍵入「vmkload_mod –s mpt2sas」指令，查看目前所使用的硬碟驅動資訊，你可以知道預設情況下 SATA 硬碟的佇列深度為 32，而 SAS 硬碟佇列深度則為 254。
~# vmkload_mod -s mpt2sas
vmkload_mod module information
input file: /usr/lib/vmware/vmkmod/mpt2sas
Version: Version 10.00.00.00.5vmw, Build: 799733, Interface: 9.2 Built on: Aug 1 2012
...略...
mpt2sas_raid_queue_depth: int
Max RAID Device Queue Depth (default = 128)
mpt2sas_sata_queue_depth: int
Max SATA Device Queue Depth (default = 32)
mpt2sas_sas_queue_depth: int
Max SAS Device Queue Depth (default = 254)
...略...所以，你可以想像得到的是，假設採用的 RAID Card 是 Intel RMS25JB040 其佇列深度為「256」，當一台 x86 伺服器採用 8 顆 SATA硬碟時，此片 RAID Card 可能還迎刃有餘。但是，如果 x86 伺服器採用 8 顆 SAS 硬碟時，那麼可以想見的是處理資料 I/O 時，整體運作效能的瓶頸將會卡在 RAID Card 上。
所以，在上述的運作情境中，如果將 RAID Card 更換為 Intel RMS25CB040，其佇列深度為「975」的情況下，那麼即使 x86 伺服器採用 8 顆 SAS 硬碟時，也不會發生資料 I/O 傳輸瓶頸的問題。
圖 13、RAID Card 佇列深度值必須夠大，才能有效讓資料 I/O 管道暢通
選擇正確的 RAID Card 之後，在實作環境中該如何確認 RAID Card 及硬碟的佇列深度？ 同樣的，你可以為 ESXi 主機啟動 SSH 服務，登入後輸入「esxtop」指令，然後依序按下「d > f > d」鍵選擇 Queue Stats 項目，在顯示結果當中的「AQLEN」欄位值，便是 RAID Card 的佇列深度。
圖 14、手動查詢 RAID Card 的佇列深度值
同樣的，為 ESXi 主機啟動 SSH 服務，登入後輸入「esxtop」指令然後按下「u」鍵，在顯示結果當中的「DQLEN」欄位值，便是硬碟的佇列深度（詳請參考 VMware KB 1027901、KB 1267）。
圖 15、手動查詢硬碟的佇列深度值
7、VSAN 環境，ESXi 應該裝在 SD/USB 或硬碟內？
Q： 預計建立 VSAN 運作環境，應該要將 ESXi 5.5 update1 安裝在 SD Card 或 USB Flash 當中，或者是直接安裝在硬碟內，哪一種方式比較好？
A : 原則上，在您準備建立 VSAN 運作環境的 x86 伺服器中，你應該將 ESXi 安裝在 SD Card 或 USB Flash 當中（4GB ~ 16GB即可）。不建議將 ESXi 安裝在硬碟的原因是，當該顆硬碟安裝 ESXi 並啟用 VSAN 功能後，該顆硬碟的其餘空間是「無法使用」的，舉例來說，如果使用一顆 SAS 600GB 的硬碟安裝 ESXi 並啟用 VSAN 功能後，那麼餘下的空間完全無法使用（等於浪費 590GB 以上的儲存空間）。
不過有個限制必須要注意，當 x86 伺服器所安裝的實體記憶體空間，如果「小於 512GB」的話，那麼可以將 ESXi 安裝在 SD Card 或 USB Flash 當中。但是，如果 x86 伺服器的實體記憶體空間「大於 512GB」時，那麼「只能」將 ESXi 安裝在硬碟當中，畢竟現在主流的 x86 伺服器實體記憶體空間，都可以達到 TB 等級，所以這個限制條件值得注意。
8、將 ESXi 安裝在 USB 當中，卻發生系統日誌為暫存？
Q： 聽從建議將 ESXi 安裝在 SD Card 或 USB 當中，但是卻發生 System Log 無法儲存的錯誤訊息？
A : 事實上，安裝 ESXi 的方式共有三種分別是 Installable、Embedded、PXE，其中 Installable 的安裝方式，便是大家所熟悉的方式也就是下載 ISO 映像檔後進行安裝，而 PXE 的方式則是配合 Auto Deploy 機制自動佈建，最後的 Embedded 安裝方式，通常為伺服器硬體廠商將硬體驅動進行最佳化之後的 ESXi 版本（詳請參考 VMware KB 2014558）。當您將 ESXi 安裝在 SD Card 或 USB Flash 當中時，其實 ESXi 便如同運作在 Embedded 的模式了。因此，當您將 ESXi 安裝在 SD Card 或 USB Flash 之後，透過 vSphere Client 或 vSphere Web Client 登入管理介面時，便會發現系統提示說 ESXi 主機的「系統日誌（System Log）」，目前儲存在非持續性的儲存資源警告訊息 （系統日誌將會存放在暫存區，只要 ESXi 主機重開機日誌便會清空）。
圖 16、管理介面出現系統提示，表示系統日誌儲存在非持續性的儲存資源警告訊息
此時，你只要在其它 Datastore 儲存資源中，建立存放 ESXi 系統日誌的資料夾，並將 ESXi 的系統日誌存放路徑指定至該資料夾即可。舉例來說，ESXi 主機掛載了 NFS 儲存資源，在其中建立了 ESXi 儲存系統日誌的資料夾「esxi1-logs」，之後以 vSphere Client 登入管理介面後，依序點選「Configuration > Advanced Settings > Syslog > global」項目，接著在右邊視窗中「Syslog.global.logDir」區塊，將剛才在 NFS 建立的資料夾路徑填入此例為「[NFS]esxi1-logs」，確認無誤後按下 OK 鈕即可（詳請參考 VMware KB 2032823、KB 1033696）。
圖 17、指定 Embedded Mode 的 ESXi 主機，將系統日誌存放至其它 Datastore
完成設定回到 vSphere Client 管理介面後，可以發現警告訊息已經消失，並且查看剛才在 NFS Datastore 中所建立的資料夾內容，可以看到 ESXi 主機已經將相關的系統日誌儲存於此路徑當中。
圖 18、ESXi 主機已經將相關的系統日誌儲存於指定的儲存路徑
9、結語
事實上，目前的 VSAN 為正式發行的 1.0 版本，讀者或許會覺得似乎有許多相關的限制必須特別注意。相信之後的 VSAN 2.0 版本（目前為 VSAN 2.0 Beta）會放寬許多限制，舉例來說，在 VSAN 2.0 中可能會放寬可以使用 TLC SSD 固態硬碟...等。希望透過本文的討論讓讀者了解到，當您計劃導入及部署 VMware VSAN 運作環境時，在調整現有的 x86 伺服器，或者準備採購新的 x86 伺服器時，應該要特別注意 SSD 固態硬碟及 RAID Card 的部份，以免屆時所架設的 VSAN Cluster 運作效能不如預期。