百度云磁带库存储架构的设计与实践

本文转载自 百度智能云技术站 微信公众号

我们身处一个海量数据时代，企业的数据量爆炸式增长，历史数据对企业的重要性，在于以史明鉴。磁带库存储目前在企业领域中一直在对企业的历史数据进行存储，并且发挥着重要的作用。

本文将分享「百度沧海·存储」的磁带库存储架构的设计与实践，内容涵盖了从存储系统的简介、设计思想，到 ARIES 架构设计、业务实践案例等内容，希望相关领域的读者能够从中获得一些启发和灵感。主要内容包括以下几大部分：

• 磁带与磁带库简介；
• Aries 云存储系统简介；
• Aries 磁带库存储架构；
• 业务实践案例。

1    磁带与磁带库简介

本文第一部分，我们首先简单介绍一下磁带与磁带库。主要包括磁带介质、企业级磁带库等概念，磁带（库）的主要特性，以及磁带（库）的软件体系和应用场景。

1.1    磁带介质

在了解磁带这种介质之前，我们可以先看两张图片。

左边的图片展示了一张磁带专辑，它是 2008 年 10 月华语乐坛最后数张磁带专辑之一，从 2009 年开始，华语乐坛不再使用磁带来发行专辑。目前在消费级市场上，仅有少数特殊行业还在使用磁带，大部分行业已经很少能见到磁带的身影。

右边的图片展示了 2021 年 9 月发布的 LTO-9 企业级磁带及驱动器，LTO 技术从早期一直发展到今天的第 9 代，可以看出，磁带目前仍然在企业级市场中被大量使用，且其技术仍处于快速发展过程中。

1.2    企业级磁带库

这一页提供了两张图来展示一下企业级磁带库，让大家对企业级磁带库的外观和它的内部构造以及实际部署形式有一个感性的认知。

左边这张图是一个典型的磁带库库体，我们看到的是库体的正面，有很多柜门，打开之后能够看到内部的构造。库体内部上面部分的长方形部件是访问磁带的驱动器，也叫做带机。中下部分主要部件就是一系列的盘仓，里面装满了磁带，实际上一个盘仓向内可以安装多盘磁带。通过横向增加多个磁带库柜子，可以实现磁带库的灵活扩容。

右边这张图展示的是从侧面看一个实际的磁带库部署的视图。我们可以看到，库体中间有一个蓝色的线，那其实是一根导轨，导轨上面安装有机械臂。常态下，磁带不像磁盘是直接连接到主机的，而是放置在盘仓中，且盘仓并不直接连接磁带驱动器。也就是说，当系统需要去访问某一盘磁带的时候，它需要用利用机械臂将目标磁带从对应的盘仓当中弹出来，然后插入到某个驱动器的槽位中，最后才能实现相应的访问行为。当系统不再需要访问这盘磁带时，它将再次利用机械臂，将磁带从驱动器的槽位中拔出来，并将其压入它隶属的盘仓中。

从上面两张图中可以看出，磁带库的部署和运行与传统的基于磁盘的服务器的部署和运行有着很大的不同。

1.3    磁带（库）的主要特性

下面再分别介绍一下企业级磁带和磁带库的主要特性。

先看下企业级磁带的特性。

• 磁带的第一个特性，也是非常典型的特性，也是大家很明显能感受到的特性，即，磁带是一种顺序读写介质。当前主流磁带顺序访问的吞吐在 360~400MB/s 的水平，比磁盘要高。虽然实际上磁带也是可以支持随机读的，只是会引入比较高的首字节访问延迟，一般在分钟级。磁带顺序访问的特性也会带来一个问题，即，当磁带中的某个文件被删除了，其空间回收代价是比较高的，这个问题类似于 LSM 风格的存储引擎中空间回收的问题。
• 磁带的第二个特性是可靠性相对比较高。磁带的误码率比磁盘要低，比磁盘更不容易出现数据错误，此外，带机在写磁带时一般也会同步执行实时校验，尽量确保数据进入磁带时没有出错。
• 磁带的第三个特性是移动性强。磁带常态是脱机存放的，很便于物理搬迁，而且在搬迁过程中，出故障的可能性也很小，维保人员的心理压力也会比较小。
• 磁带的第四个特性是成本相对比较低。以当前主流的 LTO-9 标准为例，单盘磁带容量达到了 18T，和现在主流的单个磁盘的容量差不多，但磁带的成本却比磁盘要低很多。
• 磁带的第五个特性是依赖特殊的软硬件。和传统基于磁盘的这套软件栈和硬件环境不太一样，它需要依赖一些专门的配套软件和硬件环境，才能去实现相应的访问。

