阿里盘古

[lambertxiao]

摘要

本文介绍了盘古存储系统如何随着硬件技术和业务模式的不断发展，持续演进，以提供高性能、可靠的存储服务，实现100微秒级别的I/O延迟。盘古的演进包括两个阶段。在第一阶段，盘古积极拥抱固态硬盘（SSD）存储和远程直接内存访问（RDMA）网络技术的兴起，通过创新文件系统和设计用户空间存储操作系统，大幅降低了I/O延迟，同时提供了高吞吐量和IOPS。在第二阶段，盘古从以容量为导向的存储提供商转变为以性能为导向的存储提供商。为适应这一业务模式的转变，盘古升级了其基础设施，采用了更高容量的SSD和从25 Gbps升级到100 Gbps的RDMA带宽的存储服务器。它还引入了一系列关键设计，包括减少流量放大、远程直接缓存访问和CPU计算卸载，以确保盘古能够充分利用硬件升级带来的性能提升。除了技术创新，我们还分享了盘古在演进过程中的运营经验，并讨论了从中汲取的重要教训。

引言

自2009年阿里巴巴开始开发和部署盘古存储系统以来，盘古一直作为阿里巴巴集团和阿里云统一的存储平台。它为阿里巴巴的核心业务（如淘宝、天猫、蚂蚁金服和阿里妈妈）提供了可扩展、高性能和可靠的存储服务。许多云服务，如弹性块存储（EBS）、对象存储服务（OSS）、网络附加存储（NAS）、PolarDB和MaxCompute，都是基于盘古构建的。经过十多年的发展，盘古已经成为一个全球性的存储系统，拥有EB级别的数据量和数万亿个文件的管理能力。

盘古的演进不仅体现在技术层面的持续创新，更体现在对业务需求的深入理解和快速响应。随着云计算和大数据技术的飞速发展，阿里巴巴集团的业务规模不断扩大，对存储系统的性能、可靠性和扩展性提出了更高的要求。盘古团队紧密围绕业务需求，不断推动系统的优化和升级，以满足日益增长的数据存储和访问需求。

盘古的成功也得益于阿里巴巴集团强大的技术实力和丰富的行业经验。通过整合集团内部的资源和技术优势，盘古团队得以快速解决在研发过程中遇到的各种技术难题，确保系统的稳定运行和持续创新。

盘古 1.0

盘古系统从2009年开始开发部署，至今已经经历了两个阶段的演进。其中，Pangu 1.0阶段从2009年持续到2015年，主要面向空间容量的存储服务。以下是对Pangu 1.0的详细介绍：

Pangu 1.0的设计基础是通用的服务器资源，包括CPU和硬盘驱动器（HDD），这些资源具有毫秒级别的I/O延迟和吉比特每秒（Gbps）级别的数据中心网络。为了满足不同存储服务的需求，Pangu 1.0设计了一个基于Linux Ext4的分布式内核空间文件系统，并使用了内核空间的TCP。随着业务的不断发展，Pangu 1.0逐渐增加了对多种文件类型的支持，如TempFile（类似临时文件系统）、LogFile（支持Append-only的日志文件）以及支持随机读写的Random Access File。

这一时期与云计算的早期阶段相吻合。尽管Pangu 1.0的性能（即吞吐量和I/O延迟）已经达到了HDD和Gbps级别网络的极限，但客户的主要关注点仍然是获取大量空间来存储数据，而非追求高性能。

盘古 2.0

随着新型硬件技术的涌现，我们需要设计新的系统架构来充分利用这些技术的优势。自2015年起，我们开始设计和开发盘古2.0，以拥抱新兴的固态硬盘（SSD）和远程直接内存访问（RDMA）技术。盘古2.0的目标是为用户提供高性能的存储服务，实现100微秒级别的I/O延迟。

尽管SSD和RDMA在存储和网络方面能够实现高性能、低延迟的I/O操作，但我们在实践中发现了一些挑战：

首先，盘古1.0中使用的多种文件类型，特别是支持随机访问的文件类型，在SSD上的表现并不理想。虽然SSD在顺序操作中可以实现高吞吐量和IOPS（每秒输入/输出操作数），但在随机访问模式下性能不佳。

其次，传统的内核空间软件栈无法跟上SSD和RDMA的高IOPS和低I/O延迟。这是因为数据复制和频繁的中断会导致性能瓶颈。为了解决这个问题，我们决定设计一个用户空间的存储操作系统，以减少内核切换开销和数据拷贝次数。

最后，从以服务器为中心的数据中心架构向资源解耦的数据中心架构的转变，也给我们实现低I/O延迟带来了额外的挑战。为了应对这些挑战，我们升级了存储服务器的配置，采用了更高容量的SSD和RDMA带宽达到100 Gbps的网络。

盘古2.0通过创新文件系统和设计用户空间存储操作系统，成功地克服了这些挑战。它大幅降低了I/O延迟，同时提供了高吞吐量和IOPS。此外，盘古2.0还引入了一系列关键设计，如减少流量放大、远程直接缓存访问和CPU计算卸载，以充分发挥硬件升级带来的性能提升。

盘古2.0的第一阶段：通过文件系统重构和用户空间存储操作系统拥抱SSD和RDMA

为了实现高性能和低延迟的I/O，盘古2.0在这一阶段首先对其文件系统的关键组件提出了新设计。为了简化整个系统的开发和管理，盘古2.0设计了一个 统一的、仅追加 的持久性层。此外，它还引入了自包含的块布局，以减少文件写入操作的I/O延迟。

其次，盘古2.0设计了一个用户空间存储操作系统（USSOS）。USSOS 采用运行至完成线程模型，实现用户空间存储栈与用户空间网络栈之间的高效协作。它还提出了一种用户空间调度机制，以高效地分配CPU和内存资源。

第三，盘古2.0部署了相关机制，以便在动态环境下提供服务水平协议（SLA）保证。通过这些创新，盘古2.0在第一阶段实现了毫秒级的P999 I/O延迟。

盘古2.0的第二阶段：适应以性能为导向的业务模型，通过基础设施更新突破网络/内存/CPU瓶颈

自2018年起，盘古逐渐从以数量为导向的业务模型转变为以性能为导向。这是因为越来越多的企业正在将业务迁移到阿里云，并对存储性能和延迟提出了严格的要求。2020年新冠疫情爆发后，这种转变变得更快。为了适应业务模型的这种变化和客户群的快速扩张，盘古2.0需要不断升级其基础设施。

通过原始服务器和交换机以Clos为基础的拓扑结构（例如FatTree [8]）扩展基础设施并不经济，这会导致更高的总体拥有成本（例如机架空间、电力、冷却和劳动力）以及更高的环境成本（例如更高的碳排放率）。因此，盘古研发了内部的高容量存储服务器（每台服务器配备96TB SSD），并将网络带宽从25 Gbps升级至100 Gbps。

为了充分利用这些升级带来的性能提升，盘古2.0提出了一系列技术来应对网络、内存和CPU的性能瓶颈，并充分利用其庞大的资源。具体来说，盘古2.0通过减少网络流量放大比率和动态调整不同流量的优先级来优化网络带宽。它提出了远程直接缓存访问（RDCA）来解决内存瓶颈问题。同时，它还通过消除数据的序列化和反序列化开销以及引入CPU等待指令来同步超线程，从而解决CPU瓶颈问题。

盘古2.0在生产环境中表现出高性能。在第一阶段结束时，盘古2.0成功支持了弹性SSD块存储服务，实现了百微秒级的I/O延迟和100万IOPS。在2018年阿里巴巴的双11购物节期间，盘古2.0为阿里巴巴数据库服务提供了280微秒的延迟。对于OTS存储服务，在相同的硬件条件下，盘古2.0的I/O延迟比盘古1.0低一个数量级。对于写密集型服务（例如EBS云盘），P999 I/O延迟小于1毫秒；对于读密集型服务（例如在线搜索），P999 I/O延迟小于11毫秒。

