NVMe e SSD SATA per VPS a confronto: prestazioni, carichi di lavoro e costi

Due piani possono indicare lo stesso numero di vCPU e la stessa memoria, eppure uno completa la migrazione di un database in pochi minuti mentre l'altro resta bloccato per un'ora. La differenza sta di solito nel percorso di storage: dischi NVMe collegati via PCIe oppure SSD SATA o SAS dietro un controller tradizionale.

Questa guida spiega che cosa distingue davvero le due soluzioni, quali carichi di lavoro traggono vantaggio da NVMe e quali no, come misurare personalmente un server con fio prima di impegnarsi e perché franchigie di traffico e località rientrano nella stessa decisione.

Che cosa cambia davvero: interfaccia, protocollo e code

La differenza dipende da come l'unità comunica con la CPU. Gli SSD SATA usano il protocollo AHCI, progettato per i dischi rotativi, su un collegamento che arriva al massimo a 6 Gbps, il che in pratica significa circa 550 MB/s di throughput sequenziale. SAS porta il collegamento a 12 Gbps e aggiunge funzionalità enterprise come il dual porting, ma passa comunque attraverso un host bus adapter o un controller RAID.

I dischi NVMe si collegano direttamente alle linee PCIe. La differenza più importante per i server riguarda le code: AHCI offre una sola coda di comandi con 32 voci, mentre NVMe consente fino a 64K code con fino a 64K comandi ciascuna.

Su un VPS il sistema guest non vede direttamente il disco fisico. Una buona configurazione dell'host preserva gran parte del vantaggio di NVMe. Una configurazione scadente, un overcommit eccessivo o limiti di I/O aggressivi possono annullarlo.

IOPS, latenza e profondità di coda spiegate per chi acquista

Tre numeri descrivono le prestazioni dello storage, e sono collegati tra loro. Gli IOPS sono il numero di operazioni di lettura o scrittura completate al secondo, di solito misurate con piccoli blocchi da 4 KB. La latenza è il tempo impiegato da una singola operazione. La profondità di coda è il numero di operazioni in sospeso nello stesso momento.

Questi valori sono legati da una regola semplice: gli IOPS sono all'incirca la profondità di coda divisa per la latenza. Un disco che risponde in 100 microsecondi con profondità di coda 1 offre circa 10.000 IOPS. I valori di IOPS dichiarati sono quasi sempre misurati con profondità di coda elevate, che favoriscono i dischi in condizioni che molte applicazioni non creano mai.

Un database transazionale che esegue il commit di una transazione alla volta, attendendo ogni fsync, lavora con una profondità di coda vicina a 1. In questo caso la latenza conta più degli IOPS di picco. NVMe riduce tipicamente la latenza del dispositivo rispetto a SATA, e il percorso software più breve elimina ulteriore overhead, quindi il miglioramento si vede anche quando l'applicazione non invia molte richieste in parallelo.

La latenza di coda merita la massima attenzione. Quando confronti i server, guarda la latenza di completamento al 99° e al 99,9° percentile.

Carichi di lavoro che traggono vantaggio da NVMe

NVMe ripaga quando l'applicazione è limitata dalla latenza dello storage o da molte piccole operazioni concorrenti. I casi più evidenti sono:

• Database relazionali. PostgreSQL, MySQL e motori simili scrivono su un log a ogni commit e leggono pagine casuali quando il working set supera la memoria. Una latenza di scrittura più bassa aumenta il tasso di commit, e letture casuali più rapide accorciano le query che non trovano i dati nel buffer cache.
• Indici di ricerca e di analytics. Elasticsearch, OpenSearch e motori simili uniscono segmenti, aggiornano gli indici e leggono molti file piccoli. NVMe accorcia i tempi di indicizzazione e mantiene stabile la latenza delle query durante i merge.
• Server di build e CI. La compilazione di codebase di grandi dimensioni, la risoluzione delle dipendenze e l'esecuzione delle suite di test generano migliaia di piccole letture e scritture di file. Build che sulla carta sono limitate dalla CPU spesso risultano in attesa dello storage.
• Key-value store con persistenza. I sistemi che scrivono su disco snapshot o log append-only traggono vantaggio da flush rapidi, che riducono la pausa percepita dagli utenti durante la persistenza.
• Host di container e di virtualizzazione. Il pull delle immagini, l'avvio di molti container e l'esecuzione di diversi servizi intensivi su una sola macchina moltiplicano la concorrenza di I/O, ed è proprio lì che le code di NVMe aiutano.
• Job di elaborazione dei dati. Le fasi ETL che ordinano, riversano su disco o rimescolano file intermedi terminano più rapidamente quando lo storage temporaneo è NVMe.

