Block Storage et performances

Résumé succinct

Le stockage par blocs fournit les périphériques bruts (LUN/volume) sur lesquels vous construisez FS, LVM/ZFS, etc. Les performances sont déterminées par le type de support, le protocole d'accès, les files d'attente et la profondeur, la taille du bloc, le schéma de codage (RAID/EC), les caches et les barrières, l'usine réseau, ainsi que le modèle I/O de l'application spécifique (rand/série, lecture/écriture, sync/async). L'objectif est de fournir les retards p95/p99 nécessaires et IOPS/pass avec stabilité et prévisibilité.

Taxonomie de l'accès par blocs

Local : NVMe (PCIe), SAS/SATA SSD/HDD. Latence minimale, aucun goulot d'étranglement réseau.

Réseau :

iSCSI (Ethernet, LUN, MPIO, ALUA).
Fibre Channel (FC) (16-64G, faibles retards, parapluie).
NVMe-oF : NVMe/TCP, NVMe/RoCE, NVMe/FC - « native » NVMe sur le réseau, moins de lettres de voiture.
HCI/distribué (Ceph RBD, vSAN) : évolutivité pratique, mais latence plus élevée, réseau/codage critique.

Sélection (s) :

p99 latitude ≤ 1-2 ms, IOPS très haut → NVMe/NVMe-oF local.
Latence stable « moyenne » 2-5 ms, usine mature → FC ou NVMe/FC.
Unification sur Ethernet, exploitation plus facile des → iSCSI ou NVMe/TCP.

Protocoles et leurs caractéristiques

iSCSI : polyvalence, MPIO/ALUA, sensible à la configuration TCP (MTU, offload, qdepth).
FC : isolation, flux sans perte, zonage WWPN, files d'attente HBA et crédits.
NVMe-oF : parallèle à travers plusieurs queues de sous-mission/complétion, faible charge CPU, TLS possible pour NVMe/TCP (si nécessaire).

RAID/EC et supports

RAID10 - latence minimale et IOPS prévisibles ; Optimal pour les bases de données/portefeuilles.
RAID5/6 - mieux en capacité, pénalité d'écriture (write penalty), baisse IOPS pour sync-write.
Erasure Coding dans les baies distribuées - bénéfique en termes de capacité, mais l'enregistrement est « plus cher ».
NVMe SSD - p99 top ; SAS SSD - compromis ; HDD est une bande passante séquentielle, mais une mauvaise rand.

Systèmes de fichiers et alignement

XFS est un excellent choix pour les grands fichiers/journaux OBD ; personnalisable 'agcount', 'realtime' pour les logs.
ext4 - polyvalent, attentif à 'stride/stripe _ width' sous RAID.
ZFS - CoW, vérification de l'intégrité, snapshots/répliques, ARC/ZIL/SLOG ; pour les charges sync - SLOG sur NVMe avec PLP.
Alignement : 1MiB-aligned les sections, correct 'recordsize '/' blocksize' sous la charge.

Files d'attente, profondeur et taille du bloc

L'IOPS croît avec Queue Depth, mais la latence augmente également ; la cible est le QD qui donne le bon IOPS lors du contrôle de p95/p99.
Taille du bloc : petit (4-16K) - plus IOPS, pire passe ; grande (128K-1M) - meilleure vitesse de passage.
NVMe qpairs : isoler par noyau/NUMA ; iSCSI/FC : qdepth NVA/initiateurs, stratégies MPIO.
Barrières et FUA : inclus write-barriers améliorent la fiabilité, mais augmentent p99 ; SLOG/PLP sont compensés.

Multipath et disponibilité

MPIO/DM-Multipath : agrégation de chemins, tolérance aux pannes.

Politiques : 'round-robin' (bilan), 'queue-length' (plus intelligent), 'failover' (actif-passiva).
ALUA : chemins « préférés » vers le contrôleur actif.
Important : 'no _ path _ retry', 'queue _ if _ no _ path' - soigneusement pour ne pas « geler » I/O pendant de longues minutes.
Zonage FC : « une zone initiatrice est un seul ciblage » (reduces blast radius).
NVMe-oF: ANA (Asymmetric Namespace Access) — аналог ALUA.

TRIM/Discard et cache

TRIM/Discard libère les blocs SSD (réduit l'amplitude d'écriture, stabilise la latence). Incluez régulièrement (cron) ou une discard en ligne là où c'est permis.
Read-ahead est utile pour des lectures successives ; nocif dans le random.
Cache Write-back du contrôleur - uniquement avec BBU/PLP ; sinon, le risque de perte de données.

Pile réseau (pour iSCSI/NVMe-TCP)

VLAN/VRF distincts pour l'usine de scorage ; l'isolement du trafic client.
MTU 9000 end-to-end; RSS/RPS et pinning IRQ à NUMA.
QoS/priority pour RoCE (si lossless), ECN/RED pour les pics TCP.
Deux arbres fat indépendants jusqu'au storage (double TOR, alimentation électrique différente).

Tuning Linux/hôte (échantillon)

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 '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 et profilage

fio est un ensemble minimal de profils :

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

Conseils :

Séparer le réchauffage et la mesure, fixer la température/thermal throttling.
Testez sur LUN/volume, pas sur FS (si la cible est du fer « brut »).
Mesurez p95/p99 latitude et 99. 9 % sont eux qui « tuent » les OBD.

Surveillance et SLO

Métriques :