再看下企业级磁带库的特性。

业务在大规模使用磁带库的时候，一般而言，不会只是单纯购买一堆磁带和带机，然后自行实现全部的软件栈和硬件环境从而实现对磁带的访问管理，故比较常见的方式，是以磁带库的方式去部署和应用，所以我们也需要探讨磁带库的特性。

• 磁带库的第一个特性是大容量交付。一般来说，交付一个磁带库，往往从数十 PB 起步，可高达数百 PB。也就是说，如果业务的数据规模本身并不是很大，强行去应用磁带库，算上业务改造、环境建设、招标采购和运维支持等投入，折腾一遍磁带库，最终带来的总收益不一定有多可观。因此，如果想让磁带库产生大的收益，对业务的数据体量是有一定要求的。
• 磁带库的第二个特性是总带宽比较低。相比于磁带库动辄上百 PB 的总容量，一般在里面部署的带机数量相对比较少，这就导致磁带库的总带宽相对比较低，这一点不如基于磁盘的高密度机型。这也要求业务只能将合适的数据存储到磁带库中，如果数据偏热，或者仍然存在较多的访问，是不太适合磁带库的，否则访问带宽可能严重不足，访问延迟也比较高。
• 磁带库的第三个特性是成本比较低。一个磁带库部署中，除了最关键的磁带，还包括带机、导轨、机械臂、柜体等各类硬件，即使将这些全部算上，它总的存储 TCO 成本仍然比基于高密度磁盘的高密度机型存储方案更低。
• 磁带库的第四个特性是能耗低。磁带在无访问的时候脱机存放于盘仓中，不会消耗能源，而磁带库能够同时访问的磁带数量很少（受限于带机的数量），故磁带库的总能耗较低。
• 磁带库的第五个特性是需要适配特殊的软件。磁带库这个领域存在很多特殊的软件，包括开源的软件和各个厂商私有的软件，业务如果要接入磁带库，可能需要去适配供应商的这些特殊的软件套件。维保人员可能也需要学习供应商配套的带库管理软件来实现对磁带库的日常运维和管理。

1.4    磁带（库）软件体系

本小节介绍一下磁带和磁带库的软件体系，包括 LTFS 系列、私有格式&软件库、应用层分布式存储系统和带库管理软件。

第一个是 LTFS 系列。LTFS 的全称是 Line Tape File System，是一个开源的存储格式标准，它以文件系统的形式定义了数据在磁带介质上的存储格式和访问接口，应用程序可以通过该接口和软件库来直接存取磁带上的数据。LTFS 提供了开源的LE 版本库，这个版本提供了比较基础的访问能力。部分厂商还在此基础上研发了具备更多高级能力的商业版本，比如 IBM 的 LTFS-EE。

第二是私有格式及相应的软件库。部分厂商在 LTFS 之外，还提供了自己的私有格式，例如昆腾的 ANTF 格式及相应的软件库。

第三个是应用层分布式存储系统。这个是指，供应商在磁带库基础上进一步提供的分布式存储系统，能够为应用层访问磁带库提供很大的便利，例如 IBM 的 GPFS 和昆腾的 StorNext。实际上，不依赖这一层软件，应用程序仍然可以基于更底层的软件来访问磁带或磁带库，但是应用层需要感知大量的底层细节，并自行实现很多分布式层面的高级能力，这不一定是最合适的做法。

第四个是带库管理软件。基于这类软件，维保人员能够实现对磁带库的日常运维和管理。

1.5    磁带（库）应用场景

第一部分的最后一小节，我们看一下磁带库有哪些合适的应用场景。从上图可以看出，磁带（库）大致可以应用于如下几个典型场景：

• 备份：日志备份、数据库备份等；
• 归档：历史数据的归档和长期存储等；
• 冷数据：低成本存储访问概率较低的大型数据；
• 创新用法：例如当做大容量低成本的回收站等。

2    Aries 云存储系统简介

在本文第二部分中，我们介绍下 Aries 云存储系统。我们的磁带库存储架构是基于 Aries 云存储系统实现的，故为了方便大家理解磁带库架构的细节，在这里先对 Aries 做些必要的介绍。

