Oracles molninfrastruktur inkluderar ett brett utbud av tjänsteerbjudanden inklusive beräkning, lagring, nätverk, databas och lastbalansering – i själva verket all den infrastruktur som krävs för att bygga ett molnbaserat datacenter. I samband med den här recensionen är vi intresserade av kategorin Oracle Cloud Infrastructure Compute, med ett mycket specifikt fokus på deras instanser av ren metall. Liksom de flesta molnleverantörer erbjuder Oracle virtualiserade beräkningsinstanser, men till skillnad från de flesta andra virtuella erbjudanden kan Oracle backa upp dessa med former som innehåller upp till ~25TB NVMe-lagring för applikationer som behöver låg latens. Hur bra de än är, har Oracle ytterligare höjt satsningen på molnberäkningsprestanda genom att erbjuda branschens första högpresterande bare-metal-instanser, idealiska för verksamhetskritiska applikationer där latens är av största vikt. Instanser kommer med upp till 52 OCPU, 768 GB RAM, dubbla 25 GbE NIC och upp till 51 TB lokalt ansluten NVMe-lagring. För de som vill ha mer finns upp till 512 TB nätverksansluten NVMe-blocklagring tillgängligt samt GPU-alternativ. Alla olika Oracle-datorerbjudanden körs på ett högoptimerat mjukvarudefinierat nätverk som är inställt för att minimera konflikter och maximera prestanda.
Det finns ett brett utbud av molnerbjudanden för närvarande och till och med flera stora molnerbjudanden med AWS, Google Cloud Platform och Microsoft Azure överst på listan. Även om dessa molntjänstleverantörer erbjuder många fantastiska produkter och tjänster, är en sak som de vanligtvis inte har prestanda. När man jämför moln med lokalt, slår on-prem alltid molnet helt enkelt. Oracle vill ändra denna syn med sina molninfrastrukturerbjudanden.
Oracles beräkningserbjudanden kommer med löften man kan förvänta sig av lokala lagrings- eller servrar, inklusive prestanda, tillgänglighet, mångsidighet och styrning. Prestandasidan stöder maximal och konsekvent prestanda för verksamhetskritiska applikationer och backas upp av det nyligen tillkännagivna heltäckande servicenivåavtalet för molninfrastruktur , vilket i skrivande stund är det enda liknande i branschen. Erbjudandet stöder tillgänglighet på flera lager, inklusive DNS, lastbalansering, replikering, säkerhetskopiering, lagringsbilder och klustring. Beräkningserbjudandena sträcker sig från en enda kärnig virtuell dator till 52-kärnig en-tenant bare metal-instans, vilket erbjuder mångsidigheten att köra allt från vanliga arbetsbelastningar till HPC-kluster. Och med Oracles bare metal-instanser får kunderna isoleringen och kontrollen hos en lokal server, eftersom de inte innehåller några andra hyresgäster och ingen programvara från Oracle-leverantören.
Beräkningserbjudandena från Oracle Cloud finns i flera "former", inklusive instanser av ren metall, GPU-instanser av bar metall och VM-instanser. För denna granskning kommer vi att titta på instanser av ren metall, som enligt Oracle kan leverera upp till 5.1 miljoner IOPS och är avsedda för användningsfall som uppdragskritiska databasapplikationer, HPC-arbetsbelastningar och I/O-intensiva webbapplikationer. Som jämförelse visar vi också Oracles VM-former, med lokal NVMe-lagring (DenseIO) och med nätverksblocklagring (Standard).
Verksamhetsledningen
Hanteringsgränssnittet för Oracle Cloud Infrastructure är ganska enkelt att ta reda på. Huvudsidan har genomgångar och hjälp om det behövs. Längst upp finns hyresrätten eller kontot, den region man använder (us-ashburn-1, i vårt fall), tillsammans med flikar för Hem (som är huvudsidan), Identitet, Beräkna, Databas, Nätverk, Lagring, Revision och e-post. För våra tester visas DenseIO2 och Standard2.
Eftersom den här recensionen fokuserar på Compute-sidan, tittar vi under den fliken kan vi se de instanser vi kommer att använda för våra prestandatester. Varje instans har sitt namn, form, region, tillgänglighetsdomän och när den skapades. På vänster sida kan användare ändra listan genom att välja status, till exempel "kör".
Genom att klicka på ellipsen på höger sida kan man borra lite djupare i en instans. Om man tittar på BM.DenseIO2.52 kan man enkelt se om instansen körs och mer djupgående information om den. Taggar kan kopplas till det här också. Längst upp i informationen finns möjligheten att skapa en anpassad bild, starta, stoppa eller starta om instansen, avsluta den eller tillämpa taggar. Att scrolla ner ger en möjlighet att även bifoga blockvolymer.
Under fliken Nätverk kan man se det virtuella molnnätverket som används eller skapa ett. För VCN finns det information som region, standardrutttabell, DNS-domän och när den skapades. Återigen, ellipsen till höger gör det möjligt att borra ner, applicera taggar och skapa ett subnät.
Under fliken Lagring kan användare se blockvolymerna i sitt fack och skapa fler. Blockvolymerna listas efter datum då de skapades och användare kan drilla ner för mer information, skapa manuella säkerhetskopior, ta bort blockvolymen från instansen, ta bort volymen eller tillämpa taggar.
Och som Audit antyder kan man snabbt titta på tidigare händelser genom att välja datum och tidsintervall. Detta gör det möjligt för företag att möta ledningsefterlevnadsbehov där användaren och åtgärder för varje händelse eller förändring av miljön fångas.
Prestanda
VDBench arbetsbelastningsanalys
För att utvärdera prestandan för dessa Oracle Cloud-instanser använde vi vdbench som installerades lokalt på varje plattform. Våra tester spreds över all lokal lagring samtidigt, så om både BV (Block Volume) och NVMe-lagring fanns, testade vi en grupp åt gången. 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 Full Clone och Linked Clone Traces
Vi tittar på både remote block devices (BV) och NVMe. Eftersom det finns en så 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). För den här recensionen tittar vi på både Bare Metal (BM) och VM-konfigurationer med både standard och täta IO-körningar på BV och bara täta IO-körningar för NVMe.
När man tittar på topp 4K-läsning för BV, började alla fyra körningarna med en stark latens på under millisekunder. Den första som lossnade var VM.Standard, vilket gjorde att den var strax under 53K IOPS och nådde en topp på 60,591 15 IOPS med en latens på 1ms. Nästa som bröt fördröjningen under millisekunder var VM.DenseIO, som gick över 72,626 ms på ungefär samma plats som standard, men nådde en topp på 7.5 235 IOPS med en latens på 252,275 ms. Båda bara metal-körningarna gick mycket bättre med DenseIO som körde sub-millisekunders latensprestanda fram till cirka 4.1K IOPS, och nådde en topp på 250 1 IOPS med en latens på 258,329ms. BM.Standard klarade sig till cirka 4.05K IOPS innan den gick över XNUMXms och nådde en topp på XNUMX XNUMX IOPS med en latens på XNUMXms.
Om man tittar på topp 4K-läsprestanda för NVMe, hade båda körningarna sub-millisekunders latens hela tiden. VM.DenseIO nådde en topp på 569,534 214 IOPS med en latens på 4,419,490μs. BM.DenseIO nådde en topp på 174.6 XNUMX XNUMX IOPS med en latens på endast XNUMX μs.
Genom att byta till slumpmässig 4K-skrivtoppprestanda för BV ser vi en liknande placering som tidigare med virtuella datorer som toppar mycket tidigare än BM. VM.Standard nådde cirka 63K IOPS innan den bröt fördröjningen under millisekunder och nådde en topp på 77,229 5.3 IOPS vid 69 ms latens. VM.DenseIO presterade lite bättre och slog omkring 1K IOPS innan den gick över 84,274ms och nådde en topp på 3.9 263 IOPS med en latens på 1ms. BM.DenseIO kunde ta sig norr om 280,158K IOPS innan den gick över 2.02 ms i latens och nådde en topp på 278 280,844 IOPS med en latens på 1.84 ms. Och BM.Standard var den bäst presterande konfigurationen till cirka XNUMXK IOPS innan den gick över sub-millisekunders latens och nådde en topp på XNUMX XNUMX IOPS med en latens på XNUMXms.
Med NVMe på 4K-skrivning överträffade BM återigen VM:n med båda med under-millisekunders latensprestanda hela tiden. VM.DenseIO nådde en topp på 412,207 141 IOPS med en latens på 3,232,215μs. BM.DenseIO nådde en topp på 125 XNUMX XNUMX IOPS med en latens på XNUMX μs.
Går vi vidare till sekventiellt arbete, först tittar vi på 64K läsning för BV. Både VM.Standard och VM.DenseIO bröt 1ms latens vid cirka 15.5K IOPS eller 968MB/s. Och båda bibehöll mer eller mindre samma prestanda när latensen klättrade till 8.2 ms. Återigen såg vi något liknande med BM.Standard och BM.DenseIO som båda bröt 1ms vid cirka 37.5K IOPS eller 2.35GB/s. Båda konfigurationerna nådde en topp strax norr om 47K IOPS eller 2.95 GB/s vid 8.4ms latens.
NVMe sekventiell 64K-läsning hade båda konfigurationerna förbli under sub-millisekunders latens hela tiden. VM.DenseIO nådde en topp på 39,512 2.5 IOPS eller 403 GB/s med en latens på 323,879 μs, medan BM.DenseIO nådde en topp på 20.2 361 IOPS eller XNUMX GB/s med en latens på XNUMX μs.
Med 64K sekventiell skrivning för BV ser vi återigen ett liknande fenomen med VM.Standard och VM.DenseIO som båda bryter 1ms latens med en prestanda på 12K IOPS eller 770MB/s. Båda toppade runt 15.1K IOPS eller 943MB/s med en latens på 3.1ms. Med BM.Standard och BM.DenseIO bröt båda 1ms latens vid cirka 42K IOPS eller 2.6GB/s med BM.DenseIO som toppade på 46,768 2.92 IOPS eller 2.6GB/s med 46,787ms latens. BM.Standard nådde en topp på 2.92 3.4 IOPS eller XNUMX GB/s med en latens på XNUMX ms.
För 64K sekventiella skrivningar för NVMe hade både VM.DenseIO och BM.DenseIO sub-millisekunders latensprestanda igen, men båda drabbades också av en spik i latens (tillsammans med en slutlig minskning av prestanda för BM.DenseIO). VM.DenseIO nådde en topp på 25K IOPS eller 1.56GB/s med en latens på 311μs efter en spik upp till 754μs. BM.DenseIO hade mycket bättre toppprestanda (160,895 10.1 IOPS eller 170 GB/s med en latens på 132,192 μs), men den släppte en del i slutet med en uppåtgående latens också, och slutade på 8.8 310 IOPS eller XNUMX GB/s med en latens på XNUMXμs.
I vår SQL-arbetsbelastning för BV var VM.Standard den första som gick över 1 ms vid ungefär 50 73,259 IOPS, den nådde en topp på 3.4 1 IOPS med en latens på 58 ms. VM.DenseIO gick över 78,624ms latens vid cirka 3.1K IOPS och toppade på 1 275 IOPS med en latens på 305,368ms. Med BMs stannade båda under 1.7 ms i latens till cirka 307,979K (med BM.DenseIO som körde lite längre). BM.Standard nådde en topp på 1.35 XNUMX IOPS med XNUMX ms latens medan BM.DenseIO nådde en topp på XNUMX XNUMX IOPS med XNUMX ms latens.
SQL för NVMe hade återigen under millisekunders latens genomgående med VM.DenseIO som toppade på 188,786 167 IOPS med 1,684,869 μs. BM.DenseIO nådde en topp på 142 XNUMX XNUMX IOPS med en latens på XNUMXμs.
I SQL 90-10-riktmärket för BV bröt båda virtuella datorerna fördröjningsprestanda under millisekunder vid cirka 58K IOPS. VM.Standard nådde en topp på 71,691 3.5 IOPS med en latens på 79,033 ms. VM.DenseIO nådde en topp på 3.05 1 IOPS med en latens på 270 ms. BM.Standard bröt 303,904ms latens med en prestanda på ungefär 1.7K IOPS och nådde en topp på 290 307,472 IOPS med en latens på 1.34ms. BM.DenseIO hade en fördröjning på under millisekunder till cirka XNUMX XNUMX IOPS och nådde en topp på XNUMX XNUMX IOPS med en latens på XNUMX ms.
För NVMe SQL 90-10 nådde VM.DenseIO en topp på 172,693 182 IOPS med en latens på 1,328,437μs. BM.DenseIO nådde en topp på 165 XNUMX XNUMX IOPS med XNUMX μs.
I SQL 80-20 benchmark för BV, nådde VM.Standard cirka 54K IOPS innan den gick över 1ms och nådde en topp på 72,204 3.4 IOPS med en latens på 59ms. VM.DenseIO hade en fördröjning på under millisekunder fram till cirka 78,787 2.99 IOPS och nådde en topp på 280 1 IOPS med en latens på 300,014 ms. BM.Standard körde till cirka 1.6K IOPS med latens under 1ms och toppade på 285 299,730 IOPS med en latens på 1.3ms. BM.DenseIO bröt XNUMX ms latens vid cirka XNUMX XNUMX IOPS och nådde en topp på XNUMX XNUMX IOPS med XNUMX ms latens innan den sjönk i prestanda.
I SQL 80-20 benchmark för NVMe nådde VM.DenseIO en topp på 144,010 218 IOPS med en latens på 1,114,056μs. BM.DenseIO nådde en topp på 182 XNUMX XNUMX IOPS med en latens på XNUMX μs innan den hade en liten nedgång i prestanda.
I vår Oracle-arbetsbelastning med BV hade VM.Standard fördröjningsprestanda under millisekunder tills den nådde cirka 52K IOPS och toppade på 70,096 3.4 IOPS med en latens på 1ms. VM.DenseIO bröt 58ms latens vid ungefär 75,000K IOPS och nådde en topp på 3.1 1 IOPS med en latens på 255ms. BM.Standard bröt 280,599ms latens runt 1.41K med en toppprestanda på 260 267,632 IOPS med en latens på 1.3ms. BM.DenseIO hade en fördröjning på under millisekunder till cirka XNUMX XNUMX IOPS och nådde en topp på XNUMX XNUMX IOPS med en latens på XNUMX ms.
Vår Oracle-arbetsbelastning med NVMe visade en toppprestanda för VM.DenseIO på 132,553 257 IOPS med en latens på 1,043,104 μs. Med BM.DenseIO var toppprestandan 199 XNUMX XNUMX IOPS och en latens på XNUMX μs.
I Oracle 90-10 för BV hade VM.Standard en fördröjning på under millisekunder till drygt 54K IOPS och nådde en topp på 72,533 2.2 IOPS med en latens på 1ms. VM.DenseIO bröt 61ms latens vid ungefär 76,908K IOPS och nådde en topp på 1.86 297 IOPS med en latens på 1ms. Båda BM:erna kom till 305,771K IOPS innan de bröt 1.17ms latens. BM.Standard nådde en topp på 297,509 1.03 IOPS med en latens på XNUMX ms. BM.DenseIO hade en toppprestanda på XNUMX XNUMX IOPS med en latens på XNUMX ms.
I Oracle 90-10 för NVMe hade VM.DenseIO en toppprestanda på 133,330 163 IOPS och en latens på 1,088,454 μs. BM.DenseIO hade en toppprestanda på 142 XNUMX XNUMX IOPS och en latens på XNUMX μs.
I Oracle 80-20 med BV nådde VM.Standard cirka 55K på mindre än 1ms och nådde en topp på 74,032 2.14 IOPS med en latens på 51ms. VM.DenseIO hade en fördröjning på under millisekunder till cirka 75,666K och nådde en topp på 2 295 IOPS med en latens på 1ms. Båda BM:erna klarade sig till cirka 306,955K IOPS innan de bröt 1.14ms. BM.Standard nådde en topp på 295 893 IOPS med en latens på XNUMX ms. BM.DenseIO nådde en topp på cirka XNUMXK IOPS med en latens på XNUMXμs.
I Oracle 80-20 med NVMe nådde VM.DenseIO en topp på 108,483 195 IOPS med en latens på 956,326μs. BM.DenseIO nådde en topp på 158 XNUMX IOPS med en latens på XNUMXμs.
Därefter tittade vi på VDI Full Clone. För uppstarten med BV bröt VM.Standard 1ms strax under 40K IOPS och nådde en topp på 56,057 4.2 IOPS med en latens på 43ms. VM.DenseIO gjorde det med en fördröjning på under millisekunder till ungefär 61,570K IOPS och nådde en topp på 3.6 200 IOPS med en latens på 220 ms. Båda BMs hade sub-millisekunders latens tills strax över 2.1K IOPS-tröskeln. Båda nådde en topp på cirka XNUMX XNUMX IOPS med en latens på XNUMX innan de sjönk i prestanda.
För Full Clone-start med NVMe nådde VM.DenseIO en topp på cirka 136K IOPS med en latens på 235μs. BM.DenseIO nådde en topp på 1,032,322 213 XNUMX IOPS med en latens på XNUMXμs.
Med VDI Full Clone Initial Log In med BV kom båda virtuella datorerna till cirka 41K IOPS med sub-millisekunders latens, med VM.Standard som toppade på 55,522 3.7 IOPS med en latens på 59,560 ms och VMDenseIO nådde en topp på 3.6 203 IOPS med 225 ms latens. . Båda BM:erna bröt fördröjningen under millisekunder precis runt 2.04K IOPS (med standard före tät). BM.Standard nådde en topp på cirka 224,385 1.8 IOPS med XNUMX ms latens och BM.DenseIO nådde en topp på XNUMX XNUMX IOPS med en latens på XNUMX ms.
För VDI Full Clone Initial Login med NVMe nådde VM.Standard en topp på 59,883 506 IOPS med en latens på 467,761μs. Och BM.DenseIO nådde en topp på 262 XNUMX IOPS med en latens på XNUMXμs.
VDI Full Clone Monday Login med BV hade VM.Standard med sub-millisekunders latens tills det bara var 36K IOPS med en topp på 50,685 2.3 IOPS och en latens på 1ms. VM.DenseIO presterade under 38 ms till strax norr om 53,304K IOPS och nådde en topp på 2.2 1 IOPS med 205 ms latens. BM.Standard bröt 224,764ms latens vid cirka 1.5K IOPS och toppade på 1 210 IOPS med en latens på 220ms. BM.DenseIO gick över 1.2ms runt XNUMXK med en topp på drygt XNUMXK IOPS och en latens på XNUMXms.
VDI Full Clone Monday Login med NVMe visade en toppprestanda för VM.DenseIO på 44,384 356 IOPS med en latens på 356,691μs. BM.DenseIO nådde en topp på 252 XNUMX IOPS med en latens på XNUMXμs.
Vårt slutliga urval av tester tittar på VDI Linked Clone. Från och med starttestet med BV, hade VM.Standard en fördröjning på under millisekunder till cirka 29K IOPS, och nådde en topp på cirka 38K IOPS med 2.4ms latens. VM.DenseIO klarade sig till cirka 32K IOPS innan den bröt 1ms och nådde en topp på cirka 38K IOPS också med 2.16ms latens. Båda BM:erna kom till ungefär 100K IOPS innan de gick över 1ms latens. Båda hade en toppprestanda på cirka 114K IOPS med 3ms latens.
Med VDI Linked Clone Boot för NVMe såg vi VM.DenseIO-toppen vid 65,384 238 IOPS med en latens på 555,004μs. BM.DenseIO nådde en topp på 217 XNUMX IOPS med en latens på XNUMXμs.
Med Initial Login med BV bröt båda virtuella datorerna 1 ms latens vid ungefär 28K IOPS, med VM.Standard som toppade på 36,682 1.6 IOPS med en latens på 38,525 ms och VM.DenseIO toppade vid 1.6 1 IOPS med en latens på 132 ms. Båda BM:arna bröt 140,848 ms latens vid cirka 1.3K IOPS med BM.Standard som toppade på 139,883 1.2 IOPS med en latens på XNUMX ms och BM.DenseIO toppade vid XNUMX XNUMX IOPS och XNUMX ms latens.
Initial inloggning med NVMe såg en toppprestanda på 24,228 326 IOPS och 242,778 μs för VM.DenseIO och 234 XNUMX IOPS med XNUMX μs för BM.DenseIO.
Slutligen, med VDI Linked Clone Monday Login med BV, hade VM.Standard en latensprestanda på under millisekunder fram till cirka 27K IOPS med en topp på 39,874 2.86 IOPS och en latens på 1ms. VM.DenseIO bröt 25ms vid cirka 42,469K IOPS och nådde en topp på 3 135 IOPS och 146ms latens. Båda BM:erna hade en fördröjning på under millisekunder till cirka 1.6K IOPS med båda topparna på 1.76K IOPS, denseIO hade en latens på XNUMX ms och standarden hade en latens på XNUMX ms.
Med VDI Linked Clone Monday Login med NVMe nådde VM.DenseIO en topp på 34,016 464 IOPS och en latens på 260,527μs. BM.DenseIO nådde en topp på 317 XNUMX IOPS och en latens på XNUMX μs.
Slutsats
Oracles molninfrastruktur tar ett av huvudproblemen med molnet – prestanda eller avsaknad därav – och löser det med sina instanser av bara metall. Oracle erbjuder blankmetall- och virtuella beräkningsinstanser samt NVMe-versioner med upp till 25 TB NVMe-lagring för prestanda som inte liknar något annat som setts i molnet. Det krävs mer än NVMe-lagring för att nå Oracles noterade prestanda på upp till 5.1 miljoner IOPS; instanserna har också upp till 52 OCPU, 768 GB RAM, dubbla 25 GbE NIC och upp till 51 TB lokalt ansluten NVMe-lagring. Denna prestandanivå används främst för användningsfall som verksamhetskritiska databasapplikationer, HPC-arbetsbelastningar och I/O-intensiva webbapplikationer.
På prestandasidan körde vi våra VDBech-tester för både blankmetall (BM) och VM-former med både lokal NVMe-lagring (DenseIO) och nätverksblocklagring (Standard). Prestationen, enkelt uttryckt, blåste bort oss. För varje test körde vi två uppsättningar diagram, eftersom latensskillnaden mellan DenseIO och Standard var så stor att diagrammen skulle vara svåra att läsa om alla var på en uppsättning. När det gäller hur bra lagringsprestanda på dessa instanser är jämfört med traditionell lagring, konkurrerar de med många av de bästa delade lagringsalternativen på marknaden, än mindre molnalternativ. De bifogade BV:erna som är värd för iSCSI och säkerhetskopieras erbjuder en stark blandning av genomströmning och bandbredd som serveras med låg latens. För att sätta detta i sitt sammanhang såg vi många tester med 32 BV:er anslutna på de 52 OCPU-instanserna som överträffade prestandan för all-flash-lagringsmatriser som vi har testat i vårt labb. Vissa kan faktiskt ha varit något snabbare, vilket är ganska imponerande med tanke på att vi jämför en molninstans med en $250k+ AFA, FC-växling och flera datorvärdar.
Det som dock gör Oracle Cloud-bara metall-instanserna verkligen otroliga är den lokalt anslutna NVMe-lagringen. DenseIO2.8 hade 1 enhet, medan DenseIO2.52 hade 8, vilket ger dessa instanser prestanda mätt i miljontals IOPS. Förekomsten med 1 NVMe SSD såg en slumpmässig 4K-läshastighet på 569k IOPS, medan instansen med 8 hade prestanda skjutit i höjden till 4.4M IOPS. Bandbredd var heller inget skämt; den mindre instansen såg 2.5 GB/s avläsningstopp, medan den större toppade över 20 GB/s. Se till att ha en backupplan på plats, eftersom NVMe-formerna trots allt är lokalt ansluten lagring som måste skyddas.
Oracle har byggt ut toppspecifika servrar och lagring i molnet; det enda som kan konkurrera med deras bare metal-instanser är att bygga ut en top-spec server som är värd lokalt, tillsammans med alla andra komponenter och tjänster för att stödja den. Som med alla molnlösningar erbjuder Oracle smidigheten att slå på och av dina instanser och flexibilitet för att justera lagringskraven efter behov. Med dessa fall är den uppenbara frågan som kommer upp kostnaden. Lämpligheten av att få en instans online inom Oracle Cloud jämfört med ansträngningen och kostnaden som krävs för att installera jämförbar hårdvara i ditt eget datacenter, är kanske den avgörande faktorn. Även om NVMe-ansluten lagring är dyr, finns det inga bråk med prestandafördelarna som vi såg. Om du har ett företag som påverkas av behandlingstiden för stora datamängder, finns det ingen enklare eller snabbare lösning för att få arbetsbelastningar som analys kompletta än de NVMe-baserade former vi använde. Och det är inte så att de vanliga bifogade blockformerna var dåliga, NVMe-formerna var bara så overkliga att de överskuggade resten. Summan av kardemumman är att framtidstänkande företag som kan hämta mätbart värde från högpresterande moln definitivt borde utvärdera vad Oracle har på gång. Det finns många val när man går till molnet, men det finns inget som är så snabbt som det vi har sett med Oracle Clouds bare metal-instanser, vilket gör dessa lösningar till en tydlig och välförtjänt vinnare av vår första Editor's Choice Award som beviljats en molntjänst leverantör.
Amazon