More Than Capacity: Performance-oriented Evolution of Pangu in Alibaba——论文泛读

FAST 2023 Paper 

背景

盘古1.0：面向容量的存储服务提供商。

• 目标是支撑大容量存储，性能次要。

• 基于 Ext4 和内核 TCP 设计的内核文件系统。

• 面向 HDD 和以太网设计，延迟 ms 级，网络 Gbps 级。

• 分为多种文件类型 TempFile, LogFile, random access file

但新的硬件技术需要新的设计，尽管SSD和RDMA可以在存储和网络中实现高性能、低延迟的I/O，但观察到：

• 盘古1.0中使用的多种文件类型，特别是允许随机访问的文件类型，在SSD上表现不佳。

• 由于数据拷贝和频繁中断，内核空间软件堆栈无法跟上SSD和RDMA的高IOPS和低I/O延迟。

• 从以服务器为中心的数据中心体系结构到按资源划分的数据中心架构的范式转变，对实现低I/O延迟带来了额外的挑战。

本文工作

本文介绍了盘古存储系统如何随着硬件技术和业务模式的不断发展，以提供高性能、可靠的I/O延迟级别的存储服务。包括两个阶段。

• 通过文件系统重构和设计用户空间存储操作系统（USSOS），充分利用固态硬盘（SSD）存储和远程直接内存访问（RDMA）网络技术。为了简化整个文件系统的开发和管理，设计了统一的、仅追加的持久层，还引入了自包含块布局，以减少文件写操作的I/O延迟。USSOS使用运行到完成线程模型来实现用户空间存储堆栈和用户空间网络堆栈之间的高效协作。还提出了用于高效CPU和内存资源分配的用户空间调度机制。通过这些创新，实现了毫秒级P999 I/O延迟，同时提供了高吞吐量和IOPS。

• 从面向容量发展为面向性能。升级其基础设施，开发了大容量存储服务器（每台服务器96 TB SSD），并将网络带宽从25 Gbps升级到100 Gbps。并引入了一系列关键设计，通过降低网络流量放大率和动态调整不同流量的优先级来优化网络带宽；通过远程直接缓存访问（RDCA）来解决内存瓶颈；通过消除数据（去）序列化的数据税，引入CPU等待指令同步超线程，来解决CPU瓶颈。

第一阶段，盘古2.0成功支持弹性SSD块存储服务，I/O延迟为100μs级，IOPS为1M。对于写密集型服务（如EBS云硬盘），P999 I/O延迟小于1ms。对于读密集型服务，P999输入/输出延迟小于11ms。第二阶段，通过将网络从2×25 Gbps升级到2×100 Gbps，并突破网络、内存和CPU的瓶颈，泰山存储服务器的标准化有效吞吐量提高了6.1倍。

盘古架构

Master:

• Raft 容灾

• 存储所有元数据

• 元数据分为 namespace 和 stream

• 元数据按目录树分区利用局部性，然后使用哈希分区负载均衡

• namespace 存储目录结构和文件元数据

• stream 存储文件到 chunk 的映射

Chunkserver:

• USSFS 用户态只追加文件系统

• 针对 SMR 等不同硬件优化

持久化层

重客户端设计

• 客户端负责数据复制或 EC 算法

• 自带重试机制

• 主动探测 ChunkServer 性能

• 上层服务自己负责 GC

自包含块布局

• Chunk 包含数据和元数据，节省 IO 次数

• 客户端连续写入很多 Chunk 时，定时保存元数据快照，故障重启后检查 CRC 恢复正确状态

元数据操作优化

• 并行化元数据操作

• 可变长度的大 chunk

  • 不同服务根据需要选择 chunk 长度减少碎片化

• 客户端通过 LRU 缓存元数据

  • 过期时，ChunkServer 回复错误

• 客户端元数据请求批处理

• 推测性预取 chunk 信息

  • 读请求返回多余的 master 预测的 chunk

  • 写请求返回多余的空闲 chunk

• 写数据 piggyback

  • 创建 chunk 请求和写入 chunk 数据一起发送，节省 1 RTT

Chunkserver USSOS

内存管理

• 每个请求由一个线程 Run to Completion

• DPDK 和 SPDK 共享同一片大页内存池

