泉眼无声惜细流
树阴照水爱晴柔
前言
最近阅读了两篇EBS(Elastic Block Storage)相关的材料，分别阐释了阿里云和AWS EBS的变迁。EBS作为云时代存储基础设施建设，阿里云和AWS在迭代过程中遇到过类似的痛点，因而也提出了类似的解决方案。当然，由于各自情况的差异，两者也有不同之处，因而本文记录一些两者异同。
阿里云EBS
阿里云EBS的发展已经有10+年的历史，经历EBS1到EBS3的迭代，逐步从设计简单可用到注重高性能和高空间使用效率。下表为EBS各版本引入的关键技术和痛点：
| 关键技术 | 痛点 | |
|---|---|---|
| EBS1 | 网络TCP；存储HDD；存储-计算集群分离；磁盘虚拟化映射到物理磁盘；VD被独占管理 | 空间利用率低；性能瓶颈；热点问题 |
| EBS2 | 网络Luna；存储SSD；VD分段；日志结构设计；引入pangu；后台GC阶段数据压缩和擦除编码（EC） | 流量放大；级联故障 |
| EBS3 | 网络Solar；存储SSD；使用在线（即前台）EC/压缩来减少流量放大；融合写入引擎（FWE）和基于FPGA的硬件压缩；引入Logical Failure Domain来控制级联故障 | 集群管理服务器单点故障问题；FPGA故障率 |
| EBSX | 网络Solar；存储PMem+SSD；替换FPGA为ARM CPU；引入联合集群管理服务器 |
EBS1
EBS1使用内核态TCP协议栈，并且由于依然使用HDD，性能非常受HDD影响，因为HDD的工业设计，其天然对于随机读写的表现不佳。并且在EBS1中，每个Virtual Disk实际上由专门独立的Block Sever进行独占式管理，因此每个VD的性能完全取决于其对应的Block Server，很容易形成单点过热的问题。EBS1还将VD的逻辑地址直接映射到存储集群内的磁盘的物理地址上，因而导致没法直接进行数据压缩和应用擦除编码（EC），只能维持3份数据拷贝，磁盘空间利用率很低。因而为了解决这些问题，阿里云推出了EBS2。
EBS2
EBS2使用定制化的用户态TCP协议Luna来实现零拷贝内存模型和减少网络I／O时的用户态，内核态切换和数据传输，获取了更高的吞吐量和性能。并且EBS2全面拥抱SSD来摆脱HDD的性能瓶颈。EBS2还将VD分段为更小的数据分段，并将这些数据分段与Block Server进行映射，从而解决了单个Block Server称为性能瓶颈和单点过热问题。为了提升空间利用效率，EBS2在后台GC阶段对数据进行压缩和EC。由于EBS2不再像EBS1一样自己处理数据持久化问题而是依托于pangu，因此不必再维护VD到物理磁盘的映射，所以压缩和EC算法的应用得以实现。但是由于在后台GC阶段进行数据压缩和EC，使得本来只要写三份数据的请求流量放大为三份原始数据的写入流量加上后台数据的压缩和EC流量，放大了流量。因此，EBS3应运而生。
EBS3
EBS3使用定制化的UDP协议Solar，并利用阿里与的特殊数据处理单元（DPU）上的硬件卸载功能，Solar可以将每个存储数据块打包为网络数据包，从而实现 CPU/PCIe 绕过、方便的接收端缓冲区管理和快速的多路径恢复。EBS3通过使用融合写入引擎（Fusion Write Engine，FWE）来合并小写入操作，并采用FPGA卸载压缩计算，实现了在线（前台）擦除编码/压缩，因而解决了流量放大的问题。
EBSX
因为SSD依然不够快，因此EBSX实验性地使用PMem直接越过磁盘I／O获得了极致的性能提升。并且由于FPGA的高故障率和迭代成本，阿里云还是选择了多核ARMCPU作为存储端server的CPU。
根据他们的经验，FPGA无疑是许多硬件卸载场景的首选，因为其具有高灵活性和竞争性的性能。我们也在BlockClient和BlockServer中都采用了FPGA作为概念验证。然而，频繁的错误和高昂的资本支出（CapEx）让我们意识到FPGA可能不是大规模存储系统的理想加速选项。
其次，ASIC和ARM都适用于计算到存储的架构，但方式不同。计算端由于规模庞大且成本敏感，具有稳定的操作符，如处理和转发（如加密），这与ASIC的特性相匹配。而存储后端可能经常需要升级（如改进垃圾收集算法和优化ZNS SSD的主机FTL）并优先考虑任务之间的低干扰。因此，多核ARM CPU成为了一个合适的选择。
AWS EBS
AWS EBS由简单的共享硬盘驱动器HDD的产品发展为一个每日执行超过140万亿次操作的大规模网络存储系统，其成就令人赞叹。但这些成就并非一蹴而就，而是通过不断的递进式的迭代取得的。以下为AWS EBS技术层面的一些演变：
硬盘
在AWS EBS首次构建时，存储市场的主流还是HDD，因而AWS也采用了HDD作为数据存储介质，导致其服务的延迟主要受HDD的天然劣势影响。因此，在SSD兴起之后，AWS也开始使用SSD作为存储介质以获得更好的读写性能。AWS并未直接推翻基于HDD的产品，而是推出了一种新的EBS卷类型，作为探索SSD的第一步。
虚拟机管理程序优化
AWS EBS基于Xen构建，为了提升服务性能，AWS开发人员们认为有必要减少整个系统的队列数量，在AWS EBS中存在很多不同的队列，诸如实例块设备队列、Xen环形队列、dom0内核块设备队列、EBS客户端网络队列等。
首先，开发人员们发现，尽管dom0设备驱动程序几乎没有延迟，但当多个实例尝试I／O操作时，它们之间的交互会导致整个系统的吞吐量下降，并且AWS EC2的块设备队列和队列条目的默认设置是Xen开发团队基于当时有限的存储硬件所设定的，这个设置导致每个主机只能接受64个并发I/O请求，远远不能满足实际生产需求。因此，AWS优化了虚拟化相关的问题。
网络优化
AWS团队开发了Nitro卸载卡，专门用于网络处理，其将VPC（虚拟专有云）的数据包处理从Xen dom0的内核空间转移到了专用的硬件管道中，不再需要占用客户实例的CPU资源来处理网络流量。
对于EBS，AWS团队决定采取同样的措施，将更多的工作处理转移到硬件上，消除了hypervisor中的多个操作系统队列。同时，第二版Nitro卡还具有处理EBS加密卷的能力。
尽管迁移到Nitro取得了巨大的胜利，但网络本身的又成了性能瓶颈。因此，AWS团队意识到需要比TCP更好的解决方案，针对弹性和可拓展HPC的云优化协议（SRD）由此诞生。这个协议旨在提供更强的容错性：增强恢复能力和绕过故障，更容易卸载到硬件中。在实践中，AWS发现正在传输的I/O请求可以重现排序，并不需要如TCP一般严格保证顺序交付。
异同
相同点
- AWS和阿里云都支持将更多处理诸如网络流量处理、数据压缩、加密等卸载到硬件上以获得更好的性能，释放CPU进行更有价值的计算任务
- AWS和阿里云都定制了自己的网络传输层协议，最终拥抱了具有UDP特性的可靠传输协议，并且两者一致认为传输层协议要能够更容易的卸载到硬件中
- AWS和阿里云都认为更好的硬件是提升EBS性能的基础，诸如HDD被替换为更高性能的SSD
- AWS和阿里云都是通过逐步迭代而非彻底的变革来推动EBS的发展
- AWS和阿里云都通过简化调用堆栈来提升性能
不同点
- 阿里云侧重硬盘空间利用率，因而着重加强了数据压缩和备份效率的提升，如引入EC算法，并将之卸载到专门的FPGA卡中
- AWS尝试了虚拟化管理系统层面的优化，如Xen中IO的优化
