IOPS indica la quantità di operazioni che vengono eseguite nell’intervallo di tempo di un secondo (input /output operations per second). Di fatto, IOPS è una misurazione delle prestazioni usata per descrivere i dispositivi di archiviazione, siano essi HDD, SSD o anche reti SAN. Lo storage Provisioned IOPS, di cui parliamo in questo articolo, è un tipo di storage caratterizzato da prestazioni prevedibili e latenza bassa costante.
Ciò premesso, entriamo nei meandri della realizzazione di un sistema di storage alla ricerca delle risposte più comuni alla domanda ricorrente: come fornire IOPS indipendentemente dalla capacità?
Capacità, througput e IOPS: tre parametri difficili da conciliare
La progettazione del sistema di storage ha sempre comportato un compromesso fra tre parametri: capacità, throughput e IOPS. Sfortunatamente – il pensiero va agli ingegneri di sistema – le limitazioni fisiche dei componenti di archiviazione non consentono di impostarli in modo indipendente, almeno non nell’hardware. La dipendenza parametrica obbliga i progettisti a scegliere tra capacità e prestazioni.
I workoload che richiedono un elevato throughput di I/O per piccoli set di dati evidenziano l’enigma IOPS VS Capacity. Per esempio, un commento sul portale Azure Feedback illustra il problema dell’impossibilità di eseguire il provisioning delle prestazioni indipendentemente dalla capacità per i managed disk di Azure.
Il software defined storage (SDS) può disaccoppiare questi parametri, inserendo un livello di astrazione logica tra le risorse di storage e i componenti. Inoltre, un piano di controllo software centralizzato consente ai servizi di cloud storage di suddividere in modo granulare la capacità distribuendo volumi di blocchi logici e condivisioni di file tra nodi e unità di archiviazione.
Anche se i sistemi di storage distribuito iperscalabili sono ottimizzabili in modo indipendente, come vediamo in questo articolo, va detto che solo pochi servizi consentono un compromesso accettabile tra capacità e prestazioni, probabilmente a causa dell’alto costo di fornitura e della scarsa domanda.
Origini del problema e prime soluzioni
Il collegamento tra IOPS e capacità dei sistemi è legato alle limitazioni meccaniche dei piatti magnetici e delle testine degli hard disk, due problemi che hanno ristretto la capacità di aumentare IOPS a quattro possibili interventi:
- Velocità di rotazione maggiore
- Supporti magnetici ad alta densità
- Diverse testine di lettura-scrittura
- Cache RAM più grandi
Sebbene gli SSD eliminino i vincoli meccanici su throughput e I/O, essi presentano altre limitazioni, tra cui:
- La velocità delle operazioni di lettura e scrittura della cella di archiviazione.
- Grandi blocchi di memoria nella memoria flash NAND, che causano amplificazione in scritturae latenza di accesso.
- Throughput controllato dalla velocità dell’unità microcontroller incorporata e dai buffer di memoria, dalle interfacce NAND I/O e SATA.
Questi ostacoli pongono un limite al throughput SSD e IOPS, in particolare per le scritture casuali, che possono avere dieci volte la latenza delle scritture sequenziali. Il metodo tradizionale per alimentare workload con IOPS elevati consiste nel distribuire i volumi di archiviazione su tutti i dispositivi necessari in un RAID e nell’aggiungere cache RAM più grandi come buffer I/O. Ma attenzione: la prima tattica si traduce in capacità inutilizzata, la seconda invece aggiunge un costo significativo.
SDS per eseguire il provisioning di IOPS in modo indipendente
Il primo prodotto in grado di disconnettere la capacità di storage dal throughput è arrivato da SolidFire, un’azienda acquisita da NetApp nel 2015. SolidFire ha aperto la strada a una funzionalità di quality of service (QoS) che impone livelli minimi, massimi e burst per throughput e IOPS. La differenza sta nell’aver allocato prestazioni e capacità in modo indipendente per ciascun volume in un sistema. Nel suo sistema scale-out, ogni nodo 1U faceva parte di un controller distribuito connesso tramite una rete back-end dedicata ad alta velocità. Questo software potrebbe suddividere in modo trasparente la capacità su tutti i nodi necessari per soddisfare la QoS.
Sebbene i cloud provider siano notoriamente riservati sull’hardware fisico e sul software di provisioning e gestione alla base dei loro servizi, oggi adottano l’approccio di SolidFire di array scale-out con controller distribuiti su scala rack e pod. I provider, in genere, distribuiscono centinaia di server di archiviazione identici che vengono aggregati in pool di risorse per servizi di archiviazione di diverse categorie, come blocchi, file e oggetti, e livelli di prestazioni. Ad esempio, Amazon Elastic Block Store (EBS) è disponibile in più varietà, tra cui SSD per uso generico, denominati gp2 e gp3, e SSD IOPS con provisioning, denominati io1 e io2.
In genere, i prodotti di cloud storage offrono livelli IOPS con limiti di capacità diversi, sia minimi che massimi. Al contrario, le istanze gp3 sono insolite in quanto consentono agli utenti di aumentare in modo indipendente il throughput e gli IOPS senza dover fornire più capacità di storage a blocchi. Le istanze gp2 e gp3 forniscono soft cap sulle prestazioni IOPS e, secondo Amazon, forniscono entro il 10% delle prestazioni IOPS previste il 99% delle volte in un determinato anno. Inoltre, i volumi gp2 inferiori a 1.000 GB hanno prestazioni di burst fino a 3.000 IOPS per almeno 30 minuti, mentre i volumi gp3 forniscono un minimo di 3.000 IOPS senza capacità di burst. Al contrario, i volumi IOPS io1 e io2 assegnati, secondo Amazon, forniscono entro il 10% delle prestazioni IOPS assegnati il 99,9% delle volte in un anno, con una latenza inferiore a 10 ms. Se abbinati a istanze Elastic Compute Cloud r5 basate su AMD, i volumi io2 possono fornire fino a 260.000 IOPS per volumi fino a 4 GB.
Diversi provider concorrenti di AWS offrono una flessibilità simile per fornire IOPS indipendentemente dalla capacità. Tra i prodotti disponibili ci sono:
- Azure Ultra Disks, disponibili in diverse dimensioni fisse da 4 gibibyte (GiB) a 64 tebibyte. Qui gli utenti possono impostare limiti fino a 300 IOPS per GiB, con un massimo di 160.000 IOPS per disco. Pertanto, un volume da 32 GiB può essere configurato da 100 a 9.600 IOPS.
- IBM Cloud IOPS, che supportano la regolazione dinamica e senza interruzioni della capacità IOPS entro i limiti dei suoi due livelli di servizio. Gli Endurancesupportano impostazioni IOPS superiori a 0,25 IOPS per GB, mentre i Performance, o IOPS allocati, supportano valori compresi tra 100 e 48.000 IOPS.
Al contrario, la maggior parte dei cloud service scala linearmente le prestazioni IOPS con le dimensioni del volume. Ad esempio, i Google Cloud Platform (GCP) Persistent Disks forniscono 30 IOPS di lettura e scrittura per gigabyte fino a un massimo di 60.000 IOPS di lettura, a seconda del numero di vCPU collegate, della dimensione del blocco e di altri parametri. Allo stesso modo, Oracle Cloud Infrastructure (OCI) Block Higher Performance Volumes fornisce 75 IOPS per gigabyte (4.000 blocchi) fino a 35.000 IOPS per volume. Pertanto, se un’applicazione richiede solo un volume di 128 GB, gli SSD GCP possono fornire 3.840 IOPS; OCI Higher Performance può fornire 9.600 IOPS, mentre Amazon EBS io2 può essere configurato fino a 64.000 IOPS.
Scegliere un servizio
La maggior parte dei servizi di cloud storage e dei fornitori di array scala IOPS con la capacità perché i limiti tecnici della tecnologia di unità e controller richiedono la scalabilità orizzontale dei dispositivi per fornire più throughput e capacità IOPS. Tuttavia, per alcune applicazioni, i requisiti del working set e della velocità effettiva di I/O non vengono scalati linearmente.
Ad esempio, come sottolinea anche AWS nel suo blog sui volumi EBS gp3, alcune app, come MySQL e Hadoop, richiedono prestazioni elevate ma capacità di archiviazione non elevate. Allo stesso modo, le applicazioni basate su microservizi, che potrebbero avere piccoli working set con molte transazioni in uno storage pool condiviso, possono essere accelerate riducendo la latenza di storage e aumentando le operazioni di I/O al secondo. In questi casi, un servizio cloud come EBS io2 o gp3 o un prodotto di archiviazione come NetApp SolidFire, che non associa IOPS più veloci a volumi di dimensioni maggiori, offrirà prestazioni migliori in rapporto all’investimento.
