Beoordeling Oracle Cloud Infrastructure Compute Bare Metal Instances

De Oracle Cloud Infrastructure omvat een breed scala aan serviceaanbiedingen, waaronder rekenkracht, opslag, netwerken, databases en taakverdeling – in feite alle infrastructuur die nodig is om een cloudgebaseerd datacenter te bouwen. In de context van deze review zijn we geïnteresseerd in de Oracle Cloud Infrastructure Compute-categorie, met een zeer specifieke focus op hun bare metal-instances. Net als de meeste cloudproviders biedt Oracle gevirtualiseerde rekeninstances, maar in tegenstelling tot de meeste andere virtuele aanbiedingen, kan Oracle deze ondersteunen met vormen die tot ~25 TB aan NVMe-opslag bevatten voor applicaties die een lage latentie nodig hebben. Hoe goed die ook zijn, Oracle heeft de lat voor cloud computing-prestaties verder verhoogd door de eerste krachtige bare-metal-instances in de branche aan te bieden, ideaal voor missiekritieke applicaties waarbij latency van het grootste belang is. Instanties worden geleverd met maximaal 52 OCPU's, 768 GB RAM, dubbele 25 GbE NIC's en maximaal 51 TB aan lokaal aangesloten NVMe-opslag. Voor degenen die meer willen, is er tot 512 TB aan netwerkverbonden NVMe-blokopslag beschikbaar, evenals GPU-opties. Alle verschillende Oracle-rekenoplossingen draaien op een sterk geoptimaliseerd softwaregedefinieerd netwerk dat is afgestemd om conflicten te minimaliseren en de prestaties te maximaliseren.

De Oracle Cloud Infrastructure omvat een breed scala aan serviceaanbiedingen, waaronder rekenkracht, opslag, netwerken, databases en taakverdeling – in feite alle infrastructuur die nodig is om een cloudgebaseerd datacenter te bouwen. In de context van deze review zijn we geïnteresseerd in de Oracle Cloud Infrastructure Compute-categorie, met een zeer specifieke focus op hun bare metal-instances. Net als de meeste cloudproviders biedt Oracle gevirtualiseerde rekeninstances, maar in tegenstelling tot de meeste andere virtuele aanbiedingen, kan Oracle deze ondersteunen met vormen die tot ~25 TB aan NVMe-opslag bevatten voor applicaties die een lage latentie nodig hebben. Hoe geweldig die ook zijn, Oracle heeft de lat voor cloud computing-prestaties verder verhoogd door de eerste krachtige bare-metal-instances in de branche aan te bieden, ideaal voor missiekritieke applicaties waarbij latency van het grootste belang is. Instanties worden geleverd met maximaal 52 OCPU's, 768 GB RAM, dubbele 25 GbE NIC's en maximaal 51 TB aan lokaal aangesloten NVMe-opslag. Voor degenen die meer willen, is er tot 512 TB aan op het netwerk aangesloten NVMe-blokopslag beschikbaar, evenals GPU-opties. Alle verschillende Oracle-rekenoplossingen draaien op een sterk geoptimaliseerd softwaregedefinieerd netwerk dat is afgestemd om conflicten te minimaliseren en de prestaties te maximaliseren.

Er is op dit moment een grote verscheidenheid aan cloudaanbiedingen en zelfs verschillende grote cloudaanbiedingen met AWS, Google Cloud Platform en Microsoft Azure bovenaan die lijst. Hoewel deze cloudserviceproviders veel geweldige producten en services bieden, is één ding dat ze meestal niet hebben, de prestaties. Bij het vergelijken van cloud met on-premises, verslaat on-prem altijd de cloud zonder twijfel. Oracle probeert deze visie te veranderen met zijn aanbod van cloudinfrastructuur.

