Bare-Metal-Performance im Vergleich zu Cloud-VMs: Ein praktischer Vergleich

Beim Marketing für Cloud-Infrastrukturen geht's vor allem um Flexibilität, globale Reichweite und Managed Services. Der Leistungsvergleich zwischen Cloud-VMs und Bare-Metal-Hardware kommt in diesen Marketingmaterialien kaum vor, weil der Vergleich für anhaltende, vorhersehbare Workloads nicht gut für Cloud-VMs aussieht.

Dieser Artikel geht auf die genauen Mechanismen ein, warum Cloud-VMs nicht so gut laufen wie Bare-Metal-Server, wie du diese Unterschiede in deiner eigenen Umgebung messen kannst, in welchen Workload-Kategorien die Cloud wirklich besser ist und ab welchem monatlichen Ausgabenlevel Bare-Metal-Server die wirtschaftlich bessere Wahl sind.

CPU-Steal-Zeit: Der versteckte Leistungsabfall

Was ist CPU-Steal-Zeit?

Die CPU-Steal-Zeit misst, wie viel Prozent der Zeit die vCPU einer virtuellen Maschine darauf wartet, dass der Hypervisor sie auf einem physischen Kern einplant. Wenn sich mehrere VMs einen physischen Server teilen, konkurrieren ihre vCPUs um physische CPU-Zeit. Wenn deine VM was ausführen will, der Hypervisor aber gerade eine andere VM bedient, sammelt sich diese Wartezeit als Steal-Zeit an.

Die Steal-Zeit kann man unter Linux in der Spalte „st“ in der Ausgabe von „top“ oder „mpstat“ sehen. Auf einer gesunden, wenig ausgelasteten Cloud-VM kann die Steal-Zeit zwischen 0 und 2 % liegen. Auf einem stark ausgelasteten Cloud-Host während der Spitzenzeiten ist eine Steal-Zeit von 10 bis 30 % nicht ungewöhnlich und bedeutet, dass deine Anwendung 70 bis 90 % der CPU bekommt, auf der sie ihrer Meinung nach läuft.

Wie sich Zeitdiebstahl auf Anwendungen auswirkt

Die Auswirkungen von Diebstahlzeit sind nicht bei allen Arten von Arbeitslasten gleich:

• Latenzempfindliche Anwendungen (APIs, Datenbanken, Echtzeitverarbeitung): Die Steal- Zeit verlängert direkt die Antwortzeit. Eine 10-ms-Datenbankabfrage mit 15 % Steal-Zeit dauert 11,5 ms. Bei anhaltender Belastung steigt die p99-Latenz (die schlechtesten 1 % der Anfragen) überproportional an, weil die Steal-Zeit nicht gleichmäßig verteilt ist.
• Batch-Verarbeitung (ETL, Backups, Berichterstellung): Die Steal- Zeit verlängert die Gesamtdauer des Jobs proportional. Ein zweistündiger ETL-Job auf einer VM mit 20 % Steal-Zeit dauert 2,5 Stunden.
• Durchsatzbasierte Arbeitslasten (Dateiverarbeitung, Transcodierung): Der Durchsatz sinkt proportional zum Prozentsatz der Auslastung.

Auf Bare-Metal-Systemen ist die Steal-Zeit per Definition null. Der Prozessor wird nicht geteilt. Der Anwendungscode läuft, wenn das Betriebssystem ihn plant, nicht wenn ein Hypervisor die Erlaubnis erteilt.

Der Effekt des lauten Nachbarn

Wie gemeinsame Infrastruktur für Variabilität sorgt

Ein „Noisy Neighbor“ ist, wenn die Auslastung durch einen anderen Nutzer auf demselben Server die Leistung deiner Anwendung beeinträchtigt. Das betrifft nicht nur die CPU:

• Speicherdruck: Hypervisoren nutzen Memory-Balloon-Treiber, um RAM von VMs zurückzugewinnen, wenn der physische Hostspeicher knapp wird. Der deiner VM zugewiesene Speicher kann ohne Vorwarnung reduziert werden, was zu einem Swapping des Betriebssystems führt.
• Netzwerk-E/A: Physische Netzwerkkarten werden geteilt. Eine VM, die große Dateien überträgt, kann die Bandbreite der geteilten Netzwerkkarte voll auslasten und so den Netzwerkdurchsatz für alle VMs auf demselben Host beeinträchtigen.
• Speicher-E/A: Cloud-Blockspeicher (EBS, Persistent Disk) läuft über ein gemeinsames Netzwerk. Hohe E/A-Last von benachbarten Mandanten beeinträchtigt die IOPS für alle Mandanten, die diesen Speichercluster nutzen.

