本文整理自 2023 年 7 月 DataFunSummit 2023 數據基礎架構峰會——分布式存儲架構與優化分論壇同名主題分享。

傳統介質的新氣象！百度智能云基于磁帶庫實現冷數據存儲架構。

我們身處一個海量數據時代，企業的數據量爆炸式增長，歷史數據對企業的重要性，在于以史明鑒。磁帶庫存儲目前在企業領域中一直在對企業的歷史數據進行存儲，并且發揮著重要的作用。

本文將分享「百度滄海·存儲」的磁帶庫存儲架構的設計與實踐，內容涵蓋了從存儲系統的簡介、設計思想，到 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 分鐘。分鐘級的取回耗時，和我們此前對磁帶庫動輒數小時甚至數天才能取回數據的傳統印象，似乎有點不太一樣，原來磁帶庫也能夠實現較快的取回速度。

圖片

以上是今天分享的全部內容。