塊存儲和性能

簡短摘要

塊存儲提供了原始設備（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。