Die Oracle Cloud Infrastructure umfasst eine Vielzahl von Serviceangeboten, darunter Rechenleistung, Speicher, Netzwerk, Datenbank und Lastausgleich – praktisch die gesamte Infrastruktur, die für den Aufbau eines cloudbasierten Rechenzentrums erforderlich ist. Im Rahmen dieser Überprüfung interessieren wir uns für die Kategorie Oracle Cloud Infrastructure Compute, mit einem ganz besonderen Fokus auf deren Bare-Metal-Instanzen. Wie die meisten Cloud-Anbieter bietet Oracle virtualisierte Recheninstanzen an, aber im Gegensatz zu den meisten anderen virtuellen Angeboten kann Oracle diese mit Formen unterstützen, die bis zu ~25 TB NVMe-Speicher für Anwendungen enthalten, die eine geringe Latenz benötigen. So großartig diese auch sind, Oracle hat die Anforderungen an die Cloud-Computing-Leistung noch weiter erhöht, indem es die ersten leistungsstarken Bare-Metal-Instanzen der Branche anbietet, ideal für geschäftskritische Anwendungen, bei denen die Latenz von größter Bedeutung ist. Instanzen verfügen über bis zu 52 OCPUs, 768 GB RAM, zwei 25-GbE-NICs und bis zu 51 TB lokal angeschlossenen NVMe-Speicher. Für diejenigen, die mehr wünschen, stehen bis zu 512 TB netzwerkgebundener NVMe-Blockspeicher sowie GPU-Optionen zur Verfügung. Alle verschiedenen Rechenangebote von Oracle laufen in einem hochoptimierten softwaredefinierten Netzwerk, das darauf abgestimmt ist, Konflikte zu minimieren und die Leistung zu maximieren.
Die Oracle Cloud Infrastructure umfasst eine Vielzahl von Serviceangeboten, darunter Rechenleistung, Speicher, Netzwerk, Datenbank und Lastausgleich – praktisch die gesamte Infrastruktur, die für den Aufbau eines cloudbasierten Rechenzentrums erforderlich ist. Im Rahmen dieser Überprüfung interessieren wir uns für die Kategorie Oracle Cloud Infrastructure Compute, mit einem ganz besonderen Fokus auf deren Bare-Metal-Instanzen. Wie die meisten Cloud-Anbieter bietet Oracle virtualisierte Recheninstanzen an, aber im Gegensatz zu den meisten anderen virtuellen Angeboten kann Oracle diese mit Formen unterstützen, die bis zu ~25 TB NVMe-Speicher für Anwendungen enthalten, die eine geringe Latenz benötigen. So großartig diese auch sind, Oracle hat den Einsatz für Cloud-Computing-Leistung noch weiter erhöht, indem es die ersten leistungsstarken Bare-Metal-Instanzen der Branche anbietet, ideal für geschäftskritische Anwendungen, bei denen die Latenz von größter Bedeutung ist. Instanzen verfügen über bis zu 52 OCPUs, 768 GB RAM, zwei 25-GbE-NICs und bis zu 51 TB lokal angeschlossenen NVMe-Speicher. Für diejenigen, die mehr wünschen, stehen bis zu 512 TB netzwerkgebundener NVMe-Blockspeicher sowie GPU-Optionen zur Verfügung. Alle verschiedenen Rechenangebote von Oracle laufen in einem hochoptimierten softwaredefinierten Netzwerk, das darauf abgestimmt ist, Konflikte zu minimieren und die Leistung zu maximieren.
Derzeit gibt es eine große Vielfalt an Cloud-Angeboten und sogar mehrere große Cloud-Angebote, wobei AWS, Google Cloud Platform und Microsoft Azure ganz oben auf der Liste stehen. Obwohl diese Cloud-Dienstanbieter viele großartige Produkte und Dienste anbieten, fehlt es ihnen in der Regel an Leistung. Beim Vergleich von Cloud- und On-Premises-Lösungen ist die On-Premise-Lösung der Cloud immer deutlich überlegen. Oracle möchte diese Sichtweise mit seinen Cloud-Infrastrukturangeboten ändern.
Die Rechenangebote von Oracle bieten Versprechen, die man von On-Prem-Speicher oder Servern erwarten würde, einschließlich Leistung, Verfügbarkeit, Vielseitigkeit und Governance. Die Leistungsseite unterstützt Spitzen- und konsistente Leistung für geschäftskritische Anwendungen und wird durch unterstützt hat kürzlich ein End-to-End-SLA für die Cloud-Infrastruktur angekündigt, das zum jetzigen Zeitpunkt das einzige seiner Art in der Branche ist. Das Angebot unterstützt die Verfügbarkeit auf mehreren Ebenen, einschließlich DNS, Lastausgleich, Replikation, Sicherung, Speicher-Snapshots und Clustering. Die Computing-Angebote reichen von einer Single-Core-VM bis hin zu 52-Core-Single-Tenant-Bare-Metal und bieten die Vielseitigkeit, alles von allgemeinen Workloads bis hin zu HPC-Clustern auszuführen. Und mit den Bare-Metal-Instanzen von Oracle erhalten Kunden die Isolation und Kontrolle eines lokalen Servers, da sie keine anderen Mandanten und keine Software von Oracle-Anbietern enthalten.
Die Rechenangebote von Oracle Cloud gibt es in verschiedenen „Formen“, darunter Bare-Metal-Instanzen, Bare-Metal-GPU-Instanzen und VM-Instanzen. Für diesen Test werden wir uns Bare-Metal-Instanzen ansehen, die laut Oracle bis zu 5.1 Millionen IOPS liefern können und für Anwendungsfälle wie geschäftskritische Datenbankanwendungen, HPC-Workloads und I/O-intensive Webanwendungen vorgesehen sind. Zum Vergleich zeigen wir auch die VM-Formen von Oracle, mit lokalem NVMe-Speicher (DenseIO) und mit Netzwerk-Blockspeicher (Standard).
Management
Die Verwaltungs-GUI für Oracle Cloud Infrastructure ist ziemlich einfach herauszufinden. Auf der Hauptseite finden Sie bei Bedarf exemplarische Vorgehensweisen und Hilfestellungen. Oben befinden sich der Mandant oder das Konto, die verwendete Region (in unserem Fall us-ashburn-1) sowie Registerkarten für „Home“ (die Hauptseite), „Identität“, „Computing“, „Datenbank“, „Netzwerk“, „Speicher“ und „Audit“. , und E-Mail. Für unsere Tests werden DenseIO2 und Standard2 angezeigt.
Da sich diese Überprüfung auf die Compute-Seite konzentriert, können wir unter dieser Registerkarte die Instanzen sehen, die wir für unsere Leistungstests verwenden werden. Jede Instanz hat ihren Namen, ihre Form, ihre Region, ihre Verfügbarkeitsdomäne und den Zeitpunkt ihrer Erstellung. Auf der linken Seite können Benutzer die Auflistung ändern, indem sie den Status auswählen, beispielsweise „Läuft“.
Durch Klicken auf die Auslassungspunkte auf der rechten Seite können Sie einen tieferen Einblick in eine Instanz erhalten. Wenn man sich BM.DenseIO2.52 ansieht, kann man leicht erkennen, ob die Instanz ausgeführt wird, und detailliertere Informationen dazu erhalten. Auch hier können Tags damit verknüpft werden. Am oberen Rand der Informationen finden Sie die Möglichkeit, ein benutzerdefiniertes Image zu erstellen, die Instanz zu starten, zu stoppen oder neu zu starten, sie zu beenden oder Tags anzuwenden. Wenn Sie nach unten scrollen, haben Sie auch die Möglichkeit, Block-Volumes anzuhängen.
Auf der Registerkarte „Netzwerk“ können Sie sehen, welches virtuelle Cloud-Netzwerk verwendet wird, oder eines erstellen. Für das VCN gibt es Informationen wie Region, Standard-Routentabelle, DNS-Domäne und Zeitpunkt der Erstellung. Auch hier ermöglichen die Auslassungspunkte auf der rechten Seite einen Drilldown, das Anwenden von Tags und das Erstellen eines Subnetzes.
Auf der Registerkarte „Speicher“ können Benutzer die Block-Volumes in ihrem Compartment sehen und weitere erstellen. Die Block-Volumes werden nach Erstellungsdatum aufgelistet und Benutzer können nach weiteren Informationen suchen, manuelle Sicherungen erstellen, das Block-Volume von der Instanz trennen, das Volume löschen oder Tags anwenden.
Und wie Audit andeutet, kann man durch Auswahl des Datums- und Zeitbereichs schnell einen Blick auf vergangene Ereignisse werfen. Dies ermöglicht es Unternehmen, die Compliance-Anforderungen des Managements zu erfüllen, indem der Benutzer und die Aktion für jedes Ereignis oder jede Änderung in der Umgebung erfasst werden.
Kennzahlen
VDBench-Workload-Analyse
Um die Leistung dieser Oracle Cloud-Instanzen zu bewerten, haben wir vdbench genutzt, das lokal auf jeder Plattform installiert ist. Unsere Tests wurden gleichzeitig auf den gesamten lokalen Speicher verteilt. Wenn also sowohl BV (Block Volume) als auch NVMe-Speicher vorhanden waren, haben wir jeweils eine Gruppe getestet. Bei beiden Speichertypen haben wir 12 % jedes Geräts zugewiesen und sie aggregiert gruppiert, um die maximale Systemleistung bei einer moderaten Menge an Datenlokalität zu ermitteln.
Diese Workloads bieten eine Reihe unterschiedlicher Testprofile, die von „Vier-Ecken“-Tests über allgemeine Tests der Datenbankübertragungsgröße bis hin zu Trace-Erfassungen aus verschiedenen VDI-Umgebungen reichen. Alle diese Tests nutzen den gemeinsamen vdBench-Workload-Generator mit einer Skript-Engine, um Ergebnisse über einen großen Computing-Testcluster zu automatisieren und zu erfassen. Dadurch können wir dieselben Arbeitslasten auf einer Vielzahl von Speichergeräten wiederholen, einschließlich Flash-Arrays und einzelnen Speichergeräten.
Profile:
- 4K Random Read: 100 % Read, 128 Threads, 0-120 % Iorate
- 4K Random Write: 100 % Schreiben, 64 Threads, 0-120 % Iorate
- 64K sequentielles Lesen: 100 % Lesen, 16 Threads, 0-120 % Leserate
- 64K Sequentielles Schreiben: 100 % Schreiben, 8 Threads, 0-120 % Iorate
- Synthetische Datenbank: SQL und Oracle
- VDI-Vollklon- und Linked-Clone-Traces
Wir betrachten sowohl Remote Block Devices (BV) als auch NVMe. Da es einen so dramatischen Leistungsunterschied gibt, haben wir die Ergebnisse in zwei Diagramme aufgeteilt (die Latenzzeiten würden so weit auseinander liegen, dass die Diagramme sehr schwer zu lesen wären). Für diesen Test betrachten wir sowohl Bare-Metal- (BM) als auch VM-Konfigurationen mit Standard- und Dense-IO-Läufen auf BV und nur Dense-IO-Läufen für NVMe.
Betrachtet man den Spitzenwert der 4K-Lesevorgänge für BV, so begannen alle vier Läufe mit einer starken Latenz von unter einer Millisekunde. Der erste, der sich ablöste, war VM.Standard, der knapp 53 IOPS erreichte und dann bei 60,591 IOPS mit einer Latenz von 15 ms seinen Höhepunkt erreichte. Der nächste, der die Latenzzeit unter einer Millisekunde durchbrach, war VM.DenseIO, das ungefähr an der gleichen Stelle wie der Standard über 1 ms lag, aber mit 72,626 IOPS mit einer Latenz von 7.5 ms seinen Höhepunkt erreichte. Beide Bare-Metal-Läufe schnitten viel besser ab, wobei DenseIO eine Latenzleistung von unter einer Millisekunde bis etwa 235 IOPS ausführte und einen Spitzenwert von 252,275 IOPS mit einer Latenz von 4.1 ms erreichte. Der BM.Standard erreichte etwa 250 IOPS, bevor er 1 ms überschritt und einen Spitzenwert von 258,329 IOPS mit einer Latenz von 4.05 ms erreichte.
Betrachtet man die maximale 4K-Leseleistung für NVMe, so wiesen beide Läufe durchgehend eine Latenz von weniger als einer Millisekunde auf. Der VM.DenseIO erreichte einen Spitzenwert von 569,534 IOPS mit einer Latenz von 214 μs. Der BM.DenseIO erreichte einen Spitzenwert von 4,419,490 IOPS mit einer Latenz von nur 174.6 μs.
Beim Wechsel zur zufälligen 4K-Schreibspitzenleistung für BV sehen wir eine ähnliche Platzierung wie zuvor, wobei die VMs ihren Höhepunkt viel früher erreichen als die BMs. Der VM.Standard erreichte etwa 63 IOPS, bevor er die Sub-Millisekunden-Latenz durchbrach, und erreichte bei einer Latenz von 77,229 ms einen Spitzenwert von 5.3 IOPS. Die Leistung von VM.DenseIO war etwas besser und erreichte etwa 69 IOPS, bevor die 1-ms-Marke überschritten wurde, und erreichte einen Spitzenwert von 84,274 IOPS mit einer Latenz von 3.9 ms. Der BM.DenseIO schaffte es, über 263 IOPS zu erreichen, bevor er eine Latenz von über 1 ms erreichte, und erreichte einen Spitzenwert von 280,158 IOPS mit einer Latenz von 2.02 ms. Und BM.Standard war die leistungsstärkste Konfiguration mit etwa 278 IOPS, bevor die Latenzzeit unter einer Millisekunde überschritten wurde, und erreichte einen Spitzenwert von 280,844 IOPS mit einer Latenz von 1.84 ms.
Mit dem NVMe beim 4K-Schreiben übertraf der BM wiederum den VM, da beide durchgehend eine Latenzleistung von unter einer Millisekunde hatten. Der VM.DenseIO erreichte einen Spitzenwert von 412,207 IOPS mit einer Latenz von 141 μs. Der BM.DenseIO erreichte einen Spitzenwert von 3,232,215 IOPS mit einer Latenz von 125 μs.
Kommen wir zur sequentiellen Arbeit und schauen uns zunächst den 64K-Read für BV an. Sowohl VM.Standard als auch VM.DenseIO durchbrachen die 1-ms-Latenz bei etwa 15.5 IOPS oder 968 MB/s. Und beide behielten mehr oder weniger die gleiche Leistung, während die Latenz auf 8.2 ms stieg. Wiederum sahen wir etwas Ähnliches bei BM.Standard und BM.DenseIO, die beide 1 ms bei etwa 37.5 IOPS oder 2.35 GB/s unterbrachen. Beide Konfigurationen erreichten einen Spitzenwert von knapp über 47 IOPS oder 2.95 GB/s bei einer Latenz von 8.4 ms.
Bei sequenziellem NVMe-64K-Lesevorgang blieben beide Konfigurationen durchgehend unter einer Latenz von weniger als einer Millisekunde. Der VM.DenseIO erreichte einen Spitzenwert von 39,512 IOPS oder 2.5 GB/s mit einer Latenz von 403 μs, während der BM.DenseIO einen Spitzenwert von 323,879 IOPS oder 20.2 GB/s mit einer Latenz von 361 μs erreichte.
Bei sequenziellen 64K-Schreibvorgängen für BV sehen wir erneut ein ähnliches Phänomen, da VM.Standard und VM.DenseIO beide die Latenzzeit von 1 ms bei einer Leistung von 12 IOPS oder 770 MB/s unterbrechen. Beide erreichten einen Spitzenwert von etwa 15.1 IOPS oder 943 MB/s bei einer Latenz von 3.1 ms. Mit BM.Standard und BM.DenseIO durchbrachen beide die 1-ms-Latenz bei etwa 42 IOPS oder 2.6 GB/s, während BM.DenseIO bei 46,768 IOPS oder 2.92 GB/s mit 2.6 ms Latenz einen Spitzenwert erreichte. Der BM.Standard erreichte einen Spitzenwert von 46,787 IOPS oder 2.92 GB/s mit einer Latenz von 3.4 ms.
Bei sequentiellen 64K-Schreibvorgängen für NVMe hatten sowohl VM.DenseIO als auch BM.DenseIO durchgehend eine Latenzleistung von unter einer Millisekunde, aber auch beide erlitten einen Anstieg der Latenz (gepaart mit einer endgültigen Leistungsreduzierung für BM.DenseIO). Der VM.DenseIO erreichte einen Spitzenwert von 25 IOPS oder 1.56 GB/s mit einer Latenz von 311 μs nach einem Anstieg auf 754 μs. Der BM.DenseIO hatte eine viel bessere Spitzenleistung (160,895 IOPS oder 10.1 GB/s bei einer Latenz von 170 μs), brach jedoch am Ende etwas ein, wobei auch die Latenz zunahm, und endete bei 132,192 IOPS oder 8.8 GB/s mit einer Latenz von 310μs.
In unserem SQL-Workload für BV erreichte VM.Standard als erster die 1-ms-Marke bei etwa 50 IOPS und erreichte einen Spitzenwert von 73,259 IOPS mit einer Latenz von 3.4 ms. VM.DenseIO erreichte eine Latenzzeit von über 1 ms bei etwa 58 IOPS und erreichte einen Spitzenwert von 78,624 IOPS mit einer Latenz von 3.1 ms. Bei den BMs blieb die Latenz bei beiden bis etwa 1 unter 275 ms (wobei BM.DenseIO etwas länger lief). Der BM.Standard erreichte einen Spitzenwert von 305,368 IOPS mit einer Latenz von 1.7 ms, während der BM.DenseIO einen Spitzenwert von 307,979 IOPS mit einer Latenz von 1.35 ms erreichte.
SQL für NVMe hatte wiederum durchgehend eine Latenz von unter einer Millisekunde, wobei VM.DenseIO einen Spitzenwert von 188,786 IOPS mit 167 μs erreichte. Der BM.DenseIO erreichte einen Spitzenwert von 1,684,869 IOPS mit einer Latenz von 142 μs.
Im SQL 90-10-Benchmark für BV erreichten beide VMs eine Latenzleistung von unter einer Millisekunde bei etwa 58 IOPS. Der VM.Standard erreichte einen Spitzenwert von 71,691 IOPS mit einer Latenz von 3.5 ms. Der VM.DenseIO erreichte einen Spitzenwert von 79,033 IOPS mit einer Latenz von 3.05 ms. Der BM.Standard durchbrach die 1-ms-Latenz bei einer Leistung von etwa 270 IOPS und erreichte einen Spitzenwert von 303,904 IOPS mit einer Latenz von 1.7 ms. Das BM.DenseIO hatte eine Latenz von weniger als einer Millisekunde bis etwa 290 IOPS und erreichte einen Spitzenwert von 307,472 IOPS mit einer Latenz von 1.34 ms.
Für NVMe SQL 90-10 erreichte VM.DenseIO einen Spitzenwert von 172,693 IOPS mit einer Latenz von 182 μs. Der BM.DenseIO erreichte einen Spitzenwert von 1,328,437 IOPS mit 165 μs.
Im SQL 80-20-Benchmark für BV erreichte der VM.Standard etwa 54 IOPS, bevor er 1 ms überschritt, und erreichte einen Spitzenwert von 72,204 IOPS mit einer Latenz von 3.4 ms. VM.DenseIO hatte eine Latenz von weniger als einer Millisekunde bis etwa 59 IOPS und erreichte einen Spitzenwert von 78,787 IOPS mit einer Latenz von 2.99 ms. Der BM.Standard erreichte etwa 280 IOPS mit einer Latenz unter 1 ms und erreichte einen Spitzenwert von 300,014 IOPS mit einer Latenz von 1.6 ms. BM.DenseIO durchbrach die 1-ms-Latenz bei etwa 285 IOPS und erreichte mit 299,730 ms Latenz einen Spitzenwert von 1.3 IOPS, bevor die Leistung nachließ.
Im SQL 80-20-Benchmark für NVMe erreichte VM.DenseIO einen Spitzenwert von 144,010 IOPS mit einer Latenz von 218 μs. Der BM.DenseIO erreichte einen Spitzenwert von 1,114,056 IOPS mit einer Latenz von 182 μs, bevor es zu einem leichten Leistungsabfall kam.
In unserem Oracle-Workload mit BV hatte der VM.Standard eine Latenzleistung von unter einer Millisekunde, bis er etwa 52 IOPS erreichte und einen Spitzenwert von 70,096 IOPS mit einer Latenz von 3.4 ms erreichte. Die VM.DenseIO durchbrach die 1-ms-Latenz bei etwa 58 IOPS und erreichte einen Spitzenwert von 75,000 IOPS mit einer Latenz von 3.1 ms. BM.Standard durchbrach die 1-ms-Latenz bei etwa 255 mit einer Spitzenleistung von 280,599 IOPS bei einer Latenz von 1.41 ms. BM.DenseIO hatte eine Latenz von unter einer Millisekunde bis etwa 260 IOPS und erreichte einen Spitzenwert von 267,632 IOPS mit einer Latenz von 1.3 ms.
Unser Oracle-Workload mit NVMe zeigte eine Spitzenleistung für VM.DenseIO von 132,553 IOPS mit einer Latenz von 257 μs. Mit BM.DenseIO betrug die Spitzenleistung 1,043,104 IOPS und eine Latenz von 199μs.
In Oracle 90-10 für BV hatte VM.Standard eine Latenz von unter einer Millisekunde bis knapp über 54 IOPS und erreichte einen Spitzenwert von 72,533 IOPS mit einer Latenz von 2.2 ms. VM.DenseIO durchbrach die 1-ms-Latenz bei etwa 61 IOPS und erreichte einen Höchstwert von 76,908 IOPS mit einer Latenz von 1.86 ms. Beide BMs erreichten 297 IOPS, bevor sie die 1-ms-Latenz durchbrachen. Der BM.Standard erreichte einen Spitzenwert von 305,771 IOPS mit einer Latenz von 1.17 ms. Der BM.DenseIO hatte eine Spitzenleistung von 297,509 IOPS mit einer Latenz von 1.03 ms.
Im Oracle 90-10 für NVMe hatte VM.DenseIO eine Spitzenleistung von 133,330 IOPS und eine Latenz von 163 μs. Der BM.DenseIO hatte eine Spitzenleistung von 1,088,454 IOPS und eine Latenz von 142 μs.
Beim Oracle 80-20 mit BV erreichte VM.Standard in weniger als 55 ms etwa 1 KB und erreichte einen Spitzenwert von 74,032 IOPS mit einer Latenz von 2.14 ms. VM.DenseIO hatte eine Latenz von unter einer Millisekunde bis etwa 51 und erreichte einen Spitzenwert von 75,666 IOPS mit einer Latenz von 2 ms. Beide BMs schafften es bis etwa 295 IOPS, bevor sie nach 1 ms durchbrachen. Der BM.Standard erreichte einen Spitzenwert von 306,955 IOPS mit einer Latenz von 1.14 ms. Der BM.DenseIO erreichte einen Spitzenwert von etwa 295 IOPS mit einer Latenz von 893 μs.
Im Oracle 80-20 mit NVMe erreichte VM.DenseIO einen Spitzenwert von 108,483 IOPS mit einer Latenz von 195 μs. Der BM.DenseIO erreichte einen Spitzenwert von 956,326 IOPS mit einer Latenz von 158 μs.
Als nächstes haben wir uns VDI Full Clone angesehen. Beim Booten mit BV durchbrach VM.Standard 1 ms bei knapp 40 IOPS und erreichte einen Spitzenwert von 56,057 IOPS mit einer Latenz von 4.2 ms. VM.DenseIO schaffte es mit einer Latenz von unter einer Millisekunde bis etwa 43 IOPS und erreichte einen Spitzenwert von 61,570 IOPS mit einer Latenz von 3.6 ms. Beide BMs hatten eine Latenz von weniger als einer Millisekunde, bis sie knapp über dem 200-IOPS-Schwellenwert lagen. Beide erreichten ihren Höhepunkt bei etwa 220 IOPS mit einer Latenz von 2.1, bevor die Leistung abnahm.
Beim Full Clone-Boot mit NVMe erreichte VM.DenseIO einen Spitzenwert von etwa 136 IOPS mit einer Latenz von 235 μs. Der BM.DenseIO erreichte einen Spitzenwert von 1,032,322 IOPS mit einer Latenz von 213 μs.
Mit VDI Full Clone Initial Log In mit BV erreichten beide VMs etwa 41 IOPS mit einer Latenz von weniger als einer Millisekunde, wobei VM.Standard einen Spitzenwert von 55,522 IOPS mit einer Latenz von 3.7 ms und VMDenseIO einen Spitzenwert von 59,560 IOPS mit einer Latenz von 3.6 ms erreichte . Beide BMs durchbrachen die Latenzzeit unter einer Millisekunde bei etwa 203 IOPS (wobei Standard vor Dense ging). BM.Standard erreichte einen Spitzenwert von etwa 225 IOPS mit einer Latenz von 2.04 ms und BM.DenseIO erreichte einen Spitzenwert von 224,385 IOPS mit einer Latenz von 1.8 ms.
Beim VDI Full Clone Initial Login mit NVMe erreichte der VM.Standard einen Spitzenwert von 59,883 IOPS mit einer Latenz von 506 μs. Und der BM.DenseIO erreichte einen Spitzenwert von 467,761 IOPS mit einer Latenz von 262 μs.
VDI Full Clone Monday Login mit BV hatte den VM.Standard mit einer Latenz von unter einer Millisekunde bis knapp 36 IOPS mit einem Spitzenwert von 50,685 IOPS und einer Latenz von 2.3 ms. VM.DenseIO erreichte eine Leistung von weniger als 1 ms bis knapp über 38 IOPS und erreichte einen Spitzenwert von 53,304 IOPS mit einer Latenz von 2.2 ms. BM.Standard durchbrach die 1-ms-Latenz bei etwa 205 IOPS und erreichte einen Spitzenwert von 224,764 IOPS mit einer Latenz von 1.5 ms. BM.DenseIO erreichte eine Geschwindigkeit von über 1 ms bei etwa 210 mit einem Spitzenwert von knapp über 220 IOPS und einer Latenz von 1.2 ms.
VDI Full Clone Monday Login mit NVMe zeigte eine Spitzenleistung von VM.DenseIO von 44,384 IOPS mit einer Latenz von 356 μs. BM.DenseIO erreichte einen Spitzenwert von 356,691 IOPS mit einer Latenz von 252 μs.
Unsere letzte Auswahl an Tests befasst sich mit VDI Linked Clone. Beginnend mit dem Boot-Test mit BV zeigte der VM.Standard eine Latenz von unter einer Millisekunde bis etwa 29 IOPS und erreichte einen Spitzenwert von etwa 38 IOPS mit einer Latenz von 2.4 ms. VM.DenseIO schaffte es bis zu etwa 32 IOPS, bevor es 1 ms durchbrach, und erreichte ebenfalls etwa 38 IOPS mit einer Latenz von 2.16 ms. Beide BMs erreichten etwa 100 IOPS, bevor die Latenzzeit die 1-ms-Marke überschritt. Beide hatten eine Spitzenleistung von etwa 114 IOPS mit einer Latenz von 3 ms.
Mit VDI Linked Clone Boot für NVMe sahen wir den VM.DenseIO-Spitzenwert bei 65,384 IOPS mit einer Latenz von 238 μs. Der BM.DenseIO erreichte einen Spitzenwert von 555,004 IOPS mit einer Latenz von 217 μs.
Bei der ersten Anmeldung mit BV durchbrachen beide VMs die 1-ms-Latenz bei etwa 28 IOPS, wobei VM.Standard einen Spitzenwert von 36,682 IOPS mit einer Latenz von 1.6 ms und VM.DenseIO einen Spitzenwert von 38,525 IOPS mit einer Latenz von 1.6 ms erreichte. Beide BMs durchbrachen die 1-ms-Latenz bei etwa 132 IOPS, wobei der BM.Standard einen Spitzenwert von 140,848 IOPS mit einer Latenz von 1.3 ms und der BM.DenseIO einen Spitzenwert von 139,883 IOPS und einer Latenz von 1.2 ms erreichte.
Bei der ersten Anmeldung mit NVMe wurde eine Spitzenleistung von 24,228 IOPS und 326 μs für VM.DenseIO und 242,778 IOPS mit 234 μs für BM.DenseIO erzielt.
Schließlich erreichte VM.Standard mit VDI Linked Clone Monday Login mit BV eine Latenzleistung von unter einer Millisekunde bis etwa 27 IOPS mit einem Spitzenwert von 39,874 IOPS und einer Latenz von 2.86 ms. VM.DenseIO durchbrach 1 ms bei etwa 25 IOPS und erreichte einen Spitzenwert von 42,469 IOPS und einer Latenz von 3 ms. Beide BMs hatten eine Latenz von unter einer Millisekunde bis etwa 135 IOPS, wobei beide einen Spitzenwert von 146 IOPS erreichten, wobei der DenseIO eine Latenz von 1.6 ms und der Standard eine Latenz von 1.76 ms aufwies.
Mit VDI Linked Clone Monday Login mit NVMe erreichte VM.DenseIO einen Spitzenwert von 34,016 IOPS und einer Latenz von 464 μs. BM.DenseIO erreichte einen Spitzenwert von 260,527 IOPS und einer Latenz von 317 μs.
Schlussfolgerung
Die Cloud-Infrastruktur von Oracle nimmt eines der Hauptprobleme der Cloud – Leistung oder deren Mangel – und geht es mit ihren Bare-Metal-Instanzen an. Oracle bietet Bare-Metal- und virtuelle Recheninstanzen sowie NVMe-Versionen mit bis zu 25 TB NVMe-Speicher für eine Leistung, die in der Cloud ihresgleichen sucht. Um die von Oracle angegebene Leistung von bis zu 5.1 Millionen IOPS zu erreichen, ist mehr als NVMe-Speicher erforderlich. Die Instanzen verfügen außerdem über bis zu 52 OCPUs, 768 GB RAM, zwei 25-GbE-NICs und bis zu 51 TB lokal angeschlossenen NVMe-Speicher. Dieses Leistungsniveau wird hauptsächlich für Anwendungsfälle wie geschäftskritische Datenbankanwendungen, HPC-Workloads und E/A-intensive Webanwendungen verwendet.
Was die Leistung betrifft, haben wir unsere VDBech-Tests sowohl für Bare-Metal- (BM) als auch für VM-Formen durchgeführt, wobei wir sowohl den lokalen NVMe-Speicher (DenseIO) als auch den Netzwerkblockspeicher (Standard) verwendeten. Die Leistung hat uns einfach umgehauen. Für jeden Test haben wir zwei Diagrammsätze ausgeführt, da die Latenzdiskrepanz zwischen DenseIO und Standard so groß war, dass die Diagramme schwer zu lesen wären, wenn alle auf einem Satz wären. In Bezug auf die gute Speicherleistung dieser Instanzen im Vergleich zu herkömmlichem Speicher konkurrieren sie mit vielen der besten Shared-Storage-Optionen auf dem Markt, ganz zu schweigen von Cloud-Alternativen. Die angeschlossenen BVs, die über iSCSI gehostet und gesichert werden, bieten eine starke Mischung aus Durchsatz und Bandbreite bei geringer Latenz. Um dies in einen Zusammenhang zu bringen: Wir haben gesehen, dass viele Tests mit 32 BVs, die an die 52 OCPU-Instanzen angeschlossen waren, die Leistung der All-Flash-Speicher-Arrays übertrafen, die wir in unserem Labor getestet haben. Einige waren möglicherweise tatsächlich etwas schneller, was ziemlich beeindruckend ist, wenn man bedenkt, dass wir eine Cloud-Instanz mit einem AFA über 250 US-Dollar, FC-Switching und mehreren Rechenhosts vergleichen.
Was die Bare-Metal-Instanzen der Oracle Cloud jedoch wirklich unglaublich macht, ist der lokal angeschlossene NVMe-Speicher. Das DenseIO2.8 hatte 1 Gerät, während das DenseIO2.52 8 hatte, was die Leistung dieser Instanzen in Millionen von IOPS misst. Die Instanz mit 1 NVMe-SSD erreichte mit 4 IOPS die höchste zufällige 569K-Lesegeschwindigkeit, während die Leistung der Instanz mit 8 auf 4.4 Mio. IOPS anstieg. Auch die Bandbreite war kein Scherz; Die kleinere Instanz erreichte eine Lesespitze von 2.5 GB/s, während die größere Instanz über 20 GB/s erreichte. Stellen Sie sicher, dass Sie über einen Backup-Plan verfügen, da es sich bei den NVMe-Shapes schließlich um lokal angeschlossenen Speicher handelt, der geschützt werden muss.
Oracle hat erstklassige Server und Speicher in der Cloud entwickelt; Das Einzige, was ihren Bare-Metal-Instanzen Konkurrenz machen kann, ist der Aufbau eines lokal gehosteten Servers der Spitzenklasse, zusammen mit allen anderen Komponenten und Diensten, die ihn unterstützen. Wie bei allen Cloud-Lösungen bietet Oracle die Flexibilität, Ihre Instanzen ein- und auszuschalten, und die Flexibilität, den Speicherbedarf nach Bedarf anzupassen. In diesen Fällen ist das offensichtliche Problem die Kosten. Die Zweckmäßigkeit, eine Instanz innerhalb der Oracle Cloud online zu stellen, im Vergleich zum Aufwand und den Kosten, die für die Einrichtung vergleichbarer Hardware in Ihrem eigenen Rechenzentrum erforderlich sind, ist möglicherweise der entscheidende Faktor. Obwohl NVMe-angeschlossener Speicher teuer ist, gibt es keine Einwände gegen die Leistungsvorteile, die wir gesehen haben. Wenn Sie ein Unternehmen haben, das von der Verarbeitungszeit großer Datenmengen betroffen ist, gibt es keine einfachere oder schnellere Lösung als die von uns verwendeten NVMe-basierten Formen, um Arbeitslasten wie Analysen abzuschließen. Und es ist nicht so, dass die standardmäßig angehängten Blockformen schlecht waren, die NVMe-Formen waren einfach so unwirklich, dass sie den Rest in den Schatten stellten. Das Fazit ist, dass zukunftsorientierte Unternehmen, die messbaren Nutzen aus einer Hochleistungs-Cloud ziehen können, unbedingt die Aktivitäten von Oracle bewerten sollten. Es gibt viele Möglichkeiten, in die Cloud zu wechseln, aber nichts ist so schnell wie das, was wir bei den Bare-Metal-Instanzen der Oracle Cloud gesehen haben, was diese Lösungen zu einem klaren und verdienten Gewinner unseres ersten Editor's Choice Award für Cloud-Dienste macht Anbieter.
Besprechen Sie diese Rezension
Melden Sie sich für den StorageReview-Newsletter an