在第二阶段，通过将网络从2×25 Gbps升级到2×100 Gbps，并突破网络、内存和CPU的瓶颈，泰山存储服务器的归一化有效吞吐量提高了6.1倍。这表明盘古2.0通过基础设施的升级和技术创新，成功适应了以性能为导向的业务模型，并显著提升了存储系统的性能。

[lambertxiao]

2 背景

2.1 盘古系统概览

盘古是一个大规模的分布式存储系统，它主要由盘古核心（Pangu Core）、盘古服务（Pangu Service）和盘古监控系统（Pangu Monitoring System）构成。盘古核心又包括客户端（clients）、主服务器（masters）和块服务器（chunkservers），并提供了一个仅追加的持久语义。

客户端提供SDK给盘古云存储服务（如EBS和OSS），并负责接收这些服务的文件请求，与主服务器和块服务器通信以满足这些请求。与其他分布式文件系统（如Tectonic和Colossus）类似，盘古中的客户端是重量级的，并在副本管理、服务等级协议（SLA）保证和数据一致性管理中发挥着关键作用。

盘古通过其创新的架构和设计，为大规模数据存储提供了高性能、高可用性和高可靠性的解决方案。这种系统对于处理大量数据、支持高并发访问和确保数据一致性等方面都具有显著优势，因此在云计算和大数据领域得到了广泛应用。

盘古的主服务器负责管理盘古中的所有元数据，并使用基于Raft的协议来维持元数据的一致性。为了更好地实现水平可扩展性和可伸缩性（例如支持数百亿个文件），盘古的主服务器将单一的元数据服务分解为两个独立的服务：命名空间服务和流元数据服务。其中，流是一组块的抽象。这两个服务首先通过目录树对元数据进行分区，以实现元数据的局部性，然后进一步使用哈希对这些组进行分区，以实现良好的负载均衡。命名空间服务提供有关文件的信息（例如目录树和命名空间），而流元数据服务提供从文件到块（即块的位置）的映射。块服务器以块的形式存储数据，并配备了定制的用户空间存储文件系统（USSFS）。USSFS为不同硬件（例如HM-SMR驱动的SMRSTORE）提供高性能、仅追加的存储引擎。在盘古2.0的早期阶段（即第一阶段），每个文件都存储在具有三个副本的块服务器中，之后垃圾收集工作器（GCWorker）执行垃圾收集并使用擦除编码（EC）存储文件。在盘古2.0的第二阶段，我们逐渐在关键业务（例如EBS）中用EC替换3路复制，以减少盘古中的流量放大。

在盘古核心之上，盘古服务通过面向云原生的文件系统（即Fisc）提供了传统的云存储服务（如EBS、OSS和NAS）以及云原生存储服务。盘古监控系统（例如Perseus）为盘古核心和盘古服务提供实时监控和AI辅助的根源分析服务。盘古核心、盘古服务和盘古监控系统的基础设施通过高速网络相互连接。

盘古服务的云原生存储服务是盘古架构中的一大亮点。它充分利用了云原生的优势，通过声明化的API实现对性能、容量、功能等方面的度量和声明，从而为用户提供更加灵活、高效的存储解决方案。同时，盘古服务还继承了底层存储变革的巨大红利，进入了亚毫秒级别时延和百万IOPS的时代，为用户提供了卓越的存储性能。

盘古监控系统的实时监控和AI辅助的根源分析服务，使得盘古系统能够及时发现并解决潜在的问题，保证了系统的稳定性和可靠性。通过高速网络的连接，盘古系统的各个组件能够高效地协同工作，为用户提供高质量的存储服务。

2.2 盘古2.0设计目标

为了应对硬件技术的不断涌现和业务模式的转变，盘古2.0旨在实现以下目标：

• 低延迟：盘古2.0旨在利用SSD和RDMA的低延迟特性，在计算与存储分离的架构中实现平均100微秒级别的I/O延迟，并在网络流量抖动和服务器故障等动态环境下提供毫秒级别的P999服务等级协议（SLA）。

• 高吞吐量：盘古2.0旨在使存储服务器的有效吞吐量接近其容量极限。

• 对所有服务的统一高性能支持：盘古2.0旨在为运行在其上的所有服务提供统一的高性能支持，如在线搜索、数据流分析、EBS、OSS和数据库等。

2.3 相关工作

许多分布式存储系统已经被设计和部署。其中一些是开源的（例如HDFS和Ceph），而另一些则是不同行业组织使用的专有系统（例如GFS、Tectonic和AWS）。

盘古是阿里巴巴集团的专有存储系统，为阿里巴巴的核心业务和阿里云提供存储基础设施支持。在过去的几年里，我们分享了盘古在不同方面的经验，例如RDMA的大规模部署、用于扩展云存储服务的键值引擎、EBS存储服务的网络和存储软件栈的协同设计，以及命名空间元数据服务的一些关键设计。

本文着重介绍了盘古如何适应硬件技术的出现和业务模式的转变，演进为提供统一低延迟、高吞吐量的存储服务，以支持阿里巴巴的所有业务和阿里云的经验。盘古的设计和实施充分展示了分布式存储系统在应对不断变化的业务需求和技术挑战时的灵活性和可扩展性。随着技术的不断进步，盘古将继续优化和完善，为阿里巴巴和阿里云提供更加高效、可靠的存储服务。

[lambertxiao]

3 第一阶段：拥抱SSD和RDMA

在这一阶段，盘古系统积极接纳SSD和RDMA技术的出现，以提供高性能、可靠且低I/O延迟的存储服务。与传统的HDD和TCP相比，SSD和RDMA技术分别在存储和网络层面大幅降低了I/O延迟。然而，将这两项技术集成到盘古这一大型、分布式且架构成熟的存储系统中，并非易事，面临着诸多挑战。

为此，盘古在其文件系统的关键组件中引入了一系列新的设计，并开发了一个用户空间存储操作系统。这些举措旨在实现高吞吐量、高IOPS性能，同时保持100微秒级别的I/O延迟。此外，盘古还部署了新颖的机制，以确保在动态环境下（如性能滞后节点和瞬时/永久故障）能够提供稳定的SLA保障。

3.1 Append-Only 文件系统

如图1所示，盘古的核心基础层由Master、Chunkserver和Client组成。盘古首先引入了一个统一的、仅追加的持久层，该持久层具有一个名为FlatLogFile的的仅追加接口，以简化其架构。FlatLogFile对于具有高通量和低延迟的SSD非常友好。然后，盘古采用了多种设计来提高其性能。具体来说，盘古Client为满足不同存储服务的需求而设计为重量级。基于FlatLogFile，盘古采用仅追加的块，并使用自包含的块布局在Chunkserver上管理块。盘古在Master上实现了分布式元数据管理，以实现高效的元数据操作。

盘古的这些设计使其能够充分利用SSD和RDMA的优势，提供高性能、可靠的存储服务。通过仅追加的持久层，盘古能够简化数据写入和管理的复杂性，提高系统的整体性能。重量级的Client设计则能够满足各种存储服务的需求，为不同的业务场景提供灵活的支持。此外，分布式元数据管理使得盘古能够高效地处理大量的元数据操作，进一步提升存储系统的性能和可靠性。

3.1.1 统一的仅追加持久层

盘古的持久层为所有盘古存储服务（如EBS、OSS和NAS）提供接口。在盘古的早期开发中，持久层为不同的存储服务提供了不同的接口。例如，它为低延迟的NAS服务提供了LogFile接口，为高吞吐量的Maxcompute数据分析服务提供了TempFile接口。然而，这种设计带来了大量的开发和管理复杂性。具体来说，对于每个存储服务，盘古的开发者都需要设计并实现新的接口。这是一个复杂、劳动密集且容易出错的过程。