Het rekenaanbod van Oracle komt met beloftes die je zou verwachten van on-prem opslag of servers, waaronder prestaties, beschikbaarheid, veelzijdigheid en beheer. De prestatiekant ondersteunt piek- en consistente prestaties voor missiekritieke applicaties en wordt ondersteund door de onlangs aangekondigde SLA voor end-to-end cloudinfrastructuur, wat op het moment van schrijven de enige is die erop lijkt in de branche. Het aanbod ondersteunt beschikbaarheid op meerdere lagen, waaronder DNS, taakverdeling, replicatie, back-up, opslagmomentopnamen en clustering. Het rekenaanbod varieert van een single-core VM tot 52-core single-tenant bare metal, en biedt de veelzijdigheid om alles uit te voeren, van algemene workloads tot HPC-clusters. En met de bare metal-instances van Oracle krijgen klanten de isolatie en controle van een server op locatie, omdat ze geen andere tenants en geen software van een Oracle-provider bevatten.

Het rekenaanbod van Oracle Cloud is er in verschillende 'vormen', waaronder bare metal-instances, bare metal GPU-instances en VM-instances. Voor deze review kijken we naar bare metal-instances, die volgens Oracle tot 5.1 miljoen IOPS kunnen leveren en zijn bedoeld voor gebruiksscenario's zoals bedrijfskritische database-applicaties, HPC-workloads en I/O-intensieve webapplicaties. Ter vergelijking laten we ook de VM-vormen van Oracle zien, met lokale NVMe-opslag (DenseIO) en met netwerkblokopslag (standaard).

beheer

De beheer-GUI voor Oracle Cloud Infrastructure is vrij eenvoudig te achterhalen. De hoofdpagina bevat walkthroughs en hulp, indien nodig. Bovenaan staan de huur of het account, de regio die men gebruikt (us-ashburn-1, in ons geval), samen met tabbladen voor Home (wat de hoofdpagina is), Identity, Compute, Database, Networking, Storage, Audit , en E-mail. Voor onze tests worden DenseIO2 en Standard2 getoond.

Aangezien deze beoordeling zich richt op de Compute-kant, kunnen we onder dat tabblad kijken welke instanties we zullen gebruiken voor onze prestatietests. Elke instantie heeft zijn naam, vorm, regio, beschikbaarheidsdomein en wanneer deze is gemaakt. Aan de linkerkant kunnen gebruikers de vermelding wijzigen door de status te selecteren, bijvoorbeeld 'actief'.

Door op de ellips aan de rechterkant te klikken, kunt u iets dieper in een instantie boren. Kijkend naar de BM.DenseIO2.52, kan men gemakkelijk zien of de instantie actief is en meer diepgaande informatie erover. Hier kunnen ook tags aan worden gekoppeld. Bovenaan de info staat de mogelijkheid om een aangepaste afbeelding te maken, de instantie te starten, te stoppen of opnieuw op te starten, te beëindigen of tags toe te passen. Naar beneden scrollen geeft je de mogelijkheid om ook blokvolumes toe te voegen.

Op het tabblad Netwerken kan men zien welk Virtual Cloud Network wordt gebruikt of er een maken. Voor de VCN is er informatie zoals regio, standaardroutetabel, DNS-domein en wanneer deze is gemaakt. Nogmaals, de ellips aan de rechterkant maakt het mogelijk om naar beneden te gaan, tags toe te passen en een subnet te maken.

Onder het tabblad Opslag kunnen gebruikers de blokvolumes in hun compartiment zien en er meer maken. De blokvolumes worden weergegeven op aanmaakdatum en gebruikers kunnen inzoomen voor meer informatie, handmatige back-ups maken, het blokvolume loskoppelen van de instantie, het volume verwijderen of tags toepassen.

En zoals Audit impliceert, kan men snel gebeurtenissen uit het verleden bekijken door de datum en het tijdsbereik te selecteren. Dit stelt ondernemingen in staat om te voldoen aan de behoeften op het gebied van managementnaleving, waarbij de gebruiker en actie voor elke gebeurtenis of wijziging in de omgeving wordt vastgelegd.

Prestatie

VDBench-werkbelastinganalyse

Om de prestaties van deze Oracle Cloud-instances te evalueren, hebben we gebruik gemaakt van vdbench dat lokaal op elk platform is geïnstalleerd. Onze tests waren tegelijkertijd verspreid over alle lokale opslag, dus als zowel BV (Block Volume) als NVMe-opslag aanwezig waren, testten we één groep tegelijk. 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 volledige kloon en gekoppelde kloonsporen