• RDMA 写入内存池后，SPDK 直接将数据写入存储设备

任务调度

• 引入心跳机制，运行时间过长的任务放到后台线程防止阻塞

• 引入 QoS 调度机制，不同 QoS 任务放到不同优先级队列中

• 引入轮询-事件切换机制（NAPI），网卡空闲一段时间后进入事件通知模式

USSFS 只追加文件系统

• 非 POSIX API：open, close, seal, format, read, append

• 本质上是日志文件系统

• 利用了 chunk 自包含元数据的特性避免多次 IO

• 使用轮询模式操作 SSD

• 最小以 1MB 粒度分配磁盘空间

业务 SLA 保证

追逐机制，降低响应延迟

• 写入 MinCopy 个服务器就返回成功，2 x MinCopy > MaxCopy

• 对于超时未响应的服务器，等待 t ms，等待时间内返回成功就释放内存

• 否则，判断已经未写入的数据量是否小于阈值 k

  • 小于则直接重试

  • 大于则 seal chunk，并通知 master 从其他服务器复制 chunk 的副本

不停写机制，降低写延迟

• 写入失败的时候 seal chunk，上报成功写入的长度，在新 chunk 继续写

• 如果已经 seal 的 chunk 数据损坏，尝试从其他副本复制，没有再重试

备份读机制

• 同时向多个 ChunkServer 发起读请求

• 通过 IO 类型和磁盘类型决定备份请求的时间和数量

• 设置硬上限，避免系统过载

黑名单机制

• 确定性黑名单：服务器宕机，SSD 损坏

• 概率性黑名单：延迟超过阈值，延迟越大概率越大，超过中位数设为 1

• 定时探测黑名单的服务器，移除或降低概率

• 限制黑名单总数

网络瓶颈优化

使用有损 RDMA 网络，禁用 Pause 帧

优化网络流量

• ISA-L EC 替代三副本（6.375x -> 4.875x）

• LZ4 压缩 FlatLogFile（4.875x -> 2.9375x）

• 业务前端和后台工作流量动态分配

内存瓶颈优化

问题

• 网卡 DMA 操作和应用程序访存产生内存带宽竞争

• 导致网卡缓冲区溢出丢包

方法一：添加更多小内存

• 增加内存通道

• 启用 NUMA 避免跨 UPI

方法二：背景流量从 TCP 切换到 RDMA

• 减少内存拷贝

• 设计了类似 tc 的工具控制流量

方法三：远程缓存直接访问（使用 DDIO）

• 使用 SRQ 接收小消息以及带窗口流量控制的读缓冲

• 尽量使缓冲区能放入 CPU 缓存中

• 使用流水线并行化以及硬件卸载尽快流转 cache 数据

• 对于抖动，用新的内存替换掉落后者的区域

• 太多替换的时候，主动将落后数据拷贝到内存中

• 都无法解决缓存竞争时，让网卡发出 ECN 拥塞控制包

CPU 瓶颈优化

混合 RPC 序列化

• 数据通路的 RPC 使用 FlatBuffer 类似的零开销序列化

• 控制通路继续使用 Protobuf，更加灵活

超线程 monitor mwait 优化

• 例如 T1 是空闲网络轮询线程，T2 是压缩线程

• T1 发出 mwait 指令等待特定内存地址写入

• 避免了无意义的 HT 上下文切换

硬件卸载

• 压缩卸载到 FPGA

• CRC 校验卸载到网卡

总结

对阿里云盘古2.0的介绍，包括两个阶段：（1）通过文件系统重构和用户空间存储操作系统（USSOS），充分利用SSD和RDMA。设计了统一的、仅追加的持久层，引入了自包含块布局，以减少文件写操作的I/O延迟。USSOS使用运行到完成线程模型，利用高效CPU和内存资源分配的用户空间调度机制。（2）从面向容量发展为面向性能。升级基础设施，开发了每台服务器96 TB SSD，将网络带宽从25 Gbps升级到100 Gbps。引入了一系列关键设计，通过降低网络流量放大率和动态调整流量的优先级来优化网络带宽；通过远程直接缓存访问（RDCA）来解决内存瓶颈；通过消除数据（去）序列化的数据税，引入CPU等待指令同步超线程，来解决CPU瓶颈。