前言
本论文是继阿里在FAST`23发表的关于Pangu系统演进的论文之后又一个比较有参考意义的工作，从论文里我们可以窥探阿里是如何基于Pangu去构造一个高性能的块存储系统。
Pangu的介绍可以参考：Pangu 2.0: 如何打造一个高性能的分布式存储系统
演进
EBS1 (2012 ~ 2015)
特点：
- 存算分离，存储层自建
- 多个VM共享宿主机同一个BlockClient
- 存储集群由BlockManager、BlockServer、CchunkManager和ChunkServer组成
- BlockManager管理VD->BlockServer的映射关系，BlockServer和VD是一对多的关系
- 每个VD由多个64MB大小的Chunk(64MB)组成，ChunkManger管理Chunk到ChunkServer的映射关系；Chunk有多个副本组成
- BlockManager和ChunkManager均有Paxos协议保证数据的一致性，提供高可用的服务
缺陷：
- VD和BlockServer是n对1的关系，每个VD的数据访问只能由一台BlockServer承担，容易成为性能瓶颈
- inplace-update以及不确定的io大小，想做数据压缩（EC）比较困难
- HDD以及tcp/ip的内核网络协议栈很难提供高质量的服务
EBS2（2015~ 2019）
架构：
特点：
- 存算分离，存储层进一步进行存算分离，去除了EBS1的ChunkManager/ChunkServer，使用append-only的分布式存储系统Pangu[1]
- 存储层的"计算"节点BlobServer和BlockManager为无状态服务，BlockManager不再依赖Paxos等共识协议，使用Pangu提供的分布式锁实现高可用，见图3
- VD的LBA分多级管理，打散VD的请求到不同的BlockServer；VD的LBA首先按照128GB分成不同的逻辑SegmentGroup，然后每个SegemntGroup会有4个32G的Segment组成，SegmentGroup的128G数据会按照2MB分为不同的Sector，按照Round-robin方式分配4个不同的Segment上；每个Segment在Pangu上有多个不同的DataFile组成，每个DataFile默认是512MB，见Figure4
- Segment是BlockManager在BlockServer上调度的基本单元，Segment到BlockServer的映射关系由BlockManager管理
- BlockServer将用户的数据持久化到Pangu(DataFile)，内部维护了一个LBA到DataFile的索引，该索引使用LSM-Tree保存了LBA->(DataFileID, offset, length)的映射关系，并且使用一个TxnFile记录了Update Record（类似redo，所以是不是可以猜测LSM没有实现实现redo，只是一个简单的memtable+sst，或者TxnFile和途中的Update MemTable以及SSTable其实是现实是一个结构，不过不太重要就理解为LSM-Tree就行)，DataFile、TxnFile和SSTable都是持久化保存在Pangu的，Crash恢复只需要读取TxnFile然后就可以恢复出来Crash前的MemTable，这个会非常快
- 为了提供空间利用率，BlockServer内部实现了一个GC功能，实现两个目的：回收垃圾数据以及用户数据进行压缩（LZ4和EC(8.3)）。GCWroker在后台会将多个DataFile进行压缩然后EC的方式写入新的EC DataFile，并且修改Index Map
- 因为压缩后数据会有变化，ECDataFile的结构如下，offset table保存了LAB到压缩后数据的位置(只是保存Offset吗？和IndexMap里保存的数据是什么关系？）
- LSM的架构想要生成快照更加容易，blockserver只上传上一次快照到当前快照的时间戳中间的更新即可（这里应该设计到和GC怎么交互，如果没有快照是不是还不能GC？)
- BlockServer和BloackManager的数据都是存储在Pangu因此都是无状态的，而且其恢复很快所以没有单独的热备（恢复时间到底有多快没有说？能做到秒级恢复？）
- BlockServer和Pangu的ChunkServer同机部署，但是依然通过网络传输数据，不强制data-locality
限制：
- 虽然最终减少了存储空间（从3副本降低到0.69，实际线上平均是1.29），但是后台GC也消耗了额外的网络带宽，从3增加到了4.69
在线EC的挑战点：
- EC要求数据至少是16KB才能实现高压缩率和编码效率，但是线上70%的写都是少于16KB的；为了提供100us的写延迟，想要在短时间内攒够16KB的数据是比较困难的，这要求Segment的写吞吐至少是160MB/s，这个吞吐已经超过了线上90%集群的吞吐，如果只是简单的将不满16KB的数据补齐(padding-zero)，会造成空间的放大
- 即使使用延迟优化的LZ4压缩算法，压缩16KB的数据也需要25us，这是不可接受的性能损失
EBS3(2019~now)
架构：
特点：
- 在BlockServer内部增加了一个FWE(Fusion Write Engine)的组件，将不同VD的写入进行聚合，超过16KB或者8us超时就发送到一个外部的FPGA加速器进行数据的压缩，FPGA加速器内部会读数据按照4KB进行拆分并行进行压缩或者解压缩，然后LSBD模块会将压缩后的书写使用EC(4,2)写入到Pangu，这里写入的文件是Append-only的JournalFile，写入成功后就可以ack用户了
- 原始数据会按照segment写入到内存的SegmentCache用于读取，SegmentCache攒到512KB会使用本机的CPU进行压缩后使用EC(8,3）写入到Pangu的DataFile，然后更新TxnFile和IndexMap，这一步是后台进行的；JournalFile不接受任何读请求，只用来故障恢复的时候恢复出SegmentCache内的数据
- 使用高速网络(2x100Gbps）、基于UDB的网络传输协议以及DPU-offloading实现CPU/PCIe bypass，可以参考论文[2]
- 数据冗余度从1.29降到了0.77；流量放大从4.69降低到了1.59
- 基于FPAG的压缩可以实现7.3GiB/s的吞吐，延迟增加大概在29~65us（EBS2担心的增加25us问题依然存在？，可能主要还是高速网络获益？）
关于可用性：
- 在架构上BlockManager使用联邦架构，将VDs分成逻辑上不同的Partiition，然后引入一个CentralManager，管理VD到partition以及Partition到BlockManager的映射；使用简单的静态的Hash算法计算VD归属哪一个Partition，Parition到BlockManager是静态映射；为了进一步减少单点，BlockClient在访问的时候会向所有的BlockManager询问VD是否属于它管理，而不需要经过CentralManager
- BlockManager不再使用三个节点，只需要单个节点，一旦出现故障，CentralManager会马上重新将上面的Partition迁移到其他BlockManager，新的BlockManager可以从Pangu读取元素局快速恢复，因为每个BlockManager管理的VD非常少，所以可以快速启动，不需要额外的热备
EBSX
EBSX主要是利用高速持久化内存PMem以及高速的网络框架进一步降低端到端延迟，PMem已经停产所以没有太多参考价值，但是本地Cache的思路在存算分离的架构下确实是优化的一个重要方向
总结
整体来讲，结合Pangu的论文[1]和本篇论文可以对阿里的存储架构有相对全面的认识，块存储是否一定要采用存算分离的架构，是否一定要构建在类似Pangu的系统之上，这个就根据各自的场景进行选择了，架构没有优劣，只是各种选择的产物，比如EBS1的架构也不是说一定不能做到高性能，EBS2的很多技术手段依然可以在EBS1实施，但是像阿里云已经有成熟的Pangu系统，其他存储服务（EBS、OSS)等统一到Pangu也许是最好的"选择"，也可能是必然的选择。
回到论文本身，除了前面提到的一些关键点，论文里还有很多关于架构选择以及实施过程中遇到的难点，以及未来演进的方向的探讨，比如如何选择offloading等，还是很有参考意义的