OpenStack ist keine gescheiterte Plattform. Es ist eine Plattform, deren Betriebskosten in knappen Fachkräften bezahlt werden. Diese Seite beschreibt, wann dieser Tausch nicht mehr aufgeht, was der Wechsel auf eine Kubernetes-native Control Plane Dienst für Dienst bedeutet — und welche Teile wirklich schwierig sind.
Passt zu: Ænix Public Cloud Platform, wenn die OpenStack-Cloud an externe Kunden verkauft wird (Hoster, MSPs, Telcos, nationale Betreiber); Ænix Private Cloud Platform, wenn sie interne Verbraucher unter DORA-, NIS2- oder sektorspezifischen Auflagen bedient.
Wann Sie nicht migrieren sollten
Das gehört an den Anfang, weil die meisten Texte zu OpenStack es auslassen.
Bleiben Sie auf OpenStack, wenn Sie ein funktionierendes Betriebsteam haben, das den Release-Zyklus kennt, Sie auf einem gepflegten Release stehen, Ihr Upgrade-Pfad geübt statt theoretisch ist und Sie genug von der Dienstepalette nutzen — Ironic für Bare Metal, Octavia, Manila, Designate, Barbican —, dass ein Ersatz den Neubau mehrerer dieser Dienste bedeuten würde. OpenStack kann Dinge, die Kubernetes-native Plattformen nicht können: Multi-Hypervisor-Compute, ausgereiftes Bare-Metal-Provisioning und eine API-Oberfläche, die ein Jahrzehnt an Werkzeugen bereits spricht.
Der Grund für eine Migration ist betrieblich, nicht technisch-überlegen. Er wird stark, wenn:
- Upgrades hängen. Die Umgebung liegt zwei oder mehr Releases zurück, das Upgrade ist ein Projekt statt eines Wartungsfensters, und jedes Aufschieben verschlimmert das nächste.
- Das Team ein Bus-Faktor-Problem ist. Ein oder zwei Personen tragen die gesamte Control Plane. OpenStack-Kompetenz wird vom Markt nicht in dem Tempo nachgeliefert, in dem sie abfließt.
- Der genutzte Dienstumfang schmal ist. In der Praxis laufen viele Clouds auf Keystone, Nova, Glance, Cinder, Neutron und Horizon — und sonst nichts. Diesen Umfang ersetzt eine Kubernetes Control Plane ohne Verlust.
- Container bereits die Mehrheit der Last stellen. Sie betreiben Kubernetes auf OpenStack-VMs, bezahlen zwei Control Planes und debuggen über beide hinweg.
- Sich die Distributionsökonomie geändert hat. Das herstellergestützte OpenStack-Abonnement wurde zu einem Preis verlängert, der nicht mehr zum Wert des Supports passt.
Trifft nichts davon zu, lautet die ehrliche Empfehlung: bleiben und stattdessen in die Upgrade-Pipeline investieren.
Zuordnung Dienst für Dienst
Hier entscheidet sich der Umfang. Jedes OpenStack-Projekt hat ein Ziel, kein Ziel oder einen Neuentwurf.
| OpenStack | Ziel in Cozystack | Charakter der Migration |
|---|---|---|
| Keystone (Identität, Domains, Projekte) | Tenant-CRD plus Kubernetes-RBAC, OIDC gegen Ihren bestehenden IdP | Neumodellierung. Projektbäume bilden sich nicht eins zu eins ab; die Mandantenhierarchie wird im Assessment entworfen. |
| Nova (Compute) | KubeVirt-VMs im selben Cluster wie Container | Mechanisch. Beide Seiten sind libvirt/KVM. |
| Glance (Images) | CDI-DataVolumes mit Object Storage als Quelle | Mechanisch. QCOW2 und raw kommen mit. |
| Cinder (Block) | LINSTOR/DRBD, oder den bestehenden Ceph-Cluster über den Ceph-CSI-Treiber weiter nutzen | Mechanisch, wenn Ceph bleibt; Datenumzug bei Konsolidierung auf LINSTOR. |
| Neutron (Netzwerk) | Cilium (eBPF) mit L2-Announcements oder BGP; MetalLB, wo bereits Standard | Neuentwurf. Der schwierige Teil — siehe unten. |
| Swift / Ceph RGW (Object) | S3-kompatibler Object Storage auf der Plattform, oder RGW behalten | Meist behalten. Object-Endpunkte sind langlebig und kundensichtbar. |
| Octavia (Load Balancing) | Kubernetes-Services vom Typ LoadBalancer plus Ingress-Schicht | Neuentwurf. Die Semantik pro Mandant unterscheidet sich. |
| Ironic (Bare Metal) | Keine direkte Entsprechung | Lücke. Wenn Ironic tragend ist, behalten Sie es — oder diesen Teil von OpenStack. |
| Magnum (Kubernetes as a Service) | Mandanten-Kubernetes-Cluster mit gehosteten Control Planes | Vereinfachung. Genau darauf ist die Plattform gebaut. |
| Trove (DBaaS) | Managed-Datenbank-Anwendungen im Mandantenkatalog | Ersatz, keine Migration. Daten ziehen per Dump oder Replikat um. |
| Heat (Orchestrierung) | Helm plus GitOps-Reconciliation | Neubau. Heat-Templates lassen sich nicht konvertieren. |
| Horizon (Dashboard) | Cozystack-Mandanten-Dashboard | Ersatz. Schulen statt portieren. |
| Ceilometer / Gnocchi | Prometheus-kompatibler Metrik-Stack mit Langzeitspeicher | Ersatz. Abrechnungsanbindungen müssen umgehängt werden. |
Zwei Zeilen verdienen Nachdruck, weil dort Migrationen aus dem Ruder laufen.
Neutron ist der Neuentwurf. Mandantennetze, Router, Floating IPs, Security Groups und Provider-VLANs sind ein Adressierungs- und Policy-Modell, nicht bloß Verkabelung. Cilium erreicht dieselben Ergebnisse über andere Primitive: Network Policy statt Security Groups, LB-IPAM mit BGP oder L2-Announcements statt Floating IPs und L3-Agent. Kundensichtbare Adressen müssen den Umzug überleben oder nach einem Plan umnummeriert werden, dem Ihre Kunden zugestimmt haben. Planen Sie hier echte Entwurfszeit ein; das Überspringen ist der häufigste Grund für eine steckengebliebene OpenStack-Migration.
Heat und Horizon kommen nicht mit. Alles, was ein Mandant gegen die OpenStack-API automatisiert hat — Terraform-Provider, Heat-Stacks, interne Skripte —, wird gegen die Kubernetes-API neu geschrieben. Für eine interne Cloud sind das Schulungskosten. Für eine öffentliche Cloud mit API-nutzenden Kunden ist es eine Produktentscheidung mit Abkündigungsfrist, und die gehört an Tag eins in den Plan, nicht in Monat neun.
Ablauf der Migration
- Platform Readiness Assessment (14 oder 28 Tage, Festpreis). Vollständige Dienstinventur — welche OpenStack-Projekte tatsächlich genutzt werden, welche mandantensichtbare APIs haben, hinter welchen Integrationen hängen. Entwurf des Mandantenmodells. Adressplan. Ergebnis ist eine schriftliche Zielarchitektur und eine Kohortenfolge — und der Punkt, an dem ein Nein noch günstig ist.
- Parallel-Deployment. Cozystack wird neben der laufenden OpenStack-Cloud aufgebaut, nicht darauf. Beide Control Planes bestehen für die Dauer nebeneinander; es gibt keinen Moment, in dem die gesamte Umgebung an einem einzigen Cutover hängt.
- Kohorten-Migration. Die eigentliche Disk-Übertragung erledigt Konveyor Forklift; es ist in den Ænix-Plattformen enthalten und unterstützt OpenStack als Quelle. Zuordnungen von Datastore zu StorageClass und von Netz zu Netz werden als Kubernetes-Objekte deklariert,
virt-v2vübernimmt die Konvertierung auf Gastseite. Beachten Sie die Einschränkung: Von OpenStack aus führt Forklift nur Cold Migrations durch — warme, inkrementelle Übertragung gibt es für vSphere und RHV, nicht für OpenStack. Jede OpenStack-Instanz hat also ein echtes Abschaltfenster, und die Kohortengröße hängt davon ab, wie viele dieser Fenster Sie gleichzeitig einplanen können. Workloads ziehen in definierten Gruppen um — typischerweise nach Mandant, bei einer internen Cloud nach Anwendungsschicht. Jede Kohorte wird im Parallel-Run validiert, bevor ihre OpenStack-Seite freigegeben wird. Compute zuerst, Storage folgt dem Compute, das Netzwerk wird pro Kohorte gegen den abgestimmten Adressplan umgeschaltet. - Decommission. OpenStack-Knoten werden geleert und in den neuen Cluster überführt, sobald Kohorten abgeschlossen sind. Die Umgebung braucht damit nicht über die gesamte Laufzeit doppelte Hardware, sondern nur Reserve für die jeweils größte laufende Kohorte.
Typische Dauer: 4 bis 12 Monate für mittelgroße Umgebungen; 12 bis 18 Monate, wenn Neutron eine komplexe Provider-Netz-Topologie trägt oder Mandanten die OpenStack-API direkt nutzen.
Was sauber umzieht und was nicht
Zieht sauber um. VM-Disks — beide Seiten sind KVM, ein QCOW2- oder raw-Image wird per Forklift ohne Änderung am Gastsystem in ein KubeVirt-DataVolume importiert. Linux-Gäste booten in der Regel beim ersten Versuch. Ceph, wenn Sie es behalten. Object-Storage-Endpunkte. Alles bereits Containerisierte.
Braucht Entwurfsarbeit. Die Mandantenhierarchie, falls Sie Keystone-Domains und verschachtelte Projekte genutzt haben. Load-Balancer-Semantik. Quota- und Rate-Limit-Modelle. Alles, was einen Floating-IP-Pool voraussetzt.
Muss neu gebaut werden. Heat-Stacks. Horizon-Anpassungen. Abrechnungs- und Metering-Anbindungen, die Ceilometer lesen und auf die neue Metrikquelle umgehängt werden müssen — bei einem Service-Provider ist das nach dem Netzwerk der längste Einzelposten, und weil er den Umsatz betrifft, wird er früh eingeplant statt spät.
Zieht womöglich gar nicht um. Ironic-verwaltetes Bare Metal. Windows-Gäste brauchen dieselbe VirtIO-Treiberbehandlung wie bei jeder Virtualisierungsmigration. Als Hersteller-VM ausgelieferte Appliances brauchen die Freigabe ihres Herstellers für den neuen Hypervisor, bevor Sie mit ihnen planen.
Zur Plattformentscheidung dahinter siehe OpenStack-Alternative und Cozystack vs. OpenStack oder den ausführlichen Beitrag OpenStack vs. Cozystack: Modernisierungswege. Die Kostenseite modellieren Sie mit dem TCO-Rechner (englisch).
Wie Ænix arbeitet
- Platform Readiness Assessment (14 oder 28 Tage, Festpreis) — Dienstinventur, Zielarchitektur, Mandanten- und Adressentwurf, Kohortenplan, Risikoregister. Siehe Platform Readiness Assessment.
- Pilot-Kohorte — die erste Mandantengruppe migriert mit Ænix-Ingenieuren im Team; daraus entstehen die Runbooks für den Rest.
- Rollende Migration — Kohorte für Kohorte, im Parallel-Run validiert, mit OpenStack-Hardware, die in den Zielcluster nachwandert.
- Betrieb — entweder betreibt Ihr Team die Plattform mit Cozystack Enterprise Support im Rücken, oder Ænix betreibt sie.
Ænix hat Cozystack entwickelt (ein CNCF-Sandbox-Projekt, Apache 2.0) und pflegt es gemeinsam mit Maintainern anderer Unternehmen.