Block Storage e prestazioni

Breve riepilogo

Lo storage a blocchi fornisce dispositivi crudi (LUN/volume) sopra i quali si costruiscono FS, LVM/ZFS, ecc. Le prestazioni sono definite dal tipo di supporto, dal protocollo di accesso, dalle code e dalla profondità, dalle dimensioni del blocco, dallo schema di codifica (RAID/CE), dalla cache e dalle barriere, dalla struttura di rete e dal pattern I/O di un'applicazione specifica (rand/serie, lettura/scrittura, sync/async). L'obiettivo è quello di fornire i giusti p95/p99 di ritardo e IOPS/banda larga con stabilità e prevedibilità.

Tassonomia di accesso a blocchi

Locale: NVMe (PCIe), SAS/SATA SSD/HDD. Latitanza minima, mancanza di colli di rete.

Rete:

iSCSI (Ethernet, LUN, MPIO, ALUA).
Fibre Channel (FC) (16-64G, ritardi bassi, zonning).
NVMe-oF: NVMe/TCP, NVMe/RoCE, NVMe/FC - NVME nativo sulla rete, meno firme.
HCI/distribuiti (Ceph RBD, vSAN): scalabilità facile, ma latenza superiore, rete/codifica critica.

Selezione (segnali):

p99 latency, 1-2 mc, IOPS molto alto, locale.
Una latitanza media stabile di 2-5 ms, una fabbrica matura di → FC o NVMe/FC.
Unificazione su Ethernet, più facile da usare con o NVMe/TCP.

Protocolli e caratteristiche

iSCSI: versatilità, MPIO/ALUA, sensibile alla configurazione TCP (MTU, offload, qdepth).
FC: isolamento, flussi senza perdita, zoning WWPN, code HBA e prestiti.
NVMe-oF - Parallelità con molti Submision/Complection Queues, basso carico CPU, TLS è possibile per NVMe/TCP (se necessario).

RAID/CE e supporti

RAID10 - Minimo latitanza e prevedibile IOPS; ideale per il database/portafogli.
RAID5/6 - meglio in capacità, multa di scrittura (write penalty), cade IOPS per sync-write.
Erasure Coding in array distribuiti è vantaggioso in termini di capacità, ma la scrittura è più costosa.
NVMe SSD - p99 top; SAS SSD - compromesso; L'HDD è un range sequenziale, ma cattivo.

File system e allineamento

XFS è una scelta eccellente per grandi file/registri database; personalizzabile «agcount», «realtime» per i loghi.
ext4 è universale, attento a «stride/stripe _ width» sotto RAID.
ZFS - CoW, controllo di integrità, snapshot/replica, ARC/ZIL/SLOG; per i carichi sync - SLOG su NVMe con PLP.
Allineamento: partizioni 1MiB-aligned, corrette «recordsize »/« blocksize» sotto carico.

Code, profondità e dimensioni del blocco

IOPS cresce con Queue Depth, ma cresce anche la latitanza; l'obiettivo è un QD che fornisce l'IOPS desiderato al controllo p95/p99.
Dimensioni blocco: piccole (4-16K) - più grande IOPS, peggio larghezza di banda; grandi (128K-1M): velocità più veloce.
NVMe qpairs: seleziona i core/NUMA; iSCSI/FC: qdepth NVA/iniziatori, criteri MPIO.
Barriere e FUA: i write-barriers inclusi migliorano l'affidabilità, ma aumentano il p99; SLOG/PLP sono compensati.

Multipath e disponibilità

MPIO/DM-Multiplath: aggregazione dei percorsi, tolleranza di errore.

Criteri: «round-robin» (equilibrio), «queue-length» (più intelligente), «failover» (attivo passivo).
ALUA: percorsi preferiti per il controller attivo.
L'importante è: 'no _ path _ retry', 'queue _ if _ no _ path', per non «congelare» I/O per lunghi minuti.
Zoning FC: «Una zona di iniziazione - un target» (reduces blast radius).
NVMe-oF: ANA (Asymmetric Namespace Access) — аналог ALUA.

TRIM/Discard e cache

TRIM/Discard liberano i blocchi SSD (riduce il write-amp, stabilizza la latitanza). Abilitare regolarmente (cron) o discard online dove è consentito.
Read-ahead è utile per le letture consecutive È dannoso per il random.
Write-back cache controller - solo con BBU/PLP; altrimenti il rischio di perdita di dati.

Stack di rete (per iSCSI/NVMe-TCP)

VLAN/VRF separati per la fabbrica di storming; isolamento dal traffico client.
MTU 9000 end-to-end; RSS/RPS e pinning IRQ al NUMERO.
QoS/priority per i RoCE (se lossless), ECN/RED per i picchi TCP.
Due alberi di fat indipendenti fino allo stormo (TOR doppi, fider di alimentazione diversi).

