注意
本文档适用于 Ceph 开发版本。
纠删码
默认情况下，Cephpools会创建类型为“复制”的池。在复制类型的池中，每个对象都会被复制到多个磁盘。这种多次复制是称为“复制”的数据保护方法。
相比之下，erasure-coded池使用与复制不同的数据保护方法。在纠删码中，数据被分成两种类型的片段：数据块和奇偶校验块。如果一个驱动器发生故障或损坏，则使用奇偶校验块来重建数据。在大规模情况下，纠删码相对于复制可以节省空间。
在此文档中，数据块被称为“数据块”，奇偶校验块被称为“编码块”。
纠删码也称为“前向纠错码”。第一个前向纠错码由理查德·汉明在 1950 年在贝尔实验室开发。
创建一个示例纠删码池
最简单的纠删码池类似于RAID5并且至少需要三个主机：
ceph osd pool create ecpool erasure
pool 'ecpool' created
echo ABCDEFGHI | rados --pool ecpool put NYAN -
rados --pool ecpool get NYAN -
ABCDEFGHI
纠删码配置文件
默认纠删码配置文件可以在不丢失数据的情况下承受两个 OSD 的重叠丢失。这种纠删码配置文件相当于一个大小为三的复制池，但存储需求不同：它不需要 3TB 来存储 1TB，而只需要 2TB 来存储 1TB。默认配置文件可以使用此命令显示：
ceph osd erasure-code-profile get default
k=2
m=2
plugin=isa
crush-failure-domain=host
technique=reed_sol_van
Note
刚刚显示的配置文件是针对default纠删码池的，而不是针对最简单的纠删码池。这两个池不是相同的：
默认纠删码池有两个数据块（K）和两个编码块（M）。默认纠删码池的配置文件是“k=2 m=2”。
最简单的纠删码池有两个数据块（K）和一个编码块（M）。最简单的纠删码池的配置文件是“k=2 m=1”。
选择正确的配置文件很重要，因为配置文件在池创建后不能修改。如果您发现您需要一个与您创建的配置文件不同的配置文件（并且可能需要更仔细地考虑）的纠删码池，您必须创建一个具有不同（并且可能需要更仔细地考虑）配置文件的新池。当创建新池时，必须将配置文件错误的池中的所有对象移动到新创建的池中。在池创建后，没有办法更改池的配置文件。
配置文件的最重要参数是K, M, and crush-failure-domain，因为它们定义了存储开销和数据持久性。例如，如果所需的架构必须承受两个机架的丢失，并且存储开销为 67%，
ceph osd erasure-code-profile set myprofile \
k=3 \
m=2 \
crush-failure-domain=rack
ceph osd pool create ecpool erasure myprofile
echo ABCDEFGHI | rados --pool ecpool put NYAN -
rados --pool ecpool get NYAN -
ABCDEFGHI
The NYAN对象将被分成三个（K=3）和两个额外的块将被创建（M=2）。的值M定义了可以同时丢失的 OSD 数量而不会丢失任何数据。的crush-failure-domain=rack将创建一个 CRUSH 规则，确保没有两个块存储在同一个机架中。
更多信息可以在纠删码配置文件 documentation.
使用覆盖的纠删码
默认情况下，纠删码池仅与执行完整对象写入和附加的操作一起工作（例如，RGW）。
自 Luminous 以来，可以通过每个池的设置启用纠删码池的部分写入。这允许 RBD 和 CephFS 将其数据存储在纠删码池中：
ceph osd pool set ec_pool allow_ec_overwrites true
这只能在驻留在 BlueStore OSD 上的池上启用，因为 BlueStore 在深度扫描期间使用校验和来检测位腐或其他损坏。使用 Filestore 与 EC 覆盖不仅不安全，而且与 BlueStore 相比性能较低。此外，Filestore 已弃用，您集群中的任何 Filestore OSD 都应迁移到 BlueStore。
纠删码池不支持 omap，因此要使用它们与 RBD 和 CephFS 一起使用，您必须指示它们将它们的数据存储在 EC 池中，并将它们的元数据存储在复制池中。对于 RBD，这意味着在创建镜像时使用纠删码池作为--data-pool：
rbd create --size 1G --data-pool ec_pool replicated_pool/image_name
对于 CephFS，可以在创建文件系统时或通过文件布局.
纠删码池开销
纠删码池的开销因子（空间放大）是(k+m) / k。对于 4,2 配置文件，开销为 1.5，这意味着 1.5 GiB 的底层存储用于存储 1 GiB 的用户数据。与默认复制size-3相比，开销因子为 3.0。不要将纠删码视为免费午餐：在使用 HDD 时以及在进行集群恢复或回填时，存在显著的性能权衡。
以下是显示各种值的k和m开销因子的表格。随着k增加到 4 以上，增量容量开销收益很快就会遇到递减回报，但性能影响会成正比增长。我们建议您不要选择k> 4 或m> 2 的配置文件，除非您完全理解其影响，包括您的集群拓扑呈现的故障域数量。如果您选择m=1，请在维护期间预期数据不可用，在组件故障重叠时预期数据丢失。因此，具有m=1的配置文件强烈不建议用于生产数据。
必须保持活动状态且在必须承受大量重叠组件故障的情况下避免数据丢失的部署可能更喜欢m> 2 的值。请注意，此类配置文件会导致空间效率降低和性能下降，尤其是在回填和恢复期间。
如果您确定要使用纠删码为一个或多个池，但不确定要使用哪个配置文件，请选择k=4和m=2。与使用size=3进行复制相比，您将获得双倍的可用空间，并且写入和恢复性能影响相对可容忍。
Note
大多数纠删码池部署至少需要k+mCRUSH 故障机架的或`hosts。在规划 EC 配置文件和集群拓扑以使故障域至少为k+m+1的操作方面存在优势。在大多数情况下k> 8 的值是不鼓励的。
Note
CephFS 和 RGW 部署中有很大比例的非常小的用户文件/对象可能需要仔细规划，因为纠删码数据池会导致相当大的额外空间放大。CephFS 和 RGW 都支持具有不同介质、性能和数据保护策略的多个数据池，这可以启用高效和有效的部署。例如，RGW 部署可以为例外的索引和默认桶数据池提供适量的 TLC SSD，并提供更大的纠删码 QLC SSD 或 HDD，通过存储类别、放置目标或 Lua 脚本将较大的和较冷的对象定向到其中。
m=1 |
m=2 |
m=3 |
m=4 |
m=5 |
m=6 |
m=7 |
m=8 |
m=9 |
m=10 |
m=11 |
|
|---|---|---|---|---|---|---|---|---|---|---|---|
k=1 |
2.00 |
3.00 |
4.00 |
5.00 |
6.00 |
7.00 |
8.00 |
9.00 |
10.00 |
11.00 |
12.00 |
k=2 |
1.50 |
2.00 |
2.50 |
3.00 |
3.50 |
4.00 |
4.50 |
5.00 |
5.50 |
6.00 |
6.50 |
k=3 |
1.33 |
1.67 |
2.00 |
2.33 |
2.67 |
3.00 |
3.33 |
3.67 |
4.00 |
4.33 |
4.67 |
k=4 |
1.25 |
1.50 |
1.75 |
2.00 |
2.25 |
2.50 |
2.75 |
3.00 |
3.25 |
3.50 |
3.75 |
k=5 |
1.20 |
1.40 |
1.60 |
1.80 |
2.00 |
2.20 |
2.40 |
2.60 |
2.80 |
3.00 |
3.20 |
k=6 |
1.16 |
1.33 |
1.50 |
1.66 |
1.83 |
2.00 |
2.17 |
2.33 |
2.50 |
2.66 |
2.83 |
k=7 |
1.14 |
1.29 |
1.43 |
1.58 |
1.71 |
1.86 |
2.00 |
2.14 |
2.29 |
2.43 |
2.58 |
k=8 |
1.13 |
1.25 |
1.38 |
1.50 |
1.63 |
1.75 |
1.88 |
2.00 |
2.13 |
2.25 |
2.38 |
k=9 |
1.11 |
1.22 |
1.33 |
1.44 |
1.56 |
1.67 |
1.78 |
1.88 |
2.00 |
2.11 |
2.22 |
k=10 |
1.10 |
1.20 |
1.30 |
1.40 |
1.50 |
1.60 |
1.70 |
1.80 |
1.90 |
2.00 |
2.10 |
k=11 |
1.09 |
1.18 |
1.27 |
1.36 |
1.45 |
1.54 |
1.63 |
1.72 |
1.82 |
1.91 |
2.00 |
k=12 |
1.08 |
1.17 |
1.25 |
1.33 |
1.42 |
1.50 |
1.58 |
1.67 |
1.75 |
1.83 |
1.92 |
k=20 |
1.05 |
1.10 |
1.15 |
1.20 |
1.25 |
1.30 |
1.35 |
1.40 |
1.45 |
1.50 |
1.55 |
纠删码池和缓存层
Note
在 Reef 中，缓存层已被弃用。我们强烈建议不要部署新的缓存层，并努力从现有部署中删除它们。
纠删码池比复制池需要更多资源，并且缺少复制池支持的一些功能（例如，omap）。为了克服这些限制，可以在设置纠删码池之前设置一个缓存层。例如，如果池
For example, if the pool hot-storage由快速存储组成，则以下命令将hot-storage池作为ecpool in 回写模式：如果基础层和缓存层配置为 17bce1 模式，每次 Ceph 客户端向其写入数据时都会从基础层接收一个 ACK。然后缓存分层代理确定 22f3d3 是否已设置。如果已设置并且数据在每个间隔内写入的次数超过指定次数，则数据将提升到缓存层。模式的层：
ceph osd tier add ecpool hot-storage
ceph osd tier cache-mode hot-storage writeback
ceph osd tier set-overlay ecpool hot-storage
结果是，对ecpool的每个写入和读取实际上都使用hot-storage池，并受益于其灵活性和速度。
更多信息可以在缓存层文档中找到。请注意，然而，缓存层已被弃用，并且可能在未来的版本中完全删除。
纠删码池恢复
如果纠删码池丢失任何数据片段，它必须从其他地方恢复它们。这种恢复涉及从剩余的片段中读取、重建数据并写入新的片段。
在 Octopus 和以后的版本中，只要至少有K片段K片段，实际上您已经丢失了数据！）
在 Octopus 之前，纠删码池要求至少有min_size片段可用，即使min_size大于K。这是一个在设计新的池模式时出于谨慎考虑而做出的保守决定。因此，具有丢失 OSD 但没有完全数据丢失的池无法在没有手动干预以临时更改min_size设置进行指数衰减。
的情min_size be K+1 or greater to prevent loss of writes and
loss of data.
术语表
- chunk
When the encoding function is called, it returns chunks of the same size as each other. There are two kinds of chunks: (1) data chunks, which can be concatenated to reconstruct the original object, and (2) coding chunks, which can be used to rebuild a lost chunk.
- K
The number of data chunks into which an object is divided. For example, if K = 2, then a 10KB object is divided into two objects of 5KB each.
- M
The number of coding chunks computed by the encoding function. M is equal to the number of OSDs that can be missing from the cluster without the cluster suffering data loss. For example, if there are two coding chunks, then two OSDs can be missing without data loss.
目录
由 Ceph 基金会带给您
Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.