Please enable Javascript to view the contents

运维需要知道的存储知识

 ·  ☕ 15 分钟

1. 存储器

1.1 HDD

HDD（Hard Disk Drive，机械硬盘）利用磁场方向记录信息。盘片表面涂有磁性材料，磁头悬浮在盘面上，通过磁场方向表示 0/1。盘片被划成一圈圈磁道，再切成扇区（常见 4K）。读写时，磁头先横向寻道对准目标磁道，再等目标扇区转到磁头下方。

可以原地改写，不像 NAND 需要先擦后写。延迟主要来自寻道和旋转等待，7200rpm 转半圈大约 4ms，因此顺序读写尚可、随机读写很差。

特点：

  • 容量大、单价低，常见 4–28 TB
  • 顺序读写尚可，100–280 MB/s
  • 随机读写较差，50–200 IOPS
  • 延迟 5–15 ms
  • 使用率可达到 80–90%

适用场景：

  • 数据备份
  • 大容量 / 大文件存储
  • 冷数据、归档、顺序日志

查看设备：

1
2

lsblk -d -o NAME,ROTA,TRAN,MODEL,SIZE
smartctl -a /dev/sdX

ROTA=1 通常是转盘。/dev/sdX 不是 HDD 专属，SATA SSD、SAS、virtio 也会叫这个名字。

注意：

  • 消费级多 SATA，机房常见 SAS（12Gb/s、expander、多路径）
  • 关注 SMART 的 reallocated / pending、振动、坏道
  • 调度器用 mq-deadline / bfq；RAID 重建、fsck、全盘扫描会打满盘
  • 不要把 WAL / 系统盘放 HDD 上，也不要用 RAID / LVM 绑快慢盘

1.2 SSD

SSD（Solid State Drive，固态硬盘）数据落在 NAND Flash 上：按页写入、按块擦除，无法原地改写。FTL 把新数据写到空闲页，旧页作废，等 GC 时再整块擦除。

SLC Cache 先以高速写入，再回刷到 TLC / QLC；缓存打满或盘较满后，速度会掉到原生水平。GC、磨损均衡、回刷都会造成延迟尖刺，标称速度只在 Cache 未满时成立。

类型bit/单元说明
QLC4最便宜、最慢、寿命短
TLC3目前主流
MLC2介于 SLC 与 TLC
SLC1最快、寿命最长、最贵

特点：

  • SATA SSD 容量常见 480 G–3.84 T；顺序约 500–560 MB/s（被接口卡住）；随机 4K 约 5–10 万 IOPS；延迟 50–200 μs
  • QLC 容量常见 4–8 T+；Burst 可接近 TLC，持续写常掉到数百 MB/s，写延迟抖动大
  • 使用率建议低于 80%，QLC 更要留空

适用场景：

  • 读多写少、对象 / 镜像等容量型负载（QLC）
  • 系统盘、轻量库（SATA SSD，尤其没有 NVMe 槽时）
  • 持续重写、数据库日志不适合廉价 QLC

注意：

  • 寿命看 percentage_used / TBW、写放大、温度降速
  • 企业盘有 PLP，掉电能刷回 NAND；消费盘可能丢数据
  • 3.84T 这类规格是给 GC 留的 OP
  • TRIM 用定时 fstrim，不要挂载持续 discard
1
2

smartctl -a /dev/sdX
fstrim -v /

1.3 NVMe

NVMe（Non-Volatile Memory Express）是为闪存设计的存储协议，支持多队列、深队列。本机多走 PCIe，跨机则是 NVMe-oF（RDMA 或 TCP）。设备一般是 /dev/nvme0n1。

相比 SATA / AHCI：NVMe 规格队列上限到 64K，实际盘远小于此。SATA SSD 的性能受限于 NCQ=32 和约 600MB/s。

特点：

  • TLC 容量常见 1.92–7.68 T（可见 15 T+）；顺序 2–14 GB/s（Gen3～Gen5）；随机 4K 约 20–150 万 IOPS；延迟 10–100 μs
  • 使用率建议低于 70–80%
  • QLC NVMe 读尚可、写弱且不稳
  • NVMe-oF（RDMA）吞吐常受 25/100/200GbE 限制，延迟比本机多约 20–100 μs，仍慢于本机 NVMe