We kijken naar zowel remote block devices (BV) als NVMe. Omdat er zo'n dramatisch 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). Voor deze review kijken we naar zowel Bare Metal (BM) als VM-configuraties met zowel standaard als dichte IO-runs op BV en alleen dichte IO-runs voor de NVMe.

Kijkend naar piek 4K gelezen voor BV, begonnen alle vier runs met een sterke latentie van minder dan een milliseconde. De eerste die wegviel was de VM.Standard, waardoor deze net onder de 53K IOPS kwam en vervolgens piekte op 60,591 IOPS met een latentie van 15ms. De volgende die de latentie van minder dan een milliseconde onderbrak, was de VM.DenseIO, die meer dan 1 ms ging op ongeveer dezelfde plek als standaard, maar piekte op 72,626 IOPS met een latentie van 7.5 ms. Beide bare metal-runs deden het veel beter met de DenseIO met latentieprestaties van minder dan een milliseconde tot ongeveer 235 IOPS, met een piek van 252,275 IOPS met een latentie van 4.1 ms. De BM.Standard haalde het tot ongeveer 250 IOPS voordat hij meer dan 1 ms overschreed en piekte op 258,329 IOPS met een latentie van 4.05 ms.

Kijkend naar de maximale 4K-leesprestaties voor NVMe, hadden beide runs een latentie van minder dan een milliseconde. De VM.DenseIO piekte op 569,534 IOPS met een latentie van 214μs. De BM.DenseIO piekte op 4,419,490 IOPS met een latentie van slechts 174.6 μs.

Als we overschakelen naar willekeurige 4K-schrijfpiekprestaties voor BV, zien we een vergelijkbare plaatsing als voorheen, waarbij de VM's veel eerder pieken dan de BM's. De VM.Standard bereikte ongeveer 63 IOPS voordat de latentie van minder dan een milliseconde werd verbroken en piekte op 77,229 IOPS bij een latentie van 5.3 ms. De VM.DenseIO presteerde een beetje beter met ongeveer 69K IOPS voordat hij meer dan 1 ms overschreed en piekte op 84,274 IOPS met een latentie van 3.9 ms. De BM.DenseIO was in staat om ten noorden van 263K IOPS te komen voordat hij boven de 1 ms in latentie ging en piekte op 280,158 IOPS met een latentie van 2.02 ms. En BM.Standard was de best presterende configuratie die ongeveer 278 IOPS maakte voordat hij de latentie van minder dan een milliseconde overschreed en piekte op 280,844 IOPS met een latentie van 1.84 ms.

Met de NVMe op 4K-schrijven presteerde de BM opnieuw beter dan de VM, waarbij beide latentieprestaties van minder dan een milliseconde hadden. De VM.DenseIO piekte op 412,207 IOPS met een latentie van 141μs. De BM.DenseIO piekte op 3,232,215 IOPS met een latentie van 125μs.

Als we verder gaan met sequentieel werk, kijken we eerst naar 64K gelezen voor BV. Zowel de VM.Standard als de VM.DenseIO onderbraken de latentie van 1 ms bij ongeveer 15.5 K IOPS of 968 MB/s. En beide behielden min of meer dezelfde prestaties terwijl de latentie steeg tot 8.2 ms. Opnieuw zagen we iets soortgelijks met BM.Standard en BM.DenseIO die beide 1 ms breken bij ongeveer 37.5K IOPS of 2.35GB/s. Beide configuraties piekten net ten noorden van 47K IOPS of 2.95 GB/s bij een latentie van 8.4 ms.

NVMe sequentiële 64K-lezing waarbij beide configuraties de hele tijd onder de submilliseconde latentie bleven. De VM.DenseIO piekte op 39,512 IOPS of 2.5GB/s met een latentie van 403μs, terwijl de BM.DenseIO piekte op 323,879 IOPS of 20.2GB/s met een latentie van 361μs.

