L'infrastruttura Oracle Cloud include un'ampia varietà di offerte di servizi tra cui elaborazione, archiviazione, rete, database e bilanciamento del carico: in effetti, tutta l'infrastruttura necessaria per costruire un data center basato su cloud. Nel contesto di questa recensione, siamo interessati alla categoria Oracle Cloud Infrastructure Compute, con un focus molto specifico sulle istanze bare metal. Come la maggior parte dei fornitori di servizi cloud, Oracle offre istanze di elaborazione virtualizzate, ma a differenza della maggior parte delle altre offerte virtuali, Oracle può supportarle con forme che contengono fino a ~25 TB di spazio di archiviazione NVMe per applicazioni che necessitano di bassa latenza. Per quanto eccezionali, Oracle ha ulteriormente alzato la posta in termini di prestazioni di cloud computing offrendo le prime istanze bare metal ad alte prestazioni del settore, ideali per applicazioni mission-critical in cui la latenza è fondamentale. Le istanze vengono fornite con un massimo di 52 OCPU, 768 GB di RAM, due NIC da 25 GbE e fino a 51 TB di spazio di archiviazione NVMe collegato localmente. Per coloro che desiderano di più, sono disponibili fino a 512 TB di spazio di archiviazione a blocchi NVMe collegato in rete, nonché opzioni GPU. Tutte le diverse offerte di elaborazione Oracle vengono eseguite su una rete definita dal software altamente ottimizzata, ottimizzata per ridurre al minimo i conflitti e massimizzare le prestazioni.
L'infrastruttura Oracle Cloud include un'ampia varietà di offerte di servizi tra cui elaborazione, archiviazione, rete, database e bilanciamento del carico: in effetti, tutta l'infrastruttura necessaria per costruire un data center basato su cloud. Nel contesto di questa recensione, siamo interessati alla categoria Oracle Cloud Infrastructure Compute, con un focus molto specifico sulle istanze bare metal. Come la maggior parte dei provider cloud, Oracle offre istanze di elaborazione virtualizzate, ma a differenza della maggior parte delle altre offerte virtuali, Oracle può supportarle con forme che contengono fino a circa 25 TB di spazio di archiviazione NVMe per applicazioni che necessitano di bassa latenza. Per quanto eccezionali, Oracle ha ulteriormente alzato la posta in termini di prestazioni di cloud computing offrendo le prime istanze bare metal ad alte prestazioni del settore, ideali per applicazioni mission-critical in cui la latenza è fondamentale. Le istanze vengono fornite con un massimo di 52 OCPU, 768 GB di RAM, due NIC da 25 GbE e fino a 51 TB di spazio di archiviazione NVMe collegato localmente. Per coloro che desiderano di più, sono disponibili fino a 512 TB di spazio di archiviazione a blocchi NVMe collegato in rete, nonché opzioni GPU. Tutte le diverse offerte di elaborazione Oracle vengono eseguite su una rete definita dal software altamente ottimizzata, ottimizzata per ridurre al minimo i conflitti e massimizzare le prestazioni.
Esiste un'ampia varietà di offerte cloud a questo punto e anche diverse offerte cloud di grandi dimensioni con AWS, Google Cloud Platform e Microsoft Azure in cima all'elenco. Sebbene questi fornitori di servizi cloud offrano molti ottimi prodotti e servizi, una cosa che in genere non hanno sono le prestazioni. Quando si confronta il cloud con quello on-premise, l'on-premise batte sempre il cloud. Oracle sta cercando di cambiare questa visione con le sue offerte di infrastruttura cloud.
Le offerte di elaborazione di Oracle presentano le promesse che ci si aspetterebbe dallo storage o dai server on-premise, tra cui prestazioni, disponibilità, versatilità e governance. Il lato delle prestazioni supporta prestazioni massime e costanti per le applicazioni mission-critical ed è supportato da recentemente annunciato lo SLA per l'infrastruttura cloud end-to-end, che al momento della stesura di questo articolo è l'unico simile nel settore. L'offerta supporta la disponibilità a più livelli, tra cui DNS, bilanciamento del carico, replica, backup, snapshot di archiviazione e clustering. Le offerte di elaborazione spaziano da una VM single core al bare metal single-tenant a 52 core, offrendo la versatilità necessaria per eseguire qualsiasi cosa, dai carichi di lavoro comuni ai cluster HPC. E con le istanze bare metal di Oracle, i clienti ottengono l'isolamento e il controllo di un server on-prem, poiché non contengono altri tenant e nessun software del provider Oracle.
Le offerte di elaborazione di Oracle Cloud sono disponibili in diverse "forme", tra cui istanze bare metal, istanze GPU bare metal e istanze VM. Per questa recensione esamineremo le istanze bare metal, che secondo Oracle possono fornire fino a 5.1 milioni di IOPS e sono destinate a casi d'uso come applicazioni di database mission-critical, carichi di lavoro HPC e applicazioni Web ad uso intensivo di I/O. Per confronto, mostreremo anche le forme VM di Oracle, con storage NVMe locale (DenseIO) e con storage a blocchi di rete (Standard).
Management
La GUI di gestione per Oracle Cloud Infrastructure è abbastanza semplice da capire. La pagina principale contiene procedure dettagliate e assistenza, se necessario. Nella parte superiore sono presenti la locazione o l'account, la regione utilizzata (us-ashburn-1, nel nostro caso), insieme alle schede per Home (che è la pagina principale), Identità, Calcolo, Database, Rete, Archiviazione, Controllo ed e-mail. Per i nostri test, vengono mostrati DenseIO2 e Standard2.
Poiché questa recensione si concentra sul lato calcolo, guardando sotto quella scheda possiamo vedere le istanze che utilizzeremo per i nostri test delle prestazioni. Ogni istanza ha il proprio nome, forma, regione, dominio di disponibilità e data di creazione. Sul lato sinistro, gli utenti possono modificare l'elenco selezionando lo stato, ad esempio "in esecuzione".
Facendo clic sui puntini di sospensione sul lato destro è possibile approfondire un po' l'istanza. Osservando BM.DenseIO2.52, si può facilmente vedere se l'istanza è in esecuzione e informazioni più approfondite al riguardo. Anche qui è possibile associarvi dei tag. Nella parte superiore delle informazioni è presente la possibilità di creare un'immagine personalizzata, avviare, arrestare o riavviare l'istanza, terminarla o applicare tag. Scorrendo verso il basso è possibile allegare anche volumi a blocchi.
Nella scheda Rete, è possibile vedere la rete cloud virtuale utilizzata o crearne una. Per la VCN sono disponibili informazioni quali regione, tabella di routing predefinita, dominio DNS e data di creazione. Ancora una volta, i puntini di sospensione a destra consentono di eseguire il drill-down, applicare tag e creare una sottorete.
Nella scheda Archiviazione, gli utenti possono vedere i volumi dei blocchi nel proprio scomparto e crearne altri. I volumi a blocchi sono elencati per data di creazione e gli utenti possono approfondire per ulteriori informazioni, creare backup manuali, scollegare il volume a blocchi dall'istanza, eliminare il volume o applicare tag.
E come implica Audit, è possibile esaminare rapidamente gli eventi passati selezionando la data e l'intervallo di tempo. Ciò consente alle aziende di soddisfare le esigenze di conformità gestionale in cui vengono catturati l'utente e l'azione per ogni evento o modifica all'ambiente.
Performance
Analisi del carico di lavoro VDBench
Per valutare le prestazioni di queste istanze Oracle Cloud, abbiamo sfruttato vdbench installato localmente su ciascuna piattaforma. I nostri test sono stati distribuiti su tutto lo spazio di archiviazione locale contemporaneamente, quindi se erano presenti sia lo spazio di archiviazione BV (Block Volume) che NVMe, abbiamo testato un gruppo alla volta. 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
- Clonazione completa VDI e tracce di clonazione collegata
Esaminiamo sia i dispositivi a blocchi remoti (BV) che NVMe. Dato che c'è una differenza di prestazioni così drammatica, abbiamo separato i risultati in due grafici (la latenza sarebbe così distante che i grafici sarebbero molto difficili da leggere). Per questa recensione esaminiamo sia le configurazioni Bare Metal (BM) che quelle VM con operazioni di IO sia standard che dense su BV e solo operazioni di IO dense per NVMe.
Osservando il picco di lettura 4K per BV, tutte e quattro le sessioni sono iniziate con una forte latenza inferiore al millisecondo. Il primo a staccarsi è stato il VM.Standard, arrivando a poco meno di 53 IOPS, per poi raggiungere un picco di 60,591 IOPS con una latenza di 15 ms. Il successivo a rompere la latenza inferiore al millisecondo è stato il VM.DenseIO, che è andato oltre 1 ms più o meno nello stesso punto dello standard, ma con un picco di 72,626 IOPS con una latenza di 7.5 ms. Entrambe le esecuzioni bare metal hanno funzionato molto meglio con DenseIO che ha eseguito prestazioni di latenza inferiore al millisecondo fino a circa 235 IOPS, con un picco di 252,275 IOPS con una latenza di 4.1 ms. Il BM.Standard è arrivato fino a circa 250 IOPS prima di superare 1 ms e ha raggiunto il picco di 258,329 IOPS con una latenza di 4.05 ms.
Osservando le prestazioni di lettura di picco in 4K per NVMe, entrambe le esecuzioni hanno avuto una latenza inferiore al millisecondo. Il VM.DenseIO ha raggiunto il picco di 569,534 IOPS con una latenza di 214μs. Il BM.DenseIO ha raggiunto il picco di 4,419,490 IOPS con una latenza di soli 174.6 μs.
Passando alle prestazioni di picco in scrittura 4K casuali per BV, vediamo un posizionamento simile a prima con le VM che raggiungono il picco molto prima dei BM. Il VM.Standard è arrivato a circa 63 IOPS prima di interrompere la latenza inferiore al millisecondo e ha raggiunto il picco di 77,229 IOPS con una latenza di 5.3 ms. VM.DenseIO ha ottenuto risultati leggermente migliori, raggiungendo circa 69 IOPS prima di superare 1 ms e raggiungendo il picco a 84,274 IOPS con una latenza di 3.9 ms. BM.DenseIO è riuscito a raggiungere oltre 263 IOPS prima di superare 1 ms di latenza e raggiungere il picco di 280,158 IOPS con una latenza di 2.02 ms. E BM.Standard è stata la configurazione con le prestazioni più elevate, raggiungendo circa 278 IOPS prima di superare una latenza inferiore al millisecondo e raggiungere il picco di 280,844 IOPS con una latenza di 1.84 ms.
Con NVMe in scrittura 4K, ancora una volta il BM ha sovraperformato la VM con entrambi con prestazioni di latenza inferiori al millisecondo. Il VM.DenseIO ha raggiunto il picco di 412,207 IOPS con una latenza di 141μs. Il BM.DenseIO ha raggiunto il picco di 3,232,215 IOPS con una latenza di 125μs.
Passando al lavoro sequenziale, esaminiamo prima la lettura di 64K per BV. Sia VM.Standard che VM.DenseIO hanno superato la latenza di 1 ms a circa 15.5K IOPS o 968 MB/s. Ed entrambi hanno mantenuto più o meno le stesse prestazioni mentre la latenza è salita a 8.2 ms. Ancora una volta abbiamo riscontrato qualcosa di simile con BM.Standard e BM.DenseIO che hanno entrambi superato 1 ms a circa 37.5K IOPS o 2.35 GB/s. Entrambe le configurazioni hanno raggiunto il picco appena a nord di 47 IOPS o 2.95 GB/s con una latenza di 8.4 ms.
La lettura sequenziale di 64K NVMe ha fatto sì che entrambe le configurazioni rimanessero al di sotto della latenza inferiore al millisecondo per tutto il tempo. Il VM.DenseIO ha raggiunto il picco di 39,512 IOPS o 2.5 GB/s con una latenza di 403 μs, mentre il BM.DenseIO ha raggiunto il picco di 323,879 IOPS o 20.2 GB/s con una latenza di 361 μs.
Con le scritture sequenziali da 64K per BV, vediamo nuovamente un fenomeno simile con VM.Standard e VM.DenseIO che interrompono entrambi la latenza di 1 ms con prestazioni di 12K IOPS o 770 MB/s. Entrambi hanno raggiunto un picco di circa 15.1K IOPS o 943 MB/s con una latenza di 3.1 ms. Con BM.Standard e BM.DenseIO entrambi hanno superato la latenza di 1 ms a circa 42 IOPS o 2.6 GB/s, mentre il BM.DenseIO ha raggiunto un picco di 46,768 IOPS o 2.92 GB/s con una latenza di 2.6 ms. Il BM.Standard ha raggiunto il picco di 46,787 IOPS o 2.92 GB/s con una latenza di 3.4 ms.
Per le scritture sequenziali a 64K per NVMe, sia VM.DenseIO che BM.DenseIO hanno avuto nuovamente prestazioni di latenza inferiori al millisecondo, ma entrambi hanno subito anche un picco di latenza (unito a una riduzione finale delle prestazioni per BM.DenseIO). Il VM.DenseIO ha raggiunto il picco di 25K IOPS o 1.56GB/s con una latenza di 311μs dopo un picco fino a 754μs. Il BM.DenseIO ha avuto prestazioni di picco molto migliori (160,895 IOPS o 10.1 GB/s con una latenza di 170 μs), ma alla fine è diminuita leggermente con un aumento anche della latenza, finendo a 132,192 IOPS o 8.8 GB/s con una latenza di 310μs.
Nel nostro carico di lavoro SQL per BV, VM.Standard è stato il primo a superare 1 ms a circa 50 IOPS, raggiungendo un picco di 73,259 IOPS con una latenza di 3.4 ms. VM.DenseIO ha superato la latenza di 1 ms a circa 58 IOPS e ha raggiunto il picco di 78,624 IOPS con una latenza di 3.1 ms. Con i BM, entrambi sono rimasti sotto 1 ms di latenza fino a circa 275K (con BM.DenseIO che funzionava un po' più a lungo). Il BM.Standard ha raggiunto il picco di 305,368 IOPS con una latenza di 1.7 ms mentre il BM.DenseIO ha raggiunto il picco di 307,979 IOPS con una latenza di 1.35 ms.
SQL per NVMe ha avuto ancora una volta una latenza inferiore al millisecondo con un picco di VM.DenseIO a 188,786 IOPS con 167μs. Il BM.DenseIO ha raggiunto il picco di 1,684,869 IOPS con una latenza di 142μs.
Nel benchmark SQL 90-10 per BV, entrambe le VM hanno superato le prestazioni di latenza inferiore al millisecondo a circa 58 IOPS. Il VM.Standard ha raggiunto il picco di 71,691 IOPS con una latenza di 3.5 ms. Il VM.DenseIO ha raggiunto il picco di 79,033 IOPS con una latenza di 3.05 ms. Il BM.Standard ha superato la latenza di 1 ms con una prestazione di circa 270 IOPS e ha raggiunto il picco di 303,904 IOPS con una latenza di 1.7 ms. Il BM.DenseIO ha avuto una latenza inferiore al millisecondo fino a circa 290 IOPS e ha raggiunto il picco a 307,472 IOPS con una latenza di 1.34 ms.
Per NVMe SQL 90-10, VM.DenseIO ha raggiunto il picco di 172,693 IOPS con una latenza di 182μs. Il BM.DenseIO ha raggiunto il picco di 1,328,437 IOPS con 165μs.
Nel benchmark SQL 80-20 per BV, VM.Standard è arrivato a circa 54 IOPS prima di superare 1 ms e raggiungere il picco di 72,204 IOPS con una latenza di 3.4 ms. VM.DenseIO ha avuto una latenza inferiore al millisecondo fino a circa 59 IOPS e ha raggiunto un picco di 78,787 IOPS con una latenza di 2.99 ms. Il BM.Standard ha raggiunto circa 280 IOPS con una latenza inferiore a 1 ms e ha raggiunto il picco di 300,014 IOPS con una latenza di 1.6 ms. Il BM.DenseIO ha superato la latenza di 1 ms a circa 285 IOPS e ha raggiunto il picco a 299,730 IOPS con una latenza di 1.3 ms prima di diminuire in termini di prestazioni.
Nel benchmark SQL 80-20 per NVMe, VM.DenseIO ha raggiunto il picco di 144,010 IOPS con una latenza di 218μs. Il BM.DenseIO ha raggiunto il picco di 1,114,056 IOPS con una latenza di 182μs prima di riscontrare un leggero calo delle prestazioni.
Nel nostro carico di lavoro Oracle con BV, VM.Standard ha registrato prestazioni di latenza inferiori al millisecondo fino a raggiungere circa 52 IOPS e un picco di 70,096 IOPS con una latenza di 3.4 ms. VM.DenseIO ha superato la latenza di 1 ms a circa 58 IOPS e ha raggiunto il picco di 75,000 IOPS con una latenza di 3.1 ms. BM.Standard ha superato la latenza di 1 ms intorno a 255 con una prestazione di picco di 280,599 IOPS con una latenza di 1.41 ms. BM.DenseIO ha avuto una latenza inferiore al millisecondo fino a circa 260 IOPS e ha raggiunto il picco a 267,632 IOPS con una latenza di 1.3 ms.
Il nostro carico di lavoro Oracle con NVMe ha mostrato prestazioni di picco per VM.DenseIO di 132,553 IOPS con una latenza di 257μs. Con BM.DenseIO la prestazione di picco è stata di 1,043,104 IOPS e una latenza di 199μs.
In Oracle 90-10 per BV, VM.Standard aveva una latenza inferiore al millisecondo fino a poco più di 54 IOPS e raggiungeva un picco di 72,533 IOPS con una latenza di 2.2 ms. VM.DenseIO ha superato la latenza di 1 ms a circa 61 IOPS e ha raggiunto il picco a 76,908 IOPS con una latenza di 1.86 ms. Entrambi i BM sono riusciti a raggiungere 297 IOPS prima di superare 1 ms di latenza. Il BM.Standard ha raggiunto il picco di 305,771 IOPS con una latenza di 1.17 ms. Il BM.DenseIO ha avuto una prestazione di picco di 297,509 IOPS con una latenza di 1.03 ms.
Nell'Oracle 90-10 per NVMe, VM.DenseIO ha avuto una prestazione di picco di 133,330 IOPS e una latenza di 163μs. Il BM.DenseIO ha avuto una prestazione di picco di 1,088,454 IOPS e una latenza di 142μs.
Nell'Oracle 80-20 con BV, VM.Standard è arrivato a circa 55 in meno di 1 ms e ha raggiunto il picco di 74,032 IOPS con una latenza di 2.14 ms. VM.DenseIO ha avuto una latenza inferiore al millisecondo fino a circa 51K e ha raggiunto il picco a 75,666 IOPS con una latenza di 2 ms. Entrambi i BM sono riusciti a raggiungere circa 295 IOPS prima di superare 1 ms. Il BM.Standard ha raggiunto il picco di 306,955 IOPS con una latenza di 1.14 ms. Il BM.DenseIO ha raggiunto il picco a circa 295 IOPS con una latenza di 893μs.
Nell'Oracle 80-20 con NVMe, VM.DenseIO ha raggiunto il picco di 108,483 IOPS con una latenza di 195μs. Il BM.DenseIO ha raggiunto il picco di 956,326 IOPS con una latenza di 158μs.
Successivamente abbiamo esaminato VDI Full Clone. Per l'avvio con BV, VM.Standard ha superato 1 ms appena sotto i 40 IOPS e ha raggiunto il picco di 56,057 IOPS con una latenza di 4.2 ms. VM.DenseIO ce l'ha fatta con una latenza inferiore al millisecondo fino a circa 43 IOPS e ha raggiunto il picco di 61,570 IOPS con una latenza di 3.6 ms. Entrambi i BM hanno avuto una latenza inferiore al millisecondo fino a poco oltre la soglia di 200 IOPS. Entrambi hanno raggiunto il picco di circa 220 IOPS con una latenza di 2.1 prima di diminuire in termini di prestazioni.
Per l'avvio Full Clone con NVMe, VM.DenseIO ha raggiunto il picco di circa 136 IOPS con una latenza di 235μs. Il BM.DenseIO ha raggiunto il picco di 1,032,322 IOPS con una latenza di 213μs.
Con l'accesso iniziale VDI Full Clone con BV, entrambe le VM hanno raggiunto circa 41 IOPS con una latenza inferiore al millisecondo, con VM.Standard che ha raggiunto un picco di 55,522 IOPS con una latenza di 3.7 ms e VMDenseIO che ha raggiunto un picco di 59,560 IOPS con una latenza di 3.6 ms. . Entrambi i BM hanno rotto la latenza inferiore al millisecondo intorno ai 203 IOPS (con lo standard che precede la densità). BM.Standard ha raggiunto il picco a circa 225 IOPS con una latenza di 2.04 ms mentre BM.DenseIO ha raggiunto il picco a 224,385 IOPS con una latenza di 1.8 ms.
Per l'accesso iniziale VDI Full Clone con NVMe, VM.Standard ha raggiunto il picco di 59,883 IOPS con una latenza di 506μs. E BM.DenseIO ha raggiunto il picco di 467,761 IOPS con una latenza di 262μs.
VDI Full Clone Monday Login con BV aveva VM.Standard con latenza inferiore al millisecondo fino a poco meno di 36 IOPS con un picco di 50,685 IOPS e una latenza di 2.3 ms. VM.DenseIO ha funzionato in meno di 1 ms fino a poco più di 38 IOPS e ha raggiunto il picco di 53,304 IOPS con una latenza di 2.2 ms. BM.Standard ha superato la latenza di 1 ms a circa 205 IOPS e ha raggiunto il picco a 224,764 IOPS con una latenza di 1.5 ms. BM.DenseIO è andato oltre 1 ms intorno a 210 con un picco di poco più di 220 IOPS e una latenza di 1.2 ms.
VDI Full Clone Monday L'accesso con NVMe ha mostrato prestazioni di picco di VM.DenseIO di 44,384 IOPS con una latenza di 356μs. BM.DenseIO ha raggiunto il picco di 356,691 IOPS con una latenza di 252μs.
La nostra selezione finale di test riguarda VDI Linked Clone. Ricominciando con il test di avvio con BV, VM.Standard ha avuto una latenza inferiore al millisecondo fino a circa 29 IOPS, con un picco di circa 38 IOPS con una latenza di 2.4 ms. VM.DenseIO è arrivato fino a circa 32 IOPS prima di superare 1 ms e ha raggiunto anche il picco a circa 38 IOPS con una latenza di 2.16 ms. Entrambi i BM sono riusciti a raggiungere circa 100 IOPS prima di superare la latenza di 1 ms. Entrambi hanno registrato prestazioni di picco di circa 114 IOPS con una latenza di 3 ms.
Con VDI Linked Clone Boot per NVMe, abbiamo riscontrato il picco VM.DenseIO a 65,384 IOPS con una latenza di 238μs. Il BM.DenseIO ha raggiunto il picco di 555,004 IOPS con una latenza di 217μs.
Con l'accesso iniziale con BV, entrambe le VM hanno superato la latenza di 1 ms a circa 28 IOPS, con VM.Standard che ha raggiunto un picco di 36,682 IOPS con una latenza di 1.6 ms e VM.DenseIO che ha raggiunto un picco di 38,525 IOPS con una latenza di 1.6 ms. Entrambi i BM hanno superato la latenza di 1 ms a circa 132 IOPS, con il BM.Standard che ha raggiunto un picco di 140,848 IOPS con una latenza di 1.3 ms e il BM.DenseIO che ha raggiunto un picco di 139,883 IOPS e una latenza di 1.2 ms.
L'accesso iniziale con NVMe ha registrato prestazioni di picco di 24,228 IOPS e 326μs per VM.DenseIO e 242,778 IOPS con 234μs per BM.DenseIO.
Infine, con VDI Linked Clone Monday Login with BV, VM.Standard ha registrato prestazioni di latenza inferiori al millisecondo fino a circa 27 IOPS con un picco di 39,874 IOPS e una latenza di 2.86 ms. VM.DenseIO ha superato 1 ms a circa 25 IOPS e ha raggiunto il picco a 42,469 IOPS e una latenza di 3 ms. Entrambi i BM hanno avuto una latenza inferiore al millisecondo fino a circa 135 IOPS con entrambi un picco a 146 IOPS, il denseIO con una latenza di 1.6 ms e lo standard con una latenza di 1.76 ms.
Con VDI Linked Clone Monday Login con NVMe, VM.DenseIO ha raggiunto il picco di 34,016 IOPS e una latenza di 464μs. BM.DenseIO ha raggiunto il picco di 260,527 IOPS e una latenza di 317μs.
Conclusione
L'infrastruttura cloud di Oracle affronta uno dei problemi principali del cloud, ovvero le prestazioni o la loro mancanza, e lo risolve con le sue istanze bare metal. Oracle offre istanze bare metal e di elaborazione virtuale, nonché versioni NVMe con un massimo di 25 TB di storage NVMe per prestazioni diverse da qualsiasi altra soluzione vista nel cloud. Ci vuole più dello storage NVMe per raggiungere le prestazioni indicate da Oracle fino a 5.1 milioni di IOPS; le istanze hanno anche fino a 52 OCPU, 768 GB di RAM, doppia scheda di rete da 25 GbE e fino a 51 TB di spazio di archiviazione NVMe collegato localmente. Questo livello di prestazioni viene utilizzato principalmente per casi d'uso come applicazioni di database mission-critical, carichi di lavoro HPC e applicazioni Web ad uso intensivo di I/O.
Dal punto di vista delle prestazioni, abbiamo eseguito i nostri test VDBech sia per le forme bare metal (BM) che per quelle VM utilizzando sia lo storage NVMe locale (DenseIO) che lo storage a blocchi di rete (Standard). La performance, in poche parole, ci ha lasciato senza fiato. Per ogni test abbiamo eseguito due serie di grafici, poiché la discrepanza di latenza tra DenseIO e Standard era così grande che i grafici sarebbero difficili da leggere se fossero tutti sullo stesso set. In termini di prestazioni di archiviazione su queste istanze rispetto allo storage tradizionale, rivaleggiano con molte delle migliori opzioni di archiviazione condivisa sul mercato, per non parlare delle alternative cloud. I BV collegati ospitati su iSCSI e sottoposti a backup offrono un forte mix di throughput e larghezza di banda servito a bassa latenza. Per contestualizzare questo dato, abbiamo riscontrato che molti test con 32 BV collegati alle 52 istanze OCPU superano le prestazioni degli array di archiviazione all-flash che abbiamo testato nel nostro laboratorio. Alcuni potrebbero in realtà essere leggermente più veloci, il che è piuttosto impressionante considerando che stiamo confrontando un'istanza cloud con un AFA da $ 250, cambio FC e più host di elaborazione.
Ciò che rende le istanze bare metal di Oracle Cloud davvero incredibili, tuttavia, è lo spazio di archiviazione NVMe collegato localmente. DenseIO2.8 aveva 1 dispositivo, mentre DenseIO2.52 ne aveva 8, fornendo a queste istanze prestazioni misurate in milioni di IOPS. L'istanza con 1 SSD NVMe ha registrato una velocità di lettura casuale 4K massima pari a 569 IOPS, mentre l'istanza con 8 SSD ha registrato prestazioni alle stelle fino a 4.4 milioni di IOPS. Anche la larghezza di banda non era uno scherzo; l'istanza più piccola ha registrato un picco di lettura di 2.5 GB/s, mentre quella più grande ha superato i 20 GB/s. Assicurati di disporre di un piano di backup, poiché dopo tutto le forme NVMe sono archiviazione collegata localmente, che deve essere protetta.
Oracle ha creato server e storage di alta qualità nel cloud; l'unica cosa che può rivaleggiare con le loro istanze bare metal è costruire un server con le migliori specifiche ospitato localmente, insieme a tutti gli altri componenti e servizi per supportarlo. Come con tutte le soluzioni cloud, Oracle offre la fluidità per attivare e disattivare le istanze e la flessibilità per adattare i requisiti di storage in base alle esigenze. In questi casi, il problema ovvio che si presenterà sarà il costo. La convenienza di mettere un'istanza online all'interno di Oracle Cloud rispetto allo sforzo e alle spese necessarie per configurare hardware comparabile nel tuo data center è forse il fattore decisivo chiave. Anche se lo storage collegato NVMe è costoso, non c’è dubbio sui vantaggi prestazionali che abbiamo riscontrato. Se la tua azienda risente dei tempi di elaborazione di set di dati di grandi dimensioni, non esiste una soluzione più semplice o più veloce per completare carichi di lavoro come l'analisi rispetto alle forme basate su NVMe che abbiamo utilizzato. E non è che le forme standard dei blocchi allegati fossero pessime, le forme NVMe erano semplicemente così irreali da eclissare il resto. La conclusione è che le aziende lungimiranti che possono trarre valore misurabile dal cloud ad alte prestazioni dovrebbero sicuramente valutare ciò che Oracle sta facendo. Ci sono molte scelte quando si passa al cloud, ma non c'è niente di così veloce come quello che abbiamo visto con le istanze bare metal di Oracle Cloud, rendendo queste soluzioni chiaramente e meritevoli vincitrici del nostro primo Editor's Choice Award assegnato a un servizio cloud. fornitore.
Offerte di Oracle Cloud Compute
Iscriviti alla newsletter di StorageReview