IOPS
SAS 12G SSD enterprise: 100-200k IOPS
SATA SSD enterprise: 80-100k IOPS
NVMe Gen4 enterprise: 1M-1.6M IOPS · 10× il SAS
NVMe enterprise sostituisce SAS/SATA con un protocollo nativo PCIe: IOPS dieci-cento volte superiori, latenza in singole cifre di microsecondi invece di millisecondi. Ma non basta comprare dischi NVMe — servono backplane compatibile, slot PCIe Gen4/5 liberi, alimentazione ridondante per drive ad alto wattaggio, supporto hot-swap su U.2/U.3.
SAS 12G SSD enterprise: 100-200k IOPS
SATA SSD enterprise: 80-100k IOPS
NVMe Gen4 enterprise: 1M-1.6M IOPS · 10× il SAS
SAS/SATA enterprise SSD: 100-300 µs
NVMe enterprise: 10-30 µs · 10× più basso
NVMe-oF su rete: 30-100 µs (ok per scenari distributed)
SAS 12G: 1.2 GB/s per disco
SATA 6G: 550 MB/s per disco
NVMe Gen4 x4: 7 GB/s per disco
NVMe Gen5 x4: 14 GB/s (in arrivo)
Backplane "SAS/SATA only" non accetta NVMe. Servono backplane tri-mode (SAS/SATA/NVMe). PowerEdge R750 con back-zone configurabile NVMe; HPE DL380 Gen11 NVMe-ready; Lenovo SR650 V2 con backplane NVMe-ready. Su modelli più vecchi (R740 prima releases) il backplane va sostituito.
Ogni NVMe U.2/U.3 occupa 4 lane PCIe. Su sistema 2-socket Xeon Scalable Gen3 ci sono tipicamente 64 lane CPU + chipset: ogni NVMe slot costa 4 lane. Verifichiamo lane budget includendo eventuali NIC 25G/100G, GPU, controller storage tri-mode.
NVMe enterprise wattaggio: U.2 da 7-15 W in attività, picchi maggiori. 24× U.2 fanno 240-360W solo per i dischi. Su sistemi con PSU al limite l'aggiunta di NVMe scala oltre il budget: serve passare a PSU di taglio superiore.
NVMe enterprise sotto carico generano calore non banale. Sistemi con airflow standard reggono; sistemi a densità alta (1U dense) richiedono ventole performance e thermal management aggiornato. Cuocere le NVMe accelera il wear-out e attiva il throttling termico.
U.2 (2.5") classico, U.3 retrocompatibile + tri-mode, M.2 boot/cache solo (non hot-swap), EDSFF E1.S/E3 emergenti per data center density. Server enterprise standard è U.2/U.3 enterprise per storage, M.2 per boot.
Sistemi operativi moderni supportano NVMe nativamente (Linux kernel 3.13+, Windows Server 2012 R2+). Su sistemi più vecchi (Windows Server 2008, RHEL 6) servono driver vendor. VMware ESXi 6.5+ supporta nativamente NVMe.
Verifica modello, backplane esistente, lane PCIe libere, slot AIC liberi, PSU budget, raffreddamento esistente. Identifichiamo se la migrazione è plug-in o richiede upgrade backplane.
Read-intensive, mixed-use o write-intensive in base al workload. Capacità per drive coerente con la classe scelta e il budget di lane. Vendor: Samsung PM9A3/PM9B1, Kioxia CD8 / CM7, Micron 7450/9400, Solidigm D7-PS1010, Western Digital DC SN840.
Sostituzione backplane SAS-only con tri-mode dove necessario. Installazione tri-mode controller se RAID hardware richiesto. Cablaggio SAS aggiornato (SlimSAS, MCIO).
Installazione fisica NVMe in bay. Configurazione storage: RAID hardware via tri-mode, oppure passthrough HBA per SDS, oppure mdadm/Storage Spaces se software. Driver e firmware aggiornati.
Benchmark fio per workload tipico, verifica temperature drive sotto carico, validazione hot-swap se richiesta, baseline performance scritta. Migrazione dati dal precedente storage in finestra concordata.
Cliente datacenter Lombardia, applicazione SaaS multi-tenant su PostgreSQL 15 con 8 TB dataset attivo. PowerEdge R750xs con 8× SAS 12G 10K 2.4 TB in RAID 10, controller PERC H755. Latenza query OLTP nel range 8-30 ms, batch reporting che richiedeva 4-6 ore di notte saturando lo storage.
Soluzione: R750xs è già NVMe-ready in front bay. Sostituito il pool storage con 6× Samsung PM9A3 U.2 NVMe 3.84 TB Mixed-Use in RAID 10 software via mdadm (no controller tri-mode, per ottenere massima velocità NVMe). PERC H755 mantenuto come HBA passthrough.
Migrazione: setup parallelo del nuovo storage, pg_basebackup verso il nuovo pool, swap durante finestra notturna di manutenzione. Database online sul nuovo storage in 90 minuti di downtime totale (incluso vacuum/analyze post-switch).
Risultato: latenza query OLTP 95-percentile da 30 ms a 4 ms. Batch notturno da 4-6 ore a 50 minuti. IOPS storage da 18k peak a 380k peak. ROI calcolato in 8 mesi rispetto al costo di scaling-out su un nodo aggiuntivo.
Dipende dal modello. Server con backplane SAS/SATA standard non accetta NVMe a meno di sostituire backplane con versione tri-mode. Server già predisposti (Dell PowerEdge R750 con tri-mode backplane, HPE ProLiant DL380 Gen11 con NVMe-ready bays, Lenovo SR650 V2) accettano direttamente. Verifichiamo il modello esatto e ti rispondo con la fattibilità.
No. NVMe diretto su PCIe Gen4 x4 fa 7 GB/s e 1M IOPS; NVMe via tri-mode con cache è limitato dal controller (1-2 GB/s tipicamente, qualche centinaia di k IOPS). Ma il tri-mode dà RAID hardware, cache protetta, una console di gestione unificata: per workload mid-market che vogliono protezione facile è ottimo trade-off.
Sì sulle U.2 e U.3 enterprise (Dell, HPE, Lenovo): è una feature nativa del protocollo. Su consumer NVMe (M.2) no — M.2 non è progettato per hot-swap. Le SSD enterprise U.3 più moderne supportano hot-add senza fermo del sistema, con riconoscimento da parte del sistema operativo (su Linux automatico, su Windows talvolta serve rescan).
Per workload IOPS-bound (database, virtualizzazione) la differenza è marginale: Gen4 satura già la maggior parte dei workload. Per throughput puro (analytics, ML training, file server di grandi dataset) Gen5 fa la differenza, raddoppiando il throughput sequenziale. CPU che supportano Gen5 sono Xeon Sapphire Rapids+, EPYC Genoa+.
Sì, ed è anzi il pattern moderno per ottenere il massimo dei NVMe: software-defined storage espone gli IOPS NVMe in modo molto più efficiente del controller RAID hardware. ZFS su NVMe è eccellente per workload database. Windows Storage Spaces Direct e VMware vSAN sono progettati esattamente per NVMe + SDS.
Le SSD enterprise NVMe sono classificate per workload: Read-Intensive (1 DWPD), Mixed-Use (3 DWPD), Write-Intensive (10 DWPD). Per database OLTP intensivi conviene Mixed-Use. Read-Intensive va bene per VM repository, file server. Write-Intensive solo per log shippers / metadata pesanti. Sbagliare classe può causare wear-out in 1-2 anni invece di 5+.
Inviami brand, modello (Service Tag / Serial / part number motherboard), workload obiettivo. Entro un giorno lavorativo ti rispondo con la fattibilità tecnica, i vincoli che ho visto e una stima onesta.