Block Storage und Performance

Kurze Zusammenfassung

Blockspeicher gibt rohe Geräte (LUN/Volume), auf denen Sie FS, LVM/ZFS usw. aufbauen. Die Performance wird bestimmt durch: Medientyp, Zugriffsprotokoll, Warteschlangen und Tiefe, Blockgröße, Codierungsschema (RAID/EC), Caches und Barrieren, Netzwerk-Fabric sowie anwendungsspezifisches I/O-Muster (Random/Sequential, Read/Write, Sync/Async). Das Ziel ist es, die gewünschte p95/p99 Latenz und IOPS/Durchsatz mit Stabilität und Vorhersehbarkeit bereitzustellen.

Blockzugriffstaxonomie

Lokal: NVMe (PCIe), SAS/SATA SSD/HDD. Minimale Latenz, keine Netzwerkengpässe.

Netzwerk:

iSCSI (Ethernet, LUN, MPIO, ALUA).
Fibre Channel (FC) (16-64G, geringe Latenz, Zoning).
NVMe-oF: NVMe/TCP, NVMe/RoCE, NVMe/FC - „native“ NVMe über das Netzwerk, weniger Lieferscheine.
HCI/Distributed (Ceph RBD, vSAN): komfortable Skalierbarkeit, aber höhere Latenz, Netzwerk/Codierung kritisch.

Auswahl (Signale):

p99 Latenz ≤ 1-2 ms, sehr hoher IOPS → lokaler NVMe/NVMe-oF.
Stabile „mittlere“ Latenz von 2-5 ms, ausgereifte Fabrik → FC oder NVMe/FC.
Vereinheitlichung auf Ethernet, einfacher Betrieb → iSCSI oder NVMe/TCP.

Protokolle und ihre Merkmale

iSCSI: Vielseitigkeit, MPIO/ALUA, empfindlich auf TCP-Konfiguration (MTU, Offload, qdepth).
FC: Isolation, verlustfreie Streams, WWPN-Zoning, HBA-Warteschlangen und Credits.
NVMe-oF: Parallelität über viele Submission/Completion Queues, geringe CPU-Last, TLS möglich für NVMe/TCP (bei Bedarf).

RAID/EC und Medien

RAID10 - minimale Latenz und vorhersehbare IOPS; optimal für DB/Wallets.
RAID5/6 - bessere Kapazität, Schreibstrafe (Schreibpenalty), IOPS für Sync-Schreiben fällt.
Erasure Coding in verteilten Arrays - vorteilhaft für die Kapazität, aber der Eintrag ist „teurer“.
NVMe SSD - p99 top; SAS SSD - ein Kompromiss; HDD ist eine konsistente Bandbreite, aber ein schlechter Rand.

Dateisysteme und Ausrichtung

XFS ist eine ausgezeichnete Wahl für große DB-Dateien/Protokolle; konfigurierbar 'agcount', 'realtime' für Protokolle.
ext4 - vielseitig, aufmerksam auf 'stride/stripe _ width' unter RAID.
ZFS - CoW, Integritätsprüfung, Snapshots/Replika, ARC/ZIL/SLOG; für Sync-Lasten - SLOG auf NVMe mit PLP.
Ausrichtung: 1MiB-aligned Abschnitte, korrekte' recordsize '/' blocksize' unter Last.

Warteschlangen, Tiefe und Blockgröße

IOPS wachsen mit der Queue Depth, aber auch die Latenz nimmt zu; Ziel ist eine QD, die den gewünschten IOPS liefert, wenn p95/p99 überwacht wird.
Blockgröße: klein (4-16K) - mehr IOPS, schlechtere Bandbreite; groß (128K-1M) - bessere Durchgangsgeschwindigkeit.
NVMe qpairs: nach Kernel/NUMA zuweisen; iSCSI/FC: qdepth NVA/Initiatoren, MPIO-Richtlinien.
Barrieren und FUA: Eingeschlossene Write-Barrier erhöhen die Zuverlässigkeit, erhöhen aber p99; SLOG/PLP wird kompensiert.

Multipath und Verfügbarkeit

MPIO/DM-Multipath: Pfadaggregation, Fehlertoleranz.

