Het lijdt weinig twijfel dat Amazon de leider is als het gaat om een verscheidenheid aan cloudservices die worden aangeboden via hun EC2-webservice (Elastic Compute Cloud). Met een relatief eenvoudig provisioningproces en de mogelijkheid om instances en opslagbehoeften gemakkelijk omhoog of omlaag te schalen, wil EC2 alle beloften van de cloud waarmaken tegen kosteneffectieve prijzen. Voor sommigen gaat de cloud echter niet alleen om flexibiliteit en implementatiegemak; het gaat om prestaties. De zakelijke voordelen van de mogelijkheid om krachtige omgevingen omhoog of omlaag te draaien voor kritieke toepassingen zoals analyse, wegen vaak veel zwaarder dan de kosten om dit via OPEX te doen in plaats van de langetermijninvestering van CAPEX. Daartoe heeft Amazon in mei de i3 bare metal-instancefamilie geïntroduceerd die directe toegang biedt tot CPU- en geheugenresources van de onderliggende server.
Het lijdt weinig twijfel dat Amazon de leider is als het gaat om een verscheidenheid aan cloudservices die worden aangeboden via hun EC2-webservice (Elastic Compute Cloud). Met een relatief eenvoudig provisioningproces en de mogelijkheid om instances en opslagbehoeften gemakkelijk omhoog of omlaag te schalen, wil EC2 alle beloften van de cloud waarmaken tegen kosteneffectieve prijzen. Voor sommigen gaat de cloud echter niet alleen om flexibiliteit en implementatiegemak; het gaat om prestaties. De zakelijke voordelen van de mogelijkheid om krachtige omgevingen omhoog of omlaag te draaien voor kritieke toepassingen zoals analyse, wegen vaak veel zwaarder dan de kosten om dit via OPEX te doen in plaats van de langetermijninvestering van CAPEX. Daartoe heeft Amazon in mei de i3 bare metal-instancefamilie geïntroduceerd die directe toegang biedt tot CPU- en geheugenresources van de onderliggende server.
i3.metal-instanties zijn gebouwd op het Nitro-systeem, een verzameling van door AWS gebouwde hardware-offload- en serverbeveiligingscomponenten die "veilig hoogwaardige netwerk- en opslagbronnen leveren aan EC2-instanties." i3.metal-instanties profiteren ook van alle andere services die AWS Cloud biedt, zoals Elastic Block Store (EBS), die we hebben gebruikt als onderdeel van deze beoordeling. De instances bieden ook tot 15.2 TB aan NVMe SSD-backed instance-opslag, evenals 2.3 GHz Intel Xeon-processors met 36 hyper-threaded cores (72 logische processors) en 512 GiB geheugen. Aan de fabric-kant leveren de i3.metal-instances tot 25 Gbps aan totale netwerkbandbreedte, waardoor een hoge netwerkdoorvoer en lagere latentie worden gestimuleerd via Elastic Network Adapter (ENA)-gebaseerde Enhanced Networking.
Binnen EC2 zijn er een aantal instantietypen. De i3-instanties vallen in de categorie "Opslag geoptimaliseerd", waarbij de i3.metal-instanties de mantel nemen als de best presterende van die groep. De onderstaande tabel geeft de familie en de configuratie van de instantietypen weer.
| Model | vCPU | Geheugen (GiB) | Netwerkprestaties | Opslag (TB) |
| i3.groot | 2 | 15.25 | Tot 10 Gigabit | 1 x 0.475 NVMe-SSD |
| i3.xgroot | 4 | 30.5 | Tot 10 Gigabit | 1 x 0.95 NVMe-SSD |
| i3.2xgroot | 8 | 61 | Tot 10 Gigabit | 1 x 1.9 NVMe-SSD |
| i3.4xgroot | 16 | 122 | Tot 10 Gigabit | 2 x 1.9 NVMe-SSD |
| i3.8xgroot | 32 | 244 | 10 Gigabit | 4 x 1.9 NVMe-SSD |
| i3.16xgroot | 64 | 488 | 25 Gigabit | 8 x 1.9 NVMe-SSD |
| i3.metaal | 72 | 512 | 25 Gigabit | 8 x 1.9 NVMe-SSD |
i3.metal instances zijn beschikbaar in de regio's AWS US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt) en Europe (Ierland) en kunnen worden gekocht als on-demand instances. Gereserveerde exemplaren (3 jaar, 1 jaar en converteerbaar), of als Spot-exemplaren. Voor deze review hebben we getest in de regio Noord-Virginia. We hebben getest met zowel NVMe-opslag als EBS-blokvolumes.
Performance
VDBench-werkbelastinganalyse
Om de prestaties van de EC2 i3.metal-instantie te evalueren, hebben we VDBench gebruikt die lokaal is geïnstalleerd om zowel EBS-opslag (30 x 1 TB) als NVMe-opslag (8 x 1.7 TB) te testen. Voor beide opslagtypen hebben we 12% van elk apparaat toegewezen en ze samen gegroepeerd om te kijken naar pieksysteemprestaties met een matige hoeveelheid gegevenslocatie.
Deze workloads bieden een scala aan verschillende testprofielen, variërend van "four corners"-tests, algemene tests voor de grootte van database-overdrachten, evenals het vastleggen van sporen uit verschillende VDI-omgevingen. Al deze tests maken gebruik van de gemeenschappelijke vdBench-workloadgenerator, met een scripting-engine om resultaten te automatiseren en vast te leggen over een groot rekentestcluster. Hierdoor kunnen we dezelfde workloads herhalen op een breed scala aan opslagapparaten, waaronder flash-arrays en individuele opslagapparaten.
profielen:
- 4K willekeurig lezen: 100% lezen, 128 threads, 0-120% joate
- 4K willekeurig schrijven: 100% schrijven, 64 threads, 0-120% irate
- 64K sequentieel lezen: 100% lezen, 16 threads, 0-120% jorate
- 64K sequentieel schrijven: 100% schrijven, 8 threads, 0-120% snelheid
- Synthetische database: SQL en Oracle
- VDI gekoppelde kloonsporen
We kijken in deze review naar zowel EBS als NVMe. Omdat er een enorm prestatieverschil is, hebben we de resultaten in twee grafieken verdeeld (de latentie zou zo ver uit elkaar liggen dat de grafieken erg moeilijk te lezen zouden zijn).
Onze eerste test kijkt naar 4K willekeurig lezen. Hier had de EBS-instantie tot het einde een latentie van minder dan een milliseconde. Met ongeveer 64K IOPS steeg de latentie tot 59.46 ms met een prestatie van 64,047 IOPS.
Als we kijken naar de NVMe 4K peak random read, zien we dat de instantie veel beter presteert. De instantie piekte op 2,802,904 IOPS met een latentie van 348μs.
4K willekeurig schrijven met EBS zag bijna hetzelfde als 4K leest met EBS. De instantie brak 1 ms iets eerder, ongeveer 60 IOPS, en piekte op 64,003 IOPS met een latentie van 29.97 ms.
Voor de NVMe-versie van de instantie was er een beetje een piek in latentie, maar nog steeds minder dan 1 ms. De instantie piekte op 920,975 IOPS met een latentie van 545μs.
Overschakelen naar sequentiële tests, voor de EBS 64K-piekleesprestaties, had de instantie een latentie van minder dan een milliseconde tot ongeveer 70K IOPS of ongeveer 450 MB/s en piekte op 17,360 IOPS of 1.08 GB/s met een latentie van 27.65 ms.
64K sequentieel lezen met de NVMe gaf ons topprestaties van 244,037 IOPS of 15.25 GB/s met een latentie van 514 μs.
Met 64K schrijven met EBS begon de instantie boven 1 ms en piekte op 17,359 IOPS of 1.08 GB/s met een latentie van 13.8 ms.
De 64K sequentiële schrijfbewerking is de eerste keer dat we zien dat de NVMe-instantie langer dan 1 ms duurt. De instantie piekte op 58,572 IOPS of 3.66 GB/s met een latentie van 1.08 ms.
Bij het overschakelen naar onze SQL-workloads had de EBS-instantie een latentieprestatie van minder dan een milliseconde tot ongeveer 55 IOPS en piekte op 64,036 IOPS met een latentie van 14.93 ms.
Voor de NVMe-versie van de instantie zagen we piekprestaties van 834,231 IOPS met een latentie van 302μs voor de SQL-test.
Voor de SQL 90-10 met EBS brak de instantie opnieuw de latentie van 1 ms rond 55 IOPS en bereikte een piek van 64,036 IOPS met een latentie van 14.99 ms.
De NVMe-versie van de instantie in de SQL 90-10 had een piekprestatie van 605,150 IOPS en een latentie van 415μs.
De SQL 80-20 met EBS gaf opnieuw bijna dezelfde cijfers met een latentie van minder dan een milliseconde die eindigde rond 55K IOPS en een piek van 64,036 IOPS met een latentie van 14.93 ms.
De SQL 80-20 met NVMe had de hitnummers van 511,840 IOPS en een latentie van 493μs.
De Oracle-tests voor EBS toonden dezelfde oneven piekprestaties van bijna dezelfde cijfers. Voor Oracle bereikte de instantie 64,036 IOPS met een latentie van 13.6 ms. De instantie had een latentieprestatie van minder dan een milliseconde tot ongeveer 55 IOPS.
Met NVMe bereikte de instantie 457,372 IOPS met een latentie van 613 μs in de Oracle-test.
Oracle 90-10 had de EBS-instantiepiek op 64,035 IOPS met een latentie van 10.3 ms. De instantie brak 1 ms bij ongeveer 55 IOPS.
De NVMe-versie van de instantie in de Oracle 90-10 kon 520,448 IOPS halen met een latentie van 333μs.
Oracle 80-20 liet de EBS 1 ms breken rond 55K IOPS en piekte op 64,036 IOPS met een latentie van 10.3 ms.
De instantie met NVMe had een piekprestatie van 435,265 IOPS met een latentie van 400 μs.
Vervolgens kijken we naar onze VDI Linked Clone (LC) testen. Beginnend met Boot had de EBS-versie van de instantie een latentie van minder dan een milliseconde tot ongeveer 35 IOPS en piekte op 42,893 IOPS met een latentie van 11.2 ms.
De NVMe-versie van de instantie bereikte een piek van 349,799 IOPS en een latentie van 363 μs in onze VDI LC Boot-test.
Voor de eerste aanmelding van VDI LC lag de EBS-instantie enige tijd schrijlings op de lijn van 1 ms voordat hij omviel rond 31 IOPS. De instance piekte op 34,486 IOPS en een latentie van 6.95 ms.
Met VDI LC Initial Login piekte de NVMe-instantie op 93,405 IOPS met een latentie van 677μs.
Met de VDI LC Monday Login flirtte de EBS-instantie opnieuw enige tijd met 1 ms voordat hij de duik nam rond 25K IOPS en piekte op 34,643 IOPS met een latentie van 13.85 ms.
En tot slot had onze VDI LC Monday Login met NVMe de instantiepiek van 119,615 IOPS met een latentie van 1.1 ms.
Conclusie
De cloudservices van Amazon worden doorgaans beschouwd als de meest veelzijdige die er zijn. Hoewel de rekenkracht en opslag zeker gevarieerd zijn, heeft Amazon ook prestatie-opties. Amazon biedt een overvloed aan prestatie-opties op zijn EC2-webservice, inclusief zijn i3 bare metal-exemplaar. Deze instanties maken gebruik van het AWS Nitro-systeem van speciaal gebouwde hardware en software. De i3.metal-instanties bieden betere prestaties door directe toegang tot de CPU's en het geheugen, terwijl ze gebruikers nog steeds de mogelijkheid bieden om te profiteren van andere functies, zoals AWS EBS-bijgevoegde opslag en lokale NVMe-opslag.
Voor prestaties hebben we zowel blokopslag (EBS) als NVMe getest. Dit is bedoeld om lezers een idee te geven van wat ze kunnen verwachten in termen van opties, en minder van de ene is beter dan de andere (doorgaans presteert NVMe-opslag beter en heeft een veel lagere latentie, daarom zijn er twee reeksen grafieken). Als we naar de EBS keken, zagen we een patroon waarbij de instantie boven de 1 ms ging en kort daarna versnelde in latentie en afwerking. Tijdens onze tests piekte de EBS op ongeveer 64K IOPS, wat het maximum is dat is toegestaan voor EBS. Dit omvatte de 4K-tests en alle drie de SQL- en Oracle-tests. De instantie vertraagde een beetje voor onze VDI-tests. Amazon geeft wel aan dat het mogelijk is om instellingen aan te passen om meer dan de 64K voorgeschreven IOPS te bereiken, maar de processen om daar te komen zijn niet wat de meeste klanten zouden ervaren, dus hebben we deze weg niet gevolgd.
Voor onze NVMe-tests zagen we resultaten die meer in lijn waren met onze normale benchmarks. Hoogtepunten hier waren een willekeurige 4K-leesprestatie van 2.8 miljoen IOPS, 4K-schrijfsnelheid van 920K IOPS, 64K-leessnelheid van 15.25 GB/s en SQL-prestaties van meer dan 500K IOPS in alle drie de tests (waarbij de SQL-test ongeveer 834K IOPS was). Oracle-tests hadden ook een sterke prestatie met de NVMe, met resultaten tussen 435 IOPS en 520 IOPS. Onze VDI Linked Clone vertoonde sterke opstartprestaties met ongeveer 350 IOPS. De enige teleurstelling hier is dat klanten niet kunnen kiezen voor meer lokale NVMe in de i3.metal-instanties.
Over het algemeen gaf de i3.metal-instantie ons precies wat Amazon beloofde. Dat is geruststellend voor klanten die willen weten dat ze het beloofde serviceniveau krijgen. Dit is natuurlijk niet zonder kosten, zoals bij elke cloudimplementatie, gaat de zorg over gebruiksgemak en resultaten in de cloud versus andere cloudproviders versus op locatie. Dat gezegd hebbende, klanten die werklasten hebben die genoegen kunnen nemen met een lager IOPS-niveau, kunnen behoorlijk wat geld besparen. Het komt er echter echt op neer wat de uiteindelijke vereisten zijn voor het specifieke exemplaar. Daartoe zijn de i3.metal-instanties geweldig voor reguliere toepassingen die de prestatielimieten die i3.metal biedt niet zullen of kunnen overschrijden en die de IOPS niet nodig hebben die een all-flash-array on prem zou leveren voor voorbeeld. En als je al deel uitmaakt van de Amazon-familie, is de overstap naar bare metal bekend en is er waarschijnlijk een kostenvoordeel als je meerdere AWS-programma's in bulk gebruikt.
Meld u aan voor de StorageReview-nieuwsbrief