适用场景：

  • 容量型、读多写少（QLC NVMe）
  • 共享盘、存算分离（NVMe-oF）
  • 数据库、WAL、虚拟机、高 IOPS（TLC NVMe）

查看设备：

1
2
3
4

lsblk -o NAME,TRAN,TYPE
nvme list
nvme smart-log /dev/nvme0
cat /sys/block/nvme0n1/queue/scheduler

注意：

  • 调度器用 none 或 mq-deadline
  • 队列深度、中断绑核、blk-mq 会影响满载 IOPS

1.4 RAID

RAID（Redundant Array of Independent Disks，独立磁盘冗余阵列）把多块盘组合成一个逻辑卷，换取容量、性能或冗余。可以硬件做（HBA / RAID 卡），也可以软件做（内核 md、Linux 的 mdadm、软 RAID）。磁盘管理上是「先组 RAID 再分区 / 建文件系统」，和单盘一样会暴露成一块块设备。

常见级别：

级别最少盘数容量冗余说明
RAID 02全部无条带化，性能好，坏一块全丢
RAID 1250%1 块镜像，写要写两份，读可并行
RAID 53(n-1)/n1 块条带 + 分布式校验，通用
RAID 64(n-2)/n2 块双校验，能扛两块同时坏
RAID 10450%每组 1 块先镜像再条带，兼顾性能与冗余

特点：

  • 容量和冗余是反的：冗余越高，可用容量越小
  • 延迟下限由单盘决定：单块盘多快，阵列一般不会更快；但随机 IO 可被并行条带摊薄，小写命中需跨盘读改写时延迟更高
  • 校验盘写放大：RAID 5/6 每次小写要读改写，写性能下降、延迟抖动
  • 重建会打满整组盘的 IO，期间性能下降、故障风险上升
  • 硬件 RAID 卡本身是单点，电池 / 掉电保护失效会丢数据
  • 软 RAID 简单、无额外硬件，但占 CPU；两者对上层都是「一块盘」

适用场景：

  • RAID 1：系统盘、数据库日志，要冗余且写少
  • RAID 5/6：容量型大文件、冷数据，能接受重建时间
  • RAID 10：数据库数据文件、高 IOPS 且要冗余
  • 追求纯容量 / 纯性能、不关心冗余时使用 RAID 0，或不做 RAID

注意：

  • 避免同一 RAID 中的盘来自同一批次，故障可能集中出现
  • 关注重建进度与 md 的阵列状态（degraded / rebuilding）
  • 组 RAID 前需明确：RAID 不是备份，误删 / 病毒 / 勒索仍无法恢复
  • 使用 RAID 卡时，查看盘的 SMART 往往需借助直通 / 单盘模式，避免被卡遮蔽

查看阵列：

1
2
3

cat /proc/mdstat
mdadm --detail /dev/md0
smartctl -a -d sat /dev/sdX

2. 数据传输

2.1 SATA

SATA（Serial ATA）是本地串行接口，搭配 AHCI。点对点连接，一口一盘。共享带宽更常见于 SAS expander，或芯片组上多个口争抢总带宽。

特点：

  • SATA III 理论 6Gb/s，实际约 550–600 MB/s
  • NCQ 队列深度 32
  • 设备多为 /dev/sdX，和 SCSI、virtio 混名

适用场景：

  • HDD、早期 / 入门 SSD
  • 顺序读写够用，随机和高并发弱于 NVMe

注意：

  • BIOS 里 AHCI 不要被设成 IDE 兼容
  • 主板口、HBA、线材都可能成为瓶颈
  • 粗序：HDD < SATA SSD < RDMA 网络盘 < 本机 NVMe

查看设备：

1

lsblk -d -o NAME,TRAN,SIZE

TRAN=sata 才是走 SATA。设备名仍可能是 /dev/sdX。

2.2 PCIe

PCIe（Peripheral Component Interconnect Express）是点对点串行总线，带宽由 lane 数（x1 / x2 / x4 / x8 / x16）和代数共同决定。NVMe 盘多为 ×4，廉价 M.2 常见 ×2。可以理解为：PCIe 是传输通道，NVMe 是在其上运行的协议。

