块存储和性能

简短摘要

块存储提供了原始设备（LUN/卷），您可以在其上构建FS，LVM/ZFS等。性能由媒体类型，访问协议，队列和深度，块大小，编码方案（RAID/EC），缓存和屏障，网络工厂以及特定应用程序的I/O模式（运行/串行，读取/写入，sync/async）定义。目标是确保所需的p95/p99延迟和IOPS/带宽具有稳定性和可预测性。

块访问分类法

本地：NVMe（PCIe），SAS/SATA SSD/HDD。最小潜伏期，没有网络瓶颈。

网络：

iSCSI (Ethernet, LUN, MPIO, ALUA).
光纤通道（FC）（16-64G、低延迟、分区）。
NVMe-oF：NVMe/@@TCP，NVMe/@@RoCE，NVMe/@@FC是网络上的"本地"NVMe，其开销较少。
HCI/分布式（Ceph RBD, vSAN）：可扩展性方便,但潜伏度更高,关键在于网络/编码。

选择（信号）：

p99 latency ≤ 1-2毫秒，非常高的IOPS →本地NVMe/NVMe-oF。
稳定的"中等"潜伏期2-5毫秒,成熟的工厂→ FC或NVMe/FC。
以太网统一，更容易使用iSCSI或NVMe/TCP →。

协议及其功能

iSCSI：多功能性,MPIO/ALUA,对TCP设置敏感（MTU, offload, qdepth）。
FC：隔离、无损流、WWPN分区、HBA队列和信用。
NVMe-oF：通过Submission/Completion Queues的多个并行性,低的CPU负载,TLS可用于NVMe/TCP（如果需要）。

RAID/EC和介质

RAID10-最小潜伏期和可预测的IOPS；最适合DB/钱包。
RAID5/6-容量更好，写入处罚（写入penalty），同时写入IOPS。
分布式阵列中的Erasure Coding在容量上是有益的，但是记录"更昂贵"。
NVMe SSD-p99顶级；SAS SSD-折衷方案；HDD是串行带宽，但运行不佳。

文件系统和对齐

XFS是大型DB文件/日志的绝佳选择。可自定义的"agcount"，"realtime"用于登录。
ext4是通用的，密切关注RAID下的"stride/stripe_width"。
ZFS-CoW，完整性检查，狙击/复制，ARC/ZIL/SLOG；对于同步负载-带有PLP的NVMe上的SLOG。
对齐：1MiB-aligned部分,在负载下正确的"记录大小"/"blocksize"。

队列、深度和块大小

IOPS随着Queue Depth的增长而增长，但潜伏期也在增长。目标是QD，在控制p95/p99时提供所需的IOPS。
块大小：小（4-16K）-IOPS更大，带宽更差；较大（128K-1M）-较好的直通速度。
NVMe qpairs：在内核/NUMA上突出显示；iSCSI/FC： qdepth NVA/启动器, MPIO策略。
障碍物和FUA：包含的写障碍物提高了可靠性，但增加了p99；SLOG/PLP可补偿。

多重性和可用性

MPIO/DM-Multipath：路径聚合，容错。

政策："round-robin"（资产负债表），"queue-length"（更聪明），"failover"（资产负债表）。
ALUA：通往活动控制器的"首选"路径。
重要的是："no_path_retry"，"queue_if_no_path"-整齐地避免将I/O"冻结"很长时间。
FC分区："一个启动器区域是一个目标"（reduces blast radius）。

NVMe-oF: ANA (Asymmetric Namespace Access) — аналог ALUA.

TRIM/Discard和缓存

TRIM/Discard释放SSD单元（降低write-amp，稳定潜伏期）。在允许的情况下定期启用（cron）或在线光盘。
阅读耳机对于连续阅读很有用；randome有害。
写回控制器缓存-仅带有BBU/PLP；否则，数据丢失的风险。

网络堆栈（适用于iSCSI/NVMe-TCP）

单独的VLAN/VRF用于storage工厂；与客户流量隔离。
MTU 9000 end-to-end;RSS/RPS和将IRQ固定到NUMA。
QoS/priority用于RoCE（如果失效），ECN/RED用于TCP峰。
两棵独立的fat树直到storage（双TOR，不同的电源馈线）。

Linux/主机调音（样本）

bash
Scheduler for NVMe echo none     sudo tee /sys/block/nvme0n1/queue/scheduler echo 1024      sudo tee /sys/block/nvme0n1/queue/nr_requests echo 0        sudo tee /sys/block/nvme0n1/queue/add_random echo 0        sudo tee /sys/block/nvme0n1/queue/iostats

Read-ahead (sequential loads)
blockdev --setra 4096 /dev/nvme0n1

iSCSI: example of aggressive timeouts and retries iscsiadm -m node --op update -n node. session. timeo. replacement_timeout -v 10 iscsiadm -m node --op update -n node. conn[0].timeo. noop_out_interval -v 5 iscsiadm -m node --op update -n node. conn[0].timeo. noop_out_timeout -v 5

