选择 Ceph 纠删码参数与故障域：从空间倍率到恢复门槛

来源：Ceph 文档贡献者《Erasure code》。所引官方 latest 文档页面明确标注为开发版本文档。涉及 Tentacle 的选项不能直接套用到旧集群；本文未连接 Ceph，也未创建存储池、开启标志或迁移数据。

Ceph 默认创建复制池（replicated）：同一个对象写到多块磁盘，通过多份副本保护数据。纠删码池（erasure-coded，简称 EC）则把数据分成数据块和编码块，在部分块丢失或损坏时由剩余块重建。文档把它们分别称为 data chunks 与 coding chunks；纠删码也是前向纠错编码的一类，原文回溯了 Richard Hamming 于 1950 年在贝尔实验室开发的早期纠错码。

EC 的吸引力是减少大规模存储中的冗余空间。但容量、故障隔离、恢复流量和小 I/O 性能是同一个设计问题，不能只按最小空间倍率选参数。

K、M 与故障域分别决定什么

K 是数据块数量，M 是编码块数量。对文中使用的 Reed–Solomon 类配置，一组数据共有 K+M 个块，任意 K 个有效块即可恢复原数据，最多可以缺失 M 个块。K=2 时，一个 10 KB 对象在理想分割示意中拆成两块各 5 KB 数据块，编码块用于补回缺失块。

“能丢 M 个块”必须与对象的实际放置关系一起解释。只有 CRUSH 规则确实把同一对象的各块分到不同故障域，某个机架或主机的故障才不会一次带走多块。M 不等于“任何 M 次相关故障都绝对不会丢数据”，更不能覆盖介质同时损坏、错误配置和备份缺失的风险。

理论空间倍率为 (K+M)/K。3+2 为 5/3，约 1.67 倍，即额外空间约 67%；4+2 与 6+3 都是 1.5 倍。三副本则为 3 倍。该公式没有包含所有元数据、索引、小对象填充、分配粒度与运维预留。

Ceph 官方文档还列出 K=1–12、20 与 M=1–11 的完整理论空间倍率矩阵。下表保留原表全部数值；各值按官方文档所列精度呈现，仅用于容量关系比较，不构成部署建议。

先读取实际 profile，再创建池

原文首先给出 ceph osd pool create ecpool erasure，并将最简单 EC 池描述为至少三台主机。但后面列出的默认 profile 是 2+2、host 故障域，需要至少四个不同 host。这两件事不能连在一起直接照抄。

ceph osd erasure-code-profile get default

原文展示的结果为：

k=2
m=2
plugin=isa
crush-failure-domain=host
technique=reed_sol_van

最简单的 2+1 与默认的 2+2 不是同一种池。本文的修订是：明确查询当前配置，并在建池时显式指定 profile。生产数据不宜采用 M=1；维护期间容易不可用，故障重叠时容错余量也很低。

下面沿用原文的 3+2 机架示例，但给它独立名称。执行前必须已建立正确的 rack 拓扑，至少有五个符合规则的机架故障域，通常应规划第六个或更多域以便恢复。这些是会改变集群状态的参考命令，本轮仅静态审查：

ceph osd erasure-code-profile set wwj_k3m2_rack     k=3     m=2     crush-failure-domain=rack

ceph osd pool create wwj_ec_demo erasure wwj_k3m2_rack

原文用对象 NYAN 展示写入和读回字符串。下面只作为授权实验池的示意，put 会覆盖同名对象，必须先确认名称未被业务使用：

printf '%s\n' 'ABCDEFGHI' | rados --pool wwj_ec_demo put WWJ_DEMO_NYAN -
rados --pool wwj_ec_demo get WWJ_DEMO_NYAN -

原文的读回内容为 ABCDEFGHI。此处改名并把 echo 改为确定格式的 printf，没有实际执行，也没有声称本稿已读回成功。K=3 表示原始对象分成三个数据块，再生成 M=2 个编码块；rack 规则应保证两块不会放在同一机架。

哪些参数创建后不能改，哪些能通过 CRUSH 调整

池的 EC 编码参数不能原地改成另一套 profile。若创建后发现 K、M 或编码选择不合适，需要创建新池并迁移对象。迁移不是简单修改配置项，必须另行设计客户端切换、校验与回退。

故障域有一个例外：可以为池切换 CRUSH 规则，从而改变实际放置使用的故障域。官方要求新旧规则除故障域外保持一致：

# 仅说明命令结构；先核对目标池和预先审查的规则
ceph osd pool set <pool-name> crush_rule <rule-name>

切换后，ceph osd pool ls detail 仍可能显示最初的 EC profile，其中记录的是旧故障域；真正生效的是新 CRUSH rule。profile 中的 crush-failure-domain 主要用于最初创建规则，不能只看旧 profile 判断现状。修改规则会影响放置和数据迁移，不能把它视为无代价操作。

覆盖写入：数据池和元数据池要分开

默认情况下，EC 池主要支持完整 RADOS 对象写入，例如 RGW 常见的使用方式。自 Luminous 起，可以逐池启用部分覆盖写，使 RBD、CephFS 和 librados 可以把数据存入 EC 池：

ceph osd pool set ec_pool allow_ec_overwrites true

此功能要求池位于 BlueStore OSD。BlueStore 的校验和参与深度 scrub，用于发现位腐败和其他损坏。官方明确指出，在 FileStore 上使用 EC 覆盖写不安全且性能更差；FileStore 也已弃用，应迁移至 BlueStore。原文把在适用池上启用覆盖写列为惯例，但执行前仍须确认本池的 OSD 后端与部署版本。