Aries 的全称 A Reliable and Integrated Exabytes Storage。在百度沧海·存储的层次 + 组件式的技术和产品体系中，Aries 扮演的是「统一数据面存储底座」的角色。

2.1    百度沧海·存储技术栈

下图是百度沧海·存储的技术视角鸟瞰图，包括基础架构层和产品架构层。

基础架构层分为 Aries 和 TafDB 两大部分，TafDB 负责解决元数据管理的问题，主要是 KV 或表格型元数据，在此基础上，支撑了平坦目录树和层次化目录树等。Aries 主要负责数据本身的管理，它对上层提供三种数据模型，分别是 Slice Model（切片模型）、Volume Model（卷模型）和 Stream Model（流模型）。

产品架构层则包含了一系列的云上存储产品和一些只面向百度内部的存储产品。实际上，Aries 还支撑了百度网盘，但因为网盘不属于沧海存储体系，故没有体现在这张图中。

2.2    Aries 架构简介

Aries 系统初看略微复杂，总共有十几个模块。但 Aries 采用了子系统化和微服务化的设计，整个系统可以划分为 4 个子系统，分别是：资源管理子系统、用户访问子系统、磁带库存储子系统、以及修复、校验与清理子系统。不同的模块分属不同的子系统，子系统内部高内聚，子系统之间低耦合，跨子系统的交互相对较少。

其中磁带库存储子系统即是 Aries 的磁带库架构的核心部分，负责对接磁带库，它包含 TapeService 和 TapeNode 两个模块。此外，资源管理子系统包含 Master 和 DataNode 两个模块，主要负责存储资源的管理和集群层面的基础管理。用户访问子系统包含 DataAgent（含 API）、VolumeService、Allocator、StateService 和 StreamService 等模块，主要负责实现用户的访问通路。校验、修复与清理子系统包含 CheckService、TinkerService、Validator 和 Gardener 等模块，顾名思义，主要负责数据的正确性保证、可靠性保证和垃圾的及时回收清理等。

Aries 的架构特点可以总结为微服务化、超大规模、多模型集成、多介质支持和面向故障设计。在生产环境，Aries 管理了数万台高密度和 JBOD 存储服务器，总数据量超过了 10EB，其中单集群的最大数据量达到了 1.7EB。

2.3    Aries 数据&访问模型

Aries 的数据模型包含 Slice、Volume 和 Stream 三种：1）Slice 是最基础的模型，也是系统对外服务的最小实体，一般大小不超过 16MB；2）Volume 基于 Slice 构建，其内部包含的 Slice 之间无顺序关系；3）Stream 也基于 Slice 构建，但其内部的 Slice 之间存在某种顺序关系。

三种数据模型对应的访问模型介绍如下：1）Slice 采用直接 EC 的处理方式，写入时一次性 Put 进来，不可变更，也不支持追加写；2）Volume：用户可同时并行 Put 多个 Slice 到同一个 Volume 中，支持 Slice 粒度的点读和批量读；3）Stream：任意时刻，最多只能有 1 个会话可写，并且只能以有序的方式写入不同的 Slices 到同一个 Stream 中，除支持 Slice 粒度的点读和批量读之外，还支持按照 Slice 的顺序关系来读取数据。

2.4    Aries 概念简介

本小节介绍 Aries 的一些主要概念，包括 Table Space、Volume & Volumelet，以及 Slice & Shard。

Table Space。Table Space 是一个类似于数据库表空间的概念。一个 Table Space 可以包含多个 Volume，这些 Volume 具有相同的 EC 模型。Table Space 会绑定到一个或多个资源池，同一个 Table Space 内部的 Volume 存储于相同的资源池，那么基于 Table Space 的概念可以实现 Volume 和资源池的映射。

Volume 和 Volumelet。Volume 是一个逻辑容器的概念，逻辑大小一般在几十 GB 到 1TB 的之间，Volumelet 就是 Volume 的物理存在。假定 EC 模型为 (r, k)，那么一个 Volume 会存在 r + k 个对应的 Volumelets。当 r = 1 时，EC 模型退化为 1 + k 个副本的多副本模型。Volumelet 实际上就是 DataNode 里面容纳数据物理容器。当然，在不同的存储引擎里面，Volumelet 的实际实现也各不相同。

