HDD Usage

即使我作为一名 2016年上大学的老狗，我遥想，哪怕是在我入学那个年代，HDD 在笔记本电脑上做系统盘也已经将是过去了，彼时我看到家里台式开机要一分钟多（然后家里的神秘软件提醒你开机花了一分钟），然后上大学新买的笔记本开机只要半分钟，这给了小小的我比较大的震撼（这台笔记本没用多久我就换 Mac 了，花了当时我眼里的巨款，Mac 陪我度过了整个大学四年）。然后上学的时候其实发现大家情况都差不多，没什么 HDD 机器，只有我的舍友有 HDD NAS 盘。后面做 DB 的时候，其实基本没有什么 Storage System on HDD 的 paper，我印象中很深的是，RocksDB 和 WiscKey 很多地方都说明了自己专门给 SSD 做优化，包括 2020 年以后，TUM 的很多 paper 也在挖掘 io_uring 和 NVMe 的带宽（我打满了 4KB 读写 iops/带宽 ！我无敌了！<— 大概是这个画风），我们回忆一下，io_uring for High-Performance DBMSs: When and How to Use It 给的 1.5M iops。那 HDD 呢？正常盘可能 150-170 4KB iops，读单盘吞吐能打到 300MiB/s，然后近线一般的盘可能 7200RPM，150-180 iops（当然有一些技术能让这些 IOPS 增长 2-3 倍，比如 MACH.2 或者高吞吐盘）。额，你确定要用？而且 SSD 单盘容量也好做，QLC 盘现在都有能买的 120TiB 的了。像 Five Minutes Rule 在 20 年 21 年左右推算的成本曲线中，SSD 过几年就在任何角度都能一脚踢死 HDD 了（包括成本上）。

那故事哪里变了呢，首先我们要讲一个一句话鬼故事：诶我看 S3 （对象存储）不是跑在 HDD 上吗？相对于全闪+高性能网络的集群，HDD 这套可能存算比需要调整一下，机器带更多的盘，然后希望上游用更顺序的读写来饱和 IOPS 和带宽。这套价值在于，2026 年 SSD 价格 / HDD 价格可能比 2021 年那篇论文发的时候还悬殊了，因为 SSD 因为众所周知的原因价格在狂飙。然后图片呀视频啊量比较大，访问又是大部分时候是顺序的，比较适合存储在 HDD 上。这里最重要的还是成本问题。我找 AI 列了一下表格，不一定完全靠谱，毕竟企业采购价格之类的可能不一样，但是可以作为参考:

  1. SMR/CMR-HDD 仍是容量成本地板：$40/TB 量级（合约）/ $35–54（零售），SMR 比同代 CMR 再高约 8–15% 容量、/TB 更低，但只适合顺序写、需要主机端 zoned/SMR 栈支持；
  2. QLC SSD：$603/TB，约为 HDD 的 14.9 倍，但随机读 IOPS / 瓦、机架密度领先两个数量级（122TB 单盘 vs HDD 32TB），是 AI 数据湖 / 对象存储 / CDN 的 HDD 替代层；
  3. TLC SSD：$753/TB，约为 HDD 的 18.6 倍、QLC 的 1.25 倍，买的是 1–3 DWPD 耐久、稳态写性能和低延迟（读延迟 60µs 级 vs HDD 平均 4.16ms）；
  4. HAMR（Exos M）不是独立第四类介质，写入语义仍是 CMR，成本介于传统 CMR 与 SMR 之间，意义是把 CMR 单盘容量推到 32/36TB、改善 W/TB；

额，那为什么我们个人用户不买 HDD ？其实现在很多个人用户需求被云卡住了，小企业自己上云买东西虽然其实比自己组硬件贵很多，但是对他们来说确实少了很多麻烦。但云厂商或者企业规模如果大了，就会感觉，啊我觉得 HDD 编程虽然麻烦（可能要做好 EC 之类的东西），但对企业来说，可以苦一苦程序员和硬件、固件之类的部门，让相关部门写 HDD 代码来降低很多冷数据或者近线数据存储的成本。

HDD 的硬件和近线服务

img

img

我们先再详细介绍一下这块知识（虽然大家应该都看过了）

这个图大家应该都看过很多次了，我们以读写来介绍一下这里的行为。这里也可以看 Branch Education 的一个科普视频 How do Hard Disk Drives Work? (Youtube) 来粗略的了解一下这一块的细节。

  1. HDD 是多个盘片组成的
  2. Spindle 是带着大家一起转的，转的速度相对快
  3. Actuator 会 Seek 到对应的位置来读写，这里上面有对应的读写头
  4. 盘片的几何结构会有一些很简单的推论，比如外道读取比内道块

然后这里可能你会发现，诶我并发上不去啊，因为它机械臂可能就这么一个。当然这里有 MACH.2 之类的方式，大大增加复杂性，来提升这里读取 iops/带宽

img

我们接下来会有一个问题，Linux 之类的机器上，SSD/HDD 被抽象为块设备，这个块可能对应盘面上 512B/4KiB 的 Sector。我们可以有一个大概的规则（所以，我们可以按照 LBA 的规则，来推算一些大致规则）：

