Es besteht kaum ein Zweifel daran, dass Amazon führend ist, wenn es um eine Vielzahl von Cloud-Diensten geht, die über seinen EC2-Webdienst (Elastic Compute Cloud) angeboten werden. Mit einem relativ einfachen Bereitstellungsprozess und der Möglichkeit, Instanzen und Speicheranforderungen problemlos nach oben oder unten zu skalieren, zielt EC2 darauf ab, alle Versprechen der Cloud zu kostengünstigen Preisen zu erfüllen. Für einige geht es bei der Cloud jedoch nicht nur um Flexibilität und einfache Bereitstellung; es geht um Leistung. Die geschäftlichen Vorteile, die sich aus der Möglichkeit ergeben, leistungsstarke Umgebungen für kritische Anwendungen wie Analysen hoch- oder herunterzufahren, können die Kosten dafür durch OPEX anstelle der langfristigen Investitionen in CAPEX oft bei weitem überwiegen. Zu diesem Zweck hat Amazon im Mai die i3-Bare-Metal-Instanzfamilie eingeführt, die direkten Zugriff auf CPU- und Speicherressourcen des zugrunde liegenden Servers bietet.
Es besteht kaum ein Zweifel daran, dass Amazon führend ist, wenn es um eine Vielzahl von Cloud-Diensten geht, die über seinen EC2-Webdienst (Elastic Compute Cloud) angeboten werden. Mit einem relativ einfachen Bereitstellungsprozess und der Möglichkeit, Instanzen und Speicheranforderungen problemlos nach oben oder unten zu skalieren, zielt EC2 darauf ab, alle Versprechen der Cloud zu kostengünstigen Preisen zu erfüllen. Für einige geht es bei der Cloud jedoch nicht nur um Flexibilität und einfache Bereitstellung; es geht um Leistung. Die geschäftlichen Vorteile, die sich aus der Möglichkeit ergeben, leistungsstarke Umgebungen für kritische Anwendungen wie Analysen hoch- oder herunterzufahren, können die Kosten dafür durch OPEX anstelle der langfristigen Investitionen in CAPEX oft bei weitem überwiegen. Zu diesem Zweck hat Amazon im Mai die i3-Bare-Metal-Instanzfamilie eingeführt, die direkten Zugriff auf CPU- und Speicherressourcen des zugrunde liegenden Servers bietet.
i3.metal-Instanzen basieren auf dem Nitro-System, einer Sammlung von AWS-basierten Hardware-Offload- und Serverschutzkomponenten, die „EC2-Instanzen sicher leistungsstarke Netzwerk- und Speicherressourcen bereitstellen“. i3.metal-Instanzen nutzen auch alle anderen von AWS Cloud angebotenen Dienste wie Elastic Block Store (EBS), die wir im Rahmen dieser Überprüfung genutzt haben. Die Instanzen verfügen außerdem über bis zu 15.2 TB NVMe-SSD-gestützten Instanzspeicher sowie 2.3-GHz-Intel-Xeon-Prozessoren mit 36 Hyper-Threaded-Kernen (72 logischen Prozessoren) und 512 GiB Arbeitsspeicher. Auf der Fabric-Seite liefern die i3.metal-Instanzen bis zu 25 Gbit/s aggregierte Netzwerkbandbreite und sorgen so für einen hohen Netzwerkdurchsatz und eine geringere Latenz über Elastic Network Adapter (ENA)-basiertes Enhanced Networking.
Innerhalb von EC2 gibt es eine Reihe von Instanztypen. Die i3-Instanzen fallen in die Kategorie „Speicheroptimiert“, wobei die i3.metal-Instanzen die leistungsstärkste dieser Gruppe sind. Die folgende Tabelle zeigt die Familie und die Konfiguration der Instanztypen.
| Modell | vCPU | Arbeitsspeicher (GiB) | Netzwerkleistung | Speicher (TB) |
| i3.groß | 2 | 15.25 | Bis zu 10 Gigabit | 1 x 0.475 NVMe SSD |
| i3.xlarge | 4 | 30.5 | Bis zu 10 Gigabit | 1 x 0.95 NVMe SSD |
| i3.2xlarge | 8 | 61 | Bis zu 10 Gigabit | 1 x 1.9 NVMe SSD |
| i3.4xlarge | 16 | 122 | Bis zu 10 Gigabit | 2 x 1.9 NVMe SSD |
| i3.8xlarge | 32 | 244 | 10 Gigabit | 4 x 1.9 NVMe SSD |
| i3.16xlarge | 64 | 488 | 25 Gigabit | 8 x 1.9 NVMe SSD |
| i3.metall | 72 | 512 | 25 Gigabit | 8 x 1.9 NVMe SSD |
i3.metal-Instanzen sind in den AWS-Regionen USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Oregon), Europa (Frankfurt) und Europa (Irland) verfügbar und können als On-Demand-Instanzen erworben werden. Reservierte Instanzen (3 Jahre, 1 Jahr und konvertierbar) oder als Spot-Instanzen. Für die Zwecke dieser Überprüfung haben wir in der Region North Virginia getestet. Wir haben sowohl mit NVMe-Speicher als auch mit EBS-Block-Volumes getestet.
Kennzahlen
VDBench-Workload-Analyse
Um die Leistung der EC2 i3.metal-Instanz zu bewerten, haben wir den lokal installierten VDBench genutzt, um sowohl EBS- (30 x 1 TB) als auch NVMe-Speicher (8 x 1.7 TB) zu testen. 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-verknüpfte Klonspuren
In diesem Test betrachten wir sowohl EBS als auch NVMe. Da es einen 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).
Unser erster Test befasst sich mit 4K-Zufallslesevorgängen. Hier hatte die EBS-Instanz bis zum Schluss eine Latenzleistung von unter einer Millisekunde. Bereits bei etwa 64 IOPS stieg die Latenz auf 59.46 ms bei einer Leistung von 64,047 IOPS.
Wenn wir uns den NVMe 4K Peak Random Read ansehen, sehen wir, dass die Instanz eine viel bessere Leistung erbringt. Die Instanz erreichte einen Spitzenwert von 2,802,904 IOPS mit einer Latenz von 348 μs.
Beim zufälligen 4K-Schreiben mit EBS kam es fast zu dem gleichen Ergebnis wie beim 4K-Lesevorgang mit EBS. Die Instanz brach 1 ms früher ab, etwa 60 IOPS, und erreichte einen Höchstwert von 64,003 IOPS mit einer Latenz von 29.97 ms.
Bei der NVMe-Version der Instanz gab es einen leichten Anstieg der Latenz, aber immer noch unter 1 ms. Die Instanz erreichte einen Spitzenwert von 920,975 IOPS mit einer Latenz von 545 μs.
Bei der Umstellung auf sequentielle Tests für die EBS 64K-Spitzenleseleistung hatte die Instanz eine Latenz von unter einer Millisekunde bis etwa 70 IOPS oder etwa 450 MB/s und erreichte einen Spitzenwert von 17,360 IOPS oder 1.08 GB/s mit einer Latenz von 27.65 ms.
Sequentielles 64K-Lesen mit NVMe ergab eine Spitzenleistung von 244,037 IOPS oder 15.25 GB/s bei einer Latenz von 514 μs.
Bei 64 Schreibvorgängen mit EBS startete die Instanz bei mehr als 1 ms und erreichte einen Spitzenwert von 17,359 IOPS oder 1.08 GB/s mit einer Latenz von 13.8 ms.
Beim sequentiellen 64-KByte-Schreibvorgang sehen wir zum ersten Mal, dass die NVMe-Instanz länger als 1 ms dauert. Die Instanz erreichte einen Spitzenwert von 58,572 IOPS oder 3.66 GB/s mit einer Latenz von 1.08 ms.
Bei der Umstellung auf unsere SQL-Workloads hatte die EBS-Instanz eine Latenzleistung von unter einer Millisekunde bis etwa 55 IOPS und erreichte einen Spitzenwert von 64,036 IOPS mit einer Latenz von 14.93 ms.
Für die NVMe-Version der Instanz konnten wir beim SQL-Test eine Spitzenleistung von 834,231 IOPS mit einer Latenz von 302 μs feststellen.
Bei SQL 90-10 mit EBS durchbrach die Instanz erneut die 1-ms-Latenzzeit bei etwa 55 IOPS und erreichte anschließend einen Spitzenwert von 64,036 IOPS mit einer Latenz von 14.99 ms.
Die NVMe-Version der Instanz im SQL 90-10 hatte eine Spitzenleistung von 605,150 IOPS und eine Latenz von 415μs.
Der SQL 80-20 mit EBS lieferte wiederum nahezu die gleichen Zahlen, wobei die Latenzzeit unter einer Millisekunde bei etwa 55 IOPS endete und ein Spitzenwert von 64,036 IOPS mit einer Latenz von 14.93 ms erreicht wurde.
Der SQL 80-20 mit NVMe hatte eine Instanztrefferzahl von 511,840 IOPS und eine Latenz von 493 μs.
Die Oracle-Tests für EBS zeigten die gleiche seltsame Spitzenleistung mit nahezu gleichen Zahlen. Bei Oracle erreichte die Instanz 64,036 IOPS mit einer Latenz von 13.6 ms. Die Instanz hatte eine Latenzleistung von weniger als einer Millisekunde bis etwa 55 IOPS.
Mit NVMe erreichte die Instanz im Oracle-Test 457,372 IOPS mit einer Latenz von 613μs.
Bei Oracle 90-10 lag der Spitzenwert der EBS-Instanz bei 64,035 IOPS mit einer Latenz von 10.3 ms. Die Instanz brach nach 1 ms bei etwa 55 IOPS ab.
Die NVMe-Version der Instanz im Oracle 90-10 konnte 520,448 IOPS mit einer Latenz von 333 μs erreichen.
Bei Oracle 80-20 unterbrach der EBS 1 ms bei etwa 55 IOPS und erreichte einen Spitzenwert von 64,036 IOPS mit einer Latenz von 10.3 ms.
Die Instanz mit NVMe hatte eine Spitzenleistung von 435,265 IOPS bei einer Latenz von 400 μs.
Als nächstes werfen wir einen Blick auf unsere VDI Linked Clone (LC)-Tests. Beginnend mit dem Booten hatte die EBS-Version der Instanz eine Latenz von weniger als einer Millisekunde bis etwa 35 IOPS und erreichte einen Spitzenwert von 42,893 IOPS mit einer Latenz von 11.2 ms.
Die NVMe-Version der Instanz konnte in unserem VDI LC Boot-Test einen Spitzenwert von 349,799 IOPS und einer Latenz von 363 μs erreichen.
Bei der VDI LC-Erstanmeldung überschritt die EBS-Instanz einige Zeit die Grenze von 1 ms, bevor sie auf etwa 31 IOPS fiel. Die Instanz erreichte einen Spitzenwert von 34,486 IOPS und einer Latenz von 6.95 ms.
Beim VDI LC Initial Login erreichte die NVMe-Instanz einen Spitzenwert von 93,405 IOPS mit einer Latenz von 677 μs.
Beim VDI LC Monday Login flirtete die EBS-Instanz erneut einige Zeit mit 1 ms, bevor sie den Sprung auf etwa 25 IOPS wagte und schließlich mit 34,643 IOPS mit einer Latenz von 13.85 ms ihren Höhepunkt erreichte.
Und schließlich hatte unser VDI LC Monday Login mit NVMe den Instanzspitzenwert bei 119,615 IOPS mit einer Latenz von 1.1 ms.
Fazit
Die Cloud-Dienste von Amazon gelten normalerweise als die vielseitigsten überhaupt. Während Rechenleistung und Speicher sicherlich unterschiedlich sind, bietet Amazon auch Leistungsoptionen. Amazon bietet eine Vielzahl von Leistungsoptionen für seinen EC2-Webdienst, einschließlich seiner i3-Bare-Metal-Instanz. Diese Instanzen nutzen das AWS Nitro-System aus speziell entwickelter Hardware und Software. Die i3.metal-Instanzen bieten eine bessere Leistung durch direkten Zugriff auf die CPUs und den Speicher und bieten Benutzern gleichzeitig die Möglichkeit, andere Funktionen wie den an AWS EBS angeschlossenen Speicher und den lokalen NVMe-Speicher zu nutzen.
Für die Leistung haben wir sowohl Blockspeicher (EBS) als auch NVMe getestet. Dies soll den Lesern eine Vorstellung davon geben, was sie in Bezug auf die Optionen erwarten können, und weniger davon ist besser als die andere (normalerweise ist NVMe-Speicher leistungsstärker und weist eine viel geringere Latenz auf, weshalb es zwei Diagrammsätze gibt). Als wir uns das EBS ansahen, sahen wir ein Muster, bei dem die Instanz die 1-ms-Marke überschritt und kurz darauf die Latenz und das Ende anstieg. Während unserer Tests erreichte der EBS einen Spitzenwert von etwa 64 IOPS, was dem für EBS zulässigen Höchstwert entspricht. Dazu gehörten die 4K-Tests sowie alle drei SQL- und Oracle-Tests. Für unsere VDI-Tests wurde die Instanz etwas langsamer. Amazon weist zwar darauf hin, dass es möglich ist, die Einstellungen zu optimieren, um mehr als die vorgeschriebenen 64K IOPS zu erreichen, aber die Prozesse, um dorthin zu gelangen, sind nicht die, die die meisten Kunden erleben würden, also haben wir diesen Weg nicht weiterverfolgt.
Bei unseren NVMe-Tests sahen wir Ergebnisse, die eher unseren normalen Benchmarks entsprachen. Zu den Highlights gehörten hier eine zufällige 4K-Leseleistung von 2.8 Millionen IOPS, 4K-Schreibleistung von 920 IOPS, 64K-Leseleistung von 15.25 GB/s und SQL-Leistungen von über 500 IOPS in allen drei Tests (wobei der SQL-Test etwa 834 IOPS betrug). Oracle-Tests zeigten auch mit NVMe eine starke Leistung, mit Ergebnissen zwischen 435 IOPS und 520 IOPS. Unser VDI Linked Clone zeigte eine starke Boot-Leistung mit rund 350 IOPS. Die einzige Enttäuschung hier ist, dass Kunden sich in den i3.metal-Instanzen nicht für mehr lokales NVMe entscheiden können.
Insgesamt hat uns die i3.metal-Instanz genau das gegeben, was Amazon versprochen hat. Das ist beruhigend für Kunden, die sicher sein wollen, dass sie das versprochene Serviceniveau erhalten. Dies ist natürlich nicht ohne Kosten, denn wie bei jeder Cloud-Bereitstellung geht es um die Benutzerfreundlichkeit und die Ergebnisse in der Cloud im Vergleich zu anderen Cloud-Anbietern im Vergleich zu On-Prem. Allerdings können Kunden, deren Workloads mit einem niedrigeren IOPS-Wert auskommen, eine ganze Menge Geld sparen. Es kommt jedoch wirklich darauf an, was die letztendlichen Anforderungen für den jeweiligen Fall sind. Zu diesem Zweck eignen sich die i3.metal-Instanzen hervorragend für Mainstream-Anwendungen, die die Leistungsgrenzen von i3.metal nicht überschreiten oder nicht überschreiten können und nicht die IOPS benötigen, die ein All-Flash-Array vor Ort liefern würde Beispiel. Auch wenn Sie bereits zur Amazon-Familie gehören, ist der Wechsel zu Bare-Metal bekannt und es gibt wahrscheinlich einen Kostenvorteil, wenn Sie mehrere AWS-Programme in großen Mengen nutzen.
Besprechen Sie diese Rezension
Melden Sie sich für den StorageReview-Newsletter an