Slice 和 Shard。上文介绍过，Slice 是 Aries 系统对外的基本实体，而 Shard 则是 Slice 做完 EC 编码之后生成的各个分片。准确来讲，DataNode 上管理的基本数据实体其实是 Shard。Slice 和 Shard 的关系等同于 Volume和 Volumelet 的关系。

上图右侧提供了一个 EC 模型为 2+1 的例子，这个例子比较好地体现了这些概念之间的关系。从图中可以看出，该 Volume 里面存在一个 Slice X，EC 之后生成了 Shard 0、Shard 1 和 Shard 2，另外一个 Slice Y 也与此类似。Shard 0、Shard 1 和 Shard 2 分别存储在该 Volume 对应的 Volumelet 0、Volumelet 1和 Volumelet 2 中。在外围，这个 Table Space 除了包括该 Volume，还包括很多其它的 Volume。

3    Aries 磁带库存储架构

在本文第三部分中，我们将详细介绍 Aries 磁带库的存储架构的设计思路和实现细节。

3.1    Aries 磁带库数据流

我们在刚开始做磁带库引入方案设计的时候发现，数据流是比架构本身更加重要的问题，故这里首先提供整体的数据流视图。

如图所示，蓝色箭头表示业务数据流入磁带库的方向，业务首先将数据以某种方式写入到 Aries 磁盘资源池中，然后经过 Aries 内部的一个转储调度服务，将数据最终转储到磁带库系统。图中的橙色箭头代表数据流出磁带库的方向，当业务需要取回某些数据时，Aries 内部的取回调度服务首先会将目标数据从磁带库中取回并暂存到集群的磁盘资源池中，然后通知业务从磁盘池中取回目标数据。

这套数据流设计方案的最大特点在于，业务并不直接和磁带库进行交互，而是经过了磁盘资源池的中转，从而使得整体流程得到了适当的解耦。

3.2    Aries 磁带库架构关键思路

Aries 磁带库架构的关键思路可以总结为如下四点：1）数据物理聚集性写入；2）解耦用户写入与转储磁带库；3）位置相关的取回调度；4）充分复用磁带库现有软件体系的能力。下面我们逐条对上述思路进行阐述。

第一点，数据物理聚集性写入。业务数据里面可能有很多数据之间存在关联性，比如说某个目录的数据可能都属于同一个终端用户；或者说它属于同一个业务单元；或者说一些数据具有相同的生命周期，将来可能在相同的时间会被删除或下沉；再或者说一些数据之间存在关联性的访问模式等等。如果业务能够将这些有关联性的数据识别出来，然后又能够将它们尽量以物理性聚集的方式存储在一起，将来在取回的时候也会更加高效，也能提供更好的性能。尤其是在磁带库中，因为对磁带的访问并行度受限于带机的数量，故物理性聚集存储对对加速数据取回尤为重要。

第二点，解耦用户写入与转储磁带库。在上一小节中已经介绍了，Aries 的磁带库数据流，是非常明显的解耦做法，业务层和磁带库之间没有任何直接的数据交互，而是通过磁盘资源池进行异步中转。这种解耦的做法能够带来如下几个好处：1）业务层不需要感知磁带库的细节。对业务而言，它只需要调用相应的接口将数据按照一定的方式直接写入到 Aries 的磁盘资源池中即可认为写入成功。这个过程中，业务层代码只需要跟 Aries 的常规磁盘存储架构打交道，不必与磁带库架构打交道，也不关心磁带库的细节，程序相对简单很多。2）业务方不需要适配磁带库的性能及其波动。磁带库本身是一套复杂的系统，出现性能波动是非常常见的，如果业务方直接穿透 Aries 来写磁带库，那么当磁带库出现性能波动的时候，它就需要配合处理。比如某个写入任务正在带机上执行，但是恰好又被一个取回任务所抢占，对业务程序而言，写入速度开始变慢甚至出现超时，业务程序处理这类问题非常棘手。所以，如果采用的解耦的做法，业务层完全不用关心和处理这类问题。3）业务方也不需要感知以及配合处理磁带库的局部异常或故障。实际上，磁带库在运行当中多多少少会出现一些异常，其中一个比较容易出现的故障的设备就是机械臂，机械臂有时候可能会卡住，这是一种可恢复的异常，如果能够在比较短的时间内解决并恢复，那么在这种异步架构里面，业务程序的数据写入流程其实不怎么需要关心这个事情。4）复杂工作下沉到 Aries，实现技术高度复用。实际上，Aries 在和磁带库的交互中，除了常规的读写流程，实际还存在很多异常处理的逻辑。如果不采用解耦架构，这些逻辑前置到业务侧来实现，会导致很多重复的工作，例如用户 A 实现了这一套复杂的逻辑，业务 B 将来又需要再去实现一遍。在一个组织里面也好，在一家公司内部也好，这种复杂且重复性高的工作，会导致极大的研发成本浪费。因此，将这些复杂的逻辑下沉到 Aries，由 Aries 统一解决，尽量降低业务层的复杂度和工作量，实现高度的技术复用，是非常有必要和有意义的。

