我们身处一个海量数据时代，企业的数据量爆炸式增长，汗青数据对企业的重要性，在于以史明鉴。磁带库存储目前在企业领域中不断在对企业的汗青数据停止存储，而且阐扬着重要的作用。

　　本文将分享「百度沧海·存储」的磁带库存储架构的设想与理论，内容涵盖了从存储体系的简介、设想思惟，到 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 分钟。分钟级的取回耗时，和我们此前对磁带库动辄数小时乃至数天威力取回数据的传统印象，彷佛有点不太一样，原本磁带库也能够实现较快的取回速率。　　

　　以上是本日分享的全数内容。