Met 64K sequentiële schrijfbewerkingen voor BV zien we opnieuw een soortgelijk fenomeen met VM.Standard en VM.DenseIO die beide de latentie van 1 ms breken bij een prestatie van 12K IOPS of 770MB/s. Beide piekten rond 15.1K IOPS of 943MB/s bij een latentie van 3.1ms. Met de BM.Standard en BM.DenseIO braken beide de latentie van 1 ms bij ongeveer 42K IOPS of 2.6 GB/s, waarbij de BM.DenseIO piekte op 46,768 IOPS of 2.92 GB/s met een latentie van 2.6 ms. De BM.Standard piekte op 46,787 IOPS of 2.92 GB/s met een latentie van 3.4 ms.

Voor 64K sequentiële schrijfbewerkingen voor NVMe hadden zowel de VM.DenseIO als de BM.DenseIO opnieuw sub-milliseconde latentieprestaties, maar beide leden ook een piek in latentie (gekoppeld aan een laatste prestatievermindering voor de BM.DenseIO). De VM.DenseIO piekte op 25K IOPS of 1.56GB/s met een latentie van 311μs na een piek tot 754μs. De BM.DenseIO had veel betere piekprestaties (160,895 IOPS of 10.1 GB/s bij een latentie van 170 μs), maar viel aan het eind wat terug met een stijging van de latentie en eindigde op 132,192 IOPS of 8.8 GB/s met een latentie van 310μs.

In onze SQL-workload voor BV was de VM.Standard de eerste die boven de 1 ms ging bij ongeveer 50 IOPS en piekte op 73,259 IOPS met een latentie van 3.4 ms. VM.DenseIO overschreed een latentie van 1 ms bij ongeveer 58 IOPS en piekte op 78,624 IOPS met een latentie van 3.1 ms. Met de BM's bleven beide onder de 1 ms latentie tot ongeveer 275K (waarbij de BM.DenseIO iets langer liep). De BM.Standard bereikte een piek van 305,368 IOPS met een latentie van 1.7 ms terwijl de BM.DenseIO een piek bereikte van 307,979 IOPS met een latentie van 1.35 ms.

SQL voor NVMe had opnieuw een latentie van minder dan een milliseconde, waarbij de VM.DenseIO piekte op 188,786 IOPS met 167μs. De BM.DenseIO piekte op 1,684,869 IOPS met een latentie van 142μs.

In de SQL 90-10-benchmark voor BV braken beide VM's de latentieprestaties van minder dan een milliseconde bij ongeveer 58 IOPS. De VM.Standard piekte op 71,691 IOPS met een latentie van 3.5 ms. De VM.DenseIO piekte op 79,033 IOPS met een latentie van 3.05 ms. De BM.Standard brak de latentie van 1 ms met een prestatie van ongeveer 270 IOPS en piekte op 303,904 IOPS met een latentie van 1.7 ms. De BM.DenseIO had een latentie van minder dan een milliseconde tot ongeveer 290 IOPS en piekte op 307,472 IOPS met een latentie van 1.34 ms.

Voor NVMe SQL 90-10 piekte de VM.DenseIO op 172,693 IOPS met een latentie van 182μs. De BM.DenseIO piekte op 1,328,437 IOPS met 165μs.

In de SQL 80-20-benchmark voor BV bereikte de VM.Standard ongeveer 54K IOPS voordat hij meer dan 1 ms overschreed en piekte op 72,204 IOPS met een latentie van 3.4 ms. De VM.DenseIO had een latentie van minder dan een milliseconde tot ongeveer 59 IOPS en piekte op 78,787 IOPS met een latentie van 2.99 ms. De BM.Standard liep tot ongeveer 280 IOPS met een latentie van minder dan 1 ms en piekte op 300,014 IOPS met een latentie van 1.6 ms. De BM.DenseIO brak de latentie van 1 ms bij ongeveer 285 IOPS en piekte op 299,730 IOPS met een latentie van 1.3 ms voordat de prestaties terugliepen.

In de SQL 80-20-benchmark voor NVMe piekte de VM.DenseIO op 144,010 IOPS met een latentie van 218μs. De BM.DenseIO piekte op 1,114,056 IOPS met een latentie van 182μs voordat de prestaties iets terugliepen.