第三点，位置相关的取回调度。在取回数据的过程中，调度服务仅将处于同一个位置的数据，比如属于同一个卷的数据，或者属于不同的卷但是这些卷都在同一盘磁带上的数据，尽量一次性多取回，就有机会提升取回的效率。尤其是，如果这些位置相关的取回任务的期望 Ready 时间相近的话，那么优化空间就更大了。所以调度服务在运行时，会根据位置的不同和期望时间的不同会把外部任务重组成不同的内部任务，然后以内部任务的粒度去调度执行，最大化提升数据取回的效率。

第四点，充分复用磁带库现有软件体系的能力。两年前我们开始启动引入磁带库这个事情的时候，我们和业务方、供应商和公司内部的硬件组，经过了很多的讨论和研判，认为磁带库这套东西，从硬件到软件都和我们常规的磁盘架构非常不一样，这个领域里面有很多我们没有见过的问题，也缺乏相关的应对经验，例如如何对磁带进行日常校验、如何回收磁带上的垃圾数据、如何执行跨磁带的副本修复等等。但从另外一个角度来看，磁带库供应商在这个领域耕耘了数十年，积累了大量的经验，提供了比较完善的软件体系。如果我们复用这些软件体系的能力，就能够大大简化我们接入、应用和管理磁带库的复杂度，也能够让整个架构更快地稳定下来。

3.3    Aries 磁带库架构设计图

下图展示了 Aries 磁带库架构的设计，包括相关的模块以及模块之间调用关系。

如上图所示，总共有 6 个模块会参与到磁带库架构的实现中。所有请求，都通过调用 API 进入 DataAgent，然后由 DataAgent 调用后端各模块来实现。当调用卷相关接口时则会访问 StateService，当调用数据取回相关接口时则会访问 TapeService。TapeService 与 TapeNode 之间存在获取任务和汇报任务状态信息的交互。转储成功之后更新卷信息时则由 TapeService 访问 Master 来完成，并将卷信息存储在 Master 中。数据转储完毕之后，需要清理卷在磁盘池中的数据时，由 Master 调用 DataNode 去执行。DataAgent 与 DataNode 之间存在数据写入和读取磁盘池的关系。DataNode 与 TapeNode 之间存在数据转储到磁带库和从磁带库取回的关系。这两个数据流动的子过程，构成了整体的数据流。

3.4    聚集写入过程

从本小节开始，会介绍几个关键过程的实现。

首先是聚集写入的过程。前面已经提到过，聚集写入过程的核心是如何实现有关联性的业务数据的物理性聚集存储。为了实现这一目标，Aries 将 Volume，也就是卷这个概念，从内部暴露出来给业务，让业务程序能够显式感知和自主填充卷的数据，以及显式控制卷的状态。而 Aries 则在内部实现中保证，一个卷将来在被转储到磁带库的时候，对应的是磁带库内部的一个物理的文件，并且是连续存储在某盘磁带上的，从而实现最终的物理聚集存储。

为了实现上述过程，Aries 新增了几个相关的接口供业务调用，即 allocate_volume、release_volume、seal_volume、get_volume_size 和 write_slice。接口顾名思义，分别实现分配一个可写卷、释放指定的卷、密封指定的卷、获取卷的数据大小和写入 Slice 到指定卷的功能。简要的写入过程如下：业务程序首先调用allocate_volume 分配一个可写卷，调用成功后，该卷不会再被分配给其它会话，然后业务程序将有关联的数据以 Slice 粒度逐个通过 write_slice 写入到该卷中，当这批数据写完之后，业务程序可以调用 release_volume 释放对该卷的占用。在写完一批数据之后，业务程序可以调用 get_volume_size，获取该卷的实际数据大小，并检查该大小是否超过了预设的卷大小下限，是的话，则调用 seal_volume 来通知 Aries 对该卷进行密封，一个卷一旦被密封之后，将不会再被分配出去写新的数据，而是会进入到转储调度服务的任务列表中，等待被转储到磁带库。

