Pangu 2.0: 如何打造一个高性能的分布式存储系统

Pangu存储系统是阿里云存储服务的底层存储系统，大家熟知的OSS/NAS/EBS等服务都是基于Pangu系统开发，其重要性无需多言。这篇论文是阿里巴巴在FAST` 23上发表的和盘古系统相关的三篇论文之一，论文里比较详细的介绍了盘古系统的架构以及演进过程，笔者之前在字节也是参与类似系统的开发，因此看到阿里将盘古系统2.0架构第一次系统地以论文形式发表出来，第一时间拿来拜读

摘要

• 第一阶段，Pangu利用新的SSD硬件和RDMA网络技术重新设计了一套用户空间存储系统，降低了其I/O延迟，同时提高了吞吐和IOPS；

• 第二阶段，Pangu从面向容量的存储服务转变为面向性能的存储服务。为了适应这种业务模型的变化，Pangu将服务器升级为拥有更高容量的SSD和RDMA带宽的存储服务器，网络从25 Gbps升级到100 Gbps。同时还引入了一系列关键设计，包括减少网络流量放大、远程直接缓存访问和CPU计算卸载，以确保Pangu充分利用硬件升级带来的性能提升

概述

Pangu 1.0(2009 ~ 2015)

Pangu 2.0(2015 ~ now)

• 1.0提供了各种文件类型，尤其是支持随机读写的文件类型，随机读写相比顺序读写并不能发挥SSD硬件的性能，提供极致的吞吐和IOPS

• 1.0单机存储使用的是内核文件系统，IO链路上存在大量的数据复制和中断，这些都影响了IO性能，相比SSD和RDMA消耗的延迟，已经成为了大头

• 数据中心架构已经有服务器为中心演变为了资源为中心，如何适配这种数据中心架构的演进从而提供低IO延迟的服务带来了新的挑战

2.0 第一阶段： 用户态文件系统

• 重新设计了文件系统，提供了一个用户态的文件系统(USSOS），提供了append-only的语义，并重新设计了一种自包含的Chunk Layout避免了文件系统一次io产生两次IO的情况(一次数据io和一次meta io)。

• 2.0在线程模型上使用run-to-completion的模型，避免了额外的线程切换开销，实现了用户态存储栈和用户态网络栈的高效协同，同时也提供了一个用户态的CPU/MEM资源调度机制。

• 2.0也提供了一些机制去应对这种变化的环境从而保证服务的SLA(到底是啥机制，没说...)

2.0 第二阶段：升级基础设施适应面向性能的业务模型和打破CPU/Mem的瓶颈

• 通过技术手段减少网络写放大，并且提供动态调整流量优先级的策略

• 提供远端缓存访问技术(RDCA)

• 降低序列化反序列化开销，减少CPU消耗

• 引入了CPU wait指令同步超线程

Pangu架构

• Pangu Service：这一部分严格说不算是Pangu系统的范畴，指的Pangu系统的用户，有OSS/NAS/EBS等面向普通用户的产品服务。这里值得一提的是，除了传统的存储服务（OSS/EBS/NAS等），Pangu Service提供一个一个面向云原生的文件系统服务Fisc[1]，这也是现在云原生大潮下比较重要的一个服务，也发表在今年的FAST上。

• Pangu Core: 该部分是本文关注的Pangu系统部分，包含了Client、Masters和ChunkServers。对外提供了Append-Only的持久化文件系统。其中Client是提供给Pangu Service的SDK，负责接收调用方的文件读写请求，然后和Maters和Chunkservers交互完成数据的读写，Client是一个重SDK，其在整个系统中扮演着重要的角色，诸如多副本的写入，数据的一致性等都由其负责

• Pangu Mornitor: 整个系统的监控系统，对于任何系统都是必备组件，提供了实时的监控和基于AI的根因分析服务

• 命名空间服务提供有关文件的信息，例如目录树和命名空间

• Stream是Pangu中文件的代称有一些列的Chunk组成，一个Stream可以认为是可以无限append写入的大文件，Stream元数据服务提供文件到块的映射(即块的位置)，这个和微软的Azure Storage系统是相似的(传闻Pangu早期的操刀者也是由微软过来的同学完成)

Pangu 2.0

• 低延迟：2.0旨在利用高性能的的SSD和RDMA硬件在存算分离架构下提供100us级别的IO延迟，并且能够提供ms级别的SLA保证，即便是存在网络抖动和服务器故障

• 高吞吐：充分发挥存储服务器的吞吐能力，提供极限吞吐

• 一致的高性能：为所有使用Pangu的服务，如在线搜索、数据分析、EBS、OSS和数据库，都能够提供一致的高性能服务

第一阶段：拥抱SSD和RDMA

Append-only文件系统

Heavyweight client

Append-only Chunk Management

Metadata Operation Optimization

• 元数据并行处理：目录树服务和Stream服务都是用并行化处理的方式满足元数据访问的低延迟，这里可以参考阿里在FAST`22年发表的InifiFS[2]。同时Pangu也会将元数据尽可能得Hash到不同的元数据服务处理，除此之外，Pangu 2.0还是用了 一种可预测的目录ID的数据结构使其能够支持高效的并行处理路径解析（这里不是太懂？）

