設計工具
儲存裝置

VMware vSAN 及 NVMe 命名空間魔法

Collin Murphy | 2019 年 9 月

VMware vSAN + NVMe 命名空間魔法:將 1 個 SSD 拆分成 24 個裝置,以獲得出色的儲存裝置效能

免責聲明:VMware 目前不支援這項經測試的技術,未來可能亦不會支援此項技術。不建議在任何生產環境中使用此方法,尤其是在需要 VMware 支援的情況下。

NVMe™ 正成為主流,業內許多公司都在推動採用該技術作為更高的效能標準,其中包括適用於 vSAN™ 的 VMware。NVMe 協定專為固態硬碟(SSD)而打造,與傳統 SAS/SATA 儲存裝置相比具有眾多效能優勢,其中延遲改善可能是最重要的一項優勢。PCIe 介面上的 NVMe 協定繞過了SAS/SATA 協定的大部分堆棧負荷,因此能夠提供更低的延遲、更多的 IOPS 和更高的輸送量,同時也減少 CPU 時鐘週期、功耗、熱量輸出等。

介紹鮮為人知的 NVMe 命名空間

NVMe 協定的一個不太廣為人知的功能是命名空間。藉助命名空間,可以將 SSD 分割為邏輯上獨立的較小硬碟,例如分割區。但與分割區不同的是,每個命名空間都有自己的提交和完成佇列,允許高度並行的操作。所有 NVMe 硬碟都利用命名空間,但大多數硬碟僅支援單一命名空間,並且預先配置了佔用整個硬碟容量的主命名空間。藉助美光® 9300 MAX NVMe SSD,您可以配置多達 32 個任意大小的獨立命名空間。

由於美光 9300 硬碟提供的最小容量為 3.84TB,考慮到僅會使用 600GB,我意識到將整個 9300 NVMe SSD 用於 vSAN 快取裝置是沒有意義的。然後我產生了一個瘋狂的想法,使用命名空間將 SSD 分成更小的邏輯硬碟,並將每個硬碟作為單獨的儲存裝置提供予 VMware ESXi 管理程式。

「你為什麼這麼做?」 擴充效能!

想像一下小型 ROBO 配置,使用最少的伺服器和很少的磁碟插槽。使用傳統 vSAN 配置時,您需要多個硬碟來擴充效能,因為 vSAN 會為每個額外的磁碟組新增額外的執行緒。如果您僅限於幾個插槽,那麼您基本上只能使用單一磁碟組,這會限制您的效能(以及容量),因為必須為快取磁碟保留一個插槽。美光 9300 SSD 在單一 U.2 硬碟中的容量高達 15.36TB,可實現非常高的密度,並且在命名空間的加持下還具有非常高的效能。另一個用例是使用最少伺服器的邊緣運算。其甚至可以在 vSAN 之外使用,例如作為 RDM 傳遞到多個 VM 的暫存磁碟。

在準備此示範版本時,我使用 HCIBench 在利用美光 9300 命名空間的 2 節點配置中執行了若干測試。我使用了兩台 Dell R730xd 伺服器,每台伺服器均配備雙 Intel Xeon 2690v4 處理器、256GB RAM、單一美光 9300 SSD 和雙 25GbE NIC。目的是瞭解 vSAN 效能如何隨磁碟組數量、每個磁碟組的容量硬碟、儲存裝置設定檔等的變化而變化。為確保比較結果公平,我對每個測試使用相同的 HCIBench 配置,其中每個節點有 4 個 VM,每個 VM 有8 個VMDK(每個 100GB),每個 VMDK 有 4 個執行緒,總共有 128 個未完成的 IO。該研究的最大收穫是,增加磁碟組的數量可以顯著提高效能,三個磁碟組的讀取效能幾乎是單一磁碟組的三倍。讀取及寫入擴展如下所示。這些數字是在 vSAN 預設儲存策略以及停用重複資料刪除和壓縮的情況下報告的。

磁碟組擴展寫入測試

 

 

三磁碟組的效能幾乎是單磁碟組的 3 倍

如上圖所示,讀取和寫入效能均隨磁碟組的變化而變化。超過三個磁碟組的回報可以忽略不計,因此我堅持使用三個磁碟組。我注意到讀取效能比寫入效能更好。請注意,寫入測試運行的時間足夠長,以致進入嚴重的降級狀態,因此效能較低。如果這是一項資料集 100% 適合快取層的測試,則數字會更高。

在 1 台演示伺服器上建立 4 個 vSAN 節點

在這項研究的基礎上,我想在 VMworld'19 上展示此功能,但不想僅僅為了我的演示而運送兩台大型伺服器。作為替代,我使用了 2U 4 節點 Supermicro Big Twin(SYS-2029BT-HNC0R),並決定製作完整的 4 節點 vSAN 叢集作為示範。四個節點均配備雙 Intel Xeon Gold 6142 處理器和 384GB RAM。每個節點都有 6 個磁碟插槽,其中 4 個支援 NVMe,但我只需要一個。我將 15.36TB 美光 9300 MAX 放入每個節點,安裝最新的 ESXi 6.7U3 影像(內部版本 14320388),將它們連接到 vSphere Center Server Appliance(6.7U3 內部版本 6.7.0.40000),並將每個磁碟拆分為 24 個獨立的命名空間——三個用於快取磁碟的 600GB 命名空間和 21 個用於容量磁碟的 594GB 命名空間。配置如下所示。

NVMe3

將 4 節點 vSAN 叢集配置到 24 個命名空間