为了简化盘古的开发和管理，并确保所有存储服务都能在SSD上实现高性能、低延迟的I/O操作，盘古借鉴了计算机网络的分层架构思想，引入了一种统一的文件类型，称为FlatLogFile（如图2所示）。具体来说，FlatLogFile具有仅追加的语义，上层服务（如OSS）可以配备类似键值对的映射来更新其数据，并使用垃圾回收机制来压缩其历史数据。FlatLogFile为存储服务提供了一个简单、统一的接口来执行数据操作。

此外，盘古的开发者必须确保通过FlatLogFile进行的数据操作，特别是写操作，能够在存储介质上高效可靠地执行。这样一来，存储服务的所有升级和更改对盘古开发者来说都是透明的，从而大大简化了盘古的开发和管理。

在底层实现中，我们观察到SSD由于其存储单元和闪存事务层的固有特性，可以在顺序操作上实现高吞吐量和IOPS（每秒输入/输出操作数）。为了确保通过FlatLogFile进行的数据操作可以在SSD上高效执行，我们对FlatLogFile上的顺序操作进行了对齐，以实现高性能。

具体来说，我们充分利用了SSD在顺序读写方面的优势，通过优化FlatLogFile的的设计，使得数据的写入和读取能够按照顺序进行，从而最大化地利用SSD的带宽和I/O性能。这种对齐操作不仅减少了SSD在处理随机I/O时的开销，还提高了数据的写入速度和读取效率。

此外，我们还对FlatLogFile的进行了其他优化，例如使用缓存机制来减少磁盘访问次数，以及采用压缩算法来减小存储空间的占用。这些优化措施进一步提升了盘古存储系统的整体性能，使其能够更好地满足各种应用场景的需求。

3.1.2 重量级Client

我们将盘古的Client设计为重量级，它负责与Chunkserver进行数据操作，以及与Master进行元数据信息的检索和更新。在从Master获取Chunk信息后，盘古Client负责执行相应的复制协议和纠删码（EC）协议。Client配备了重试机制（例如，在3.3节中提到的备份读取），以应对盘古中偶尔出现的抖动（例如，网络数据包丢失），从而改进I/O服务等级协议（SLA）。此外，Client还部署了探测机制，以定期从Master获取最新的Chunkserver状态，并评估Chunkserver的服务质量。

与Facebook的Tectonic文件系统Client类似，盘古Client可以选择适当的写或读参数，以满足不同存储服务（如EBS和OSS）的具体要求。这种设计使得盘古能够灵活地适应不同的应用场景和工作负载，提供了更高的可配置性和灵活性。

重量级Client的设计虽然增加了系统的复杂性，但也带来了显著的优势。它使得Client能够更深入地参与数据管理和操作过程，提高了系统的整体性能和可靠性。同时，通过Client的智能选择和配置，盘古能够更好地满足各种存储服务的需求，为用户提供更优质、更高效的存储体验。

3.1.3 仅追加的块管理

典型的文件系统（如Ext4 [6]）以块的形式存储文件。一个文件及其元数据会被分别写入存储介质，这需要两次SSD写操作。这不仅增加了文件写入的延迟，还缩短了SSD的使用寿命。因此，如果在盘古2.0中采用这种设计，会导致文件访问的高延迟，并增加硬件更换的成本。

为了解决这个问题，盘古选择在Chunkserver上以基于FlatLogFile的的仅追加语义存储文件块，并设计了一种自包含的块布局，其中每个块既存储数据又存储其自身的元数据。这样，一个块可以通过一次操作写入存储介质，而不是两次，从而大大降低了写延迟并延长了存储介质的使用寿命。图3展示了块的布局。一个块包括多个扇区单元，每个扇区单元包含三个元素：数据、填充和页脚。页脚存储块的元数据，如块ID、块长度和CRC校验和。

自包含的块布局还允许Chunkserver自己从故障中恢复。具体来说，当客户端将连续的自包含块写入存储介质时，Chunkserver会在内存中存储这些块的元数据的副本，并定期将这些信息的检查点写入存储介质。当发生故障导致一些未完成的写操作发生时，Chunkserver会从检查点加载元数据，并与块中的元数据进行比较。如果发生差异，Chunkserver会检查块的CRC以恢复到最新的正确状态。

3.1.4 元数据操作优化

盘古主节点提供了两种元数据服务：命名空间服务负责目录树和文件的管理，而流服务负责块信息的管理。流是多个块的抽象，同一流中的块属于同一个文件。为了提高可扩展性，这两种服务都采用了分布式架构。它们通过考虑元数据的局部性和负载均衡（即先按目录树分区，再按哈希值分区）来进行元数据分区。我们设计了多种机制来优化元数据操作的效率。

并行元数据处理。命名空间和流服务都采用了并行化处理（例如，InfiniFS [13]）以满足元数据访问的低延迟要求。具体来说，盘古使用哈希算法将高度聚合的元数据映射到不同的元数据服务器上。它还使用了一种新的数据结构，该结构支持可预测的目录ID，并允许客户端并行地高效地执行路径解析。

此外，我们还引入了几种技术来加速客户端从流服务中检索块信息的速度。这些技术可能包括优化查询算法、使用缓存机制来存储常用块信息，或者通过负载均衡策略来平衡不同元数据服务器之间的负载，以确保高效的块信息检索。通过这些方法，盘古能够在处理大规模分布式文件系统中的元数据时实现更高的性能和更好的用户体验。

大小可变的块。 盘古 2.0 选择使用大块的策略。这一决策带来了三个好处。它减少了元数据的数量。它避免了客户端频繁请求块所导致的不必要的 I/O 延迟。此外，它还有助于延长 SSD 的使用寿命。然而，简单地增加块的大小会增加碎片化的风险。因此，我们引入了大小可变的块（例如，大小范围从 1 MB 到 2 GB）。例如，EBS 服务的块大小有 95% 的分位数为 64 MB，99% 的分位数为 286.4 MB。可变块长度减少了碎片化的可能性，并保持了与盘古 1.0 的兼容性。

客户端缓存块信息。 每个客户端都维护一个本地元数据缓存池，以减少元数据查询请求的数量。该缓存池使用基于 LRU（最近最少使用）的机制进行更新。当应用程序需要访问数据时，客户端首先查询其元数据缓存。在以下情况下，客户端会向主节点发出新请求以获取最新的元数据：（1）缓存未命中；（2）缓存命中，但在响应请求时，相应的块服务器通知客户端其缓存的元数据已过时（例如，由于副本迁移）。这种缓存机制可以显著提高元数据访问的速度和效率，减少网络传输的负载，从而提升整个分布式文件系统的性能。

块信息请求批量处理。 我们允许每个客户端在短时间内聚合多个块信息请求，并将它们以批处理的方式发送给主节点，以提高查询效率。主节点并行处理这些批量请求，聚合结果，并将它们发送回客户端。客户端将结果拆分并分发给相应的应用程序。

这种批量处理的方法可以显著减少网络往返次数和通信开销，尤其是在处理大量小块文件或高并发访问的场景中。通过将多个请求合并成一个批量请求，可以减少单个请求的延迟，并提高整体吞吐量。主节点能够并行处理这些请求，从而充分利用其计算资源，并快速返回结果。客户端收到结果后，再将其拆分成单个的响应，并分发给相应的应用程序。

通过这种方式，我们能够在保持低延迟的同时，提高元数据操作的效率，进一步优化分布式文件系统的性能。

推测性块信息预取。 我们设计了一种贪婪的、概率性的预取机制，以减少块信息请求的数量。当主节点接收到读取请求时，它们除了返回相关块的元数据外，还会返回其他块的元数据。当主节点接收到写入请求时，它们返回的可用块比客户端请求的要多。这样，如果客户端遇到写入异常，它可以在不请求新块的情况下切换块。