img

所以根据这个规则有一些简单的推论。

1
2
3
4
5
6
7
8
9
10
11
速度
(MB/s)
  280 │╲
  240 │  ╲
  200 │    ╲___
  160 │        ╲___
  120 │            ╲____
   80 │                 ╲___
      └──────────────────────→ LBA
        0                  最大
       (外圈)              (内圈)

当然这个并不完全，盘上可能会有坏块什么的。但大概是我们拿硬件可以观测到这样的规则。所以，有的地方如果把 HDD 当成近线或者在线的设备，盘可能会控制：

  1. 真的能 Aware 使用块分布方式的话，可能会把热块放到把经常读写的东西放在 (1) 低 LBA 的地方，来保证转速快 (2) 可能会把这种数据放到中间，这样大家都离它很近了
  2. 可能会控制盘的使用水位（极端场景可能使用30-40%）。SSD 控制盘水位通常根 WAF / GC 有关，而 HDD 通常为了近线的使用这些数据。

HDD 的使用模式

HDD 适合什么场景呢？我们其实可以根据贫乏的 iops 想到，对于 SSD 而言，写的顺序性和 Block Size 会影响 SSD 的写放大和 GC，对于 HDD 来说，我们可以想到：

  1. 在单盘上，我一端是顺序 IO，就是我完全顺序的去用（这里读写都算， 毕竟你大部分时候怎么写的就得怎么读）；另一端是很随机的按照 4K 或者更小的 512B Block 来随机 IO。但其实这中间是能 Trade-off 的，我比方说用 1、2、4 MiB 这样稍微大点的大小（当然，可以更大）的大小来写呢？
  2. 这样，我们比方说，在集群里面，按照这些大小来用，然后把这个打散，能利用更大的容量

(2) 我们之前会看到，这块东西…其实就是 RAID 0 所做的，比如条带这个词起源于 RAID（RAID 0 就叫 striping）。想象 4 块盘，把一个文件按固定大小（stripe unit，比如 64KB）轮流写：

1
2
3
4
5
6
逻辑文件:  [U0][U1][U2][U3][U4][U5][U6][U7]...

盘1: U0  U4  ...
盘2: U1  U5  ...
盘3: U2  U6  ...
盘4: U3  U7  ...

事实上我们会发现，诶我们走到了做 RAID 的前辈走过的路上。上面这张图 U0 之类的被当作 Stripe Unit。那么我们继续按照 RAID 的思路来分析一下：

  • RAID-0 相当于单副本，通过并行换性能
  • RAID-1 相当于2副本;
  • RAID-5 相当于EC的k+1模式, k个数据块+1个校验块;

我们也会发现，这块 RAID-5/RAID-6 其实在往前走一步，某种程度上还能到 EC 上。这下都通了。这里我们有 Striping 这样的单元来做「比较顺序的写」，然后也有 EC 来做某种程度上的备份冗余。所以在 Meta 和 Google 的文章中，都提到了 EC 的重要性，用这个做冗余。

我们有一些内容作为佐证：

  1. Colossus under the hood: a peek into Google’s scalable storage system https://cloudblog.withgoogle.com/products/storage-data-transfer/a-peek-behind-colossus-googles-file-system
  2. f4: Facebook’s Warm BLOB Storage System https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-muralidhar.pdf
  3. Facebook’s Tectonic Filesystem: Efficiency from Exascale https://www.usenix.org/system/files/fast21-pan.pdf
  4. Availability in Globally Distributed Storage Systems https://www.usenix.org/event/osdi10/tech/full_papers/Ford.pdf

HDD 的部署

SSD 部署的时候，我大概可以划分一个大概的部署:

  1. SSD: 2U24，24 个（也有32个的）前置热插拔 NVMe/SAS/SATA 盘位，当然这 24 是数据盘，系统盘可能有额外的 M.2 之类的插口
  2. HDD: 4U60，可以插 60 块 HDD 盘，当然也能插一些 SSD 或者 WAL 或者系统盘什么的

那我们会发现，SSD 我比方说哪怕是 PCIe Gen4，我可能存储都是 2×100GbE、2×200/400GbE 这种配置，HDD 呢？我们算一个 60 x 300MB = 18GB/s，可能我插两张 25G 网卡挺好了（X）。当然，这里有可能会考虑插 SSD 盘作为 HDD 的缓存，不过这里插盘也有问题，就是本来大家 60 块盘挂一块挺好的，现在你如果一张服务这60张，那这个故障率本身也得好好考虑了。

关于部署，我们肯定能提到坏盘。Backblaze 会有一些坏盘 AFR 统计：

img

看着大概 SSD 好点，不过其实坏盘机理不一样，SSD 还有经常换固件的、HDD 也有什么摆一起了互相影响之类的问题。此外，我们也说了机器可能插 60块 HDD 盘，这样我们拿 AFR 1.4% 算，可能 4U60 一年内就平均每节点每年坏 0.84 块了。反正做存储的各种情况都得考虑盘坏了重建之类的问题，对于 HDD，这个负担原则上会比 SSD 重一些（毕竟写的慢），可能需要细一点的设计。