Ceph 中的写入放大

傷城~ 2024-05-05 07:35 2阅读 0赞

## ![c63a47d534cc55fde99ba1c24c885862.gif][] ##

新钛云服已累计为您分享**769**篇技术干货

![cb8fd68ff8ed45d4da03ae43cb6ea7c1.gif][]

![d3c01d76d540ddc2c5c6c6698412cf95.png][]

**介绍**

![f9f764197358682b5a131d16bce17a51.png][]

Ceph 是一个开源的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。 Ceph 独一无二地在一个统一的系统中同时提供了对象、块、和文件存储功能。 Ceph 消除了对系统单一中心节点的依赖，实现了无中心结构的设计思想。

我们知道Ceph为了保障数据的可靠性，存放数据通常是三副本策略（另有EC策略）。那么无论是data，metadata，journal都是三份。因此在应用端写入一个IO，在ceph内部实际上会额外产生许多内部IO，不同的存储后端差异很大。 Ceph提供了FileStore、KStore和BlueStore三种存储后端以供选择，那么以FileStore为例，来看看13X的写放大的来由。FileStore中ceph的数据被存放在XFS或者ZFS等本地文件系统中。这些文件系统本身又会记录日志（FS journal），以及还有它自己的元数据（FS metadata）。

在设计存储基础结构时，为了防止故障，保证一定的冗余度是非常有必要的。但是，冗余伴随着存储效率的降低，这也会增加您的成本。对于大型基础设施，每 TB 成本的差异可能会导致总存储成本显著提高。因此，Ceph 中的纠删码非常有吸引力。 纠删码类似于基于奇偶校验的 RAID 阵列。为每个对象创建许多数据块 （K） 和奇偶校验块 （M）。另一方面，副本只是创建给定对象的其他副本，类似于镜像 RAID 阵列。这通常意味着纠删码比副本具有更高的存储效率，计算公式为 k/（k+m）。 例如，以 6+2 为例，您将获得 75% 的存储效率——在记录的总 8 个区块中，有 6 个数据块。与三个副本相比，您将有 33% 的效率，总共 3 个记录的块中有 1 个数据块。

![8eaa5f71470b61c012bf027c6fdcf87f.png][]

**写入放大**

正常来说，Ceph 都没啥问题，除了一个经常被忽视的问题：写入放大。 数据存储中的最小分配大小本质上是一段数据可以写入的最小单位。在 Pacific Ceph 之前，此值默认为 64kb。此最小分配单元会给某些工作负载带来问题，尤其是那些对小文件进行操作的工作负载。

![c25d7834a552f2dff2f9d483cd7aeb2d.png][]

**案例**

4% 存储效率示例如下图：

![31fcbd43a4bcecdc06ee9b85faedc6c3.png][]

为了更直观一点，让我们考虑一个传入写入为 16kb 的 4+2 纠删码池。 在上面的示例中，单个 16K 写入最终会放大 24 倍的大小，因为每个块至少需要以 64K 的速度写入磁盘。这导致此特定对象的总存储效率为 ~4%。如果您的工作负载主要由 16K 对象组成，那么这可能会很快抵消您的 EC 配置文件提供的任何优势。下面是使用相同文件大小的 3 副本示例。

![9471229f7ab9c3900f476d940a7accb5.png][]

如上图所示，在此特定工作负载中，3 Replica 实际上比 4+2 纠删码池的存储效率更高。这表明规则总是有例外。从理论上讲，当存储效率是最高优先级时，应使用纠删码，但根据您的数据集，这可能会发生巨大变化。

![89dee4692e8e72dba317728a15e2d851.png][]

**写入放大重要的用例**

当然，即使按照小文件工作负载标准，16K 文件也很小，单单一篇文章的大小就 100K 左右。另外，一些可能存在写入放大问题的场景是：

*  AI training 人工智能训练
 *  audio editing 音频编辑
 *  log storing/aggregation 日志存储/聚合
 *  scientific computing 科学计算

![6b26e436dcb65a85a1ecd40b2618220a.png][]

**结论**

了解数据和工作负载是确定 Ceph 集群构建的关键部分。了解整个数据的平均文件大小将使您能够避免这种极高的写入放大。 当然，这并不总是这样的。通常，在单个集群中往往会存在各种大小的文件。在这种情况下，只需确定数据的位置即可。例如，如果单个目录树拥有大部分小文件，则可以将副本池固定到该特定树，而具有较大文件大小的其余数据仍保留在纠删码上。 如前所述，当您的最小分配大小太大时，写入放大会更加普遍，这就是为什么较新版本的 Ceph（如 Pacific 和 Quincy）默认为 4K 而不是 64K 的原因。在较新的集群或最小分配大小修改的 Octopus 集群中，写入放大的问题要小得多，因此，我们在后续的集群部署前，需要认真考虑一下。

**推荐阅读**

**![2f4b0dc5c19beacfb7eb35176948882d.png][]**

![2af4835627faf1c6d38059aba3c2777a.png][]

**推荐视频**

[c63a47d534cc55fde99ba1c24c885862.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/f4cd2ff78d67488982e41823b106065a.gif
[cb8fd68ff8ed45d4da03ae43cb6ea7c1.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/3bad03725f514a3c983888b328e93834.gif
[d3c01d76d540ddc2c5c6c6698412cf95.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/98d1f56e5f3544b290d78bc77dcd94aa.png
[f9f764197358682b5a131d16bce17a51.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/c7441ab004a84c1d9e5bcb6048ad5ce4.png
[8eaa5f71470b61c012bf027c6fdcf87f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/bbcdfa0acecc457782d283b6d0b5a08c.png
[c25d7834a552f2dff2f9d483cd7aeb2d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/82f4561b66d5492399e7bac078ea2213.png
[31fcbd43a4bcecdc06ee9b85faedc6c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/e246a8b9ff204ec69ef8a593b01b06ec.png
[9471229f7ab9c3900f476d940a7accb5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/e17023e476384e0ab8d85c9beebb5bad.png
[89dee4692e8e72dba317728a15e2d851.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/cbf50a527feb43348ce7f8c8c74c321a.png
[6b26e436dcb65a85a1ecd40b2618220a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/6ef2dc09d4d24e65b5eabcb4b16eb1e5.png
[2f4b0dc5c19beacfb7eb35176948882d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/7a03b04998ca4bfe9d22543ca3634bd8.png
[2af4835627faf1c6d38059aba3c2777a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/05/4c3a82058cb24160a39410cdbc1619c6.png