Latence p50/p95/p99 (read/write), IOPS, throughput, queue-depth, device busy %, merges, discard.
Au niveau du réseau : drops, retransmits, marquage ECN, erreurs d'interface.
Au niveau de la baie : réplication, rebuild/resilver progress, write-amp, wear-level SSD.

SLO (exemples) :

LUN БД (OLTP): p99 write ≤ 1. 5 ms, p99 lire ≤ 1. 0 ms, disponibilité ≥ 99. 95%.
Logs/logs : p95 append ≤ 2. 5 ms, passe ≥ 400 MB/s par volume.
Backaps : seq write ≥ 1 Go/s (agrégé), RTO de restauration ≤ 15 min.

Alert :

p99 latitude> seuil N minutes, dégradation IOPS sous le même QD, croissance read-modify-write en RAID5/6, surchauffe/thermal thermottle SSD, début/coincement des rebilles.

Kubernetes и CSI

PVC/StorageClass : options 'reclaimPolicy', 'volumeBindingMode = WaitForFirstConsumer', 'allowVolumeExpansion'.
Plugins CSI vendeurs : snapshots/clones, QoS/politiques de performance, volume-topologie.
AccessModes : RWO pour la base de données/state, RWX - prudent (généralement via les fichiers/réseau).
Topology/Affinity : pin des pods vers les nodules près du storage (faible latence).
Important : HPA/VPA ne « guérira » pas le mauvais disque ; Planifiez les volumes SLO, utilisez PodDissolutionBudget pour les réseaux stateful.

Snapshots, clones, groupes de cohérence

Crash-consistent snapshots - rapide, mais des incohérences OBD sont possibles.
App-consistent - via les scripts quiesce (fsfreeze, pre/post hooks DB).
Consistency Group (CG) - simultanément pour plusieurs LUN (systèmes transactionnels).
Clones - un environnement rapide dev/test sans copie.

Sécurité et conformité

iSCSI BOU/Mutual BOU, isolation VLAN/VRF.
NVMe/TCP avec TLS - pour les scénarios inter-centres/multi-sites.
Cryptage « au repos » : LUKS/dm-crypt, self-encrypting drives (TCG Opal), clés dans KMS.
Audit : qui a mappé les LUN, changement des zones FC, changement multipath.

DR et opérations

Réplique synchrone (RPO≈0) - augmente la latence, courtes distances.
Asynchrone (RPO = N min) est une géographie, acceptable pour la plupart des OBD avec des journaux.
Runbooks : perte du chemin MPIO, perte du contrôleur, rebuild du disque, dégradation du pool, changement de site.
Fenêtres de service : « rolling » des contrôleurs, limites de rebield pour ne pas manger de prod.

FinOps (coût par performance)

$/IOPS et $/ms p99 sont plus utiles que « $/TB » pour OLTP.
Tiering : OLTP chaud - NVMe/RAID10 ; reports/archives - HDD/CE.
Réserves et amortissement : prévoir une croissance de 30 à 50 % du PEI ; gardez le stock sous les rebilds/gommages.
Egress/usine : budget séparé pour le réseau de scorage et les mises à jour HBA/NIC.

Chèque d'implémentation

Protocole sélectionné (NVMe-oF/FC/iSCSI) et usine isolée.
Conçu par RAID/EC et pools par type de charge (OLTP/log/backap).
Configurés MPIO/ALUA/ANA et Timaouts ; failover/restore vérifié.
FS/alignement sous RAID, TRIM/Discard activé par règlement.
Tuning des files d'attente/qdepth/read-ahead ; validé par des profils fio (randread/write 4k, seq 1M).
Surveillance des disques/voies/latence p95/p99, alertes sur les rebilles et throttle.
Snapshots (app-consistent) et CG ; test DR/récupération.
Cryptage et BOU/TLS ; les clés dans le KMS ; audit des opérations.
Kubernetes/CSI paramètres, topologie et QoS sur les volumes.

Erreurs typiques

Un chemin sans MPIO → point unique de failure.
RAID5/6 sous sync-write OLTP → haut p99 write.
Pas de TRIM → croissance write-amp et dégradation du SSD.
QD est trop grand → « beau » IOPS et horrible tail pour la base de données.
Discard en ligne sur les volumes « chauds » avec OLTP → sauts de latence.
'queue _ if _ no _ path' sans délai → les services « dépendants » en cas d'accident.
Le mélange de NVMe et de HDD dans un seul pool → une latence imprévisible.

Spécificité pour iGaming/fintech

Portefeuille/bases de données transactionnelles : NVMe + RAID10, journal synchrone sur SLOG/NVMe, p99 write ≤ 1. 5 ms, CG-snapshots.
Files d'attente de paiement/antifrod : logs successifs → gros blocs, haut débit, LUN séparés pour le journal et les données.
De pique TPS (les tournois/matches) : pre-warm des caches du BD, headroom ≥ 30 %, le contrôle thermal throttle, burn-rate SLO.
Réglementation : cryptage des LUN, journal d'audit des muppings, exercices de RD, rapports sur les RPO/RTO.

Résultat

Le stockage par blocs productif est le protocole correct + files d'attente correctement configurées et qdepth + RAID/EC + discipline de cache/barrières + usine isolée. Fixez tout dans le runbook, mesurez le p95/p99, validez les profils fio, automatisez les snapshots et les DR - et obtenez la latence prévisible et l'IOPS dont vous avez besoin pour vos parcours de produits et vos flux de trésorerie critiques.