Carichi di lavoro per cui un SSD SATA o SAS è sufficiente

Molti carichi di lavoro vedono poca o nessuna differenza, perché lo storage non è il loro collo di bottiglia.

• Siti web con caching efficace. Un sito di contenuti servito per lo più dalla memoria, da una page cache o da una CDN legge pochissimo dal disco dopo il warm-up.
• Server applicativi stateless. I livelli API e web che tengono i dati in un database separato impiegano il loro tempo su CPU e rete.
• Distribuzione ad alto consumo di banda. La distribuzione di file, gli origin di streaming e i mirror di download leggono file di grandi dimensioni in modo sequenziale. Un SSD SATA a circa 550 MB/s supera già ciò che una porta da 1 Gbps può trasportare (circa 125 MB/s).
• Destinazioni di backup e archivi. Le scritture sequenziali di oggetti di grandi dimensioni privilegiano la capacità per dollaro rispetto alla latenza.
• Piccoli database che stanno in memoria. Se l'intero working set risiede in RAM, le letture toccano raramente il disco, e tassi di commit moderati restano ampiamente entro i limiti SATA.
• Strumenti interni a basso traffico. Wiki, ticketing e dashboard di monitoraggio con poche decine di utenti raramente generano una pressione di I/O significativa.

Qui il budget rende spesso di più in capacità SSD SATA o SAS enterprise, memoria o banda a traffico illimitato.

Come misurare con fio prima di impegnarsi

fio è lo strumento open source standard per il benchmarking dello storage su Linux ed è disponibile nei repository dei pacchetti di tutte le principali distribuzioni. Eseguilo su un server di prova o appena predisposto, su un file di test nello stesso file system che userà la tua applicazione, mai su un dispositivo raw che contiene dati.

Inizia con un test di lettura casuale a concorrenza moderata, che approssima un database o un nodo di ricerca molto attivo: fio --name=randread --filename=/var/tmp/fiotest --size=4G --rw=randread --bs=4k --ioengine=libaio --direct=1 --iodepth=32 --numjobs=4 --runtime=60 --time_based --group_reporting.

Poi esegui un test che riproduce i commit di un database: fio --name=commit --filename=/var/tmp/fiotest --size=1G --rw=randwrite --bs=4k --ioengine=libaio --direct=1 --iodepth=1 --numjobs=1 --fsync=1 --runtime=60 --time_based.

Infine, eseguire un test sequenziale con --rw=read e --bs=1M per confermare il throughput per i backup e il lavoro su file di grandi dimensioni. Nella lettura dei risultati, registrare IOPS, banda e i percentili della latenza di completamento (clat) a p50, p99 e p99.9. Su un'infrastruttura condivisa, la costanza dei risultati tra un'esecuzione e l'altra conta quanto il valore di picco, perché mostra quanto bene l'host isola i vicini.

Eliminare poi il file di test ed evitare benchmark pesanti in produzione in orario lavorativo: rallentano il traffico reale.

Franchigie di traffico, porte a traffico illimitato e costo totale

Un piano è conveniente solo se le sue condizioni di traffico corrispondono alla quantità di dati che sposti realmente.

Una porta da 1 Gbps trasferisce circa 125 MB al secondo, circa 10,8 TB al giorno o circa 324 TB al mese a pieno carico. Una franchigia mensile di 3 TB corrisponde in media a soli 9 Mbps circa sostenuti, e 16 TB a circa 49 Mbps.

I piani a consumo con una franchigia di traffico sono adatti ai carichi di lavoro in cui la priorità è la prestazione dello storage e il traffico è moderato e prevedibile. Verifica che cosa accade quando si supera la franchigia: costo aggiuntivo per terabyte, riduzione a una velocità inferiore o upgrade forzato. I piani a traffico illimitato applicano un prezzo fisso per la porta e sono adatti ai carichi con egress elevato o imprevedibile. Verifica la velocità della porta, se è dedicata o condivisa, ed eventuali clausole di fair use.

