Dedizierte Server statt VM: das bessere Preis-Leistungs-Verhältnis – und was man dafür übernimmt

Die meisten Diskussionen über Infrastruktur enden bei „Cloud oder nicht“. Die interessantere Frage liegt eine Ebene tiefer: dedizierte Hardware oder virtuelle Maschine. Darauf gibt es eine ziemlich unromantische Antwort – bei planbarer Dauerlast hat Blech das mit Abstand bessere Preis-Leistungs-Verhältnis. Trotzdem trauen sich viele nicht ran. Nicht, weil die Rechnung nicht aufginge, sondern weil man mit dem Blech Verantwortung übernimmt, die einem der Hypervisor vorher abgenommen hat.

Genau diese Verantwortung ist unser Job. Deshalb hier der ehrliche Tausch: was man gewinnt, was man dafür wirklich tun muss – und mit welchen Werkzeugen wir den zweiten Teil abdecken.

Der Tausch: was man gewinnt

• Dedizierte Kerne statt vCPU. Keine Steal Time, keine lauten Nachbarn, keine Leistung, die je nach Tageszeit schwankt. Für Datenbanken und alles Latenz-Sensitive ist das der Hauptgrund, nicht der Preis.

• RAM und NVMe in Größenordnungen, die virtualisiert absurd teuer werden. Eine MySQL-Instanz mit zweistelligem GB-Buffer-Pool ist auf Blech eine Selbstverständlichkeit statt einer Budgetfrage.

• Lokale NVMe statt Netzwerk-Storage. Keine IOPS-Kontingente, keine Storage-Rechnung, die mit der Nutzung mitwächst.

• Planbare Kosten. Ein Festpreis pro Monat statt einer nutzungsbasierten Abrechnung, die man erst am Monatsende versteht. Gerade Storage und Traffic kippen einen Vergleich oft deutlicher als der reine Compute-Preis.

Und was man dafür übernimmt

• Die Fehlerdomäne gehört dir. Auf einer VM stirbt eine Platte, und der Hypervisor schiebt dich weg – im Zweifel merkst du es nie. Auf Blech ist es deine Platte, dein DIMM, dein Netzteil.

• Kein Snapshot, kein „mal eben zurückrollen“. Der Ersatz dafür ist zweiteilig: echte Backups mit geübtem Restore und ein vollständig in Ansible beschriebener Host. Der zweite Teil wird unterschätzt – wenn die Maschine reproduzierbar ist, ist der Neuaufbau kein Drama, sondern ein Playbook-Lauf.

• Skalierung ist grobkörnig. Man fügt keine zwei vCPUs hinzu, man zieht auf die nächste Maschine. Das will vorher gedacht sein – dafür verschiebt eine ordentlich dimensionierte Maschine diese Grenze erst einmal sehr weit nach hinten.

• Bereitstellung dauert. Nicht Sekunden, eher Stunden, und ein Hardwaretausch hat Vorlaufzeit. Also Reserve einplanen, statt auf Elastizität zu hoffen.

• Die Hardware muss man selbst im Blick behalten. Eine VM hat einem noch nie von einem Lüfter erzählt.

Zusammengefasst: Die VM verkauft dir das Vergessen der Hardware. Auf Blech musst du sie kennen – und dafür bekommst du sie ganz.

Diesen zweiten Teil übernehmen wir, wenn du magst – das Leistungsbild dazu steht auf unserer Seite zu Managed Dedicated Servern. Wie er in der Praxis aussieht, im Rest dieses Artikels.

Was das in Zahlen heißt

Seit dem 15. Juni 2026 gelten bei Hetzner neue Cloud-Preise, und am deutlichsten trifft es ausgerechnet die Instanzen mit dedizierten vCPUs. Für die Standorte Deutschland und Finnland, inklusive 19 % MwSt. und ohne IPv4:

• CCX23: 4 dedizierte vCPUs, 16 GB RAM, 160 GB NVMe. Von 37,47 € auf 102,33 € im Monat – gut das Zweieinhalbfache.

