Was hat den Wechsel ausgelöst?
Die Klinik betrieb seit fünf Jahren eine VMware-Essentials-Single-Host-Infrastruktur. Hardware war hard-EOL, die Hersteller-Subscription wurde nicht mehr verlängert, und die Bildgebungs-Workloads (DVT, OPG, CT-Auswertung) liefen sichtbar an die Performance-Grenze.
Datenschutz war das größere Thema: Teile des Backup-Volumens lagen in einem US-Cloud-Anbieter — patientenidentifizierende Daten in Drittstaaten ohne dokumentierten Auftragsverarbeitungsvertrag. Aufsichtsrechtlich nicht haltbar.
Hinzu kam Wartungs-Schmerz: Single-Host bedeutet, dass jedes Update die gesamte Praxis offline nahm. Bei einer kieferchirurgischen Klinik mit Wartelisten ein wirtschaftlicher Schaden je Wartungsfenster.
Was wurde verworfen, was gewählt — und warum?
Verworfene Alternativen
- Pure-Cloud-Lösung (Azure-RIS-Stack) — scheiterte an Datensouveränität und Latenz-Anforderungen für Bildgebung
- VMware-Subscription-Renewal — wirtschaftlich nach Broadcom-Konsolidierung nicht mehr darstellbar
- Drei-Knoten-VxRail (Dell) — vergleichbare Hardware, deutlich höhere Lizenzkosten und Hersteller-Lock-in
Gewählte Architektur
- 3-Knoten-Proxmox-VE-Cluster mit dediziertem 25-GbE-Storage-Mesh, Ceph als verteiltem Block-Storage.
- Bildgebungs-Pool auf NVMe-OSDs (Hot-Tier), Routine-Workloads auf SAS-SSD (Warm-Tier) — gleicher Cluster, getrennte Pools.
- Proxmox Backup Server als dedizierter Server mit ZFS-RAIDZ2 und WORM-Aufbewahrung 30 Tage. Zweiter PBS in der Praxis-Filiale als Sync-Ziel (cold).
- OPNsense-Firewall mit segmentierten VLANs: Behandlungsräume, Verwaltung, Praxisverwaltung (Anbindung an externes Hersteller-VPN), Out-of-Band-Management, Gast-WLAN.
- Kein US-Cloud mehr im Datenpfad. Backup-Offsite-Sync auf eigenes Gerät am Filialstandort, ausschließlich über IPsec.
Wie ist es gelaufen?
Was hat sich verändert?
| Kennzahl | Vorher | Nachher |
|---|---|---|
| DICOM-Bildgebungs-Latenz (Median) | 230 ms | 45 ms |
| Verfügbarkeit (12 Monate) | nicht messbar (kein HA) | 99.97 % |
| Lizenzkosten 5 Jahre (Plattform) | Index 100 | Index 22 (− 78 %) |
| Backup-RPO | 24 h | 4 h |
| Backup-RTO (komplette VM) | ≈ 6 h | < 30 min |
| BSI-B3S Anforderungen erfüllt | 0 / 18 | 12 / 18 |
Was wir das nächste Mal anders machen würden
- DICOM-Connector-Tests vor dem Cutover sind nicht verhandelbar. Die Treiber-Inkompatibilität, die wir in der Vorab-Phase entdeckten, hätte am Migrations-Wochenende eine Notfall-Eskalation und vermutlich einen Rollback erzwungen.
- Custom-AD-Schema-Erweiterungen für Patientennummern waren nicht dokumentiert — beim ersten Test-Migrationslauf einer einzelnen VM ans Tageslicht gekommen. Pre-Migration-AD-Audit ist ab jetzt fester Bestandteil unserer Methodik.
- Praxisverwaltungs-Hersteller waren initial skeptisch gegenüber Proxmox als Plattform; nach erfolgreichem Test haben sie schriftlich Support bestätigt. Lehre: Hersteller-Freigabe vorab einholen, am besten mit dem realen Test-Setup.
- Praxisleiter ins Cutover einbinden — nicht nur informieren. Wer im Notfall-Fall am Telefon ist, muss vorher den Plan kennen.
Ä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.