• 长度可变的Chunk大小：Pangu 2.0选择使用增大Chunk的大小，他们认为这样有几个好处，第一可以减少元数据的数量；第二能够避免Client频繁的请求元数据；第三有利于提高SSD的寿命。但是如果单单增大Chunk的大小就会导致产生很多碎片，因此他们引入了可变长的Chunk大小，支持1MB到2GB大小的Chunk。比如EBS服务Chunk大小的95分位是64MB，99分位是286.4MB。这种变长的设计可以有效降低碎片的概率，同时也和Pangu 1.0保持了兼容。（这里有个疑问如果增大Chunk大小对数据的可靠性有什么影响，理论上这会影响存储的持久性SLA，因为Chunk变大了，那么其或者的副本分布的机器数就变少了，挂一块盘需要修复一个Chunk的时间就会变长，即修复一整块盘数据的时间会变长）

• 在Client端缓存Chunk的信息：每个Client都会维护一个本地的Meta缓存池，使用LRU的策略进行淘汰

• Chunk请求批处理：每个Client都会讲Chunk请求进行Batch处理，这样单个请求发送到Master，master可以并行处理然后将结果一并返回给Client

• Chunk信息预取：Pangu设计了一个贪婪、概率性的预取策略从而减少Chunk请求。当master收到Chunk请求的时候，除了返回请求的Chunk之外也会返回其他相关的Chunk信息(这个策略这里解释根据什么策略返回的)。如果收到写请求，则会返回比客户端请求更多的可用的Chunk，这样客户端写入失败的时候就不用去请求Master可以直接切换一个Chunk写入

• Data Piggybacking减少一次RTT: 合并Create Chunk和Write Chunk请求，Create Chunk直接携带用户写入的数据，通过一次请求完成Chunk的创建和数据的写入，这样可以减少一次RTT

ChunkServer 用户态文件系统(USSOS)

用户态的内存管理

• 使用Run-to-Completion线程模型，减少上下文的切换和线程间的通信以及同步

• 通过用户态的共享内存减少内存拷贝。一个线程请求一块大内存后，这个共享内存会在网络栈和存储栈共享。比如用RDMA协议从网络收到数据后会放到一块共享大页内存中，然后发送内存的地址和大小后，数据就可以通过SPDK直接写入到存储媒介中。通过这种方式可以减少数据的拷贝，同时一些后台的任务比如GC一样可以共享这块内存实现数据的零拷贝

用户态的调度机制

• 防止一个任务阻塞后续的任务。使用共享的大页内存可以实现用户空间网络和存储堆栈之间的零拷贝，但每个chunkserver只有固定数量的工作线程，新的请求根据请求中文件的哈希值分配到工作线程。如果一个任务需要太多时间（例如表查找、遍历、内存分配、监控和统计），它会占用资源并阻塞后续任务，降低请求的性能并导致其他请求饿死。为了解决这个问题，对不同情况采取不同措施，例如对于一些长任务，引入心跳机制监控任务的执行时间并设置警报，如果一个任务运行时间太长，那么就会被放入后台线程执行，当前线程就被出让出来执行其他任务

• 优先级调度保证QoS。对不同的请求赋予不同的优先级，通过优先级队列保证高优先级的任务能够早于低优先级的任务执行

• Polling和evnt-drivent切换(NAPI)。USSOS在Polling和event-driven模式之间提供了一种切换机制从而减少中断处理带来的CPU损耗。具体讲就是应用默认是event-driven模式，当收到一个通知后就会切换到polling模式，polling一段时间没有新的IO请求后会再次切换到event模式

Append-Only USSFS

• 通过使用自包含的Chunk Layout可以减少数据操作的次数，也去除传统文件系统Page Cache和Journal等开销

• 去除层次化的Inode和文件目录语义，所有的操作的操作都记录在日志文件中，通过日志文件的会发可以重建元数据

• 使用polling模式替代ext4使用的中断模式，最大化ssd的性能

高性能SLA保证

