Non c’è dubbio che Amazon sia il leader quando si tratta di una varietà di servizi cloud offerti attraverso il servizio web EC2 (Elastic Compute Cloud). Con un processo di provisioning relativamente semplice e la capacità di scalare facilmente le istanze e le esigenze di storage verso l'alto o verso il basso, EC2 mira a mantenere tutte le promesse del cloud a prezzi vantaggiosi. Per alcuni, tuttavia, il cloud non è solo questione di flessibilità e facilità di implementazione; è una questione di prestazioni. I vantaggi aziendali derivanti dalla possibilità di attivare o disattivare ambienti potenti per applicazioni critiche come l'analisi possono spesso superare di gran lunga la spesa derivante da tale operazione tramite OPEX anziché l'investimento a lungo termine di CAPEX. A tal fine, a maggio Amazon GA ha lanciato la famiglia di istanze bare metal i3 che fornisce accesso diretto alle risorse di CPU e memoria del server sottostante.
Non c’è dubbio che Amazon sia il leader quando si tratta di una varietà di servizi cloud offerti attraverso il servizio web EC2 (Elastic Compute Cloud). Con un processo di provisioning relativamente semplice e la capacità di scalare facilmente le istanze e le esigenze di storage verso l'alto o verso il basso, EC2 mira a mantenere tutte le promesse del cloud a prezzi vantaggiosi. Per alcuni, tuttavia, il cloud non è solo questione di flessibilità e facilità di implementazione; è una questione di prestazioni. I vantaggi aziendali derivanti dalla possibilità di attivare o disattivare ambienti potenti per applicazioni critiche come l'analisi possono spesso superare di gran lunga la spesa derivante da tale operazione tramite OPEX invece dell'investimento a lungo termine di CAPEX. A tal fine, a maggio Amazon GA ha lanciato la famiglia di istanze bare metal i3 che fornisce accesso diretto alle risorse di CPU e memoria del server sottostante.
Le istanze i3.metal sono basate sul sistema Nitro, che è una raccolta di componenti di protezione del server e di offload hardware realizzati da AWS che "forniscono in modo sicuro risorse di rete e di archiviazione ad alte prestazioni alle istanze EC2". Le istanze i3.metal sfruttano anche tutti gli altri servizi offerti da AWS Cloud come Elastic Block Store (EBS), che abbiamo sfruttato come parte di questa recensione. Le istanze offrono inoltre fino a 15.2 TB di spazio di archiviazione supportato da SSD NVMe, nonché processori Intel Xeon da 2.3 GHz che offrono 36 core con hyper-threading (72 processori logici) e 512 GiB di memoria. Dal punto di vista del fabric, le istanze i3.metal forniscono fino a 25 Gbps di larghezza di banda di rete aggregata, garantendo un throughput di rete elevato e una latenza inferiore tramite la rete avanzata basata su Elastic Network Adapter (ENA).
All'interno di EC2 esistono diversi tipi di istanze. Le istanze i3 rientrano nella categoria "Storage Optimized", con le istanze i3.metal che assumono il ruolo di quelle con le prestazioni più elevate di quel gruppo. La tabella seguente evidenzia la famiglia e la configurazione dei tipi di istanza.
| Modello | CPU virtuale | Memoria (GiB) | Prestazioni di rete | Spazio di archiviazione (TB) |
| i3.grande | 2 | 15.25 | Fino a 10 Gigabit | 1 SSD NVMe da 0.475 |
| i3.xlarge | 4 | 30.5 | Fino a 10 Gigabit | 1 SSD NVMe da 0.95 |
| i3.2xgrande | 8 | 61 | Fino a 10 Gigabit | 1 SSD NVMe da 1.9 |
| i3.4xgrande | 16 | 122 | Fino a 10 Gigabit | 2 SSD NVMe da 1.9 |
| i3.8xgrande | 32 | 244 | 10 Gigabit | 4 SSD NVMe da 1.9 |
| i3.16xgrande | 64 | 488 | 25 Gigabit | 8 SSD NVMe da 1.9 |
| i3.metal | 72 | 512 | 25 Gigabit | 8 SSD NVMe da 1.9 |
Le istanze i3.metal sono disponibili nelle regioni AWS Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (Oregon), Europa (Francoforte) ed Europa (Irlanda) e possono essere acquistate come istanze on demand, Istanze riservate (3 anni, 1 anno e convertibili) o come istanze Spot. Ai fini di questa recensione, abbiamo eseguito il test nella regione della Virginia del Nord. Abbiamo testato sia con lo storage NVMe che con i volumi a blocchi EBS.
Performance
Analisi del carico di lavoro VDBench
Per valutare le prestazioni dell'istanza EC2 i3.metal, abbiamo sfruttato VDBench installato localmente per testare sia lo storage EBS (30x1 TB) che NVMe (8×1.7 TB). Con entrambi i tipi di archiviazione, abbiamo allocato il 12% di ciascun dispositivo e li abbiamo raggruppati in modo aggregato per osservare le massime prestazioni del sistema con una quantità moderata di località dei dati.
Questi carichi di lavoro offrono una gamma di profili di test diversi che vanno dai test "quattro angoli", test comuni sulle dimensioni di trasferimento del database, nonché acquisizioni di tracce da diversi ambienti VDI. Tutti questi test sfruttano il comune generatore di carichi di lavoro vdBench, con un motore di scripting per automatizzare e acquisire risultati su un ampio cluster di test di calcolo. Ciò ci consente di ripetere gli stessi carichi di lavoro su un'ampia gamma di dispositivi di storage, inclusi array flash e singoli dispositivi di storage.
Profili:
- Lettura casuale 4K: lettura al 100%, 128 thread, 0-120% irate
- Scrittura casuale 4K: scrittura al 100%, 64 thread, 0-120% irate
- Lettura sequenziale 64K: lettura al 100%, 16 thread, 0-120% irate
- Scrittura sequenziale a 64K: scrittura al 100%, 8 thread, 0-120% irate
- Database sintetici: SQL e Oracle
- Tracce di clonazione collegate a VDI
In questa recensione esamineremo sia EBS che NVMe. Poiché c'è una notevole differenza di prestazioni, abbiamo separato i risultati in due grafici (la latenza sarebbe così distante che i grafici sarebbero molto difficili da leggere).
Il nostro primo test esamina la lettura casuale 4K. In questo caso l'istanza EBS ha registrato prestazioni con latenza inferiore al millisecondo fino alla fine. Proprio a circa 64 IOPS la latenza è aumentata a 59.46 ms con prestazioni di 64,047 IOPS.
Osservando la lettura casuale di picco NVMe 4K, vediamo che l'istanza funziona molto meglio. L'istanza ha raggiunto il picco di 2,802,904 IOPS con una latenza di 348μs.
La scrittura casuale 4K con EBS ha prodotto quasi la stessa cosa delle letture 4K con EBS. L'istanza si è interrotta 1 ms un po' prima, circa 60 IOPS, e ha raggiunto il picco a 64,003 IOPS con una latenza di 29.97 ms.
Per la versione NVMe dell'istanza, si è verificato un leggero picco di latenza, ma comunque inferiore a 1 ms. L'istanza ha raggiunto il picco di 920,975 IOPS con una latenza di 545μs.
Passando ai test sequenziali, per le prestazioni di picco in lettura di EBS 64K, l'istanza ha avuto una latenza inferiore al millisecondo fino a circa 70 IOPS o circa 450 MB/s e ha raggiunto il picco a 17,360 IOPS o 1.08 GB/s con una latenza di 27.65 ms.
La lettura sequenziale da 64K con NVMe ci ha fornito prestazioni di picco di 244,037 IOPS o 15.25 GB/s con una latenza di 514 μs.
Con una scrittura da 64 KB con EBS, l'istanza è iniziata sopra 1 ms e ha raggiunto il picco di 17,359 IOPS o 1.08 GB/s con una latenza di 13.8 ms.
La scrittura sequenziale da 64K è la prima volta che vediamo l'istanza NVMe superare 1 ms. L'istanza ha raggiunto il picco di 58,572 IOPS o 3.66 GB/s con una latenza di 1.08 ms.
Passando ai nostri carichi di lavoro SQL, l'istanza EBS ha registrato prestazioni con latenza inferiore al millisecondo fino a circa 55 IOPS e ha raggiunto un picco di 64,036 IOPS con una latenza di 14.93 ms.
Per la versione NVMe dell'istanza, abbiamo riscontrato prestazioni di picco di 834,231 IOPS con una latenza di 302μs per il test SQL.
Per SQL 90-10 con EBS, l'istanza ha nuovamente superato la latenza di 1 ms intorno a 55 IOPS e ha raggiunto il picco di 64,036 IOPS con una latenza di 14.99 ms.
La versione NVMe dell'istanza in SQL 90-10 ha avuto una prestazione di picco di 605,150 IOPS e una latenza di 415μs.
L'SQL 80-20 con EBS ha nuovamente fornito quasi gli stessi numeri con una latenza inferiore al millisecondo che termina intorno a 55 IOPS e un picco di 64,036 IOPS con una latenza di 14.93 ms.
L'SQL 80-20 con NVMe ha registrato numeri di istanza pari a 511,840 IOPS e una latenza di 493μs.
I test Oracle per EBS hanno mostrato le stesse strane prestazioni di picco con quasi gli stessi numeri. Per Oracle, l'istanza ha raggiunto 64,036 IOPS con una latenza di 13.6 ms. L'istanza ha avuto prestazioni di latenza inferiori al millisecondo fino a circa 55 IOPS.
Con NVMe, l'istanza ha raggiunto 457,372 IOPS con una latenza di 613μs nel test Oracle.
Oracle 90-10 ha registrato un picco dell'istanza EBS pari a 64,035 IOPS con una latenza di 10.3 ms. L'istanza ha interrotto 1 ms a circa 55 IOPS.
La versione NVMe dell'istanza in Oracle 90-10 è stata in grado di raggiungere 520,448 IOPS con una latenza di 333μs.
Oracle 80-20 ha registrato un intervallo EBS di 1 ms intorno a 55 IOPS e un picco di 64,036 IOPS con una latenza di 10.3 ms.
L'istanza con NVMe ha registrato prestazioni di picco di 435,265 IOPS con una latenza di 400μs.
Successivamente esamineremo i nostri test VDI Linked Clone (LC). A partire dall'avvio, la versione EBS dell'istanza ha avuto una latenza inferiore al millisecondo fino a circa 35 IOPS e ha raggiunto un picco di 42,893 IOPS con una latenza di 11.2 ms.
La versione NVMe dell'istanza è riuscita a raggiungere un picco di 349,799 IOPS e una latenza di 363μs nel nostro test di avvio VDI LC.
Per l'accesso iniziale VDI LC, l'istanza EBS è rimasta a cavallo della linea di 1 ms per un po' di tempo prima di scendere a circa 31 IOPS. L'istanza ha raggiunto il picco di 34,486 IOPS e 6.95 ms di latenza.
Con l'accesso iniziale VDI LC, l'istanza NVMe ha raggiunto il picco di 93,405 IOPS con una latenza di 677μs.
Con VDI LC Monday Login, ancora una volta l'istanza EBS ha flirtato con 1 ms per un po' prima di fare il grande passo intorno ai 25 IOPS e raggiungere il picco a 34,643 IOPS con una latenza di 13.85 ms.
Infine, il nostro accesso del lunedì VDI LC con NVMe ha registrato un picco di istanze pari a 119,615 IOPS con una latenza di 1.1 ms.
Conclusione
I servizi cloud di Amazon sono generalmente considerati i più versatili in circolazione. Sebbene il calcolo e l'archiviazione siano certamente vari, Amazon offre anche opzioni di prestazioni. Amazon offre una vasta gamma di opzioni prestazionali sul suo servizio web EC2, inclusa la sua istanza bare metal i3. Queste istanze sfruttano il sistema AWS Nitro di hardware e software appositamente realizzati. Le istanze i3.metal forniscono prestazioni migliori attraverso l'accesso diretto alle CPU e alla memoria, offrendo comunque agli utenti la possibilità di sfruttare altre funzionalità come lo spazio di archiviazione collegato AWS EBS e lo spazio di archiviazione NVMe locale.
Per quanto riguarda le prestazioni, abbiamo testato sia il block storage (EBS) che NVMe. Questo ha lo scopo di dare ai lettori un'idea di cosa aspettarsi in termini di opzioni e meno che uno sia migliore dell'altro (in genere l'archiviazione NVMe funziona meglio e ha una latenza molto più bassa, motivo per cui ci sono due serie di grafici). Osservando l'EBS, abbiamo notato un modello in cui l'istanza superava 1 ms e poi, poco dopo, aumentava la latenza e terminava. Durante i nostri test, l'EBS ha raggiunto il picco di circa 64 IOPS, che è il massimo consentito per l'EBS. Ciò includeva i test 4K e tutti e tre i test SQL e Oracle. L'istanza ha rallentato un po' durante i nostri test VDI. Amazon indica che è possibile modificare le impostazioni per ottenere più degli IOPS prescritti di 64K, ma i processi per arrivarci non sono quelli che la maggior parte dei clienti sperimenterebbe, quindi non abbiamo seguito questo percorso.
Per i nostri test NVMe, abbiamo riscontrato risultati più in linea con i nostri normali benchmark. I punti salienti includono prestazioni di lettura casuale 4K di 2.8 milioni di IOPS, scrittura 4K di 920 IOPS, lettura 64 di 15.25 GB/s e prestazioni SQL superiori a 500 IOPS in tutti e tre i test (con il test SQL di circa 834 IOPS). Anche i test Oracle hanno avuto ottimi risultati con NVMe, con risultati compresi tra 435 IOPS e 520 IOPS. Il nostro clone collegato VDI ha mostrato ottime prestazioni di avvio con circa 350 IOPS. L’unica delusione qui è che i clienti non possono optare per più NVMe locali nelle istanze i3.metal.
Nel complesso, l'istanza i3.metal ci ha dato esattamente ciò che Amazon aveva promesso. Ciò è rassicurante per i clienti che vogliono sapere che riceveranno il livello di servizio promesso. Questo, ovviamente, non è privo di costi, come per qualsiasi implementazione del cloud, la preoccupazione riguarderà la facilità d'uso e i risultati nel cloud rispetto ad altri fornitori di servizi cloud rispetto a quelli on-premise. Detto questo, i clienti con carichi di lavoro che possono accontentarsi di un livello IOPS inferiore possono risparmiare parecchio denaro. Tuttavia, tutto dipende da quali sono i requisiti finali per il caso specifico. A tal fine, le istanze i3.metal sono ottime per le applicazioni mainstream che non superano o non sono in grado di superare i limiti prestazionali offerti da i3.metal e non necessitano degli IOPS che un array all flash on-premise fornirebbe esempio. Inoltre, se fai già parte della famiglia Amazon, il passaggio al bare metal è familiare e probabilmente c'è un vantaggio in termini di costi consumando diversi programmi AWS in blocco.
Iscriviti alla newsletter di StorageReview
