?通常情況下，我們需要為 Kubernetes 平臺找到一種易于使用、可靠的塊存儲。

因此，本文將對幾個開源存儲解決方案進行基準測試，以了解它們在各種條件下的性能。本次對比也是在不同硬件配置條件下對DRBD(https://en.wikipedia.org/wiki/Distributed_Replicated_Block_Device?) 進行測試以及與 Ceph (?https://ceph.io/en/?) 的測試結果比較。

然而，軟件定義存儲市場在不斷發展和演變。新的項目不斷的涌現，包括最近發布的 Mayastor (https://github.com/openebs/mayastor?) 和 Vitastor (https://vitastor.io/) 。本文也包含了這兩種新興存儲。?

測試環境

一、硬件

• 服務器：三臺AX61服務器。
• CPU：AMD Ryzen 9 3900 (24) @ 3.100GHz
• 內存：Micron 32GB DDR4-3200 ECC UDIMM 2Rx8 CL22 (four modules per server)
• 磁盤：SAMSUNG MZQLB1T9HAJR-00007 1.92 TB (two per server).
• 網絡：10G (Intel 82599ES); 1G (Intel I210)

二 、核心軟件

• 操作系統： Ubuntu 20.04.3 LTS（Focal Fossa）；
• 內核： 5.4.0-54-generic。

三、主要軟件版本

• DRBD：9.1.4 (linstor-server v1.17.0);
• Ceph：16.2.7 (rook v1.8.2);
• Mayastor：1.0.0；
• Vitastor：0.6.12 (kernel 5.13.0-27-generic);
• ZFS： 0.8.3；
• LVM：2.03.07

四、測試塊信息

• 虛擬卷大小：100G（在單個客戶端測試中）；10G（在多個客戶端的測試中）；
• DRBD 同步協議：C（完全同步），啟用 bitmap。

基準測試

基準測試分幾個步驟進行：

1. 測試“原始”NVMe 驅動器的性能；
2. 測試后端開銷（LVM vs LVMThin vs ZFS）；
3. 測試 DRBD 開銷；
4. 與其他集群文件系統比較；
5. 通過千兆網絡進行基準測試；
6. 壓力測試。

下面是本文提供的一些使用 fio 測試的命令：

fio -name=randwrite_fsync -ioengine=libaio -direct=1 -randrepeat=0 -rw=randwrite -bs=4k -numjobs=1 -iodepth=1 -fsync=1
fio -name=randwrite_jobs4 -ioengine=libaio -direct=1 -randrepeat=0 -rw=randwrite -bs=4k -numjobs=4 -iodepth=128 -group_reporting
fio -name=randwrite -ioengine=libaio -direct=1 -randrepeat=0 -rw=randwrite -bs=4k -numjobs=1 -iodepth=128
fio -name=write -ioengine=libaio -direct=1 -randrepeat=0 -rw=write -bs=4M -numjobs=1 -iodepth=16
fio -name=randread_fsync -ioengine=libaio -direct=1 -randrepeat=0 -rw=randread -bs=4k -numjobs=1 -iodepth=1 -fsync=1
fio -name=randread_jobs4 -ioengine=libaio -direct=1 -randrepeat=0 -rw=randread -bs=4k -numjobs=4 -iodepth=128 -group_reporting
fio -name=randread -ioengine=libaio -direct=1 -randrepeat=0 -rw=randread -bs=4k -numjobs=1 -iodepth=128
fio -name=read -ioengine=libaio -direct=1 -randrepeat=0 -rw=read -bs=4M -numjobs=1 -iodepth=16

針對上訴測試命令，這篇文章(??https://yourcmc.ru/wiki/Ceph_performance??) 也詳細介紹了下，簡述如下：

為什么在基準測試中這些命令？畢竟，有很多參數會影響磁盤性能，例如：

• 塊大小；
• 模式——讀、寫或各種混合讀/寫模式；
• 并行度——隊列深度和線程數，換句話說，并行 I/O 請求的數量；
• 測試時間；
• 初始磁盤狀態——空、線性填充、隨機填充和在特定時間段內隨機寫入；
• 數據分布——例如，10%的熱數據和90%的冷數據或熱數據位于某個地方（例如，在磁盤的開頭）；
• 其他混合測試模式，例如，同時使用不同塊大小的基準測試。

結果還可以以不同級別的詳細信息呈現 - 除了單純的平均操作數或每秒兆字節數之外，您還可以提供曲線圖、直方圖、百分位數等。這些都有助于了解當前測試情況。

基準測試也伴隨著一些問題。例如，一些服務器 SSD 廠商認為我們必須通過隨機覆蓋磁盤至少兩次來填充轉換表來進行預處理，然后再進行測試。相反，我相信它會將 SSD 置于現實生活中很少遇到的極端條件下。

其他人說你應該繪制延遲與每秒操作數的關系圖，但在我們看來這也有點奇怪，因為這意味著你繪制的是 F1(q) 與 F2(q) 而不是“q”的關系圖本身。

簡而言之，基準測試可能是一個持久的過程。獲得完整的結果可能需要幾天時間。這通常是像 3dnews 這樣的資源在他們的 SSD 評論中所做的。但我們不想花費幾天的時間。我們需要一個能讓我們快速評估性能的測試。

因此，我們排除了一些“極端”模式，檢查其中的磁盤，并假裝其他結果介于這些“極端”之間，形成某種取決于參數的平滑函數。這些模式中的每一種也對應于一個有效的用例，這也很方便：

• 主要使用線性或大塊訪問的應用程序：對于此類應用程序，關鍵特征是線性 I/O 速度（以兆字節/秒為單位）。因此，第一個測試模式是線性讀/寫，具有 4 MB 塊和 16-32 操作的中等隊列深度。測試結果應以 MB/s 為單位。
• 使用隨機小塊訪問并支持并行性的應用程序。這導致我們使用 4 KB 隨機 I/O 模式，隊列深度至少為 128 個操作。4 KB 是大多數文件系統和 DBMS 的標準塊大小。如果單個線程無法在測試期間使驅動器飽和，則應使用多個 (2-4-8) CPU 線程。測試結果應包括 iops（每秒 I/O 操作數），但不包括延遲。延遲在這個測試中沒有意義，因為它可以通過增加隊列深度任意增加——延遲與 iops 直接相關，公式為 latency=queue/iops。
• *使用隨機小塊訪問且不支持并行性的應用程序。此類應用程序比您想象的要多；關于寫入，所有事務性 DBMS 都是一個值得注意的例子。這導致我們進行隊列深度為 1 的 4 KB 隨機 I/O 測試，對于寫入，在每次操作后進行 fsync 以防止磁盤或存儲系統通過將數據寫入易失性緩存來“作弊”。結果應包括 iops 或延遲，但不能同時包括兩者，因為正如我們之前所說，它們彼此直接相關。

基于這些信息，本文提供了一個腳本 (https://gist.github.com/kvaps/e36b82826fb8e36d0362c7f4033948d0) 來運行每個測試，然后收集并解析獲得的數據。

請注意，以下所有圖表均基于上面列出的八項測試。每個測試只運行一分鐘。當然，這些時間不足以完全探索所有的細微之處，但對于不同解決方案的一般比較來說已經足夠了。

一、測試“原始”NVMe 性能

任何基準測試都應該從基礎磁盤本身的測試開始。

這是查看我們在性能上損失了多少的起點。

根據測試結果，您可以看到我們使用的磁盤在性能上有所不同——這（可能）是由于它們的老化。

二、測試后端開銷

現在我們獲取到了 NVMe 本身的性能，下面我們需要測量每個后端的性能。總所周知，DRBD 可以在任意塊設備之上工作，甚至可以在原始未分區磁盤之上工作。

然而，自 DRBD9 發布以來，為每個虛擬機或容器使用專用設備的想法已成為主流，因為它有助于擴展并減少系統故障的影響。邏輯卷管理器使批量準備大小合適的新卷變得更加容易。此外，它還支持各種新的功能，如實時調整大小、快照、重復數據刪除等。

LINSTOR (https://linbit.com/linstor/) 支持不同的后端，包括 LVM、LVMThin 和 ZFS。它們將在下面進行測試。為了進行測試，我們使用了可用的最快磁盤（在節點 3 上）并測量了它們的性能。下面是結果：

如上所見，與 LVMThin 和 ZFS 相比，經典 LVM 幾乎沒有開銷，但它支持的功能并不多。

如果我們要進行快照，我們必須使用 LVMThin 或 ZFS，因為它們支持 COW (?https://en.wikipedia.org/wiki/Copy-on-write)并且可以在不影響性能的情況下拍攝快照。?

LVMThin 的順序讀/寫操作很好，但是隨機讀/寫操作有很多不足之處。如果整個卷都用零填充（因此，磁盤空間得到預分配）并達到“原始”磁盤性能的一半，則性能結果會更好。

ZFS 結果明顯更差。我們試圖通過調整塊大小來調整它。不幸的是，它對結果幾乎沒有影響（我們測試了 512、4K、32K 和 512K 塊大小；默認值為 8K）。較小的塊大小略微提高了性能，但延遲也顯著增加。更大的塊大小增加了順序讀寫速度，但這不是我們的目標。

然后我們決定將 ZFS 擱置一旁，并嘗試使用 LVMThin 進行同樣的操作。las，更改塊大小對測試結果幾乎沒有影響。

最終，我們選擇了默認設置的 LVM 或 LVMThin。?

LINSTOR 可以使用 LUKS 加密卷，我們很好奇這種加密在性能損失方面的成本是多少。事實證明，對 LUKS 的影響很小：對于偶爾的隨機讀/寫或順序操作，性能幾乎沒有變化，而對于一系列隨機操作，性能僅減半。您可以在圖表中看到：

三、測試DRBD開銷

在后端確認下來后，我們開始確定 DRBD 副本開銷。我們測試了每個可用的后端，但我們在這里只將 LVM 作為主要示例。

使用以下三種配置進行 DRBD 基準測試：1 個副本（純 DRBD 開銷）、兩個本地副本和兩個帶有遠程無盤客戶端的副本。

以下是結果：

?該圖顯示 DRBD 顯著降低了隨機讀/寫速度，使順序操作幾乎沒有開銷。

啟用二個副本會稍微降低操作速度并增加沒有并行性的測試的延遲。

但這很有意義：我們同時寫入兩個副本并等待每個副本的操作完成。?

在無盤客戶端的情況下，兩個副本都在遠程服務器上，因此客戶端需要連接到它們，因此速度下降和延遲增加。

此時可以得出以下結論：

• 在兩個副本的情況下，其中一個在本地，與 “raw” 設備相比，性能下降了三倍，而延遲增加了一倍（實際上這只是 CPU 的開銷）。
• 在兩個副本和一個遠程無盤客戶端的情況下，性能下降了四倍或更多，而延遲加倍。

DRBD 調整對最終結果幾乎沒有影響，所以在后續測試中沒有使用它。

四、與其他集群文件系統的比較

看起來有很多因素會導致太多的性能損失，所以在這一點上，我們決定將 DRBD 與其他解決方案進行比較。一共有三個：Ceph RBD、Mayastor 和實驗性存儲 Vitastor。

為了公平起見，我們決定使用速度較慢的后端 LVMThin，它支持 COW 和快照創建，就像 Mayastor 以外的許多其他集群文件系統一樣。

這是我得到的：

結果讓我吃驚。

Local Mayastor在隨機寫操作上排名第一，Vitastor排名第二，其次是local DRBD、Ceph、diskless DRBD。

本地 DRBD 在讀取測試中表現最好，結果良好且延遲最低。

五、千兆網絡基準測試

我還想知道每種解決方案在千兆網絡上的表現如何：

如上所見，所有四種解決方案都完美地利用了千兆以太網通道。然而，結果還有很多不足之處。Mayastor 的表現比其他人一點。DRBD 在讀方面非常出色，但寫作速度依然是很糟糕。

六、壓力測試

現在是最重要的部分：壓力測試。上述測試旨在了解存儲能力。對于這一部分，我們將嘗試模擬真實環境的負載，看看每個解決方案如何處理它。

我們將使用具有 75% 的隨機讀取和 25% 的隨機寫入操作的標準 r/w 測試，并運行它的多個副本。

fio -name=test -filename=/dev/xvda -ioengine=libaio -direct=1 -rw=randrw -rwmixread=75 -bs=4k -numjobs=1 -iodepth=64 -size=4G

我們將設置 15 分鐘的時間限制，看看在這段時間內完成了多少測試，然后將編譯通用統計數據。

LINSTOR 和 Mayastor 比其他解決方案領先一步，因為它們建議設置volumeBindingMode: WaitForFirstConsumer，從而在我們的 Pod 最終所在的同一節點上配置卷。我們決定禁用此功能以比較類似環境中的解決方案。

Ceph 還配置為每個驅動器運行兩個 OSD 并設置更多 pg (512)。

最后兩張圖顯示了節點上的總資源消耗，但這個信息很難客觀，所以不要想當然。如需更詳細的分析，我建議查看 Grafana 圖。

Grafna 對應的圖表如下：

• LINSTOR (LVMThin)：??(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/linstor_lvmthin.html);
• Vitastor1：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/vitastor1.html);
• Vitastor2：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/vitastor2.html);
• Mayastor：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/mayastor.html);
• Ceph：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/ceph.html).?

即使有大量客戶端讀寫，LINSTOR 也始終顯現出很好的結果；Vitastor 幾乎同樣出色。

Mayastor 和 Ceph 緊隨其后。此外，正如 Grafana 圖表清楚地顯示的那樣，Ceph 消耗了更多的 RAM 和 CPU 資源。

在這里，我們必須指出，Mayastor 目前不支持 COW 和快照，因此您可以放心地將它與具有 LVM 后端的 LINSTOR 進行比較：

最后兩張圖顯示了節點上的總資源消耗，但這個信息很難客觀，所以不要想當然。如需更詳細的分析，我建議查看 Grafana 圖。

Grafna 對應的圖表如下：

• LINSTOR (LVMThin)??：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/linstor_lvmthin.html);
• Vitastor1：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/vitastor1.html);
• Vitastor2：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/vitastor2.html);
• Mayastor：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/mayastor.html);
• Ceph：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/ceph.html).?