对于磁带而言，它期望写入的文件起码是 GB 级别，如果能达到 10GB 级别则更佳，同时又考虑到磁带库在取回数据的时候，是以整个文件为粒度，也就是卷的大小粒度，不宜过大。综合考虑双方面的因素，我们将这类卷的大小范围设计为 8GB 到 16GB。这类卷在磁盘池中存储时，采用的是 AppendStore 存储模型，方便高效写入和空间回收。

3.5    转储过程

转储过程分为两个大的步骤。

第一步，将磁盘中密封状态的 EC 卷里面的 Slice 全部读取出来，然后在磁带库应用层文件系统中创建一个对应的文件，最后将所有的 Slice 逐个 Append 到该文件中，将卷从 EC 形态转储成了线性文件形态。这里的文件系统就是我们最开始介绍的 GPFS 或者 StorNext。在这类文件系统当中，卷文件采用 2 副本存储模式。写完文件之后，TapeNode 还会再读一次文件并做一次校验，确保文件数据的正确性。

随后进入第二步，TapeNode 启动一个真正的转储过程，这个转储过程通过调用 LTFS-EE 的 migrate 指令，显式地将文件转储到磁带库中，至此，数据才最终进入磁带。数据在磁带库中也是按照 2 副本来存储，当转储结束之后，这个文件的 2副本会分别存储在不同的磁带中。TapeNode 会再查询一次该文件的属性信息，从中获得 2 个副本所在的磁带 ID。

上述两个步骤都完成之后，整个转储过程才算结束。随后 TapeService 开始做一些善后工作，它会通知 Master 更新卷的元信息，包括卷的入库时间、卷文件的 Size、卷文件在应用层分布式文件系统上的全路径以及对应的 2 个副本所在的磁带 ID 等等。Master 会在将来某个时刻发起对该卷原 EC 形态数据的清理操作。

3.6    取回过程

相比于转储流程，取回的流程相对会更长一些。我们按照上面图中编号的顺序，逐步介绍一下其过程。

第一步，业务通过 DataAgent 提交取回请求给 TapeService， TapeService 接受该任务之后，将任务进行持久化并提交给取回调度器；

第二步，取回调度器根据上文介绍的策略重组当前未完成的任务，并等待TapeNode 来获取任务；

第三步，当 TapeNode 获得一个任务之后，它根据任务的上下文，通过显式调用 LTFS-EE 的 recall 命令从磁带中召回目标数据所在的卷文件到磁带库应用层分布式文件系统中，存储在本地临时 Cache 空间中；

第四步，解析卷文件，将目标 Slices 从卷文件中提取出来，并存储到本地临时空间中，然后显式释放掉本地临时Cache中的卷文件；

第五步，TapeNode 将目标 Slices 写回到该卷原有的 EC 形态空间中，也就是磁盘池。前文提到过，当卷转储成功之后，卷的 EC 形态的数据会被清空，但是 EC 形态本身是有保留的，故本步骤相当于一次普通的写入过程；

第六步，TapeNode 向 TapeService 报告任务的执行状态和结果；

第七步，TapeService 会周期性地，或在一个合适的时候，通知业务方所有的取回任务的进展；

第八步，当业务方发现某个任务的目标数据已经完全准备好之后，就会启动一个/一批常规的从磁盘池读取数据过程；

最后进入第九步，Aries 将目标数据返回给业务。从上述过程中，可以很明显地看出，业务取回数据的过程也是一个异步过程，中间涉及到磁盘池的中转，并非直接从磁带库中以同步方式取回数据。

4    业务实践案例

在本文的最后一部分，我们通过一个实际案例的分析来看看业务如何通过 Aries 来应用磁带库。

4.1    业务场景与要求

首先是业务场景。第一，业务存在很多极少被访问的冷数据；第二，这些数据被删除的概率很低，所以需要长期的存储；第三，这类数据的体量还不小，具备百 PB 级别及以上的规模。

