Private Cloud · Planung, Aufbau, Betrieb
Private Cloud für Unternehmen planen und aufbauen
Virtuelle Maschinen und Container auf Hardware, die Sie kontrollieren: mit Ceph-Storage, mandantenfähigem Netzwerk, zentraler Identität und Backup. SKAFFON plant, baut und betreibt die Plattform, vermietet aber keine Kapazität.
- Proxmox VE, Ceph, OpenTofu
- Betrieb und Support rund um die Uhr (24/7)
01Einordnung
Eigene Plattform statt gemieteter Kapazität
SKAFFON plant und baut Private-Cloud-Plattformen für Unternehmen: virtuelle Maschinen und Container auf eigener Hardware oder in Colocation, mit Software-defined Storage, mandantenfähigem Netzwerk, zentraler Identität, Backup und einem Betriebskonzept. Sie richtet sich an IT-Leitung und CTOs, die eine eigene Plattform erwägen, etwa wegen Datenhoheit, planbarer Kosten bei konstanter Last oder dem Ausstieg aus einer bestehenden Virtualisierung.
Mit „Private Cloud“ meinen wir Unternehmensinfrastruktur, nicht Dateiablage für Privatpersonen: eine Plattform, auf der Ihre Teams Ressourcen per Automatisierung bereitstellen, die Sie selbst kontrollieren.
02
Eigene Plattform oder Cloud-Region: wo welche Antwort trägt
Open Source heißt nicht kostenlos: Der Aufwand verschiebt sich vom Lizenzvertrag in Betrieb und Know-how.
Die eigene Plattform lohnt sich, wenn mindestens einer zutrifft
- Daten oder Betrieb müssen in Ihrer Kontrolle bleiben.
- Die Last ist über das Jahr relativ konstant, sodass Reservierungskapazität bei Anbietern teuer wäre.
- Sie haben oder bekommen das Know-how für den Betrieb (intern oder per Dienstleister).
Eine Cloud-Region ist die ehrlichere Antwort, wenn
- die Last stark schwankt und kurzfristig skalieren muss,
- kein Betrieb zur Verfügung steht oder
- nur wenige kleine Anwendungen laufen. Einordnung unter Cloud-Plattformen und Souveräne Cloud.
03Referenzarchitektur
Sechs Module, sechs Entscheidungen, sechs typische Fehler
Die Plattform besteht aus Compute, Netzwerk, Storage, Identität, Backup und Lebenszyklus. Die Matrix zeigt, welche Entscheidungen jedes Modul verlangt und wo typischerweise Fehler passieren.
| Modul | Typische Technik | Zu entscheiden | Häufige Falle |
|---|---|---|---|
| Compute | Proxmox VE (KVM) im Cluster, Hochverfügbarkeit | Knotenzahl, CPU- und RAM-Profil, Überbuchung, Reserve für Knotenausfall | HA aktiviert, aber nie ein Knotenausfall geübt; Kapazität reicht für den Ausfall nicht (siehe Rechnung unten) |
| Netzwerk | VLANs, Bonding, Proxmox SDN (VLAN-, VXLAN- und EVPN-Zonen mit BGP) | Trennung von Management, Cluster, Storage und Gastverkehr; Mandantentrennung; Anbindung ans Unternehmensnetz | Cluster- und Storage-Verkehr auf demselben Netz; VXLAN verschlüsselt nicht von selbst, und die Kapselung kostet 50 Byte MTU |
| Storage | Ceph (RBD für VM-Disks, optional S3 über Ceph Object Gateway), alternativ ZFS mit Replikation | Replikation, Failure Domains, Medien (NVMe/SSD/HDD), Netzbandbreite | Zu kleiner Cluster für Ceph; Details auf der Seite Ceph Storage |
| Identity | Zentrale Anmeldung per OIDC/LDAP/AD, Rollen, Zwei-Faktor | Wer darf was; Notfallzugang; Service-Konten und API-Token | Gemeinsame Admin-Konten; Notfallzugang ohne Test |
| Backup | Proxmox Backup Server, Offsite-Kopie, Wiederherstellungstests | Aufbewahrung, Ziel getrennt vom Produktionsstandort, Restore-Rhythmus | Backup nie wiederhergestellt; Backup im selben Fehlerbereich wie die Produktion |
| Lifecycle | Updates, Hardware-Erneuerung, Infrastruktur als Code mit OpenTofu | Update-Fenster, Kompatibilitätsprüfung, Reproduzierbarkeit der Konfiguration | Manuelle Einzeländerungen, die niemand dokumentiert hat |
04
Wie die Schichten der Plattform aufeinander aufbauen
Von der Hardware bis zu den Workloads: vier Schichten, quer dazu Identität, Backup und Lebenszyklus.
05Dimensionierung
Kapazität mit Ausfallreserve: was ein Knotenausfall im Arbeitsspeicher kostet
Der Cluster ist im Normalbetrieb gut ausgelastet und kann den Ausfall eines Knotens nicht tragen. Die Rechnung ist einfach, wird aber leicht übersehen.
Rechenbeispiel mit angenommenen Werten, keine Messung und keine Empfehlung: Fünf Knoten mit je 512 GB Arbeitsspeicher ergeben 2.560 GB gesamt. Soll der Ausfall eines Knotens getragen werden, stehen für VMs höchstens vier Knoten zur Verfügung: 4 × 512 GB = 2.048 GB, abzüglich des Bedarfs von Hypervisor und Ceph-Diensten je Knoten (hier nicht eingerechnet; er wird anhand Ihrer Konfiguration bestimmt). Wer im Normalbetrieb mehr als diese Menge an VM-Speicher zuweist, kann bei einem Ausfall nicht alle VMs neu starten.
Bei geteiltem Ceph-Storage verringert ein Knotenausfall außerdem den verfügbaren Speicher; die Kapazitätsrechnung dafür steht auf der Seite Ceph Storage. Für CPU gilt dieselbe Logik, ergänzt um den gewählten Überbuchungsfaktor, der von Ihren Lastprofilen abhängt.
06Herstellervorgaben
Quorum, SDN und Anmeldung: was die Proxmox-Dokumentation vorgibt
Zu den technischen Voraussetzungen im Einzelnen stützen wir uns auf die Herstellerdokumentation. Betriebsdetails zu Proxmox beschreibt Proxmox Support, Cluster und Hochverfügbarkeit.
- Hochverfügbarkeit: mindestens drei Knoten für ein zuverlässiges Quorum; eigene Netzwerkkarte für den Cluster-Verkehr (Corosync braucht konstant niedrige Latenz, aber wenig Bandbreite); für kleinere Cluster ein QDevice als dritte Stimme (Proxmox: Cluster-Manager).
- Netzwerk: Das SDN unterstützt Simple-, VLAN-, QinQ-, VXLAN- und EVPN-Zonen; EVPN nutzt BGP für Layer-3-Routing über Cluster hinweg (Proxmox: SDN).
- Anmeldung: Proxmox-eigene Benutzerverwaltung, LDAP, Active Directory und OpenID Connect, dazu optionale Zwei-Faktor-Verfahren (Proxmox: Benutzerverwaltung).
07
Vom Lastprofil zum geübten Ausfall: sechs Schritte
Aufbau und Änderungen laufen als Code mit OpenTofu und Pipelines, damit die Umgebung reproduzierbar ist.
- 01
Anforderungen und Dimensionierung
Ergebnis: LastprofilWorkloads, Schutzbedarf, Wachstum, Standorte, Verfügbarkeitsziele, vorhandene Hardware.
- 02
Architektur
Ergebnis: ZielbildModule wie oben; Entscheidung, ob hyperkonvergent (Compute und Storage auf denselben Knoten) oder getrennt.
- 03
Aufbau
Ergebnis: PlattformInstallation, Härtung, Netzwerk, Storage, Identität, Monitoring, Backup. Alle Konfigurationen liegen als Code vor.
- 04
Validierung
Ergebnis: NachweisAusfalltests (Knoten, Netz, Storage), Restore-Test, Lasttest.
- 05
Übergabe
Ergebnis: RunbooksDokumentation, Runbooks, Einweisung.
- 06
Betrieb (optional)
OptionalUpdates, Monitoring, Störungsbearbeitung. Betrieb und Support bieten wir rund um die Uhr (24/7) an; die Reaktionszeiten je Prioritätsstufe ergeben sich aus dem Servicelevel-Modell unter Managed Services und werden je Vertrag vereinbart. Das Betriebsmodell beschreibt Managed Private Cloud.
08Sicherheit
Mandanten trennen, Zugänge begrenzen, Management abschotten
Mandantentrennung läuft über Netzwerk (VLAN/SDN), Rollen und Ressourcenpools. Zugänge sind personalisiert und folgen dem Least-Privilege-Prinzip, das Management-Netz bleibt vom Gastverkehr getrennt, Protokolle laufen zentral zusammen.
Anbindung an Ihr Verzeichnis, Monitoring und Ticketsystem klären wir im Projekt.
09
Was Sie zum Projekt beitragen
- Rechenzentrum, Colocation oder Hardware-Beschaffung; Stromversorgung, Kühlung, Netzanbindung
- Entscheidungen zu Schutzbedarf, Mandanten und Verfügbarkeitszielen
- Ansprechpartner für Anwendungen und deren Wartungsfenster
- Beschaffung von Herstellerverträgen (z. B. Subscriptions), soweit gewünscht
10
Was wir nicht liefern: Mietcloud, Kleinstumgebungen, Hardware
-
Gehostete Private Cloud
Sie suchen einen Anbieter, der Ihnen eine fertige Private Cloud als gehosteten Dienst vermietet.
-
Ein bis zwei Server
Ihr Bedarf ist klein genug für ein bis zwei Server ohne Hochverfügbarkeit; dann ist der Aufwand einer Plattform nicht gerechtfertigt.
-
Unvorhersehbares Hochskalieren
Sie benötigen schnelles, unvorhersehbares Hochskalieren; dort sind Cloud-Regionen im Vorteil.
-
Hardware und Rechenzentrumsbetrieb
Sie erwarten Hardware-Lieferung und Rechenzentrumsbetrieb aus einer Hand: das leisten wir nicht.
11
Auf der Plattform weiterbauen: Kubernetes, Ceph, VMware-Ausstieg
Wollen Sie Kubernetes auf der Plattform, setzen wir es als eigene Schicht auf VMs oder Bare Metal auf. Kommt die Plattform aus einem VMware-Ausstieg, beschreibt die Migrationsseite den Weg.
-
Kubernetes-Beratung
Kubernetes als eigene Schicht auf VMs oder Bare Metal.
-
Talos und Omni
Kubernetes-Betriebssystem und Cluster-Verwaltung.
-
VMware-Exit nach Proxmox
Migration aus einer bestehenden Virtualisierung.
-
Ceph Storage
Replikation, Failure Domains und Kapazitätsrechnung.
Beschreiben Sie Workloads, Standorte und Anforderungen
Aus Ihrer Beschreibung entsteht der Vorschlag für Architektur und Dimensionierung.