Ceph 中的写入写入放大

作者：祝祥 2023-10-12 08:01:00存储 存储架构 了解数据和工作负载是确定 Ceph 集群构建的关键部分。了解整个数据的写入平均文件大小将使您能够避免这种极高的写入放大。 当然，写入这并不总是写入这样的。通常，写入在单个集群中往往会存在各种大小的写入文件。

介绍

图片

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 个数据块。

写入放大

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

案例

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

图片

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

图片

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

写入放大重要的用例

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

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

结论

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

责任编辑：武晓燕 来源： 新钛云服 Ceph数据集群

(责任编辑：探索)