Stimare il traffico mensile in uscita dai log attuali o dai dati di fatturazione del provider, aggiungere un margine per la crescita e per il traffico di backup in uscita dal server, e confrontare il costo mensile totale delle varie opzioni, eccedenze incluse. A volte l'architettura giusta suddivide il carico di lavoro: NVMe per il livello database con una quota di traffico modesta, e server SSD con traffico illimitato per il livello di distribuzione.

Scegliere la località di un VPS

La località incide su latenza, conformità e costi. Nella fibra ottica la luce percorre circa 200 km per millisecondo, quindi ogni 100 km di fibra aggiungono circa 1 ms di round trip time prima di qualsiasi overhead di instradamento. I percorsi reali sono più lunghi della linea retta, ed è per questo che un server in un altro continente aggiunge comunemente da 100 a 250 ms per round trip.

• Collocare i server vicino agli utenti. Misurare il round trip time dalle regioni da cui proviene la maggior parte del traffico, con ping, mtr o monitoraggio sintetico.
• Tenere vicini i componenti che comunicano molto. Un server applicativo e il suo database dovrebbero trovarsi nella stessa località. Uno storage NVMe veloce è sprecato se ogni query attraversa un oceano.
• Verificare la residenza dei dati. Normative e contratti con i clienti possono richiedere che i dati restino in un paese specifico. Verificare dove sono conservati il server, i suoi backup ed eventuali repliche.
• Prevedere il guasto di una regione. Una seconda località per i backup o per un warm standby protegge da un'interruzione in una struttura.
• Confrontare prezzi e condizioni di traffico per regione. La stessa configurazione può avere quote incluse e costi diversi in regioni diverse.

Tabella decisionale e checklist

Tabella decisionale: ogni riga associa un profilo di carico a un tipo di storage e a un modello di traffico.

• Database transazionale con working set più grande della memoria. Scegliere NVMe. Una quota di traffico misurata è di solito sufficiente, poiché il traffico del database resta per lo più interno.
• Cluster di ricerca o indice di analytics. Scegliere NVMe con memoria sufficiente per la cache del file system. Il fabbisogno di traffico è di solito moderato.
• Server di build o CI. Scegliere NVMe. Includere nella stima del traffico il download di dipendenze e artefatti.
• Sito web in cache o livello API stateless. Basta un SSD SATA o SAS. Scegliere il traffico illimitato se il traffico pubblico è elevato o soggetto a picchi.
• Distribuzione di file, origin di streaming o mirror. SSD ad alta capacità e una porta con traffico illimitato. NVMe aggiunge poco, perché è la rete a limitare il throughput.
• Destinazione di backup o archivio. Prima di tutto la capacità. SSD o block storage di rete, dimensionati sulla retention, con condizioni di traffico che coprano il traffico di ripristino.
• Carico di lavoro misto su una sola macchina. Scegliere NVMe per il livello dati, oppure separare i livelli su più server, così che ciascuno abbia il modello di storage e di traffico di cui ha bisogno.

Prima di firmare, verificare questa checklist:

• Usa il monitoraggio attuale per trovare il limite: latenza, throughput, CPU o rete.
• Esegui test fio di lettura casuale, fsync e sequenziali; registra la latenza p99 e p99.9.
• Ripeti i test in orari diversi per verificare gli host condivisi.
• Stimare il traffico mensile in uscita dai log più la crescita e confrontarlo con la quota inclusa o la velocità della porta.
• Ottenere per iscritto le condizioni su eccedenze, limitazioni della banda o fair use.
• Misura il round trip time dalle regioni chiave verso ogni sede.
• Verificare il paese di dati, backup e repliche.
• Verificare hypervisor, interfaccia disco e limiti di I/O pubblicati per piano.
• Pianifica i backup verso una seconda località e testa un ripristino.

Come può aiutare Vonahost

La linea VPS NVMe funziona su KVM con fino a 8 vCPU, 32 GB di memoria e 500 GB di NVMe, con da 3 a 16 TB di traffico mensile, nella regione che scegliete. La linea VPS SSD utilizza SSD enterprise con fino a 12 core, 64 GB di memoria e 800 GB di storage, traffico illimitato e Linux o Windows, nella regione che scegliete. Per i workload che superano le capacità di un VPS, i server dedicati single-tenant offrono NVMe locale (2 x 960 GB) con una porta dedicata da 1 Gbps a traffico illimitato.

Ogni proposta indica configurazione, località, responsabilità e prezzo mensile in dollari statunitensi, e il paese di ciascun server è scelto dal cliente.