• CCX33: 8 dedizierte vCPUs, 32 GB RAM, 240 GB NVMe. Von 74,36 € auf 164,80 € im Monat.

• Die geteilten CX-Instanzen sind moderater gestiegen: CX23 von 4,75 € auf 6,53 €, CX33 von 7,72 € auf 10,10 €. Dafür sind genau diese günstigen Größen derzeit in den meisten Standorten kaum verfügbar – was wenig nützt, wenn man gerade eine Maschine braucht.

Jetzt der Vergleich, für den sich das Rechnen lohnt. Ein AX42 – acht echte Kerne auf einem Ryzen 7 PRO 8700GE, 64 GB DDR5 mit ECC, zwei NVMe-SSDs zu je 512 GB – kostet 115,79 € im Monat plus 58,31 € einmalig zur Einrichtung. Stell das neben die CCX33: ebenfalls acht Kerne, aber 32 statt 64 GB RAM, 240 GB statt einem Terabyte Speicher, und 164,80 € statt 115,79 € im Monat. Die dedizierte Maschine ist also die kleinere Rechnung bei der größeren Ausstattung, dazu mit Fehlerkorrektur im Speicher und lokaler NVMe ohne IOPS-Kontingent. Wer aus der Serverbörse kauft, liegt noch einmal deutlich darunter: AX41 und EX44 stehen dort bei 68,19 € im Monat ohne Einrichtungsgebühr – gebrauchte Hardware, bei der sich der Abnahme-Check aus dem nächsten Abschnitt unmittelbar bezahlt macht.

Dazu kommt ein Punkt, der sich schlecht in eine Tabelle schreiben lässt: Zum Zeitpunkt dieses Artikels weist der Hetzner-Shop die CCX-Instanzen als aktuell nicht bestellbar aus, und auch die günstigen CX-Größen sind in den meisten Standorten knapp. Der beste Preis nützt wenig, wenn die Maschine nicht verfügbar ist – bei dedizierter Hardware ist die Lieferzeit dafür planbar, und über die Serverbörse steht sie oft am selben Tag.

Zwei Einschränkungen, damit die Rechnung ehrlich bleibt: Sie gilt für Dauerlast. Wer Maschinen stundenweise hochfährt, sie nach dem Lasttest wieder wegwirft oder täglich zwischen Regionen schiebt, fährt mit der Cloud weiterhin besser – dafür ist sie gebaut. Und die Einrichtungsgebühr will eingerechnet werden: Über zwölf Monate verteilt relativiert sie sich, über zwei Monate nicht. Der Punkt ist nicht „Cloud ist teuer“, sondern: Bevor du den neuen Preis für eine Cloud-Instanz mit dedizierter CPU bezahlst, schau dir an, was dieselbe Summe als eigene Maschine kauft. Der Abstand ist seit Juni deutlich größer geworden.

Hardware sichtbar machen: Temperaturen, Watt, Lüfter

Der letzte Punkt ist der, an dem sich entscheidet, ob Blech eine gute oder eine leichtsinnige Idee ist. Auf jedem unserer Hardware-Hosts läuft deshalb ein eigenes Skript, das im Minutentakt alles einsammelt, was die Maschine über sich preisgibt, und es im Prometheus-Format ausgibt. Telegraf liest es ein, gespeichert wird in einer VictoriaMetrics-Zeitreihendatenbank, dargestellt in einem Grafana-Dashboard.

Woher die Werte kommen, entscheidet das Skript je Maschine selbst: IPMI beziehungsweise das BMC, lm-sensors, die Thermal-Zones des Kernels, hwmon, SMART samt drivetemp für die Plattentemperaturen, ssacli für die RAID-Controller in den ProLiants, nvidia-smi auf dem GPU-Host. Was eine Maschine nicht kann, meldet das Skript als fehlende Capability mit. Man sieht im Dashboard also, warum eine Kurve fehlt, statt zu rätseln, ob der Sensor kaputt oder nie vorhanden war.