Politiker: 'round-robin' (Bilanz), 'queue-length' (klüger), 'failover' (Aktiva-Passiva).
ALUA: „bevorzugte“ Pfade zum aktiven Controller.
Wichtig: 'no _ path _ retry', 'queue _ if _ no _ path' - vorsichtig, um I/O nicht für lange Minuten „einzufrieren“.
FC-Zoning: „eine Initiatorzone - ein Ziel“ (reduces blast radius).
NVMe-oF: ANA (Asymmetric Namespace Access) — аналог ALUA.

TRIM/Discard und Caching

TRIM/Discard geben SSD-Blöcke frei (reduziert Write-Amp, stabilisiert Latenz). Schalten Sie regelmäßig (cron) oder Online-Discard ein, wo es zulässig ist.
Read-ahead ist nützlich für aufeinanderfolgende Lesungen; schädlich im Random.
Write-Back Controller Caches - nur mit BBU/PLP; ansonsten das Risiko von Datenverlust.

Netzwerk-Stack (für iSCSI/NVMe-TCP)

Separate VLANs/VRFs für die Storaj Factory; Isolation vom Kundenverkehr.
MTU 9000 end-to-end; RSS/RPS und IRQ Pinning zu NUMA.
QoS/Priorität für RoCE (wenn lossless), ECN/RED für TCP-Peaks.
Zwei unabhängige Fet-Bäume bis zum Torax (Doppel-TOR, verschiedene Stromzuführungen).

Linux/Host-Tuning (Auswahl)

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 (Fragment von '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
}
}

Benchmarking und Profiling

fio - Mindestprofilsatz:

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

Tipps:

Aufwärmen und Messen trennen, Temperatur/Thermaltreiben fixieren.
Testen Sie auf LUN/Volume, nicht auf FS (wenn das Ziel „rohe“ Hardware ist).
Messen Sie p95/p99 Latenz und 99. 9% tail - sie sind es, die die DB „töten“.

Überwachung und SLO

Metriken:

Latenz p50/p95/p99 (read/write), IOPS, throughput, queue-depth, device busy%, merges, discard.
Auf Netzwerkebene: Drops, Retransmits, ECN-Markierungen, Schnittstellenfehler.
Auf Array-Ebene: Replikations-Lag, Rebuild/Resilver-Fortschritt, Write-Amp, Wear-Level-SSD.

SLO (Beispiele):

LUN БД (OLTP): p99 write ≤ 1. 5 ms, p99 lesen ≤ 1. 0 ms, Verfügbarkeit ≥ 99. 95%.
Protokolle/Logs: p95 append ≤ 2. 5 ms, Durchsatz ≥ 400 MB/s pro Volume.
Backups: seq write ≥ 1 GB/s (aggregiert), RTO Recovery ≤ 15 min.

Alerts:

p99 Latenz> N-Minuten-Schwelle, IOPS-Degradation bei gleicher QD, Read-Modify-Write-Wachstum im RAID5/6, Überhitzung/Thermal-Throttle-SSD, begonnene/festgefahrene Rebilds.

Kubernetes и CSI

PVC/StorageClass: Parameter 'reclaimPolicy', 'volumeBindingMode = WaitForFirstConsumer' (korrekte Platzierung), 'allowVolumeExpansion'.
Vendor CSI Plugins: Snapshots/Clones, QoS/Performance Policies, volume-topology.
AccessModes: RWO für DB/State, RWX - vorsichtig (meist über Datei/Netzwerk).
Topologie/Affinität: Pin Pods zu den Knoten neben dem Torax (niedrige Latenz).
Wichtig: HPA/VPA „heilt“ eine schlechte Festplatte nicht; Planen Sie SLO-Volumes, verwenden Sie PodDisruptionBudget für stateful-Netzwerke.

Schnappschüsse, Klone, Konsistency Groups

Crash-konsistente Snapshots - schnell, aber DB-Inkonsistenzen sind möglich.
App-konsistent - über Quiesce-Skripte (fsfreeze, pre/post hooks DB).
Consistency Group (CG) - gleichzeitig für mehrere LUNs (Transaktionssysteme).
Klone sind schnelle dev/test Umgebungen ohne Kopieren.