数据捎带以减少一次往返延迟（RTT）。 我们受到QUIC [25]和HTTP3 [26]的启发，使用数据捎带技术来改进写入延迟。具体来说，在客户端从主节点检索到块地址后，它将块创建请求和要写入的数据合并成一个请求，并发送给块服务器。通过这种方式，我们能够减少一次往返延迟（RTT），从而降低写入延迟。

[lambertxiao]

3.2 Chunkserver USSOS

在盘古中，块服务器负责执行所有的数据操作。因此，精心设计运行时操作系统以确保数据操作能够以低延迟和高吞吐量完成至关重要。随着高速网络技术和存储媒体的不断发展，坚持传统的设计将数据操作通过内核空间进行是低效的。这不仅会导致频繁的系统中断，消耗CPU资源，还会在用户空间和内核空间之间造成不必要的数据重复。

为了应对这些问题，我们采用了绕过内核的设计，为块服务器开发了一个高性能的用户空间存储操作系统（USSOS），它提供了一个统一的用户空间存储软件平台。除了实现设备管理和运行至完成线程模型（Run-to-Completion Thread Model）在USSOS中，盘古还实现了用户级内存管理（§3.2.1）、轻量级用户空间调度策略（§3.2.2），以及为SSD定制的高性能仅追加用户空间存储文件系统（USSFS）（§3.2.3）。

通过采用这些设计，我们能够减少系统开销，提高存储操作的效率和性能。用户级内存管理允许我们在用户空间直接管理内存，避免了内核空间与用户空间之间的数据拷贝。轻量级用户空间调度策略能够更灵活地分配和管理计算资源，以适应不同工作负载的需求。而高性能仅追加用户空间存储文件系统则针对SSD的特性进行了优化，能够充分利用SSD的性能优势，提供快速且可靠的数据存储服务。

3.2.1 用户级内存管理

Chunkserver USSOS的构建基于现有的用户空间技术，例如网络堆栈中的RDMA，以及存储堆栈中的DPDK和SPDK。但我们不仅限于此，还进一步统一了这两个堆栈，以进一步减少数据操作的延迟并提高性能。

首先，我们采用了运行至完成的线程模型。与传统的管道线程模型不同，后者将一个请求分解为多个阶段，每个阶段都在一个线程上运行。而在USSOS中，请求从始至终都在一个线程上运行，这减少了上下文切换、线程间通信和线程间同步所带来的开销。

其次，线程请求一个巨大的页面内存空间，作为网络堆栈和存储堆栈之间的共享内存。具体来说，通过RDMA协议，从网络接收的数据可以存储在这个共享的巨大页面内存中。在发送了巨大页面内存的元数据（如地址和大小）之后，数据可以直接从巨大页面内存通过SPDK框架写入存储介质。这样，在数据传输和存储过程中，我们实现了网络堆栈和存储堆栈之间的零拷贝。

此外，通过用户级共享的巨大页面内存进行I/O数据传输，不同角色（如块服务器和垃圾收集工作线程）之间的数据传输操作也可以实现零拷贝。

3.2.2 用户空间调度机制

在真实生产环境中，我们遇到了由任务调度等问题带来的性能故障。这里，我们介绍了三个关键设计来优化USSOS中的CPU调度，以提高盘古的性能。

防止任务阻塞后续任务。 正如在3.2.1节中解释的，运行至完成的线程模型通过使用共享的巨大页面内存，有助于在用户空间网络和存储堆栈之间实现零拷贝。然而，每个块服务器都有固定数量的工作线程。新的请求会根据请求中文件的哈希值被派发到一个工作线程。分配给同一工作线程的请求将按照先到先服务的顺序执行。因此，对于某个请求，如果其中一个任务花费太多时间（例如，表查找、表搜索、遍历、内存分配、监控和统计），它将占用资源并阻塞后续任务。这个问题降低了该请求的性能，并导致其他请求得不到处理。

为了解决这个问题，我们针对不同场景采取了不同的措施。对于繁重的任务，盘古引入了心跳机制来监控任务的执行时间并设置警报。如果任务超出了时间片，它将被放入后台线程，从关键路径中移除。对于系统开销，盘古使用TCMalloc的缓存来允许高频操作在缓存中完成。

这种用户空间调度机制的设计，不仅提高了任务处理的效率，还确保了系统的稳定性和性能。通过合理调度和分配CPU资源，我们可以更好地满足盘古在高并发、大规模数据处理场景下的需求，为用户提供更优质的服务体验。

优先级调度以保证高QoS。 盘古为不同的请求分配了不同的QoS目标（例如，用户请求被分配为高优先级目标，而垃圾收集请求被分配为低优先级）。然而，具有低优先级目标的请求可能会阻塞后续到达的高优先级请求，如果这些请求被分配到了同一个工作线程。因此，很难保证具有更高QoS目标的请求总是能够获得更高的优先级。为了解决这个问题，USSOS创建了优先级队列。这样，任务可以根据它们的QoS目标被放入相应的优先级队列中。

轮询和事件驱动切换（NAPI）。 USSOS采用轮询和事件驱动模式之间的切换机制，以减少在CPU利用率较低时处理大量中断的开销[30]。具体来说，网络接口卡（NIC）提供了一个由应用程序监视的文件描述符（fd），并通过fd事件通知应用程序数据的到达。应用程序默认处于事件驱动模式。当它们从NIC收到通知时，它们会进入轮询模式。如果它们在一段时间内没有收到任何I/O请求，它们会切换回事件驱动模式，并通知NIC。

3.2.3 仅追加的USSFS

先前的文件系统（例如Ext4）无法充分利用仅追加的FlatLogFile（3.1.1节）以及具有高吞吐量和低延迟的SSD。因此，盘古超越了这些限制，并定制了USSFS，一个紧凑且高性能的用户空间存储文件系统。

利用FlatLogFile的的仅追加语义，USSFS支持仅追加写操作，并提供了一套基于块（chunk）的语义，如打开、关闭、密封、格式化、读取和追加，而不是像Ext4那样的标准POSIX语义。在此基础上，它支持仅追加的顺序写操作，充分利用SSD的顺序写友好特性，以及成功写入数据的随机读取。同时，USSFS采用不同机制来最大化SSD的性能。

密封用于标记一个或多个数据块（chunks）为不可变状态

首先，它可以充分利用自包含的块布局（3.1.3节），在不使用页面缓存和日志等机制的情况下，显著减少数据操作的数量。其次，它不像Ext4那样在inode和文件目录之间建立层次关系。所有对文件的操作都记录到日志文件中。在挂载文件系统时，可以通过重播日志来重建相应的元数据。第三，我们使用轮询模式，而不是像Ext4那样的中断通知机制，以最大化SSD的性能。

此外，考虑到单个SSD节点的容量可达数十甚至数百TB，而块的大小通常为64MB，我们在USSFS中将最小空间分配粒度设置为1MB。这一选择既考虑了空间管理元数据所使用的内存大小，也考虑了SSD的空间利用率。

[lambertxiao]

3.3 高性能SLA保证

盘古引入了多种机制来提供高性能以及在故障场景下的毫秒级P999 SLA保证。这些机制旨在确保系统在各种异常情况下都能快速恢复并维持高性能。

• Chasing机制：用于应对异常抖动，例如由网络突发或网络拥塞导致的包重传。在这些场景中，集群操作环境可能会出现异常，但系统能够在短时间内自动恢复到正常状态。

• 非停止写入：主要针对不可用的块。当系统检测到某些块不可用时，非停止写入机制会确保写入操作不会因此而中断，从而维持了数据的一致性和完整性。

• 备份读取：当读取请求在限定时间内无法返回时，备份读取机制能够减少延迟。它通过从备份源获取数据来确保读取操作的顺利进行，从而提高了系统的可用性和响应速度。

