|
打印本文
时光如白驹过隙，坐在时代的列车里，我们一路向前；近三十年来，无数事物在车窗前掠影而过，一度流行，又一度黯淡。磁带，就是一个时代的符号。彼时，磁带因其低廉、可靠及易用等特性，一度成为音乐最主流的载体，将流行音乐传遍大街小巷。后来，随着 CD 和 MP3走进大众视野，磁带逐步退出历史舞台。如今，磁带作为音乐载体早被时代淘汰.....但磁带作为存储载体，近几十年却从未过时：在冷数据场景，磁带存储凭借其极低的成本和极长的寿命，在企业存储市场始终占有一席之地。今天的故事就此展开，来聊聊腾讯的深度归档存储与磁带的那些事。欢迎阅读~
提起磁带，80和90后可能感触颇深。在20世纪末至21世纪初的那些时光里，磁带绝对是那个时代的符号: 不管是在街上插着裤兜边走边听随身听的翩翩少年，亦或是街边一家接一家的外放音乐似乎永不停歇的小店，无一不在诉说着磁带的故事。
我与磁带结缘于2003年，那一年我读初一。依稀记得当时电视上天天洗脑般的播放各种学英语的广告——“学英语，Follow Me”、“XX 高复读机，学英语更容易”，潜移默化之下，似乎全天下的家长都认为复读机真的可以学英语。于是，复读机便成了中学生的必需之物，流行音乐的种子也同时在学校里生根发芽。那一年，我不仅拥有了人生中第一台复读机（也是唯一一台），也花掉了积攒已久的零花钱，拥有了人生中第一盘磁带——周杰伦的《叶惠美》。
不过后来，更厉害的东西出来了——MP3播放器。MP3播放器个头不大，但可以装的音乐更多，听完一波还可以再换一波，简直是听歌神器，再配合全球最大的盗版音乐下载基地: 某度音乐，MP3播放器迅速取代磁带成为了学生听歌设备的中流砥柱，从磁带手中接过了繁荣华语音乐的大旗。而也就是那时起，家用磁带便离我们渐行渐远。
冷数据有什么特点？日常写（如日志、音视频等），低频读，数据要可靠，成本还要低，寿命还要长，最好存放数据的介质不读时还不费电…… 这些看似苛刻但实际的需求，是冷数据的特点，却也命中了磁带的硬件特性。因此，磁带在各个大型公司中始终承担着数据备份的作用，并且在关键时刻一定能够把数据恢复出来。谷歌在2011年曾经出过一次事故，在一次 gmail 服务软件更新中出了个 bug，导致线万个 gmail 的账户数据被删除，尽管他们的邮件数据存储在了多个数据中心的多个副本里，但是数据依然有所丢失。最后，谷歌是从他们的磁带备份中把丢失的用户账户数据给恢复回来了。
但是，对于中小型企业来说，引入磁带有一定的技术门槛，前期的投入可能得不偿失。互联网公司发现了这个商机，他们在公司内部把磁带技术钻研透彻后，逐步把磁带存储技术搬到了云上。
2019年，亚马逊在云上推出了基于磁带的极冷数据存储产品：Glacier Deep Archive，也就是 S3的深度归档服务。Glacier Deep Archive 可以让中小企业0投入，直接以极低的成本使用云上的磁带存储。而除了互联网公司外，传统企业的备份需求也非常大，国内外的科研机构、广电、银行、证券、保险等行业，每年都会采购大量的磁带存储构建私有云，用于冷数据的存储。
▶︎独立机柜: 单个磁带库占地面积较小，通常配置的槽位数为400~900左右的量级（一个槽位可以插一盘磁带），对应物理存储空间约5~10PB 左右；
▶︎联排机柜: 单个磁带库占地面积较大，通常为多个机柜组合而成，槽位数配置也可以达到几千甚至上万，对应的磁带存储空间可以达到百 PB 级别。
▶︎驱动器: 也叫磁带机，负责磁带介质的读写。这里需要注意，驱动器对磁带的读和写是互斥的；
▶︎机械臂: 负责磁带介质的移动，从槽位中取出磁带放至驱动器，或者从驱动器中取出磁带放至槽位；
▶︎LTO 为标准组织定义的磁带类型，3592为 IBM 独有的磁带类型，需配合 IBM 专有驱动器才能访问，且仅能从 IBM 购买 (不可否认，IBM 对于 LTO 的技术推进也贡献很大）；
▶︎3592类型，旧磁带可格式化成新一代（容量/性能不同于新一代），可循环利用，LTO 无此功能；
▶︎磁带生产厂商主要有 FujiFilm 和 Sony，这两家厂商市场占有率总和接近100%，各家磁带库厂商的磁带生产主要交由 FujiFilm 和 Sony 进行生产，包括 LTO 和359。
HDD 与磁带的技术栈本质上有些类似，均为磁技术（加磁和读磁），通过对存储介质施加磁性，达到数据存储的目的，只是二者目前的密度不同。
目前业界真正投产的最大容量的 HDD，主要集中在20~24TB，但 CMR 短期内很难看到再有容量上的突破。HDD 的密度难以突破的原因之一，是磁头操作磁道时，会相邻磁道产生干扰，从而影响周边数据，这个问题也叫做邻道干扰（ATI），密度越高问题越明显。所以要想 HDD 的存储密度提升，ATI 是绕不开的问题。目前应对的手段主要有2个，分别是 HAMR（热辅助技术）和 MAMR（微波辅助技术）。使用 HARM 和 MAMR 理论性可以使得 HDD 达到40~50TB 这样一个容量量级，也是目前 HDD 容量的天花板。
而磁带在密度上的现状则完全不同。如果把提升密度比喻成打怪升级的账号，那么现在磁带的密度连新手村都没有出。用同样12T 的容量来比对下，12T 的硬盘容量大概是923GB/in²，而12T的LTO8磁带，它的密度现在只8.5Gb/in²。也就是在 LTO8基础上，能够至少再提升一百倍的容量空间。目前富士联合 IBM 已经在实验室中成功研制出了580T 容量的磁带 demo。不过短时间内，磁带的容量增速不会太激进，一个原因是有好东西要挤牙膏一样缓慢推进才能创造持续的商业价值，另外一个原因是配套硬件也需要时间去适配（比如网卡带宽、驱动器能力等）。
如上是详细的 HDD 与 Tape 的对比说明，这里就几个关键点补充说明：
▶︎成本: 磁带的成本优势，不仅仅在于相比于 HDD，同容量的介质采购价格更低，同时磁带的寿命通常要远长于 HDD，以及在非读写时磁带完全不费电，磁带整体 TCO 相比于 HDD 机型可以显著下降；
▶︎性能: 磁带的吞吐性能尚可，大批大文件数据连续写时，可以跑到接近理论吞吐，但磁带在读数据时，性能会退化非常严重，主要体现在寻址时间过长。当业务想要从磁带中读出数据时，磁带库需要经历“机械臂找磁带并插入驱动器”和“驱动器倒带直到数据所在 LBA”，前者耗时最长几十秒，而后者耗时可能长达2~3分钟。因此，磁带库的应用，最重要的就是如何把读性能尽可能提高；
▶︎非标设备: 磁带是一个块设备，但是不是标准块设备，访问磁带时需要依赖外部驱动和软件。
磁带是一个非标的块设备，需要外部程序配合使用。而社区中公开的技术，即为 LTFS。
LTFS 可以把单盘磁带模拟成一个文件系统，给用户屏蔽了“通过 iSCSI 协议向机械臂/驱动器发送原始指令”等细节，同时 LTFS 兼容 Linux、Windows 等多个平台。凭借开放、易用的特性，LTFS 对磁带技术有一定程度的推泼助澜的作用。不过 LTFS 在企业场景还是稍显乏力：缺乏大规模磁带管理能力、性能较弱。
▶︎可以实现批量取回优化：同一盘磁带中的多个文件优化读取顺序，跨磁带的多个文件按磁带进行合并；
▶︎提供多种访问协议：私有协议远程文件系统/NFS/CIFS/对象接口等(不过各家基本都是先实现了文件系统协议，其他协议基于文件系统协议进行二次封装，因此效率底下)；
▶︎提供副本管理：可以设置多副本 (不支持 EC，并且需要消耗大量的机器资源，性价比比较低)。
▶︎数据缓存：X86 服务器上一般有 SSD 来做磁带库的缓存盘。数据写入时，需要先写入缓存盘，再沉降到磁带中；数据回热也是类似的，回热成功后数据回到了缓存盘里。实际上我们跟磁带库打交道时，数据流都是跟缓存盘打交道，而控制流（刷磁带/读磁带）则可以通过 API 进行。
这里大家可能会有疑问，为什么不管是社区还是厂商，提供的最基础协议都是文件系统呢？主要还是因为用起来方便，尤其是小企业，使用时把文件系统挂载到本地服务器，直接跟文件系统交互即可，用着省事。这部分群体不太关心效率。但事实上，文件系统协议对互联网公司来说，还是太重了，尤其还是 Posix 语义的文件系统。
如果从互联网公司的需求来看，就做几个最简单的 BatchPut，BatchGet，BatchDelete RPC 接口就足矣，完全无需文件系统语义，因为文件系统语义大部分功能都是多余的。即使真的有场景需要提供文件系统语义，也应该通过SDK进行文件系统的操作（类似 HDFS-Client），而非通过 VFS/FUSE 进行操作，效率着实有点低。基于上述原因，亚马逊等海外的磁带使用量较大的大厂，实际上投入了非常多的人力，彻底干掉了厂商提供的所有软件，直接在纯硬件上开发适合云场景的软件系统。
只能顺序读写：通常情况下磁带只能顺序读写，不能直接原地修改；吞吐高：单盘磁带可达到300~360MB/s 吞吐，不同驱动器可并发；
COS 有5个存储类型，从冷到热分别叫标准存储、低频存储、归档存储和深度归档存储，以及智能分层（本文暂时不讲）
当有一些归档数据用户取回时，需要分钟级或者小时级，那么就可以掏3倍的价钱购买归档存储而不是买深度归档存储。但如果用户数据量非常大，比较在意成本，并且能够接受天级别的回热延迟，那么就非常适合做深度归档。比如很多企业为了合规性，把一些日志、视频进行归档，当审计或者需要时进行取回。举个例子，比如部分企业运营的原始资料（比如直播录屏），这些数据如果不是遇到重大案件回溯，基本上不会再调出来使用，但是这些数据出于合规性，又得永久保存，这种场景就可以放到深度归档里，且成本非常低。
深度归档存储（Deep Archive）是对象存储（Cloud Object Storage，COS）提供的可让海量数据长期归档的存储服务。深度归档存储提供了磁带存储级别的存储单价，为用户数据长期存储提供了低成本方案。用户无需在本地维护复杂的磁带库配置，无需关注底层存储介质的演进，通过对象存储 COS 提供的 API、SDK、生态工具和控制台等丰富的人机交互手段，即可实现便捷、低成本地管理数据。
深度归档存储适用于数据访问频率极低，但需要长期保留的场景。在日志冷备场景中，企业需要按照当地法律法规要求，将每天产生的日志数据进行冷备存储，以便追溯和分析。在视图数据和自动驾驶等业务中，企业沉淀了大量的图片、视频等媒体文件，在数据被使用过后仍然需要长期归档保存。通过深度归档存储，企业可以将这些数据存储在云上，仅在需要的时候恢复，降低存储成本和运维管理难度。
S3 Glacier Deep Archive 是 Amazon S3 成本最低的存储类，支持每年可能访问一两次的数据的长期保留和数字预留。它是为客户设计的 – 特别是那些监管严格的行业，如金融服务、医疗保健和公共部门 – 为了满足监管合规要求，将数据集保留 7—10 年或更长时间。S3 Glacier Deep Archive 还可用于备份和灾难恢复使用案例，是成本效益高、易于管理的磁带系统替代，无论磁带系统是本地库还是非本地服务都是如此。S3 Glacier Deep Archive 是 Amazon S3 Glacier 的补充，后者适合存档，其中会定期检索数据并且每隔几分钟可能需要一些数据。
概括来讲: 让用户多写少读少删、存大块数据，如果真的要读，也尽量鼓励用户批量读！
Berg 是 COS 团队设计并研发的面向磁带的极冷数据存储引擎。Berg 也是 COS 的一部分，意为冰山 （通常大家多想起 IceBerg 作为冰山示意，但在地质学词典里，Berg 本身就有冰山的意思，比如 Sugar Berg：多孔冰山）。
Berg 是国内首款支持纠删码的规模化商用的磁带存储引擎，也是腾讯从零开始完全自主设计和研发的全新存储系统。
用户的需求是上图左边，数据大小要支持 1Byte~50TB 的范围（因为对象存储本身支持的对象最大就到50TB），用户既可以直接上传，也可以把已经存在的低频归档的数据通过沉降的方式深度归档；用户需要时，可以把数据取回：按照云上的协议，当数据取回之后，数据需要在对象存储的标准存储准备好。当然，取回之后标准存储的那部分存储空间和读取也是额外收费的。最后，数据安全是底线，数据一定不能丢。
那么这些用户需求对于磁带库来说有什么问题呢？首先小文件性能会差，太大的又装不下，因为一盘磁带就12T，这也限制了磁带不能存储超过 12T 的数据。另外，磁带库本身写入读写流程非常繁琐，回热效率非常低（寻址时间可能高达3分钟），故障率也很高。而对于数据安全，则需要业务软件提供额外的副本机制了（前边讲过，磁带库软件自带的副本机制对资源浪费非常严重）。
▶︎IceWorker：真正执行任务的模块，它的职责主要是接受 Captain 分发的任务并执行。IceWorker 也是直接跟磁带库打交道的模块；
▶︎IceCenter：资源总管，寓意是冰上的大本营。IceCenter 保存了所有磁带库的资源信息，间接对 IceWorker 进行指导。比如 IceWorker 如果要沉降数据，则需要向 IceCenter 进行空间申请，申请后才能向磁带库写数据。
接下来在拆解上图，按照沉降、回热、修复、删除等等逻辑详细讲解整个的控制流、数据流是怎么样运行起来的。
最主要的原因还是，想要这些数据回热的时候更快。前边讲过，磁带存储的寻址时间非常长，我们不希望回热发生的时候，用户的数据分散在磁带库/磁带的各个地方，因此 Captain 会尽最大努力按照用户的数据特征，进行一个聚类动作，让具备相同特征的数据尽可能让 IceWorker 一起拿走，然后连续的写到磁带上，实现一个局部连续性。这样某个用户回热时，用户的数据大概率也是具备局部连续性的，可以显著提高回热性能。另外，当用户删除的时候，也可以让空洞更少一些。
怎么聚类?依然是两种思路，要想实现最精准的思路是：存到一个结构化存储里，或者就是存到大数据平台里，当 Captain 分发任务的时候，通过计算得到一个最优解。但是这个思路的实现代价太大了，有点用打蚊子的意思。本身 Berg 并不要这么高精度的聚类模型，无需过度设计。所以最后 Berg 就选择了一个轻量级的方式：实时聚类，Captain 收到信令时，立刻进行聚类计算，不同聚类模型对应不同文件，如文件过大则按策略进行切割。这样 Captain 给 IceWorker 分发任务的时候，按照聚类后的模型文件，一批一批递交给 IceWorker 去执行即可。
▶︎不可恢复性故障：Black 磁带库（组）的写请求，让后续的写请求流向健康的磁带库（组）。
回热流程的读写路径其实跟沉降非常类似，主要的策略点也在 Captain，对于用户发来的回热任务，并不是越快执行越好。Captain 如果是收到一个请求就立即执行一个请，硬件整体的吞吐是上不去的（由于回热数据的离散性，大量时间浪费在了磁带寻址上）。而磁带库的驱动器是稀缺资源，数据读写又是互斥的，磁带库处理读请求时，写请求就会暂停。因此，怎么样让磁带库更多的时间是在读数据，而不是在倒带，是 Berg 要解决的一个关键问题。
▶︎聚合：数据沉降时，会生成与数据位置相关的信息 Hint，Hint 值越接近表示数据在磁带中的 LBA 地址越接近，或者表示两盘不同磁盘间隔的距离越近。静置期内，Captain 按照 Hint 值进行聚合，保障分发给 IceWorker 的任务都是尽可能在磁带中较为靠近的，而 IceWorker 再执行这一批任务时，磁带库平均寻址时间更短，从这个角度提高了整体回热性能（吞吐）。
▶︎长尾规避：如 N 列全部成功，则 IceWorker 在收到前 K 列请求时，即可开始进行读缓存和上传数据的操作，无需等待全部列取回成功，本次回热请求可以更快时间完成执行。
第一级删除：Captain 聚合删除。Captain 的删除是以 Block 为粒度进行删除的。当 Captain 收到用户 Object 级别的删除指令时，如果是小 Object，不会立刻让 IceWorker 执行，会把这个删除请求持久化起来，直到该小 Object 对应的 Block 全部收到删除执行时，Captain 会向 IceWorker 分发一个 Block 级别的删除任务。如果某个 Block 中的 Object 一直不被删除怎么办？这会导致该 Block 内其他空间永远无法执行删除，这里需要借助 Re-Compaction 的方式来对 Block 进行坍缩&再聚合的操作来消除空洞；
▶︎第二级删除：IceWorker 向磁带库发起删除。IceWorker 向磁带库发起删除后，磁带库会从文件系统中删掉这个 Block 对应的文件，但是实际上磁带上并没有真正删除该数据，需要进到第三级删除才算真的删除；
▶︎第三级删除：磁带库回收磁带空间。这是一个非常费性能的操作，需要2个驱动器配合，一个驱动器会把待回收空间的磁带整个读一遍，同时另一个驱动器在另一盘空磁带上把这些数据再写一遍，数据复制成功后，把前一盘磁带进行格式化，达到回收空间的目的。物理删除有两个弊端，一个是驱动器资源消耗较大（占用时间较长），另一个是寿命有损 (一盘磁带格式化300次左右会寿终正寝）。因此，第三级删除也是一个较为谨慎的运维操作。
两阶段删除的目的在于：一个 Block 在被删除时，需要 N 列全部删除成功，而由于网络抖动、硬件故障等情况，可能造成部分列删除失败。这时对于磁带库中残留的若干列，无法直接确认该 Block 是产生了数据丢失还是删除部分成功。而对于两阶段删除，残留的部分列可以看到特殊标记，我们就可以直接断定它是没删干净的垃圾数据，就可以放心的进行人工清理垃圾数据的措施了。
对于磁带库而言，读数据性能开销是非常大的，并且驱动器读写是互斥的，这意味着驱动器读数据时无法再执行沉降任务；同时，对于 EC 而言，想要修复某一列数据，需要读大量其他的列的数据。这里以 KxNy 的 EC 为例；比如一盘12T 的磁带故障，则至少要读出剩下 K 盘磁带的数据（总数据量 K*12T），才能修复回这12T 的数据。
但是由于磁带故障率远低于 HDD，且当磁带故障时，大概率这一批磁带库已经写满了，只有回热请求，因此磁带数据修复对于业务的实际影响并不大。
▶︎读数据时，复算数据 CRC，并且与 Meta 中的 CRC 值对比，保障可第一时间发现问题。
▶︎磁带中不仅存储 BergMeta，同时额外存储一份 COS 的 Meta 信息，极端情况下，可以只根据磁带中内容，可还原用户的 Object 信息。
磁带库虽然能够显著降低存储成本，但是并不是所有的业务场景都适合搬到磁带上，本身磁带库的使用是有一定的业务和技术门槛的。从业务上而言，使用磁带库的场景必须是真正的冷数据的场景，用户数据具有保存时间长、低频读、低频删的特征，高频读写删会造成磁带介质寿命损害，只有真正的冷数据才能够做到“因地制宜”降成本；与此同时，由于磁带库通常单柜密度较高，当业务本身总数据量不大时，也不适宜使用磁带库。从技术上而言，使用磁带库具备一定的门槛，磁带库硬件不仅对于机房的温湿度环境要求较高，也需要机房具备一定电路网路改造能力，同时，在磁带库的使用上，设计和研发配套业务软件也需要一定的人力投入。对于一般用户而言，极冷数据存储的需求选择腾讯云 COS 深度归档服务显然性价比更高一些。
而磁带库在腾讯的大规模落地，也并不是一件易事，是 COS 团队、星星海、供应链、运管、商务、IDC、硬件运营、网平、OS、安平等多个兄弟团队之间相互协作的结果。
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
|