Please enable Javascript to view the contents

运维需要知道的存储知识

 ·  ☕ 23 分钟

1 易失存储器

1.1 REG

REG（Register，寄存器）是 CPU 内部的存储单元，位于运算单元旁边，是存储层次中最快、容量最小的一层。通用寄存器（如 x86 的 RAX/RBX/RDI 等）直接参与指令运算，访问延迟约 0.2–0.5 ns（约一个时钟周期），掉电即失，容量一般只有几十到几百字节。

特点：

  • 速度最快：位于 CPU 内、与运算单元直连，是 CPU 最快能取到的数据
  • 容量极小：通常几十到几百个字节，按「个」计数
  • 掉电即失，属于易失存储器
  • 对程序员 / 编译器可见，寄存器分配由编译器和调用约定决定

适用场景：

  • 存放指令运算的中间值、操作数、地址
  • 参数传递与函数调用约定（ABI）
  • 高性能代码的局部热点数据

注意：

  • 寄存器是 CPU 硬件资源，运维一般不直接管理，但对理解进程上下文切换、性能剖析（如 perf）有帮助
  • 上下文切换时寄存器状态需要保存 / 恢复，切换频繁会带来开销
  • 数量有限，不能作为大容量存储使用

查看：

1

grep -m1 flags /proc/cpuinfo

1.2 SRAM

SRAM（Static Random Access Memory，静态随机存取存储器）用触发器电路保存位，不需要像 DRAM 那样周期性刷新，因此访问更快（延迟约 0.5–2 ns）、也更贵、更占面积。常用于 CPU 的 Cache（L1/L2/L3）以及寄存器的缓存层。掉电即失，属于易失存储器。

特点：

  • 速度快、无刷新：访问延迟通常比 DRAM 低一个数量级（几 ns）
  • 贵、密度低：电路单元大，同样面积容量远小于 DRAM
  • 无需刷新：用双稳态电路保持数据，但掉电仍丢失
  • 通常被用作 Cache，不是主存

适用场景：

  • CPU Cache（L1 / L2 / L3）
  • 高速缓冲、TLB 等 CPU 内部结构
  • 需要极低延迟的暂存数据

注意：

  • SRAM 一般不作为主存，容量小、成本高
  • 运维关注的是它所在的 Cache 层级：Cache 命中率影响性能，多级 Cache（L1/L2/L3）逐级扩大但变慢
  • 查看 Cache 大小与层级可指导性能优化

查看：

1
2

lscpu | grep -iE 'cache|model name'
cat /sys/devices/system/cpu/cpu0/cache/index*/size

1.3 DRAM

DRAM（Dynamic Random Access Memory，动态随机存取存储器）是 CPU 的暂存空间，掉电即失。按字节寻址、可随机访问，容量通常几十到几百 GB，带宽取决于 DDR 代数与内存通道数，延迟约 60–100 ns。相比硬盘，内存是「快的设备」，也是 Page Cache、tmpfs、io_uring 队列等的落脚点。

特点：

  • 按字节寻址、可原地读写，无需像 NAND 先擦后写
  • 延迟 ns 级，比 NVMe（μs 级）快几个数量级；容量又远小于显存 / 硬盘
  • 带宽受 DDR 代数与通道数限制，多通道并行才有高带宽
  • 掉电数据丢失，不是持久存储；ECC 内存可纠正单比特错误

适用场景：

  • 应用工作内存、JVM / 数据库缓冲池
  • Page Cache（文件读写的缓存层）
  • tmpfs / /dev/shm（临时目录）

注意：

  • OOM：内存不足时内核触发 OOM Killer，可能杀掉关键进程；先看 /proc/meminfo 与 cgroup 限制
  • 开启 swap 时，内存压力会落到磁盘，出现「内存慢」其实是磁盘慢
  • NUMA：多路服务器内存分布在多个 node，跨 node 访问带宽下降，绑核 / 绑 NUMA 可避免
  • ECC 与内存故障：关注 edac / mcelog，内存错误会逐步累积导致系统不稳定

查看：

1
2
3
4

free -h
cat /proc/meminfo
numactl --hardware
dmidecode -t memory | grep -E 'Size|Speed|Type:'

1.4 VRAM