其次是业务要求。第一，这些数据之间存在某种关联性，如果将来在取回的时候，有可能很多数据会被一起取回，所以在归档到磁带库时，尽量能够实现物理性聚集存储；第二，相比于基于磁盘的高密度机型存储方案，期望成本仍然能有较大的降幅，否则给这类数据重做一个存储方案的必要性就不大了；第三，有足够的冗余能力，能够长期给数据提供足够的可靠性；第四，能够容忍一定的故障，但是总体上要提供足够的可用性，使得数据可以被及时地取回。其中最后两点基本上就要求数据存在磁带库里面时，仍然需要采用多副本的方式，经过折衷，采用了 2 副本的方案，并设计了适合于 2 副本的部署架构。

4.2    磁带库部署

下图展示了该业务的磁带库的实际部署细节。

该业务的首个磁带库于 22 年上半年完成采购和部署。因为设计的是 2 副本的存储方式，故本次部署实际是采用了 2 个对等的磁带库，每个磁带库的大小都是 102PB。磁带采用的是 LTO-8 系列，每盘磁带容量为 12TB。每个磁带库配置了44 个带机和 22 个机头服务器。

对于每个磁带库，我们又进一步将其划分为五个物理池，如上图所示，每个物理池采用不同的颜色来表示。其中最右边的灰色物理池相对较小，这个小池子用来当做我们的测试环境。其余四个物理池 A、B、C 和 D，相对比较大，是线上环境。每个线上物理池，配置 5 台机头服务器，每台机头服务器连接 2 个带机，一个物理池一共连接 10 个带机，那么 4 个物理池一共配置 20 台机头服务器和 40 个带机，剩下的 2 台机头服务器和 4 个带机分配给测试池环境。

一个实际的部署，包含 2 个对等的物理磁带库。我们将两个磁带库中，具有相同编号（上图中具有相同颜色）的物理池，构建成一个更大的逻辑池。具体而言，将这两个物理池中的各自 5 台，也就是一共 10 台机头服务器，作为一个整体，部署一套 GPFS，也就是说，这 10 台机头服务器将作为一个整体的文件系统对上层暴露，被 Aries 视为一个逻辑的磁带存储池。那么整个部署中，会存在 A、B、C 和 D 总共 4 套逻辑资源池。

这么做有几个原因，一是单个磁带库确实很大，适当分割有利于更精细的管理；二是能够降低磁带库机头服务器中东西向的流量，减少灌库过程中对网卡带宽的压力。在实际转储数据到磁带库的过程中，TapeNode 会显式指定副本的两个目标物理池，从而实现数据副本分别写入不同的物理池。测试环境的部署规则与此相同。

4.3    机头服务器软硬件

下图简要展示了机头服务器的软硬件构成。

机头服务器软件部分，自下而上包括：

• LTFS-EE：直接访问磁带库的进程
• GPFS：GPFS 服务进程
• TapeNode：TapeNode 服务进程

机头服务器关键硬件部分包括：

• HBA卡*2：每张 HBA 卡通过光纤连接一个带机
• 网卡*2：提供足够的网卡带宽
• Optane 1.6T 盘*2：做 Raid 1 更可靠
• 系统盘等

此外，GPFS 根目录会挂载到本机挂载点上，故每个逻辑池的机头服务器看到的 GPFS 目录视图是完全一致的。

4.4    业务应用效果（写入）

下图展示了业务实际写入的效果。

该业务从 2022 年 10 月份开始写入数据，写入平稳期间，一天的写入量大概在 0.8~0.9PB 之间，2023 年 2 月底，该磁带库环境被写满。

4.5    业务应用效果（取回）

最后一张图展示了业务在线上执行取回压测的效果。

因为业务的这部分数据确实非常冷，很难在线上等到一个实际的大批量取回任务，所以我们在线上做了一些压测。其中一次压测是要求一次性取回 124 个不同卷，卷平均大小在 8GB 左右，故这次批量取回的数据量大约在 1TB 左右。测试时，将 124 个任务一次性全都发送给 TapeService， TapeService 随即启动任务调度过程，统计每个卷真正被取回到业务侧的时间。最后将每个卷被取回的耗时及其分布，按照分钟粒度进行统计，如图所示，x 轴是分钟粒度的耗时，y 轴是在这个时间内被取回的卷的数量。

从图中可以看出，最快的一个卷，取回耗时仅 3 分钟，最慢的一个卷，取回耗时也才 24 分钟，所有卷的平均取回耗时大约为 14 分钟。分钟级的取回耗时，和我们此前对磁带库动辄数小时甚至数天才能取回数据的传统印象，似乎有点不太一样，原来磁带库也能够实现较快的取回速度。