Tuning Linux/host (campionamento)

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 (frammento "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 e profilassi

fio - Set minimo di profili:

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

Suggerimenti:

Separa il riscaldamento e la misura, fissa la temperatura/termal throttling.
Testare su LUN/volume anziché su FS (se l'obiettivo è ferro crudo).
Misurate p95/p99 latency e 99. Il 9% di tail è «uccidono» il database.

Monitoraggio e SLO

Metriche:

Latenza p50/p95/p99 (read/write), iOPS, throughput, queue-depth, device busy%, muges, discard.
A livello di rete: drops, retransmits, etichettature ECN, errori di interfaccia.
A livello di array: blade di replica, rebuild/resilver progressi, write-amp, wear-level SSD.

SLO (esempi):

LUN БД (OLTP): p99 write ≤ 1. 5 mc, p99 read 1. 0 mc, ≥ 99. 95%.
Logi/registri: p95 append 2. 5 ms, ≥ da 400 MB su un volume.
Backup: seq write da 1 GB/s (aggregato), RTO di ripristino da 15 minuti

Alert:

p99 latency> soglia N minuti, degrado IOPS con lo stesso QD, crescita read-modify-write in RAID5/6, surriscaldamento/termal throtle SSD, rebild iniziati/bloccati.

Kubernetes и CSI

PVC/StorageClass: reclaimPolicy, volumeBindingMode=WaitForFirstConsumer, allowVolumeExpansion.
Plugin CSI venditori: snapshot/cloni, QoS/criteri di prestazioni, volume-topology.
AccessModes: ROVO per database/state, RANDX - attenzione (solitamente tramite file/rete).
Topology/Affinity: pin a nodi accanto allo stereo (bassa latitanza).
Importante: HPA/VPA non «curerà» il disco cattivo; pianificare i volumi SLO, utilizzare il PodDisruptionBudget per le reti stateful.

Snapshot, cloni, Consistency Groups

Crash-consistent snapshot - Veloce, ma possibile incoerenza del database.
App-consistent - attraverso gli script quiesce (fsfreeze, pre/post hooks database).
Consistency Group (CG) - Contemporaneamente per più LUN (sistemi transazionali).
I cloni sono un ambiente uv/test veloce senza copia.

Protezione e compliance

CHAP/Mutual CHAP, isolamento VLAN/VRF.
NVMe/TCP con TLS - per script interattive/multi-arending.
Crittografia a riposo: LUKS/dm-crypt, self-encrypting drives (TCG Opal), chiavi in KMS.
Controllo: chi è il lettore LUN, cambia le zone FC, modifica multipath.

DR e operazioni

Replica sincrona (RPO≈0) - Aumenta la latitudine e le distanze brevi.
Asincrona (RPO = N min) è una georasistenza accettabile per la maggior parte dei database con registri.
Runbooks: perdita del percorso MPIO, perdita del controller, rebuild del disco, degrado del pool, cambio del sito.
Le finestre di servizio sono i controller «rolling», i limiti del rebyld, per non mangiare il prone.

FinOps (costo per prestazioni)

$/IOPS e $/mc p99 sono più utili di $/TB per OLTP.
Tiering: OLTP caldo - NVMe/RAID10; reperti/archivio - HDD/CE.
Riserve e ammortamento: pianificare una crescita del 30-50% IOPS; Tieni la scorta sotto i rebeld/scrub.
Egress/fabbrica: budget separato per la rete di stage e aggiornamenti HBA/NIC.

Assegno foglio di implementazione

È stato selezionato un protocollo (NVMe-oF/FC/iSCSI) e una fabbrica isolata.
Progettati RAID/CE e pool per tipo di carico (OLTP/logg/bacap).
Configurati MPIO/ALUA/ANA e timeout; failover/restore verificati.
FS/allineamento RAID abilitato da TRIM/Discard per regolamento.
Tuning code/qdepth/read-ahead; convalidato da profili fio (randread/write 4k, seq 1M).
Monitoraggio dei dischi/percorsi/latitanza p95/p99, alert per i reboot e throttle.
Snapshot (app-consistent) e CG; Test DR/ripristino.
Crittografia e CHAP/TLS; chiavi di KMS Controllo delle operazioni.
Kubernets/CSI parametri, topologia e QoS per i volumi.

Errori tipici

Un percorso senza MPIO-single point of failure.
RAID5/6 sotto sync-write OLTP alto p99 write.
Nessun TRIM per crescita write-amp e degrado SSD.
Il QD è troppo grande per «belli» IOPS e un terribile tail per il database.
Discard online su volumi «hot» con OLTP per i picchi di latitanza.
«queue _ if _ no _ path» senza timeout per i servizi «dipendenti» in caso di incidente.
La miscelazione tra NVMe e HDD in un unico pool è una latitanza imprevedibile.

Specifico per iGaming/Fintech

Portafoglio/database transazioni: NVME + RAID10, registro sincronizzato su SLOG/NVMe separato, p99 write ≤ 1. 5 mc, CG-snashot.
Code di pagamento/antifrode: seriali, grandi blocchi, larghezza di banda, singoli LUN di registro e dati.
TPS di punta (tornei/partite): pre-warm cache BD, headroom 30%, controllo termal throttle, burn-rate SLO.
Regolazione: crittografia LUN, controllo dei mupping, esercitazioni DR, report RPO/RTO.

Totale

Lo storage a blocchi produttivi è il protocollo corretto + code corrette e qdepth + RAID/CE adeguato + disciplina cache/barriere + fabbrica isolata. Fissare tutto in runbook-s, misurare p95/p99, convalidare i profili fio, automatizzare snap e DR - e ottenere la prevedibile latitanza e iOPS necessari per i percorsi critici del prodotto e il flusso di cassa.