Luminous 现在完全支持覆盖写纠删码(EC) RADOS池，允许RBD和CephFS(以及RGW)直接使用纠删码池。这可能会显着地降低Ceph系统每兆字节的总成本，因为通常的3副本存储开销可以减少到大约1.2倍到2倍，这取决于纠删码算法的选择
背景
Ceph RADOS对象存储最初是围绕多副本(通常是2x或3x)构建的。实现起来相对简单(尽管在CP分布式系统中仍然很难实现)，并在一段时间内为我们提供了良好的服务。随着Firefly版本发布(2014年5月)，增加了对纠删码(EC)池的支持。纠删码允许Ceph 在k个 OSDs上的对象数据进行条带化。用编码的冗余信息添加m个附加块。这类似于传统RAID系统中的奇偶校验，但纠删码通常泛化到几乎任何k和m值，而RAID 5则修正m=1和RAID 6修正m=2。Ceph的纠删码是通过插件实现的，这些插件包括传统的Reed-Soloman库(为Intel和ARM架构进行了优化)、本地重构代码(LRC)插件和SHEC shingled 纠删码。
然而，到目前为止，EC池只允许对象追加和删除-不支持覆盖。这允许EC池用于RGW对象存储，并作为复制缓存层后面的冷层存储使用，但RBD和CephFS不能直接使用EC池。考虑到纠删码能够大大降低了系统每千兆字节的总成本，这种不支持对许多用户来说并不令人满意。
失败后的一致性
造成这一限制的原因是很难保持一致性，Ceph一直非常关注这个问题。如果在更新被复制的对象时发生了故障，那么无论对象的新版本或旧版本最终得到多少副本或副本，恢复都是很简单的。在上面的示例中，一个对象的三个副本最初包含内容“。在RADOS中，三个副本中只有两个被更新。我们可以将第三个副本前滚到B，也可以将前两个副本滚回A；在RADOS中，这两种选择都将使系统保持一致。更新后，这两个选项都可以(我们目前正在前滚)。
如果是纠删码对象，情况要复杂一些，而不是对象的三个相同和完整的副本，而是将内容分散到四个对象上(在上面的例子中)，每个对象有1/4的数据，两个纠删码对象p和q。如果在更新过程中失败，只有三个“A”对象被更新为新的对象。“B”内容，我们有一个问题：4+2 EC需要任何4个碎片来重建原始内容，但是我们只有三个新的和三个旧的，因此两者都不能重建。这个基本问题是所谓的“RAID Hole”的一个广义版本。许多系统(即使是在生产中广泛使用的系统)都把这个问题掩盖了起来，而且大多数时候他们都能解决这个问题，通常是因为在系统崩溃之前提交书面文件的人仍然会在那里再次提交并解决这个问题，从来没有发现这一选择是可以接受的。
为了从这种情况中恢复过来，RADOS必须能够在更新之前将B1、B2和B3对象滚回其先前的状态，以便恢复系统的一致性。对于现有的纠删码池，只允许追加，这意味着可以通过截断新内容来回滚。然而，到目前为止，还可以维护回滚信息。实现数据覆盖的成本是非常高的：需要读取旧内容，将其写入临时位置，然后写入新内容，然后(在确定所有碎片应用了更新之后)丢弃临时回滚数据。最后，使用Blue Store，我们可以自由地实现我们需要的低级原语。磁盘上将要覆盖的块，逻辑上用新数据覆盖它(将新内容写入新位置)，然后丢弃旧的引用。最终的结果是，在失败后，任何部分应用的更新都可以回滚，以便存储在RADOS中的数据始终处于一致状态。
创建支持覆盖写的EC池
创建一个EC池的工作原理与以前一样。首先，您需要决定要使用什么样的纠删码算法。这通常意味着选择您的值k和m。m值控制在丢失数据之前可以容忍多少失败。一般来说，m=2将提供3x复制提供的相同级别的数据保护。K值决定每个对象的数据将被条带化多少个OSD。k的较大值意味着较低的存储开销(因为您需要为存储的用户数据的每k个字节存储km字节)，但较大的值也意味着任何写入(和许多读取)都需要与更多的设备通信，从而增加了延迟。
在这个例子中，我们将创建一个可以与RBD一起使用的EC池，我们选择k=4和m=2，这意味着我们的存储开销是1.5倍(是3x复制成本的一半，耶！)，但是我们没有在每个IO中涉及太多的OSD。
首先，我们创建我们的EC配置文件，我们称之为“ec-42-profile”，它还指定了我们想要使用的故障域和CRUSH设备类。(指定一个设备类是发光技术中一个可选但方便的新特性。)
ceph osd erasure-code-profile set ec-42-profile k=4 m=2 crush-failure-domain=host crush-device-class=ssd osd erasure-code-profile set ec-42-profile k=4 m=2 crush-failure-domain=host crush-device-class=ssd创建EC池：
ceph osd pool create ec42 64 erasure ec-42-profile osd pool create ec42 64 erasure ec-42-profile然后
设置EC池支持覆盖写overwrites（使得EC池可以被RBD和CephFS使用）
ceph osd pool set ec42 allow_ec_overwrites true osd pool set ec42 allow_ec_overwrites trueRBD使用EC池
使得ec42存储池可以被rbd使用
ceph osd pool application enable ec42 rbd osd pool application enable ec42 rbdRBD可以将镜像数据存储在EC池中，但是镜像头和元数据仍然需要放在多副本池中。
rbd create rbd/myimage --size 1T --data-pool ec42 create rbd/myimage --size 1T --data-pool ec42然后，像任何其它镜像一样使用，除了所有数据将被存储在“ec42”池中而不是“rbd”池中。
请注意，客户端必须使用Luminous版本LibRBD（或较新版本）版本；
较早版本的Ceph（例如，Jewel）不支持数据池功能。
CephFS使用EC池
使得ec42存储池作为cephfs的数据池
ceph osd pool application enable ec42 cephfs osd pool application enable ec42 cephfs然后将其作为文件系统的数据池添加，假设您使用的是“default”文件系统
ceph fs add_data_pool default ec42 fs add_data_pool default ec42然后，您可以标记应该存储在新池中的特定目录。例如，如果CephFS被挂载在/ceph上，并且希望使用“ec42”池存储/ceph/logs中的所有内容，
setfattr -n ceph.dir.layout -v pool=ec42 /ceph/logs -n ceph.dir.layout -v pool=ec42 /ceph/logs这将导致在/ceph/logs中创建的任何新文件(或该点下的任何子目录)将数据放置到EC池中。
RGW使用EC池
从Firefly版本开始，开始支持RGW对象数据使用EC池。这个过程和以前没有什么不同。
唯一要注意的是，没有必要在RGW数据池上启用覆盖(尽管这样做不会对任何事情造成伤害)。
有多快？
和往常一样快，视情况而定
如果将大量数据写入大对象，EC池通常比多副本池更快：写入的数据较少（只提供了1.5倍，而对于多副本池是3X）。然而，OSD进程消耗的CPU比以前多很多，所以如果服务器慢了，可能无法实现任何加速。大容量或流式读取的性能与以前一样。
然而，小IO写比多副本池慢，主要有两个原因。
- 首先，所有的写入都必须更新完整的条带（所有K+M OSDs），它通常比在我们上面的示例中有更多副本的OSD（6比3）。这样会增加等待时间。
- 第二，如果一个写只更新一部分的条带，我们需要读取前面的条带值（来自所有K+M OSDs），进行更新，重新编码，然后再次写入更新的碎片。出于这个原因，我们倾向于使条带非常小的默认情况下（交易一些CPU开销的一个较低的部分条纹更新的可能性），但问题并不总是消失。有几个系统在这个问题上撒了不同程度的聪明，以延缓条纹更新或避免触摸不变碎片，但我们还没有实现任何复杂的这里。
像往常一样，你应该在工作量上尝试一下，看看效果如何！
约束
在Librados级别上，EC池看起来就像多副本池，因此CephFS和RBD几乎不需要任何更改才能从这个特性中获益。唯一的例外是RADOS对象的“OMAP”部分(允许您在每个对象中存储任意键/值数据)不受EC池的支持。属于普通多副本池，但具有特殊的“数据池”属性-RBD标头对象使用OMAP，不能驻留在EC池中。
摘要
纠删码是减少容错设备故障所需的总体存储开销的重要工具，到目前为止，纠删码只能与RGW一起用于对象存储，但从Luminous版本开始也可以用于RBD和CephFS工作负载。