In onze Oracle-workload met BV had de VM.Standard een latentieprestatie van minder dan een milliseconde totdat hij ongeveer 52 IOPS bereikte en piekte op 70,096 IOPS met een latentie van 3.4 ms. De VM.DenseIO brak de latentie van 1 ms bij ongeveer 58K IOPS en piekte op 75,000 IOPS met een latentie van 3.1 ms. BM.Standard brak de latentie van 1 ms rond 255K met een piekprestatie van 280,599 IOPS met een latentie van 1.41 ms. BM.DenseIO had een latentie van minder dan een milliseconde tot ongeveer 260 IOPS en piekte op 267,632 IOPS met een latentie van 1.3 ms.

Onze Oracle-workload met NVMe liet een topprestatie zien voor de VM.DenseIO van 132,553 IOPS met een latentie van 257μs. Met BM.DenseIO waren de piekprestaties 1,043,104 IOPS en een latentie van 199μs.

In de Oracle 90-10 voor BV had de VM.Standard een latentie van minder dan een milliseconde tot iets meer dan 54K IOPS en piekte op 72,533 IOPS met een latentie van 2.2 ms. De VM.DenseIO brak de latentie van 1 ms bij ongeveer 61K IOPS en piekte op 76,908 IOPS met een latentie van 1.86 ms. Beide BM's bereikten 297 IOPS voordat ze de latentie van 1 ms verbraken. De BM.Standard piekte op 305,771 IOPS met een latentie van 1.17 ms. De BM.DenseIO had een piekprestatie van 297,509 IOPS met een latentie van 1.03 ms.

In de Oracle 90-10 voor NVMe had de VM.DenseIO een piekprestatie van 133,330 IOPS en een latentie van 163μs. De BM.DenseIO had een piekprestatie van 1,088,454 IOPS en een latentie van 142μs.

In de Oracle 80-20 met BV bereikte de VM.Standard ongeveer 55K in minder dan 1 ms en piekte op 74,032 IOPS met een latentie van 2.14 ms. De VM.DenseIO had een latentie van minder dan een milliseconde tot ongeveer 51K en piekte op 75,666 IOPS met een latentie van 2 ms. Beide BM's haalden het tot ongeveer 295 IOPS voordat ze 1 ms braken. De BM.Standard piekte op 306,955 IOPS met een latentie van 1.14 ms. De BM.DenseIO piekte op ongeveer 295K IOPS met een latentie van 893μs.

In de Oracle 80-20 met NVMe piekte de VM.DenseIO op 108,483 IOPS met een latentie van 195μs. De BM.DenseIO piekte op 956,326 IOPS met een latentie van 158μs.

Vervolgens keken we naar VDI Full Clone. Voor het opstarten met BV brak VM.Standard 1 ms net onder de 40K IOPS en piekte op 56,057 IOPS met een latentie van 4.2 ms. VM.DenseIO haalde het met een latentie van minder dan een milliseconde tot ongeveer 43K IOPS en piekte op 61,570 IOPS met een latentie van 3.6 ms. Beide BM's hadden een latentie van minder dan een milliseconde tot net boven de 200 IOPS-drempel. Beide piekten op ongeveer 220 IOPS met een latentie van 2.1 voordat de prestaties achteruit gingen.

Voor Full Clone-opstart met NVMe piekte de VM.DenseIO op ongeveer 136K IOPS met een latentie van 235μs. De BM.DenseIO piekte op 1,032,322 IOPS met een latentie van 213μs.

Met VDI Full Clone Initial Log In with BV bereikten beide VM's ongeveer 41 IOPS met een latentie van minder dan een milliseconde, waarbij de VM.Standard piekte op 55,522 IOPS met een latentie van 3.7 ms en de VMDenseIO piekte op 59,560 IOPS met een latentie van 3.6 ms . Beide BM's braken de latentie van minder dan een milliseconde rond 203K IOPS (met standaard voor dicht). BM.Standard piekte op ongeveer 225 IOPS met een latentie van 2.04 ms en de BM.DenseIO piekte op 224,385 IOPS met een latentie van 1.8 ms.

Voor VDI Full Clone Initial Login met NVMe piekte de VM.Standard op 59,883 IOPS met een latentie van 506μs. En de BM.DenseIO piekte op 467,761 IOPS met een latentie van 262μs.

