• 服务器：三台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 测试的命令：

针对上诉测试命令，这篇文章(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 或延迟，但不能同时包括两者，因为正如我们之前所说，它们彼此直接相关。

任何基准测试都应该从基础磁盘本身的测试开始。

现在我们获取到了 NVMe 本身的性能，下面我们需要测量每个后端的性能。总所周知，DRBD 可以在任意块设备之上工作，甚至可以在原始未分区磁盘之上工作。

如上所见，与 LVMThin 和 ZFS 相比，经典 LVM 几乎没有开销，但它支持的功能并不多。

在后端确认下来后，我们开始确定 DRBD 副本开销。我们测试了每个可用的后端，但我们在这里只将 LVM 作为主要示例。

该图显示 DRBD 显着降低了随机读/写速度，使顺序操作几乎没有开销。

• 在两个副本的情况下，其中一个在本地，与 “raw” 设备相比，性能下降了三倍，而延迟增加了一倍（实际上这只是 CPU 的开销）。

• 在两个副本和一个远程无盘客户端的情况下，性能下降了四倍或更多，而延迟加倍。

看起来有很多因素会导致太多的性能损失，所以在这一点上，我们决定将 DRBD 与其他解决方案进行比较。一共有三个：Ceph RBD、Mayastor 和实验性存储 Vitastor。

结果让我吃惊。

本地 DRBD 在读取测试中表现最好，结果良好且延迟最低。

我还想知道每种解决方案在千兆网络上的表现如何：

如上所见，所有四种解决方案都完美地利用了千兆以太网通道。然而，结果还有很多不足之处。Mayastor 的表现比其他人一点。DRBD 在读方面非常出色，但写作速度依然是很糟糕。

现在是最重要的部分：压力测试。上述测试旨在了解存储能力。对于这一部分，我们将尝试模拟真实环境的负载，看看每个解决方案如何处理它。

我们将设置 15 分钟的时间限制，看看在这段时间内完成了多少测试，然后将编译通用统计数据。

最后两张图显示了节点上的总资源消耗，但这个信息很难客观，所以不要想当然。如需更详细的分析，我建议查看 Grafana 图。

• 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 资源。

最后两张图显示了节点上的总资源消耗，但这个信息很难客观，所以不要想当然。如需更详细的分析，我建议查看 Grafana 图。

• 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).

Grafana 图形：

• Mayastor：(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).

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) 后端——当它发布时，我们希望在这方面会有所改善。

原文：

https://blog.palark.com/kubernetes-storage-performance-linstor-ceph-mayastor-vitastor/