Erfasst werden Temperaturen getrennt nach Quelle – CPU, System, Platten, GPU, Netzteil, Chipsatz –, die Leistungsaufnahme in Watt samt Stromstärke und Spannungen, soweit das BMC sie liefert, und die Lüfterdrehzahlen. Der Stromverbrauch ist dabei mehr als eine Zahl fürs Datenblatt: Ein Server, der bei gleicher Last plötzlich mehr zieht und dessen Lüfter hochdrehen, erzählt von einem Problem, bevor irgendein Prozess langsamer wird.

Ein Detail, das zum Gesamtbild gehört: Telegraf darf diese Werkzeuge über eine eng gefasste sudo-Regel aufrufen – namentlich aufgeführte Kommandos, keine Blankovollmacht, und auch die Kernelmodule, die es laden darf, sind einzeln aufgezählt. Monitoring, das sich selbst zum Risiko macht, wäre ein schlechter Tausch. Über allem liegt Icinga2 als Alarmierungsschicht, inklusive RAID-Check. Grafana zeigt den Verlauf, Icinga weckt jemanden.

Abnahme statt Vertrauen: der Check vor der Inbetriebnahme

Laufende Überwachung hilft nur bei Maschinen, die man schon hat. Die zweite Hälfte ist die Abnahme. Auf jedem Hardware-Host liegt dafür ein Skript, das einen vollständigen Hardware- und Disk-Health-Report zieht – gedacht für den Moment, bevor man einen Server übernimmt, etwa aus einer Serverbörse, und bevor er in Produktion geht.

Es liest zuerst das Inventar aus: Hersteller, Modell, Mainboard, BIOS-Version und -Datum, CPU, dazu jedes Speichermodul einzeln mit Bestückung, Typ und Takt – und ob ECC tatsächlich aktiv ist. Danach kommen die Zahlen, die weh tun können:

• ECC-Fehlerzähler aus EDAC: korrigierbare Fehler sind eine Warnung im Sinne von „dieses Modul beobachten“, unkorrigierbare sind kritisch. Das ist der Check, den auf einer VM niemand je zu sehen bekommt.

• SMART pro Platte, mit getrennten Regeln für NVMe und SATA/SAS. Bei NVMe die verbrauchte Endurance in Prozent, verbleibende Reserve-Blöcke, Media-Errors, Critical-Warning-Flags und die geschriebene Datenmenge. Bei SATA reallozierte, schwebende und unkorrigierbare Sektoren, CRC-Fehler samt Hinweis, dass die meist vom Kabel kommen und nicht von der Platte, plus der herstellerabhängige Verschleißindikator.

• Betriebsstunden, umgerechnet in Jahre. Bei gebrauchten Maschinen die erste Zahl, die man sehen will.

• RAID-Status für mdadm und ZFS sowie Storage-Fehler im Kernel-Log.

Am Ende steht ein Urteil in drei Stufen, ausgegeben als Nagios-Exit-Code: alles gut, nutzbar aber im Auge behalten, oder nicht abnehmen und nicht in Produktion geben. Das Skript kann außerdem auf allen Platten einen SMART-Selbsttest anstoßen – und es meldet, wenn auf einer Platte noch nie einer gelaufen ist. Das ist der Unterschied zwischen „günstige Hardware bestellt“ und „günstige Hardware verantwortet“.

Drei Fälle aus der Praxis

Am aufschlussreichsten ist, wie unterschiedlich die Fälle aussehen, in denen wir Blech einsetzen – und wie ähnlich sie im Betrieb sind.