单向大约带宽（GB/s），已按编码粗算：

代数单 lane×2×4×8×16
Gen20.51248
Gen3124816
Gen42481632
Gen548163264
Gen68163264128

机房现在常见 Gen3 / Gen4，新机器 Gen5；Gen2 还在老平台，Gen6 刚起步。NVMe 看 ×4 那一列；GPU / 高速网卡常见 ×8、×16。全双工，实际上限还受控制器、NAND、散热限制。

适用场景：

  • 本机 NVMe、GPU、高速网卡
  • 需要 GB/s 级本地带宽时；SATA 不够用

查看链路：

1

lspci -vv | grep -A2 -E 'LnkCap|LnkSta'

对比 LnkSta（实际）和 LnkCap（能力）的 Speed / Width。插错槽、争抢 lane、转接后可能出现降代或减半宽的情况，例如 Gen4 ×4 变成 Gen3 ×2。Gen5 盘容易先遇到散热瓶颈。

2.3 DMA

DMA（Direct Memory Access，直接内存访问）让设备把数据直接搬入 / 搬出内存，CPU 只负责提交描述符，不承担搬运工作。本地 NVMe、网卡、GPU 读写都走 DMA；GPUDirect（GDR / GDS）是在 PCIe 上做 P2P DMA，让设备之间直接传输，无需先经 CPU 内存中转。

特点：

  • 本机盘、网卡读写主机内存，底层都是 DMA
  • GPUDirect RDMA（GDR）：网卡 ↔ GPU 显存，RoCE 流量可不进 DRAM
  • GPUDirect Storage（GDS）：NVMe ↔ GPU 显存，读盘可少一次 cudaMemcpy
  • 对 PCIe 拓扑敏感；GPU 和 NIC 不在同一 switch 上，P2P 可能回退成经 CPU 内存
  • 和 2.4 RDMA 的关系：RDMA 是远程 DMA；GDR 是把 RDMA 的对端从主机内存换成 GPU 显存

适用场景：

  • 所有高速块设备和网卡的数据搬运
  • 多机 GPU 训练，参数 / 梯度走 RoCE 且开 GPUDirect RDMA
  • 大模型 checkpoint 从 NVMe 直读 GPU（GDS）

注意：

  • GDR 需要 NVIDIA 驱动、nvidia-peermem、网卡支持 peer memory
  • GDR 失败时往往静默回退到 host memory，性能明显下降但不一定报错

查看拓扑：

1
2

nvidia-smi topo -m
lsmod | grep nvidia_peermem

P2P 是否可用，先看 nvidia-smi topo -m 里 GPU 和 NIC 是否在同一 switch。

2.4 RDMA

RDMA（Remote Direct Memory Access，远程直接内存访问）让一台机器直接读写另一台机器的内存，省去内核协议栈的拷贝。CPU 仍需提交描述符、处理完成队列。载体：InfiniBand、RoCE，偶见 iWARP。

特点：

  • 延迟低、CPU 占用低、吞吐高
  • 对丢包、PFC / ECN 敏感；RoCE 丢包的影响比 TCP 更明显
  • NVMe-oF 也可走 TCP，此时不是 RDMA，延迟更高
  • 本机 NVMe 通常仍更快，RDMA 远好于 iSCSI / NFS

适用场景：

  • NVMe-oF、部分 SAN、分布式存储后端
  • 存算分离、共享快存储
  • 不适合丢包多、没有把 PFC / ECN 调好的以太网

注意：

  • 关注 Pause 帧、PFC 死锁、ECN、CNP、网卡驱动
  • 吞吐需对照网卡 25/100/200GbE，不要用本机 NVMe 的标称值去对比

查看链路：

1
2

ibdev2netdev
ethtool -S eth0 | grep -iE 'pause|pfc|discard|drop'

排查 RoCE 应先看 Pause / PFC，而不要只看以太网丢包。

2.5 交换机

交换机是存储网络的交汇点：NVMe-oF、iSCSI、RoCE 的数据都要经过它转发，链路质量直接决定存储的延迟与吞吐。存储侧关注的主要是端口与转发能力，而不是路由计算。