Sicherheit und Compliance

iSCSI CHAP/Mutual CHAP, VLAN/VRF-Isolation.
NVMe/TCP mit TLS - für interzentrische/Multi-Array-Szenarien.
Verschlüsselung „in Ruhe“: LUKS/dm-crypt, selbstverschlüsselnde Treiber (TCG Opal), Schlüssel im KMS.
Audit: Wer ist Muppil LUN, FC Zonenwechsel, multipath Änderungen.

DR und Operationen

Synchrone Replikation (RPO≈0) - erhöht die Latenz, kurze Entfernungen.
Asynchron (RPO = N min) - Georasting, für die meisten DBs mit Logs akzeptabel.
Runbooks: MPIO-Pfad-Verlust, Controller-Verlust, Festplatten-Rebuild, Pool-Degradation, Standortwechsel.
Wartungsfenster: „Rolling“ Controller, Rebild Grenzen, um nicht zu essen prod.

FinOps (Kosten pro Leistung)

$/IOPS und $/ms p99 sind für OLTP nützlicher als „$/TB“.
Tiering: heißes OLTP - NVMe/RAID10; Berichte/Archiv - HDD/EC.
Reserven und Abschreibungen: Planen Sie ein Wachstum von 30-50% IOPS; Halten Sie den Bestand unter Rebilds/Peelings.
Egress/Factory: separates Budget für das Storaj-Netzwerk und HBA/NIC-Upgrades.

Checkliste für die Implementierung

Protokoll (NVMe-oF/FC/iSCSI) und isolierte Fabrik ausgewählt.
RAID/EC und Pools nach Lastart (OLTP/Log/Backup) ausgelegt.
MPIO/ALUA/ANA und Timeouts konfiguriert; failover/restore überprüft.
FS/Ausrichtung unter RAID, TRIM/Discard per Reglement aktiviert.
Queue Tuning/qdepth/read-ahead; validiert durch fio-Profile (randread/write 4k, seq 1M).
Disk/path/latency monitoring p95/p99, Rebild- und Throttle-Alerts.
Schnappschüsse (app-consistent) und CG; DR/Wiederherstellungstest.
Verschlüsselung und CHAP/TLS; Schlüssel im KMS; Prüfung der Vorgänge.
Kubernetes/CSI-Parameter, Topologie und QoS auf Volumes.

Typische Fehler

Ein Weg ohne MPIO → Single Point of Failure.
RAID5/6 unter sync-write OLTP → hoch p99 write.
Kein TRIM → Write-Amp-Wachstum und SSD-Degradation.
QD ist zu groß → „schöne“ IOPS und ein schreckliches Tail für die DB.
Online-Discard auf „heißen“ Volumes mit OLTP → Latenzsprünge.
„queue _ if _ no _ path“ ohne Timeout → „eingefrorene“ Dienste bei einem Unfall.
Das Mischen von NVMe und HDD in einem Pool → eine unvorhersehbare Latenz.

Spezifität für iGaming/Fintech

Wallet/Transaction DB: NVMe + RAID10, synchrones Protokoll auf separatem SLOG/NVMe, p99 write ≤ 1. 5 ms, CG-Schnappschüsse.
Die Reihen der Auszahlungen/antifrod: die konsequenten Hohlwege → die großen Blöcke, hoch durchlass-, abgesonderte LUN unter die Zeitschrift und die Daten.
Spitzen-TPS (Turniere/Matches): Pre-Warm-DB-Caches, Headroom ≥ 30%, Thermal Throttle Control, Burn-Rate SLO.
Regulierung: LUN-Verschlüsselung, Mupping-Audit-Protokoll, DR-Übungen, RPO/RTO-Reporting.

Summe

Produktiver Blockspeicher ist das richtige Protokoll + korrekt konfigurierte Warteschlangen und qdepth + angemessenes RAID/EC + Cache-/Barriere-Disziplin + isolierte Fabrik. Sichern Sie alles in Runbooks, messen Sie p95/p99, validieren Sie Fio-Profile, automatisieren Sie Snapshots und DRs - und erhalten Sie die vorhersehbare Latenz und IOPS, die Sie für kritische Produkt- und Cashflow-Pfade benötigen.