CubeFS技术揭秘 ｜ 多AZ纠删码容灾技术
I. 引言
背景及意义
多AZ容灾是指在云计算环境中，将应用程序和数据部署在多个可用区（Availability Zone，简称AZ）中，以实现高可用性和容灾能力。在云计算环境中，由于单个AZ可能出现故障或不可用，因此将数据部署在多个AZ中可以提高系统的可用性和容灾能力，保证业务的连续性、稳定性。通过将数据部署在多个AZ中，可以实现数据备份和恢复，保证数据的安全性和完整性。另外在云计算环境中，用户对系统的可用性和稳定性要求越来越高。通过多AZ容灾技术，可以提高系统的可用性和稳定性，提高用户体验和满意度。
本文主要内容
本文主要介绍CubeFS纠删码子系统Blobstore的AZ级容灾方案。由于多副本模式存储成本高效率低、多AZ情况下网络带宽消耗很大、且需要及时保证数据一致性等劣势，我们接下来只讨论纠删码（Erasure Coding）存储模式。Blobstore使用纠删码技术将用户数据编码计算并持久化存储于多个AZ中，以实现高可用性和容灾能力。主要包括多AZ的EC计算原理，及如何保持高可用地写入、高效读取、减少跨AZ的数据恢复。关于EC数据的可靠性公式，在此就不赘述，可以参看我们相关的文章。
II. 技术原理
基本概念
可用区（AZ）
在云计算环境中，将数据中心划分为多个区域，每个区域都拥有独立的电力、网络和物理设施，以实现高可用性和容灾能力，对外提供相似于用户本地的云服务。
纠删码（EC）
EC是一种数据冗余编解码技术，它通过将数据进行分块并生成多个编码块，并将这些编码块分别存储在不同的存储节点上，以实现数据的高可用性和容灾能力。正是因为EC的这种冗余度特性才能在低成本高效率的存储成本下实现多AZ的容灾能力。
容灾能力
容灾是指多AZ的数据中心允许某一个AZ或多个AZ不可用，甚至不可用的AZ完全无法为数据恢复提供任何帮助。不同AZ数、冗余度、容灾能力简单关系图如下所示：
| 数据中心AZ数 | 容灾能力 | 数据最低冗余度 |
|---|---|---|
| 1 | 0 | 1 |
| 2 | 1 | 2 |
| 3 | 1 | 1.5 |
| 3 | 2 | 3 |
| 4 | 1 | 1.333... |
| 4 | 2 | 2 |
| 4 | 3 | 4 |
表1
多AZ优缺点
- 优点：
- 高可用性：当某个AZ出现故障或不可用时，系统中其他AZ不受任何影响，以保证数据的连续性和稳定性。
- 容灾能力：当某个AZ出现灾难性无法恢复的故障时，保证数据的安全性和完整性。
- 冗余度：在高可靠性的前提下，可提供更低冗余度的存储能力，较低成本。
- 缺点：
- 存储成本：由表1可知，要获取更好的容灾能力，数据冗余度必须成倍提升，本质上和成本效率出现了冲突，所以我们一般只讨论一个AZ的容灾情况。
- 扇入扇出问题：多可用区需要生成有限制的相适编码块，在写入和读取时都需要连接多个数据节点，因此需要更多的计算资源，增加了网络带宽消耗。
III. 技术实现
写入
图1，AZ=3，EC（12，9），LRC（12，9，3）
- 无AZ故障时，写入Quorum 在数据编码写入时，我们不把LRC中的局部数据块当作有效数据，因为在某些场景下局部数据块对数据恢复没有作用（如图1中AZ-3的 L31 对数据恢复没有帮助）。
数据写入最小的Quorum = D +（D+P）/ AZ = 12+（12+9）/ 3 = 19；在极端情况下要保证一个AZ的容灾能力，EC（12，9）模型最多只能允许2个有效数据块写入失败，不然在AZ故障时可能出现数据丢失（如图1中AZ-3故障）。
在实际生成中，AZ故障发生概率极低，可以适当把写入Quorum调小，消除部分长尾效应，提升用户体验。
- 某个AZ故障无法写入 如果当前已经出现了某个AZ无法写入，为了保持系统连续性，数据写入依然会成功。这时已经无法满足数据写入的最小Quorum，则必须保证其他AZ有效数据全部写成功（如图1AZ-3故障时，需要写入AZ-1、AZ-2的全部14份有效数据），并在故障AZ恢复后尽快启动数据恢复流程。
读取
- 修复读：由于单AZ内没有足够的数据块，该场景必须跨AZ读取相应数据块完成EC恢复；跨AZ数据流量 = DataSize *（1 - （N+P）/ AZ / N）= DataSize * 5/12。
- Range读：当Range读较小数据（需读取数据小于数据块）时，直接去对应AZ的相应数据块读取，避免有扇出的数据恢复浪费AZ间带宽；在对应数据块损坏时，可读足够有效数据块的部分数据作修复读流程。
修复
- RS码：普通EC数据恢复的跨AZ带宽如上述的修复读。
- LRC：在一个EC组中，损坏一个数据块的几率要远大于损坏多个数据块的几率。如果能够及时发现坏块，那么多数情况下只需要恢复一块就够了。这时启用LRC就可以在本AZ内完成数据恢复，避免跨AZ的带宽和IO消耗。
- AzureLRC+1：在Azure LRC的基础上对全局校验块也生成局部校验块，配合一定的放置策略，从而实现更好的修复表现；可以在极端情况下（单AZ故障+额外单块故障）系统仍拥有修复数据的能力。
小文件优化
图2， 1K 实际数据的EC布局
在纠删码中小文件的扇入扇出问题尤为突出，极大影响小文件的读写效率；对此我们规定EC的每个数据块有最小数据大小，且可根据情况定义数据块大小值（比如4K）。当实际数据不足 D*4K时用0补齐，编码写入到各AZ。以图2为例讨论该优化项的优势：
- 文件系统一般都以4K为一个Block大小。
- 读取时可直接读第一个D数据块；也可从任一个P走恢复读流程；减少IO路径且不消耗跨跨AZ带宽。
- 数据损坏时，可从任一个校验块恢复数据。
- 数据冗余度提升至 （P+1），提高了可靠性。同时也浪费了部分空间，但在云计算场景中，小文件的性能要求比存储成本更高，用空间换时间的思想很好地解决了该问题，使存储抽象层更加统一完善。
VI. 参考文献
【1】Erasure Code