随着硬件技术（SSD，RDMA 等）和商业模式（从面向大容量到面向高性能）的演进，阿里盘古存储系统也在不断进化，存储服务从 ms 级延迟逐渐进化到高性能、高可靠的 100us 级。
如何做到的呢？
- 在第一阶段，为适应 SSD 和 RDMA（性能瓶颈逐渐从硬件转移到了软件层），创新了文件系统和设计用户态的存储操作系统，从而能够大幅降低 I/O 延迟，提供高吞吐量和 IOPS；
- 在第二阶段，为适应盘古从面向容量的商业模式往面向性能的转变，提高了基础设施中 SSD 和 100 Gbps 带宽的 RDMA 的数量。同时也引入了大量关键设计：降低流量放大、远程直接缓存访问（RDCA）、CPU 计算卸载，确保盘古充分收获硬件升级带来的性能提升。
Introduction
盘古作为一个统一存储平台，为阿里和阿里云（比如淘宝，天猫，蚂蚁金服等等）提供了可扩展，高性能和高可靠的存储服务；一些云服务，比如 EBS，OSS 等等也是建立在其之上。现如今，盘古已经达到了 EB 级存储容量，管理了万亿个文件。
盘古1.0：面向容量的存储服务提供者。
2009-2015，盘古构建在商用 CPU 和 HDD 之上，提供 ms 级 I/O 延迟和 Gbps 级数据中心网络。基于 Ext4 和内核态的 TCP，盘古设计了分布式内核态的文件系统，能够提供多种文件类型（比如临时文件，日志文件和随机访问文件）供不同存储服务所使用。受限于 HDD 和 Gbps 级网络，盘古已经达到性能上限，且云计算早期，客户也更关注大容量。
新硬件需要新设计
SSD 和 RDMA 能够提供高性能、低延迟的 I/O，但（1）允许随机访问的文件类型在 SSD 上的性能很差，而顺序操作能够提供更高的吞吐量；（2）由于数据拷贝和频繁中断，内核软件栈无法紧跟 SSD 和 RDMA 的高 IOPS 和低延迟；（3）从以服务器为中心的数据中心架构到资源分解（内存分离？）的数据中心架构（学习和总结其中的动机），这种范式转变为实现低 I/O 延迟带来了额外的挑战。
盘古2.0第一阶段：通过文件系统重构和用户态存储操作系统，拥抱 SSD 和 RDMA。
为简化整体系统的开发和管理，为盘古的文件系统（1）设计了仅添加的持久层和引入了独立的块布局减少文件写入操作的 I/O 延迟；（2）设计了用户态存储操作系统（USSOS），使用 run-to-completion 线程模型实现用户态存储栈和用户态网络栈的高效协作，并且提出了用户态调度机制，有效实现了 CPU 和内存资源分配；（3）在动态环境下，部署了 SLA 保护机制。
通过以上设计，在第一阶段就实现了ms 级 P999 I/O 延迟。
盘古2.0第二阶段：通过增加 SSD 和 100Gbps RDMA 的数量以及突破网络/内存/CPU瓶颈，适应性能导向的商业模式
增加 SSD 数量：盘古每台服务器配备 96TB 的 SSD；将 RDMA 带宽从 25Gbps 升级到 100 Gbps。
为充分收获这些硬件带来的性能提升，需要打破网络、内存和 CPU 的性能瓶颈。（1）通过减少网络流量放大比例和动态适应流量优先级，优化网络带宽；（2）通过提出远程直接缓存访问（RDCA），应对内存瓶颈；（3）通过消除数据序列化、反序列负担和引入 CPU 等待指令同步超线程，解决 CPU 瓶颈。
Background
Overview
盘古是一个大规模分布式存储系统，由 Pangu Core，Pangu Service 和 Pangu Monitoring System 组成。
Pangu Core 由 clients，masters 和 chunkservers 组成。clients 为盘古云存储服务（比如 EBS 和 OSS）提供 SDK，接收上层服务的文件请求并与 masters 和 chunkservers 通信；masters 管理盘古所有的元数据，并使用基于 Raft 的协议来维护一致性，为更好的水平扩展性，将元数据服务分成 namespace 服务（提供有关文件的信息，例如目录树和命名空间）和 stream 服务（提供从文件到块位置的映射）；chunkservers 以块的形式存储数据，并配备定制的用户态存储文件服务（USSFS），USSFS 为不同硬件提供高性能、仅添加存储引擎（例如 HM-SMR SMRSTORE，FAST 23 的另一篇阿里论文）。在早期，每个文件都存储在具有三副本的 chunkserver 中，后来由垃圾回收工作器执行垃圾回收并使用纠删码存储文件，减少了流量放大。
在 Pangu Core 上层，Pangu Service 提供传统的云存储服务。
Pangu Monitoring System 为 Pangu Service 和 Pangu Core 提供实时的监控和 AI 辅助的根因分析服务。
阶段一：拥抱 SSD 和 RDMA
SSD 和 RDMA 的出现，使得 I/O 瓶颈从硬件逐渐转移至软件层，为此，盘古创新了文件系统和设计用户态的存储操作系统。
Append-Only File System
首先引入一个统一的、仅添加的持久层，带有一个名为 FlatLogFile 的仅添加接口，简化架构并具有高吞吐量和低延迟；heavyweight client 可以满足不同存储服务的需求；基于 FlatLogFile 接口，盘古采用仅添加的 chunk 并使用独立的 chunk 布局来管理 chunkservers 上的 chunk；盘古在 masters 上实现了分布式元数据管理，做到高效的元数据操作。
Unified, Append-Only Persistence Layer
早期的盘古为不同的存储服务提供了不同的接口，而现如今，为了简化开发和管理，确保所有存储服务都能在 SSD 上实现高性能、低延迟的 I/O 服务，盘古的持久层为它们（例如 EBS 和 OSS）提供了统一的文件类型 FlatLogFile。
Heavyweight Client
client 负责与 chunkservers 交互进行数据操作，与 masters 交互进行元数据信息检索和更新。
Append-only Chunk Management
典型的文件系统（如 Ext4）将文件存储在块中，通过两次 SSD 写操作，将文件及元数据分别写入存储介质，不仅增加了文件写入延迟，而且缩短了 SSD 的寿命。因此，盘古选择在 chunkservers 中以 chunk 形式存储文件，这些 chunk 具有基于 FlatLogFile 的仅添加语义，并设计一个独立的 chunk 布局，其中每个 chunk 都存储数据和自己的元数据（是否导致实际可用存储容量减少？）。这样，一次操作就可完成写入。
如下是 chunk 布局，一个 chunk 包括多个扇区单元，每个扇区包括三个元素：data，padding 和 footer。footer 存储块元数据，例如块 ID，块长度和 CRC 校验和。
Metadata Operation Optimization
元数据服务分成两种：namespace 和 stream。namespace 负责目录树和文件管理；stream 负责块信息管理，stream 是一组块的抽象，同一 stream 中的块属于同一文件。
不同 chunk 大小。大块可以减少元数据数量，同时避免由于客户端频繁请求块而导致的不必要 I/O 延迟，有助于提高 SSD 的使用寿命，但是，可能会引入碎片风险。因此，引入长度可变的 chunk，大小分为从 1MB 到 2GB。
在客户端缓存 chunk 信息。每个客户端维护一个本地元数据缓存池，以减少元数据查询请求的数量。
chunk 信息请求批处理。每个 client 短时间内聚合多个 chunk 信息请求，批量发给 master，提高查询效率。master 批量处理请求，聚合结果并将其发送回 client。client 分解结果并将其分派到相应的应用程序。
推测性 chunk 信息预取。当 masters 收到读取请求时，返回相关的 chunk 元数据和其它 chunk 的元数据（过去的经验表征和请求 chunk 频繁一起访问？缓存到 client？）；当 masters 收到写入请求时，返回更多的 chunk 以应对写入异常，而无需再向 masters 请求新的 chunk。
Data piggybacking to reduce one RTT。client 从 masters 获取到 chunk 地址后，将 chunk 创建请求和要写入的数据合并成一个请求发送给 chunkservers，从而能够将写入延迟减少一个 RTT。
Chunkserver USSOS
chunkservers 负责执行所有的数据操作，因此，必须仔细设计运行时操作系统，以确保数据操作能够以低延迟和高吞吐量完成。传统内核态进行数据操作将发生频繁的系统中断，消耗 CPU 资源，而且会在用户态和内核态之间产生不必要的重复。因此，采用绕过内核的设计，为 chunkserver 开发一个高性能的用户态存储操作系统，提供统一的用户态存储软件平台。
盘古还实现了用户级内存管理，轻量级用户态调度策略和用于 SSD 的定制高性能仅添加用户态存储文件系统（USSFS）。
User-Level Memory Management
chunkserver USSOS 基于现有的用户态技术（如网络栈中的 RDMA、存储栈中的 DPDK 和 SPDK）构建。同时，更进一步
- 利用 run-to-completion 线程模型，相比于传统的 pipeline 线程模型，减少了线程上下文切换、通信和同步的开销；
- 线程请求大页内存作为网络和存储栈之间的共享内存，通过 RDMA，可以将从网络接收的数据存储在这个共享大页内存中，发送大页内存的元数据（例如地址和大小）后，可以通过 SPDK 帧将数据直接从大页内存写入存储介质。这样，在数据传输和存储过程中实现了网络和存储堆栈之间的零拷贝。
User-Space Scheduling Mechanism
三个优化 CPU 调度的关键设计。
防止阻塞后续任务。每个 chunkserver 有固定数量的工作线程，根据请求中文件的哈希值将新请求分派到工作线程，分配给同一工作线程的请求按照 FIFO 顺序执行。而如果一项任务花费太多时间，将导致资源被占用并且后续任务被阻塞。为解决此问题，引入心跳机制监控任务的执行并设置警报，当时间片被用完时，它将被放入后台线程并从关键路径中删除。
优先级调度保证高 Qos。盘古为不同的请求分配不同的 Qos 目标，比如用户请求高 Qos，GC 请求低 Qos，通过使用优先级队列保证较高 Qos 目标的请求拥有较高优先级。
轮询和事件驱动的切换。NIC（网卡） 提供一个供应用程序监控的 fd，并通过 fd 事件通知应用程序有数据到达。默认情况下，应用程序处于事件驱动模式，而当它们收到来自 NIC 的通知时，它们将进入轮询状态。如果一段事件内没有收到任何 I/O 请求，它们将重新切换回事件驱动模式并通知 NIC。
Append-Only USSFS
USSFS 提供了一系列基于 chunk 的操作接口（打开、关闭、格式化、读取和追加等），支持顺序写入和随机读取。
通过多种机制最大化 SSD 性能
- 充分利用独立的 chunk 布局减少数据操作的数量，而无需使用页面缓存；
- 无需像 Ext4 那样在 inode 和文件目录之间建立层次关系，所有对文件的操作会记录到日志文件中，可以通过挂载文件系统时重放日志来重建相应的元数据；
- 使用轮询模式而不是像 Ext4 那样的中断机制来最大化 SSD 性能。
High Performance SLA Guarantee
阶段2：适应面向性能的商业模式
泰山服务器（作为 chunkservers）配备了大量 SSD（96TB）和高性能 RDMA（100Gbps），此时，其它资源（例如网络、内存和 CPU）成为了性能瓶颈。
网络瓶颈
TODO
内存瓶颈
内存瓶颈来自接收主机中网络进程（即执行 DMA 操作的 NIC）和应用程序进程（如数据拷贝、数据复制和垃圾回收）之间的内存带宽竞争。NIC 无法获得足够的内存带宽，导致 NIC 缓冲区被传输中的数据包填满，最终导致溢出，触发网络中的拥塞控制造成整体性能下降。
对此，分三步解决：（1）在服务器中添加更多小容量 DRAM，以充分利用内存通道；（2）将后台流量从 TCP 切换到 RDMA，以减少服务器的内存带宽小号；（3）设计远程直接缓存访问（RDCA）将内存移出接收方主机的数据路径，并让发送者直接访问接收器的缓存。
加一些小容量内存
由于瓶颈在于内存带宽而不是内存容量，因此在服务器中添加更多小容量 DRAM，可以充分利用内存通道并增加每台服务器的可用内存带宽。
启用非均匀内存访问（NUMA），以避免跨 sockers 内存访问。
后台流量从 TCP 切换到 RDMA
原本的 25Gbps 的 RDMA 只能支持前端流量走 RDMA，而后台流量是走的 TCP，而 TCP 比 RDMA 至少多需要 4 个内存副本。而使用 100Gbps 后，后台流量也可以走 RDMA 了。
远程直接缓存访问
让发送者绕过接收者的内存直接访问其缓存。
从 LLC 中拿一小片区域支持 NIC 操作。
CPU 瓶颈
TODO
运营经验
TODO