BlueStore压缩性能

使用BlueStore OSD后端，Red Hat Ceph Storage获得了一种称为“动态数据压缩”的新功能，有助于节省磁盘空间。可以对在BlueStore osd上创建的每个Ceph池启用或禁用压缩。除此之外，使用Ceph CLI可以随时更改压缩算法和模式，而不管池中是否包含数据。在本文中，我们将深入探讨BlueStore的压缩机制，并了解其对性能的影响。

BlueStore中的数据是否被压缩由压缩模式和与写操作相关的任何提示的组合决定。BlueStore提供的不同压缩模式有:

• none: 不压缩数据。
• passive:除非写操作具有可压缩提示设置，否则不要压缩数据。
• aggressive: 除非写入操作具有不可压缩提示设置，否则压缩数据。
• force:无论如何都要尝试压缩数据。在所有情况下使用压缩，即使客户端提示数据不可压缩。

compression_mode, compression_algorithm, compression_required_ratio, compression_min-blob_size, and compresion_max_blob_size 参数可以通过每个池属性或全局配置选项来设置。池属性可以通过以下方式设置:

ceph osd pool set <pool-name> compression_algorithm <algorithm>
ceph osd pool set <pool-name> compression_mode <mode>
ceph osd pool set <pool-name> compression_required_ratio <ratio>
ceph osd pool set <pool-name> compression_min_blob_size <size>
ceph osd pool set <pool-name> compression_max_blob_size <size>

Bluestore压缩内部原理

Bluestore不会压缩任何等于或小于配置的min_alloc_size的写入。在具有默认值的部署中，SSD的min_alloc_size为16KiB，HDD为64KiB。在我们的案例中，我们使用的是所有闪存（SSD）介质，Ceph不会尝试对大小低于32KiB的IO进行压缩。

为了能够在较小的块大小下测试压缩性能，我们重新部署了min_alloc_size为4KiB的Ceph集群，通过修改Ceph的配置，我们能够实现块大小为8KiB的压缩。

请注意，在Ceph集群中修改默认配置的min_alloc_size会对性能产生影响。在我们的例子中，我们将大小从16KiB减少到4KiB，我们正在修改8KiB和16KiB块大小的IOs的数据路径，它们将不再是延迟写入并首先进入WAL设备，任何大于4KiB的块将直接写入OSD配置的块设备。

Bluestore 压缩配置和测试方法

为了了解BlueStore压缩的性能方面，我们运行了以下几项测试：

1. 在Red Hat Openstack Platform 10上运行的40个实例，每个实例连接一个Cinder卷（40xRBD卷）。然后，我们使用连接的Cinder卷创建并安装了一个XFS文件系统。
2. 使用FIO libRBD IO引擎的84xRBD卷。

Pbench-Fio被用作首选的基准工具，具有3个新的Fio参数（如下），以确保Fio在测试期间生成可压缩的数据集。

refill_buffers
buffer_compress_percentage=80
buffer_pattern=0xdeadface

我们使用Aggressive压缩模式运行测试，这样我们就会压缩所有对象，除非客户端提示它们不可压缩。测试期间使用了以下Ceph bluestore压缩全局选项

bluestore_compression_algorithm: snappy
bluestore_compression_mode: aggressive
bluestore_compression_required_ratio: .875

bluestore_compression_required_tratio是此处的关键可调参数，计算如下

bluestore_compression_required_ratio = Size_Compressed / Size_Original

默认值为0.875，这意味着如果压缩没有将大小减少至少12.5%，则不会压缩对象。由于净增益较低，高于此比率的对象将不会以压缩方式存储。

为了了解我们在FIO合成数据集测试中实现的压缩量，我们使用了四个Ceph性能指标:

• Bluestore_compressed_original。被压缩的原始字节之和。
• Bluestore_compressed_allocated。为压缩数据分配的字节数之和。
• Compress_success_count。有益压缩操作的总和。
• Compress_rejected_count。由于空间净增益低而拒绝的压缩操作的总和。

要查询上述性能指标的当前值，我们可以使用Ceph perf dump命令对我们正在运行的osd之一:

ceph daemon osd.X perf dump | grep -E '(compress_.*_count|bluestore_compressed_)'

在压缩基准测试期间从客户端测量的关键指标:

• IOPS。每秒完成的IO操作总数
• Average Latency。客户端完成一次IO操作所需的平均时间。
• P95%。95%延迟的百分位数。
• P99%。 99%延迟的百分位数。

测试实验室配置

测试实验室由5个RHCS全闪存(NVMe)服务器和7个客户端节点组成，详细的硬件和软件配置分别如表1和表2所示。请参阅这篇博客文章，了解更多关于实验室设置的细节。

小块:FIO合成基准

重要的是要考虑到，使用Bluestore压缩可以节省的空间完全取决于应用程序工作负载的可压缩性以及所使用的压缩模式。因此，对于8KB的块大小和具有aggressive压缩的40个RBD卷，我们实现了以下compress_success_count和compress_rejected_count。

  "compress_success_count": 48190908,
  "compress_rejected_count": 26669868,

在我们的数据集(8KB)执行的74860776个写请求总数中，我们能够成功压缩48190908个写请求，因此在我们的合成数据集中成功压缩的写请求百分比为64%。

查看bluestore_compressed_allocated和bluestore_compressed_original 性能计数器，我们可以看到，由于Bluestore压缩，成功压缩的64%的写操作转化为每个OSD节省60Gb的空间。

"bluestore_compressed_allocated": 60988112896
"bluestore_compressed_original": 121976225792