幸運的是,由於這是標準 NVMe 功能,所以我不需要任何特殊工具來配置命名空間——我只需使用內建的「esxcli nvme」命令來建立它們。下面的命令顯示如何建立命名空間並將其附加到控制器。

建立:

「esxcli nvme 裝置命名空間建立 -A vmhba3 -c 1258291200 -p 0 -f 0 -m 0 -s 1258291200」

連結:

「esxcli nvme 裝置命名空間連結 -A vmhba3 -c 1 -n 1」

建立命名空間後,它們將作為單獨的儲存裝置(而非分割區)顯示在 vSphere 主機中。據主機所知,命名空間都是獨立的實體儲存裝置。實際上,我是在欺騙 vSAN,讓它誤以為我提供了多個實體磁碟機,而我知道我實際上只使用了一個實體磁碟機。

當您的磁碟機是瓶頸時,這根本沒有用處,但是當您使用能夠提供 850K IOPS 和 3.5+GB/s 輸送量的磁碟機時,將其拆分為更小的邏輯硬碟有助於 vSAN(或您使用的任何應用程式)透過增加並行化來擴展效能。有關美光 9300 高性能 SSD 之功能的更多信息,請瀏覽產品頁面

為了創建示範版本,我決定使用比 HCIBench 更靈活、可配置的解決方案來產生負載。相反,我建立了自己的 VM,以便完全控制它們。每個主機有兩個 VM,每個 VM 有 8 個 VMDK。事實證明,這是在所有命名空間上分佈足夠執行緒的最佳 VM 數量,同時透過最大限度地減少數量來簡化管理。我使用 CentOS 7.6 作為作業系統,並為每個系統提供 8 個 vCPU 和 8GB vRAM 以及一個網路介面。每個 VM 都將 8 個 VMDK 作為常規硬碟(而非 NVMe 控制器)安裝,測試顯示兩個選項都沒有顯著的效能差異。我再次使用停用重複資料刪除和壓縮的 vSAN 預設儲存策略。

我建立了一個單獨的 VM 來運行 Windows Server 2019,在其中使用 Iometer 工具針對主機產生負載。Iometer 工作執行緒被分配給每台主機上的每個 VMDK,分別具有 16 個和 1 個執行緒(未完成的 IO),用於 4K 隨機和 128K 順序工作負載。最佳執行緒數量是透過簡單試驗和錯誤確定的。目標是最大化 4K 隨機讀取的 IOPS 和最大化 128K 序列讀取的輸送量(GB/s),同時保持每次讀取的合理延遲。在某個時間點,您的效能將不再增加,但您的延遲會增加,此時我會停止添加執行緒。

獲勝者是……效能!

技術討論已經夠多了——讓我們來談談效能。在您瞭解 NVMe、命名空間和美光 9300 SSD 之前,如果我告訴您,您可以使用單一磁碟機獲得驚人的效能,您可能會認為我瘋了。然而,透過這個解決方案,與大多數使用 20 多個實體磁碟機的解決方案相比,我能夠從單一磁碟機獲得更高的效能……外形尺寸小得多……密度更高……並且功耗更低……產生更少的熱量……降低您的 TCO……

透過此配置,我能夠實現750K IOPS(4k 隨機讀取)和超過 11.5GB/s(128K 序列讀取)!事實上,輸送量是如此之高,以至於我必須在解決方案中添加第三個 NIC,以便 vSAN 可以擁有兩個專用 NIC。每個節點的平均速度超過 21Gbps,某些節點有時會超過 25Gbps。這意味著我所獲得的效能甚至比雙 10GbE NIC 的效能還要高,即使您將它們都提供給 vSAN,並且沒有為 vMotion、管理或其他網路功能進行保留。

牆上的大圖顯示了讀取 iops 和讀取輸送量的兩個圖表

VMworld’19 上的美光 NVMe 命名空間演示

由於演示是在 VMworld 的 Solutions Exchange 中即時運行(而不是在溫控實驗室環境中),因此噪音是一個問題。我將功耗設定降低為「節能」,這略微降低了效能,但四天內仍保持 550K+ IOPS。這是一項直接 4K 隨機讀取測試,因此輸送量僅為 2GB/s。如果我將區塊大小切換為 128K,您會看到輸送量躍升至約 8GB/s,IOPS 減少至約 62K IOPS。

請注意,每個節點運行兩個 VM,因此每個指標報告了八個單獨的數字。除了八個負載 VM 之外,我還運行一個帶有 Kibana 的三節點 Elasticsearch 叢集(使用每個 VM 上運行的 Metricbeat 來收集主機指標)、vCenter Server Appliance 以及用於管理的 Windows 伺服器。即使該叢集中運行著總共 14 個 VM ,這些磁碟機也可以毫不費力地提供這種效能。

該演示在 VMworld 上引起了極大關注。我每天都會就這種配置進行幾次演示,甚至受邀與 Virtually Speaking(@virtspeaking)的人員一起參加 podcast,討論 vSAN、全快閃、命名空間、網路、耐用性、成本、TCO 的未來等等。

兩位男士發表評論

我(右)在與 Virtually Speaking 的人員交談

我們計劃進一步測試這一點並為其提出更多用例。美光和 VMware 目前正進行洽談,我們希望在不久的將來看到其成為受支援的配置。別忘了,美光儲存裝置專家早在 VMworld 2014 上便已向觀眾展示過全快閃 vSAN 叢集,並引發大量關注,當時這項技術尚未廣為人知。當時人們也認為我們瘋了! 😉

在 Twitter 上關注我們 @MicronTechnology,並在 LinkedIn 上與我們聯絡,隨時掌握美光最新資訊。