This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
本 SPEC 描述了使用纠删码改进全球集群的效率。它提出了一种方法，可以在超过 1 个区域的纠删码情况下提高 PUT/GET 性能，即使某个区域丢失也能确保原始数据。
Swift 现在支持纠删码 (EC)，与单区域集群相比，EC 可以确保更高的持久性和更低的磁盘成本。但是，如果 Swift 在 2 个区域上运行 EC，使用小于 2 倍数据冗余度（例如 ec_k=10, ec_m=4），并且由于某些不幸的原因（例如大地震、火灾、海啸）导致其中一个区域丢失，则数据可能会丢失。这是因为，假设每个区域都有大致相等的可用磁盘容量，每个区域应该有大约 7 个碎片，少于 ec_k，这不足以让 EC 方案重建原始数据。
为了保护存储的数据并确保更高的持久性，Swift 必须为每个区域保留 >= 1 个数据大小（即 >= 2 倍用于 2 个区域），通过使用更大的 ec_m（例如 ec_k=10 的 ec_m=14）来实现。然而，这种增加会牺牲编码性能。在我的测量中，在 Intel Xeon E5-2630v3 [1] 上运行 PyECLib 编码/解码，基准测试结果如下
| 方案 | ec_k | ec_m | 编码 | 解码 |
|---|---|---|---|---|
| jerasure_rs_vand | 10 | 4 | 7.6Gbps | 12.21Gbps |
| 10 | 14 | 2.67Gbps | 12.27Gbps | |
| 20 | 4 | 7.6Gbps | 12.87Gbps | |
| 20 | 24 | 1.6Gbps | 12.37Gbps | |
| isa_lrs_vand | 10 | 4 | 14.27Gbps | 18.4Gbps |
| 10 | 14 | 6.53Gbps | 18.46Gbps | |
| 20 | 4 | 15.33Gbps | 18.12Gbps | |
| 20 | 24 | 4.8Gbps | 18.66Gbps |
请注意，“解码”使用 (ec_k + ec_m) - 2 个碎片，因此性能下降的幅度小于编码时，如上述结果所示。
在上述结果中，比较 ec_k=10, ec_m=4 与 ec_k=10, ec_m=14，编码性能下降了大约 1/3，其他编码也遵循类似的趋势。这表明在构建 2+ 区域 EC 集群时存在问题。
1: http://ark.intel.com/ja/products/83356/Intel-Xeon-Processor-E5-2630-v3-20M-Cache-2_40-GHz
添加一个类似于“duplication_factor”的选项。它将创建重复（复制）的碎片，而不是采用更大的 ec_m。
例如，如果 duplication_factor=2，Swift 将编码 ec_k=10, ec_m=4，并在 Swift 中存储 28 个碎片（10x2 个数据碎片和 4x2 个奇偶校验碎片）。
这需要在 PUT/GET 和重建序列中进行更改，以将 Swift 中的碎片索引映射到 PyECLib 的实际碎片索引，但恕我直言，我们不需要努力构建对代理服务器 <-> 对象服务器 <-> 磁盘之间通信的过多修改。
我不想在 SPEC 的第一个补丁中详细描述实现，因为它应该是一个改进 Swift 的想法。后续补丁中将对实现方面进行更多讨论。
这些重复碎片的放置非常重要。如果相同的碎片（原始碎片和复制碎片）出现在同一区域，并且第二个区域发生故障，那么我们将处于与较小的奇偶校验碎片情况相同的情况，即无法重建原始对象。
例如：
在这种情况下，第 1 区域只有碎片索引为 0、1、2 的碎片，第 2 区域只有 3、4、5。因此，无法仅从一个区域的碎片中重建原始对象，因为该区域的碎片唯一性小于 k。最坏的情况，例如这种情况，将导致与没有复制因子时发生的情况一样严重的数据丢失。
即，事实上，数据持久性将是
在未来的工作中，我们可以找到一种方法将碎片索引与区域关联起来，例如“第 1 个子集应该在第 1 个区域，第 2 个子集应该……”但到目前为止，这超出了本 SPEC 的范围。
我们可以找到一种方法使用 container-sync 作为解决问题的方案，而不是采用我提出的更改。本节将描述我的“提议的更改”和“container-sync”的优缺点。
优点
缺点
优点
缺点
无