VRAM（Video Random Access Memory，显存）是 GPU 自带的高速存储，用于存放模型参数、中间激活、KV Cache 等，访问延迟约 100–200 ns。数据中心 GPU 的显存多为 HBM，消费级 GPU 多为 GDDR。显存与系统内存物理隔离，数据需经 PCIe 在两者之间拷贝。

特点：

  • 容量：A100 40/80 GB，H100 80 GB，H200 141 GB；消费级如 RTX 4090 24 GB
  • 带宽极高：H100 约 3.35 TB/s，是系统内存带宽的数倍
  • GPU 直接访问显存，不经过 CPU 内存
  • 显存不足时不像 swap 那样能优雅降级，通常直接报 CUDA OOM

适用场景：

  • 大模型训练：参数、梯度、优化器状态、激活
  • 推理：模型权重 + KV Cache（vLLM / TensorRT-LLM）
  • 与存储相关：GDS 直接把 checkpoint 从 NVMe 读入显存，跳过内存中转

注意：

  • CUDA OOM 常见诱因：KV Cache 过大、并发进程过多、碎片化；先看 nvidia-smi
  • 多进程 / 多容器共享显存，注意隔离与 MPS / MIG
  • 显存不足时可 CPU offload、张量并行，但会牺牲吞吐

查看：

1
2

nvidia-smi
nvidia-smi --query-gpu=memory.total,memory.used,memory.free --format=csv

1.5 HBM

HBM（High Bandwidth Memory，高带宽内存）是一种 3D 堆叠 DRAM，通过硅通孔（TSV）垂直互联、以宽总线访问，专为高带宽而设计，访问延迟约 100–200 ns。数据中心 GPU（A100 / H100 / H200 / MI300）的显存基本都是 HBM。

特点：

  • 高带宽：HBM3e 单颗可达 1.2 TB/s+，H200 整卡约 4.8 TB/s
  • 容量相对小、成本高：受堆叠层数、良率限制，容量往往小于 GDDR
  • 与 GDDR 的区别：GDDR 走独立内存总线、容量大但带宽相对低；HBM 宽总线、带宽极高、更省电
  • 贴装于 GPU 同一基板，不占 PCIe 带宽

适用场景：

  • 大模型训练 / 推理的高带宽需求，主要受显存带宽限制的场景
  • 高带宽、低功耗优于 GDDR 的场景（数据中心 GPU 标配）

注意：

  • HBM 故障多为整卡问题，靠 nvidia-smi / ECC 计数观测
  • 高带宽不能替代容量；带宽打满时会成为训练 / 推理吞吐瓶颈
  • 判断瓶颈是「显存容量」还是「显存带宽」，分别看 nvidia-smi 的 Used 与 utilization

查看：

1
2

nvidia-smi -q -d MEMORY
nvidia-smi -q | grep -iE 'HBM|Memory|Bandwidth'

2 非易失存储器

2.1 HDD

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

可以原地改写，不像 NAND 需要先擦后写。延迟主要来自寻道和旋转等待，延迟约 5–15 ms，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 绑快慢盘

2.2 SSD

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

SLC Cache 先以高速写入，再回刷到 TLC / QLC；缓存打满或盘较满后，速度会掉到原生水平。访问延迟约 50–200 μs，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 /

2.3 NVMe

NVMe（Non-Volatile Memory Express）是为闪存设计的存储协议，支持多队列、深队列，访问延迟约 10–100 μs。本机多走 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

3 数据传输

3.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。

3.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 盘容易先遇到散热瓶颈。

3.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 内存
  • 和 3.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。

3.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，而不要只看以太网丢包。

3.5 Switch

交换机是存储网络的交汇点：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

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

登录交换机后执行 show interface counters。

4 系统 IO

应用的读写并不会直达设备，而是要穿过一条完整的路径。默认情况下，数据先经 VFS、文件系统进入 Page Cache（内核缓存），再由块层、驱动通过 DMA 写到设备：

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

Direct IO 只是跳过 Page Cache 这一层，其余路径不变，仍会经过文件系统和块层。现代 NVMe 使用 blk-mq 多队列调度；io_uring 通过减少系统调用，提升高并发下的吞吐。

查看现场：

1
2
3

iostat -x 1
df -h
df -i

4.1 Buffered IO

