Wer Private Cloud empfiehlt, sollte selbst darin leben
CCsolutions berät Unternehmen, die eine Migration von Public Cloud zu privater Infrastruktur evaluieren. Über ein Jahr lang lief unser eigener Monitoring-Stack auf DigitalOcean. Die Inkonsequenz war offensichtlich. Wir predigten die Vorteile der Private Cloud, während wir Premium für geteilte virtuelle Maschinen zahlten.
Dieser Artikel dokumentiert genau, wie wir Grafana, Loki und Mimir von DigitalOcean auf Hetzner Baremetal mit Syself-Management bewegt haben. Ohne Marketing-Filter. Mit allen Zahlen.
Das Problem mit dem alten Setup
Unser Stack auf DigitalOcean bestand aus 6 virtualisierten Nodes, jeder mit 8 vCPU und 32 GB RAM. Monatliche Kosten: rund 2.000 Euro. Auf dem Papier ausreichend für ein kleines Team mit moderatem Log- und Metrikvolumen. In der Praxis eine Reihe operativer Probleme.
Erstes Kopfweh: OOM-Fehler bei Loki und Mimir alle paar Tage. Die Kompaktierung historischer Mimir-Blöcke verbrauchte zeitweise mehr als 25 GB RAM, genug um den OOM-Killer auszulösen. Jeder Neustart bedeutete temporären Datenverlust im Monitoring, genau dann wenn man es am dringendsten braucht.
Zweitens: Query-Latenz. Grafana-Dashboards mit 30 Tagen Daten luden in 8 bis 12 Sekunden. Mit 90 Tagen, 30 Sekunden und mehr. Der Grund ist simpel. Block Storage auf shared VMs liefert nicht den I/O-Durchsatz, den Loki für das Index-Scanning braucht.
Drittens, und am wichtigsten für unsere Strategie: null Kontrolle über die zugrundeliegende Hardware. Bei virtuellen Maschinen weißt du nicht, mit wem du den Hypervisor teilst. Dein lauter Nachbar kann zur Unzeit Disk-Bandbreite konsumieren. Für ein kritisches Monitoring-System ist diese Unvorhersehbarkeit inakzeptabel.
Warum Hetzner Baremetal mit Syself
Wir evaluierten vier Optionen. Den DigitalOcean-Plan aufstocken. Zu AWS oder GCP mit Dedicated Instances migrieren. Baremetal bei OVH oder Hetzner mieten. Einen eigenen Cluster on-premises bauen.
Die erste verwarfen wir, weil sie das ökonomische Problem skalierte ohne die Wurzel zu lösen. AWS und GCP fielen wegen Kosten raus: eine EC2-Dedicated-Instance mit vergleichbaren Specs kostet das Doppelte. On-premises braucht Datacenter-Personal, das wir nicht haben.
Hetzner Baremetal gewann durch eine seltene Kombination: niedriger Preis, moderne Hardware, europäische Rechenzentren mit niedriger Latenz nach DACH und LATAM, und akzeptable APIs für Automatisierung.
Das zweite Problem war die Kubernetes-Control-Plane. Manueller Bootstrap mit kubeadm ist machbar, aber Control-Plane-Upgrades und Tagesbetrieb fressen Zeit aus dem Team. Hier kam Syself ins Spiel, ein Provider der den Kubernetes-Cluster auf fremder Hardware managt. Du zahlst für das Control-Plane-Management und behältst volle Kontrolle über Workers und Daten.
Hardware und finale Architektur
Vier Baremetal-Nodes bei Hetzner. Specs pro Node:
- AMD Ryzen, 16 physische Cores
- 64 GB RAM DDR4 ECC
- 1 TB NVMe SSD
Gesamtkapazität des Clusters: 64 physische Cores, 256 GB RAM, 4 TB lokaler NVMe-Storage.
Die Kubernetes-Control-Plane managt Syself in eigener Infrastruktur. Die 4 Nodes sind Workers, auf denen der gesamte Stack läuft: Grafana für Visualisierung, Loki für Log-Aggregation, Mimir für Langzeit-Metriken, und die Agents von beiden (Promtail, Grafana Agent).
Der Storage ist der fundamentale Wechsel. Vorher hingen wir an Block Volumes von DigitalOcean. Jetzt haben wir lokales NVMe auf jedem Worker. Für Loki und Mimir, die I/O-sensitiv sind, ist der Effekt direkt. Queries, die früher Sekunden brauchten, laufen jetzt in Millisekunden.
Der Migrationsprozess
Die Migration dauerte drei Wochen, ohne Monitoring-Downtime. Die wichtigen Schritte:
Woche 1: Provisionierung und Validierung. Wir provisionierten die 4 Nodes bei Hetzner, verbanden sie mit der Syself-Control-Plane, konfigurierten Networking und Storage. Wir validierten, dass der Cluster die Kubernetes-Tests (Basis-e2e-Tests) bestand, bevor wir produktive Workloads anfassten.
Woche 2: Datenreplikation. Wir konfigurierten Mimir und Loki im neuen Cluster mit demselben S3-Bucket wie der alte Cluster. Beide Cluster schrieben mehrere Tage lang in dieselbe Datenquelle, um Konsistenz zu garantieren. Grafana wurde mit parallelen Datasources konfiguriert.
Woche 3: Traffic-Wechsel. Wir richteten die Agents der produktiven Umgebungen auf den neuen Cluster aus. Wir verifizierten, dass die Dashboards identisch funktionierten. Den alten Cluster behielten wir 5 zusätzliche Tage als Sicherheitsnetz. Danach Termination.
Null Datenverlust, null Wartungsfenster, null Anrufe um 3 Uhr morgens.
Ergebnisse mit echten Zahlen
Nach drei Monaten produktivem Betrieb:
| Metrik | Vorher (DigitalOcean) | Nachher (Hetzner) | Änderung | |---|---|---|---| | Monatskosten | ~2.000 EUR | ~1.000 bis 1.100 EUR | 40 bis 50% weniger | | Gesamt CPU Cores | 48 vCPU | 64 physische Cores | 33% mehr | | Gesamt RAM | 192 GB | 256 GB | 33% mehr | | OOM-Fehler | Alle 2 bis 3 Tage | Null in 90 Tagen | Eliminiert | | Query-Latenz 30 Tage | 8 bis 12s | < 1s | 10x schneller | | Query-Latenz 90 Tage | 30s+ | 2 bis 3s | 10x schneller |
Die echte Ersparnis ist größer als die nominellen 40%, weil wir nicht äquivalente Kapazität vergleichen. Wir zahlen weniger für mehr Ressourcen. Der Unterschied zwischen virtualisierten vCPU mit Shared Tenancy und dedizierten physischen Cores zählt auch. Mimir-Spitzen konkurrieren nicht mehr mit unbekannten Workloads.
Was wir gelernt haben
Drei Erkenntnisse, die wir in Kundenprojekte mitnehmen.
Die Kostenersparnis ist real, aber operative Konsistenz ist wichtiger. Monitoring ist die erste Infrastruktur, die ein SRE-Team stabil braucht. Wenn dein Grafana während eines Vorfalls ausfällt, hast du das Problem multipliziert. Null OOM-Fehler in 90 Tagen sind mehr wert als 40% Ersparnis.
I/O ist der versteckte Engpass. In den meisten Stacks, die wir evaluieren, ist der Bottleneck nicht CPU oder RAM, sondern Storage-Throughput. Lokales NVMe eliminiert dieses Problem. Wenn deine Workloads disk-sensitiv sind (Datenbanken, Log-Systeme, Metrik-Systeme), erwäge Baremetal vor VMs.
Managed Kubernetes auf eigener Hardware ist ein wenig genutzter Sweet Spot. Die meisten Teams wählen zwischen vollständig managed (EKS, AKS, GKE) oder vollständig self-hosted. Die Mittelweg-Option, gemanagte Control Plane mit eigenen Workers, kombiniert das Beste aus beiden Welten. Operative Einfachheit ohne Souveränitätsverlust über die Daten.
Fazit
Unsere eigene Monitoring-Migration war kein Kundenprojekt. Sie war eine Validierung der These, die wir verkaufen. Wenn wir Private Cloud Kunden mit kosten- oder compliance-sensitiven Workloads empfehlen, wollen wir diese Reise selbst gemacht haben, mit allen Fehlern und Lernerfahrungen.
Wenn ihr eine ähnliche Migration evaluiert und über Details sprechen wollt, die in einen Blog-Post nicht passen (exakte Mimir-Konfiguration, Datentransferkosten, Provider-Optionen in DACH), bucht ein kostenloses 45-Minuten-Gespräch. Wir teilen, was wir wissen.
Mitgründer von CCsolutions. Über ein Jahrzehnt Erfahrung im Aufbau von Infrastruktur für regulierte Branchen (Finanzen, Gesundheit, Energie). Spezialisiert auf Kubernetes, FinOps und private KI-Architekturen. Schreibt über das, was funktioniert und was nicht, mit echten Zahlen.
Mehr über uns