• 黑名单机制：用于隔离提供劣质服务或发生故障的chunkservers。通过将表现不佳的服务器加入黑名单，系统可以避免进一步的数据丢失或服务中断，同时确保整体性能的稳定。

Chasing机制

Chasing机制特别设计用来应对系统中的异常抖动，如网络突发状况或数据包重传等导致的性能下降。Chasing机制的核心思想是允许客户端在部分副本成功写入后，即可返回成功给应用程序，同时继续等待剩余副本的写入完成。

具体来说，当应用程序请求客户端将数据写入到多个chunk副本时（例如，写入数据[1, 2, 3]到3个chunk副本），Chasing机制会确保在MinCopy个副本成功写入后，客户端即可向应用程序返回成功。这里，MinCopy和MaxCopy是系统配置的参数，分别代表最小和最大副本数。

假设MaxCopy = 3且MinCopy = 2，那么在图4所示的场景中，当chunkserver 1和2成功返回写入成功的确认，但chunkserver 3尚未返回时，客户端仍然会向应用程序返回成功。随后，客户端会保留该chunk在内存中，并等待一个额外的时间段t（这是一个经验性的毫秒级阈值）。

如果在T + t时刻之前，chunkserver 3也返回了写入成功的确认，那么客户端会释放内存中的chunk。 如果chunkserver 3没有完成写入，但尚未完成的部分小于一个经验性的阈值k，客户端会尝试在chunkserver 3上进行重试。 如果未完成的部分大于k，客户端会在chunkserver 3上密封这个chunk，确保它不会再进行后续的追加操作。随后，客户端会通知主节点（masters），主节点会负责从chunkserver 1或2复制数据到另一个不同的chunk，以确保最终有总共3个副本。

我们的分析表明，通过精心选择t和k的值，Chasing机制能够显著减少写操作的尾部延迟，同时不会增加数据丢失的风险。具体来说，以MaxCopy = 3的情况为例，当两个副本成功写入chunkservers后，系统中就有了三个副本，其中第三个副本仍然保存在客户端的内存中。在[T,T + t]时间段内，数据丢失只可能发生在以下情况：两个chunkserver副本的SSD损坏，同时客户端内存中的最后一个副本也失效，或者整个集群断电。由于SSD的年故障率（即约1.5% [32-37]）和服务器的年停机率（即小于2% [38, 39]）相近，因此当两个副本成功写入而第三个副本处于Chasing状态时，数据丢失的概率与所有三个副本都成功写入时的概率大致相同。盘古系统已经部署Chasing机制十多年，并且从未因Chasing机制而导致数据丢失。最近的研究也开始关注这种早期写入确认机制[40-42]。

非停止写入

我们设计此机制是为了在块写入失败时减少写入延迟。当写入失败发生时，客户端会密封这个块，并向主节点报告成功写入的数据长度。然后，它使用一个新的块来继续写入未完成的数据。如果已密封块中写入的数据损坏，我们会利用其他副本在后台流量中复制一份此数据到新的块中。如果没有可用的副本，客户端会再次将这部分数据写入新的块。

备份读取

为了减少动态环境下的读取延迟，客户端在接收到之前发送的读取请求的响应之前，会向其他chunkservers发送额外的读取请求作为备份。这种机制有两个关键参数：发送备份读取请求的数量和等待时间。为此，盘古系统会计算不同磁盘类型和I/O大小的延迟，并利用这些信息来动态调整发送备份读取请求的时间。同时，它还会限制备份读取请求的数量，以控制系统负载。

黑名单机制

为了避免向服务质量较差的chunkservers发送I/O请求，盘古系统引入了两个黑名单：确定性黑名单和非确定性黑名单。当盘古系统确定某个chunkserver无法提供服务（例如，chunkserver的SSD损坏）时，该服务器将被添加到确定性黑名单中。如果一个chunkserver能够提供服务，但其延迟超过某个阈值，它将以与其服务延迟成正比的概率被添加到非确定性黑名单中。如果服务器的延迟超过所有服务器中位延迟的几倍，它将直接以100%的概率被添加到非确定性黑名单中。为了从黑名单中释放服务器，客户端会定期（例如，每秒）向这些服务器发送I/O探测。如果确定性黑名单上的服务器成功返回该请求的响应，它将被从黑名单中移除。对于非确定性黑名单上的服务器，盘古系统会根据接收该请求响应的时间来决定是否将服务器从黑名单中移除。

盘古系统限制了黑名单上服务器的总数，以确保系统的可用性。对于每个服务器，它引入了一个添加/移除黑名单的宽限期，以维持系统的稳定性。此外，由于TCP和RDMA链路中失败的服务器可能不同，盘古系统分别为TCP和RDMA链路维护了单独的黑名单，并在两个链路上进行I/O探测以更新它们。

[lambertxiao]

3.4 评估

图5展示了在2018年双11节期间，当每秒事务数达到55万次的峰值时，Pangu数据库（DB）访问的延迟情况。这一峰值至少是非节日期间的10倍以上。该数据库包含数百万个数据库（例如，淘宝商家的数据库），每个数据库都包含数百万电商用户的数据。在此过程中，数据库需要查询用户的订单并记录交易。在如此高的事务处理速率下，访问延迟低于280微秒，这证明了Pangu 2.0的高性能。

图6展示了使用相同的SSD和25Gbps网络的云产品OTS [9]查询的延迟。在相同的查询压力下，从Pangu 1.0升级到Pangu 2.0后，查询延迟几乎减少了一个数量级。这主要是因为Pangu 2.0中读写操作的低延迟以及单线程处理能力的提升。

图7和图8分别展示了一个月内两个集群（在线EBS和在线搜索业务）的平均延迟和长尾延迟。在线EBS是写密集型的，其在线读写比接近1:10，期望在写操作上实现高吞吐量。如图7所示，其长尾延迟小于1毫秒。在线搜索业务主要为阿里巴巴电商的查询和推荐服务（例如，在淘宝和天猫上搜索商品），期望在读操作上实现高吞吐量。如图8所示，一个月内读操作的长尾延迟小于5毫秒。这些结果表明，Pangu 2.0对延迟SLA有很好的保障。

[lambertxiao]

第二阶段：适应以性能为导向的业务模式

自2018年起，盘古逐渐从以容量为导向的存储提供商转变为以性能为导向的提供商。这一业务模式的转变以及盘古客户群的快速扩张，要求盘古不断升级其基础设施。然而，在基于Clos拓扑结构的基础上，继续使用原有的服务器和交换机来扩展基础设施，在多方面都是不经济的，包括更高的财务和环境成本（例如，更高的碳排放率）。因此，盘古开发了自己的内部存储服务器泰山。泰山服务器配备了2×24核的Skylake CPU、12×8TB的商品级SSD、128GB DDR内存以及2×双端口100 Gbps的NIC。尽管我们目前可以继续增加其存储容量，但为了维持高水平的写入IOPS/GB，以适应以性能为导向的业务模式的需求，我们选择不这样做。得益于SSD制造商的优化（例如，缓存和通道），单个泰山服务器的SSD吞吐量可以达到20 GB/s以上。

拥有如此高性能的存储服务器，我们自然会发现其他资源（例如，网络、内存和CPU）成为盘古的性能瓶颈。因此，我们将盘古的网络从25 Gbps RDMA升级到100 Gbps。然而，与人们的普遍认知相反，在这样一个升级后的基础设施中提供高性能、低延迟的I/O并非易事。这是因为新硬件在大规模部署中也带来了新的技术挑战。为此，我们提出并部署了一系列新颖的技术来优化盘古庞大网络（第4.1节）、内存（第4.2节）和CPU资源（第4.3节）的运行。

4.1 网络瓶颈

盘古从两个方面对网络进行了优化：网络带宽扩展（第4.1.1节）和流量优化（第4.1.2节）。