即使有大量客戶端讀寫，LINSTOR 也始終顯現出很好的結果；Vitastor 幾乎同樣出色。

Mayastor 和 Ceph 緊隨其后。此外，正如 Grafana 圖表清楚地顯示的那樣，Ceph 消耗了更多的 RAM 和 CPU 資源。

在這里，我們必須指出，Mayastor 目前不支持 COW 和快照，因此您可以放心地將它與具有 LVM 后端的 LINSTOR 進行比較：

Grafana 圖形：

• Mayasto?r：(??https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/mayastor.html??);
• Linstor (LVM)：(??https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/linstor_lvm.html??).?

LINSTOR 對 24 個本地客戶端的測試結果相當奇怪——集群可能正忙于做其他事情。但總體趨勢很明顯：LINSTOR + LVM 配置明顯優于 Mayastor。Mayastor 的優點在于它具有較低的 CPU 平均負載。

另一方面，我們可以啟用volumeBindingMode: WaitForFirstConsumer并查看測試結果有多少變化。請注意，在這種模式下，至少有一個副本是本地的，即它與 Pod 運行在同一個地方：

Grafna 圖形：

• Mayastor (local)：??(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/mayastor_local.html);
• LINSTOR (LVM local)：(https://kvaps.github.io/images/posts/Comparing-Ceph-LINSTOR-Mayastor-and-Vitastor-storage-performance-in-Kubernetes/linstor_lvm_local.html).?

簡單總結

根據基準測試結果，基于當前的配置信息：

• LINSTOR 是最快的存儲解決方案之一。?
• Vitastor 緊隨其后，后者（如果考慮其類似 Ceph 的架構）看起來很有前途。例如，這將允許在所有集群節點之間分配單個塊設備的負載。
• Mayastor 性能也不錯，但目前它的功能比較少。如果客戶端數量很多，同等配置的 LINSTOR 會更快。
• Ceph 消耗比較多的硬件資源（通常看這些可能會是瓶頸）。目前，開發人員正在開發一個新的 Crimson (?https://www.youtube.com/watch?v=YxbT5MneEL0?) 后端——當它發布時，我們希望在這方面會有所改善。

對于我們的案例，LINSTOR 被選為最成熟的生產就緒解決方案。