特点：

  • L2 / L3：存储网络多为 L2 二层（VLAN 隔离），跨网段才走 L3 路由
  • 线速转发：理想情况每个端口都能跑满线速；背板带宽不足时多口会共享上限
  • 端口缓冲区：突发流量靠端口 buffer 吸收，buffer 不足会丢包，对 RoCE 是致命的
  • PFC / ECN：RoCE 依赖无损网络，靠 PFC 逐跳反压、ECN 标记拥塞，配置不当会死锁
  • IB 与以太：InfiniBand 交换机原生 RDMA、端到端流控；以太交换机靠 RoCE 模拟，需额外调 PFC / ECN

适用场景：

  • 以太交换机承载 RoCE（存算分离、NVMe-oF）
  • IB 交换机用于高性能、低延迟的 RDMA 存储与训练网络
  • 数据中心用 leaf-spine 架构扩展端口规模

注意：

  • 无损网络必须全局开启 PFC / ECN，且队列映射一致，否则出现 PFC 死锁
  • 光模块、光纤、端口速率不匹配会降速或丢包
  • 端口打满前先看是否有广播风暴、环路、聚合配置错误
  • 交换机本身是单点，靠堆叠 / MLAG 提供冗余

查看链路：

1
2
3

ethtool eth0
ethtool -S eth0 | grep -iE 'pause|pfc|drop|discard'
show interface counters（登录交换机）

3. 系统 IO

应用 → VFS → 文件系统 → Page Cache（直接 IO 绕过）→ 块层 → 驱动 → DMA / 总线 → 设备

直接 IO 仍走文件系统和块层，只跳过 Page Cache。NVMe 用 blk-mq；io_uring 减少系统调用。

查看现场：

1
2
3

iostat -x 1
df -h
df -i

3.1 带缓冲 IO

默认路径。读先看 Page Cache，写先写进缓存，flusher 按脏页比例 / 时间回写。fsync / fdatasync 是等待数据落盘（或落到盘内缓存），不是「只有 fsync 才写盘」。没有 PLP 时，fsync 成功也可能只到盘内 DRAM。

特点：

  • 读缓存命中极快，测到的可能是内存
  • 写快往往只是写进内存；脏页堆积后突然刷盘，所有写者会被阻塞
  • dirty_ratio / dirty_bytes、dirty_background_ratio、dirty_expire_centisecs 控制脏页积攒量与刷盘时机

适用场景：

  • 通用文件读写、大多数应用的默认路径
  • 读多、能吃 Page Cache 的负载
  • 需要崩溃一致时仍要自己 fsync

注意：

  • 不带 iflag=direct 的 dd / hdparm 测的是内存
  • 脏页过多会卡住写者，看 /proc/meminfo 的 Dirty / Writeback
  • 分区按 4K 对齐，否则 SSD 写放大变差
  • 不要默认挂载持续 discard
1
2

grep -E 'Dirty|Writeback|Cached' /proc/meminfo
dd if=/dev/zero of=/tmp/test bs=1G count=1 oflag=direct

3.2 直接 IO

O_DIRECT 绕过 Page Cache，数据在用户缓冲和设备之间直接传输，仍经过 VFS → 文件系统 → 块层 → 驱动。需要按逻辑块对齐（常见 4K），未对齐一般会返回 EINVAL。

特点：

  • 延迟更接近设备，不易被 cache 命中造成的假象误导
  • 内核不负责合并、预读，应用必须自行做缓存
  • 元数据、journal 仍可能走缓冲，fsync 依然必要

适用场景：

  • MySQL InnoDB（常用 O_DIRECT）
  • 虚拟机磁盘
  • 用 fio --direct=1 测盘
  • PostgreSQL 默认不是这种，仍是带缓冲 IO

测盘：

1

fio --name=randwrite --filename=/dev/nvme0n1 --direct=1 --rw=randwrite --bs=4k --iodepth=32 --runtime=60

测盘用 direct；测应用体验应按应用真实模式，不要混在一起对比。小 IO、未对齐可能导致失败或无法运行。

4. 文件系统

两个维度不要混淆：ext4 / XFS 是本机盘上的格式；NFS / CephFS / JuiceFS 是多机如何访问。NFS 底层通常仍是 ext4 或 XFS。

