Ein Kunde, der mehr als 20 Webanwendungen betreibt, hatte seine Infrastruktur auf 7 Maschinen bei zwei verschiedenen Anbietern verstreut: einige Anwendungen auf 5 Hosting-VMs in Rumänien und zwei weitere auf zwei dedizierten Servern, gemietet bei Hetzner. Doppelte Kosten, inkonsistente Sicherheit und keinerlei einheitliche Übersicht. Wir haben alles auf einem einzigen neuen Debian-Server mit KVM-Virtualisierung konsolidiert — mit einem echten Sicherheitsperimeter und 24/7-Monitoring. Umgesetzt im April 2025, bei Hetzner, auf Debian 12 (Bookworm), auf einem Dual-CPU-Server mit 128 GB RAM.
Der Kontext
Die Infrastruktur des Kunden war organisch gewachsen, ohne einheitlichen Plan:
- 5 VMs bei einem rumänischen Hosting-Anbieter, auf denen die meisten der 20+ Webanwendungen liefen
- 2 dedizierte Server, gemietet bei Hetzner, jeweils mit eigenen Anwendungen und Konfigurationen
- Zwei Anbieter, zwei Rechnungen, zwei unterschiedliche Verwaltungsmodelle
- Sicherheit in Teilen — jede Maschine mit eigenen Regeln (oder ohne), ohne zentralen Kontrollpunkt
- Kein zentrales Monitoring: ein Problem an einer Anwendung wurde bemerkt, wenn der Kunde anrief, nicht vorher
Das Geschäftsrisiko war nicht eine einzelne ausgefallene Anwendung, sondern der Mangel an Kontrolle und Übersicht über alles, was in Produktion lief.
Die Herausforderung
Wir mussten alles konsolidieren, ohne die Anwendungen neu zu schreiben und ohne lange Ausfallzeiten, und dabei die Workloads isoliert halten — die alten Anwendungen durften sich nicht gegenseitig beeinflussen. Außerdem wollte der Kunde niedrigere Kosten und eine einzige Verwaltung, aber ohne Kompromisse bei der Sicherheit.
Die vorgeschlagene Lösung
Nach technischen Gesprächen mit dem Kunden war die Entscheidung klar: ein einziger neuer, leistungsstärkerer physischer Server bei Hetzner, umgewandelt in einen Virtualisierungs-Host. Darauf haben wir eine KVM-Umgebung mit drei virtuellen Maschinen aufgebaut, jede mit einer klar definierten Rolle:
- Debian-Linux-Host — das Basissystem, gehärtet und in einen Sicherheitsperimeter und einzigen Einstiegspunkt verwandelt
- KVM als Hypervisor — echte Isolation zwischen Workloads, Snapshots, flexible Ressourcenzuteilung
- 3 VMs — zwei für die beiden alten dedizierten Server, eine für alle Anwendungen der 5 rumänischen VMs
Warum KVM und nicht Proxmox oder VMware
Wir wollten einen einzigen schlanken Server, der sowohl Virtualisierung als auch den Sicherheitsperimeter übernimmt — nginx, Suricata und GeoIP laufen auf demselben Debian-Host. KVM ist der native Linux-Hypervisor: keine Lizenzkosten, volle Kontrolle, direkte Integration mit dem Host, ohne zusätzliche Management-Schicht. Proxmox oder VMware hätten hier unnötige Komplexität hinzugefügt — zudem ist echtes HA auf nur zwei Proxmox-Knoten problematisch: ein Cluster braucht eine dritte Stimme für das Quorum, sonst riskiert man Split-Brain. Für einen einzigen Host mit schneller Wiederherstellung auf einem Standby-Server war Debian + KVM die richtige Wahl.
Kurz gesagt, die Umwandlung:
Die Umsetzung
Schritt 1 — Debian-Host + KVM
Auf dem neuen Server haben wir Debian Linux als Host-System installiert, nach Best Practices gehärtet (minimale Dienste, SSH per Schlüssel, nftables-Firewall, Kernel-Tuning). Darüber KVM/QEMU + libvirt als Virtualisierungsschicht. So läuft jede Anwendung oder Anwendungsgruppe isoliert in ihrer eigenen VM, ohne den Rest beeinflussen zu können.
Schritt 2 — Migration der zwei dedizierten Server (Image-Level)
Die beiden alten physischen dedizierten Server bei Hetzner wurden auf Image-Ebene migriert (P2V — physical to virtual), jeweils in eine eigene VM auf dem neuen Host. Wir haben den gesamten Server übernommen — Betriebssystem, Konfigurationen, Anwendungen — genau so, wie er war, ohne Neuinstallation und ohne manuelle Neukonfiguration. Die Anwendungen starteten in der VM identisch zur alten Umgebung.
Schritt 3 — Konsolidierung der 5 rumänischen VMs
Die 20+ Webanwendungen, verteilt auf die 5 Hosting-VMs in Rumänien, wurden in eine einzige VM auf dem neuen Server migriert. Wir haben die Anwendungen gruppiert, die Abhängigkeiten neu aufgebaut (Runtimes und Datenbanken nach Bedarf) und jede Anwendung validiert, bevor wir die alte Umgebung abgeschaltet haben.
Sicherheit — der Host als Perimeter
Der gesamte Verkehr läuft jetzt über einen einzigen kontrollierten Punkt auf dem Host, bevor er eine Anwendung erreicht. Das ermöglichte uns, einen echten Sicherheitsperimeter aufzubauen, identisch für alle 20+ Anwendungen:
- nginx als Reverse Proxy — einziger Einstiegspunkt für alle Anwendungen der 3 VMs. Zentrale TLS-Terminierung, Zertifikate an einem Ort verwaltet, Routing pro Domain/Anwendung, konsistentes Rate Limiting und Security-Header. Die Anwendungen in den VMs sind nicht direkt dem Internet ausgesetzt.
- GeoIP-Filterung — Filterung auf Länderebene direkt auf dem Host. Wir verkleinern die Angriffsfläche, indem wir Regionen blockieren, aus denen der Kunde keine legitimen Nutzer hat, aus denen aber die Masse der automatisierten Scans und Angriffe kommt.
- Suricata IDS/IPS — Deep Packet Inspection auf dem Host, mit aktuellen Regelsätzen. Es erkennt und blockiert Exploit-Versuche (SQLi, Scans, bekannte Payloads), bevor sie die Anwendungen in den VMs erreichen. Jeder Alarm wird protokolliert und ans Monitoring weitergeleitet.
- CrowdSec — verhaltensbasierte Erkennung von Angriffen (Brute-Force, Scans, Missbrauch) und signalbasierte Blockierung, inklusive geteilter Community-Blocklisten
- ipset mit dynamischen Listen — sehr schnelle Blockierung auf Kernel-Ebene großer IP-Listen, die sich dynamisch aktualisieren (CrowdSec-Entscheidungen, Threat-Feeds, IP-Reputation) — Angreifer werden am Tor abgewiesen, bevor sie die Apps erreichen
- NetFlow — praktisch jede Verbindung durch den Server wird protokolliert, auf Flow-Ebene: wer mit wem, wie viel Traffic, wann. Volle Sichtbarkeit für Untersuchungen und Audit
Das Ergebnis: statt 7 Maschinen mit unterschiedlichen (oder nicht vorhandenen) Regeln, ein einziger konsistenter Perimeter, durch den alles läuft.
Monitoring und Alarmierung — Zabbix
Ohne Übersicht würde die Konsolidierung das Problem nur verschieben. Wir haben Zabbix als zentrales Monitoring- und Alarmierungssystem eingerichtet, mit Agenten auf dem Host und allen 3 VMs:
- Infrastruktur — CPU, RAM, Disk, I/O und der Zustand jeder KVM-VM auf dem Host; Alarm, bevor eine Ressource kritisch wird (z. B. Disk über 80%)
- Anwendungen — HTTP/HTTPS-Checks für jede Webanwendung (Statuscode, Antwortzeit, Ablauf des TLS-Zertifikats), damit wir wissen, dass sie ausfällt, bevor der Kunde anruft
- Sicherheit — Suricata-Alarme und nginx-Ereignisse fließen in Zabbix ein, korreliert mit den übrigen Metriken
- Backup — Status der Backup-Jobs, damit ein fehlgeschlagenes Backup einen Alarm auslöst und keine Überraschung beim Restore
- Alarmierung mit Eskalation — E-Mail-Benachrichtigungen mit Schwellenwerten und Schweregraden, plus Dashboards für einen Echtzeit-Überblick
Verfügbarkeit und Image-Level-Backup
Die Konsolidierung auf einen einzigen physischen Server bedeutet, dass dieser Server kritisch wird — also war das Backup Teil des Designs, kein nachträglicher Zusatz. Wir verwenden eine Enterprise-Image-Level-Backup-Lösung: jede VM wird vollständig gesichert (komplettes Image + Inkrementelle), auf einem zweiten, vom Kunden separat gemieteten Server, an einem anderen physischen Standort.
Der Vorteil gegenüber einem klassischen Datei-Backup: bei Bedarf stellen wir die gesamte VM in Minuten wieder her — System, Konfigurationen, Anwendungen, Daten — startbereit, nicht von Hand zusammengesetzt. Die RTO sinkt von Stunden auf Minuten, und die physisch getrennte Kopie folgt dem 3-2-1-Prinzip.
Das ist kein HA-Cluster mit automatischem Failover — es war eine bewusste Kostenentscheidung. Der Backup-Server ist nicht nur ein Kopierziel: bei Bedarf können die 3 VMs in wenigen Minuten direkt darauf gestartet werden (Warm Standby), da sie als vollständige, startbereite Images gesichert sind. So erreichen wir eine RTO im Minutenbereich zu einem Bruchteil der Kosten und Komplexität eines echten HA-Clusters. Wenn das Geschäft ein automatisches Failover im Sekundenbereich erfordert, ist der nächste Schritt ein Cluster aus 2-3 Knoten mit Replikation — aber für das Volumen und das Budget dieses Kunden war die schnelle, getestete Wiederherstellung die richtige Balance.
Das Ergebnis
- ✅ Von 7 Maschinen bei zwei Anbietern zu einem einzigen Server mit 3 VMs — eine Verwaltung, eine Hauptrechnung
- ✅ 20+ Webanwendungen ohne Neuschreiben migriert, mit echter Isolation zwischen Workloads (KVM)
- ✅ Die beiden dedizierten Server auf Image-Ebene übernommen — null manuelle Neukonfiguration
- ✅ Ein einziger Sicherheitsperimeter: nginx Reverse Proxy + GeoIP + Suricata IDS/IPS auf dem Host, identisch für alle Anwendungen
- ✅ Vollständige 24/7-Übersicht mit Zabbix — Alarm vor dem Vorfall, nicht danach
- ✅ Image-Level-Backup auf einem separaten Server — vollständiger Restore in Minuten, Kopie an einem anderen physischen Standort
- ✅ Niedrigere Kosten und vollständig dokumentiert übergebene Infrastruktur
Haben Sie Anwendungen über mehrere Server verstreut?
Wenn Sie bei mehreren Anbietern Rechnungen für Anwendungen zahlen, die über verschiedene Maschinen verteilt sind, ohne gemeinsamen Sicherheitsperimeter und ohne einheitliches Monitoring, zahlen Sie wahrscheinlich mehr für weniger Kontrolle. Wir erstellen Audits und Konsolidierungspläne: was zusammengeführt werden kann, wie man Workloads isoliert, welchen Sicherheitsperimeter man einrichtet und wie man alles von einem Ort aus überwacht.