4.1.1 带宽扩展

为了匹配单个存储节点上所有SSD的吞吐量，盘古将网络带宽从25 Gbps升级到100 Gbps，以提高其网络能力。网络带宽扩展的成功取决于软硬件的改进。在硬件方面，盘古采用了高性能的NIC/RNIC、光模块（QSFP28 DAC、QSFP28 AOC、QSFP28 [43]）、单模/多模光纤以及高性能交换机。在网络软件栈方面，盘古首先采用了无损RDMA，并提出了各种机制以实现大规模RDMA部署，例如当RDMA网络上出现过多的暂停帧时，关闭NIC端口或短时间（例如，几秒钟）内将RDMA切换到TCP [17]。然而，这些机制无法解决基于暂停帧的流量控制的其他问题（例如，死锁[44]和队头阻塞[45, 46]）。因此，盘古升级到了有损RDMA，其中禁用了暂停帧，以避免这些问题并提高性能。关于带宽扩展的更多细节（例如，我们如何解决异构网络软硬件的互操作性问题）可以在我们早期的论文[17]中找到。

4.1.2 流量优化

除了提高网络能力外，我们还通过减少流量放大倍数来解决网络瓶颈问题。具体来说，流量放大倍数是通过网络传输的数据量与实际文件大小的比值来计算的。以EBS服务的工作流程为例（图9）。首先，EBS客户端将文件（1x）发送到盘古客户端（步骤（a））。其次，盘古客户端将文件传输到3个存储节点以写入3个副本（3x）。第三，垃圾收集器（GCWorker）读取文件（1x）并对其执行垃圾收集操作。为了简化说明，我们忽略了GC前后文件大小的变化。最后，文件以EC（8，3）的形式（1.375x）写回存储节点，这提供了与3个副本相同的容错级别，但使用了更少的存储空间。因此，文件写入的流量放大倍数可能高达6.375x（1x+3x+1x+1.375x）。换句话说，在100 Gbps的网络中，EBS的最大数据访问带宽小于16 Gbps。为了应对高流量放大倍数限制盘古服务能力的问题，我们引入了两项优化：EC（纠删码）和数据压缩。

使用EC代替3副本机制

使用EC（纠删码）代替3副本机制可以在实现良好容错级别的同时，大幅减少网络流量放大倍数。以图9为例，如果我们使用EC（4，2）（步骤（b1））来代替3副本步骤，网络流量放大倍数可以从6.375x降低到4.875x，即步骤（a）、（b1）、（c1）和（d1）的总和。

在进行这种替换时，会遇到两个挑战。首先，由于需要对固定长度的数据进行EC操作，因此存储小文件时需要大量的零填充，这会导致空间浪费。为了应对这一问题，我们引入了多种机制，包括小写请求聚合以及EC和3副本之间的动态切换。其次，计算EC会引入不可忽视的延迟。为此，盘古采用了Intel ISA-L，与Jerasure相比，它可以将计算EC的延迟减少2.5到3倍。

压缩FlatLogFile

我们观察到FlatLogFile存在高度的冗余性。因此，盘古客户端和GCWorker在写入文件之前都会对其进行压缩，以进一步减少流量（例如，图9中的步骤（b2）和（d2））。我们选择LZ4算法来实现高效的压缩和解压缩。盘古中的实证数据显示，平均压缩率可以达到50%。因此，在上面的例子中，步骤（b2）、（c2）和（d2）的流量放大倍数都可以减少一半。结果，流量放大倍数可以进一步从4.875x降低到2.9375x，即步骤（a）、（b2）、（c2）和（d2）的总和。

前端与后台流量之间的动态带宽分配

我们动态调整后台流量可用的网络带宽阈值。例如，如果整个存储集群中有足够的空闲空间，我们会临时降低阈值以限制后台流量（如垃圾收集流量）的带宽，并允许前端流量使用更多的带宽。对于淘宝这样的平台，盘古从白天到午夜会设置一个较低的阈值，以应对大量的前端访问请求。午夜之后，随着前端流量的减少，盘古会提高这个阈值。

[lambertxiao]

4.2 内存瓶颈

盘古面临的基本内存瓶颈在于接收端主机中网络进程（即NIC执行DMA操作）和应用进程（如数据拷贝、数据复制和垃圾收集）之间对内存带宽的高竞争。由于NIC无法获取足够的内存带宽，会产生严重的PCIe回压。这导致NIC缓冲区充满在途数据包，最终会丢弃溢出的数据包，触发网络中的拥塞控制机制，从而导致整体性能下降（即每台服务器网络吞吐量下降30%，延迟增加5%-10%，IOPS下降10%）。这种现象并非盘古独有，谷歌最近也报告了类似的问题[50]。

我们分三步解决这一内存带宽瓶颈。首先，我们在服务器上增加更多小容量的DRAM，以充分利用内存通道。其次，我们将后台流量从TCP切换到RDMA，以减少服务器对内存带宽的消耗（§4.2.2）。最后，我们设计了远程直接缓存访问（RDCA），将内存移出接收端主机的数据路径，并让发送端直接访问接收端的缓存（§4.2.3）。

4.2.1 增加小容量DRAM

由于瓶颈在于内存带宽而非内存容量，我们在服务器上增加了更多小容量的DRAM（例如16GB），以充分利用内存通道，并提高每台服务器可用的内存带宽。我们还启用了非均匀内存访问（NUMA），以避免跨插槽的内存访问受到Ultra Path Interconnect的限制[51]。

4.2.2 将后台流量从TCP切换到RDMA

在25-Gbps网络中，盘古使用TCP传输后台流量，以确保前端流量的服务质量，因为25-Gbps交换机上只有一个用于RDMA传输的硬件队列。

随着网络升级到100 Gbps，盘古开始使用RDMA传输后台流量，以减少网络进程对内存带宽的消耗。这是因为TCP至少需要比RDMA多四次内存拷贝。通过切换到RDMA，后台流量消耗的内存带宽减少了约75%。为了保证前端流量的服务质量，我们设计了一个类似于Linux tc[52, 53]的主机速率控制机制，以控制注入网络的后台流量速率。

4.2.3 远程直接缓存访问

除了增加可用的内存带宽和减少不必要的内存带宽消耗外，我们还提出了远程直接缓存访问（RDCA）架构，让发送端绕过接收端的内存，直接访问其缓存。这一设计基于盘古生产工作负载中的一个重要观察：数据在离开NIC后在内存中停留的时间非常短（即平均数百微秒）。假设NIC后平均停留时间为200微秒，对于双端口100 Gbps的NIC，我们只需要5MB的临时存储空间来存储离开NIC的数据。虽然其他缓存访问技术（如DCA[54, 55]和DDIO[56]）已经被提出，但它们都存在泄漏DMA问题（即新到达的消息频繁触发缓存驱逐[57, 58]）。相比之下，RDCA有了实质性的进步，它表明我们可以通过以下三个组件，回收一小部分LLC（最后一级缓存）来支持NIC以线路速率进行操作：

• 缓存常驻缓冲区池。该池使用共享接收队列（SRQ）来接收小消息，并为接收大消息配备了一个带有基于窗口的速率控制机制的READ缓冲区，这样RDMA操作所需的内存缓冲区就可以放入缓存中。

• 快速缓存回收。为了支持100 Gbps的NIC以尽可能少的LLC（最后一级缓存）在线路速率下运行，我们设计了快速缓存回收机制，通过（1）沿管道并行处理数据，以及（2）使用硬件卸载和轻量级（反）序列化来优化处理，从而减少数据在NIC后的停留时间。