Multipath（multipath片段。conf`):

conf defaults {
find_multipaths yes polling_interval 5 no_path_retry 12
}
devices {
device {
vendor "PURE    DELL    NETAPP    HITACHI"
path_checker tur features "1 queue_if_no_path"
path_grouping_policy group_by_prio prio alua
}
}

基准和分析

fio-最小配置文件集：

bash
Random read 4K, queue 32, 4 threads fio --name = randread --filename =/dev/nvme0n1 --direct = 1 --rw = randread\
--bs=4k --iodepth=32 --numjobs=4 --time_based --runtime=60

Random 4K entry (sync), log loads fio --name = randwrite --rw = randwrite --bs = 4k --iodepth = 16 --numjobs = 4\
--fsync=1 --direct=1 --runtime=60

Large block sequential recording (backups/dumps)
fio --name=seqwrite --rw=write --bs=1M --iodepth=64 --numjobs=2 --runtime=60

提示：

分开加热和测量,固定温度/热热热。
在LUN/卷而不是 FS上进行测试（如果目标是"生"铁）。
计数p95/p99 latency和99。9％的尾巴是他们"杀死"DB。

监控和SLO

度量标准：

潜伏期p50/p95/p99 （read/write）, IOPS, throughput, queue-depth, device busy%, merges, discard。
在网络级别：drops, retransmits, ECN标记,接口错误。
在阵列级别：复制时差,rebuild/resilver进度,write-amp, wear-level SSD。

SLO（示例）：

LUN БД (OLTP): p99 write ≤ 1.5 ms, p99 read ≤ 1.0毫秒，可用性≥ 99。95%.
Logi/Journal： p95 append ≤ 2.5毫秒，每卷≥ 400 MB/s的带宽。
备份：seq write ≥ 1 GB/s（聚合），RTO恢复≤ 15分钟。

Alerts：

p99 latency>阈值N分钟,IOPS降解在相同的QD, read-modify-write生长在RAID5/6,过热/热热SSD,开始/卡住肋骨。

Kubernetes и CSI

PVC/StorageClass：参数"reclaimPolicy"、"volumeBindingMode=WaitForFirstConsumer"（正确放置）、"allowVolumeExpansion"。
Vendor CSI插件：狙击/克隆，QoS/性能策略，volume-topology。
AccessModes：用于DB/State的RWO, RWX-小心（通常通过文件/网络）。

Topology/Affinity： pin pod to nodes near storaja（低潜伏期）.

重要：HPA/VPA不会"治愈"坏盘；计划卷的SLO，使用PodDisruptionBudget进行静态网络。

Snapshots、克隆、一致性组

Crash-consistent snapshots-很快，但DB不一致是可能的。
App-consistent-通过quiesce脚本（fsfreeze, pre/post hooks DB）。
Consistency Group （CG）-同时针对多个LUN（事务系统）。
克隆-不复制的快速dev/测试环境。

安全性和合规性

iSCSI CHAP/Mutual CHAP, VLAN/VRF隔离。
带有TLS的NVMe/TCP-用于中间/多帧脚本。
静止加密：LUKS/dm-crypt，自加密驱动器（TCG蛋白石），KMS中的密钥。
审计：谁绘制了LUN，更改了FC区域，更改了multipath。

DR和操作

同步副本（RPO≈0）-增加潜伏期，短距离。
异步（RPO=N min）是大多数具有日志的DB都可以接受的地质站。
Runbooks： MPIO路径丢失、控制器丢失、磁盘重整、池降级、站点切换。
服务窗口："滚动"控制器，重新填充限值，以免吃碎屑。

FinOps（性能成本）

$/IOPS和$/ms p99-对于OLTP更有用"$/TB"。
Tiering：热OLTP-NVMe/RAID10；报告/存档-HDD/EC。
储备金和摊销：计划增加30-50%的IOPS；把库存放在肋骨/灌木丛下。
Egress/Factory：单独的Storaj网络预算和HBA/NIC更新。

实施支票

选择了协议（NVMe-oF/FC/iSCSI）和绝缘工厂。
由RAID/EC和按负载类型（OLTP/log/back）设计的池。
已设置MPIO/ALUA/ANA和定时器；failover/restore验证。
RAID下的FS/对齐,按规定启用TRIM/Discard。
排队调音/qdepth/read-ahead；由fio配置文件（randread/write 4k，seq 1M）验证。
监控磁盘/路径/潜伏期p95/p99、差速器到rebilds和throttle。
Snapshots（app-consistent）和CG；DR/恢复测试。
加密和CHAP/TLS；KMS中的密钥；操作审核。
每个卷的Kubernetes/CSI参数，拓扑和QoS。

典型错误

一个没有MPIO →单点失败的路径。
RAID5/6在sync-write OLTP下→高p99 write。
没有TRIM → write-amp生长和SSD降解。
QD太大→"美丽"IOPS和DB的可怕尾巴。
在带有OLTP的"热门"卷上在线张贴卡→潜伏期跳跃。
"queue_if_no_path"不在事故发生时→"挂起"服务。
在一个池中溷合NVMe和HDD →不可预测的潜伏期。

iGaming/fintech的细节

钱包/事务数据库：NVMe+RAID 10,单独的SLOG/NVMe上的同步日志,p99 write ≤ 1。5毫秒，CG狙击手。
支付队列/对数：串行日志→大块、高带宽、日志和数据下单独的LUN。
高峰TPS（比赛/比赛）：DB的预热缓存，头顶≥ 30％，热热热控制，burn-rate SLO。
调节：LUN加密、mapping审核日志、DR练习、RPO/RTO报告。

底线

生产块存储是正确的协议+正确配置的队列和qdepth+充分的RAID/EC+缓存/屏障+隔离工厂。将所有内容都固定在运行簿中,测量p95/p99、验证fio配置文件、自动化snapshots和DR-并获得关键产品和现金流路径所需的可预测潜伏期和IOPS。