Managed Private Cloud · Proxmox VE, KVM, Ceph
Managed Private Cloud und Virtualisierungsbetrieb
SKAFFON betreibt Ihre Virtualisierungsplattform: Hypervisor-Lifecycle, Storage, Backup mit Proxmox Backup Server, Monitoring und Störungsbearbeitung. Betrieb und Support laufen 24/7.
- Proxmox VE, KVM und Ceph
- Backup mit Restore-Test
- Aufgabenteilung nach RACI
01Ausgangslage
Eine Private Cloud, die jemand dauerhaft verantwortet
Eine eigene Virtualisierungsplattform verlangt Dauerbetrieb: Updates in der richtigen Reihenfolge, Kapazität für den Ausfall eines Knotens, Storage, der nicht still degradiert, und Backups, die sich nachweislich einspielen lassen. Der Service richtet sich an IT-Leitung und Infrastrukturverantwortliche, die eine eigene Plattform behalten oder einführen, den Betrieb aber nicht mit eigener Bereitschaft abdecken wollen.
Typische Auslöser sind ein Umstieg von einer anderen Virtualisierung (VMware-Exit nach Proxmox), ein gewachsener Cluster ohne klare Zuständigkeit oder ein Team, das die Plattform nebenbei betreut. Wer die Plattform erst entwerfen muss, beginnt bei Private Cloud; die technischen Grundlagen zu Cluster und Hochverfügbarkeit beschreibt Proxmox. Die Einordnung im Ganzen finden Sie unter Managed Services.
02Betriebsumfang
Acht Bereiche, die wir an Ihrem Proxmox-Cluster betreiben
-
Hypervisor-Lifecycle
Minor- und Major-Upgrades für Proxmox VE, Kernel- und Paketupdates, Knotenaustausch und Erweiterung.
-
Cluster und Hochverfügbarkeit
Quorum, Fencing, HA-Regeln und Kapazitätsreserve; Ausfalltests nach Änderungen.
-
Storage
Lokaler, gemeinsamer oder Ceph-Storage: Kapazität, Datenverteilung und Zustand im Blick.
-
Netzwerk
Management-, Cluster-, Storage- und VM-Verkehr getrennt; VLANs und Bonding.
-
Backup
Proxmox Backup Server mit Aufbewahrungsregeln, Offsite-Kopie und Restore-Tests.
-
Monitoring
Metriken und Alarme zu Knoten, Storage, HA und Backup, aufgebaut mit Prometheus und Grafana.
-
Infrastruktur als Code
VM-Vorlagen, Netze und Konfiguration mit OpenTofu, soweit sinnvoll.
-
Betriebsbericht
Regelmäßig: Incidents, Changes, Updates, Kapazität und Backup-Ergebnisse.
03Verantwortung
Wer am Cluster wofür geradesteht
R = führt aus, A = trägt die Ergebnisverantwortung, C = wird konsultiert, I = wird informiert. Standardaufteilung; der Vertrag legt die endgültige Fassung fest.
| Tätigkeit | SKAFFON | Kunde |
|---|---|---|
| Proxmox-Updates planen und durchführen | R | A (Freigabe Fenster) |
| Cluster-, HA- und Storage-Konfiguration pflegen | R/A | C |
| Monitoring und Alarmierung betreiben | R/A | I |
| Störung auf Plattformebene (Knoten, Cluster, Storage, Netzwerk) | R/A | I |
| Hardwaretausch, Rechenzentrumszugang, Strom, Kühlung | C | R/A |
| Störung im Gast (Betriebssystem, Anwendung der VM) | C | R/A |
| Backup einrichten, Aufbewahrung, Restore-Tests | R/A | C |
| Entscheidung über Wiederherstellung im Ernstfall | R | A |
| Proxmox-Subscription und Herstellersupport | C | R/A |
| Kapazitätsplanung und Beschaffungsempfehlung | R | A |
| Zugriffskonzept (wer darf was) | R | A |
| Betriebsreview und Eskalation | R | A |
Herstellersupport für Proxmox VE bekommen Sie ausschließlich über eine Subscription bei Proxmox (Proxmox, Subscriptions); sie ersetzt unseren Betrieb nicht, und unser Betrieb ersetzt sie nicht. Die Hardware bleibt in Ihrer Verantwortung, solange nichts anderes vereinbart ist.
04Storage und Netz
Wo ein Cluster unbemerkt Redundanz verliert
Ein Cluster fällt selten mit einem Knall aus. Häufiger verliert er unbemerkt Redundanz: ein Ceph-Zustand, der nicht mehr gesund ist, eine Replikation im Rückstand, ein Netz, in dem Storage- und VM-Verkehr um dieselbe Leitung konkurrieren.
Deshalb überwachen wir Kapazität, Datenverteilung und Zustand des Storage und halten Management-, Cluster-, Storage- und VM-Verkehr getrennt. Änderungen an HA und Storage werden mit Ausfalltests abgesichert.
- Lokaler, gemeinsamer oder Ceph-Storage
- Alarme zu Knoten, Storage, HA und Backup
- Ausfalltest nach jeder relevanten Änderung
05Runbook
Rollierendes Update: ein Knoten nach dem anderen
Ein Update gilt erst als erledigt, wenn der Cluster wieder die Kapazität für den Ausfall eines Knotens hat. Das Verfahren in acht Schritten:
- 01
Vorbereitung
VorabRelease Notes und Kompatibilität prüfen; wichtig etwa der Wechsel von HA-Gruppen zu Node-Affinity-Regeln ab Proxmox VE 9.0 (Proxmox VE Roadmap). Wartungsfenster mit Ihnen abstimmen.
- 02
Absicherung
VorabFrisches Backup der VMs und der Konfiguration; geprüfter Restore-Weg; Rückfallkriterien festlegen.
- 03
Kapazitätscheck
EntscheidungFällt ein Knoten während des Updates aus, müssen die übrigen die Last tragen. Reicht das nicht, wird das Fenster verschoben oder Last reduziert.
- 04
Einzelner Knoten
UmsetzungVMs auf andere Knoten verlagern (soweit gemeinsamer Speicher und Hardware-Kompatibilität es zulassen), Knoten aktualisieren, neu starten, Zustand prüfen.
- 05
Prüfung vor dem nächsten Knoten
UmsetzungQuorum, Ceph-Zustand und Replikation müssen wieder gesund sein, bevor der nächste Knoten folgt. Nie zwei Knoten gleichzeitig.
- 06
Abschluss
Ergebnis: AbnahmeVMs zurückverlagern oder neu verteilen, Smoke-Tests, Alarme und Dashboards prüfen, Abnahme durch Sie.
- 07
Rückfall
Falls nötigEin Zurück zur alten Version planen wir nicht. Stattdessen vereinbaren wir vor dem Update den Weg zurück zu einem gesicherten Zustand: betroffene Knoten neu aufsetzen oder VMs aus dem Backup wiederherstellen.
- 08
Dokumentation
NachweisIm Betriebsbericht und in den Runbooks.
06Backup
Backups: sichern, aufräumen, prüfen, einspielen
Der Proxmox Backup Server trennt, was Teams oft vermischen. Nach der Herstellerdokumentation entfernt ein Prune-Job nur Snapshot-Metadaten nach den Aufbewahrungsregeln; Speicher wird erst durch die Garbage Collection frei, die nicht mehr referenzierte Chunks löscht. Verifikationsjobs prüfen, ob gesicherte Daten intakt sind.
07Wiederherstellung
Wiederherstellungsziele und Zusagen je Topologie
Wiederherstellungsziele (RPO/RTO) leiten sich aus Ihren Geschäftsanforderungen ab, werden je System vertraglich festgelegt und per Restore-Test nachgewiesen.
Verfügbarkeitsziele vereinbaren wir je Plattform. Was ein Cluster zusichern kann, hängt von der Topologie ab: Knotenzahl, Redundanz von Netzwerk und Storage, Standort der Hardware. Laut Proxmox-Dokumentation braucht HA mindestens drei Knoten; ein Zwei-Knoten-Cluster kann den Ausfall eines Knotens nicht wie ein Drei-Knoten-Cluster abfangen. Kennzahlen, Messmethode und Folgen bei Abweichung werden vertraglich vereinbart; die Systematik beschreibt der Servicelevel-Rahmen.
08Prozesse
Störung, Änderung, Sicherheitsupdate: drei Wege durch den Betrieb
Incident: Erkennung (Alarm oder Meldung), Priorisierung, Eingrenzung, Behebung oder Workaround, Statusinformation, Abschluss mit Ihrer Bestätigung, bei schweren Störungen Ursachenanalyse mit Maßnahmen.
Change: Änderung als Pull Request oder dokumentierter Auftrag, Einstufung (Standard- oder prüfpflichtiger Change), Freigabe durch Sie, Umsetzung durch SKAFFON, Verifikation, Rückfallplan vor Umsetzung.
Patch: Beobachtung von Sicherheitsmeldungen zu Proxmox VE, Kernel, Ceph und Backup-Server, Bewertung, Test, Rollout nach dem Update-Verfahren. Dringende Sicherheitsupdates stimmen wir außerhalb des Regelzyklus ab.
09Einstieg
Vom Bestand zum Betriebsplan
Das Onboarding beginnt mit einer Bestandsaufnahme: Hardware, Netzwerk, Storage, Versionen, Backups, Risiken. Daraus entsteht der Betriebsplan mit RACI und Fenstern. Es folgen Zugänge mit minimalen Rechten, Monitoring und Backup, Ausfalltest und Restore-Test; danach beginnt der Regelbetrieb. Cluster ohne Dokumentation sind möglich, brauchen aber eine gründlichere Bestandsaufnahme.
Wir legen Umfang, RACI und Berichtsrhythmus aus dieser Bestandsaufnahme fest; das Angebot nennt Umfang, Annahmen und Preismodell.
10Abgrenzung
Wo der Betrieb der Plattform endet
Das übernehmen wir
- Die Plattformebene: Knoten, Cluster, Storage, Netzwerk, Backup und Monitoring.
- Die Übernahme eines bestehenden Clusters nach einer Bestandsaufnahme.
Das liegt woanders
- Offizieller Herstellersupport für Proxmox VE: den leistet nur Proxmox.
- Hardwarearbeiten im Rechenzentrum wie Austausch und Verkabelung: sie bleiben bei Ihnen oder Ihrem Rechenzentrumsbetreiber.
- Last in Containern auf Kubernetes ohne Virtualisierungsschicht: dann ist Managed Kubernetes der passendere Service.
- Die Verantwortung für Anwendungsfehler in den VMs, ohne dass die Anwendung bekannt ist.
11
Häufige Fragen
Betreiben Sie auch Hardware und Rechenzentrum?
Nein, der Service betrifft die Plattformebene. Hardware und Standort bleiben in Ihrer Verantwortung, sofern nichts anderes vereinbart ist.
Können Sie einen bestehenden Cluster übernehmen?
Ja, nach einer Bestandsaufnahme. Cluster ohne Dokumentation sind möglich, brauchen aber eine gründlichere Aufnahme von Hardware, Netzwerk, Storage und Backups.
Ersetzt Ihr Betrieb die Proxmox-Subscription?
Nein. Herstellersupport für Proxmox VE gibt es nur über eine Subscription bei Proxmox. Unser Betrieb ersetzt sie nicht, und sie ersetzt unseren Betrieb nicht.
Wie läuft ein Update, ohne dass die Plattform ausfällt?
Rollierend, ein Knoten nach dem anderen, mit Kapazitätscheck vorab und Zustandsprüfung vor dem nächsten Knoten. Das Verfahren steht im Runbook oben.
Beschreiben Sie Ihren Cluster
Schildern Sie Plattform und Betriebsanforderungen; Fragen vorab beantworten wir über den Kontakt.