• 缓存压力感知逃逸机制。为了应对偶尔的抖动（例如SSD写入缓慢和应用异常），逃逸机制会监控预留LLC的使用情况并采取相应的行动，包括（1）通过向缓存常驻缓冲区池添加新缓冲区来替换掉落后数据的缓存缓冲区，这样RDCA中可用的缓存大小就可以保持不变，以适应新到达的请求；（2）如果发生了太多替换，则主动将运行缓慢的应用程序的数据复制到内存中，以便其他应用程序可以使用RDCA缓冲区池，并且该池不会占用太多缓存；（3）如果复制到内存失败或不足以释放缓存压力，则让NIC在拥塞通知数据包中标记显式拥塞通知（ECN）以指示拥塞。

我们利用Intel的DDIO[56]在商用硬件上实现了RDCA。在盘古的一些集群中进行的广泛评估结果表明，对于典型的存储工作负载，RDCA每个服务器消耗12MB LLC缓存（占总缓存的20%），平均内存带宽消耗降低了约89%，网络吞吐量提高了9%。我们还发现，RDCA在非存储工作负载中也是有效的，例如，它可以将延迟敏感型HPC应用中集体通信的平均延迟降低高达35.1%。RDCA已于2022年底在盘古中推出。

[lambertxiao]

4.3 CPU瓶颈

即使在打破了网络和内存瓶颈之后，盘古在100 Gbps网络中的吞吐量仍然只能达到其理论值的80%。这是因为诸如数据序列化和反序列化、数据压缩以及数据CRC计算等操作消耗了大量的CPU资源，使得CPU成为盘古的另一个瓶颈。为此，盘古采用了一种混合设计来减少（反）序列化操作（§4.3.1），使用特殊的硬件指令CPU Wait来充分利用CPU（§4.3.2），以及采用硬件/软件协同设计[59]将CRC计算和数据压缩卸载到硬件（§4.3.3）。

4.3.1 混合RPCs

在盘古中，使用Protobuf[60]对RPC请求进行序列化和反序列化大约占用了30%的CPU开销。我们观察到，这种开销主要发生在数据路径上，且仅涉及少数几种RPC类型。因此，我们采用了一种混合设计来处理这个问题。我们将数据路径操作切换为使用类似于FlatBuffer[61]的原始结构，以便直接发送和接收数据而无需进行序列化。盘古仍然使用Protobuf来处理控制操作，因为它具有灵活性和复杂性。结果，每个CPU核心的网络吞吐量提高了约59%。

4.3.2 使用CPU Wait支持超线程

盘古最初并未使用超线程（HT）[62]，但随着CPU核心资源的日益稀缺，开始采用超线程技术。然而，超线程存在两个主要的性能问题。首先，一个物理核心上的两个超线程需要切换上下文。其次，当两个超线程同时执行任务时，一个超线程的执行会影响另一个超线程，导致两个任务的延迟都增加。例如，当网络空闲轮询线程在一个超线程上运行，而另一个超线程（来自同一物理核心）正在使用LZ4算法[49]和lzbeach[63]压缩4KB数据时，与压缩线程独占物理核心的情况相比，数据压缩的延迟增加了25%。

为了解决这两个问题，盘古引入了CPU wait指令。它包含monitor和mwait。盘古调用它们需要的时间不到5毫秒。回顾上面的例子，在引入CPU wait之后，网络空闲轮询线程将在受监控的内存地址上执行mwait，直到其他线程写入该内存地址才唤醒。在mwait过程中，它所运行的超线程进入空闲睡眠状态，即C-States中除C0之外的状态[64, 65]，不会干扰另一个超线程。此外，使用系统调用唤醒超线程的时间为毫秒级别。因此，盘古可以充分利用CPU核心并实现高性能。在这个例子中，与不使用CPU wait的情况相比，网络吞吐量提高了31.6%。

4.3.3 硬件与软件协同设计

为了实现高性能，盘古将一些任务从CPU卸载到可编程硬件上。首先，数据压缩被卸载到基于FPGA的计算存储驱动器上[66]。在3 GB/s的吞吐量下，基于硬件的FPGA压缩可以节省大约10个物理核心（Intel Xeon Platinum 2.5 Ghz）。其次，CRC计算被卸载到支持RDMA的网络接口卡（NICs）上，这些NICs计算每个数据块的CRC。然后，CPU将这些CRC进行聚合，并执行轻量级检查[18]。这种设计确保了低CPU开销和高应用级数据完整性。在相同的吞吐量下，与使用软件相比，使用硬件进行CRC计算可以节省30%的CPU开销。

4.4 评估

图10展示了EBS和高性能ESSD上存储节点性能发展路线图上的归一化有效吞吐量（NETPSN）。

阶段1. 为了更好地说明Pangu 2.0的性能发展，我们在Pangu引入2 × 25-Gbps网络和4-TB SSD时，将NETPSN初始化为1。

阶段2. 随着SSD容量增加到8 TB且性能更高，Pangu引入了100-Gbps网络。网络带宽为100 Gbps，因为服务器支持PCIe gen3。尽管网络带宽翻倍，但NETPSN从1增加到1.7而不是2。这是因为读写操作的内存带宽达到了90 GB/s，接近服务器的最大内存带宽（105 GB/s）。

阶段3. 内存带宽不足导致NICs处数据包丢失，进而导致吞吐量大幅下降。通过第4.2节的内存带宽优化，我们成功地将NETPSN增加到2。

阶段4. 在引入PCIe gen4后，网络吞吐量增加到2×100 Gbps。网络带宽翻倍，但NETPSN并没有，即从3.3增加到4，而是增加到3.3，这是由于流量放大问题（约6倍）。

阶段5. 在Pangu客户端采用EC(4, 2)、数据压缩和其他优化后，流量放大比降低了一半（∼3倍）（第4.1节）。然而，NETPSN增加到5而不是6.6。主要原因是数据压缩和其他操作消耗了大量CPU资源。

阶段6. 为了解决CPU瓶颈，Pangu将任务（如数据压缩和CRC）从CPU卸载到硬件（第4.3节），最终将NETPSN增加到6.1。

[lambertxiao]

5 运营经验

在介绍了Pangu 2.0的设计创新后，接下来我们将介绍Pangu的基本运营周期，重点关注Pangu监控系统，并分享我们在解决Pangu运营过程中遇到的一些重要问题的经验。

5.1 Pangu的运营周期

Pangu的基本运营周期包括五个阶段：规划、开发、测试、部署和监控。在进入开发阶段之前，新的硬件和软件解决方案会经过严格的规划阶段（即可行性分析、效益成本分析以及社会和法规研究）。在开发和部署之间，我们会在各种场景下对这些解决方案进行广泛的测试。特别是，Pangu通过内部基于模板的准入测试，解决了来自不同供应商的异构硬件之间的互操作性问题。新的解决方案会逐个集群地在Pangu的生产环境中推出。上线后，Pangu监控系统会通过细粒度的监控、彻底的根源分析、快速响应和事后文档记录，密切关注它们的行为。

细粒度监控与智能诊断

在Pangu 2.0中，我们为Pangu监控系统引入了两项关键设计，以适应高性能要求（即100微秒级别的I/O延迟）。首先，我们将监控的时间粒度从15秒提高到1秒，并扩展了Log Service，设计了一个按需追踪系统。与Pangu 1.0中的粗粒度监控相比，这使我们能够基于每个文件操作进行追踪，从而准确捕获细粒度的异常事件（例如内存分配异常和日志打印超时）。其次，我们采用了人工智能技术来更好地捕捉异常事件与其根本原因之间的因果关系。推断出的根本原因由运营团队进行评分，并反馈给训练模型以提高其准确性。这种设计显著提高了诊断的准确性，并减少了所需的人力投入。

在Pangu 2.0的运营过程中，细粒度监控与智能诊断的组合为我们提供了强大的故障排查能力。通过实时、高精度的数据收集和分析，我们能够迅速定位并解决问题，确保系统的稳定性和性能。同时，AI技术的引入不仅提高了诊断效率，还帮助我们不断优化系统，预防潜在问题的发生。