Cloud-Anbieter haben Kontrollen eingebaut (I/O-Credits, Bandbreitenbeschränkungen, CPU-Credit-Systeme), die den Schaden von lauten Nachbarn eindämmen. Diese Kontrollen schränken aber auch deine eigene Spitzenleistung ein. t3-Instanzen auf AWS nutzen CPU-Credits: super durchschnittliche Leistung mit Burst-Fähigkeit, aber anhaltende CPU-intensive Workloads verbrauchen die Credits und drosseln die Leistung auf den Basiswert.

Speicherbandbreite auf Bare-Metal-Servern im Vergleich zu Cloud-VMs

Die Speicherbandbreite ist oft der Engpass bei Datenbank- und Analyse-Workloads, aber in den Spezifikationen von Cloud-VMs wird die Speicherbandbreite normalerweise nicht angegeben. Der Grund: Cloud-VMs teilen sich die Speicherkanäle des physischen Servers mit anderen VMs, sodass die verfügbare Bandbreite pro VM nur ein Bruchteil der Gesamtbandbreite der physischen Hardware ist.

Ein physischer Server mit DDR5-4800 in einer 4-Kanal-Konfiguration hat eine theoretische Spitzenbandbreite von ungefähr 153 GB/s. Auf einem physischen Host mit 4 VMs kommt die effektive Speicherbandbreite jeder VM unter idealen Bedingungen auf fast 38 GB/s. Bei Konflikten sinkt sie noch weiter.

Auf dem Extreme Dedicated Server von InMotion steht dir die volle DDR5-Bandbreite von 153 GB/s für deine Aufgaben zur Verfügung. Bei Analysejobs, die große Datensätze scannen, ist dieser Unterschied der Hauptgrund für die Leistungssteigerung, wenn man von der Cloud auf Bare Metal umsteigt.

Speicher-I/O: Netzwerkgebunden vs. direktes NVMe

Cloud-Blockspeicherarchitektur

AWS EBS, Google Persistent Disk und Azure Managed Disks sind Netzwerkspeichersysteme. Deine VM schickt Block-E/A-Anfragen über das interne Netzwerk des Rechenzentrums an einen Speichercluster. Das sorgt für eine zusätzliche Latenz von etwa 0,5 bis 2 ms pro E/A-Vorgang im Vergleich zu lokalem Speicher und begrenzt die maximale IOPS und den Durchsatz je nach der für das Volume bereitgestellten Stufe.

Lagerung Typ	Typische Latenz	Sequentielles Lesen	Zufällige IOPS	Kosten
AWS EBS gp3 (bereitgestellt)	0,5–1 ms	1.000 MB/s (maximal)	16.000 IOPS (maximal)	0,08 $/GB/Monat + IOPS-Gebühren
AWS EBS io2 Block Express	0,1–0,2 ms	4.000 MB/s	256.000 IOPS (maximal)	0,125 $/GB/Monat + 0,065 $/bereitgestellte IOPS
InMotion NVMe direkt)	0,05–0,1 ms	5.000–7.000 MB/s	500.000–1 Mio. IOPS	In den Serverkosten enthalten

Der Kostenvergleich ist echt krass. 3,84 TB AWS EBS gp3-Speicher kosten ungefähr 307 $ pro Monat nur für das Volumen, ohne IOPS-Bereitstellung. Die gleichen 3,84 TB NVMe gibt's beim Extreme Dedicated Server InMotion Hostingzu einem günstigeren Preis. Cloud-Speicher ist preislich nicht so, dass er mit lokalem NVMe mithalten kann.

Unterschiede in der Netzwerkleistung

Latenz für Endnutzer

Sowohl Cloud- als auch dedizierte Server haben Latenzeigenschaften, die hauptsächlich von der physischen Entfernung zu den Endnutzern und der Qualität des Netzwerk-Routings abhängen. Cloud-Anbieter haben einen globalen Vertriebsvorteil: AWS, Google und Azure haben Standorte auf allen Kontinenten, während InMotion Hosting Rechenzentren in Los Angeles und Amsterdam InMotion Hosting .

Für Apps, die vor allem Leute in Nordamerika und Westeuropa bedienen, decken die Rechenzentren von InMotion die wichtigsten Nutzergruppen ab. Los Angeles erreicht Leute in Nordamerika super; Amsterdam bedient Leute in Westeuropa mit geringer Latenz und erfüllt die EU-Vorgaben zur Datenhoheit. Apps, die in Südostasien, Australien oder Südamerika präsent sein müssen, brauchen vielleicht eine CDN-Schicht oder eine geografisch verteilte Cloud-Bereitstellung.