VDI Full Clone Monday Login with BV had de VM.Standard met een latentie van minder dan een milliseconde tot net onder de 36K IOPS met een piek van 50,685 IOPS en een latentie van 2.3 ms. VM.DenseIO presteerde minder dan 1 ms tot net ten noorden van 38K IOPS en piekte op 53,304 IOPS met een latentie van 2.2 ms. BM.Standard brak de latentie van 1 ms bij ongeveer 205 IOPS en piekte op 224,764 IOPS met een latentie van 1.5 ms. BM.DenseIO ging boven 1 ms rond 210K met een piek van iets meer dan 220K IOPS en een latentie van 1.2 ms.

VDI Full Clone Monday Login met NVMe toonde een piekprestatie van VM.DenseIO van 44,384 IOPS met een latentie van 356μs. BM.DenseIO piekte op 356,691 IOPS met een latentie van 252μs.

Onze uiteindelijke selectie van tests kijkt naar VDI Linked Clone. Opnieuw beginnend met de opstarttest met BV, had de VM.Standard een latentie van minder dan een milliseconde tot ongeveer 29K IOPS, met een piek van ongeveer 38K IOPS met een latentie van 2.4 ms. VM.DenseIO haalde het tot ongeveer 32K IOPS voordat het 1 ms brak en piekte ook op ongeveer 38K IOPS met een latentie van 2.16 ms. Beide BM's bereikten ongeveer 100 IOPS voordat ze de latentie van 1 ms overschreden. Beide hadden een piekprestatie van ongeveer 114K IOPS met een latentie van 3 ms.

Met VDI Linked Clone Boot voor NVMe zagen we de VM.DenseIO-piek op 65,384 IOPS met een latentie van 238μs. De BM.DenseIO piekte op 555,004 IOPS met een latentie van 217μs.

Met Initial Login with BV braken beide VM's de latentie van 1 ms bij ongeveer 28K IOPS, waarbij de VM.Standard piekte op 36,682 IOPS met een latentie van 1.6 ms en de VM.DenseIO piekte op 38,525 IOPS met een latentie van 1.6 ms. Beide BM's braken de latentie van 1 ms bij ongeveer 132K IOPS, waarbij de BM.Standard een piek bereikte van 140,848 IOPS met een latentie van 1.3 ms en de BM.DenseIO een piek van 139,883 IOPS en een latentie van 1.2 ms.

Eerste login met NVMe zag een piekprestatie van 24,228 IOPS en 326μs voor de VM.DenseIO en 242,778 IOPS met 234μs voor de BM.DenseIO.

Eindelijk, met VDI Linked Clone Monday Login with BV, had de VM.Standard een latentieprestatie van minder dan een milliseconde tot ongeveer 27K IOPS met een piek van 39,874 IOPS en een latentie van 2.86 ms. VM.DenseIO brak 1 ms bij ongeveer 25 IOPS en piekte op 42,469 IOPS en 3 ms latentie. Beide BM's hadden een latentie van minder dan een milliseconde tot ongeveer 135K IOPS met beide een piek van 146K IOPS, de densityIO had een latentie van 1.6 ms en de standaard had een latentie van 1.76 ms.

Met VDI Linked Clone Monday Login met NVMe piekte de VM.DenseIO op 34,016 IOPS en een latentie van 464μs. BM.DenseIO piekte op 260,527 IOPS en een latentie van 317μs.

Conclusie

Oracle's Cloud Infrastructure neemt een van de belangrijkste problemen met de Cloud - prestaties of het gebrek daaraan - en pakt dit aan met zijn bare metal-instances. Oracle biedt bare metal en virtuele rekeninstances, evenals NVMe-versies met tot 25 TB NVMe-opslag voor ongeëvenaarde prestaties in de cloud. Er is meer nodig dan NVMe-opslag om Oracle's geciteerde prestaties van maximaal 5.1 miljoen IOPS te halen; de instanties hebben ook tot 52 OCPU's, 768 GB RAM, dubbele 25 GbE NIC's en tot 51 TB aan lokaal aangesloten NVMe-opslag. Dit prestatieniveau wordt voornamelijk gebruikt voor gebruiksscenario's zoals bedrijfskritische databasetoepassingen, HPC-workloads en I/O-intensieve webtoepassingen.