5.2 案例研究

广泛的数据完整性检查

Pangu广泛采用CRC（循环冗余校验）来确保数据完整性，包括数据路径上的端到端CRC、对所有副本的每月CRC、对随机抽样副本的CRC以及在EC（纠删码）构建过程中对额外副本的CRC。在我们遇到的所有数据完整性问题中，CPU静默错误是一个具有代表性的例子。具体来说，我们发现了一些端到端CRC错误，并确定它们的根源是某些CPU上的静默错误。为了防止此类错误，我们与Intel合作，在生产环境负载较低时部署静默错误测试工具，并取得了一些成功。

处理USSOS中的SLA抖动

在Pangu的运营过程中，我们遇到并解决了一些导致USSOS（统一存储服务操作系统）中SLA（服务等级协议）抖动的问题，如内存分配、周期性重任务以及USSOS CPU利用率的增加。首先，我们发现现有的内存分配机制（如TCMalloc）在进入全局内存分配阶段（例如新线程需要内存时）或内存组织阶段（例如太多RDMA队列对试图保留高阶内存空间时）会变得非常耗时。为此，我们引入了一个用户空间内存分配池，并优化了RDMA驱动程序以使用匿名页面。其次，对于周期性重任务（如日志打印），我们将其移至异步线程，以避免影响数据操作的SLA。最后，我们发现当内存占用率高且USSOS需要进行内存回收时，USSOS的CPU利用率会显著增加。因此，我们调整了内存回收的阈值，减少了USSOS进入内存回收状态的机会。同时，我们还在后台回收分配给缓冲区和缓存的内存。

处理USSOS中的可纠正机器检查异常（MCE）以提高可用性

最初，USSOS（统一存储服务操作系统）能够监控此类硬件故障，但它无法感知内核如何迁移物理内存以进行异常隔离。因此，当USSOS尝试访问已经迁移的、基于其过时的虚拟-物理内存地址映射的物理内存时，会发生错误。

为此，我们在USSOS的MCE监控守护进程中添加了一个处理程序。一旦发现的可纠正MCE数量超过某个阈值，与之相关的用户空间进程将暂停，并让处理程序通知内核迁移内存。迁移完成后，进程恢复并在访问内存页之前更新其映射表。这种设计在几乎不牺牲性能的情况下提高了Pangu的可用性。例如，我们在一个包含2300台服务器的集群中观察到，在22天内发生了少于330个可纠正MCE。

来自不同供应商的异构内存带宽

Pangu部署了来自不同供应商的内存。我们的测试表明，在1:1的内存读写比下，来自三个不同供应商的128GB内存的可实现带宽分别为94GB/s、84GB/s和60GB/s（即存在57%的差异）。这种异构内存带宽会导致集群中的性能下降。这一观察结果让我们更加关注内存的性能，而非仅关注容量。这也是我们最早发现接收端主机数据路径拥塞的证据，并直接促成了RDCA（远程直接缓存访问）的开发（§4.2.3）。

应对双11大促期间的尾延迟激增

双11是阿里巴巴一年一度的最大在线购物节。在这样的高流量压力下，确保Pangu的高性能需要实时监控、诊断与响应，确保所有技术特性能够协同工作。在2019年的双11期间，我们注意到基于Pangu的关系型数据库服务（RDS）出现了读取尾延迟激增的问题。通过分析系统追踪信息，我们确定根本原因是同时发生了两个数据块的再平衡迁移，以及存储剩余未迁移数据块的块服务器发生故障。因此，客户端在请求最新块服务器IP地址之前，必须尝试访问所有三个副本并失败，从而增加了延迟。

为了解决这个问题，我们让客户端定期从主节点获取异常块服务器的块信息，如果它们所需的数据块位于异常服务器上，则立即请求最新的块元数据。这一措施在当时有效地应对了尾延迟的激增。

然而，这种机制有其局限性。在2020年的双11期间，客户端再次遭遇了尾延迟激增的问题。我们发现根本原因是许多块服务器由于内部问题被判定为异常。客户端因此收到了大量关于异常块服务器的信息，并花费大量资源进行处理（例如反序列化和地址解析），导致长时间的I/O挂起。面对即将到来的流量高峰，我们暂时禁用了这一机制，并在节日过后进行了一系列改进升级，包括使用独立线程处理异常服务器操作，以及限制每次请求的异常服务器数量。

[lambertxiao]

6 经验

关于用户空间系统的经验

我们开发了Pangu的块服务器用户空间操作系统（USSOS）（第3.2节），以适应新型网络和存储技术的高速发展。在其开发和运行过程中，我们获得了以下三个重要的经验。

首先，用户空间系统更容易开发和运维。例如，我们的数据显示，在内核空间文件系统中修复一个错误大约需要两个月的时间，而在USSFS（第3.2.3节）中只需要几周。在用户空间中开发新功能（例如分区命名空间[69]）所需的开发人员更少，时间更短。此外，监控和追踪用户空间系统的行为，并根据需要调整其参数也更为容易。

其次，开发用户空间系统时应借鉴内核空间的设计。特别是为了构建高性能的USSOS，我们不仅需要统一存储和网络栈，还需要设计用于内存管理、CPU调度和硬件故障处理的用户空间模块。内核空间在这些功能方面表现得相当出色，因此用户空间系统可以通过学习借鉴其设计来获益。

第三，用户空间系统的性能提升并不局限于高速存储如SSD。具体来说，我们在Pangu的USSFS中提供了一系列机制来加速HDD的性能。例如，USSFS利用自包含的数据块布局（第3.1.3节）来减少元数据操作的次数。它还利用磁盘内外轨道之间的差异来提高HDD的写入效率。

性能与成本权衡的经验

为了满足新的业务需求，Pangu通常首先选择增加硬件来提高性能，这是在考虑总体拥有成本（TCO）平衡的基础上做出的决策（例如，将网络从25 Gbps升级到100 Gbps，通过放置更多小容量的DRAM增加内存通道数量，以及使用更强大的CPU升级服务器）。硬件扩展有效地提升了Pangu的性能，但由于成本问题，这种方法并不具有可持续性。因此，Pangu也投入了大量精力，如进行流量优化（第4.1.2节），提高其资源利用率和效率。

持久性内存（PMem）的经验

PMem具有许多优势，例如快速的数据持久化、RDMA友好性、低读取延迟（PMem上6微秒 vs. SSD上80微秒）、低尾延迟和缓存友好性。因此，我们在Pangu中开发了一项基于PMem的、延迟为30微秒的EBS服务[1]。然而，英特尔决定终止其PMem业务[70]，这迫使我们重新思考这项服务。在开发新服务时，我们需要进行更全面的规划（例如，考虑可替代性、可持续性和成本权衡）。但我们相信，新的存储级内存[71]将会带着更好的解决方案涌现出来。

硬件卸载的经验

成本与效益的权衡是硬件卸载（第4.3.3节）的一个基本问题，自2018年以来，这一直是Pangu中持续讨论的话题。硬件卸载压缩的整个开发过程耗费了一个20人团队两年的时间，期间我们解决了许多问题，如FPGA硬件成本、压缩数据的完整性，以及与其他硬件功能的共存问题。最终，其带来的效益远大于成本。硬件卸载显著降低了压缩的平均延迟和尾延迟，有效地在低延迟情况下减少了网络流量。因此，我们的基础设施服务能力提高了约50%。我们在2020年以缓慢的速度在Pangu中推出了硬件压缩，首先应用于内部服务（如日志/监控服务），然后逐步扩展到核心外部服务（如EBS）。为了防止硬件中的潜在错误损害数据完整性，我们在硬件上执行数据解压缩和CRC校验，并定期进行软件CRC校验。自2022年起，Pangu中的所有200 Gbps集群都默认启用硬件压缩，并且事故发生的频率越来越低。