Vorhersehbarkeit vs. Spitzenleistung

Die Bandbreite von Cloud-Netzwerken hängt normalerweise von Burst-Limits auf Instanzebene und der gemeinsamen NIC-Kapazität ab. Ein c5.2xlarge auf AWS bietet bis zu 10 Gbit/s Netzwerkbandbreite, die als „Bis zu 10 Gbit/s“ bezeichnet wird. Das heißt, es gibt Burst-Zugriff auf 10 Gbit/s, wobei der tatsächliche nachhaltige Durchsatz niedriger ist und dem Traffic-Management unterliegt.

Die dedizierten Server von InMotion haben einen 1-Gbit/s-Port, den man auf einen garantierten 10-Gbit/s-Port ohne Datenvolumenbegrenzung aufrüsten kann. Garantierte 10 Gbit/s sind was anderes als „bis zu 10 Gbit/s Burst“. Für Anwendungen, die eine anhaltend hohe Bandbreite brauchen (wie Video-Streaming, Verteilung großer Dateien oder Datenerfassung), ist eine garantierte Bandbreite echt wichtig.

Benchmark: Latenz bei Datenbankabfragen

Ein praktischer Vergleich der Latenz bei Datenbankabfragen von p50 und p99 auf Cloud-VMs im Vergleich zu Bare-Metal-Servern für eine mittelgroße PostgreSQL (50 GB Arbeitsspeicher, Standard-OLTP-Abfragemix):

Umwelt	p50 Latenz	p99 Latenz	CPU-Auslastung (Durchschnitt)	Anmerkungen
AWS RDS db.r5.2xlarge	4 ms	45 ms	Nicht zutreffend (verwaltet)	Netzwerk-Overhead zum RDS-Endpunkt
AWS EC2 r5.2xlarge (64 GB)	3 ms	38 ms	3–12 %	EBS-Speicher-Overhead + Steal-Zeit
InMotion Advanced (64 GB DDR4, NVMe)	2,5 ms	12 ms	0%	Lokales NVMe, keine Zeitverschwendung
InMotion Extreme (192 GB DDR5 ECC, NVMe)	1,8 ms	8 ms	0%	Vollständiger Arbeitssatz im Pufferpool

Bei der p99-Latenz ist der Unterschied am deutlichsten. Die schlechtesten 1 % der Anfragen auf der Cloud-Infrastruktur haben mit Steal-Time-Spitzen und Schwankungen im Speichernetzwerk zu kämpfen. Auf Bare-Metal-Systemen bleibt die p99-Leistung nah am Median, weil es diese Schwankungen nicht gibt.

Wo Cloud-VMs punkten

Ein ehrlicher Vergleich zeigt, in welchen Bereichen die Cloud-Infrastruktur dedizierte Bare-Metal-Server wirklich übertrifft:

• Automatische Skalierung: Die Cloud -Infrastruktur lässt sich in wenigen Minuten horizontal skalieren. Das Hinzufügen eines Bare-Metal-Servers dauert Stunden bis Tage.
• Weltweite Verteilung: 15–30 Cloud-Regionen im Vergleich zu 2 Standorten von InMotion-Rechenzentren. Anwendungen, die auf mehreren Kontinenten verfügbar sein müssen, profitieren von der globalen Reichweite der Cloud.
• Managed Services: RDS , ElastiCache, Lambda und ähnliche Managed Services machen Teams ohne eigenes Infrastrukturpersonal das Leben leichter.
• Intermittierende Arbeitslasten: Ein Batch-Job, der zwei Stunden pro Woche läuft, kostet auf Cloud-Spot-Instanzen nur ein paar Cent. Ein dedizierter Server kostet dasselbe, egal ob er eine Stunde oder 720 Stunden pro Monat läuft.

Die Entscheidung treffen

• Wenn deine Workload ständig läuft und eine vorhersehbare Leistung braucht: Bare-Metal-Dedicated ist in Sachen Kosten und Leistung einfach top.
• Wenn deine Arbeitslast plötzlich und unvorhersehbar steigt: Die Flexibilität der Cloud kann die höheren Kosten rechtfertigen.
  • Wenn du mehr als 300 Dollar pro Monat für Cloud-Computing für eine stabile Arbeitslast ausgibst: Mach den Bare-Metal-Vergleich.
• Wenn die Variabilität der p99-Latenzzeit deine Anwendungs-SLAs beeinträchtigt: Die Null-Steal-Zeit von Bare Metal geht direkt an die Wurzel des Problems.