Wat de prestaties betreft, hebben we onze VDBech-tests uitgevoerd voor zowel bare metal (BM) als VM-vormen met behulp van zowel de lokale NVMe-opslag (DenseIO) als netwerkblokopslag (Standard). De uitvoering, simpel gezegd, blies ons weg. Voor elke test hebben we twee sets grafieken uitgevoerd, omdat het latentieverschil tussen de DenseIO en Standard zo groot was dat de grafieken moeilijk te lezen zouden zijn als ze allemaal op één set zouden staan. In termen van hoe goede opslagprestaties op deze instanties worden vergeleken met traditionele opslag, wedijveren ze met veel van de beste gedeelde opslagopties op de markt, laat staan met cloudalternatieven. De gekoppelde BV's die worden gehost via iSCSI en waarvan een back-up wordt gemaakt, bieden een sterke mix van doorvoer en bandbreedte, geserveerd met een lage latentie. Om dit in context te plaatsen: we zagen dat veel tests met 32 BV's aangesloten op de 52 OCPU-instances de prestaties overtroffen van all-flash storagearrays die we in ons laboratorium hebben getest. Sommige waren misschien zelfs iets sneller, wat best indrukwekkend is als je bedenkt dat we een cloudinstantie vergelijken met een AFA van $ 250+, FC-switching en meerdere compute-hosts.

Wat de bare metal-instances van Oracle Cloud echter echt ongelooflijk maakt, is de lokaal aangesloten NVMe-opslag. De DenseIO2.8 had 1 apparaat, terwijl de DenseIO2.52 er 8 had, waardoor de prestaties van deze instanties werden gemeten in miljoenen IOPS. De instantie met 1 NVMe SSD zag een willekeurige 4K-leessnelheid tot 569 IOPS, terwijl de instantie met 8 de prestaties omhoogschoot naar 4.4 miljoen IOPS. Bandbreedte was ook geen grap; de kleinere instantie zag een leespiek van 2.5 GB/s, terwijl de grotere boven de 20 GB/s uitkwam. Zorg ervoor dat u een back-upplan hebt, aangezien de NVMe-vormen tenslotte lokaal gekoppelde opslag zijn, die moet worden beschermd.

Oracle heeft top-spec servers en opslag in de cloud gebouwd; het enige dat hun bare metal-instanties kan evenaren, is het bouwen van een server met topspecificaties die lokaal wordt gehost, samen met alle andere componenten en services om dit te ondersteunen. Net als bij alle cloudoplossingen biedt Oracle de flexibiliteit om uw instances in en uit te schakelen en de flexibiliteit om de opslagvereisten naar behoefte aan te passen. In deze gevallen is het voor de hand liggende probleem de kosten. De opportuniteit van het online krijgen van een instance binnen Oracle Cloud versus de inspanning en kosten die nodig zijn om vergelijkbare hardware in uw eigen datacenter op te zetten, is misschien wel de belangrijkste doorslaggevende factor. Hoewel aangesloten NVMe-opslag duur is, is er geen discussie over de prestatievoordelen die we zagen. Als u een bedrijf heeft dat wordt beïnvloed door de verwerkingstijd van grote datasets, is er geen eenvoudigere of snellere oplossing om workloads zoals analyses compleet te krijgen dan de op NVMe gebaseerde vormen die we gebruikten. En het is niet zo dat de standaard bijgevoegde blokvormen slecht waren, de NVMe-vormen waren gewoon zo onwerkelijk dat ze de rest overschaduwen. Het komt erop neer dat vooruitstrevende bedrijven die meetbare waarde kunnen halen uit een krachtige cloud, zeker moeten evalueren wat Oracle aan het doen is. Er zijn veel keuzes wanneer u naar de cloud gaat, maar niets is zo snel als wat we hebben gezien met de Oracle Cloud bare metal-instances, waardoor deze oplossingen een duidelijke en terechte winnaar zijn van onze eerste Editor's Choice Award die is toegekend aan een cloudservices aanbieder.