Buffered IO 是应用默认的读写路径。读数据时先查 Page Cache，命中则直接从内存返回，无需访问磁盘；写数据时先写进 Page Cache，再由内核的 flusher 线程按脏页比例或时间阈值异步回写到磁盘，而不是每条写入都立刻落盘。因此读写都经过内核缓存这一中转。

fsync / fdatasync 的作用是等待数据落盘（或至少落到盘内缓存），它不代表「只有 fsync 才写盘」——平时 flusher 一直在后台刷盘。另外要注意，若磁盘没有 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

4.2 Direct IO

Direct 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、未对齐可能导致失败或无法运行。

5 逻辑存储

逻辑存储是把底层物理设备（HDD / SSD）进一步组合、划分成逻辑卷的层面，位于文件系统之下。典型代表是 RAID（多盘组阵列）和 LVM（跨盘做卷管理）。

5.1 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

5.2 LVM

LVM（Logical Volume Manager，逻辑卷管理）把多块盘或分区聚合成一个卷组，再从中切出任意大小的逻辑卷，用于灵活的扩容、缩容和迁移。层级是：物理卷（PV）→ 卷组（VG）→ 逻辑卷（LV），LV 上再建文件系统。

层级：

  • PV（Physical Volume）：物理卷，可以是整块盘或一个分区，pvcreate 初始化
  • VG（Volume Group）：卷组，多个 PV 的集合，vgcreate 建立
  • LV（Logical Volume）：从 VG 中切出的逻辑卷，lvcreate 建立，格式化后挂载使用

特点：

  • 扩容/缩容灵活：可在线 lvextend / lvreduce 调整 LV，文件系统再 resize2fs / xfs_growfs 跟进
  • 跨盘聚合：多个 PV 组成一个大的 VG，再按需切分，容量利用率高
  • 支持快照（snapshot）、条带化（stripe）、镜像（mirror）等高级特性
  • 本身不提供冗余：冗余通常由底层 RAID 或上层复制承担；丢盘后 VG 可能降级或无法挂载

查看卷：

1
2
3

pvdisplay
vgdisplay
lvdisplay

6 本地文件系统

本地文件系统是建在本机块设备（或逻辑卷）上的格式，一次只能被一台机器直接挂载读写。findmnt / df -T 中源为 /dev/... 且类型为 ext4 / xfs / btrfs / zfs 的即本地文件系统。

1
2
3

findmnt -D
df -hT
lsblk -f

6.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。

6.2 XFS

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

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

1
2

xfs_info /data
xfs_growfs /data

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

6.3 Btrfs

Btrfs（B-tree File System）是 Linux 上的 CoW（写时复制）文件系统，提供子卷、快照、压缩、校验和等特性，RHEL 用于系统盘的默认选项（Fedora 系）。数据校验会带来一定开销，写放大高于 ext4；快照与回滚对系统盘、容器镜像友好。

1
2
3

btrfs filesystem usage /data
btrfs subvolume list /data
btrfs filesystem df /data

注意：用 btrfs 而不是 fsck.ext4 检查；快照不是备份，原数据损坏时快照同样可能受损。

6.4 ZFS

ZFS（Zettabyte File System）是带存储池的文件系统，集成校验和、快照、压缩、RAID-Z 与缓存（ARC / L2ARC）等能力，常搭配 OpenZFS 使用，在 NAS / 存储服务器上常见。单盘设备通常是 /dev/zvol 或挂载点，而不是裸块设备。

1
2
3

zpool status
zpool list
zfs list

注意：内存建议配大（ARC 会吃内存）；RAID-Z 扩容复杂，通常整体重建；L2ARC 掉电不持久。

7 网络文件系统

网络文件系统让多台机器通过共享接口访问同一份数据，底层仍落在某台机器或集群的本地文件系统 / 对象存储上。findmnt / df -T 中类型为 nfs4、ceph、fuse.juicefs 的即网络文件系统。

7.1 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。

7.2 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。

7.3 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

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

7.4 3FS

3FS（Fire-Flyer File System）是 DeepSeek 开源的分布式文件系统，数据分片存放在多台存储节点的 SSD 上，元数据由 Meta Service 管理，客户端经 RDMA（RoCE / InfiniBand）拉取数据，面向大模型训练 / 推理的高吞吐读取。与 CephFS 同属自建存储集群，容量随存储节点扩展。

