第 1 部分 - BlueStore（默认与调优）性能比较
致谢 ¶
我们感谢BBVA、Cisco和Intel提供的尖端硬件，这些硬件用于运行Red Hat Ceph Storage 3.2全闪存性能POC。本博客系列提供的测试和结果是BBVA、Intel、Cisco和Red Hat合作的共同努力。所有合作伙伴共同努力，为基于Red Hat Ceph Storage和Cisco及Intel硬件技术的软件定义存储构建块创建性能基准。
执行摘要 ¶
- 与默认（开箱即用）配置相比，调整Ceph配置以用于全闪存集群可带来显著的性能提升。从而提供高达134%更高的IOPS、约70%更低的平均延迟和约90%更低的尾部延迟，适用于全闪存集群。
RHCS 在全闪存存储上的介绍 ¶
全闪存存储系统为企业提供了多项优势。这包括在吞吐量和更低延迟方面的高性能、与传统基于硬盘的存储系统相比，降低的TCO（总拥有成本），以及降低的功耗和冷却消耗。全球数字化转型需要对企业IT基础设施进行现代化改造，以提高几乎所有关键业务应用程序的性能、响应能力和弹性。随着复杂应用程序堆栈、数据库和新型工作负载的激增，存储（数据）已成为当今企业的神经系统。实现存储天堂的唯一途径是使用为Exascale构建的软件定义、可扩展存储技术。
Red Hat Ceph Storage (RHCS) 是一种开源、大规模可扩展的软件定义存储，它具有企业存储工作负载所需的所有弹性、持久性和可靠性。随着NAND技术的进步，闪存介质作为存储变得越来越经济实惠。RHCS 占据中心舞台，能够以低延迟提供数百万IOPS，满足客户最苛刻和存储密集型工作负载的需求。
高性能和延迟敏感型工作负载通常通过块设备接口消耗存储。Ceph 通过 RBD（一个 librbd 库）为客户端提供块存储，RBD 是位于 rados 之上的一个薄层（如图 1 所示），利用 rados 提供的所有功能。RBD 块设备本质上是分布式，因为它在 Red Hat Ceph Storage 集群中的多个对象上条带化块设备映像，每个对象都映射到放置组，并分布在整个集群中的单独 Ceph OSD 上，这大大增强了访问 RBD 卷数据的并行性。
图 1：RHCS 架构组件
RHCS 块设备是稀疏配置的、可调整大小的，并在 Ceph 集群中的多个 OSD 上存储条带化数据。RHCS 块设备利用 RADOS 功能，例如自愈、复制和一致性。
Ceph 是一个拥有蓬勃社区的开源项目，在最近的几个版本中，对全闪存集群的性能优化方面做了大量工作，其中一些改进包括
- 引入 BlueStore 作为 OSD 的新型存储后端。从 RHCS 3.2 开始，BlueStore 功能已正式发布 (GA)。BlueStore 通过简化 IO 数据路径和避免双写惩罚，与旧的 FileStore 后端相比，提供了巨大的性能提升。
- 降低 CPU 使用率。与 BlueStore 一起，Ceph 核心的许多其他性能改进有助于降低 OSD CPU 消耗，尤其是在闪存介质 OSD 上。
BlueStore 介绍 ¶
BlueStore 是 Ceph OSD 守护进程的新型对象存储后端。原始对象存储 FileStore 需要在原始块设备之上使用文件系统。对象随后被写入文件系统。与原始 FileStore 后端不同，BlueStore 直接将对象存储在块设备上，而无需任何文件系统接口，从而提高了集群的性能。要了解有关 BlueStore 的更多信息，请参阅 Red Hat Ceph 文档。
BlueStore 内部原理 ¶
图 2 显示了 BlueStore 如何与块设备交互。数据直接写入原始块设备，所有元数据操作都由 RocksDB 管理。包含 OSD 的设备在 RocksDB 元数据和集群中存储的实际用户数据之间进行划分。用户数据对象作为 blob 直接存储在原始块设备上，一旦数据写入块设备，RocksDB 元数据就会使用有关新数据 blob 的所需详细信息进行更新。
RocksDB 是一种嵌入式高性能键值存储，非常适合闪存存储。RocksDB 无法直接写入原始磁盘设备，它需要一个底层文件系统来存储其持久数据，这就是 BlueFS 的用武之地。BlueFS 是一个使用 RocksDB 存储其 sst 文件所需的最少功能集而开发的 Filesystem。
RocksDB 在持久存储上使用 WAL 作为事务日志，与所有写入首先进入日志的 Filestore 不同，在 bluestore 中我们有两种不同的写入数据路径，一种是将数据直接写入块设备，另一种使用延迟写入，使用延迟写入，数据写入 WAL 设备，然后异步刷新到磁盘。
Bluestore 有多种可能的存储布局配置
- 主设备，用于存储对象数据。
- 可选的 RocksDB 设备，用于存储元数据
- 可选的 WAL 设备，用于存储事务日志。
例如，在我们的测试环境中，我们将主设备配置在 Intel P4500 驱动器上，这是用户数据将存储在的位置。然后，我们将 WAL 和 RocksDB 设备配置在更快的 Intel Optane P4800 驱动器上，将 WAL 和 RocksDB 放在高性能驱动器上将为我们提供更多的 IOPS 和更低的延迟。
BlueStore 的一项新功能是它能够在最低级别压缩数据，如果启用了压缩，分配到原始设备上的数据 blob 将被压缩。这意味着写入 RH Ceph Storage 的任何数据，无论使用哪个客户端（rbd、rados 等），都可以从此功能中受益。
BlueStore 的另一个好处是它以校验和的形式在集群中存储数据和元数据，以提高完整性。每当从持久存储读取数据时，都会对其校验和进行验证
图 2：BlueStore 与 Filestore 比较
实验室环境详情 ¶
测试实验室由 5 个 RHCS 全闪存（NVMe）服务器和 7 个客户端节点组成，详细的硬件和软件配置分别如表 1 和表 2 所示。
| 5 个 RHCS OSD 节点配置 | |
| 机箱 | Cisco UCS C220-M5SN 机架服务器 |
| CPU | 2 个 Intel® Xeon® Platinum 8180 28 核（56 HT 核）@ 2.50 GHz |
| 内存 | 196 GB |
| 网卡 | Cisco UCS VIC 1387 2 端口 x 40Gb |
| 存储 | Ceph 数据：7 个 Intel® SSD DC P4500 4.0 TB
Ceph 元数据（RocksDB/WAL）：1 个 Intel® Optane™ SSD DC P4800X 375 GB Ceph 存储池放置组：4096 |
| 软件配置 | RHEL 7.6、Linux Kernel 3.10、RHCS 3.2 (12.2.8-52) |
表 1：Ceph 节点配置 ¶
| 7 个客户端硬件配置 | |
| 机箱 | Cisco UCS B200 M4 刀片服务器 |
| CPU | 2x Intel® Xeon® CPU E5-2640 v4 @ 2.40GHz |
| 内存 | 528 GB |
| 网卡 | Cisco UCS VIC 1387 2 端口 x 10Gb |
| 软件配置 | RHOSP 10、RHEL 7.6、Linux Kernel 3.10、Pbench-FIO 3.3 |
表 2：客户端节点配置 ¶
从 RHCS 3.2 开始，支持容器化存储守护进程 (CSD) 部署策略，并且在本基准测试练习中使用了相同的策略。与推荐每个介质设备一个 OSD 的旋转介质不同，本测试中使用的每个 NVMe 设备都配置为由两个 Ceph OSD 使用，以充分利用 NVMe 设备的性能。
图 3：实验室环境拓扑
对于高度高性能和容错的存储集群，网络架构与运行监视器和 OSD 守护进程的节点一样重要。因此，部署的网络架构必须能够处理预期的客户端带宽数量。如图 3 所示，使用了两个物理网络
- 公共网络由 Ceph 客户端用于在 Ceph OSD 节点上读取和写入。
- 集群网络使每个 Ceph OSD 守护进程能够检查其他 Ceph OSD 守护进程的心跳，向监视器发送状态报告，复制对象，重新平衡集群并在系统组件发生故障时回填和恢复。
实验室环境部署了 ACI leaf 和 spine 拓扑，公共网络和集群网络都配置为使用 jumbo frame，MTU 大小为 9000。
从 OSP 客户端的网络带宽受限于光纤互连上行链路，因此我们只有 80gbit/s 可用，因此从客户端到 ceph 集群的最大吞吐量约为 10GBytes/s。
图 4：实验室环境网络拓扑
容器化 Ceph 守护进程的部署使我们能够将多个 Ceph 服务放置在单个节点上。这消除了对专用存储节点的需要，并有助于降低 TCO。因此，前 3 个节点用于共同放置 Ceph MON、Ceph MGR 和 Ceph OSD 服务，其余两个节点专用于 Ceph OSD 使用。表 3 详细说明了为不同的 Ceph 守护进程配置的每个容器的资源限制。
对于每个 RHCS 节点，我们有 2 个 x 28 个物理核心，通过超线程，这为我们提供了总共 112 个 vCPU。我们将 vCPU 的数量分配给 RHCS 服务，并为 OS 保留了一些。因此，我们将 8 个 vCPU 分配给 OS，每个 Ceph Monitor 和 Manager 容器分配 3 个 vCPU。对于每个 Ceph OSD 容器，我们设置了 7 个 vCPU 的限制。由于每个节点有 7 个 NVMe 设备，为了充分利用 NVMe 设备，每个设备都配置（分区）为托管 2 个 Ceph OSD。因此，最终计算结果如下：7 个 vCPU/OSD * 7 个 NVMe 设备 * 每个设备 2 个 OSD = 每个节点分配给 Ceph OSD 的 98 个 vCPU。如果我们加上 MON 的 3 个 vCPU、MGR 的 3 个 vCPU 和 OS 的 8 个 vCPU，我们达到了 112 个 vCPU，即达到了物理 CPU 的完全订阅。
| 操作系统 | 每个 OSD 容器 | 每个 MON 容器 | 每个 MGR 容器 | |
| vCPU（HT 核心） | 8 | 7 | 3 | 3 |
| 内存（GB） | 12 | 12 | 6 | 6 |
表 3：Ceph 容器资源分配
基准测试方法 ¶
FIO 是行业标准的合成基准测试工具，用于测试 Ceph 块存储。它提供了一个 librbd 模块来针对 RBD 卷运行测试。我们使用了不同数量的卷/客户端节点，具体取决于我们希望在每个测试中实现的目标，我们主要使用了以下两种组合
- 7 个客户端，每个客户端有 12 个 200GB Ceph RBD（84 个卷）
- 7 个客户端，每个客户端有 15 个 200GB Ceph RBD（105 个卷）
最初我们使用 12 个 Ceph RBD 卷给每个客户端，然而在某些测试中，我们无法使用 12 个卷将存储子系统压力测试到峰值，因此在一些测试中我们将每个客户端的卷数增加到 15 个，从而获得了更高的性能。在使用每个客户端 15 个卷时，我们使用了 2x 复制池上的 21TB 已配置容量（42TB 原始容量）。
FIO librbd IOengine 允许 fio 测试 Ceph RBD 卷的块存储性能，无需 KVM/QEMU 配置，通过用户态 librbd 库实现。这些库与 QEMU 后端使用的库相同，因此如果我们将 7 个客户端乘以 15 个 RBD 卷，就可以创建一个类似于使用每个 RBD 卷的 105 个 OSP 实例的客户端工作负载。使用的 FIO 模板文件可在此处获取 这里。
在运行测试之前，RBD 卷使用顺序写入预先置备到卷的全部大小，从而消除了 Ceph 薄配置机制的影响，以生成稳定且可重现的结果。在每个测试之前，从所有 OSD 和客户端节点中删除 .OS 缓存。每个测试运行四次，运行时间为 900 秒，预热时间为 180 秒。该研究报告了这四次运行的平均结果。
性能比较：默认 BlueStore 与调优 BlueStore ¶
开箱即用的 BlueStore OSD 后端的 RHCS 在大型块工作负载方面表现出色，但是对于小块，发现默认 OSD 配置过于保守。因此，我们调整了 RHCS 集群以优化小块性能，作为参考，使用的 ceph.conf 文件可在此处获取 这里。
以下是一些应用于 Ceph OSD 的最相关的调优。
- 用于 BlueStore 元数据的 RocksDB 键值存储在 OSD 的写入性能中起着重要作用。应用以下 RocksDB 调优以最大程度地减少由于 DB 压缩引起的写入放大。
| bluestore_rocksdb_options = compression=kNoCompression,max_write_buffer_number=32,min_write_buffer_number_to_merge=2,recycle_log_file_num=32,compaction_style=kCompactionStyleLevel,write_buffer_size=67108864,target_file_size_base=67108864,max_background_compactions=31,level0_file_num_compaction_trigger=8,level0_slowdown_writes_trigger=32,level0_stop_writes_trigger=64,max_bytes_for_level_base=536870912,compaction_threads=32,max_bytes_for_level_multiplier=8,flusher_threads=8,compaction_readahead_size=2MB |
- RHCS 3.2 引入了 bluestore 缓存自动调优功能。这对于大多数工作负载来说效果很好，因此我们建议使用它，但是我们发现，在测试期间，禁用缓存自动调优并手动配置 BlueStore 缓存选项可以获得更好的结果。
| bluestore_cache_autotune = 0 |
- 在随机小块工作负载中，尽可能多地将 BlueStore 元数据（Onodes）缓存起来非常重要。如果 OSD 节点上有足够的内存，则增加 bluestore 缓存的大小可以提高性能，在我们的例子中，我们使用 8GB 的 bluestore 缓存，而可用内存为 12Gb。默认的 bluestore_cache_size_ssd 是 4GB
| bluestore_cache_size_ssd = 8G |
- 当 bluestore_cache_autotune 被禁用并且设置了 bluestore_cache_size_ssd 参数时，BlueStore 缓存被细分为 3 个不同的缓存
- cache_meta：用于 BlueStore Onode 及其相关数据。
- cache_kv：用于 RocksDB 块缓存，包括索引/Bloom 过滤器
- 数据缓存：用于 BlueStore 数据缓冲区的缓存。
- 可以使用比例来配置每个缓存的空间量，对于 RBD 工作负载，我们增加了 bluestore_cache_meta_ratio，以便获得更大的 BlueStore Onode 缓存大小，在测试期间，使用以下比例可以获得最佳结果
| bluestore_cache_autotune = 0
bluestore_cache_kv_ratio = 0.2 bluestore_cache_meta_ratio = 0.8 |
- 当 RHCS 开始为故障 OSD 执行恢复过程时，它会使用基于日志的恢复，小块写入会生成一个很长的更改列表，这些更改必须写入 PG 日志，这会增加写入放大并影响性能。在测试期间，我们观察到减少存储的 PG 日志数量可以提高性能。但是，这些设置有一个缺点，几乎所有的恢复过程都会使用回填，当我们使用回填时，我们必须逐步遍历整个 PG 的哈希空间，并将源 PG 与目标 PG 进行比较，从而增加恢复时间。
- 我们在测试期间观察到减少 PG 日志数量可以减少写入放大。因此，应用了以下 PG 日志调优。
| osd_min_pg_log_entries = 10
osd_max_pg_log_entries = 10 osd_pg_log_dups_tracked = 10 osd_pg_log_trim_min = 10 |
- 在所有 Ceph 节点上应用了定制的 Red Hat Enterprise Linux 7.6 吞吐量性能 tuned profile。
如图 1 所示，调优 BlueStore 相比于默认 BlueStore 配置，产生了更高的 IOPS 和更低的平均和尾部延迟。因此，与默认配置相比，调优后的 BlueStore 显示
| Ceph BlueStore 调优配置n | |||
| 工作负载 | IOPS | 平均延迟 | 尾部延迟 |
| 随机读 | 高 43% | 低 30% | 低 36% |
| 随机读写 | 高 132% | 低 73% | 低 90% |
| 随机写 | 高 134% | 低 70% | 低 91% |
图 1：RHCS 3.2 默认配置与调优配置
接下来 ¶
在基准测试博客系列的后续部分，在 下一节中，您将了解在 RHCS 3.2 BlueStore 全闪存集群上运行的小块、中块和大型块工作负载的性能见解。
本文最初由 Karan Singh 和 Daniel Parkes 撰写。