RBD 和 CephFS 并不是把所有内容都放进 EC 池：数据可以放 EC 池，元数据仍需复制池。RBD 创建镜像时，以复制池保存镜像元数据，通过 --data-pool 指定 EC 数据池：

rbd create --size 1G --data-pool ec_pool replicated_pool/image_name

这条命令会创建镜像，名称和两个池都必须提前核验。CephFS 则可在创建文件系统时设置 EC 默认数据池，或通过文件布局选择数据池。EC 默认不支持 omap 等能力，不能把元数据池替换成 EC 来追求容量。

Tentacle 的 EC 优化标志与条带单元

从 Tentacle 起，官方引入逐池优化标志，改进小 I/O，并消除填充，从而减少空间放大：

# 不可撤销的池格式相关开关，仅供变更评审参考
ceph osd pool set ec_pool allow_ec_optimizations true

开启后不能关闭。它改变新数据的存储方式。所有 Monitor 和 OSD 必须升级至 Tentacle 或更高版本才能设置；网关和客户端不要求同时升级。现有池可以启用，也可通过 osd_pool_default_flag_ec_optimizations 设置新池默认行为。当前文档只支持 Jerasure 与 ISA-L 插件配合 reed_sol_van，不支持的插件与 technique 组合会被拒绝。

这类优化更适合 RBD、CephFS，以及含大量小对象或随机小读取的 RGW。若 RGW 主要顺序读写大对象，收益可能很小。这些是文档给出的适用判断，本稿没有自行完成基准测试。

默认 stripe unit 为 4K，适合常规 EC 池。原文基于其性能测试建议：启用优化时，通用 I/O 通常选至少 16K；更大的条带单元会改善小读取，却可能降低小型顺序写入的性能。读多的负载可考虑增至 256 KB，超过 256 KB 通常没有额外收益。这不是所有硬件上的保证。

stripe unit 是建池时的参数，可在 EC profile 或中央配置 osd_pool_erasure_code_stripe_unit 中设置，创建后不能修改。因此给旧池开启优化并不意味着能获得与新建、重新选过条带单元的池相同的全部收益。

未启用优化时，K、M 越大通常性能代价越高。启用后，增加 K 的代价在原文测试中明显减轻，但增加 M 仍影响写入，尤其是小写入；文档对块和文件负载建议 M 不大于 3。选择前要同时考虑容量、写入和恢复。

容量收益必须与运行余量一起计算

4+2 的理论倍率是 1.5，相比三副本能容纳约两倍用户数据，但 EC 不是无代价压缩。HDD、回填和恢复期间的性能代价尤其值得关注。K 超过 4 后，每增加一个数据块带来的空间改善趋于递减；原文建议在充分理解影响前不要贸然选择 K>4 或 M>2，并通常不鼓励 K>8。

原文为不确定配置的读者列出 4+2 或 6+3，作为空间和恢复代价的折中起点；这必须与故障域数量及负载适配，不能解释成所有集群的通用最优值。若需要承受更多重叠故障，M>2 可能合理，但会牺牲容量效率和性能。

多数部署至少需要 K+M 个 CRUSH 故障域，规划 K+M+1 个通常更有利于运维。满足最小数量只是能够放置，预留额外域与空闲容量才使丢域后的重建有位置可去。

大量很小的 CephFS 文件或 RGW 对象可能产生额外空间放大。它们都支持多个数据池，可按介质、性能和保护方式分流。原文举例：使用少量 TLC SSD 组成复制的索引池及默认桶数据池，使用更大规模的 EC QLC SSD 或 HDD 承接大而冷的对象，通过存储类、placement target 或 Lua 脚本路由。

缓存分层是历史方案，不能继续作为新部署建议

原文保留了用快池 hot-storage 为 ecpool 建立 writeback 缓存层的历史段落，其目的曾是借助复制快池弥补 EC 的部分能力与性能限制。该方案涉及 ceph osd tier add、cache-mode writeback 与 set-overlay，使访问先经过缓存池。

同一页面明确说明 cache tiering 自 Reef 起弃用，建议不再建立新缓存层，并逐步移除现有部署。因此本文保留历史背景与命令名称，不提供可直接粘贴的新建步骤。不能为了补齐 EC 的 omap 或小写性能而继续采用这项弃用路径。

可恢复不等于可安全继续写

丢失数据分片后，恢复过程需要从剩余分片读取、解码并写出新分片。Octopus 及更高版本，只要至少 K 个分片可用就可以恢复；少于 K 则无法按这套编码重建完整数据。

Octopus 之前，恢复曾要求至少有 min_size 个分片，即便 min_size 大于 K。这种保守设计导致某些数据还可恢复的池无法自动恢复并变为 active，需要人工临时调整门槛。

不要因此把生产池的 min_size 一律降到 K。原文建议设置为 K+1 或更高，避免写入或数据丢失。K 是解码所需的数学下限，min_size 是运行时保护决策的一部分，两者目的不同。每个实际变更都需要结合当前故障、可用分片、版本和恢复余量单独判断。

来源与署名：Ceph 文档贡献者，Ceph Documentation 由 Ceph Foundation 支持。本文补充了目标版本、显式 profile、对象覆盖和不可逆开关边界，并指出原始文档中三主机简例与默认 2+2 profile 的不同。该页面未标注单页许可；Ceph 项目的公开说明对文档许可存在差异，复用前应按文件与目标版本核对。示意图由未完纪编辑原创绘制，并非集群截图或实测结果。本文译文与原创示意图依据另行取得的授权用于本次发布；此说明不为源文或后续复用授予开放许可。