• Chasing机制。这个机制可以减少系统抖动对写延迟的影响，在写入数据副本的时候设置MinCopy和MaxCopy，通常2xMinCopy > MaxCopy（不如MaxCopy为3，MinCopy为2），假设其中一个副本发生了异常，那么写入只需要写入MinCopy就返回用户成功。假设两个正常副本写入成功时的时间为T，Client已经返回用户写入成功，但是依然会将该Chunk保存在内存中，等待时间t(ms级别），如果异常的副本在T+t前返回成功，那么Client就会从内存中将该chunk释放。如果没有，但是没有写入成功的数据大小小于k，那么client就会重试写入，如果没有写入成功的数据大于k，那么Client就会将失败的副本Seal掉(禁止后续写入)，然后通知masters修复该副本。通过他们分析发现小心的选择t和k可以额在减少写入尾延迟的同时不带来任何数据丢失的风险。

• Non-stop write。客户端在写入Chunk失败时，会seal掉该Chunk，并把已经写成功的数据长度上报给Masters，重新选择一个新的Chunk进行写入。如果sealed的chunk数据有损坏，那么会有后台修复将该Chunk从没有损坏的Chunk修复一份出来

• Backup Read。这个机制是为了减少系统抖动情况下的读延迟。一个chunk有多个副本，当下发读请求到一个副本时，等待一段时间t，如果请求还没有成功，那么会马上发送n个请求到其他副本，哪个请求先回来就返回给用户，这些后发出去的请求称为backup read。t和n的选择Pangu会根据不同类型的磁盘和io大小动态进行计算和调整，也会根据系统的负载限制其数量

• Backlisting。为了避免请求下发到异常的Chunkserver导致延迟增加，引入了确定性黑名单和非确定性黑名单。当一个chunkserver被认为无法提供服务时（例如，chunkserver的SSD已损坏），该服务器将被添加到确定性黑名单中。如果一个chunkserver可以提供服务，但其延迟超过一定阈值，它将被添加到非确定性黑名单中，并且加入黑名单的概率随着其服务延迟的增加而增加。客户端定期向黑名单中的服务器发送I/O探测请求以释放它们。同时也限制了黑名单上服务器的总数以确保系统的可用性。对于每个服务器，它引入了一个宽限期来添加/删除它们到/从黑名单中以维护系统的稳定性。此外，由于TCP和RDMA链接中的故障服务器可能不同，因此Pangu分别维护TCP和RDMA链接的黑名单，并在两个链接上进行I/O探测以更新它们

第二阶段：适应面向性能的业务模型

网络瓶颈

• 硬件上：采用高性能的NIC/RNIC、光模块（QSFP28 DAC、QSFP28 AOC、QSFP28等），单模/多模光纤和高性能交换机

• 网络软件栈：早期为了大规模部署RDMA，采用了关闭NIC端口或在RDMA网络上有太多暂停帧时（例如几秒钟）临时切换到TCP等各种机制，但是这些机制不能处理基于暂停帧的流量控制的其他问题（例如死锁和头部阻塞，因此又升级到有损RDMA，禁用暂停帧，以避免这些问题并提高性能

• 使用EC替代3副本。用EC(4,2)替代第(b)步的三副本，放大从3x减少到1.5x，最终放大为4.875x。EC对于小IO不是很友好，存在zero-padding的问题，为了解决这个问题Pangu允许小IO聚合写入以及动态切换EC和3副本。除此，Pangu将EC库Jerasure替换为Intel ISA-L，延迟也降低了2.5~3倍

• 压缩FlatLogFile。在GC和Client写入数据的时候使用LZ4对数据进行压缩，线上数据分析平均压缩率可以到50%，这样(b)和(c)步放大分布变为0.5*1.5x和0.5*1.375x，整体的放大就降为了2.9375x

• 动态为前端和后台流量分配网络带宽。如果集群还有很多空闲流量，那么可以调低后台GC的带宽占用阈值，还有比如夜间调大GC带宽使用阈值，白天减小阈值等

内存瓶颈

• 增加小容量的DRAM扩充内存带宽。因为内存容量不是瓶颈，因此可以增加小容量的DRAM去充分利用内存通道增加单台机器的内存带宽

• 后台流量从TCP切换到RDMA。早期因为25Gbps RDMA网络只有一个硬件队列，因此后台流量都是使用了TCP，随着网络升级到100Gbps，后台流量也可以切换打RDMA，相比TCP，网络带宽需求可以降低75%。为了保证前端流量的Qos，设计了一种类似Linux tc的机制控制后台流量

• 远端缓存直接访问。Pangu团队发现数据离开网卡后在内存中时间非常短（平均几百微秒）。假设在内存中停留的时间平均为200微秒的，对于双端口100 Gbps的网卡，只需要5 MB的临时存储来存储离开NIC的数据，因此他们使用英特尔的DDIO在商用硬件上实现了RDCA(Remote Direct Cache Access)使得发送这可以绕过接受者的内存直接访问Cache。在盘古的一些集群上的广泛评估结果表明，对于典型的存储工作负载，RDCA每台服务器消耗12MB LLC缓存(占总缓存的20%)，平均内存带宽消耗减少了89%，网络吞吐量提高了9%。RDCA在非存储工作负载中也很有效，例如，在延迟敏感的HPC应用程序中，它将集合通信的平均延迟降低了多达35.1%

CPU瓶颈

• 混合RPC。Pangu团队发现RPC请求中序列化/反序列化消耗了30%的CPU，因此他们对数据链路使用类似FlatBuffer替代Protobuf，但是在控制链路依然使用ProtoBuf，最终优化后单核CPU网络吞吐增加了59%

• 使用CPU wait指令支持超线程。引入cpu wait指令解决超线程存在的同一个物理核线程切换的开销以及两个线程同时执行相互干扰带来的性能退化，最终单核CPU网络吞吐增加了31.6%

• 软硬件系统设计。引入可编程FPGA硬件，将数据压缩和CRC计算卸载到FPGA进行，同样的网络吞吐下，可以节省30%的CPU开销[3]

其他优化案例

• 进行大量的数据完整性校验。通过CRC确保数据的完整性，比如端到端的CRC、不同副本间CRC、随机副本CRC等

• 处理一些影响SLA的异常抖动。比如TCMalloc在申请内存时候如果触发了从全局内存申请则会产生延迟抖动，因此他们引入了用户空间的内存分配池，优化RDMA驱动使用匿名页。其次一些周期性的任务放到后台执行，比如打印日志，还有比如内存占用过高时候进行内存回收会导致很高的CPU使用率，因此调整了内存回收阈值减少回收的机会

• 处理USSOS中的可纠正机器检查异常(MCE)以提高可用性。增加后台守护进程去检测和处理MCE错误，一旦发现就会通知内核迁移故障的内存

• 对内存性能进行评估，不同供应商的内存带宽差异很大，如果都加入同一个集群可能带来延迟的抖动

经验教训

用户态系统

• 用户态系统的开发和运营比内核空间系统更简单。在Pangu的数据中，内核空间文件系统的错误修复需要约两个月的时间，而在USSFS中只需要几周的时间

• 开发用户空间系统应该借鉴内核空间的设计。为了构建高性能的USSOS，不仅需要统一存储和网络堆栈，还需要设计用户空间模块来管理内存、CPU调度和硬件故障处理

• 用户空间系统的性能提升不仅适用于高速存储设备，如SSD。Pangu的USSFS中提供了一系列机制来加速HDD的性能，例如利用自包含的块布局来减少元数据操作次数，利用磁盘内部和外部轨道的差异来提高写入效率

性能和成本

• 为了满足新的业务需求，Pangu通常首选添加更多硬件来提高性能，基于总拥有成本（TCO）平衡考虑（例如，将网络从25 Gbps升级到100 Gbps，通过增加更多小容量DRAM和升级更强大的CPU来增加内存通道数量）

• 硬件扩展有效地提高了Pangu的性能，但由于产生的成本不可持续，因此Pangu还花费了大量精力，例如流量优化，提高其资源利用率和效率

• 在性能和成本之间进行权衡是必要的，Pangu通过定期评估业务需求和硬件资源的使用情况来确保平衡

PMem

硬件卸载

• 硬件卸载的成本与收益权衡。Pangu硬件卸载压缩的整个开发过程用了20人团队两年时间，期间也解决了许多问题，如FPGA硬件成本、压缩数据的完整性以及与硬件中的其他功能共存等问题

• 硬件卸载的结果收益大大超过了成本。硬件卸载显著降低了压缩的平均延迟和尾延迟，有效降低了低延迟内的网络流量，服务的整体能力提高了约50%

• 内部先使用，然后逐步扩展到核心服务，整个过程中为了防止可能存在的硬件错误损害数据完整性，在硬件上执行数据解压缩和CRC检查，定期的进行软件CRC检查

• Pangu的所有200 Gbps集群默认启用硬件压缩，事故发生的次数越来越少

参考

1. Fisc: A Large-Scale Cloud-Native-Oriented File System

2. InfiniFS: An Efficient Metadata Service for Large-Scale Distributed Filesystems

3. OLARDB Meets Computational Storage: Efficiently Support Analytical Workloads in Cloud-Native Relational Database