What’s the Story in EBS Glory: Evolutions and Lessons in Building Cloud Block Store——论文泛读

FAST 2024 Paper 论文阅读笔记整理

本文工作

在本文中，定性和定量地讨论了过去十年在阿里巴巴云上构建弹性块存储（EBS）的设计选择、生产经验和教训。为了应对硬件的进步和用户的需求，我们将重点从EBS1的简单设计转移到EBS2的高性能和空间效率，并最终减少EBS3的网络流量放大。

EBS1的关键设计：从虚拟磁盘（VD）到物理磁盘的原地更新；对虚拟磁盘的独占管理。EBS1直接将虚拟机（VM）内的VD映射为后端存储服务器中的一系列64MiB-Ext4文件。EBS1采用一组无状态区块服务器来管理虚拟磁盘，其中每个虚拟磁盘都由区块服务器独家处理。但局限性是直接的虚拟化导致了严重的空间放大和性能瓶颈。

EBS2的关键设计：日志结构设计；VD分段。使用Pangu[35]分布式文件系统作为存储后端，并重新设计了BlockServer，以将VD的所有写入转换为顺序附加。通过切换到日志结构布局，EBS2仍然对写入使用三副本复制，但可以在垃圾收集（GC）期间在后台透明地执行数据压缩和擦除编码（EC）。EBS2将VD划分为更精细的分段（每段32 GB），从而将虚拟磁盘和块服务器之间的映射从虚拟磁盘级别转移到分段级别。通过以上两种变化，EBS2能够将空间效率从EBS1中的3（三副本复制）降低到平均1.29。此外，配备SSD的EBS2-backed VD可实现1M的IOPS和4000 MiB/s的吞吐量，平均延迟为100μs级。但EBS2面临流量放大因子增加到4.69，即3（前台复制写入）加1（后台GC读取）和0.69（后台EC/压缩写入）。

EBS3的关键设计，使用在线（即前台）EC/压缩来减少流量放大：融合写入引擎（FWE）和基于FPGA的硬件压缩。FWE聚合来自不同段的写入请求，以满足EC和压缩的大小要求。EBS3将计算密集型压缩卸载到定制的FPGA以进行加速。因此，EBS3将存储放大因子从1.29降低到0.77（压缩后），并将流量放大因子从4.69降低到1.59，同时仍然保持与EBS2类似的性能。

将开发经验总结为四个主题，包括：

1. 在延迟、吞吐量、IOPS和容量方面实现高弹性。云块存储的一个代表性特征是弹性，为VD提供不同的性能和容量水平，关键是：确定边界和实现细粒度调优。我们发现平均延迟和尾部延迟分别由不同的因素决定——硬件开销和软件处理。因此，构建了EBSX，一种由持久内存支持的单跳架构，用于最小化平均延迟；使用I/O专用线程来减轻尾部延迟。此外，吞吐量和IOPS受类似机制的限制。在前端BlockClient中，通过将处理从内核转移到用户空间，然后在FPGA中进行硬件卸载来优化堆栈。在后端BlockServer中，利用高并行度实现高效的吞吐量/IOPS控制。

2. 通过最小化单个、区域和全球故障事件的爆炸半径来提高可用性。首先对三个级别的故障事件进行分类，包括单个、区域和全局故障事件，这些故障事件可能导致集群中的一个、多个或所有VD（暂时）停止服务。随着VD分段和段迁移，现场诊断表明区域事件变得更加频繁，单个事件现在可以很容易地级联为区域甚至全球事件。因此，在控制平面上，我们开发了联合块管理器将VD组织成小型组，并使用控制管理器进行协调。在数据平面上，我们构建了逻辑故障域，以限制段迁移的目的地。

3. 识别各种硬件卸载解决方案中的动机和关键权衡。以BlockClient和BlockServer的卸载演变为例，讨论不同选项之间的权衡。BlockClient从FPGA卸载开始，以加速存储/网络虚拟化。受大规模部署下FPGA不稳定性的影响（22%的停机时间由FPGA相关问题引起），BlockClient放弃了基于FPGA的方法，采用了基于ASIC的解决方案。BlockServer最初也选择FPGA来加速EC/压缩，但由于灵活性和成本要求，选择了多核ARM CPU作为后续方法。

4. 确定备选解决方案的利弊，并解释为什么看似有希望的想法在实践中行不通。为什么使用日志结构存储，为什么不用开源软件，为什么与盘古分布式文件系统分离。

总结

对生产环境中的阿里EBS的设计进行总结。EBS开发的三个阶段：EBS1，虚拟磁盘（VD）到物理磁盘原地更新，对虚拟磁盘的独占管理；EBS2，日志结构设计，VD分段；EBS3，使用在线EC/压缩来减少流量放大，融合写入引擎（FWE）和基于FPGA的硬件压缩。

总结开发过程中的经验教训：（1）在延迟、吞吐量、IOPS和容量方面实现高弹性。构建了EBSX，由持久内存支持的单跳架构，最小化平均延迟。使用I/O专用线程来减轻尾部延迟。在前端BlockClient中，将处理从内核转移到用户空间，在FPGA中进行硬件卸载来优化堆栈。在后端BlockServer中，利用高并行度实现高效的吞吐量/IOPS控制。（2）最小化单个、区域和全球故障事件的爆炸半径来提高可用性。开发了联合块管理器将VD组织成小型组，并使用控制管理器进行协调。在数据平面上，构建逻辑故障域，以限制段迁移的目的地。（3）识别各种硬件卸载方案的动机和权衡。BlockClient从FPGA卸载开始，转向基于ASIC的解决方案。BlockServer最初选择FPGA来加速EC/压缩，转向多核ARM CPU作为后续方法。