Was hat den Wechsel ausgelöst?
Die Behörde betrieb einen 5 Jahre alten VxRail-Cluster — Hyperconverged-Lösung von Dell mit VMware vSphere und vSAN. Hardware lief auf den letzten EOL-Zyklus zu, eine Vertragsverlängerung wurde nicht angeboten.
Parallel wuchsen die Anforderungen: mehrere interne Fachverfahren wurden auf cloud-native Architekturen modernisiert (Container-Workloads), das Sicherheitskonzept war auf alte BSI-Grundschutz-Bausteine ausgerichtet, und die zuständige Aufsicht forderte eine vollständige Standard-Absicherung samt dokumentierter Härtung.
Wirtschaftlich: VxRail-Refresh hätte sechs Jahre Hardware-Subscription plus VMware-Lizenzen bedeutet — ein Preisniveau, das im Behörden-Budget zunehmend schwer zu rechtfertigen ist.
Was wurde verworfen, was gewählt — und warum?
Verworfene Alternativen
- VxRail-Refresh — Hardware-Vendor-Lock-in plus Broadcom-Lizenzkostenexplosion
- Reine Public Cloud (deutsche Anbieter) — interne Audit-Trail-Anforderungen und KRITIS-Vorbehalte
- Pure-OpenShift — Overhead für 4-Personen-IT-Team zu hoch, wir wollten Linux-natives Tooling
Gewählte Architektur
- Hyperconverged Proxmox VE mit Ceph auf 5 Knoten (3 Compute + 2 Storage-heavy), 25-GbE-Mesh, NVMe-Pools.
- Kubernetes-Overlay (k3s) für die cloud-native Fachverfahren — kompakte Distribution, läuft als reguläre Proxmox-VMs ohne separate Plattform-Lizenz.
- Strikte Netzsegmentierung: getrennte Cluster-Zonen für Test, Produktion, Out-of-Band-Management; Mikrosegmentierung pro Fachverfahren via OPNsense-Regeln.
- Wazuh-SIEM zentral, mit allen 142 Endpunkten (Server, VMs, Workstations) verbunden. 24/7-Auswertung in unserem Full-IT-Service.
- Tiered Backup: lokal (PBS), Sync zu zweitem Standort, WORM-Tape für Compliance-Archive.
Wie ist es gelaufen?
Was hat sich verändert?
| Kennzahl | Vorher | Nachher |
|---|---|---|
| Lizenzkosten 5 Jahre (Plattform) | Index 100 | Index 18 (− 82 %) |
| Compute-Headroom | Auslastung 78 % | Auslastung 38 % (+ 40 % Reserve) |
| Storage-IOPS | Index 100 | Index 305 (× 3) |
| BSI-Grundschutz | alte Bausteine, Lücken im Audit | Standard-Absicherung mit dokumentierter Härtung |
| Wazuh-SIEM | kein zentrales Logging | 142 Agents, 1.28 M Events/Tag, 0 ungeklärte Major Incidents |
| Patch-Frequenz Linux-Server | alle 3 – 6 Monate händisch | wöchentlich, automatisiert via Ansible |
Was wir das nächste Mal anders machen würden
- Migrations-Reihenfolge musste mehrfach umgeplant werden. Abhängigkeiten zwischen Fachverfahren waren nicht vollständig dokumentiert. Eine zweiwöchige Reverse-Engineering-Phase vor dem ersten Cutover hätte uns im Mittelteil 4 – 6 Tage gespart.
- Custom-Compliance-Reporting für die Aufsicht musste neu entwickelt werden — VxRail hatte das mitgeliefert. Wir haben eine kleine Python-Pipeline gebaut, die monatliche Reports aus Wazuh-Daten erzeugt.
- Ansible-Automation hat sich überproportional ausgezahlt. Patching, neue VMs, Standard-Härtung — was vorher Tage gedauert hat, läuft jetzt in Minuten und ist nachvollziehbar versioniert.
- Penetrationstest vor Produktivnahme war Gold wert. Drei der fünf Findings waren Konfigurationsdetails, die im Routinebetrieb nicht aufgefallen wären, aber bei einem späteren Audit hochrelevant gewesen wären.
Ähnliches Vorhaben? 30 Minuten reichen für ein erstes Bild.
Wir hören zu, stellen die richtigen Fragen und sagen ehrlich, ob wir der passende Partner sind. Kostenfrei, unverbindlich.