findmnt / df -T：源是 /dev/... 且类型为 ext4 / xfs 是本地；nfs4、ceph、fuse.juicefs 是远程。

1
2
3

findmnt -D
df -hT
lsblk -f

4.1 ext4

Linux 最常见的本地文件系统，建在本机块设备上。Ubuntu 系统盘默认多是它。工具链成熟（e2fsprogs），能缩容（但较麻烦）。适合系统盘、根分区、中小数据盘。超大盘、高并行大文件不如 XFS。延迟就是底层那块盘的延迟，且不能多机同时写（除非再通过 NFS 导出去）。

1
2

tune2fs -l /dev/nvme0n1p1 | grep -E 'Filesystem volume name|Block size|Inode'
resize2fs /dev/nvme0n1p1

注意：mkfs.ext4 会清空分区；SSD 用 fstrim；小文件看 df -i。

4.2 XFS

同样是本地文件系统，RHEL / 机房数据盘更常见。分配并行度更好，适合大文件、大容量、多线程写。不能原地缩小，修复需使用 xfs_repair，不要用 fsck.ext4 去修。

和 ext4 处于同一维度，选择哪个只影响单机如何管理这块盘。

1
2

xfs_info /data
xfs_growfs /data

注意：建 FS 前确认设备；分区 4K 对齐。

4.3 NFS

把一台机器上的目录导出，客户端按本地路径读写，数据走网络（通常 TCP 2049）。服务端目录本身仍是 ext4 或 XFS。扩展方式是给那台机器配置更强的硬件；服务端一旦故障，客户端会一并阻塞。

NFSv3 无状态、简单；NFSv4.1 有复合操作、委托、nconnect。新部署用 4.1。

特点：多机一份目录、部署简单；延迟吞吐受网络和服务端盘限制。sync 更安全更慢，async 掉电可能丢最近写入。

适用场景：共享配置、数据集、家目录、备份。不适合数据库 WAL、高并发小文件随机写。

1
2
3

showmount -e 10.0.0.1
mount -t nfs -o nfsvers=4.1,hard,nconnect=4 10.0.0.1:/data /mnt/nfs
nfsstat -c

注意：生产环境使用 hard 并保证服务端高可用；修改 /etc/exports 后执行 exportfs -ra；no_root_squash 相当于把客户端 root 映射为服务端 root；出现卡顿先检查服务端盘和网络；PVC 打满需查看服务端 df。

4.4 CephFS

Ceph 的文件接口。数据存放在多台 OSD 上（副本或纠删码），元数据由 MDS 管理。同一套集群还能对外提供 RBD（块）和 RGW（S3），但这两者不是文件系统。

与 NFS 的差别：不是导出一台机的本地目录，容量随 OSD 增加。与 JuiceFS 的差别：自行管理盘，不依赖外部对象桶。

适用场景：需要统一块 + 文件 + 对象、集群内共享、能够维护 OSD。不适合作为单机系统盘。

1
2
3

df -hT | grep ceph
ceph fs status
ceph -s

注意：性能瓶颈可能在 MDS、OSD 或网络；空间不足需查看存储池 / OSD，而不是某台 NFS 机的 df。

4.5 JuiceFS

把 POSIX 套在对象存储上：数据放在 S3 / OSS / MinIO，元数据存在 Redis / TiKV / PostgreSQL 等，客户端常带本地缓存。类型一般是 fuse.juicefs。

适用场景：训练 / 推理数据集、对象存储要用文件接口、读多写少。不适合数据库。

1
2
3

df -hT | grep juicefs
juicefs status <META-URL>
juicefs stats /mnt/jfs

注意：排障需分层排查本地缓存、元数据引擎、对象存储三层；元数据引擎故障时，即使桶内对象仍在，也无法列出目录。

5. 观测

5.1 snmp_exporter

采集交换机等网络设备的 SNMP。存储虽不直接依赖它，但 NVMe-oF、iSCSI、RoCE 等存储网络的延迟与吞吐都受交换机状态影响，故障往往先在链路上体现。

