Ein praktischer Leitfaden zur Bewertung Ihrer VMware-Umgebung und zur Entwicklung einer Migrationsroadmap zu OpenShift Virtualization
Dies ist der dritte Blog unserer Serie zur Migration von VMware zu OpenShift Virtualization. Lesen Sie zuerst Blog Nr. 1: Warum wenden wir uns von VMware ab? und Blog Nr. 2: Einführung in OpenShift Virtualization.
In unseren vorherigen Beiträgen haben wir die betriebswirtschaftlichen Aspekte betrachtet, die derzeit zu einer Abkehr von VMWare führen. Wir haben auch die technische Architektur von OpenShift Virtualization analysiert. Beide Perspektiven (betriebswirtschaftlich und technisch) führen zu derselben Erkenntnis: Diese Art von Migration ist im Kern eher ein “People” und “Process” Thema und weniger eine “technische Herausforderung”.
In diesem Blogpost widmen wir uns daher der Herausforderung wie man die konkrete Planung der Migration angehen kann. Dabei überrascht viele Teams eine einfache Frage, die wir zu Beginn stellen: “Wissen Sie wirklich, was alles in Ihrer Umgebung und daran angrenzend ‘läuft’?”.
Wir haben mehrere Unternehmen bei solchen Migrationen begleitet und sehen immer wieder dasselbe Muster. Teams investieren Wochen in die Bewertung von OpenShift Virtualization: Sie validieren Live-Migration, testen die Unterstützung von VM-Betriebssystemen und messen Performance. Das sind sinnvolle Aktivitäten, greifen aber am Kern der Herausforderung vorbei.
Migrationen geraten selten deshalb ins Stocken, weil die Technologie (OpenShift Virtualization) nicht funktioniert. Viele andere kleine Details in der Umgebung so einer Plattform sorgen unserer Erfahrung nach eher für Herausforderungen. Kritisch wird es z.B. dort, wo der CSI-Treiber des Storage-Arrays nicht ausreicht, die Backup-Lösung die neue Umgebung nicht schützen kann oder die bisher gelebten Disaster-Recovery-Prozesse nicht auf die neue Plattform übertragbar sind.
In unserer Assessment-Phase entscheidet sich, ob eine Migration von VMware zu OpenShift erfolgreich wird. Nicht, weil OpenShift Virtualization schwer bereitzustellen wäre: Die Plattform ist ausgereift und gut dokumentiert. Die eigentliche Herausforderung liegt in den Drittanbieter-Integrationen, die über Jahre rund um den VMware-Betrieb aufgebaut wurden. Storage-Array, Backup-Lösung, Disaster-Recovery-Verfahren, Monitoring-Stack – all diese Komponenten haben mit VMware und vSphere reibungslos funktioniert. Damit sie auch mit OpenShift Virtualization funktionieren, braucht es sorgfältige Planung, manchmal die Einbindung von Herstellern und gelegentlich pragmatische Lösungen.
Dieser Beitrag beschreibt unseren Ansatz für die Planung des VMware-Ausstiegs. Wir zeigen, wie Sie Ihre bestehende Landschaft bewerten, warum Drittanbieter-Integrationen oft mehr Aufmerksamkeit verdienen als die Virtualisierungsplattform selbst, wie Sie Migrationsroadmaps entwerfen und welche Rollen Sie im Team benötigen. Das Ziel ist ein pragmatischer Rahmen, den Sie an die spezifische Situation Ihrer Organisation anpassen können.
Ein klares Bild Ihrer Umgebung gewinnen
Datenerhebung mit RVTools
Bevor Sie eine Migration planen können, brauchen Sie ein vollständiges Bild der Umgebung, die migriert werden soll. Die Herausforderung besteht nicht darin, überhaupt Daten zu sammeln. VMware-Umgebungen erzeugen große Mengen an Telemetrie. Entscheidend ist, die richtigen Daten zu erfassen und korrekt zu interpretieren.
RVTools gehört weiterhin zu den wertvollsten Werkzeugen für die Inventarisierung von VMware-Umgebungen. Das kostenlose Tool exportiert detaillierte Informationen über Ihre vSphere-Landschaft, darunter VMs, Hosts, Datastores, Netzwerke und Resource Pools. Die Daten im Excel-Format bilden einen guten Ausgangspunkt: Sie lassen sich filtern, sortieren und aggregieren, um die Eigenschaften Ihrer Umgebung besser zu verstehen.
Bei der Auswertung von RVTools-Daten achten wir besonders auf mehrere Dimensionen:
- VM-Dichte – Wie viele VMs gibt es im Verhältnis zu Ihren Hosts? Diese Information hilft, OpenShift Worker Nodes richtig zu dimensionieren.
- Datastore-Verteilung – Wie ist Storage bereitgestellt? Gibt es über die gesamte Umgebung hinweg konsistente Performance-Eigenschaften?
- Alter und Größe von Snapshots – Alte Snapshots weisen entweder auf vergessene Zwischenstände hin oder auf Workflows, die von Snapshot-Funktionalität abhängen und deshalb auch auf der neuen Plattform abgebildet werden müssen.
- Ressourcenauslastung – Identifizieren Sie VMs mit dauerhaft hoher Ressourcennutzung, die während der Migration besondere Aufmerksamkeit benötigen.
- Guest-OS-Informationen – Ermitteln Sie, mit welchen Betriebssystemen Sie arbeiten, einschließlich Appliances.
Ergänzend zu RVTools sollten Sie weitere Daten zu Performance-Eigenschaften, Netzwerktopologie und Applikationsabhängigkeiten sammeln. Performance-Daten aus vCenter oder Ihren Monitoring-Tools zeigen, welche VMs dauerhaft stark ausgelastet sind.
Eine saubere Dokumentation der Netzwerktopologie macht komplexe Konfigurationen sichtbar, die möglicherweise neu umgesetzt werden müssen. Das Mapping von Applikationsabhängigkeiten zeigt, welche VMs miteinander kommunizieren und warum. So vermeiden Sie Überraschungen, wenn Sie Workloads zwischen Plattformen verschieben.
Migrationsplanung mit T-Shirt Größen
Nach der Datenerhebung sollten Sie VMs zu Migrationseinheiten bündeln, die gemeinsam verschoben werden können. Wir arbeiten dafür mit T-Shirt-Sizing: klein, mittel und groß. Es geht dabei nicht um exakte Kapazitätsplanung, sondern um handhabbare Arbeitspakete, die Teams systematisch umsetzen können. T-Shirt-Sizing ist allerdings nur ein Kriterium. Abhängigkeiten zwischen Systemen und die fachliche bzw. operative Verantwortung für VMs bestimmen ebenfalls, wie Einheiten sinnvoll gebildet werden. Gute Migrationspakete berücksichtigen Applikationsbeziehungen, Shared Services und Zuständigkeiten, damit Unterbrechungen möglichst gering bleiben. Wo immer möglich, sollten Migrationen teamweise organisiert werden. Das vereinfacht die Koordination und reduziert teamübergreifende Auswirkungen während des Cutovers.
Kleine Migrationen umfassen wenige VMs mit einfachen Abhängigkeiten und lassen sich meist in einem einzelnen Migrationsfenster abschließen. Sie eignen sich gut für die erste Validierung, für Teamtraining und als Nachweis, dass die Migrationsverfahren funktionieren, bevor größere Pakete folgen.
Mittlere Migrationen umfassen eine oder zwei Gruppen zusammengehöriger VMs, die während Wartungsfenstern außerhalb der Kernzeiten verschoben werden können. Sie erfordern mehr Koordination und enthalten häufig Abhängigkeiten zwischen Datenbanken, Applikationsservern und Frontend-Komponenten. Für diese Pakete brauchen Sie eine klare Reihenfolge, abgestimmte Verantwortlichkeiten und definierte Verifikationsschritte.
Große Migrationen sind mehrtägige oder mehrwöchige Vorhaben und betreffen ganze Cluster oder Applikationssuiten. Sie brauchen Projektmanagement, gestaffelte Cutover, klare Verantwortlichkeiten und eine belastbare Rollback-Planung. Die meisten Unternehmen fahren besser mit einem phasenweisen Ansatz, statt alles auf einmal zu migrieren. Idealerweise folgt die Reihenfolge den Applikations- und Teamgrenzen, damit der Betrieb stabil bleibt.
Drittanbieter-Integrationen als zentrale Herausforderung
Realitäten der Storage-Integration
Storage-Integration gehört zu den vorhersehbarsten und zugleich am häufigsten unterschätzten Problembereichen bei Migrationen von VMware zu OpenShift Virtualization. Ihre bestehende Storage-Infrastruktur hat mit vSphere über eine vertraute Integrationsschicht funktioniert. OpenShift Virtualization benötigt CSI-Treiber, und deren Reifegrad unterscheidet sich je nach Hersteller erheblich.
Entscheidend ist die funktionale Parität. Unterstützt der CSI-Treiber Ihres Storage-Arrays dieselben Snapshot-Fähigkeiten, auf die Ihre Backup-Lösung angewiesen ist? Kann er Clone-Operationen abbilden, die Sie für Testumgebungen nutzen? Liefert er die Performance-Eigenschaften, die latenzsensitive Anwendungen brauchen?
Wir haben Situationen erlebt, in denen Storage-Arrays mit hervorragender vSphere-Integration nur eingeschränkte CSI-Treiber bereitstellten. In einem Fall erforderte die Snapshot-Unterstützung des Treibers eine Storage-Array-Konfiguration, die nicht dokumentiert war und nur mit Unterstützung des Herstellers geklärt werden konnte. In einem anderen Fall unterstützte der Treiber zwar Snapshots, aber nicht den inkrementellen Snapshot-Workflow, den die Backup-Software erwartete. Am Ende musste die Backup-Lösung gewechselt werden.
Performance-Tests sind ebenso wichtig. Storage-Performance in OpenShift Virtualization unterscheidet sich in Details von vSphere. I/O-Muster containerisierter Workloads können von klassischen VM-Mustern abweichen, und auch die Effizienz des CSI-Treibers variiert. Stellen Sie deshalb Proof-of-Concept-VMs auf Ihrem Storage-Array bereit und führen Sie repräsentative Workloads aus, bevor Sie die Migration fest planen.
Backup- und Recovery-Integration
Die Unterstützung Ihrer Backup-Lösung für OpenShift Virtualization sollten Sie sorgfältig prüfen. VMware-Umgebungen integrieren sich typischerweise über APIs in Backup-Tools, die vSphere-Konstrukte wie Resource Pools, Datastores und VM-Snapshots verstehen. OpenShift Virtualization stellt andere APIs bereit, und Backup-Anbieter unterstützen diese in sehr unterschiedlichem Umfang.
Für Unternehmen, die Veritas Enterprise Vault, Veritas Backup Exec oder ähnliche Veritas-Lösungen einsetzen, hängt die Integrationslage von Produktversion und OpenShift-Konfiguration ab. Veritas baut seine Kubernetes-nativen Backup-Fähigkeiten aus, doch die konkreten Möglichkeiten für VMs auf OpenShift Virtualization hängen vom jeweiligen Deployment-Modell ab. Prüfen Sie daher früh, ob Ihre aktuelle Lizenz die erforderlichen Funktionen umfasst, ob Upgrades notwendig sind und ob die Backup-Lösung Ihre Recovery Time Objectives und Recovery Point Objectives für die zu migrierenden Workloads erfüllen kann.
Alternative Lösungen wie Kasten by Veeam und Velero bieten Kubernetes-native Ansätze für VM-Backups innerhalb von OpenShift. Diese Tools integrieren sich direkt mit KubeVirt-APIs und können VMs auf OpenShift Virtualization konsistent schützen. Gleichzeitig bedeuten sie einen Wechsel gegenüber bestehenden Backup-Werkzeugen. Das kann zusätzliches Training und Änderungen im Betrieb erforderlich machen.
Bei der Backup-Integration geht es nicht nur darum, ob Ihre bestehende Lösung grundsätzlich funktioniert. Entscheidend ist, ob sie dasselbe Maß an Sicherheit bietet, das Sie gewohnt sind. Testen Sie Restores vor der Migration. Validieren Sie, dass Ihre Backup-Workflows innerhalb akzeptabler Zeitfenster abschließen. Dokumentieren Sie Recovery-Prozesse für jede Workload-Klasse, die Sie migrieren.
Disaster-Recovery-Überlegungen
Disaster-Recovery-Verfahren aus VMware-Umgebungen hängen häufig von vSphere-spezifischen Funktionen wie Site Recovery Manager (SRM) oder arraybasierter Replikation ab. Diese lassen sich nicht direkt auf OpenShift-Virtualization-Umgebungen übertragen. Entweder benötigen Sie neue DR-Lösungen oder Sie müssen bestehende Verfahren gezielt anpassen.
Wenn Sie arraybasierte Replikation für DR nutzen, kann der CSI-Treiber Ihres Storage-Arrays dieselben Replikationsfähigkeiten bereitstellen – muss es aber nicht. Einige Hersteller haben Operatoren entwickelt, die Kubernetes um Replikationsfunktionen erweitern. Diese Komponenten müssen jedoch separat installiert und konfiguriert werden.
Für SRM-Nutzer ist der Weg weniger eindeutig. Ein direktes OpenShift-Virtualization-Äquivalent zu SRM gibt es nicht. Unternehmen in dieser Situation evaluieren typischerweise DR-Lösungen von Drittanbietern für Kubernetes-Umgebungen oder bauen neue DR-Prozesse mit nativen OpenShift- und Kubernetes-Fähigkeiten auf.
Das DR-Assessment sollte Ihre aktuellen Recovery-Fähigkeiten erfassen, passende Alternativen in OpenShift Virtualization aufzeigen und einen Zeitplan festlegen. Neue DR-Verfahren sollten stehen, bevor produktive Workloads migriert werden.
Ihre Migrationsroadmap aufbauen
Grundprinzipien der Planung
Wenn das Assessment abgeschlossen und die Integrationsrisiken bekannt sind, können Sie Ihre Migrationsroadmap erstellen. Sie sollte realistische Zeitpläne abbilden, Risiken berücksichtigen und so strukturiert sein, dass sie schrittweise Wert liefert, statt auf einen Big-Bang-Cutover zu setzen.
Wir empfehlen eine phasenweise Planung, die organisatorische Fähigkeiten gezielt aufbaut. In frühen Phasen werden weniger kritische Workloads migriert, damit das Team lernen und Prozesse verfeinern kann. Produktive Workloads folgen später, wenn das Team Sicherheit gewonnen und Integrationsprobleme aus den ersten Migrationen gelöst hat.
Kompetenzaufbau / Trainings als Teil der Roadmap
Training wird in Migrationsprojekten oft nachträglich behandelt, zwischen technische Aufgaben geschoben oder als etwas betrachtet, das sich schon von selbst ergeben wird. Wir empfehlen ausdrücklich, Trainingsaktivitäten auf mehreren Ebenen fest in die Migrationsroadmap aufzunehmen.
VMware-Administratoren brauchen praktische Erfahrung mit OpenShift-Konzepten, bevor die Migration beginnt. Dazu gehören Kubernetes-Grundlagen, der Umgang mit YAML-Manifests sowie Sicherheit mit der OpenShift-Webkonsole, der CLI und Konzepten wie GitOps. Ohne diese Basis werden Administratoren während der Migration Schwierigkeiten haben und neue Praktiken nur zögerlich übernehmen.
Application Owner müssen verstehen, wie ihre Workloads in der neuen Umgebung betrieben werden. Dazu gehören Änderungen bei Deployment-Praktiken, Monitoring-Ansätzen und operativen Abläufen. Applikationsteams sollten an der Migration ihrer Workloads beteiligt sein, statt die Aufgabe vollständig an Infrastrukturteams abzugeben.
Operations-Teams benötigen Training zu Backup-Prozessen, Recovery-Abläufen und Monitoring für OpenShift-Virtualization-Umgebungen. Der operative Alltag unterscheidet sich von VMware, und bestehende Runbooks müssen aktualisiert oder vollständig neu geschrieben werden.
Planen Sie Trainings so früh, dass Teams vorbereitet sind, wenn sie das Gelernte anwenden müssen. Wir empfehlen, Administratorentraining bereits während der Assessment-Phase zu starten. Applikationsspezifisches Training sollte parallel zu Pilotmigrationen stattfinden.
Zusätzlich sollten Organisationen dedizierte Zeit und eine strukturierte Umgebung bereitstellen, damit Kunden oder interne Plattformnutzer ihre bestehenden Automatisierungen an die neue Plattform anpassen können. Viele Teams verlassen sich auf Skripte, Pipelines, API-Integrationen oder Infrastructure-as-Code rund um die bestehende Umgebung. Diese Automatisierungen lassen sich nicht automatisch übertragen und müssen möglicherweise refaktoriert oder neu entworfen werden. Ein klares Übergangsfenster, gute Dokumentation und technische Unterstützung reduzieren Reibung deutlich und beschleunigen die Einführung der neuen Umgebung.
Persona Mapping
Wen Sie im Migrationsteam benötigen
Erfolgreiche Migrationen von VMware zu OpenShift Virtualization erfordern vielfältige Expertise, die in der Regel nicht bei einer einzelnen Person liegt. Ein klares Verständnis der beteiligten Rollen erleichtert die Ressourcenplanung und macht Lücken im aktuellen Team sichtbar.
| Rolle | Verantwortung |
|---|---|
| Infrastructure Architect | Zielarchitektur, Cluster-Dimensionierung, Netzwerk- und Storage-Design |
| Storage Specialist | Backend-Storage-Konfiguration, CSI-Treiber-Konfiguration, Einrichtung von Storage Classes, Performance-Validierung, SAN-Zoning |
| Backup Specialist | Integration der Backup-Lösung, Validierung von RPO/RTO, Recovery-Tests |
| Network Engineer | Netzwerktopologie, VLANs, Firewall-Konfiguration, Routing, Load Balancer |
| VMware Administrator | Wissen über die aktuelle Umgebung, Übersetzung von VMware- in Kubernetes-Konzepte |
| Application Owner | Workload-spezifische Anforderungen, Beteiligung an der Migration |
| Project Manager | Teamübergreifende Koordination, Zeitplanung, Stakeholder-Kommunikation |
Diese Rollen liegen in typischen VMware-Umgebungen selten in einem einzigen Team. Die Migration erfordert funktionsübergreifende Zusammenarbeit zwischen Storage-, Netzwerk-, Backup- und Virtualisierungsteams, die bisher möglicherweise weitgehend unabhängig gearbeitet haben. Organisatorisches Change Management ist deshalb ebenso wichtig wie technische Planung.
Fazit
Der Weg von VMware zu OpenShift Virtualization beginnt mit einer ehrlichen Bestandsaufnahme der bestehenden Umgebung und einer realistischen Planung dessen, was sich ändern muss. OpenShift Virtualization selbst ist eine leistungsfähige, ausgereifte Plattform. Mehr Aufmerksamkeit verdienen meist die Integrationsherausforderungen rund um Storage, Backup und Disaster Recovery.
Bevor Sie VM-Migrationen terminieren, investieren Sie Zeit in ein klares Verständnis Ihrer aktuellen Umgebung, in die Validierung von Drittanbieter-Integrationen und in den Aufbau von Teams mit der notwendigen Expertise.
Planen Sie Migrationsroadmaps so, dass sie schrittweise Wert liefern, organisatorische Fähigkeiten kontinuierlich aufbauen und Training als festen Bestandteil behandeln, nicht als nachgelagerte Aktivität.
Im nächsten Blog wechseln wir von der Planung zur Umsetzung. “Migrationen in der Praxis: Erfahrungen aus dem Feld” beleuchtet reale Migrationserfahrungen, typische Herausforderungen während der Umsetzung und praktische Ansätze für häufige Probleme. Diese Erkenntnisse entstehen nur, wenn Migrationen wiederholt und in unterschiedlichen Umgebungen durchgeführt werden.
Falls Sie Fragen haben, sind wir nur einen Klick entfernt.
