3.1 平均延迟与长尾延迟

虚拟磁盘（VD）的延迟是由其底层架构决定的，具体而言，取决于请求所经历的路径。以EBS2为例，VD的延迟受制于两跳网络（从BlockClient到BlockServer，再至ChunkServer）的延迟、软件栈处理时间（即BlockClient、BlockServer和Pangu组件的处理时间）以及SSD的I/O操作时间。因此，延迟的弹性本质上是粗粒度的，不同架构（比如EBS2和EBS3）下的各种时间开销级别不同。针对不同代际的EBS，在其最繁忙的生产集群的前10%中，测量了8 KiB随机读写操作的平均延迟构成。由于EBS1已不再部署且其硬件（如HDD和10Gbps网络）已过时，故未将其纳入比较。

• 硬件处理的主导作用：不论是EBS2还是EBS3，大部分总延迟都是由硬件处理造成的，包括第一跳和第二跳网络（橙色和粉色标记）以及磁盘I/O（黄色标记）。

• EBS3的特性：尽管EBS3在前端增加了EC（纠错编码）和压缩处理的时间，但因数据体积减小，网络传输时间（即第二跳延迟）相应减少，这使得EBS3与EBS2的总体延迟相近。这一结果反映了EBS3在优化数据处理与传输时间之间的平衡。

• 读写差异：读操作与写操作的主要区别在于硬盘I/O延迟。值得注意的是，EBS2采用的是TLC SSD，而EBS3则使用QLC SSD。这两种类型SSD在性能特性上有所不同，特别是写入速度和耐久性，这也会影响它们的I/O延迟表现。

扩展阅读：

• 深度剖析：大容量QLC SSD为何遭疯抢？

• 全景解析SSD IO QoS性能优化

• 为什么QLC NAND才是ZNS SSD最大的赢家？

上述分析侧重于平均延迟，但长尾延迟QoS（即极端情况下的延迟）也是衡量存储系统性能的关键指标。长尾延迟通常受软件处理的不确定性、资源竞争、以及硬件突发状况等因素影响。在EBS2和EBS3中，通过优化软件栈处理流程，比如分离客户端I/O与后台任务（如垃圾回收），以及采用更高效的数据处理算法，可以减少由软件引起的大延迟事件，从而改善整体的长尾延迟表现。

3.2 IOPS与吞吐带宽

系统整体的IOPS和吞吐量上限主要受到BlockClient的限制。BlockClient作为客户端请求与后端存储服务交互的前端组件，它的处理和转发能力直接影响了整个系统能够处理的IOPS和数据吞吐量。具体来说，BlockClient处理请求从内核空间到用户空间的转换，并进一步到硬件卸载（如FPGA或专用加速器），这一系列操作构成了性能的瓶颈。

• EBS2的改进：在EBS2中，通过引入用户空间TCP堆栈处理I/O请求，将I/O处理从内核空间转移到用户空间，以减少内核态与用户态之间的切换开销，从而提升性能。

• EBS3的进一步优化：EBS3在此基础上更进一步，利用通用FPGA（Field-Programmable Gate Array）硬件卸载技术，直接绕过CPU处理数据移动、数据块CRC校验和数据包传输，显著提升了I/O处理能力。EBS3配备2x100G网络，但此时瓶颈转移到了PCIe总线带宽上。

• 吞吐量与IOPS随HT数量增加：下图展示了BlockClient在不同优化措施下，最大吞吐量和IOPS的变化情况。结果显示，对于EBS2，当使用2x25Gbps网络时，吞吐量主要受限于网络能力。而在EBS3的2x100G网络配置下，瓶颈变为PCIe带宽。只要网络带宽允许，增加超线程（HT）数量就能提升IOPS。

为了更好地适应不同工作负载的需求，引入了自适应性能级别（AutoPL）的虚拟磁盘。这意味着用户可以根据实际需求动态调整IOPS和吞吐量，而不需要改变磁盘的容量配置。这种机制为用户提供了一种灵活的方式来应对瞬时或周期性的性能高峰。

• Base + Burst策略：为了高效分配IOPS和吞吐量给不同的虚拟磁盘（VDs），采用基础（Base）与突发（Burst）相结合的策略。

• • 基础吞吐量：确保每个VD都能获得一个最低的、稳定的IOPS和吞吐量保障（Base throughput），满足基本的性能需求，确保服务质量。

  • 突发吞吐量：在基础之上，系统会根据当前资源的可用情况，尽力满足VD的额外性能需求（Burst throughput）。这种策略允许VD在需要时短时间内超过其基础配额，以应对短暂的高负载情况，而不会长期影响其他VD的性能。

3.3 容量

在EBS的设计中，实现容量弹性的能力是其作为云块存储服务的基本要求之一。为了满足这一需求，EBS引入了多项关键特性来增强其在容量管理上的灵活性和效率，具体包括以下两点：

• 分段设计带来的无缝VD调整：EBS利用分段设计（Segmentation Design）实现了虚拟磁盘（VD）容量的无缝调整，即用户可以轻松地对VD进行扩容或缩容操作，这一过程通过添加或移除所谓的“SegmentGroups”来完成。SegmentGroups作为存储空间分配的逻辑单元，使得EBS能够快速响应用户对存储容量变化的需求，而无需中断服务。目前，EBS支持的虚拟磁盘容量范围从1 GiB到64 TiB，覆盖了从小型应用到大型数据库等多种存储需求场景。

• 快速克隆：server-less应用的特点之一是需要在短时间内快速分配大量资源，如虚拟磁盘。为此，EBS利用了Pangu文件系统的硬链接特性，这一特性允许在存储集群内部通过下载单个快照来克隆多个磁盘，大大加快了资源部署的速度。基于这一技术，EBS2能够实现令人印象深刻的性能指标：在1分钟内创建多达10,000个虚拟磁盘，每个磁盘大小为40 GiB。这样的能力对于需要频繁创建和复制存储环境的场景（如开发测试、大规模部署、灾备演练等）来说，是极其宝贵的，它极大提升了资源分配的效率和响应速度。