用途：

  • 端口状态、丢包、错包、CRC 错误
  • 端口吞吐、利用率、光模块收发功率
  • 电源、风扇、温度、设备 up/down

指标：

  • 端口 ifHCInOctets / ifHCOutOctets、ifInErrors / ifOutErrors
  • 端口链路状态（up / down / admin down）
  • 光模块 TX / RX 功率、温度

瓶颈：

  • 端口持续丢包、CRC 错误，说明链路质量差
  • 光模块功率异常或偏低，多为光衰或故障前兆
  • 端口利用率打满，需排查流量或链路聚合
1

snmpwalk -v2c -c public 10.0.0.2 .1.3.6.1.2.1.2.2

5.2 ipmi_exporter

采集主板 IPMI / BMC 的硬件监控。存储节点盘多、功耗高，机箱风扇、电源、硬盘背板温度都是磁盘寿命的间接风险因素。

用途：

  • 机箱温度、风扇转速、电源状态
  • 硬盘背板 / 控制器温度
  • 硬件告警（SEL 事件、SDR 阈值）

指标：

  • ipmi_temperature_celsius、ipmi_fan_speed_rpm
  • ipmi_power_supply_state
  • ipmi_sel_entries

瓶颈：

  • 风扇异常或温度超标，先降速再宕机
  • 电源冗余丢失，冗余级别下降
  • SEL 事件堆积，说明有未被处理的硬件故障
1
2

ipmitool sdr list
ipmitool sel elist

5.3 smartctl_exporter

抓 HDD / SSD / NVMe 的 SMART。现在 smartctl 也能读取 NVMe 的 SMART，一般不必再单独做一套 nvme 文本采集。

用途：

  • 坏道、寿命、温度、掉电
  • 企业盘 spare、percentage_used
  • 与 node_exporter 搭配：一个反映「当前性能慢」，一个反映「盘是否即将故障」

指标：

  • temperature
  • available_spare、percentage_used
  • media_errors
  • reallocated / pending

瓶颈：

  • pending 上涨，应准备换盘
  • spare 降至门限，触发 critical_warning
  • 温度触发降速、throttle
  • percentage_used 逼近 100%，说明写放大已很高

5.4 node_exporter

覆盖本机容量、磁盘 IO、内存脏页、PSI、网卡。这是存储观测的底座。

用途：

  • 文件系统和 inode 是否打满
  • 磁盘吞吐、IOPS、繁忙程度
  • 脏页是否堆积、任务是否在等待 IO
  • 网卡 / InfiniBand 计数（RDMA、NVMe-oF 时一并查看）

指标：

  • node_filesystem_avail_bytes、node_filesystem_files_free
  • node_disk_read_bytes_total、node_disk_written_bytes_total、node_disk_io_time_seconds_total、node_disk_io_now
  • node_memory_Dirty_bytes、node_memory_Writeback_bytes
  • node_pressure_io_waiting_seconds_total
  • node_network_*，InfiniBand 开 --collector.infiniband

瓶颈：

  • 文件系统或 inode 打满，SSD 越满越慢
  • node_disk_io_time 持续升高；Dirty 堆积后出现写延迟尖刺
  • IO PSI 高，说明任务在等待磁盘，不一定是 CPU 不足
  • 多队列 SSD 上 util 容易接近 100%，不代表已打满。告警应看写延迟、队列、应用 p99
  • await 需用 node_disk_read_time / write_time 除以操作次数自行计算，node_exporter 不直接提供 iostat 中的 await

5.5 process-exporter

用于查看是哪个进程在占用磁盘。node_exporter 只能说明设备繁忙，却无法指出具体进程。

用途：

  • 备份、compaction、日志切割、容器内某个 Pod 打满磁盘
  • 与 cAdvisor / kubelet 互补：宿主机看进程，K8s 上看 PVC / 容器

指标：

  • 进程 read_bytes / write_bytes
  • 进程 IO 延迟

瓶颈：

  • 单进程打满写操作
  • 某个任务刷爆 Dirty，导致其他写者被阻塞
  • 只看 node_exporter 会遗漏 PVC 打满；只看 kubelet 会遗漏盘即将故障、SLC Cache 掉速。宿主机和容器两层都需覆盖
微信公众号
作者
微信公众号

相关内容