Blech, das im Lager steht. Für KRUU betreuen wir fünf Server, die in den Fulfillment-Centern in Europa und den USA stehen, teils betagte ProLiants. Sie stehen dort, wo die Ware ist, weil der Warenausgang weiterlaufen muss, auch wenn die Leitung nach draußen es gerade nicht tut, und weil Scanner und Drucker keine Lust auf Umwege haben. Darauf laufen Docker, Node.js-Anwendungen, GitLab-Runner und RabbitMQ; fluent-bit schickt die Logs zentral hinaus, damit man von außen sieht, was drinnen passiert. Angebunden sind sie über ein Site-to-Site-VPN und verwaltet mit demselben Ansible wie alles andere – Standort und Besitzverhältnis ändern am Betriebsmodell nichts. Ehrlicherweise gehört dazu: Ein Lager ist kein Rechenzentrum. Staub, Temperatur und Stromversorgung sind dort reale Themen, und genau deshalb liegen die Temperaturen und Lüfterdrehzahlen dieser Maschinen in Grafana.

Blech als Normalfall. Ein Kunde mit großem Server-Park fährt darauf seine Anwendungsserver, MySQL-Primary und -Replica auf getrennten Maschinen, einen eigenen ClickHouse-Server und Elasticsearch. Daneben stehen Cloud-VMs – aber nur dort, wo es um Nähe zum Nutzer geht und nicht um Rechenleistung. Das ist die eigentliche Botschaft: kein Entweder-oder. Blech dort, wo Dauerlast und Datenbanken liegen, VMs dort, wo Geografie oder kurze Lebensdauer zählen.

Die eigene Backup-Infrastruktur. Zwei dedizierte Maschinen mit vielen Platten an zwei Standorten, darauf SeaweedFS als S3-kompatibler Objektspeicher plus VictoriaLogs. Wir sichern unsere Kunden auf eigene Hardware statt in fremden Objektspeicher. Hier ist Blech kein Kompromiss, sondern der ganze Punkt: Speicher pro Euro, ohne Abruf- und Traffic-Kosten, die mit der Nutzung wachsen.

Die Einwände, ehrlich beantwortet

• „Und wenn eine Platte stirbt?“ Sie stirbt irgendwann. Deshalb RAID, deshalb SMART-Trends statt Momentaufnahme, deshalb Backups außer Haus. Die Frage ist nicht ob, sondern ob man es vorher sieht und ob der Wiederanlauf geübt ist.

• „Kein Snapshot, kein Rollback.“ Stimmt. Der Ersatz ist der bessere: ein Host, der vollständig in Ansible beschrieben ist, plus Restore aus dem Backup. Ein Snapshot rettet dich vor deinem eigenen Fehler, nicht vor einem Hardwareschaden – dafür brauchst du ohnehin das Backup.

• „Wer fährt nachts ins Rechenzentrum?“ Niemand. Fernwartung über BMC beziehungsweise iLO, Rescue-System, Remote Hands beim Anbieter. Bei Hardware, die beim Kunden vor Ort steht, ist die Antwort eine andere und muss vorher geklärt sein: Ersatzteil vor Ort und eine klare Zuständigkeit.

• „Gebrauchte Hardware aus der Börse?“ Genau dafür der Abnahme-Check. Betriebsstunden, Verschleiß, ECC-Fehler, nie gelaufener Selbsttest – wenn das Bild nicht stimmt, wird die Maschine nicht angenommen.

• „Wir sind zu klein für eigene Server.“ Meist ist es andersherum. Gerade bei planbarer Dauerlast – Datenbanken, Backups, Analytics – ist Blech früher wirtschaftlich, als man denkt. Elastizität zahlt sich nur aus, wenn man sie wirklich nutzt.

Du willst die Leistung, aber nicht die Verantwortung allein tragen?

Wir betreiben dedizierte Maschinen und Cloud-VMs mit demselben Ansible, demselben Monitoring und derselben Backup-Strecke – als Managed Dedicated Server, provider-unabhängig und mit 24/7-Bereitschaft. Dazu gehören die Abnahme neuer Hardware, Temperatur- und Verbrauchsüberwachung, RAID- und SMART-Trends sowie ein Restore, den wir üben, statt ihn zu versprechen. Schreib uns – wir rechnen dir den Vergleich für deine Last durch, ehrlich in beide Richtungen.