Windows 在很多方面都很棒，它成為世界第一的操作系統是有原因的。 也就是說，它並不完美，尤其是在採用新的存儲標準時。 因此，有進取心的公司有巨大的機會為 Windows 商店開發解決方案。 隨著 NVMe SSD 繼續主導企業，成為 SSD 服務器存儲的標準，能夠共享該存儲的需求也在增加。 可悲的是，在 Windows 中，這是一個問題，直到最近。 今年早些時候，StarWind 將適用於 Windows 的 NVMe-oF Initiator 商業化。
Windows 在很多方面都很棒，它成為世界第一的操作系統是有原因的。 也就是說，它並不完美，尤其是在採用新的存儲標準時。 因此，有進取心的公司有巨大的機會為 Windows 商店開發解決方案。 隨著 NVMe SSD 繼續主導企業，成為 SSD 服務器存儲的標準，能夠共享該存儲的需求也在增加。 可悲的是，在 Windows 中，這是一個問題，直到最近。 今年早些時候，StarWind 將適用於 Windows 的 NVMe-oF Initiator 商業化。
在商業化之前，StarWind 一直在提供適用於 Windows 的 NVMe-oF Initiator 作為開發和 PoC 用例的免費工具。 他們仍然 提供免費版本 對於那些想玩的人，但我們今天要看的是 GA 發布版本。 事實上，如果您正在查看適用於 Windows 的任何 NVMe-oF Initiator，您可能正在使用 StarWind IP。 他們為需要擴展其產品的各種合作夥伴提供 OEM 解決方案。
適用於 Windows 配置的 NVMe-oF 啟動器
適用於 Windows 的 StarWind NVMe-oF Initiator 可以在任何 Windows 主機上輕鬆安裝。 不需要專門的硬件或額外的 Windows 組件。 該軟件已通過 Windows 認證（Server 2019 和 Windows 10），並通過了與主要 NVMe-oF 存儲供應商的兼容性測試。 在我們的場景中，我們有一個非常簡單的配置，即一個存儲主機和四個客戶端。
四個客戶中的每一個都是 戴爾PowerEdge R740 服務器。 他們每個人都運行兩個 6130GHz 的 Intel Xeon Gold 2.1 CPU 和 256GB 的 DRAM。 對於連接，我們使用 NVIDIA ConnectX-5 EN 100GbE NIC (MCX516A-CCAT)。 服務器安裝了 Windows Server 2019 Standard Edition，利用 StarWind NVMe-oF Initiator for Windows 1.9.0.455 版。 對於 Linux 測試，我們使用了 CentOS 8.4.2105（內核 – 4.18.0-305.10.2）和 nvme-cli 1.12。 服務器直接連接到存儲主機。
存儲主機是一台 Intel OEM 服務器 (M50CYP2SB2U)，配備兩個 8380 GHz 的 Intel Xeon 2.3 CPU 和 512GB DRAM。 我們再次使用了 NVIDIA ConnectX-5 EN 100GbE NIC (MCX516A-CDAT)，這次我們在主機中使用了四個。 在這種情況下，我們使用 CentOS 8.4.2105（內核 – 5.13.7-1.el8.elrepo）和 SPDK v21.07。
在主機中，我們使用八個 英特爾P5510 第 4 代 NVMe 固態硬盤。 SSD 分為兩批，每批四塊，以便與 CPU 進行 NUMA 對齊。 它們在 RAID0 中配置以獲得最佳性能。
用於 Windows 性能的 NVMe-oF 啟動器
對於此測試，我們利用 Linux 和 Windows 啟動器通過 FIO 運行了以下基準測試。
- 隨機讀取 4K – 16 個線程，32 個隊列深度
- 隨機寫入 4K – 8 個線程，4 個隊列深度
- 隨機讀取 64K – 4 個線程，32 個隊列深度
- 隨機寫入 64K – 4 個線程，1 個隊列深度
- 順序讀取 1M – 2 個線程，8 個隊列深度
- 順序寫入 1M – 1 個線程，8 個隊列深度
單次測試持續時間為 3600 秒（1 小時）。 在對寫入操作進行基準測試之前，存儲已先預熱 3600 秒（1 小時）。 所有測試均進行了三次，取平均值作為最終結果。
在我們研究 4 個客戶端的 Linux NVMeoF 啟動器性能的第一組中，我們在 5.54K 隨機讀取中以 21.6 毫秒的延遲在 0.369GB/s 的帶寬下測量了 4M IOPS。 4K 隨機寫入性能在 1.58GB/s 的帶寬下測得 6.2M IOPS，延遲為 0.08ms。
轉向大塊傳輸，我們測量了 64K 隨機，最後是 1M 順序測試，重點關注整個結構的帶寬。 在 64K 隨機讀取中，我們在 46.6 毫秒的延遲下測得 0.69GB/s，在 7.2ms 的寫入延遲下測得 0.14GB/s。 1M 順序讀取速度為 42.9GB/s，延遲為 1.48ms，寫入速度為 25.4GB/s，延遲為 1.26ms。
接下來，我們切換到 Windows，我們在相同的四個客戶端上利用了 StarWind NVMeoF 發起程序。 在這裡，我們在 4.17K 隨機讀取時測得 4 萬次 IOPS，或在 16.3 毫秒延遲時測得 0.35GB/秒。 4K 隨機寫入速度為 1.54M IOPS 或 6GB/s，延遲為 0.07ms。
然後，我們轉移到具有相同隨機訪問配置文件的更大的 64K 傳輸大小。 在這裡，我們在 46.6 毫秒的延遲下測量了 0.68GB/s 的讀取速度，在 7.2ms 的延遲下測量了 0.13GB/s 的寫入速度。 切換到我們最後一個具有順序訪問模式的 1M 傳輸大小的工作負載配置文件，我們測量到 42.9GB/s 的讀取速度為 1.38ms 延遲，25.2GB/s 的寫入速度為 1.14ms 延遲。
比較這些數字，除了 4K 隨機讀取外，Windows 和 Linux 的性能非常接近。 在所有其他測試中，性能差距小於 3%。 主要區別實際上歸結為流經 Windows 存儲堆棧時增加的 CPU 開銷。 這產生了 2.7 到 3.7 倍的差異，其中增加的 I/O 本身對 CPU 使用率的影響最大。
從 Linux 中的 16% 的 CPU 利用率上升到 Windows 中的 44% 是一個相當大的跳躍，但從 3.5% 到 9% 的跳躍不會達到相同的程度。 對於需要在 Windows 中運行的應用程序或通常更關注 Windows 的 IT 商店，StarWind 的主要目標是帶來他們顯然能夠實現的 NVMeoF 功能和性能。
結論
此分析的目的不是確定推出您自己的 NVMe-oF 解決方案的最佳方式或最快方式。 大多數存儲部署跟隨應用程序，而不是應用程序跟隨存儲。 也就是說，組織可能想要使用 Windows 的原因有很多。 可能是特定應用程序、現有基礎設施、成本原因或任何其他問題使 Windows 成為首選平台。 至少現在，借助 StarWind 的 NVMe-oF Initiator for Windows，我們可以選擇共享 NVMe SSD 並讓它們盡可能靠近應用程序系統。
暫時忽略客戶端操作系統，我們測試中的主要限制實際上歸結為系統之間的網絡鏈接。 在我們的案例中，利用 100Gb NIC，我們使網絡飽和，並在 Linux 和 Windows 環境中達到 46.6GB/s 的最高速度。 即使是 Windows 中的峰值 4K 隨機讀取測試也達到了 16.3GB/s，這可以計算出超過六個 25GbE 鏈接的隨機 I/O。 網絡最終在 NVMe-oF 中扮演更重要的角色，因為 NVMe 性能以任何方式切片都會吸收大量流量。
但歸根結底，我們的目標是評估 StarWind 啟動器的工作情況。 它真的很好用。 考慮替代方案是“沒有適合您的 NVMe-oF！” 在 Windows 中，我們很高興有任何選擇。 是的，該特權會影響 CPU，但即使從 Linux 到 Windows 的百分比增量很可怕，但在 4K 隨機讀取之外，感知到的影響是最小的。 如果您不確定這是否合適，StarWind 可讓您免費試用。 安裝如此簡單，有充分的理由試一試，看看 NVMe-oF 在 Windows 中對您的應用程序的工作效果如何。
參與 StorageReview
電子報 | YouTube | 播客 iTunes/Spotify | Instagram | Twitter | Facebook | RSS訂閱