如图-1/表1所示，在比较 Aggressive压缩和无压缩时，我们观察到个位数的IOPS百分比下降，这并不是很显著。同时发现平均和尾部延迟略高。这种性能税的原因之一可能是，Ceph BlueStore压缩每个对象blob以匹配compression_required_ratio，然后将确认发送回客户端。因此，当压缩设置为激进时，IOPS略有降低，平均延迟和尾部延迟增加。

图1: FIO 100% write test - 40 RBD Volumes

如图2所示，我们试图通过对来自aggressive压缩池和无压缩池的84个RBD卷运行FIO来增加集群上的负载。我们观察到了类似的性能差异，如图1所示。与无压缩相比，BlueStore压缩会带来轻微的性能税。实际上，任何声称提供动态压缩功能的存储系统都可以实现这一点。

图2: FIO 100% Random Read / Random Write test - 84 RBD Volumes

压缩也有与之相关的计算成本。数据压缩是由像snappy和zstd这样的算法完成的，它们需要CPU周期来压缩原始blob并存储它们。如图3所示，块大小越小(8K)，aggressive压缩和无压缩之间的CPU利用率差越低。当我们将块大小增加到16K/32K/1M时，这个增量会增加。其中一个原因可能是，对于较大的块大小，压缩算法需要做更多的工作来压缩blob和存储，从而导致更高的CPU消耗。

图 3: FIO 100% Random Write test - 84 RBD Volumes (IOPS vs CPU % Utilization)

大块(1MB): FIO合成基准

与小块大小类似，我们还测试了具有不同压缩模式的大块大小工作负载。因此，我们测试了aggressive、force和无压缩模式。如图4所示，aggressive模式和force模式的总吞吐量非常相似，我们没有观察到显著的性能差异。除了随机读工作负载之外，在随机读写和随机写模式中，压缩模式（aggressive /force）和无压缩模式之间存在很大的性能差异。

图4: FIO 1MB - 40 RBD Volumes

为了给系统增加更多的负载，我们使用了libRBD FIO IO引擎，并生成了84个RBD卷。该测试的性能如图5所示。

图 5: FIO 1MB - 84 RBD Volumes

MySQL数据库池的Bluestore压缩

到目前为止，我们已经讨论了基于FIO的综合性能测试，由PBench-Fio自动化。为了了解BlueStore压缩在接近真实的生产工作负载中的性能含义，我们在压缩和未压缩的存储池上测试了多个MySQL数据库实例的性能。

MySQL测试方法

Bluestore的配置方式与前面的测试相同，使用snappy 算法和aggressive压缩模式。我们在OpenStack上部署了20个VM实例，它们托管在5个计算节点上。在这20个VM实例中，有10个VM用作MySQL数据库实例，其余10个实例用作MySQL数据库客户端，这样在DB实例和DB客户端之间创建了1:1的关系。

10xMariadb服务器通过Cinder配备了1x100GB RBD卷，并安装在/var/lib/mysql上。在创建文件系统并安装之前，通过使用dd工具写入完整块设备对卷进行了预处理。

/dev/mapper/APLIvg00-lv_mariadb_data      99G 8.6G 91G 9% /var/lib/mysql

测试期间使用的MariaDB配置文件可在此gist中获得。使用sysbench命令在每个数据库上创建Dataset，如下所述。

sysbench oltp_write_only --threads=64 --table_size=50000000 --mysql-host=$i --mysql-db=sysbench --mysql-user=sysbench --mysql-password=secret --db-driver=mysql --mysql_storage_engine=innodb prepare

创建数据集后，运行了以下三种类型的测试:

• 读
• 写
• 读_写

在每次测试之前，重启mariadb实例以清除innodb缓存，每次测试在900秒内运行并重复2次，捕获的结果是2次运行的平均值。

MySQL测试结果

使用Bluestore压缩可以节省的空间完全取决于应用程序工作负载的可压缩性以及所使用的压缩模式。

在Mysql压缩测试中，结合Sysbench生成的数据集和bluestore默认compression_required_ratio(0.875)进行aggressive压缩，我们获得了以下成功和拒绝计数。

compress_success_count: 594148,
compress_rejected_count: 1991191, 

在我们的数据集中运行的2585339个写入请求总数中，我们能够成功压缩594148个写入请求，因此我们在Mysql Sysbench数据集中成功压缩的写入请求百分比为22%。

查看bluestore_compressed_allocated和bluestore_compressed_original性能计数器，我们可以看到，由于压缩，成功压缩的22%的写操作转化为每个OSD节省20Gb的空间。

bluestore_compressed_allocated: 200351744, 
bluestore_compressed_original: 400703488,

在Ceph-metrics的帮助下，我们在MySQL测试期间监视OSD节点上的系统资源。OSD节点的平均cpu使用率在14%以下，磁盘使用率在9%以下。发现磁盘延迟平均在~2 ms以下，孤立的峰值保持在个位数。

如图6所示，MySQL每秒事务数(TPS)没有受到BlueStore压缩的严重影响。在TPS和事务延迟方面，BlueStore aggressive 压缩确实比不压缩表现出较小的性能损失。

图6: MySQL数据库池上的BlueStore 压缩

主要结论

• 与未压缩池相比，启用BlueStore压缩的池显示，基于FIO的合成工作负载仅降低10%的性能，MySQL数据库工作负载仅降低7%。这种减少归因于执行数据压缩的底层算法。
• 在块大小较小(8K)的情况下，aggressive压缩和非压缩模式之间的CPU利用率差更低。这个增量随着块大小的增加而增加(16K/32K/1M)
• 低管理开销，同时支持Ceph池压缩。Ceph CLI开箱即用，提供了启用压缩所需的所有功能。