Cost-efficient Archive Cloud Storage with Tape: Design and Deployment
今日分享论文为 FAST'26 顶会论文，原文链接为 Cost-efficient Archive Cloud Storage with Tape: Design and Deployment
@article{wangcost,
title={Cost-efficient Archive Cloud Storage with Tape: Design and Deployment},
author={Wang, Qing and Yang, Fan and Liu, Qiang and Xiao, Geng and Chen, Yongpeng and Lan, Hao and Chen, Leiming and Chen, Bangzhu and Liu, Chenrui and Bai, Pingchang and others}
}团子导读：深度冷存储与 TapeOBS
深度冷存储的特征
- 写远多于读。 论文给出了生产数据：最大客户的读操作仅占 0.000112%，多位客户甚至从未发起过读请求。这是一种极端的 write-heavy 工作负载。
- 恢复有小时级 SLA。 用户接受数小时的等待——这在普通对象存储中几乎不可想象，但正是这种宽松的时间窗口给了系统做批量调度的空间。
- 数据生命周期长、删除少。 数据一旦写入就要保存数年乃至数十年。用户主动删除极为罕见，多数在过期后自动清理。
- 对 TCO 极其敏感。 存储的是"不得不留"的数据，业务上不会为之付出高额的存储溢价。论文的数据显示，基于磁带的方案 TCO 是 HDD 方案的 1/4.95。
这些特征决定了深度归档存储的设计哲学：一切为成本让路，性能和延迟退居其次。
磁带库与 HDD 的核心区别
磁带库的物理特性带来了一组和 HDD 完全不同工程约束：
1) 存储与访问设备解耦。 HDD 中盘片和磁头是密封在一起的，任何时候都可以读写。磁带库中，1000 盘磁带只配 4 个驱动器——存储介质和读写设备是物理分离的。一个驱动器一次只能服务一盘磁带。这种极端的不对称比（1000:4）是磁带库最核心的约束。
2) 切换代价极高。 将一盘磁带从存储槽装载到驱动器需要约 80 秒——倒带、卸载旧磁带、机械臂搬运、装载新磁带。如果驱动器频繁在不同磁带之间切换（论文称之为"驱动器抖动"），有效带宽会断崖式下降。仅仅在每 23.2GB 数据后做一次切换，有效带宽就已经减半。
3) 顺序访问介质。 HDD 虽然随机读写性能不佳，但至少可以在毫秒级完成寻道。磁带需要正/反向卷带来定位数据，寻道时间远超 HDD。同时，磁带的内部由数百个磁道组（wrap）构成，相邻磁道组的访问方向相反，直觉上按逻辑块顺序访问反而会产生大量不必要的物理寻道。
4) 成本结构不同。 磁带单价低（$/GB 比 HDD 低 50% 以上）、寿命长（10 年 vs. 5 年）、闲置零功耗。但驱动器昂贵，带宽受限。可以理解为：存储容量几乎免费，但访问能力是稀缺且昂贵的资源。
这些差异决定了，不能简单地"把 HDD 换成磁带"——需要从架构层面为磁带的物理约束做专门的设计。
本文的核心亮点：应对磁带物理约束的系统设计
围绕磁带的特性展开：
1) 完全异步的磁带池。 TapeOBS 在磁带池之上维护了一个容量约为磁带池 4% 的 HDD 池作为持久化写缓冲。用户写入先落 HDD 池（高可用），然后异步刷入磁带池。用户恢复请求同样异步处理——反正 SLA 是小时级的。这样对磁带池的所有读写都是异步的，解耦了用户请求速率和磁带驱动器的有限带宽。而且方便实现批量调度读写。
2) 专用驱动器。 将 4 个驱动器静态分为写驱动器（2 个）、读驱动器（1 个）和内部驱动器（1 个）。不同任务有不同的访问模式：写是持续顺序追加、读是用户驱动的随机访问、内部操作（GC/一致性检查/EC 修复）通常长时间聚焦同一盘磁带。如果所有驱动器共享所有任务，全部驱动器都会遭受抖动。静态划分后，写驱动器和内部驱动器可以全速运行。
3) 批量纠删码（b-EC）。 TapeOBS 通过在服务层聚合多个对象再做 EC（跨对象 EC），使得多数对象只落在一盘磁带上，其恢复只需一个驱动器。其实在我们的 HDD 大条带 EC 中也可以参考。
4) 面向磁带的本地存储引擎。 在磁带库头节点的 NVMe SSD 上构建了简单的 KV 存储，持久化维护子 PLog 元数据。使用 SCAN 算法对读请求按物理位置排序，减少寻道。
论文还记录了一个有趣的工程发现：磁带驱动器的流量控制问题。驱动器内部有缓冲区，会根据主机提交速率选择写入速度。如果提交速率抖动，驱动器可能错误估计主机速度并选择较低的速度，导致持续的性能下降。通过读取驱动器缓冲区大小来估算驱动器速度，并用速率限制器对齐提交速度。这类问题只有在实际部署中才能遇到，论文公开分享，对后来者很有参考价值。
Append-Only 性质与 Append-Only 系统
现代磁带（如 LTO 系列）是 append-only 的，无法就地更新。原因和 SMR（叠瓦式磁记录）硬盘类似：为了提升存储密度，数据磁道采用叠瓦式重叠排列。就地覆写会破坏相邻磁道的数据。SMR HDD 在消费级市场因这一特性引发了不少争议，但在归档存储场景下，append-only 反而是天然适配的。
append-only 存储在分布式系统中其实是一种被广泛接受的模式。笔者在 RocksDB 存算分离 中也提到，追加写文件系统是很受欢迎的——BigTable、HBase、Spanner 都构建在追加写文件系统之上。追加写牺牲了随机写语义，换取了分布式系统设计和容灾机制的简化。
TapeOBS 天然利用了这种 append-only 特性。PLog（持久化日志）作为基本存储单元也是 append-only 的：创建、追加、封存，之后变为不可变。日志结构化写入使得驱动器可以持续向同一盘磁带顺序追加，最大限度减少了驱动器切换和寻道。磁带的分区机制则提供了有限的独立追加点，放宽了纯顺序写的约束。
append-only 天生也带来的垃圾回收（GC）问题（这个缺点其实和磁带无关，只是磁带介质大幅度放大了 GC 的影响）。HDD 上的 GC 涉及的是磁盘读写，而磁带上的 GC 还要面临驱动器切换和卷带寻道的额外开销。TapeOBS 结合业务特性通过基于生命周期的数据分组缓解了这个问题。
导读小结
这是一篇极具实际意义和工程价值的系统论文，详细介绍非常多磁带深度冷存储的细节。对正在构建深度冷存储、混合存储的读者非常有实践意义。设计重度 GC 存储系统的开发者也可以参考。非常推荐阅读。
受限于老博客的架构，完整论文翻译请移步 https://storage-memo.steinslab.io/sys/fast26-tape/，感谢！
