Det råder ingen tvekan om att Amazon är ledande när det kommer till en mängd olika molntjänster som erbjuds genom deras EC2 (Elastic Compute Cloud) webbtjänst. Med en relativt enkel provisioneringsprocess och möjligheten att enkelt skala instanser och lagringsbehov upp eller ner, siktar EC2 på att leverera alla löften om molnet till kostnadseffektiva prisklasser. För vissa handlar dock molnet inte bara om flexibilitet och enkel implementering; det handlar om prestanda. Affärsfördelarna med att kunna snurra kraftfulla miljöer upp eller ner för kritiska applikationer som analys kan ofta överväga kostnaden för att göra det genom OPEX istället för den långsiktiga investeringen av CAPEX. För det ändamålet lanserade Amazon i maj i3 bare metal-instansfamiljen som ger direkt åtkomst till CPU- och minnesresurser på den underliggande servern.
Det råder ingen tvekan om att Amazon är ledande när det kommer till en mängd olika molntjänster som erbjuds genom deras EC2 (Elastic Compute Cloud) webbtjänst. Med en relativt enkel provisioneringsprocess och möjligheten att enkelt skala instanser och lagringsbehov upp eller ner, siktar EC2 på att leverera alla löften om molnet till kostnadseffektiva prisklasser. För vissa handlar dock molnet inte bara om flexibilitet och enkel implementering; det handlar om prestanda. Affärsfördelarna med att kunna snurra kraftfulla miljöer upp eller ner för kritiska applikationer som analys kan ofta överväga kostnaden för att göra det genom OPEX istället för den långsiktiga investeringen av CAPEX. För det ändamålet lanserade Amazon i maj i3 bare metal-instansfamiljen som ger direkt åtkomst till CPU- och minnesresurser på den underliggande servern.
i3.metal-instanser är byggda på Nitro-systemet, som är en samling av AWS-byggda hårdvaruavlastnings- och serverskyddskomponenter som "på ett säkert sätt tillhandahåller högpresterande nätverks- och lagringsresurser till EC2-instanser." i3.metal-instanser drar också nytta av alla andra tjänster som AWS Cloud erbjuder som Elastic Block Store (EBS), som vi utnyttjade som en del av denna recension. Instanserna har också upp till 15.2 TB NVMe SSD-stödd instanslagring, samt 2.3 GHz Intel Xeon-processorer som erbjuder 36 hypertrådade kärnor (72 logiska processorer) och 512 GiB minne. På tygsidan levererar i3.metal-instanserna upp till 25 Gbps sammanlagd nätverksbandbredd, vilket driver hög nätverksgenomströmning och lägre latens via Elastic Network Adapter (ENA)-baserad Enhanced Networking.
Inom EC2 finns ett antal instanstyper. i3-instanserna faller inom kategorin "Storage Optimized", där i3.metal-instanserna tar manteln som den högst presterande av den gruppen. Tabellen nedan belyser familjen och konfigurationen av instanstyperna.
| Modell | vCPU | Minne (GiB) | Nätverksprestanda | Lagring (TB) |
| i3.stor | 2 | 15.25 | Upp till 10 Gigabit | 1 x 0.475 NVMe SSD |
| i3.xlarge | 4 | 30.5 | Upp till 10 Gigabit | 1 x 0.95 NVMe SSD |
| i3.2xlarge | 8 | 61 | Upp till 10 Gigabit | 1 x 1.9 NVMe SSD |
| i3.4xlarge | 16 | 122 | Upp till 10 Gigabit | 2 x 1.9 NVMe SSD |
| i3.8xlarge | 32 | 244 | 10 Gigabit | 4 x 1.9 NVMe SSD |
| i3.16xlarge | 64 | 488 | 25 Gigabit | 8 x 1.9 NVMe SSD |
| i3.metall | 72 | 512 | 25 Gigabit | 8 x 1.9 NVMe SSD |
i3.metal-instanser är tillgängliga i regionerna AWS US East (N. Virginia), US East (Ohio), US West (Oregon), Europa (Frankfurt) och Europa (Irland) och kan köpas som On-Demand-instanser, Reserverade instanser (3-Yr, 1-Yr och Convertible), eller som Spot-instanser. För denna recension testade vi i North Virginia-regionen. Vi testade med både NVMe-lagring och EBS-blockvolymer.
Prestation
VDBench arbetsbelastningsanalys
För att utvärdera prestandan för EC2 i3.metal-instansen använde vi VDBench installerad lokalt för att testa både EBS (30x1TB) och NVMe (8×1.7TB) lagring. Med båda lagringstyperna allokerade vi 12 % av varje enhet och grupperade dem sammantaget för att titta på maximal systemprestanda med en måttlig mängd datalokalitet.
Dessa arbetsbelastningar erbjuder en rad olika testprofiler som sträcker sig från "fyra hörn"-tester, vanliga tester av databasöverföringsstorlek, såväl som spårfångst från olika VDI-miljöer. Alla dessa tester utnyttjar den vanliga vdBench-arbetsbelastningsgeneratorn, med en skriptmotor för att automatisera och fånga resultat över ett stort beräkningstestkluster. Detta gör att vi kan upprepa samma arbetsbelastningar över ett brett utbud av lagringsenheter, inklusive flash-arrayer och individuella lagringsenheter.
profiler:
- 4K slumpmässig läsning: 100 % läsning, 128 trådar, 0-120 % iorat
- 4K Random Write: 100% Write, 64 trådar, 0-120% iorate
- 64K sekventiell läsning: 100 % läsning, 16 trådar, 0-120 % iorat
- 64K sekventiell skrivning: 100% skriv, 8 trådar, 0-120% iorate
- Syntetisk databas: SQL och Oracle
- VDI-länkade klonspår
Vi tittar på både EBS och NVMe i denna recension. Eftersom det finns en dramatisk prestandaskillnad har vi delat upp resultaten i två diagram (latensen skulle vara så långt ifrån varandra att diagrammen skulle vara mycket svåra att läsa).
Vårt första test tittar på slumpmässig läsning i 4K. Här hade EBS-instansen sub-millisekunders latensprestanda ända till slutet. Precis vid cirka 64K IOPS ökade den i latens till 59.46ms med prestanda på 64,047 XNUMX IOPS.
När vi tittar på slumpmässig läsning av NVMe 4K-topp, ser vi att instansen presterar mycket bättre. Förekomsten nådde en topp på 2,802,904 348 XNUMX IOPS med en latens på XNUMX μs.
4K slumpmässig skrivning med EBS såg nästan samma sak som 4K-läsning med EBS. Förekomsten bröt 1 ms lite tidigare, cirka 60K IOPS, och nådde en topp på 64,003 29.97 IOPS med en latens på XNUMX ms.
För NVMe-versionen av instansen var det lite spik i latensen men fortfarande under 1 ms. Förekomsten nådde en topp på 920,975 545 IOPS med en latens på XNUMX μs.
Byte över till sekventiella tester, för EBS 64K topp läsprestanda, hade instansen submillisekunders latens till cirka 70K IOPS eller cirka 450MB/s och toppade på 17,360 1.08 IOPS eller 27.65GB/s med en latens på XNUMXms.
64K sekventiell läsning med NVMe gav oss toppprestanda på 244,037 15.25 IOPS eller 514 GB/s med en latens på XNUMXμs.
Med 64K-skrivning med EBS startade instansen över 1 ms och nådde en topp på 17,359 1.08 IOPS eller 13.8 GB/s med en latens på XNUMX ms.
64K sekventiell skrivning är första gången vi ser NVMe-instansen gå över 1ms. Förekomsten nådde en topp på 58,572 3.66 IOPS eller 1.08 GB/s med en latens på XNUMX ms.
När vi växlade över till våra SQL-arbetsbelastningar hade EBS-instansen sub-millisekunders latensprestanda fram till cirka 55K IOPS och toppade på 64,036 14.93 IOPS med en latens på XNUMXms.
För NVMe-versionen av instansen såg vi toppprestanda på 834,231 302 IOPS med en latens på XNUMXμs för SQL-testet.
För SQL 90-10 med EBS, bröt instansen återigen 1ms latens runt 55K IOPS och gick vidare till en topp på 64,036 14.99 IOPS med XNUMXms latens.
NVMe-versionen av instansen i SQL 90-10 hade en toppprestanda på 605,150 415 IOPS och en latens på XNUMXμs.
SQL 80-20 med EBS gav återigen nästan samma siffror med fördröjningen under millisekunder som slutade runt 55K IOPS och en topp på 64,036 14.93 IOPS med XNUMXms latens.
SQL 80-20 med NVMe hade instansens träffnummer på 511,840 493 IOPS och en latens på XNUMXμs.
Oracle-testerna för EBS visade samma udda toppprestanda med nästan samma siffror. För Oracle nådde instansen 64,036 13.6 IOPS med en latens på 55 ms. Förekomsten hade en fördröjningsprestanda på under millisekunder fram till cirka XNUMXK IOPS.
Med NVMe fick instansen 457,372 613 IOPS med en latens på XNUMXμs i Oracle-testet.
Oracle 90-10 hade EBS-instansens topp vid 64,035 10.3 IOPS med en latens på 1 ms. Förekomsten bröt 55ms vid cirka XNUMXK IOPS.
NVMe-versionen av instansen i Oracle 90-10 kunde nå 520,448 333 IOPS med en latens på XNUMXμs.
Oracle 80-20 hade EBS-avbrottet 1ms runt 55K IOPS och toppade på 64,036 10.3 IOPS med en latens på XNUMXms.
Förekomsten med NVMe hade en toppprestanda på 435,265 400 IOPS med en latens på XNUMX μs.
Därefter tittar vi på våra VDI Linked Clone (LC)-tester. Från och med Boot hade EBS-versionen av instansen sub-millisekunders latens till cirka 35K IOPS och toppade på 42,893 11.2 IOPS med en latens på XNUMXms.
NVMe-versionen av instansen kunde nå en topp på 349,799 363 IOPS och en latens på XNUMXμs i vårt VDI LC Boot-test.
För VDI LC Initial Login gick EBS-instansen över linjen på 1ms under en tid innan den föll över runt 31K IOPS. Förekomsten nådde en topp på 34,486 6.95 IOPS och XNUMX ms latens.
Med VDI LC Initial Login nådde NVMe-instansen en topp på 93,405 677 IOPS med en latens på XNUMXμs.
Med VDI LC Monday Login flirtade EBS-instansen återigen med 1ms under en tid innan de tog steget runt 25K IOPS och fortsatte med att nå toppen på 34,643 13.85 IOPS med en latens på XNUMXms.
Och slutligen, vår VDI LC Monday Login med NVMe hade instanstoppen på 119,615 1.1 IOPS med en latens på XNUMX ms.
Slutsats
Amazons molntjänster anses vanligtvis vara de mest mångsidiga som finns. Även om beräkningen och lagringen verkligen varierar, har Amazon också prestandaalternativ. Amazon erbjuder en uppsjö av prestandaalternativ på sin EC2-webbtjänst, inklusive dess i3 bare metal-instans. Dessa instanser utnyttjar AWS Nitro-systemet med specialbyggd hårdvara och mjukvara. i3.metal-instanserna ger bättre prestanda genom direkt åtkomst till processorerna och minnet samtidigt som de erbjuder användarna möjligheten att dra nytta av andra funktioner som AWS EBS-ansluten lagring och lokal NVMe-lagring.
För prestanda testade vi både blocklagring (EBS) och NVMe. Detta är avsett att ge läsarna en uppfattning om vad de kan förvänta sig när det gäller alternativ, och mindre av att det ena är bättre än det andra (vanligtvis presterar NVMe-lagring bättre och har mycket lägre latens, vilket är anledningen till att det finns två uppsättningar diagram). När vi tittade på EBS såg vi ett mönster där instansen gick över 1 ms och sedan kort därefter ökade i latens och finish. Under hela vår testning nådde EBS en topp på cirka 64K IOPS, vilket är det högsta tillåtna för EBS. Detta inkluderade 4K-testerna och alla tre SQL- och Oracle-testerna. Förekomsten saktade lite för våra VDI-tester. Amazon indikerar att det är möjligt att justera inställningar för att uppnå mer än 64K föreskrivna IOPS, men processerna för att komma dit är inte vad de flesta kunder skulle uppleva, så vi följde inte denna väg.
För vår NVMe-testning såg vi resultat som var mer i linje med våra normala riktmärken. Höjdpunkterna här inkluderade en slumpmässig 4K-läsprestanda på 2.8 miljoner IOPS, 4K-skrivning på 920K IOPS, 64K-läsning på 15.25GB/s och SQL-prestanda över 500K IOPS i alla tre testerna (med SQL-testet på runt 834K IOPS). Oracle-tester visade också starkt med NVMe, med resultat mellan 435K IOPS och 520K IOPS. Vår VDI Linked Clone visade en stark startprestanda med ungefär 350K IOPS. Den enda besvikelsen här är att kunderna inte kan välja mer lokala NVMe i i3.metal-instanserna.
Sammantaget gav i3.metal-instansen oss exakt vad Amazon lovade att den skulle. Det är betryggande för kunder som vill veta att de kommer att få den utlovade servicenivån. Detta är naturligtvis inte utan kostnad, som med alla molninstallationer kommer problemet att handla om användarvänlighet och resultat i molnet kontra andra molnleverantörer kontra on prem. Som sagt, kunder som har arbetsbelastningar som kan nöja sig med en lägre IOPS-nivå kan spara en hel del pengar. Men det handlar verkligen om vad de ultimata kraven är för den specifika instansen. För det ändamålet är i3.metal-instanserna utmärkta för vanliga applikationer som inte kommer att eller inte kan överskrida prestandagränserna i3.metal erbjuder och som inte behöver IOPS en all flash-array on prem skulle leverera för exempel. Dessutom, om du redan är i Amazon-familjen, är övergången till ren metall bekant och det finns förmodligen en kostnadsfördel när du konsumerar flera AWS-program i bulk.
Anmäl dig till StorageReviews nyhetsbrev