特点：面向 AI 的高带宽读取、走 RDMA、数据与元数据分离；与 JuiceFS 的差别是不依赖外部对象桶。

适用场景：多 GPU 节点共享训练 / 推理数据集、checkpoint 高速读取。部署门槛比 NFS 高，需 RDMA 网络与多节点规划，小规模收益有限。

1
2

df -hT | grep -i 3fs
ethtool -S eth0 | grep -iE 'pause|pfc|discard|drop'

注意：性能瓶颈常在 RDMA 网络与存储节点 SSD；数据面走无损网络，优先看 PFC / 丢包；排障需分层排查客户端、Meta Service、存储节点。

8 运维监控

8.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

8.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

8.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%，说明写放大已很高

8.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

8.5 process-exporter

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

用途：

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

指标：

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

瓶颈：

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

9 性能指标

9.1 IOPS

IOPS（Input/Output Operations Per Second，每秒输入输出次数）衡量存储每秒能完成的读写操作次数，适合评估随机访问和小块 IO 能力。数字越大越好，但需说明块大小与读写比例才有意义。

特点：

  • 关注「操作次数」，与块大小、IO 模型（顺序 / 随机）强相关
  • 随机 4K 是衡量随机 IOPS 的典型场景；顺序大块更适合看吞吐
  • 常见数值：HDD 随机约 50–200 IOPS，SATA SSD 约 5–10 万，NVMe 约 20–150 万

查看：

1

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

9.2 Throughput

吞吐衡量存储单位时间能传输的数据量，单位为 MB/s 或 GB/s，适合评估顺序读写和大块传输能力。它等于「IOPS × 块大小」，所以大块顺序 IO 主要看吞吐。

特点：

  • 关注「数据量」，适合顺序读写的容量型负载
  • 受接口、协议、队列深度影响：SATA SSD 约 500–560 MB/s，NVMe 可达 2–14 GB/s
  • 与 IOPS 互补：同一条链路，块越大越偏向吞吐，块越小越偏向 IOPS

查看：

1

fio --name=seqread --filename=/dev/nvme0n1 --direct=1 --rw=read --bs=1M --iodepth=16 --runtime=60

9.3 Latency

延迟衡量单个 IO 从发出到完成的时间，单位为 ns / μs / ms，反映存储的响应快慢。延迟越低越好，尾延迟（p99 / p99.9）比平均延迟更能反映真实体验，因为尖刺会拖垮长尾。

特点：

  • 平均延迟掩盖抖动，关注 p99 / p99.9 尾延迟
  • 不同存储数量级不同：内存 ns 级、NVMe μs 级、HDD ms 级
  • 写放大、GC、回刷、SLC Cache 打满都会造成延迟尖刺

查看：

1

fio --name=lat --filename=/data/fio.test --direct=1 --rw=randread --bs=4k --iodepth=1 --runtime=60

9.4 Bandwidth

带宽衡量链路的理论传输上限，与吞吐相关但侧重「链路 / 协议能力」。吞吐是实际测到的传输量，带宽是上限；两者贴近说明接近打满链路。

特点：

  • SATA III 约 6Gb/s（实际约 550–600 MB/s），PCIe Gen3 ×4 约 4GB/s，Gen5 ×4 约 16GB/s
  • 多盘 / 多链路可并行聚合，带宽随之叠加
  • 网络存储还受网卡带宽（如 25/100/200GbE）限制

查看：

1
2

lspci -vv | grep -A2 -E 'LnkCap|LnkSta'
ethtool eth0 | grep -i speed

9.5 QD

队列深度（Queue Depth）表示同一时刻在途（未完成）的 IO 数量，决定存储能否打满。深队列利于顺序吞吐与高 IOPS，但会增加延迟；浅队列适合低延迟场景。

特点：

  • 队列深度 = 并发在途请求数，是 fio 里 --iodepth 的参数
  • 深队列（如 32/128）榨取吞吐和 IOPS，浅队列（1）测量单请求延迟
  • 与延迟存在权衡：越深越可能排队，延迟上升

查看：

1

fio --name=qd --filename=/dev/nvme0n1 --direct=1 --rw=randread --bs=4k --iodepth=128 --runtime=60
微信公众号
作者
微信公众号

相关内容