Relocate to STACKIT: Überblick zur VMware-Migration

Migration assess discovery design-and-mobilize design +5

CloudMent AI-Powered Cloud Advisor

CloudMent

Partner-Software-Asset für KI-gestützte STACKIT-Migrationsbewertung, R-Strategie-Auswahl, Zielarchitektur, Business Case und evidenzbasierte Migrationsplanung.

CloudMent AI-Powered Cloud Advisor

Migration

Software

Rapid-Discovery-Prozess auf einen Blick

Das folgende Diagramm zeigt den Kern von Rapid Discovery: Rohdaten aus Quellsystemen werden durch Tooling in eine entscheidungsreife Baseline überführt, die frühe Preisindikationen und erste Sizing-Annahmen ermöglicht.

Seitlich wischen, um das ganze Diagramm zu sehen

Methodik in der Praxis

Eine belastbare Rapid Discovery folgt typischerweise einem klaren Ablauf:

Datensammlung aus vorhandenen Quellen (CMDB, Hypervisor-Exporte, Cloud-Inventare, Monitoring, Storage-Reports, Datenbanklisten).
Standardisierung und Konsolidierung der Daten in ein einheitliches Schema.
Kategorisierung nach Workload-Typen und technischen Merkmalen.
Aggregation auf Management-Ebene für schnelle Entscheidungsfindung.
Erste Plausibilisierung mit Fachverantwortlichen.

Ziel ist kein perfektes Zielbild, sondern ein verlässlicher Startpunkt mit ausreichender Genauigkeit für frühe Entscheidungen.

Datenqualität und Annahmen

Die Aussagekraft der Ergebnisse hängt stark von der Datenqualität ab. Typische Herausforderungen sind Dubletten, veraltete Einträge, inkonsistente Benennungen und fehlende Leistungsdaten.

Empfehlung für diese Phase:

Annahmen dokumentieren: Wachstumsraten, Konsolidierungsfaktoren und Reserven transparent halten.
Unklare Datensätze markieren: Unsichere Datensätze kennzeichnen statt früh zu verwerfen.
Konfidenzniveau vergeben: Ergebnisse als hoch, mittel oder niedrig einstufen.

So bleibt die Kostenindikation nachvollziehbar und später in der Discovery-Phase gezielt verfeinerbar.

Verbindung zu Preisindikation und TCO

Rapid Discovery liefert die Mengengerüste für erste Kostenmodelle. Dafür werden die erfassten Bestände in STACKIT-nahe Verbrauchseinheiten überführt, zum Beispiel:

Compute-Sizing: vCPU und RAM als Grundlage nutzen.
Storage-Klassen: Storage-Kapazität und I/O-Profile verwenden.
Managed Services: Datenbanktyp und Größenklassen zuordnen.
Plattformkosten: Cluster- und Node-Anzahlen einbeziehen.

In Kombination mit Betriebsannahmen (Betriebszeiten, Verfügbarkeit, Wachstumspfad) entsteht daraus eine belastbare Preisindikation und ein erster TCO-Korridor.

Typische Ergebnisse

Am Ende der Rapid-Discovery-Phase sollten mindestens folgende Ergebnisse vorliegen:

Konsolidierte Asset-Baseline

Mengen je Technologiebereich liegen konsolidiert vor.

Sinnvolle Segmentierung

Assets sind nach Kritikalität, Umgebung und Modernisierungsbedarf segmentiert.

Nachvollziehbare Annahmen

Annahmen und erkannte Datenlücken sind transparent dokumentiert.

Erste Kostenindikation

Eine erste Kostenbandbreite mit den wichtigsten Treibern liegt vor.

Priorisierte Kandidaten

Eine priorisierte Liste für die vertiefende Discovery-Phase ist verfügbar.

Diese Ergebnisse bilden die Arbeitsgrundlage für Architektur, Planung und Governance der nächsten Assess-Schritte.

Risiken und Gegenmaßnahmen

Häufige Risiken in Rapid Discovery sind zu grobe Kategorisierung, unvollständige Quellsysteme oder eine Überschätzung der Datenreife.

Bewährte Gegenmaßnahmen:

Datenquellen kombinieren: Mehrere Quellen nutzen statt nur einer Quelle.
Ausreißer prüfen: Sehr große oder sehr alte Systeme systematisch bewerten.
Perspektiven abstimmen: Finanz- und Technikblick gemeinsam ausrichten, um Fehlinterpretationen zu vermeiden.

Damit bleibt die Phase schnell, ohne an Entscheidungsqualität zu verlieren.

Übergang in die Discovery-Phase

Der Übergang ist erreicht, wenn ein belastbarer Überblick über Mengen, Technologietypen und Kostenhebel vorliegt und die offenen Punkte klar benannt sind.

In der Discovery-Phase werden diese offenen Punkte gezielt geschlossen, unter anderem durch Interviews mit Application Ownern, vertiefende Assessments und die Analyse von Abhängigkeiten, Compliance- und Betriebsanforderungen.

STEP

Discovery

Erweitern Sie die Basislinie des Bestands um Abhängigkeiten, Anwendungskritikalität, Betriebsgrenzen und repräsentative CPU-, Memory-, Storage- und Netzwerk-Messwerte, die für Relocate-Design und Wellenbildung benötigt werden.

In 4 Trails

Discovery-Analysefluss, der technische Nachweise und Input von Application Ownern in Migrationsentscheidungen zusammenführt

Überblick: Discovery

Discovery ist eines der ersten und wichtigsten Module in der Phase Design and Mobilize. Es verfeinert die Ergebnisse aus Rapid Discovery und liefert die notwendige Tiefe, um Entscheidungen zur Architektur und die Reihenfolge der Migration belastbar zu planen.

Das primäre Ziel ist ein realistisches, auf Fakten gestütztes Verständnis der bestehenden IT-Landschaft, der Business-Prioritäten und der organisatorischen Bereitschaft, bevor Zielbild und Migrationsplan im Detail festgelegt werden.

Zentrale Ziele

Vollständige Basis

Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen hinausgeht.

Transparente Abhängigkeiten

Technische und prozessuale Abhängigkeiten identifizieren, um versteckte Migrationsblocker zu vermeiden.

Business-Abgleich

Technische Erkenntnisse mit Kritikalität, Zeitrahmen und Risikoprofil des Business verknüpfen.

Planungsreife

Eine entscheidungsreife Grundlage für Zielbild und Migrationswellen erstellen.

Was Discovery typischerweise erfasst

Inventarisierung

Vollständige Erfassung von Servern, virtuellen Maschinen, Datenbanken, Middleware und Anwendungen.

Abhängigkeitsanalyse

Abbildung von Kommunikationspfaden und Laufzeitabhängigkeiten zwischen Systemen und Anwendungen.

Ressourcennutzung

Analyse von CPU-, RAM-, Storage- und I/O-Verhalten über einen repräsentativen Zeitraum.

Betriebskontext

Erhebung von Anforderungen zu Backup, Patch, SLA, Compliance und betrieblichen Randbedingungen.

Input der Application Owner

Strukturierte Fragebögen und Interviews zur Validierung von Annahmen und zum Schließen von Datenlücken.

Typisches Vorgehen

In der Praxis wird Discovery häufig gemeinsam mit STACKIT Partnern durchgeführt. Partner nutzen dabei meist eigene Tool-Landschaften, um technische Daten zu sammeln, zu normalisieren und in einer zentralen Sammlung zu konsolidieren.

Häufig werden aus diesen Tools heraus auch gezielte Rückfragen an Application Owner gestellt, um technische Befunde um Business und Betrieb zu ergänzen.

Dieses kombinierte Modell erhöht Geschwindigkeit und Konsistenz und verankert Stakeholder-Validierung direkt im Prozess.

Zwei Evidence-Streams: technisch vs. human-driven

Discovery kombiniert bewusst zwei sich ergänzende Evidence-Streams:

Technisch ermittelte Evidenz: Tooling-basierte Befunde aus Inventar-Exporten und Abhängigkeits-Signalen. Dieser Stream liefert Skalierbarkeit, Konsistenz und Wiederholbarkeit.
Application-Owner-Anreicherung (human-driven): Validierte Angaben zu Business-Kritikalität, Lifecycle-Absicht, Release-Restriktionen und betrieblicher Realität aus Interviews und Fragebögen.

Keiner der beiden Streams ist alleine ausreichend. Technische Evidenz ohne Owner-Kontext kann kritische Workloads falsch einordnen. Human-Input ohne technische Grundlage kann Kopplungen und Kapazitätsrisiken verdecken. Die Qualität von Discovery entsteht aus der Zusammenführung beider Streams in eine belastbare Basis für Entscheidungen.

Discovery-Prozess auf einen Blick

Die folgende Darstellung zeigt, wie Discovery technische und menschliche Eingaben in entscheidungsreife Ergebnisse für die nachgelagerten Module überführt.

Seitlich wischen, um das ganze Diagramm zu sehen

Typische Analyse-Muster im Discovery-Tooling

Im Discovery werden typischerweise die folgenden Analyse-Muster angewendet:

Daten normalisieren: Heterogene Exporte in ein konsistentes, auf Anwendungen ausgerichtetes Modell überführen.
Abhängigkeiten abbilden: Kommunikation, Datenaustausch und Kopplungen erkennen.
Kritikalitäts- und Risiko-Bewertung: Business-Impact, Ausfall-Domänen und Compliance-Exposition bewerten.
Analyse der Nutzung: Daten zu CPU, RAM und Storage für Right-Sizing und die Planung der Zielumgebung belastbar ableiten.
Segmentierung: Anwendungen nach Reifegrad, Restriktionen und Strategie-Fit gruppieren.
Wellen-Simulation: Move Groups und Optionen für die Reihenfolge unter Abhängigkeitsrestriktionen modellieren.
Gap- und Annahmen-Tracking: Offene Punkte transparent mit einer Einschätzung führen.

Diese Analysen bilden die technische Grundlage. Der human-driven Stream validiert, priorisiert und ordnet diese Befunde für umsetzbare Migrationsentscheidungen ein.

KI-gestützte Discovery-Assets

KI-gestützte Discovery-Assets können Workload-Eingaben, Service-Mapping, Readiness-Befunde und R-Strategie-Signale strukturieren, bevor Architekten die Discovery-Baseline validieren.

Asset-Titel

Framework

Asset-Typ

Migration assess discovery design-and-mobilize design +5

CloudMent AI-Powered Cloud Advisor

CloudMent

Cloud Framework Coriolis STACKIT Installer Stellt die Coriolis-Appliance reproduzierbar bereit, nachdem Quell- und Zielvoraussetzungen geklärt wurden. Seite öffnen

Partner-Software-Asset für KI-gestützte STACKIT-Migrationsbewertung, R-Strategie-Auswahl, Zielarchitektur, Business Case und evidenzbasierte Migrationsplanung.

CloudMent AI-Powered Cloud Advisor

Migration

Software

Methodik in der Praxis

Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.

Warum Discovery kritisch ist

Risiko der Migration reduzieren: Frühe Sichtbarkeit auf verdeckte Abhängigkeiten senkt Ausfall- und Rollback-Risiken.
Planung der Wellen verbessern: Workloads lassen sich realistisch nach Kopplung, Kritikalität und Reifegrad gruppieren.
Falsche Dimensionierung vermeiden: Gemessene Nutzung ersetzt Annahmen in der Zielkapazitätsplanung.
Governance absichern: Security-, Compliance- und Betriebsanforderungen werden vor der Umsetzung adressiert.
Stakeholder-Buy-in stärken: Gemeinsame Fakten verbessern die Entscheidungsqualität zwischen Business und IT.

Relevanz für nachgelagerte Module

Die Ergebnisse aus Discovery werden direkt in den nachgelagerten Modulen wiederverwendet:

Design

Nutzt Abhängigkeits-, Kapazitäts- und Risikosignale zur Ausgestaltung tragfähiger Zielarchitekturen.

Security und Compliance

Nutzt Datenklassifizierung und Control-Gaps zur Priorisierung von Sicherheitsanforderungen.

Landing Zone

Nutzt Plattform- und Governance-Restriktionen für grundlegende Setup-Entscheidungen.

Migrationsplan

Nutzt Move Groups, Kritikalität und Sequenzrestriktionen für realistische Wellenplanung.

Operating Model und Business Case

Nutzt Ownership-, Prozess- und Value/Risk-Signale für Rollenbild und Investitionspriorisierung.

Ergebnisse aus Discovery

Mindestens folgende Ergebnisse sollten aus Discovery vorliegen:

Konsolidierte Applikations-Basis: Inventar nach Domäne, Umgebung und Kritikalität.
Abhängigkeitskarte: Verifizierte Upstream-/Downstream-Beziehungen und wichtige Integrationen.
Profil der Nutzung: Belastbare Daten zur Auslastung und Sizing-Annahmen.
Constraint-Register: Security-, Compliance-, Lizenz- und Einschränkungen im Betrieb.
Migrationsreife-Sicht: Priorisierte Kandidaten, Risiken und Empfehlungen für die Reihenfolge.

Diese Ergebnisse sind unverzichtbare Voraussetzungen für das nachfolgende detaillierte Design und einen realistischen Migrationsplan.

Zweck

Nutzen Sie dieses Runbook, bevor Sie virtuelle VMware-Maschinen einer Relocate-Welle zuordnen. Es überführt Discovery-Evidenz in eine technische Entscheidung zur Quellbereitschaft und trennt allgemeine VMware-Prüfungen von den Anforderungen von Cloudbase Coriolis und Hystax Acura.

Das Ergebnis ist ein Bereitschaftsnachweis pro VM mit dem Status unterstützt, bedingt oder blockiert. Beheben Sie blockierende Punkte vor Beginn der Replikation, statt Unsicherheit in das Cutover-Fenster zu verschieben.

Erforderliche Eingaben

VM-Inventar: vCenter, Cluster, Host, Datastore, VM-Hardwareversion, Firmware, Betriebssystem, Status der VMware Tools, virtuelle Festplatten, Controller, NICs, Adressen und angeschlossene Geräte.
Workload-Kontext: Application Owner, Kritikalität, Abhängigkeiten, Konsistenzanforderungen, Recovery-Ziele, zulässige Ausfallzeit und Rollback-Toleranz.
Performance-Evidenz: Repräsentative Daten zu CPU, Arbeitsspeicher, IOPS, Durchsatz, Latenz, Warteschlangen, Kapazität und Wachstum statt ausschließlich provisionierter VMware-Kapazität.
Migrationspfad: Ausgewähltes Tool, Coriolis oder Acura, und dessen aktuelle Kompatibilitätsmatrix für Quelle und Ziel.

Allgemeine VMware-Bereitschaftsprüfungen

Gast und virtuelle Hardware

Bestätigen Sie, dass Gastbetriebssystem, Architektur, Dateisysteme, Partitionslayout und Boot-Modus vom ausgewählten Tool und dem STACKIT Ziel unterstützt werden.
Dokumentieren Sie BIOS- oder UEFI-Firmware, Secure Boot, virtuelle Festplattencontroller, NIC-Modelle, statische Routen und gastspezifische Treiber, die konvertiert oder ersetzt werden müssen.
Identifizieren Sie verschlüsselte Festplatten, Raw Device Mappings, Shared Disks, Independent Disks, Passthrough-Geräte, Nested Virtualization und Wechselmedien. Behandeln Sie jeden nicht unterstützten Anschluss als Blocker oder entwerfen Sie einen expliziten Ersatz.
Prüfen Sie den aktuellen Zustand der VMware Tools. Auch wenn das Migrationstool agentenlos arbeitet, verbessern aktuelle Gasttools Inventarqualität, Snapshot-Koordination und kontrolliertes Herunterfahren.
Klären Sie Lizenzierung und Aktivierungsverhalten des Betriebssystems nach dem Wechsel von virtueller Hardware und Cloud-Umgebung.

Quellzustand und Snapshot-Sicherheit

Beheben Sie aktive Alarme, fehlgeschlagene Backups, verwaiste Snapshots, Snapshot-Konsolidierungswarnungen sowie Datei- oder Volume-Fehler vor der Replikation.
Prüfen Sie, ob anwendungs- oder crash-konsistente Snapshots die Recovery-Anforderungen erfüllen. Datenbanken und andere zustandsbehaftete Systeme benötigen gegebenenfalls zusätzlich Application Quiescing oder native Replikation.
Reservieren Sie Datastore-Kapazität für Migrations-Snapshots und Change Tracking. Berücksichtigen Sie Wachstum, erwartete Schreibrate, Replikationsdauer und Wiederholungspuffer.
Testen Sie die Backup-Wiederherstellung unabhängig vom Migrationstool und bewahren Sie einen Recovery Point auf, der vor dem ersten Migrationsvorgang liegt.

Netzwerk- und Zugriffspfad

Messen Sie verfügbare Bandbreite, Latenz, Paketverlust und tägliche Datenänderungsrate zwischen Quelle und Ziel. Stellen Sie sicher, dass initiale Kopie und Deltas in den Wellenplan passen.
Validieren Sie DNS, NTP, MTU, Proxy, Routing, NAT und Firewall-Verhalten über Management- und Datenpfade. Dokumentieren Sie jede erforderliche Quelle, jedes Ziel, Protokoll, jeden Port und Owner.
Verwenden Sie dedizierte Service Accounts mit minimalen Rechten für vCenter oder ESXi und das STACKIT Ziel. Prüfen Sie API-Zugriff und Zertifikatsvertrauen vor dem Anlegen der Endpoints.
Bestätigen Sie Zieladressierung, Security Groups, DNS- und Load-Balancer-Änderungen sowie den Mechanismus zur Verkehrsumstellung. Replikationssoftware ersetzt kein Netzwerk-Cutover-Runbook.

Coriolis-Bereitschaftspfad

Wenden Sie diese Prüfungen an, wenn Cloudbase Coriolis ausgewählt ist:

Prüfen Sie die unterstützten Versionen des VMware-Quell- und STACKIT-Ziel-Endpoints gegen die für die Welle eingesetzte Coriolis-Version.
Erstellen und testen Sie den VMware-Endpoint mit einer dedizierten API-Identität. Stellen Sie sicher, dass Coriolis die ausgewählten VMs, Disks, Netzwerke und Storage-Ressourcen inventarisieren kann.
Erstellen und validieren Sie den STACKIT-Ziel-Endpoint. Definieren Sie anschließend Quell- und Ziel-Minion-Pools mit ausreichender Worker-Kapazität und Parallelität für die geplante Welle.
Definieren Sie Quell-Ziel-Mappings für Netzwerk und Storage, bevor Sie Transfer- und Deployment-Definitionen erstellen. Prüfen Sie Machine Type, Boot-Volume, Daten-Volumes und Security Groups.
Validieren Sie die für die bereitgestellte Architektur erforderliche Konnektivität der Minion-Worker und Datentransfers. HTTPS-Zugriff auf die Coriolis-Oberfläche allein belegt keinen migrationsbereiten Datenpfad.
Prüfen Sie Gastkonvertierung und OS Morphing einschließlich Bootloader, Storage-Treiber, Netzwerktreiber und Cloud-Initialisierung. Markieren Sie Workloads mit manueller Nacharbeit.

Der Coriolis STACKIT Installer stellt die Coriolis-Appliance auf STACKIT bereit und konfiguriert sie. Er erstellt keine VMware-Berechtigungen, löst keine nicht unterstützten Quellgeräte auf, dimensioniert keine Ziel-VMs und validiert nicht den Quell-Ziel-Transferpfad.

Hystax-Acura-Bereitschaftspfad

Wenden Sie diese Prüfungen an, wenn Hystax Acura ausgewählt ist:

Stellen Sie sicher, dass VMware Tools auf jeder ausgewählten VM installiert sind und ausgeführt werden.
Prüfen Sie, ob Changed Block Tracking und VMware-Snapshots für die ausgewählten virtuellen Festplatten verwendet werden können und kein kollidierender Snapshot-Vorgang aktiv ist.
Halten Sie mindestens 10 Prozent freie Kapazität auf den Quell-Datastores vor und erhöhen Sie diesen Puffer für Workloads mit hoher Änderungsrate oder langen Replikationsfenstern.
Stellen Sie die dokumentierten vSphere-API-Berechtigungen bereit und validieren Sie die Verbindung von den für Discovery und Replikation zuständigen Acura-Komponenten zu vCenter oder ESXi über die TCP-Ports 443 und 902.
Installieren und prüfen Sie die erforderlichen Hystax-Replikationsagenten auf den Quell-ESXi-Hosts, bevor die erste vollständige Replikation geplant wird.
Planen Sie mindestens eine isolierte Testmigration. Verkehrsumleitung, DNS-Änderungen und Application Freeze bleiben explizite Aktivitäten des Cutover-Runbooks außerhalb der Acura-Replikation.

Bereitschaftsentscheidung

Dokumentieren Sie das Ergebnis für jede VM und bewahren Sie die verwendete Evidenz auf.

Gastkompatibilität: Bestanden bei unterstütztem Betriebssystem, Boot-Modus, Disk-Layout und Konvertierungspfad. Blockiert bei nicht unterstütztem Gerät, Verschlüsselungsverfahren, Architektur oder Boot-Pfad.
Quellintegrität: Bestanden bei gesunder VM, getestetem Recovery Point und sicherem Snapshot-Zustand. Blockiert bei Konsolidierungsfehlern, fehlgeschlagenem Backup oder unzureichender Datastore-Kapazität.
Performance-Baseline: Bestanden mit repräsentativen Messungen für CPU, Arbeitsspeicher, Storage und Wachstum. Blockiert, wenn nur provisionierte Kapazität oder unvollständige Peak-Daten vorliegen.
Zugriff: Bestanden mit getesteten Endpoint-Zugangsdaten nach Least-Privilege-Prinzip und Zertifikatsvertrauen. Blockiert bei fehlenden API-Berechtigungen oder unverwalteten Shared Credentials.
Transferpfad: Bestanden mit gemessener Kapazität und validierten Routen, Ports, DNS, NTP und MTU. Blockiert bei Firewall-Lücken, instabilen Verbindungen oder einer Kopierdauer außerhalb des Wellenplans.
Cutover-Eingaben: Bestanden mit Ziel-Mappings, Validierungstests, Rollback-Trigger und Quellaufbewahrung. Blockiert bei undefinierter Verkehrsumstellung oder nicht testbarem Rollback-Pfad.

Geben Sie eine VM erst für die Replikation frei, wenn jeder Blocker einen Owner und ein Lösungsdatum hat. Bedingte Punkte benötigen einen ausführbaren Behebungsschritt im Wellen-Runbook; Beobachtungen ohne Auswirkungen können im Evidenznachweis verbleiben.

Primärquellen

Externe Quelle cloudbase.it Cloudbase Coriolis Externe Seite öffnen Führt von der Route weg Externe Quelle hystax.com Hystax Acura Live Migration Externe Seite öffnen Führt von der Route weg

LIFT

Design

Bestätigen Sie, dass der Workload VM-basiert bleiben soll und eine Verlagerung seiner Runtime-Platzierung mit minimalem Redesign besser passt als ein Rehost-Rebuild oder ein Plattformwechsel.

In 1 Trail

R-Strategie-Methode mit sieben Migrationspfaden und Relocate als Bewegungspfad für VM-Landschaften

Überblick: Relocate

Relocate verschiebt Workloads mit minimalen Architektur-Änderungen in ein STACKIT-kompatibles Zielsetup. Im Fokus steht eine schnelle und risikoarme Überführung, nicht die sofortige cloud-native Modernisierung.

Konkret bedeutet Relocate: Das bestehende VM-Betriebsmuster bleibt weitgehend erhalten. Geändert wird vor allem der Zielstandort inklusive Plattformkontrollen, nicht das Laufzeitmodell der Workloads.

Relocate vs. Rehost in STACKIT

Relocate und Rehost sind beide Low-Change-Pfade, unterscheiden sich aber in Tiefe und Zielbild der Migration.

Relocate in STACKIT: Fokus auf Überführung bestehender VM-zentrierter Landschaften in ein kompatibles STACKIT Zielsetup mit möglichst wenig Umformung.
Rehost in STACKIT: Fokus auf anwendungsbezogenen Lift-and-Shift mit klarer Zielabbildung, Cutover-Design und standardisierten Runbooks für den Factory-Betrieb.
Betriebliche Konsequenz: Relocate ist oft der schnellste Weg für Estate-Movement, Rehost ist oft der klarere Weg für wiederholbare Wellenumsetzung je Anwendung.
Planerische Konsequenz: Relocate bei Priorität auf Erhalt bestehender Betriebsmuster, Rehost bei Priorität auf standardisierte Migration über viele Anwendungen.

Vorgehensvarianten bei Relocate

Relocate kann in zwei operativen Varianten umgesetzt werden, je nach Estate-Grösse, Unterschiedlichkeit und Cutover-Risiko.

Tool-gestütztes Relocate: Bevorzugt in Large-Scale-Programmen, wenn Durchsatz, Konsistenz und ein wiederholbarer Ablauf der Wellen im Fokus stehen.
Kontrolliertes manuelles Relocate: Sinnvoll für kleinere oder besondere Workloads, die eine engere manuelle Steuerung brauchen.
Gemeinsame Qualitätsanforderungen: Beide Varianten brauchen dieselben Cutover-Kontrollen, Rollback-Logik und Day-1-Betriebsreife.

Wann Relocate sinnvoll ist

Zeitkritische Transition: Strikte Exit-Termine oder Vorgaben zur Datenlokation.
Geringe Veränderungstoleranz: Fachbereiche können aktuell keine größeren Umbauten tragen.
Stabile Bestands-Workloads: VM-basierte Muster sind bekannt und betrieblich beherrscht.
Spätere Modernisierung geplant: Replatform/Refactor ist als Folgeschritt vorgesehen.

Design-Aspekte im STACKIT-Kontext

Landing-Zone-Kompatibilität

Netzwerksegmentierung, IAM-Modell und Security Controls vor der Migration verifizieren.

Sizing und Performance

VM-Sizing und Storage-Profile neu baseline, um Überprovisionierung zu vermeiden.

Betriebliche Kontrollen

Monitoring-, Backup- und Recovery-Kontrollen ab Tag 1 im Ziel sicherstellen.

Umgang mit grossen Datenmengen

Für sehr grosse VM-Datenbestände Pre-Seeding, Delta-Sync-Fenster und Bandbreitensteuerung vorab festlegen, um Cutover-Downtime zu begrenzen.

Pfad für spätere Modernisierung

Klare Trigger für spätere Replatform/Refactor-Entscheidungen dokumentieren.

Datenmigration bei Relocate

Bei Relocate ist die Datenmigration oft implizit gelöst, weil die gesamte VM inklusive Storage verschoben wird. Trotzdem sollten bei großen Datenmengen explizite Design-Entscheidungen getroffen werden:

Anbindung im Netzwerk: End-to-End-Durchsatz, Latenz und Stabilität des Pfads für den Transfer im Fenster der Migration verifizieren.
Storage-Klasse: Quell- und Ziel-Storage-Klassen vor dem Cutover auf erforderliche IOPS-/Throughput-Profile abstimmen.
Pre-Seeding: Daten möglichst vor dem Cutover übertragen.
Delta-Synchronisation: Im finalen Fenster nur die letzten Änderungen nachziehen.
Integritätsprüfung: Prüfsummen und Stichproben-Reads für migrierte Volumes definieren.
Rollback-Checkpoints: Quell-Snapshots bis zur Abnahme im Ziel vorhalten.

Empfohlener Design-Ablauf

Workload-Abhängigkeiten und betriebliche Rahmenbedingungen bestätigen.
Zielabbildung in STACKIT inklusive Netzwerk- und Security-Vorgaben definieren.
Migrationssequenz, Downtime-Annahmen und Rollback-Modell entwerfen.
Betriebsbereitschaft (Monitoring, Backup, Incident-Prozess) validieren.
Optimierungs-Backlog für die Zeit nach der Überführung festlegen.

Erforderliche Ergebnisse

Gemeinsame Ergebnisse für alle Migrationspfade

Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
Übergabepaket für Migration Factory Setup und Wellenplanung.

Relocate-spezifische Ergebnisse

Relocate-Entscheidungsnachweis mit Trade-offs und Exit-Kriterien.
Zielabbildung pro Workload.
Cutover- und Rollback-Design.
Day-1-Betriebscheckliste.
Post-Relocate-Optimierungs-Backlog.

Diagramm-Schrittreferenz

Define Landing Zone

Landing-Zone-Vorgaben für die Relocate-Welle als Startpunkt der Ausführung festlegen. Account-Struktur, Netzwerksegmentierung und Basis-Kontrollen so abstimmen, dass bestehende VM-Betriebsmuster ohne Governance-Verstöße übertragen werden können.

Use migration tools

Tool-gestützten Vorgehenspfad für skalierbare, wiederholbare Relocate-Wellen festlegen. Ausführungsrollen, Batches und Rollback-Checkpoints früh festlegen, damit große VM-Landschaften konsistent über mehrere Wellen hinweg übertragen werden.

Asset-Titel

Framework

Asset-Typ

Migration design-and-mobilize use-cases relocate vmware +3

Verschachteltes VMware-ESXi-Lab auf STACKIT erstellen

STACKIT

Erstellen Sie ein verschachteltes VMware-ESXi-Lab auf STACKIT mit QEMU/KVM, geeigneten Disks, privatem Managementnetz sowie klaren Lizenz- und Abnahmegrenzen.

Verschachteltes VMware-ESXi-Lab auf STACKIT erstellen

Migration

Anleitung

Migration design-and-mobilize use-cases relocate vmware +3

STACKIT

Bereitet VMware-Bestände für kontrollierte Relocate-Wellen vor und prüft Gastkompatibilität, Quellzustand, Messdaten, Zugriffe und Transferpfade.

VMware Relocate Source Readiness

Migration

Runbook

Migration design-and-mobilize design relocate migration +2

Cloudbase Coriolis

Cloudbase Solutions

Migration design-and-mobilize design relocate coriolis +4

Coriolis unterstützt skalierbare Migration und Disaster Recovery zu STACKIT durch agentenlose Orchestrierung, Replikation und plattformübergreifende Mobilität.

Cloudbase Coriolis

Migration

Software

Coriolis STACKIT Installer

STACKIT

Migration design-and-mobilize design relocate live-migration +2

Der Coriolis STACKIT Installer stellt eine Cloudbase Coriolis Appliance aus einem OVA mit Image-Normalisierung, Netzwerk, DNS und TLS reproduzierbar bereit.

Coriolis STACKIT Installer

Migration

Software

Hystax Acura Live Migration

Hystax

Hystax Acura Live Migration automatisiert VM-Replikation, isolierte Tests, Migrationspläne und kontrollierte Cutovers aus heterogenen Quellen nach STACKIT.

Hystax Acura Live Migration

Migration

Software

Migration design-and-mobilize use-cases relocate vmware +4

Ausführung einer VMware-Relocate-Welle

STACKIT

Migration migrate optimize relocate vm +3

Führen Sie kontrollierte VMware-Relocate-Wellen nach STACKIT über vollständige Coriolis- oder Hystax-Acura-Pfade aus, mit Testmigration, Cutover, Validierung und Rollback.

Ausführung einer VMware-Relocate-Welle

Migration

Runbook

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

STACKIT

Dimensioniert verlagerte STACKIT VMs anhand repräsentativer Telemetrie neu, mit kontrollierten Machine-Type-Änderungen, Storage-Migration, Validierung und Rollback.

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

Migration

Runbook

Install

Manuelle Installationsschritte für nicht tool-gestützte Ausnahme-Workloads beschreiben.

Ziel-VM und Storage vorbereiten: Ziel-VM erstellen, erforderliche Disks anbinden und CPU-/Memory-Sizing anhand gemessener Werte aus der Quelle ausrichten.
Erforderliche Basis-Komponenten installieren: Hypervisor-Guest-Tools, OS-Pakete und Runtime-Voraussetzungen einrichten, damit der Workload stabil starten kann.
Workload-Artefakte übertragen: Disk-Images, Boot-Dateien und Service-Units/Skripte über einen kontrollierten Transfer-Pfad kopieren.
Boot- und Host-Baseline prüfen: Erfolgreichen Boot, Dateisystem-Mount-Integrität und Kernnetzwerk-Erreichbarkeit vor der Konfiguration verifizieren.
Runbook Blueprint
Cloud-Design-Patterns

Config

Manuelle Konfiguration und den Abgleich der Parameter im Ziel festlegen.

System- und Parameter der Anwendung angleichen: Hostname, DNS, Synchronisierung der Zeit und Umgebungswerte gemäß Workload-Anforderungen setzen.
Security- und Zugriffsmodell konfigurieren: Regeln für Zugriffe, Service-Credentials und administrative Grenzen für den Betrieb im Ziel anwenden.
Betriebs-Basis aktivieren: Monitoring-Agenten, Log-Forwarding, Backup-Jobs und Restore-Test-Hooks einrichten.
Konfigurationsparität prüfen: Wichtige Runtime-Parameter mit der Basis der Quelle vergleichen und akzeptierte Abweichungen dokumentieren.
Runbook Blueprint
Migrationsplan

Deploy

Manuelle Deployment-Reihenfolge und Handover-Checks definieren.

Cutover-Sequenz ausführen: Schreibzugriffe auf die Quelle stoppen, finalen Delta-Sync fahren und den Ziel-Workload in der freigegebenen Reihenfolge aktivieren.
Verhalten des Service validieren: Smoke- und Critical-Path-Tests inklusive Konnektivität zu abhängigen Systemen durchführen.
Stabilisieren und überwachen: Schlüsselmetriken, Fehlerraten und Betriebs-Alarme während des vereinbarten Hypercare-Fensters beobachten.
Ownership-Übergang abschließen: Support-Verantwortung, Eskalationswege und Rollback-Abschlusskriterien verbindlich bestätigen.
Migrationsplan
Runbook Blueprint

Validation handover

Festlegen, wie Relocate-Ergebnisse in das gemeinsame Validation-Gate einfliessen. Technische Evidenz, aktualisierte Risiko-Logs und operativen Abnahme-Status bündeln, damit die Wellen-Governance Entscheidungen ohne Rework treffen kann.

Überblick: Relocate

Relocate verschiebt Workloads mit minimalen Architektur-Änderungen in ein STACKIT-kompatibles Zielsetup. Im Fokus steht eine schnelle und risikoarme Überführung, nicht die sofortige cloud-native Modernisierung.

Konkret bedeutet Relocate: Das bestehende VM-Betriebsmuster bleibt weitgehend erhalten. Geändert wird vor allem der Zielstandort inklusive Plattformkontrollen, nicht das Laufzeitmodell der Workloads.

Relocate vs. Rehost in STACKIT

Relocate und Rehost sind beide Low-Change-Pfade, unterscheiden sich aber in Tiefe und Zielbild der Migration.

Relocate in STACKIT: Fokus auf Überführung bestehender VM-zentrierter Landschaften in ein kompatibles STACKIT Zielsetup mit möglichst wenig Umformung.
Rehost in STACKIT: Fokus auf anwendungsbezogenen Lift-and-Shift mit klarer Zielabbildung, Cutover-Design und standardisierten Runbooks für den Factory-Betrieb.
Betriebliche Konsequenz: Relocate ist oft der schnellste Weg für Estate-Movement, Rehost ist oft der klarere Weg für wiederholbare Wellenumsetzung je Anwendung.
Planerische Konsequenz: Relocate bei Priorität auf Erhalt bestehender Betriebsmuster, Rehost bei Priorität auf standardisierte Migration über viele Anwendungen.

Vorgehensvarianten bei Relocate

Relocate kann in zwei operativen Varianten umgesetzt werden, je nach Estate-Grösse, Unterschiedlichkeit und Cutover-Risiko.

Tool-gestütztes Relocate: Bevorzugt in Large-Scale-Programmen, wenn Durchsatz, Konsistenz und ein wiederholbarer Ablauf der Wellen im Fokus stehen.
Kontrolliertes manuelles Relocate: Sinnvoll für kleinere oder besondere Workloads, die eine engere manuelle Steuerung brauchen.
Gemeinsame Qualitätsanforderungen: Beide Varianten brauchen dieselben Cutover-Kontrollen, Rollback-Logik und Day-1-Betriebsreife.

Wann Relocate sinnvoll ist

Zeitkritische Transition: Strikte Exit-Termine oder Vorgaben zur Datenlokation.
Geringe Veränderungstoleranz: Fachbereiche können aktuell keine größeren Umbauten tragen.
Stabile Bestands-Workloads: VM-basierte Muster sind bekannt und betrieblich beherrscht.
Spätere Modernisierung geplant: Replatform/Refactor ist als Folgeschritt vorgesehen.

Design-Aspekte im STACKIT-Kontext

Landing-Zone-Kompatibilität

Netzwerksegmentierung, IAM-Modell und Security Controls vor der Migration verifizieren.

Sizing und Performance

VM-Sizing und Storage-Profile neu baseline, um Überprovisionierung zu vermeiden.

Betriebliche Kontrollen

Monitoring-, Backup- und Recovery-Kontrollen ab Tag 1 im Ziel sicherstellen.

Umgang mit grossen Datenmengen

Für sehr grosse VM-Datenbestände Pre-Seeding, Delta-Sync-Fenster und Bandbreitensteuerung vorab festlegen, um Cutover-Downtime zu begrenzen.

Pfad für spätere Modernisierung

Klare Trigger für spätere Replatform/Refactor-Entscheidungen dokumentieren.

Datenmigration bei Relocate

Bei Relocate ist die Datenmigration oft implizit gelöst, weil die gesamte VM inklusive Storage verschoben wird. Trotzdem sollten bei großen Datenmengen explizite Design-Entscheidungen getroffen werden:

Anbindung im Netzwerk: End-to-End-Durchsatz, Latenz und Stabilität des Pfads für den Transfer im Fenster der Migration verifizieren.
Storage-Klasse: Quell- und Ziel-Storage-Klassen vor dem Cutover auf erforderliche IOPS-/Throughput-Profile abstimmen.
Pre-Seeding: Daten möglichst vor dem Cutover übertragen.
Delta-Synchronisation: Im finalen Fenster nur die letzten Änderungen nachziehen.
Integritätsprüfung: Prüfsummen und Stichproben-Reads für migrierte Volumes definieren.
Rollback-Checkpoints: Quell-Snapshots bis zur Abnahme im Ziel vorhalten.

Empfohlener Design-Ablauf

Workload-Abhängigkeiten und betriebliche Rahmenbedingungen bestätigen.
Zielabbildung in STACKIT inklusive Netzwerk- und Security-Vorgaben definieren.
Migrationssequenz, Downtime-Annahmen und Rollback-Modell entwerfen.
Betriebsbereitschaft (Monitoring, Backup, Incident-Prozess) validieren.
Optimierungs-Backlog für die Zeit nach der Überführung festlegen.

Erforderliche Ergebnisse

Gemeinsame Ergebnisse für alle Migrationspfade

Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
Übergabepaket für Migration Factory Setup und Wellenplanung.

Relocate-spezifische Ergebnisse

Relocate-Entscheidungsnachweis mit Trade-offs und Exit-Kriterien.
Zielabbildung pro Workload.
Cutover- und Rollback-Design.
Day-1-Betriebscheckliste.
Post-Relocate-Optimierungs-Backlog.

Diagramm-Schrittreferenz

Define Landing Zone

Landing-Zone-Vorgaben für die Relocate-Welle als Startpunkt der Ausführung festlegen. Account-Struktur, Netzwerksegmentierung und Basis-Kontrollen so abstimmen, dass bestehende VM-Betriebsmuster ohne Governance-Verstöße übertragen werden können.

Use migration tools

Tool-gestützten Vorgehenspfad für skalierbare, wiederholbare Relocate-Wellen festlegen. Ausführungsrollen, Batches und Rollback-Checkpoints früh festlegen, damit große VM-Landschaften konsistent über mehrere Wellen hinweg übertragen werden.

Asset-Titel

Framework

Asset-Typ

Migration design-and-mobilize use-cases relocate vmware +3

Verschachteltes VMware-ESXi-Lab auf STACKIT erstellen

STACKIT

Erstellen Sie ein verschachteltes VMware-ESXi-Lab auf STACKIT mit QEMU/KVM, geeigneten Disks, privatem Managementnetz sowie klaren Lizenz- und Abnahmegrenzen.

Verschachteltes VMware-ESXi-Lab auf STACKIT erstellen

Migration

Anleitung

Migration design-and-mobilize design relocate migration +2

Cloudbase Solutions

Migration design-and-mobilize design relocate coriolis +4

Coriolis unterstützt skalierbare Migration und Disaster Recovery zu STACKIT durch agentenlose Orchestrierung, Replikation und plattformübergreifende Mobilität.

Cloudbase Coriolis

Migration

Software

Coriolis STACKIT Installer

STACKIT

Migration design-and-mobilize design relocate live-migration +2

Der Coriolis STACKIT Installer stellt eine Cloudbase Coriolis Appliance aus einem OVA mit Image-Normalisierung, Netzwerk, DNS und TLS reproduzierbar bereit.

Coriolis STACKIT Installer

Migration

Software

Hystax Acura Live Migration

Hystax

Hystax Acura Live Migration automatisiert VM-Replikation, isolierte Tests, Migrationspläne und kontrollierte Cutovers aus heterogenen Quellen nach STACKIT.

Hystax Acura Live Migration

Migration

Software

Migration design-and-mobilize use-cases relocate vmware +4

Ausführung einer VMware-Relocate-Welle

STACKIT

Migration migrate optimize relocate vm +3

Führen Sie kontrollierte VMware-Relocate-Wellen nach STACKIT über vollständige Coriolis- oder Hystax-Acura-Pfade aus, mit Testmigration, Cutover, Validierung und Rollback.

Ausführung einer VMware-Relocate-Welle

Migration

Runbook

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

STACKIT

Migration design-and-mobilize design relocate vmware vm sizing block-storage

Dimensioniert verlagerte STACKIT VMs anhand repräsentativer Telemetrie neu, mit kontrollierten Machine-Type-Änderungen, Storage-Migration, Validierung und Rollback.

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

Migration

Runbook

Install

Manuelle Installationsschritte für nicht tool-gestützte Ausnahme-Workloads beschreiben.

Ziel-VM und Storage vorbereiten: Ziel-VM erstellen, erforderliche Disks anbinden und CPU-/Memory-Sizing anhand gemessener Werte aus der Quelle ausrichten.
Erforderliche Basis-Komponenten installieren: Hypervisor-Guest-Tools, OS-Pakete und Runtime-Voraussetzungen einrichten, damit der Workload stabil starten kann.
Workload-Artefakte übertragen: Disk-Images, Boot-Dateien und Service-Units/Skripte über einen kontrollierten Transfer-Pfad kopieren.
Boot- und Host-Baseline prüfen: Erfolgreichen Boot, Dateisystem-Mount-Integrität und Kernnetzwerk-Erreichbarkeit vor der Konfiguration verifizieren.
Runbook Blueprint
Cloud-Design-Patterns

Config

Manuelle Konfiguration und den Abgleich der Parameter im Ziel festlegen.

System- und Parameter der Anwendung angleichen: Hostname, DNS, Synchronisierung der Zeit und Umgebungswerte gemäß Workload-Anforderungen setzen.
Security- und Zugriffsmodell konfigurieren: Regeln für Zugriffe, Service-Credentials und administrative Grenzen für den Betrieb im Ziel anwenden.
Betriebs-Basis aktivieren: Monitoring-Agenten, Log-Forwarding, Backup-Jobs und Restore-Test-Hooks einrichten.
Konfigurationsparität prüfen: Wichtige Runtime-Parameter mit der Basis der Quelle vergleichen und akzeptierte Abweichungen dokumentieren.
Runbook Blueprint
Migrationsplan

Deploy

Manuelle Deployment-Reihenfolge und Handover-Checks definieren.

Cutover-Sequenz ausführen: Schreibzugriffe auf die Quelle stoppen, finalen Delta-Sync fahren und den Ziel-Workload in der freigegebenen Reihenfolge aktivieren.
Verhalten des Service validieren: Smoke- und Critical-Path-Tests inklusive Konnektivität zu abhängigen Systemen durchführen.
Stabilisieren und überwachen: Schlüsselmetriken, Fehlerraten und Betriebs-Alarme während des vereinbarten Hypercare-Fensters beobachten.
Ownership-Übergang abschließen: Support-Verantwortung, Eskalationswege und Rollback-Abschlusskriterien verbindlich bestätigen.
Migrationsplan
Runbook Blueprint

Validation handover

Festlegen, wie Relocate-Ergebnisse in das gemeinsame Validation-Gate einfliessen. Technische Evidenz, aktualisierte Risiko-Logs und operativen Abnahme-Status bündeln, damit die Wellen-Governance Entscheidungen ohne Rework treffen kann.

Abgesicherter VMware-zu-STACKIT-Transferpfad

OPS

Zielkapazität abbilden

Anleitung

STACKIT VM Ziel-Sizing und Block-Storage-Auswahl

STACKIT

Überführt gemessene VMware-Last in STACKIT Machine Type- und Block-Storage-Profile mit explizitem Headroom, Verfügbarkeit und Prüfgrenzen nach dem Cutover.

STACKIT Dokumentation docs.stackit.cloud STACKIT Server machine types Dokumentation öffnen STACKIT Dokumentation docs.stackit.cloud STACKIT Block Storage service plans Dokumentation öffnen STACKIT Dokumentation docs.stackit.cloud Manage a STACKIT Server Dokumentation öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Zweck

Nutzen Sie diesen Leitfaden, um das initiale STACKIT-Compute- und Storage-Profil für VMware-Workloads festzulegen, die als virtuelle Maschinen verlagert werden. Er überführt gemessene Last in ein explizites Ziel-Mapping, ohne bereitgestellte vCPU-, Memory- oder Datastore-Kapazität 1:1 zu übernehmen.

Das initiale Ziel-Sizing schützt Migration und Cutover. Es ist nicht die endgültige Optimierungsentscheidung. Prüfen Sie das Profil erneut, nachdem der Workload auf STACKIT repräsentative Telemetrie erzeugt hat.

Erforderliche Nachweise

Erfassen Sie Messwerte über einen Zeitraum, der Normalbetrieb, Peak-Fenster, Batch-Verarbeitung, Backup-Aktivität, Monatsende- oder saisonale Ereignisse sowie bekannte Störungen enthält.

CPU: Erfassen Sie verbrauchte CPU, Peak- und p95-Last, Ready- oder Contention-Zeit sowie die Dauer anhaltender Last. Nutzen Sie die Anzahl bereitgestellter vCPUs nicht als einzige Eingabe.
Memory: Erfassen Sie aktiven und verbrauchten Memory, Working-Set-Peaks, Ballooning, Swapping und Cache-Verhalten. Gehen Sie nicht davon aus, dass zugewiesener VMware-Memory dauerhaft erforderlich ist.
Storage-Kapazität: Erfassen Sie genutzte Kapazität, Wachstumsrate, Retention, Snapshot-, Backup- und temporären Workspace-Bedarf. Migrieren Sie verwaiste Snapshots oder ungenutzte Disks nicht ohne Prüfung.
Storage-Performance: Erfassen Sie Read- und Write-IOPS, Throughput, Latenz, Queue-Tiefe, Blockgröße und Peak-Dauer pro Disk. Wählen Sie eine Klasse nicht allein anhand von Kapazität oder durchschnittlichen IOPS.
Netzwerk: Erfassen Sie Ingress, Egress, Verbindungsanzahl, Burst-Profil, Latenz und Paketverlust-Sensitivität. Beziehen Sie Backup- und Replikationstraffic ein.
Verfügbarkeit: Erfassen Sie Recovery-Ziele, Anforderungen an Failure-Domains, Wartungstoleranz und Restart-Verhalten. Betrachten Sie eine größere VM nicht als Verfügbarkeitsdesign.

Dokumentieren Sie für jede Messung Quelle, Zeitraum, Perzentil, fehlende Samples, Wachstumsannahmen und Vertrauen. Wenden Sie einen benannten Sicherheitsaufschlag an, wenn Nachweise unvollständig sind, statt Unsicherheit in einem übergroßen Ziel zu verstecken.

STACKIT Machine Type auswählen

STACKIT Machine Types sind vordefinierte Hardware-Konfigurationen. Einzelne Kombinationen aus vCPU und RAM lassen sich außerhalb der angebotenen Varianten nicht frei zusammenstellen, daher ist die Auswahl ein zweidimensionaler Fit und keine direkte Umrechnung der VMware-Konfiguration.

Typnamen verstehen

Aus der STACKIT-DokuMaschinentypen - EU01 › Maschinentyp-BezeichnungenStand der Quelle 24.07.2026 · übernommen 05.10.2026

Beispiel einer Maschinentyp-Bezeichnung: c1a.8d

Der erste Teil des Namens, z. B. „c1a.8d”, bezeichnet die Variante eines Maschinentyps. Derzeit gibt es folgende Varianten:

Seitlich wischen, um die ganze Tabelle zu sehen

Variante	Beschreibung
t	Kleinere Instanzen mit geringerer CPU und weniger RAM
s	Prozessoroptimierte Instanzen mit einem CPU/RAM-Verhältnis von 1:1
c	Prozessoroptimierte Instanzen mit einem CPU/RAM-Verhältnis von 1:2
g	Allgemeine Instanzen mit einem CPU/RAM-Verhältnis von 1:4
m	Arbeitsspeicheroptimierte Instanzen mit einem CPU/RAM-Verhältnis von 1:8
b	Große, arbeitsspeicheroptimierte Instanzen mit CPU/RAM-Verhältnis 1:16 oder höher
n	Instanzen mit NVIDIA-GPUs

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Generation, Prozessorarchitektur, verfügbare Größen und exakte Memory-Werte variieren je Region und können sich im Zeitverlauf ändern. Ermitteln Sie den aktuellen Katalog in der Zielregion, bevor eine Welle freigegeben wird.

Auswahlmethode

Wandeln Sie CPU-Messwerte in erforderliche Ziel-Cores für die Design-Last um und addieren Sie dann expliziten Headroom für Peaks, Wachstum und Messvertrauen.
Wandeln Sie den beobachteten Memory-Working-Set in erforderlichen RAM um und addieren Sie Headroom für Guest-Overhead, Cache-Verhalten, Wachstum und Cutover-Unsicherheit.
Identifizieren Sie die Machine-Type-Familie, deren CPU-zu-Memory-Verhältnis bei Erfüllung beider Anforderungen die geringste Verschwendung erzeugt.
Wählen Sie den kleinsten aktuellen Typ dieser Familie, der CPU und RAM gleichzeitig erfüllt; dokumentieren Sie, welche Dimension die Größe bestimmt.
Entscheiden Sie explizit zwischen CPU-overprovisioned und d-Typen. Bevorzugen Sie einen nicht overprovisioned Typ, wenn anhaltende CPU-Last, Latenz-Sensitivität oder beobachtete Contention planbaren CPU-Zugriff erfordern.
Prüfen Sie Prozessorarchitektur, Betriebssystem-Support, Lizenzierung, Placement in Availability Zones, Quotas und Wartungsverhalten.
Testen Sie den gewählten Typ mit einem repräsentativen Pilot und halten Sie den nächstgrößeren und nächstkleineren gültigen Typ für Rollback- und spätere Rightsizing-Entscheidungen fest.

Leiten Sie äquivalente Performance nicht allein aus der vCPU-Anzahl ab. Prozessorgeneration, Overprovisioning, Guest-Treiber, Workload-Konkurrenz und Quell-Contention beeinflussen das beobachtete Ergebnis.

Block Storage auswählen

Behandeln Sie Storage-Kapazität, Performance und Verfügbarkeit als getrennte Entscheidungen.

Kapazität und Platzierung

Dimensionieren Sie jedes Root- und Daten-Volume anhand genutzter Daten, erwartetem Wachstum, File-System-Anforderungen, Snapshots, Backup-Verhalten und temporärem Migration-Workspace.
Trennen Sie Disks, wenn Workload-Konsistenz, Backup-Policy, Performance-Isolation oder künftiges Wachstum unabhängige Steuerung erfordern.
Wählen Sie Single AZ oder Metro entsprechend dem Failure-Domain-Design des Workloads. Metro-Volumes sind über Availability Zones gespiegelt; das ersetzt weder Backups noch Recovery-Design auf Anwendungsebene.

Performance-Klasse

Eine STACKIT Block Storage Performance-Klasse definiert die maximalen IOPS und den Throughput für das gesamte Volume. Die Klasse ist unabhängig von der Volume-Größe, und alle Consumer dieses Volumes, einschließlich VM- und Backup-Reads, teilen sich ihr Performance-Limit.

Ermitteln Sie erforderliche Read- und Write-IOPS, Throughput, Latenz, Blockgrößenverteilung und Konkurrenz für jedes Ziel-Volume.
Addieren Sie expliziten Headroom für Peaks, Backup, Recovery und Wachstum getrennt für IOPS und Throughput.
Wählen Sie die niedrigste aktuelle Performance-Klasse, die beide Grenzen erfüllt. Eine Klasse, die bei IOPS besteht, aber bei Throughput scheitert, oder umgekehrt, ist nicht ausreichend.
Validieren Sie die Auswahl während Replikation und isolierter Testmigration, wenn Copy-Traffic einen anderen Engpass als der normale Anwendungsbetrieb sichtbar machen kann.
Dokumentieren Sie beobachtete Latenz, I/O-Wait, Queue-Tiefe, IOPS und Throughput nach dem Cutover für die Optimize-Prüfung.

Aus der STACKIT-DokuService-Pläne › Derzeit verfügbare Servicepläne (Leistungs-Klassen)Stand der Quelle 20.01.2026 · übernommen 05.10.2026

Die folgende Tabelle listet die derzeit verfügbaren Leistungs-Klassen für die Region EU01 auf:

Seitlich wischen, um die ganze Tabelle zu sehen

Leistungs-Klasse	Name	Max. IOPS	Max. Durchsatz (MB/s)
Leistungs-Klasse 0	storage_premium_perf0	120	25
Leistungs-Klasse 1	storage_premium_perf1	500	50
Leistungs-Klasse 2	storage_premium_perf2	1000	100
Leistungs-Klasse 4	storage_premium_perf4	2000	150
Leistungs-Klasse 6	storage_premium_perf6	5000	200
Leistungs-Klasse 8	storage_premium_perf8	10000	250
Leistungs-Klasse 10	storage_premium_perf10	15000	300
Leistungs-Klasse 12	storage_premium_perf12	20000	350
Leistungs-Klasse 13	storage_premium_perf13	20000	700
Leistungs-Klasse 14	storage_premium_perf14	25000	400
Leistungs-Klasse 15	storage_premium_perf15	25000	800
Leistungs-Klasse 16	storage_premium_perf16	30000	450
Leistungs-Klasse 17	storage_premium_perf17	30000	900
Leistungs-Klasse 18	storage_premium_perf18	35000	500
Leistungs-Klasse 19	storage_premium_perf19	35000	1000
Leistungs-Klasse 20	storage_premium_perf20	40000	550
Leistungs-Klasse 21	storage_premium_perf21	40000	1100

IOPS – Input/Output Operations per second (Ein-/Ausgabebefehle pro Sekunde)

Durchsatz – Durchsatz in Megabyte pro Sekunde

Somit lassen sich die verwendeten Klassen anhand der Namensgebung im Detail unterscheiden. Beispiel: „Block Storage Premium – Leistungs-Klasse 2“ entspricht SSD-Festplatten mit max. 1000 IOPS und max. 100 Mbyte/s Durchsatz.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Die Tabelle zeigt den EU01-Katalog. Ermitteln Sie immer die aktuellen Werte für die Zielregion.

Ziel-Mapping-Nachweis

Erstellen Sie pro VM und Volume jeweils eine versionierte Mapping-Zeile.

Quell-VM und Workload: Stabile Inventar-ID und Applikationszuordnung.
Zielregion und Platzierung: Region, Availability-Zone- oder Metro-Anforderung und Quota-Ergebnis.
Machine Type: Exakter Typ, CPU- und RAM-Anforderung, bestimmende Dimension, Headroom und Overprovisioning-Entscheidung.
Root-Volume: Kapazität, Performance-Klasse, Boot-Annahmen und Recovery-Annahmen.
Daten-Volumes: Source-to-Target-Disk-Mapping, Kapazität, Performance-Klasse und Konsistenzgruppe.
Netzwerk: Zielnetzwerk, Adressen, Security Groups, DNS und erwartete Bandbreite.
Validierungsschwellen: CPU, Memory, Latenz, IOPS, Throughput, Anwendungs-SLO und Beobachtungsfenster.
Anpassungsoptionen: Freigegebener größerer und kleinerer Typ, Storage-Alternative, Änderungsmethode und Rollback-Bedingung.

Geben Sie das Mapping erst frei, wenn Zielprofil, erwartete Kosten, Quotas, Tool-Mapping und Akzeptanzschwellen vollständig bekannt sind. Übergeben Sie das exakte Mapping in die Coriolis- oder Acura-Testmigration, statt Zielressourcen erst während des Cutover auszuwählen.

Primäre Referenzen

BASE

Landing Zone

Errichten Sie das durch Governance abgesicherte Cloud-Fundament, bevor Migrationswellen davon abhängen. Trennen Sie gemeinsame Platform-Landing-Zone-Fähigkeiten von workload-spezifischen Application Landing Zones und leiten Sie beide aus Enterprise Controls und Discovery-Nachweisen ab.

In 5 Trails

Schichten aus Platform und Application Landing Zone

Überblick: Landing Zones

Eine Landing Zone ist die strukturierte Cloud-Grundlage, die festlegt, wie Ihre Organisation auf STACKIT von Anfang an betrieben wird. Sie verbindet Governance, Identität, Security, Netzwerkarchitektur, Kostensteuerung und Automatisierung zu einem belastbaren Rahmen.

Ohne diese Grundlage stocken Migrationswellen typischerweise durch fehlende Freigaben, inkonsistente Kontrollen und wiederkehrende Plattformentscheidungen.

Kernkomponenten

Die folgende Visualisierung zeigt die zentralen Komponenten für eine belastbare Plattform-Basis.

Warum Sie eine Landing Zone brauchen

Kontrolle und Risikoreduktion: Security- und Compliance-Kontrollen werden konsistent umgesetzt.
Skalierbare Delivery-Basis: Wiederverwendbare Muster beschleunigen mehrere Migrationswellen.
Klare Verantwortlichkeiten: Zuständigkeiten zwischen Plattform-, Security- und Applikationsteams sind klar.
Höhere Umsetzungsgeschwindigkeit: Grundlegende Kontrollen müssen nicht je Applikation neu entworfen werden.

Wann Sie starten sollten

Starten Sie den Landing-Zone-Stream so früh wie möglich parallel zum Discovery.

Zu spät: Produktive Migrationen werden blockiert, weil Pflichtkontrollen noch fehlen.
Zu früh ohne Discovery-Feedback: Relevante Applikationsrandbedingungen fehlen und führen zu Nacharbeit.

Bewährt hat sich ein zweigleisiges Vorgehen: Die Plattform-Basis früh etablieren und Application-Landing-Zone-Templates iterativ mit Discovery-Erkenntnissen verfeinern.

Zwei Ebenen: Platform und Application Landing Zone

Platform Landing Zone

Unternehmensweite Grundlage für Governance, Identität, Security, Netzwerk, Kostensteuerung und Automatisierung.

Zur Platform Landing Zone

Application Landing Zone

Workload-spezifische Umsetzungsprofile, abgeleitet aus Plattform-Basis und Discovery-Ergebnissen.

Zur Application Landing Zone

Typische Eingaben aus dem Unternehmen

Für ein belastbares Landing-Zone-Design werden typischerweise benötigt:

Organisations- und Ownership-Modell: Einheiten, Projektgrenzen und Verantwortungsmodell.
Compliance- und Policy-Anforderungen: Regulatorische Pflichten und interne Kontrollvorgaben.
Security-Anforderungen: IAM-Standards, Netzsegmentierung, Verschlüsselung und Logging.
Betriebs- und Supportvorgaben: Incident-Prozesse, Eskalationswege und Übergabemodell.
Erkenntnisse aus dem Applikationsportfolio: Discovery-Resultate zu Abhängigkeiten und Archetypen.

Vorgehensmodell

Unternehmensweite Leitplanken und Kontrollmodell definieren.
Platform Landing Zone als Code aufbauen und validieren.
Application-Landing-Zone-Templates aus Discovery und Migrationsdesign ableiten.
Mit Pilot-Workloads testen und über Migration-Factory-Runbooks skalieren.

STACKIT Beschleuniger und Assets

Um die Umsetzung zu beschleunigen, bietet STACKIT konkrete Best Practices und wiederverwendbare Vorlagen:

Asset-Titel

Framework

Asset-Typ

Blueprint

STACKIT Landing Zone Accelerator

STACKIT

Migration design-and-mobilize landing-zone opentofu terraform +1

Open Source In 2 Trails

STACKIT Basis-Asset zum Aufbau einer Platform Landing Zone mit wiederverwendbaren OpenTofu/Terraform-Modulen, Enterprise-Standards und zentralem Kubernetes.

STACKIT Landing Zone Accelerator

Migration

Blueprint

VM Application Landing Zone für Relocate

STACKIT

Migration design-and-mobilize landing-zone relocate vmware +4

Migration design-and-mobilize landing-zone managed-service opentofu +1

Technisches Blueprint zum Aufbau einer VM Application Landing Zone mit STACKIT Accelerator, manuellen Security Groups und Coriolis- oder Acura-Übergabe.

VM Application Landing Zone für Relocate

Migration

Blueprint

Service

Managed Landing Zone Service

STACKIT

Managed Asset Marketplace In 1 Trail

STACKIT Managed Service für Beratung, Einrichtung und Umsetzung von Landing Zones mit OpenTofu, Terragrunt und Boilerplate-Accelerators für Migration.

Managed Landing Zone Service

Migration

Service

Blueprint

meshStack Self-Service Landing Zone

meshcloud

Migration design-and-mobilize landing-zone dev-platform opentofu

Referenzarchitektur, die eine STACKIT Landing Zone um Self-Service mit Governance ergänzt: Applikationsteams bestellen Projekte und geroutete Netzwerke selbst.

meshStack Self-Service Landing Zone

Migration

Blueprint

Migration design-and-mobilize landing-zone network network-area +3

pfSense-Firewall-Connectivity-Pattern

STACKIT

Migration design-and-mobilize landing-zone caf managed-service +1

Leitfaden für den Einsatz der STACKIT pfSense Firewall als zentraler Kontrollpunkt in Hub-and-Spoke-Network-Area-Architekturen für sichere STACKIT-Migrationen.

pfSense-Firewall-Connectivity-Pattern

Migration

Software

Service

CAF Landing Zones Implementation (PRODYNA)

PRODYNA

Managed Asset Marketplace In 1 Trail

CAF Landing Zone Foundation Accelerator von PRODYNA: ein CAF-basierter Enterprise-IaC-Blueprint-Hackathon für sichere und skalierbare STACKIT Landing Zones.

CAF Landing Zones Implementation (PRODYNA)

Migration

Service

Überblick: Landing Zones

Eine Landing Zone ist die strukturierte Cloud-Grundlage, die festlegt, wie Ihre Organisation auf STACKIT von Anfang an betrieben wird. Sie verbindet Governance, Identität, Security, Netzwerkarchitektur, Kostensteuerung und Automatisierung zu einem belastbaren Rahmen.

Ohne diese Grundlage stocken Migrationswellen typischerweise durch fehlende Freigaben, inkonsistente Kontrollen und wiederkehrende Plattformentscheidungen.

Kernkomponenten

Die folgende Visualisierung zeigt die zentralen Komponenten für eine belastbare Plattform-Basis.

Warum Sie eine Landing Zone brauchen

Kontrolle und Risikoreduktion: Security- und Compliance-Kontrollen werden konsistent umgesetzt.
Skalierbare Delivery-Basis: Wiederverwendbare Muster beschleunigen mehrere Migrationswellen.
Klare Verantwortlichkeiten: Zuständigkeiten zwischen Plattform-, Security- und Applikationsteams sind klar.
Höhere Umsetzungsgeschwindigkeit: Grundlegende Kontrollen müssen nicht je Applikation neu entworfen werden.

Wann Sie starten sollten

Starten Sie den Landing-Zone-Stream so früh wie möglich parallel zum Discovery.

Zu spät: Produktive Migrationen werden blockiert, weil Pflichtkontrollen noch fehlen.
Zu früh ohne Discovery-Feedback: Relevante Applikationsrandbedingungen fehlen und führen zu Nacharbeit.

Bewährt hat sich ein zweigleisiges Vorgehen: Die Plattform-Basis früh etablieren und Application-Landing-Zone-Templates iterativ mit Discovery-Erkenntnissen verfeinern.

Zwei Ebenen: Platform und Application Landing Zone

Platform Landing Zone

Unternehmensweite Grundlage für Governance, Identität, Security, Netzwerk, Kostensteuerung und Automatisierung.

Zur Platform Landing Zone

Application Landing Zone

Workload-spezifische Umsetzungsprofile, abgeleitet aus Plattform-Basis und Discovery-Ergebnissen.

Zur Application Landing Zone

Typische Eingaben aus dem Unternehmen

Für ein belastbares Landing-Zone-Design werden typischerweise benötigt:

Organisations- und Ownership-Modell: Einheiten, Projektgrenzen und Verantwortungsmodell.
Compliance- und Policy-Anforderungen: Regulatorische Pflichten und interne Kontrollvorgaben.
Security-Anforderungen: IAM-Standards, Netzsegmentierung, Verschlüsselung und Logging.
Betriebs- und Supportvorgaben: Incident-Prozesse, Eskalationswege und Übergabemodell.
Erkenntnisse aus dem Applikationsportfolio: Discovery-Resultate zu Abhängigkeiten und Archetypen.

Vorgehensmodell

Unternehmensweite Leitplanken und Kontrollmodell definieren.
Platform Landing Zone als Code aufbauen und validieren.
Application-Landing-Zone-Templates aus Discovery und Migrationsdesign ableiten.
Mit Pilot-Workloads testen und über Migration-Factory-Runbooks skalieren.

STACKIT Beschleuniger und Assets

Um die Umsetzung zu beschleunigen, bietet STACKIT konkrete Best Practices und wiederverwendbare Vorlagen:

Asset-Titel

Framework

Asset-Typ

Blueprint

PRODYNA

Migration design-and-mobilize landing-zone caf managed-service +1

Managed Asset Marketplace In 1 Trail

CAF Landing Zone Foundation Accelerator von PRODYNA: ein CAF-basierter Enterprise-IaC-Blueprint-Hackathon für sichere und skalierbare STACKIT Landing Zones.

CAF Landing Zones Implementation (PRODYNA)

Migration

Service

Accelerator-Architektur

Architekturübersicht des STACKIT Landing Zone Accelerators vom Bootstrap über Plattformfunktionen bis zu Application Landing Zones und Workloads

GitHub Repository

Übersicht

Dieses Asset liefert eine wiederverwendbare Grundlage für die Umsetzung einer STACKIT Platform Landing Zone. Es ist für Enterprise-Umgebungen ausgelegt, die eine strukturierte Basis für Governance, Security, Netzwerk, Kostensteuerung und Automatisierung benötigen.

Repository:

GitHub Repository

Wie das Repository funktioniert

Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.

Das Root-Modul in src/main.tf orchestriert alle Plattform- und Landing-Zone-Bausteine.
Die Konfiguration erfolgt über flavor-spezifische Variablendateien in src/config/.
Deployment ist mit OpenTofu oder Terraform möglich (identische Modulstruktur).
Das erste Deployment nutzt einen temporären Bootstrap-Service-Account und wechselt danach auf Managed Backend und Managed Credentials.

Deployment-Flavors und ihr Umfang

Das Repository enthält acht Referenzkonfigurationen in src/config/. Wählen Sie die einfachste Topologie, die die erforderlichen Netzwerk-, Sicherheits-, Organisations-, Mandanten- und Regionsgrenzen erfüllt.

Standalone

Standalone-Topologie mit Management-Basis, Sandbox und öffentlicher Application Landing Zone

Nutzen Sie standalone.tfvars für die kleinste Basis: Governance, Management, eine Sandbox und eine öffentliche Application Landing Zone mit eigenem Netzwerk und direktem Internetzugang. Es wird weder eine gemeinsame Network Area noch ein Connectivity-Hub erstellt. Das Muster eignet sich, wenn Workloads keine private Ost-West-Kommunikation oder zentrales DNS benötigen.

Hub-and-Spoke

Hub-and-Spoke-Topologie mit gemeinsamer Network Area und separater öffentlicher Landing Zone

Nutzen Sie hub-and-spoke.tfvars, wenn Corporate Workloads gemeinsame private Connectivity benötigen. Ein zentrales Connectivity-Projekt stellt Network Area und DNS bereit, die Corporate Data Platform nutzt diese private Domäne und öffentliche Workloads behalten unabhängige Netzwerke mit direktem Internetzugang.

Hub-and-Spoke mit Firewall

Hub-and-Spoke-Topologie mit zentraler Inspektion durch eine OPNsense-Firewall

Nutzen Sie hub-and-spoke-firewall.tfvars, wenn Corporate Egress einen einheitlichen Inspektions- und Kontrollpunkt benötigt. Das Muster erweitert die gemeinsame Network Area um eine OPNsense-Firewall und führt die Default Routes der Corporate Landing Zones über die Appliance, während öffentliche Landing Zones direkt angebunden bleiben.

Trennung von Finance und Research

Finance- und Research-Topologie mit unabhängigen privaten Connectivity-Domänen

Nutzen Sie hub-and-spoke-finance-research.tfvars, wenn Business Units unabhängige Ownership und private Connectivity benötigen. Finance und Research erhalten innerhalb derselben STACKIT Organisation jeweils einen eigenen Adressplan, ein Connectivity-Projekt, eine Network Area und eine Workload Landing Zone.

Network Areas für regulierte und gemeinsame Workloads

Multi-Area-Topologie zur Trennung regulierter und gemeinsamer Workloads

Nutzen Sie hub-and-spoke-multi-area.tfvars, wenn regulierte und gemeinsame Workloads in getrennten privaten Connectivity-Domänen liegen müssen. Jede Domäne erhält eine eigene Network Area und DNS-Zone; zwischen ihnen besteht kein implizites Routing.

Unabhängige regionale Hubs

Multi-Region-Topologie mit unabhängigen Hubs in eu01 und eu02

Nutzen Sie hub-and-spoke-multi-region.tfvars für regionale Basen in eu01 und eu02. Jede Region erhält einen unabhängigen Hub, eine Network Area, eine Workload Landing Zone und optional einen Platform-Kubernetes-Cluster. Interregionale Connectivity wird bewusst nicht erstellt und muss explizit entworfen werden.

Isolation von Produktion und Nicht-Produktion

Produktions- und Nicht-Produktions-Topologie mit getrennten Network Areas und Firewalls

Nutzen Sie hub-and-spoke-prod-nonprod-firewall.tfvars, wenn Produktion von Nicht-Produktion isoliert werden muss. Jede Domäne erhält eine eigene Network Area und OPNsense-Firewall; Development und Test teilen die Nicht-Produktions-Domäne, bleiben aber getrennte Landing Zones.

Mandantenisolation

Mandantenisolation mit drei unabhängigen privaten Mandantendomänen

Nutzen Sie hub-and-spoke-tenant-isolation.tfvars für mehrere Mandanten innerhalb einer Organisation. Jeder Mandant erhält unabhängige Ownership, einen eigenen Adressplan, eine Network Area, ein Connectivity-Projekt und eine Workload Landing Zone ohne privates Routing zu den anderen Mandantendomänen.

Code & Registry github.com Architektur des Landing Zone Accelerators Prüfen Sie Implementierungsarchitektur, Deployment-Konfigurationen und Netzwerkverhalten im Quell-Repository. Repository öffnen

Modul-für-Modul-Beschreibung

1. Governance-Modul (`src/modules/governance`)

Zweck:

Erstellt die RM-Folder-Struktur (platform, landing_zones_corporate, landing_zones_public, sandboxes).
Vergibt Folder-Owner- und Auditor-Rollen.
Vergibt Organization-Owner- und Auditor-Rollen.
Erstellt Custom Roles auf Organisationsebene.

Landing-Zone-Zuordnung:

Platform Landing Zone: zentrale Governance-Basis.

2. Management-Modul (`src/modules/management`)

Zweck:

Erstellt ein zentrales Management-Projekt.
Provisioniert Secrets Manager und einen Default-Zugangsuser.
Provisioniert Object-Storage-Buckets (inklusive tfstate-Bucket).
Erstellt Object-Storage-Credentials und speichert sie im Secrets Manager.
Erstellt Automation-Service-Account plus rotierende Keys und speichert den Key im Secrets Manager.
Stellt optional Observability bereit und speichert die zugehörigen Zugangsdaten im Secrets Manager.
Konfiguriert optional Federated Identity Provider für den Automation-Service-Account.

Landing-Zone-Zuordnung:

Platform Landing Zone: gemeinsamer Operations- und Automatisierungs-Kontrollpfad.

3. Connectivity-Modul (`src/modules/connectivity`)

Zweck:

Erstellt ein dediziertes Connectivity-Projekt.
Erstellt Network Area und regionale Network-Area-Konfiguration.
Erstellt DNS-Zonen für gemeinsame Namensräume.
Stellt optional Firewall-Image, Volume, Server, Interfaces und Public IP bereit.
Liefert die Firewall-Next-Hop-IP für Routen in Corporate Landing Zones.

Landing-Zone-Zuordnung:

Platform Landing Zone: gemeinsame Netzwerk- und Routing-Basis.

4. DevOps-Modul (`src/modules/devops`)

Zweck:

Erstellt ein dediziertes DevOps-Projekt.
Erstellt optional eine zentrale STACKIT Git-Instanz mit ACL-Ranges.

Landing-Zone-Zuordnung:

Platform Landing Zone in der Architektur dieses Accelerators.
Begründung: Das Modul liefert zentrale Delivery-Tooling-Grundlagen und Source-Control-Kapazität für mehrere Landing Zones.

5. Landing-Zone-Modul (`src/modules/landing-zone`)

Zweck:

Erstellt anwendungsnahe Landing-Zone-Projekte iterativ über for_each.
Unterstützt corporate Landing Zones (an Network Area angebunden) und public Landing Zones.
Erstellt geroutete Netzwerke und optional Default-Route über Firewall-Next-Hop.
Erstellt optional projektbezogene Child-DNS-Zonen.
Erstellt projektbezogene Custom Roles und Role Assignments.
Erstellt Secrets Manager, Object-Storage-Buckets und Automation-Service-Account-Key-Material pro Landing Zone.

Landing-Zone-Zuordnung:

Application Landing Zone: zentrales ALZ-Umsetzungsmodul.

6. Sandboxes-Modul (`src/modules/sandboxes`)

Zweck:

Erstellt schlanke Sandbox-Projekte im dedizierten sandboxes-Folder.
Vergibt Project-Owner.

Landing-Zone-Zuordnung:

Application Landing Zone (unterstützend): nicht-produktive Testumgebung nahe ALZ-Nutzungsmustern.

Neu umgesetzter Umfang in diesem Asset

Die aktuelle Umsetzung enthält jetzt einen durchgängigen Pfad für eine zentrale Kubernetes-Plattform und ein namespace-basiertes Application-Onboarding.

Platform Landing Zone für zentrales Kubernetes

Der Platform-Umfang enthält jetzt eine dedizierte zentrale Kubernetes-Basis, die als geteilter Platform-Service betrieben werden kann.

Zentrale Cluster-Basis: Ein dediziertes Platform-Kubernetes-Projekt mit SKE-Cluster-Life-cycle, DNS-Extension-Integration und optionaler Observability-Anbindung.
Secret-Policy-Readiness: Namespace-bezogenes Secret-Manager-Policy-Enforcement unterstützt schrittweise Rollout-Modi wie audit und strict.
Shared-Service-Modell: Plattform-Teams können zentrale Fähigkeiten bereitstellen und gleichzeitig klare Projekt- und Namespace-Grenzen beibehalten.
Betriebs-Basis: Cluster-bezogene Outputs und Informationen zum Zugriff stehen für Automatisierung und kontrollierte Plattform-Operationen bereit.

Application Landing Zone für Namespace-Tenants

Application Landing Zones können jetzt den Namespace-Service aus dem zentralen Platform-Kubernetes-Cluster nutzen.

Namespace-Onboarding: Die Landing-Zone-Konfiguration kann die Namespace-Erstellung für ein Team im Shared Cluster anfordern.
Developer-Zugriffspfad: Namespace-spezifische Kubernetes-User und Role-Bindings werden für Tenant-Operationen bereitgestellt.
Service-Exposition: DNS- und Ingress-Muster sind für Service-Endpunkte auf Basis von Landing-Zone- und Namespace-Kontext vorkonfiguriert.
Secret-Integration: Workloads können zentral gesteuerte Secret-Flows konsumieren und bleiben dabei im Namespace-Umfang.

Zusätzliche Plattform-Features in diesem Setup

External-DNS-Automatisierung: DNS-Einträge für Namespace-Services werden über Kubernetes-Annotationen und Extension-Zone-Integration verwaltet.
Zentrales Kubernetes-Monitoring: Die Plattform-Observability-Integration umfasst Grafana-Zugang und Metrics-Push-Wiring für Cluster-Telemetrie.
Dashboard-Provisioning-Workflow: Beispiel-Dashboards werden für eine schnellere operative Übergabe provisioniert und importiert.
Option für Encrypted Volumes: Unterstützung für verschlüsselte Volume-Muster hilft bei strengeren Datenschutz- und Compliance-Anforderungen.
Flexibles Netzwerk-Setup: Das Platform-Kubernetes-Modul unterstützt SNA-orientierte Netzwerk-Setups für kontrollierte Enterprise-Konnektivität.

Was Entwickler in einer Application Landing Zone bekommen

Sofort nutzbarer Namespace: Ein vorkonfigurierter Namespace im zentralen Cluster statt eines vollständigen Cluster-pro-Team-Modells.
Least-Privilege-Zugriff: Namespace-bezogene Identitäten und Berechtigungen passend zu typischen Day-2-Developer-Aufgaben.
Konsistentes Endpunkt-Modell: Vorhersehbare DNS- und Ingress-Muster für die Service-Veröffentlichung.
Governed Secret Usage: Zentrale Secret-Governance mit Namespace-bezogenen Mustern zur Nutzung.
Observability-Transparenz: Gemeinsame Metrik- und Dashboard-Sichten helfen Teams bei Rollout und Validierung im Betrieb.

Platform vs Application Landing Zone Umfang in diesem Repository

Platform Landing Zone Fokus (derzeit der größere Umfang):
- governance
- management
- connectivity
- devops
Application Landing Zone Umfang (derzeit fokussierter):
- landing-zone (ALZ-Kernprovisionierung)
- sandboxes (unterstützende ALZ-nahe Umgebungen)

Damit liefert das Repository aktuell primär eine starke Plattform-Basis, während ALZ-Funktionalität bewusst auf Landing-Zone-Instanziierung und Sandbox-Enabling fokussiert ist.

Einsatz im Migrationsprogramm

Plattform-Basis früh starten (Governance, Management, Connectivity, optional DevOps).
Corporate- vs Public-ALZ-Muster anhand von Connectivity- und Compliance-Anforderungen definieren.
Application Landing Zones über die landing_zones-Map in Variablendateien bereitstellen.
Sandboxes für Team-Onboarding und kontrollierte frühe Experimente nutzen.
Nach erstem Apply State in das Managed Backend migrieren und von Bootstrap-Credentials auf Managed Automation-Credentials wechseln.

Inhalt des Assets

Wiederverwendbare Basismodule: Bausteine für Account-/Projektstruktur, IAM, Netzwerk und Kontrollen.
Policy-orientiertes Setup: Leitplanken und Konventionen für sichere und steuerbare Cloud-Nutzung.
IaC-First-Ansatz: OpenTofu/Terraform als Modell für wiederholbare Bereitstellung.
Erweiterbar für Enterprise-Bedarf: Bewusst als Basis für kundenspezifische Anpassungen ausgelegt.

Typischer Einsatz im Migrationsprogramm

Früher Plattform-Stream: Aufbau parallel zum Discovery starten.
Kontrollbasis vor produktiver Migration: Pflichtkontrollen vor dem ersten produktiven Move etablieren.
Template-Quelle für Application Landing Zones: Basismodule für Workload-Archetypen wiederverwenden und verfeinern.

Empfohlene Voraussetzungen

Organisations- und Ownership-Modell für Projekte und Umgebungen.
Security- und Compliance-Vorgaben (Identität, Logging, Nachweise, Segmentierung).
Konnektivitäts- und Integrationsanforderungen.
Betriebsmodell-Abstimmung zwischen Plattform-, Security- und Applikationsteams.

STACKIT-Landing-Zone-Accelerator-Architektur vom Bootstrap über Platform-Fähigkeiten bis zu Application Landing Zones

Zweck

Nutzen Sie dieses Blueprint, um die Application Landing Zone für eine VM-basierte Relocate-Welle aufzubauen. Es trennt die gemeinsame Platform Landing Zone, die Workload-Projekt-Baseline und den migrierten Workload klar voneinander und stellt Coriolis oder Hystax Acura ein kontrolliertes Ziel für das Deployment bereit.

Landing-Zone- und Workload-Grenze

Die Platform Landing Zone stellt organisationsweite Governance-, Connectivity-, Identity-, Audit- und Automatisierungsfähigkeiten bereit. Der STACKIT Landing Zone Accelerator erstellt danach ein Application-Landing-Zone-Projekt pro Workload und Umgebung. Security Groups bilden ein explizites manuelles Freigabegate, bevor Migrationstooling oder VMs in dieses Projekt gelangen.

Diese Grenze ist bewusst gesetzt:

Landing-Zone-Verantwortung: Projekt, Rollen, geroutetes Netzwerk, DNS-Zone, Secrets Manager, Object Storage, Automatisierungsidentität, optionale Observability-Instanz, Labels und Shared Routing.
Manuelle Security-Verantwortung: Security Groups und deren workloadspezifische Ingress- und Egress-Regeln werden vor Tool-Deployment geprüft und erstellt.
Workload-Verantwortung: Migration-Appliances, migrierte Server und Volumes, Guest-Konfiguration, Anwendungsabhängigkeiten, Backup-Policies und Telemetrie-Agenten.

Was der Accelerator bereitstellt

Erstellen Sie pro Workload-Umgebung genau einen Accelerator-landing_zones-Eintrag. Für ein privates VMware-Ziel nutzen Sie eine Corporate Landing Zone, die mit der freigegebenen Network Area verbunden ist, und aktivieren Sie Observability.

landing_zones = {
  "erp-prod" = {
    project_name          = "ERP Production"
    project_code          = "erp"
    owner_email           = "platform-owner@example.com"
    env                   = "prod"
    corporate             = true
    network_area_key      = "default"
    network_prefix_length = 24
    secretsmanager_enabled = true

    observability = {
      enabled   = true
      plan_name = "Observability-Starter-EU01"
      acl       = ["approved-admin-cidr"]
    }

    role_assignments = [
      {
        role    = "project.owner"
        subject = "migration-automation@example.com"
      }
    ]
  }
}

Nach tofu apply erfassen Sie Projekt-ID, Landing-Zone-Typ, verbundene Network-Area-ID, DNS-Zone, Secrets-Manager-Instanz-ID, Observability-Instanz-ID, Grafana-URL und Metrics-Push-URL. Diese Outputs werden zu kontrollierten Eingaben für die Migrationswelle, nicht zu Werten, die erst im Cutover entschieden werden.

Der Accelerator erstellt in diesem Modul keine migrierten VMs, Workload-Disks, Guest-Agents oder Security Groups. Er erstellt die mit Governance-Leitplanken versehene Projekt-Baseline, in die diese Ressourcen ausgerollt werden.

Manuelles Security-Group-Gate

Erstellen Sie Security Groups erst, nachdem Abhängigkeitsmatrix und Tool-Pfad freigegeben sind. Halten Sie den Regelsatz auch dann versionskontrolliert, wenn die initiale Erstellung manuell erfolgt.

Erstellen Sie getrennte Gruppen für Management des Migrationstools, Transfer-Traffic, Workload-Ingress und Workload-East-West-Abhängigkeiten, wenn ihre Lebenszyklen sich unterscheiden.
Erlauben Sie Administration nur aus freigegebenen Operator- oder Bastion-Bereichen.
Erlauben Sie Coriolis- oder Acura-Control- und Data-Pfade nur zwischen dokumentierten Quell-, Appliance-, Worker- und Zieladressen. Ermitteln Sie exakte Ports anhand der freigegebenen Produktversion.
Überführen Sie die Discovery-Abhängigkeitsmatrix in explizite Workload-Regeln; übernehmen Sie keinen breiten VMware-VLAN-Zugriff per Kopie.
Begrenzen Sie ausgehenden Traffic auf erforderliche Platform-Services, Repositories, DNS, Zeit, Telemetrie, Backup und Anwendungsabhängigkeiten.
Dokumentieren Sie Eigentümer, Zweck, Nachweis, Ablaufdatum und Rollback für jede temporäre Migrationsregel.
Testen Sie Default-Deny-Verhalten und entfernen Sie temporäre Transfer-Regeln nach Ende der Quell-Retention.

Das Gate ist erst bestanden, wenn Platform Security und Application Owner die Regeln freigeben und sowohl Migrationstool-Connectivity als auch Workload-Abhängigkeitstests erfolgreich sind.

Aufbau der VM Application Landing Zone

Bestätigen Sie die Voraussetzungen der Platform Landing Zone: Governance-Folder, IAM-Modell, Network Area, gemeinsame DNS, Routing- und Firewall-Policy, Audit-Pfad und Ownership der Automatisierung.
Leiten Sie aus Discovery eine VM-Application-Landing-Zone-Spezifikation ab: Umgebung, Project Owner, Abhängigkeitsgrenzen, Adressbedarf, DNS-Namen, Datenklassifizierung, Verfügbarkeit, Recovery-Ziele und Telemetrieanforderungen.
Fügen Sie die Workload-Umgebung der Accelerator-landing_zones-Map hinzu und aktivieren Sie Corporate Networking, Secrets Manager und Observability nach Bedarf.
Wenden Sie den Accelerator an und verifizieren Sie Projekt, Role Assignments, geroutetes Netzwerk, Route Policy, DNS-Zone, Secrets-Grenze, State Storage, Automatisierungsidentität und Observability-Outputs.
Erstellen und genehmigen Sie die Security Groups manuell aus der Abhängigkeitsmatrix und den gewählten Control- und Transfer-Pfaden des Migrationstools.
Übergeben Sie die freigegebene Projekt-ID, Netzwerk, DNS, Secrets Manager, Observability-Endpunkte, Security Groups, Quotas und Ziel-Mappings an das Coriolis- oder Acura-Runbook.
Lassen Sie das gewählte Tool nur seine erforderlichen Appliance-, Worker-, Server-, Volume-, Image- und Migrationsinhalte in die Application Landing Zone deployen.
Verbinden Sie VM-Guest-Metriken und Logs mit dem bereitgestellten Observability-Endpunkt, wenden Sie Backup- und Recovery-Policies an und validieren Sie alle Kontrollen in einer isolierten Testmigration.

Übergeben Sie das Projekt nicht an ein Migrationstool, bevor die Schritte 1 bis 5 bestanden sind. Das Tool nutzt die Landing Zone; es definiert oder ersetzt sie nicht.

Übergabevertrag für das Migrationstool

Stellen Sie beiden Tools denselben freigegebenen Landing-Zone-Vertrag bereit und halten Sie ihre Implementierungen getrennt.

Gemeinsame Inputs: STACKIT-Projekt und Region, Zielnetzwerk und Adressen, Security Groups, DNS, Machine- und Volume-Mappings, Secrets-Manager-Nutzung, Observability-Endpunkte, Quotas und Rollback-Grenzen.
Coriolis-Inhalte: Coriolis-Appliance-Komponenten, STACKIT-Endpunkt, Minion-Pools, Transfers, Deployments und die daraus entstehenden VM- und Volume-Ressourcen.
Hystax-Acura-Inhalte: Acura-Control-Komponenten, Replikationsintegration, Cloud-Site-Einstellungen, Orchestrierungspläne, Ziel-Snapshots oder Volumes und die daraus entstehenden VM-Ressourcen.
Gemeinsamer Abschlussnachweis: Security-Rule-Test, Abhängigkeitstest, Guest-Telemetrie, Backup- und Restore-Nachweis, Anwendungsabnahme und Entfernungsplan für temporären Migrationszugriff.

Definition der Einsatzbereitschaft

Die VM Application Landing Zone ist für eine Produktionswelle bereit, wenn:

der Accelerator-Apply reproduzierbar ist und seine Outputs mit den Wellennachweisen abgelegt sind;
Projektverantwortung, Automatisierungsidentität, Quotas, Benennung und Labels freigegeben sind;
Netzwerkanbindung, Routing, DNS und hybride Erreichbarkeit getestet sind;
Secrets-Manager- und Observability-Zugriffe eingeschränkt und funktionsfähig sind;
Security Groups manuell erstellt, geprüft, getestet und mit der Abhängigkeitsmatrix verknüpft sind;
das gewählte Tool nur die erforderlichen Endpunkte und Zielressourcen erreichen kann;
Backup, Recovery, Guest-Telemetrie, Akzeptanzschwellen und Rollback definiert sind.

Primärquelle

Code & Registry github.com STACKIT Landing Zone Accelerator Repository öffnen

Zweck

Nutzen Sie dieses Blueprint, um die Application Landing Zone für eine VM-basierte Relocate-Welle aufzubauen. Es trennt die gemeinsame Platform Landing Zone, die Workload-Projekt-Baseline und den migrierten Workload klar voneinander und stellt Coriolis oder Hystax Acura ein kontrolliertes Ziel für das Deployment bereit.

Landing-Zone- und Workload-Grenze

Die Platform Landing Zone stellt organisationsweite Governance-, Connectivity-, Identity-, Audit- und Automatisierungsfähigkeiten bereit. Der STACKIT Landing Zone Accelerator erstellt danach ein Application-Landing-Zone-Projekt pro Workload und Umgebung. Security Groups bilden ein explizites manuelles Freigabegate, bevor Migrationstooling oder VMs in dieses Projekt gelangen.

Diese Grenze ist bewusst gesetzt:

Landing-Zone-Verantwortung: Projekt, Rollen, geroutetes Netzwerk, DNS-Zone, Secrets Manager, Object Storage, Automatisierungsidentität, optionale Observability-Instanz, Labels und Shared Routing.
Manuelle Security-Verantwortung: Security Groups und deren workloadspezifische Ingress- und Egress-Regeln werden vor Tool-Deployment geprüft und erstellt.
Workload-Verantwortung: Migration-Appliances, migrierte Server und Volumes, Guest-Konfiguration, Anwendungsabhängigkeiten, Backup-Policies und Telemetrie-Agenten.

Was der Accelerator bereitstellt

Erstellen Sie pro Workload-Umgebung genau einen Accelerator-landing_zones-Eintrag. Für ein privates VMware-Ziel nutzen Sie eine Corporate Landing Zone, die mit der freigegebenen Network Area verbunden ist, und aktivieren Sie Observability.

landing_zones = {
  "erp-prod" = {
    project_name          = "ERP Production"
    project_code          = "erp"
    owner_email           = "platform-owner@example.com"
    env                   = "prod"
    corporate             = true
    network_area_key      = "default"
    network_prefix_length = 24
    secretsmanager_enabled = true

    observability = {
      enabled   = true
      plan_name = "Observability-Starter-EU01"
      acl       = ["approved-admin-cidr"]
    }

    role_assignments = [
      {
        role    = "project.owner"
        subject = "migration-automation@example.com"
      }
    ]
  }
}

Nach tofu apply erfassen Sie Projekt-ID, Landing-Zone-Typ, verbundene Network-Area-ID, DNS-Zone, Secrets-Manager-Instanz-ID, Observability-Instanz-ID, Grafana-URL und Metrics-Push-URL. Diese Outputs werden zu kontrollierten Eingaben für die Migrationswelle, nicht zu Werten, die erst im Cutover entschieden werden.

Der Accelerator erstellt in diesem Modul keine migrierten VMs, Workload-Disks, Guest-Agents oder Security Groups. Er erstellt die mit Governance-Leitplanken versehene Projekt-Baseline, in die diese Ressourcen ausgerollt werden.

Manuelles Security-Group-Gate

Erstellen Sie Security Groups erst, nachdem Abhängigkeitsmatrix und Tool-Pfad freigegeben sind. Halten Sie den Regelsatz auch dann versionskontrolliert, wenn die initiale Erstellung manuell erfolgt.

Erstellen Sie getrennte Gruppen für Management des Migrationstools, Transfer-Traffic, Workload-Ingress und Workload-East-West-Abhängigkeiten, wenn ihre Lebenszyklen sich unterscheiden.
Erlauben Sie Administration nur aus freigegebenen Operator- oder Bastion-Bereichen.
Erlauben Sie Coriolis- oder Acura-Control- und Data-Pfade nur zwischen dokumentierten Quell-, Appliance-, Worker- und Zieladressen. Ermitteln Sie exakte Ports anhand der freigegebenen Produktversion.
Überführen Sie die Discovery-Abhängigkeitsmatrix in explizite Workload-Regeln; übernehmen Sie keinen breiten VMware-VLAN-Zugriff per Kopie.
Begrenzen Sie ausgehenden Traffic auf erforderliche Platform-Services, Repositories, DNS, Zeit, Telemetrie, Backup und Anwendungsabhängigkeiten.
Dokumentieren Sie Eigentümer, Zweck, Nachweis, Ablaufdatum und Rollback für jede temporäre Migrationsregel.
Testen Sie Default-Deny-Verhalten und entfernen Sie temporäre Transfer-Regeln nach Ende der Quell-Retention.

Das Gate ist erst bestanden, wenn Platform Security und Application Owner die Regeln freigeben und sowohl Migrationstool-Connectivity als auch Workload-Abhängigkeitstests erfolgreich sind.

Aufbau der VM Application Landing Zone

Bestätigen Sie die Voraussetzungen der Platform Landing Zone: Governance-Folder, IAM-Modell, Network Area, gemeinsame DNS, Routing- und Firewall-Policy, Audit-Pfad und Ownership der Automatisierung.
Leiten Sie aus Discovery eine VM-Application-Landing-Zone-Spezifikation ab: Umgebung, Project Owner, Abhängigkeitsgrenzen, Adressbedarf, DNS-Namen, Datenklassifizierung, Verfügbarkeit, Recovery-Ziele und Telemetrieanforderungen.
Fügen Sie die Workload-Umgebung der Accelerator-landing_zones-Map hinzu und aktivieren Sie Corporate Networking, Secrets Manager und Observability nach Bedarf.
Wenden Sie den Accelerator an und verifizieren Sie Projekt, Role Assignments, geroutetes Netzwerk, Route Policy, DNS-Zone, Secrets-Grenze, State Storage, Automatisierungsidentität und Observability-Outputs.
Erstellen und genehmigen Sie die Security Groups manuell aus der Abhängigkeitsmatrix und den gewählten Control- und Transfer-Pfaden des Migrationstools.
Übergeben Sie die freigegebene Projekt-ID, Netzwerk, DNS, Secrets Manager, Observability-Endpunkte, Security Groups, Quotas und Ziel-Mappings an das Coriolis- oder Acura-Runbook.
Lassen Sie das gewählte Tool nur seine erforderlichen Appliance-, Worker-, Server-, Volume-, Image- und Migrationsinhalte in die Application Landing Zone deployen.
Verbinden Sie VM-Guest-Metriken und Logs mit dem bereitgestellten Observability-Endpunkt, wenden Sie Backup- und Recovery-Policies an und validieren Sie alle Kontrollen in einer isolierten Testmigration.

Übergeben Sie das Projekt nicht an ein Migrationstool, bevor die Schritte 1 bis 5 bestanden sind. Das Tool nutzt die Landing Zone; es definiert oder ersetzt sie nicht.

Übergabevertrag für das Migrationstool

Stellen Sie beiden Tools denselben freigegebenen Landing-Zone-Vertrag bereit und halten Sie ihre Implementierungen getrennt.

Gemeinsame Inputs: STACKIT-Projekt und Region, Zielnetzwerk und Adressen, Security Groups, DNS, Machine- und Volume-Mappings, Secrets-Manager-Nutzung, Observability-Endpunkte, Quotas und Rollback-Grenzen.
Coriolis-Inhalte: Coriolis-Appliance-Komponenten, STACKIT-Endpunkt, Minion-Pools, Transfers, Deployments und die daraus entstehenden VM- und Volume-Ressourcen.
Hystax-Acura-Inhalte: Acura-Control-Komponenten, Replikationsintegration, Cloud-Site-Einstellungen, Orchestrierungspläne, Ziel-Snapshots oder Volumes und die daraus entstehenden VM-Ressourcen.
Gemeinsamer Abschlussnachweis: Security-Rule-Test, Abhängigkeitstest, Guest-Telemetrie, Backup- und Restore-Nachweis, Anwendungsabnahme und Entfernungsplan für temporären Migrationszugriff.

Definition der Einsatzbereitschaft

Die VM Application Landing Zone ist für eine Produktionswelle bereit, wenn:

der Accelerator-Apply reproduzierbar ist und seine Outputs mit den Wellennachweisen abgelegt sind;
Projektverantwortung, Automatisierungsidentität, Quotas, Benennung und Labels freigegeben sind;
Netzwerkanbindung, Routing, DNS und hybride Erreichbarkeit getestet sind;
Secrets-Manager- und Observability-Zugriffe eingeschränkt und funktionsfähig sind;
Security Groups manuell erstellt, geprüft, getestet und mit der Abhängigkeitsmatrix verknüpft sind;
das gewählte Tool nur die erforderlichen Endpunkte und Zielressourcen erreichen kann;
Backup, Recovery, Guest-Telemetrie, Akzeptanzschwellen und Rollback definiert sind.

Primärquelle

Code & Registry github.com STACKIT Landing Zone Accelerator Repository öffnen

Zweck

Nutzen Sie dieses Blueprint, um die Application Landing Zone für eine VM-basierte Relocate-Welle aufzubauen. Es trennt die gemeinsame Platform Landing Zone, die Workload-Projekt-Baseline und den migrierten Workload klar voneinander und stellt Coriolis oder Hystax Acura ein kontrolliertes Ziel für das Deployment bereit.

Landing-Zone- und Workload-Grenze

Die Platform Landing Zone stellt organisationsweite Governance-, Connectivity-, Identity-, Audit- und Automatisierungsfähigkeiten bereit. Der STACKIT Landing Zone Accelerator erstellt danach ein Application-Landing-Zone-Projekt pro Workload und Umgebung. Security Groups bilden ein explizites manuelles Freigabegate, bevor Migrationstooling oder VMs in dieses Projekt gelangen.

Diese Grenze ist bewusst gesetzt:

Landing-Zone-Verantwortung: Projekt, Rollen, geroutetes Netzwerk, DNS-Zone, Secrets Manager, Object Storage, Automatisierungsidentität, optionale Observability-Instanz, Labels und Shared Routing.
Manuelle Security-Verantwortung: Security Groups und deren workloadspezifische Ingress- und Egress-Regeln werden vor Tool-Deployment geprüft und erstellt.
Workload-Verantwortung: Migration-Appliances, migrierte Server und Volumes, Guest-Konfiguration, Anwendungsabhängigkeiten, Backup-Policies und Telemetrie-Agenten.

Was der Accelerator bereitstellt

Erstellen Sie pro Workload-Umgebung genau einen Accelerator-landing_zones-Eintrag. Für ein privates VMware-Ziel nutzen Sie eine Corporate Landing Zone, die mit der freigegebenen Network Area verbunden ist, und aktivieren Sie Observability.

landing_zones = {
  "erp-prod" = {
    project_name          = "ERP Production"
    project_code          = "erp"
    owner_email           = "platform-owner@example.com"
    env                   = "prod"
    corporate             = true
    network_area_key      = "default"
    network_prefix_length = 24
    secretsmanager_enabled = true

    observability = {
      enabled   = true
      plan_name = "Observability-Starter-EU01"
      acl       = ["approved-admin-cidr"]
    }

    role_assignments = [
      {
        role    = "project.owner"
        subject = "migration-automation@example.com"
      }
    ]
  }
}

Nach tofu apply erfassen Sie Projekt-ID, Landing-Zone-Typ, verbundene Network-Area-ID, DNS-Zone, Secrets-Manager-Instanz-ID, Observability-Instanz-ID, Grafana-URL und Metrics-Push-URL. Diese Outputs werden zu kontrollierten Eingaben für die Migrationswelle, nicht zu Werten, die erst im Cutover entschieden werden.

Der Accelerator erstellt in diesem Modul keine migrierten VMs, Workload-Disks, Guest-Agents oder Security Groups. Er erstellt die mit Governance-Leitplanken versehene Projekt-Baseline, in die diese Ressourcen ausgerollt werden.

Manuelles Security-Group-Gate

Erstellen Sie Security Groups erst, nachdem Abhängigkeitsmatrix und Tool-Pfad freigegeben sind. Halten Sie den Regelsatz auch dann versionskontrolliert, wenn die initiale Erstellung manuell erfolgt.

Erstellen Sie getrennte Gruppen für Management des Migrationstools, Transfer-Traffic, Workload-Ingress und Workload-East-West-Abhängigkeiten, wenn ihre Lebenszyklen sich unterscheiden.
Erlauben Sie Administration nur aus freigegebenen Operator- oder Bastion-Bereichen.
Erlauben Sie Coriolis- oder Acura-Control- und Data-Pfade nur zwischen dokumentierten Quell-, Appliance-, Worker- und Zieladressen. Ermitteln Sie exakte Ports anhand der freigegebenen Produktversion.
Überführen Sie die Discovery-Abhängigkeitsmatrix in explizite Workload-Regeln; übernehmen Sie keinen breiten VMware-VLAN-Zugriff per Kopie.
Begrenzen Sie ausgehenden Traffic auf erforderliche Platform-Services, Repositories, DNS, Zeit, Telemetrie, Backup und Anwendungsabhängigkeiten.
Dokumentieren Sie Eigentümer, Zweck, Nachweis, Ablaufdatum und Rollback für jede temporäre Migrationsregel.
Testen Sie Default-Deny-Verhalten und entfernen Sie temporäre Transfer-Regeln nach Ende der Quell-Retention.

Das Gate ist erst bestanden, wenn Platform Security und Application Owner die Regeln freigeben und sowohl Migrationstool-Connectivity als auch Workload-Abhängigkeitstests erfolgreich sind.

Aufbau der VM Application Landing Zone

Bestätigen Sie die Voraussetzungen der Platform Landing Zone: Governance-Folder, IAM-Modell, Network Area, gemeinsame DNS, Routing- und Firewall-Policy, Audit-Pfad und Ownership der Automatisierung.
Leiten Sie aus Discovery eine VM-Application-Landing-Zone-Spezifikation ab: Umgebung, Project Owner, Abhängigkeitsgrenzen, Adressbedarf, DNS-Namen, Datenklassifizierung, Verfügbarkeit, Recovery-Ziele und Telemetrieanforderungen.
Fügen Sie die Workload-Umgebung der Accelerator-landing_zones-Map hinzu und aktivieren Sie Corporate Networking, Secrets Manager und Observability nach Bedarf.
Wenden Sie den Accelerator an und verifizieren Sie Projekt, Role Assignments, geroutetes Netzwerk, Route Policy, DNS-Zone, Secrets-Grenze, State Storage, Automatisierungsidentität und Observability-Outputs.
Erstellen und genehmigen Sie die Security Groups manuell aus der Abhängigkeitsmatrix und den gewählten Control- und Transfer-Pfaden des Migrationstools.
Übergeben Sie die freigegebene Projekt-ID, Netzwerk, DNS, Secrets Manager, Observability-Endpunkte, Security Groups, Quotas und Ziel-Mappings an das Coriolis- oder Acura-Runbook.
Lassen Sie das gewählte Tool nur seine erforderlichen Appliance-, Worker-, Server-, Volume-, Image- und Migrationsinhalte in die Application Landing Zone deployen.
Verbinden Sie VM-Guest-Metriken und Logs mit dem bereitgestellten Observability-Endpunkt, wenden Sie Backup- und Recovery-Policies an und validieren Sie alle Kontrollen in einer isolierten Testmigration.

Übergeben Sie das Projekt nicht an ein Migrationstool, bevor die Schritte 1 bis 5 bestanden sind. Das Tool nutzt die Landing Zone; es definiert oder ersetzt sie nicht.

Übergabevertrag für das Migrationstool

Stellen Sie beiden Tools denselben freigegebenen Landing-Zone-Vertrag bereit und halten Sie ihre Implementierungen getrennt.

Gemeinsame Inputs: STACKIT-Projekt und Region, Zielnetzwerk und Adressen, Security Groups, DNS, Machine- und Volume-Mappings, Secrets-Manager-Nutzung, Observability-Endpunkte, Quotas und Rollback-Grenzen.
Coriolis-Inhalte: Coriolis-Appliance-Komponenten, STACKIT-Endpunkt, Minion-Pools, Transfers, Deployments und die daraus entstehenden VM- und Volume-Ressourcen.
Hystax-Acura-Inhalte: Acura-Control-Komponenten, Replikationsintegration, Cloud-Site-Einstellungen, Orchestrierungspläne, Ziel-Snapshots oder Volumes und die daraus entstehenden VM-Ressourcen.
Gemeinsamer Abschlussnachweis: Security-Rule-Test, Abhängigkeitstest, Guest-Telemetrie, Backup- und Restore-Nachweis, Anwendungsabnahme und Entfernungsplan für temporären Migrationszugriff.

Definition der Einsatzbereitschaft

Die VM Application Landing Zone ist für eine Produktionswelle bereit, wenn:

der Accelerator-Apply reproduzierbar ist und seine Outputs mit den Wellennachweisen abgelegt sind;
Projektverantwortung, Automatisierungsidentität, Quotas, Benennung und Labels freigegeben sind;
Netzwerkanbindung, Routing, DNS und hybride Erreichbarkeit getestet sind;
Secrets-Manager- und Observability-Zugriffe eingeschränkt und funktionsfähig sind;
Security Groups manuell erstellt, geprüft, getestet und mit der Abhängigkeitsmatrix verknüpft sind;
das gewählte Tool nur die erforderlichen Endpunkte und Zielressourcen erreichen kann;
Backup, Recovery, Guest-Telemetrie, Akzeptanzschwellen und Rollback definiert sind.

Primärquelle

Code & Registry github.com STACKIT Landing Zone Accelerator Repository öffnen

OPS

Migrationsplan

Gruppieren Sie VMs nach verifizierten Abhängigkeiten und technischen Randbedingungen, beginnen Sie mit einem repräsentativen risikoarmen Piloten und definieren Sie geordnete Runbooks, Wartungsfenster, Cutover-Gates und Rollback-Grenzen.

In 2 Trails

Migrationsplan-Modell, das Portfolio-Nachweise, Wellen-Governance, Runbooks und kontrollierte Ausführung verbindet

Überblick: Dieses Modul

Der Migrationsplan ist der Übergang von Analyse zur konkreten Umsetzung. Er folgt auf Discovery und wird durch das Modul Design laufend mit umsetzbaren Details gefüllt.

Ziel ist es, die Erkenntnisse aus Discovery und Design in einen detaillierten, schrittweisen Migrationsplan zu überführen, den Delivery-Teams mit hoher Verlässlichkeit umsetzen können.

Damit bildet dieses Modul die Brücke zwischen Strategie und Ausführung und ist zentral für den Gesamterfolg der Migration.

Kernaktivitäten

Wellenbasierte Planung

Anwendungen in logische Migrationswellen gruppieren, basierend auf Abhängigkeiten, Geschäftskritikalität und technischer Komplexität.

Migrations-Runbooks

Detaillierte Schritt-für-Schritt-Runbooks je Welle oder Anwendung erstellen, inklusive Vorbereitung, Ausführung, Cutover, Rollback und Validierung.

Ressourcenplanung

Nötige Teams, Fähigkeiten, Werkzeuge und Experten je Welle festlegen, einschließlich Enablement- und Schulungsplanung.

Umsetzungs-Governance

Verbindliche Governance-Prozesse, Verantwortlichkeiten, Kommunikationsroutinen und Cutover-Kontrollen für die Wellenumsetzung etablieren.

Agilität als Grundprinzip

Migrationsplanung muss anpassungsfähig bleiben. Programme sollten frühe Wellen möglichst schnell starten und gleichzeitig Wellenschnitt und Reihenfolge kontinuierlich nachziehen, sobald neue Discovery- und Design-Ergebnisse vorliegen.

Runbooks sind lebende Dokumente. Nach jedem Cutover sollten Teams die Runbooks überarbeiten und verbessern. Mit steigender Runbook-Qualität steigt typischerweise auch die Migrationsgeschwindigkeit von Welle zu Welle.

Skalierung großer Migrationen in der Praxis

In großen Migrationsprogrammen liegt der Fokus auf skalierter Umsetzung. Typisch ist, mit kleinen Wellen zu starten (z. B. 5 Server/Woche) und den Durchsatz schrittweise zu steigern (z. B. auf 50-100 Server/Woche), abhängig von Restriktionen und Reifegrad.

Die ersten Wellen sind bewusst kleiner, damit Portfolio- und Migrations-Workstream ihre Prozesse stabilisieren, Annahmen validieren und Runbooks verbessern können. Dieser Lernzyklus ist ein zentraler Erfolgsfaktor in großen Migrationen.

Betriebsmodell der Migration Factory

In diesem Modul wird die Migration Factory typischerweise über vier Bausteine gesteuert:

Project Governance Rules

Prozesse und Werkzeuge zur Steuerung von Wellen, Kommunikation, Zeitplänen und Cutovers, damit Aufgaben in der richtigen Reihenfolge und zum richtigen Zeitpunkt ausgeführt werden.

Portfolio-Runbooks

Runbooks zur Priorisierung von Anwendungen, Planung von Wellen und Erhebung der nötigen Metadaten als Eingangsmaterial für die Umsetzung.

Migrations-Runbooks

Runbooks für die technische Umsetzung der Wellen, das Laden von Metadaten in Migrationswerkzeuge sowie Cutover und Validierung.

Best Practices und Health-Check-Matrix

Regelmäßiger Health-Check zur Fortschrittsbewertung, frühen Risikoerkennung und Stabilisierung der Auslieferung.

Datenfluss durch Portfolio- und Migrations-Workstream

Runbooks bilden den Datenfluss über zwei verbundene Workstreams:

Portfolio-Workstream: Priorisiert Anwendungen und bereitet Metadaten für kommende Wellen auf.
Migrations-Workstream: Führt Migrationen und Cutover gemäß freigegebenem Wellenplan aus.

Teams sind meist auf bestimmte Teile der Factory spezialisiert, während die Wellen durch beide Workstreams fließen. Um Engpässe zu vermeiden, sollten ausreichend vorbereitete Wellen vor der Ausführung bereitstehen. Ein bewährter Richtwert ist, den Portfolio-Workstream fünf Wellen vor dem Migrations-Workstream zu halten.

Klare Abgrenzung von Portfolio und Migration

Für Steuerung und Kapazitätsplanung ist die Unterscheidung zwischen Funktion und Team wichtig:

Portfolio: Fachliche und technische Vorbereitung einer Welle, inklusive Priorisierung, Abhängigkeitsklärung, Scope-Schnitt, Datenqualität und Readiness-Nachweis.
Portfolio Team: Rollen, die Portfolio-Arbeit ausführen und verantworten (z. B. Programmleitung, Domain-Owner, Architekt:innen, Application-Owner und Governance).
Migration: Operative Umsetzung der freigegebenen Welle mit Runbook-Ausführung, Change-/Cutover-Steuerung, Validierung, Stabilisierung und dokumentiertem Abschluss.
Migration Team: Rollen, die technische Migration durchführen und absichern (z. B. Factory-Engineers, Plattform-Team, Netzwerk/Security, Test und Betriebsübergabe).

Beide Teams sind eng gekoppelt, übernehmen aber unterschiedliche Lieferobjekte:

Portfolio Team liefert: Freigegebene Wellenzuschnitte, priorisierte Backlogs, vollständige Metadaten und umsetzungsfähige Eingangspakete.
Migration Team liefert: Erfolgreiche Cutovers, validierte Zielzustände, Lessons Learned und verbesserte Runbook-Versionen für Folgewellen.

Dynamisches Wellenmuster in der Umsetzung

Ein typisches Muster ist:

Portfolio-Taktung: Etwa 1-2 Wochen je Welle für Vorbereitung.
Migrations-Taktung: Etwa 3-4 Wochen je Welle für Umsetzung und Cutover.
Wellenpuffer: Ein Puffer von fünf Wellen zwischen Portfolio- und Migrations-Workstream.

Bevor die Migrationsumsetzung in den Regelbetrieb übergeht, wird typischerweise ein initialer Wellenpuffer aufgebaut. Ab dem Start der Ausführung laufen beide Workstreams parallel weiter, und der Puffer verhindert Lieferengpässe.

Phasen- und Modulmodell in der Wellenplanung

Die folgende Darstellung zeigt das operative Zielbild mit unserem Phasen- und Modulmodell: Der Planungsanteil liegt im Modul Migrationsplan (Design and Mobilize), die Ausführung läuft im Migrationsmodul in versetzten Wellen.

In diesem Modell sind die Phasengrenzen bewusst überlappend aufgebaut:

Design and Mobilize startet mit der Wellenplanung und bleibt bis zum Ende der Planung von Welle 8 aktiv (bis Woche 3).
Migrate startet bereits in Woche 3 und läuft über die verbleibende Zeitachse weiter.
Pilotwelle und Anpassungen: Welle 1 ist als kürzere Pilotwelle zur Erstvalidierung ausgelegt; danach folgen gezielte Factory-Setup-Anpassungen in den ersten produktiven Wellen.

Der detaillierte Setup-Umfang ist im eigenen Kapitel beschrieben: Migration Factory Setup.

Seitlich wischen, um das ganze Diagramm zu sehen

Das Muster bleibt bewusst dynamisch: Portfolio-Arbeit erzeugt einen stabilen Vorlauf, während Migration die Wellen mit Runbooks, Cutover und Validierung umsetzt.

Migration-Factory-Prozess im Modulfluss

Der Migrationsplan verbindet Discovery- und Design-Ergebnisse mit Umsetzungs-Governance, Wellenplanung und runbook-basierter Delivery. Der Prozess koppelt Portfolio- und Migrations-Workstream eng über Governance, Runbooks und kontinuierliche Verbesserung.

Wellenplanung als dynamische Zeitachse

Wellenplanung ist kein statischer Terminplan. Sie ist eine operative Zeitachse, die für Stakeholder transparent und für neue Erkenntnisse anpassbar bleiben muss. Maßgeblich sind dabei Taktung, Überlappung der Workstreams und eine klare Pufferlogik.

Iterative Planungslogik in der Praxis

Aktuelle Discovery- und Design-Ergebnisse sowie Restriktionen und Annahmen bestätigen.
Wellenzuschnitt, Reihenfolge und Staffing auf Basis des aktuellen Stands aktualisieren.
Aktuelle Welle mit freigegebenen Migrations- und Cutover-Runbooks ausführen.
Cutover-Ergebnisse, Störungen und Zeitabweichungen auswerten.
Governance-Kontrollen und Runbooks verbessern und in kommende Wellen übernehmen.
Health-Status und Wellenpuffer prüfen und in die nächste Iteration gehen.

Ergebnisse dieses Moduls

Der Migrationsplan sollte mindestens folgende Ergebnisse liefern:

Freigegebener Wellenplan: Sequenzierte Migrationswellen mit abhängigkeitsbewusster Gruppierung.
Ausführbare Runbooks: Versionierte Runbooks je Welle/Anwendung mit Validierung und Rollback.
Ressourcen- und Skill-Plan: Besetzungs- und Fähigkeitsplanung je Welle.
Governance-Taktung: Rahmen für Entscheidungen, Kommunikation und Cutover-Steuerung.
Backlog für kontinuierliche Verbesserung: Nachverfolgbare Verbesserungen aus jeder Welle.

Zweck

Verwenden Sie dieses Runbook, um eine freigegebene VMware-Relocate-Welle nach STACKIT auszuführen. Es enthält zwei vollständige Tool-Pfade: Cloudbase Coriolis und Hystax Acura. Wählen Sie für die gesamte Welle genau einen Pfad und behalten Sie dasselbe Tool, dieselben Inventar-Kennungen, Mappings und Nachweise durch Testmigration und finalen Cutover bei.

Das Runbook geht davon aus, dass Anwendungen VM-basiert bleiben. Architekturmodernisierung, Datenbank-Replatforming und Applikations-Refactoring erfordern separate Pläne und Abnahmekriterien.

Eingangskriterien

Starten Sie die Replikation erst, wenn alle Eingangskriterien erfüllt sind:

Der Wellenumfang und die Abhängigkeitsgruppen sind eingefroren und jede VM hat eine stabile Quellkennung.
Die VMware-Quellbereitschaft, tool-spezifische Voraussetzungen und Wiederherstellungspunkte sind verifiziert.
Ziel-Maschinentypen, Volumes, Performance-Klassen, Netzwerke, Adressen, Security Groups und Platzierung sind freigegeben und innerhalb der Quoten verfügbar.
Anwendungsseitige Konsistenz, Testfälle, Wartungsfenster, erwartete Downtime und maximale Cutover-Dauer sind dokumentiert.
Source Freeze, Traffic Switch, Monitoring-Aktivierung und Rollback-Aktionen haben benannte technische Owner.
Der Quellaufbewahrungszeitraum und die Befugnis zum Löschen der Quell-VMs sind vor dem Cutover definiert.

Cloud Framework VMware Relocate Source Readiness Seite öffnen Cloud Framework STACKIT VM Target Sizing and Storage Selection Seite öffnen

Wellen-Steuerungsprotokoll

Legen Sie ein versionskontrolliertes Steuerungsprotokoll für die Welle an. Es enthält:

Source- und Target-Mappings für VM, Disk, Netzwerk, Adresse und Security Group;
gewähltes Tool sowie Appliance- oder Service-Version;
Start der Erstkopie, letzte erfolgreiche Delta-Synchronisation und gemessenen Replikations-Lag;
geordnete Shutdown- und Startup-Prozeduren der Anwendung;
technische und funktionale Testfälle mit objektiven Pass-Kriterien;
Cutover-Zeitplan, Checkpoints, Hold Points und Entscheidungsbefugnis;
Rollback-Trigger, letzte sichere Entscheidungszeit, Methode zur Datenabstimmung und Quellaufbewahrung;
Links zu Logs, Screenshots, Checksummen, Testergebnissen und Freigaben.

Führen Sie das Verfahren zuerst mit einem risikoarmen Piloten aus, der die vorgesehenen Muster für Betriebssystem, Disk, Netzwerk und Anwendung repräsentiert. Überführen Sie das Runbook erst dann in größere Wellen, wenn Pilot-Erkenntnisse eingearbeitet wurden.

Coriolis-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Cloudbase Coriolis das freigegebene Migrationstool ist.

Coriolis auf STACKIT bereitstellen

Führen Sie den Coriolis STACKIT Installer Dry Run und den Cloud Check gegen das freigegebene Projekt, die Region, den Maschinentyp, die Storage-Performance-Klasse sowie die Netzwerk-, DNS- und TLS-Konfiguration aus.
Stellen Sie die lizenzierte Appliance bereit, speichern Sie ihr strukturiertes Ergebnis und erzeugte Zugangsdaten sicher und führen Sie den Installer erneut aus, um die Wiederverwendung der vorgesehenen Ressourcen zu bestätigen.
Verifizieren Sie Appliance-Backup, administrativen Zugriff, TLS, Zeitsynchronisation, Monitoring, Quoten sowie die Migrations-Datenpfade, die nicht von der HTTPS-Benutzeroberfläche abgedeckt sind.

Cloud Framework Cloudbase Coriolis Seite öffnen Cloud Framework Coriolis STACKIT Installer Stellt die Coriolis-Appliance auf STACKIT bereit und konfiguriert sie vor Endpoint- und Migrations-Setup. Seite öffnen

Endpoints und Minion-Pools konfigurieren

Erstellen Sie den VMware-Source-Endpoint und den STACKIT-Destination-Endpoint mit dedizierten Zugangsdaten. Testen Sie Authentifizierung, Zertifikatsvertrauen, Inventar-Erkennung und API-Zugriff unabhängig voneinander.
Konfigurieren Sie die Source- und Destination-Minion-Pools, die Coriolis-Operationen ausführen. Verifizieren Sie Worker-Zustand, Kapazität, Concurrency-Grenzen, Routing, Namensauflösung und Zugriff auf beide Endpoints.
Bestätigen Sie, dass ein Worker jeden benötigten Management- und Data-Transfer-Service erreichen kann. Browser-Zugriff auf die Coriolis-Appliance allein belegt keine Endpoint-zu-Endpoint- Transfer-Bereitschaft.
Dokumentieren Sie Endpoint- und Minion-Pool-Identitäten sowie Versionen im Wellen-Steuerungsprotokoll, damit Wiederholungen und Cutover dieselbe Ausführungstopologie verwenden.

Coriolis Transfer entwerfen und ausführen

Erstellen Sie pro freigegebener VM oder Konsistenzgruppe genau eine Migrations-Transfer-Definition. Wählen Sie die Quellinstanz und lösen Sie jede Source-Disk und jedes Netzwerk auf das freigegebene STACKIT-Zieldesign auf.
Bestätigen Sie Coriolis-Gastunterstützung und das OS-Morphing-Verhalten. Fügen Sie erforderliche Remediation für Bootloader, Storage-Treiber, Netzwerk oder Cloud-Initialisierung im Steuerungsprotokoll hinzu.
Starten Sie die erste Transfer-Ausführung, während der Quell-Workload aktiv bleibt. Überwachen Sie Source-Snapshots, Worker-Zustand, übertragene Bytes, Durchsatz, Zielkapazität und Fehler.
Führen Sie weitere Transfer-Ausführungen aus, um geänderte Disks zu synchronisieren. Wiederholen Sie, bis die gemessene Delta-Dauer in das Cutover-Fenster passt, und sichern Sie danach die erfolgreiche Ausführungs-ID samt Nachweisen.

Coriolis Deployment testen

Erstellen Sie eine Deployment-Definition aus dem freigegebenen Transfer und mappen Sie Ziel-Maschinentyp, Boot- und Daten-Volumes, Netzwerke, Adressen, Security Groups und Deployment-Optionen.
Führen Sie eine Deployment-Ausführung in ein isoliertes Zielnetzwerk aus, ohne Produktionsverkehr umzuschalten.
Verifizieren Sie Boot, Disk-Erkennung, Dateisystem-Integrität, NIC-Benennung, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent. Aktivieren Sie den Agent Service einmalig für das Zielprojekt, bevor Sie Agent-Befehle verwenden. Dies ist von der Installation und Bereitstellung des Agents auf einzelnen Servern getrennt. Starten Sie Abhängigkeiten und die Anwendung in der freigegebenen Reihenfolge.
Führen Sie technische und funktionale Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services. Protokollieren Sie Defekte und Zeitwerte und löschen oder isolieren Sie danach die Test-VM vor einer weiteren Generalprobe.
Korrigieren Sie Transfer-Mapping, Deployment-Definition oder Guest-Remediation und wiederholen Sie Transfer- und Deployment-Ausführungen, bis alle verpflichtenden Tests bestanden sind.

Cutover mit Coriolis

Bestätigen Sie am Cutover-Start-Gate die letzte erfolgreiche Transfer-Ausführung, den aktuellen Source-Zustand, Zielkapazität, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, führen Sie die finale Transfer-Ausführung aus und verifizieren Sie deren Abschluss, den Zustand der übertragenen Disks und Konsistenznachweise.
Führen Sie aus diesem Transfer die produktive Deployment-Ausführung aus. Wenden Sie nur die freigegebenen produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Hystax-Acura-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Hystax Acura das freigegebene Migrationstool ist.

Hystax Acura und Quelle vorbereiten

Stellen Sie die mandantenisolierten Acura-Komponenten gemäß der freigegebenen STACKIT-Zielarchitektur bereit und lizenzieren Sie sie. Verifizieren Sie Administrationszugriff, Backup, Zeitsynchronisation, Monitoring, Ziel-Storage und Ziel-API-Zugriff.
Registrieren Sie VMware-Quelle und STACKIT-Ziel mit dedizierten Zugangsdaten und validieren Sie die dokumentierten Management- und Data-Transfer-Pfade.
Stellen Sie die für die ausgewählte VMware-Integration erforderlichen Hystax-Replikationsagenten bereit und verifizieren Sie sie. Bestätigen Sie VMware Tools, Changed Block Tracking, Snapshot-Sicherheit, Datastore-Headroom und erforderliche vCenter- oder ESXi-Konnektivität, bevor Sie eine VM schützen.
Frieren Sie die Quell-VM-Kennungen und Ziel-Mappings ein, die von der Migrationswelle verwendet werden.

Cloud Framework Hystax Acura Live Migration Seite öffnen

Acura-Replikation starten und Zielzustand speichern

Starten Sie die Hintergrundreplikation für freigegebene Anwendungs-VMs, deren Disks und benötigte Metadaten. Überwachen Sie Source-Snapshots, Agent-Zustand, Durchsatz, Datastore-Wachstum und Fehler.
Verifizieren Sie, dass replizierte Daten als erwartete Volumes und Snapshots in der Ziel-Cloud gespeichert werden und die Aufbewahrung die Zielquote nicht ausschöpft.
Lassen Sie Voll- und inkrementelle Replikate laufen, bis Replikations-Lag und das erwartete finale Delta in das Cutover-Fenster passen.
Beheben Sie Agent-, Snapshot-, CBT-, Kapazitäts- oder Konnektivitätsfehler, bevor ein Wiederherstellungspunkt akzeptiert wird.

Acura-Migrationsplan erstellen

Erstellen Sie den Migrationsplan aus den freigegebenen Mappings für VM, Disk, Netzwerk, Maschinentyp, Adresse und Security Group.
Kodieren Sie Abhängigkeitsreihenfolge und Application-Launch-Sequenz im Orchestrierungsplan. Halten Sie DNS, Load-Balancer und weitere Produktions-Traffic-Switches im Wellen-Steuerungsprotokoll fest.
Prüfen Sie den Plan gegen das eingefrorene Zieldesign und dokumentieren Sie die für die Generalprobe ausgewählte Version.

Hystax-Acura-Migration testen

Starten Sie aus dem ausgewählten Wiederherstellungspunkt eine Testmigration in einem isolierten STACKIT-Netzwerk, ohne Produktionsverkehr umzuleiten. Acura kann diese Generalprobe wiederholen, ohne die Replikation zu stoppen.
Verifizieren Sie orchestrierte Startreihenfolge, Boot, Disks, Dateisysteme, NICs, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent.
Führen Sie die freigegebenen funktionalen und Performance-Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services aus dem isolierten Ziel.
Dokumentieren Sie Defekte und Zeitwerte, räumen Sie die Testumgebung auf oder isolieren Sie sie, aktualisieren Sie den Migrationsplan und wiederholen Sie die Testmigration, bis alle verpflichtenden Prüfungen bestanden sind.

Cutover mit Hystax Acura

Bestätigen Sie am Cutover-Start-Gate das letzte gesunde Replikat, den aktuellen Source-Zustand, Zielkapazität, den freigegebenen Migrationsplan, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, vervollständigen Sie die finale inkrementelle Replikation und verifizieren Sie den resultierenden Wiederherstellungspunkt.
Führen Sie den finalen Cutover über den freigegebenen Orchestrierungsplan aus und wenden Sie anschließend die geplanten produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Gemeinsames Validierungs- und Rollback-Gate

Starten Sie die Validierung, sobald die Zielinstanzen erreichbar sind. Erfassen Sie Zeitstempel, weil das verbleibende Rollback-Fenster eine technische Randbedingung ist.

Validieren Sie den VM-Zustand: Boot, Konsole, Disks, Dateisysteme, Mounts, Netzwerkschnittstellen, Routen, DNS, NTP, Zertifikate, Server Agent und erforderliche Betriebssystem-Services.
Validieren Sie den Datenzustand: erwarteter Wiederherstellungspunkt, Datei- oder Datenbankkonsistenz, Checksummen oder Record Counts sowie keine unbeabsichtigten Schreibzugriffe auf der Quelle.
Starten Sie Abhängigkeiten und Anwendungen in Reihenfolge und führen Sie dann Health Checks, synthetische Transaktionen, Integrationen, geplante Jobs und verpflichtende Geschäftstests aus.
Bestätigen Sie Logs, Metriken, Alerts, Backups, administrativen Zugriff und Security Controls in der Zielumgebung.
Vergleichen Sie CPU, Memory, Disk-Latenz, IOPS, Durchsatz, Netzwerkverhalten, Applikationslatenz und Fehlerraten mit den freigegebenen Abnahmeschwellen.
Treffen Sie an der Entscheidungs-Deadline entweder die Zielabnahme oder führen Sie den dokumentierten Rollback aus. Weichen Sie nicht in ein ungebundenes Troubleshooting-Fenster aus.

Rollback ist nur sicher, solange die Data Ownership eindeutig bleibt. Wenn das Ziel bereits Schreibzugriffe akzeptiert hat, stoppen Sie die Zielverarbeitung und führen Sie die freigegebene Rücksynchronisations- oder Abstimmungsmethode aus, bevor die Quelle neu gestartet wird. Schalten Sie nie beide Kopien mit Produktionskonnektivität gleichzeitig ein, sofern das Anwendungsdesign keine gleichzeitigen Schreiber explizit unterstützt.

Abschluss und Quellaufbewahrung

Die Welle ist technisch abgeschlossen, wenn:

verpflichtende technische und funktionale Prüfungen bestanden sind und das Ziel das deklarierte System of Record ist;
Monitoring- und Backup-Nachweise aus STACKIT vorliegen;
Defekte, temporäre Ausnahmen und Folgeaktionen Owner und Fristen haben;
tatsächliche Dauern für Replikation, Freeze, Cutover und Validierung für die nächste Welle erfasst sind;
Quell-VMs für den freigegebenen Aufbewahrungszeitraum ausgeschaltet und zugriffskontrolliert bleiben;
das Löschen der Quelle erst nach Ablauf der Aufbewahrung, Wiederherstellungsbestätigung und expliziter Freigabe erfolgt;
das initiale Ziel-Sizing mit seinen Messwerten und Abnahmeschwellen an Optimize übergeben ist.

Primäre Referenzen

Externe Quelle cloudbase.it Cloudbase Coriolis Externe Seite öffnen Führt von der Route weg Externe Quelle hystax.com Hystax Acura Live Migration Externe Seite öffnen Führt von der Route weg

LIVE

Migrate

Starten Sie Migrate nur mit freigegebenen Source- und Target-Zuständen. Bewahren Sie Topologie-Annahmen, synchronisieren Sie den Zustand, steuern Sie den Traffic-Cutover und fordern Sie objektive Nachweise für Kontinuität und Telemetrie.

In 4 Trails

Kontrollierter Migrationswellen-Flow von Readiness über Synchronisation, Cutover und Validierung bis zur Übergabe

Überblick: Migrate-Modul

Dieses Modul setzt die eigentliche technische Migration in der Migration Factory um. Zu diesem Zeitpunkt sind Entscheidungen aus Design getroffen, Landing Zones aufgebaut und Wellen geplant.

Der Fokus liegt auf reproduzierbarer Umsetzung für:

Relocate: Verlagerung von Workloads mit minimalen Änderungen an Annahmen zur Plattform.
Rehost: Lift-and-Shift auf STACKIT mit kontrolliertem Cutover und Rollback-Bereitschaft.
Replatform: Gezielte Anpassungen an der Plattform während der Migration ohne vollständiges Redesign.

Abhängigkeiten aus Design and Mobilize

Migrate startet erst, wenn aus der vorherigen Phase umsetzbare Ergebnisse vorliegen:

Design je Anwendung: Zielbild, Schnittstellen, Daten und nicht-funktionale Anforderungen sind festgelegt.
Zuordnung zur Wellenplanung: Jede Anwendung ist einer freigegebenen Welle mit Zeitfenster und Abhängigkeiten zugeordnet.
Runbook je Pfad der Migration: Für Pfad und Typ von Workload liegt ein validiertes Runbook vor, inklusive Go/No-Go-, Cutover- und Rollback-Kriterien.
Zuordnung zur Application Landing Zone: Anwendungen sind der passenden Ziel-Landing-Zone und Ownership zugeordnet.
Entscheidungswege und Kommunikation: Entscheidungswege, Eskalationsprozess und Kommunikation mit dem Application Owner sind festgelegt, inklusive der Frage, ob der Cutover gemeinsam durchgeführt werden muss.

Verweise auf Module:

End-to-End-Ablauf in der Factory

Wellenscope, Cutover-Fenster, Rollback-Kriterien und Runbook-Verantwortung final bestätigen.
Wellen-Baseline einfrieren (Versionen, Abhängigkeiten, Datenscope, Schnittstellenverträge).
Technische Readiness-Prüfungen in Quelle und Ziel durchführen.
Runbook-Schritte je Workload-Archetyp und R-Strategie-Pfad ausführen.
Cutover durchführen und Traffic gemäß Wellenplan auf STACKIT umschalten.
Technische, funktionale und operative Akzeptanzkriterien validieren.
Stabilisierungsmaßnahmen in kurzen Feedback-Schleifen umsetzen.
Stabilisierte Workloads an Optimize und Operate übergeben.

Ablauf je R-Pfad

Relocate-Ablauf

Platzierung im Ziel auf STACKIT mit äquivalenten Annahmen zur Topologie herstellen.
Daten und Zustände mit Konsistenzprüfungen migrieren.
Traffic mit Rollback-Leitplanken umschalten.
Geschäftskontinuität und operative Telemetrie verifizieren.

Rehost-Ablauf

Applikationen und Daten weitgehend unverändert übertragen.
Infrastruktur-Bindings und Konnektivität auf STACKIT neu zuordnen.
Kontrollierten Cutover mit Smoke-Tests durchführen.
Phase zur Stabilisierung und Performance-Baseline abschließen.

Replatform-Ablauf

Ausgewählte Managed Services und Plattformfunktionen in den Pfad der Migration integrieren.
Konfiguration, Deployment-Artefakte und Kontrollen im Betrieb anpassen.
Cutover mit Kompatibilitäts- und Datenintegritätsprüfungen durchführen.
SLO-Verhalten und Betriebsreife der Zielumgebung nachweisen.

Zentrale Artefakte pro Welle

Runbook-Nachweise

Vollständige Runbook-Protokolle, Entscheidungsnachweise und Rollback-Checkpoints pro Workload.

Cutover-Report

Zeitlich nachvollziehbares Ergebnis mit Abnahme, Defekten und eingeleiteten Maßnahmen.

Operative Baseline

Initiales Monitoring, Alerting, Ownership und Incident-Prozesse in der Zielumgebung.

Optimize-Backlog

Priorisierte Maßnahmen für Rightsizing, Performance-Tuning und Kostenoptimierung.

Abgrenzung zu Optimize, Repurchase und Refactor

Optimize startet direkt nach stabilem Cutover und nutzt Daten aus dem Betrieb für Tuning und Kostensteuerung: Optimize.
Repurchase folgt einer anderen SaaS-Logik und läuft bewusst außerhalb des klassischen Modells mit Wellen: Repurchase.
Refactor wird als eigener Pfad für Transformation geführt: Refactor.

Unterstützung direkt nach dem Cutover kann sich zeitlich mit Optimize überschneiden, wird aber inhaltlich in der Run-Phase behandelt.

AUTO

Einen Tool-Pfad wählen und ausführen

Wählen Sie für die komplette Welle genau ein freigegebenes Migrationstool. Halten Sie dessen Endpoint-, Mapping-, Replikations-, Testmigrations-, Final-Sync- und Cutover-Sequenz bis zum Abschluss zusammen.

Migration design-and-mobilize use-cases relocate vmware coriolis acura cutover rollback

Ausführung einer VMware-Relocate-Welle

STACKIT

Führen Sie kontrollierte VMware-Relocate-Wellen nach STACKIT über vollständige Coriolis- oder Hystax-Acura-Pfade aus, mit Testmigration, Cutover, Validierung und Rollback.

Cloud Framework VMware Relocate Source Readiness Seite öffnen Cloud Framework STACKIT VM Target Sizing and Storage Selection Seite öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Zweck

Verwenden Sie dieses Runbook, um eine freigegebene VMware-Relocate-Welle nach STACKIT auszuführen. Es enthält zwei vollständige Tool-Pfade: Cloudbase Coriolis und Hystax Acura. Wählen Sie für die gesamte Welle genau einen Pfad und behalten Sie dasselbe Tool, dieselben Inventar-Kennungen, Mappings und Nachweise durch Testmigration und finalen Cutover bei.

Das Runbook geht davon aus, dass Anwendungen VM-basiert bleiben. Architekturmodernisierung, Datenbank-Replatforming und Applikations-Refactoring erfordern separate Pläne und Abnahmekriterien.

Eingangskriterien

Starten Sie die Replikation erst, wenn alle Eingangskriterien erfüllt sind:

Der Wellenumfang und die Abhängigkeitsgruppen sind eingefroren und jede VM hat eine stabile Quellkennung.
Die VMware-Quellbereitschaft, tool-spezifische Voraussetzungen und Wiederherstellungspunkte sind verifiziert.
Ziel-Maschinentypen, Volumes, Performance-Klassen, Netzwerke, Adressen, Security Groups und Platzierung sind freigegeben und innerhalb der Quoten verfügbar.
Anwendungsseitige Konsistenz, Testfälle, Wartungsfenster, erwartete Downtime und maximale Cutover-Dauer sind dokumentiert.
Source Freeze, Traffic Switch, Monitoring-Aktivierung und Rollback-Aktionen haben benannte technische Owner.
Der Quellaufbewahrungszeitraum und die Befugnis zum Löschen der Quell-VMs sind vor dem Cutover definiert.

Wellen-Steuerungsprotokoll

Legen Sie ein versionskontrolliertes Steuerungsprotokoll für die Welle an. Es enthält:

Source- und Target-Mappings für VM, Disk, Netzwerk, Adresse und Security Group;
gewähltes Tool sowie Appliance- oder Service-Version;
Start der Erstkopie, letzte erfolgreiche Delta-Synchronisation und gemessenen Replikations-Lag;
geordnete Shutdown- und Startup-Prozeduren der Anwendung;
technische und funktionale Testfälle mit objektiven Pass-Kriterien;
Cutover-Zeitplan, Checkpoints, Hold Points und Entscheidungsbefugnis;
Rollback-Trigger, letzte sichere Entscheidungszeit, Methode zur Datenabstimmung und Quellaufbewahrung;
Links zu Logs, Screenshots, Checksummen, Testergebnissen und Freigaben.

Führen Sie das Verfahren zuerst mit einem risikoarmen Piloten aus, der die vorgesehenen Muster für Betriebssystem, Disk, Netzwerk und Anwendung repräsentiert. Überführen Sie das Runbook erst dann in größere Wellen, wenn Pilot-Erkenntnisse eingearbeitet wurden.

Coriolis-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Cloudbase Coriolis das freigegebene Migrationstool ist.

Coriolis auf STACKIT bereitstellen

Führen Sie den Coriolis STACKIT Installer Dry Run und den Cloud Check gegen das freigegebene Projekt, die Region, den Maschinentyp, die Storage-Performance-Klasse sowie die Netzwerk-, DNS- und TLS-Konfiguration aus.
Stellen Sie die lizenzierte Appliance bereit, speichern Sie ihr strukturiertes Ergebnis und erzeugte Zugangsdaten sicher und führen Sie den Installer erneut aus, um die Wiederverwendung der vorgesehenen Ressourcen zu bestätigen.
Verifizieren Sie Appliance-Backup, administrativen Zugriff, TLS, Zeitsynchronisation, Monitoring, Quoten sowie die Migrations-Datenpfade, die nicht von der HTTPS-Benutzeroberfläche abgedeckt sind.

Cloud Framework Cloudbase Coriolis Seite öffnen Cloud Framework Coriolis STACKIT Installer Stellt die Coriolis-Appliance auf STACKIT bereit und konfiguriert sie vor Endpoint- und Migrations-Setup. Seite öffnen

Endpoints und Minion-Pools konfigurieren

Erstellen Sie den VMware-Source-Endpoint und den STACKIT-Destination-Endpoint mit dedizierten Zugangsdaten. Testen Sie Authentifizierung, Zertifikatsvertrauen, Inventar-Erkennung und API-Zugriff unabhängig voneinander.
Konfigurieren Sie die Source- und Destination-Minion-Pools, die Coriolis-Operationen ausführen. Verifizieren Sie Worker-Zustand, Kapazität, Concurrency-Grenzen, Routing, Namensauflösung und Zugriff auf beide Endpoints.
Bestätigen Sie, dass ein Worker jeden benötigten Management- und Data-Transfer-Service erreichen kann. Browser-Zugriff auf die Coriolis-Appliance allein belegt keine Endpoint-zu-Endpoint- Transfer-Bereitschaft.
Dokumentieren Sie Endpoint- und Minion-Pool-Identitäten sowie Versionen im Wellen-Steuerungsprotokoll, damit Wiederholungen und Cutover dieselbe Ausführungstopologie verwenden.

Coriolis Transfer entwerfen und ausführen

Erstellen Sie pro freigegebener VM oder Konsistenzgruppe genau eine Migrations-Transfer-Definition. Wählen Sie die Quellinstanz und lösen Sie jede Source-Disk und jedes Netzwerk auf das freigegebene STACKIT-Zieldesign auf.
Bestätigen Sie Coriolis-Gastunterstützung und das OS-Morphing-Verhalten. Fügen Sie erforderliche Remediation für Bootloader, Storage-Treiber, Netzwerk oder Cloud-Initialisierung im Steuerungsprotokoll hinzu.
Starten Sie die erste Transfer-Ausführung, während der Quell-Workload aktiv bleibt. Überwachen Sie Source-Snapshots, Worker-Zustand, übertragene Bytes, Durchsatz, Zielkapazität und Fehler.
Führen Sie weitere Transfer-Ausführungen aus, um geänderte Disks zu synchronisieren. Wiederholen Sie, bis die gemessene Delta-Dauer in das Cutover-Fenster passt, und sichern Sie danach die erfolgreiche Ausführungs-ID samt Nachweisen.

Coriolis Deployment testen

Erstellen Sie eine Deployment-Definition aus dem freigegebenen Transfer und mappen Sie Ziel-Maschinentyp, Boot- und Daten-Volumes, Netzwerke, Adressen, Security Groups und Deployment-Optionen.
Führen Sie eine Deployment-Ausführung in ein isoliertes Zielnetzwerk aus, ohne Produktionsverkehr umzuschalten.
Verifizieren Sie Boot, Disk-Erkennung, Dateisystem-Integrität, NIC-Benennung, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent. Aktivieren Sie den Agent Service einmalig für das Zielprojekt, bevor Sie Agent-Befehle verwenden. Dies ist von der Installation und Bereitstellung des Agents auf einzelnen Servern getrennt. Starten Sie Abhängigkeiten und die Anwendung in der freigegebenen Reihenfolge.
Führen Sie technische und funktionale Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services. Protokollieren Sie Defekte und Zeitwerte und löschen oder isolieren Sie danach die Test-VM vor einer weiteren Generalprobe.
Korrigieren Sie Transfer-Mapping, Deployment-Definition oder Guest-Remediation und wiederholen Sie Transfer- und Deployment-Ausführungen, bis alle verpflichtenden Tests bestanden sind.

Cutover mit Coriolis

Bestätigen Sie am Cutover-Start-Gate die letzte erfolgreiche Transfer-Ausführung, den aktuellen Source-Zustand, Zielkapazität, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, führen Sie die finale Transfer-Ausführung aus und verifizieren Sie deren Abschluss, den Zustand der übertragenen Disks und Konsistenznachweise.
Führen Sie aus diesem Transfer die produktive Deployment-Ausführung aus. Wenden Sie nur die freigegebenen produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Hystax-Acura-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Hystax Acura das freigegebene Migrationstool ist.

Hystax Acura und Quelle vorbereiten

Stellen Sie die mandantenisolierten Acura-Komponenten gemäß der freigegebenen STACKIT-Zielarchitektur bereit und lizenzieren Sie sie. Verifizieren Sie Administrationszugriff, Backup, Zeitsynchronisation, Monitoring, Ziel-Storage und Ziel-API-Zugriff.
Registrieren Sie VMware-Quelle und STACKIT-Ziel mit dedizierten Zugangsdaten und validieren Sie die dokumentierten Management- und Data-Transfer-Pfade.
Stellen Sie die für die ausgewählte VMware-Integration erforderlichen Hystax-Replikationsagenten bereit und verifizieren Sie sie. Bestätigen Sie VMware Tools, Changed Block Tracking, Snapshot-Sicherheit, Datastore-Headroom und erforderliche vCenter- oder ESXi-Konnektivität, bevor Sie eine VM schützen.
Frieren Sie die Quell-VM-Kennungen und Ziel-Mappings ein, die von der Migrationswelle verwendet werden.

Cloud Framework Hystax Acura Live Migration Seite öffnen

Acura-Replikation starten und Zielzustand speichern

Starten Sie die Hintergrundreplikation für freigegebene Anwendungs-VMs, deren Disks und benötigte Metadaten. Überwachen Sie Source-Snapshots, Agent-Zustand, Durchsatz, Datastore-Wachstum und Fehler.
Verifizieren Sie, dass replizierte Daten als erwartete Volumes und Snapshots in der Ziel-Cloud gespeichert werden und die Aufbewahrung die Zielquote nicht ausschöpft.
Lassen Sie Voll- und inkrementelle Replikate laufen, bis Replikations-Lag und das erwartete finale Delta in das Cutover-Fenster passen.
Beheben Sie Agent-, Snapshot-, CBT-, Kapazitäts- oder Konnektivitätsfehler, bevor ein Wiederherstellungspunkt akzeptiert wird.

Acura-Migrationsplan erstellen

Erstellen Sie den Migrationsplan aus den freigegebenen Mappings für VM, Disk, Netzwerk, Maschinentyp, Adresse und Security Group.
Kodieren Sie Abhängigkeitsreihenfolge und Application-Launch-Sequenz im Orchestrierungsplan. Halten Sie DNS, Load-Balancer und weitere Produktions-Traffic-Switches im Wellen-Steuerungsprotokoll fest.
Prüfen Sie den Plan gegen das eingefrorene Zieldesign und dokumentieren Sie die für die Generalprobe ausgewählte Version.

Hystax-Acura-Migration testen

Starten Sie aus dem ausgewählten Wiederherstellungspunkt eine Testmigration in einem isolierten STACKIT-Netzwerk, ohne Produktionsverkehr umzuleiten. Acura kann diese Generalprobe wiederholen, ohne die Replikation zu stoppen.
Verifizieren Sie orchestrierte Startreihenfolge, Boot, Disks, Dateisysteme, NICs, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent.
Führen Sie die freigegebenen funktionalen und Performance-Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services aus dem isolierten Ziel.
Dokumentieren Sie Defekte und Zeitwerte, räumen Sie die Testumgebung auf oder isolieren Sie sie, aktualisieren Sie den Migrationsplan und wiederholen Sie die Testmigration, bis alle verpflichtenden Prüfungen bestanden sind.

Cutover mit Hystax Acura

Bestätigen Sie am Cutover-Start-Gate das letzte gesunde Replikat, den aktuellen Source-Zustand, Zielkapazität, den freigegebenen Migrationsplan, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, vervollständigen Sie die finale inkrementelle Replikation und verifizieren Sie den resultierenden Wiederherstellungspunkt.
Führen Sie den finalen Cutover über den freigegebenen Orchestrierungsplan aus und wenden Sie anschließend die geplanten produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Gemeinsames Validierungs- und Rollback-Gate

Starten Sie die Validierung, sobald die Zielinstanzen erreichbar sind. Erfassen Sie Zeitstempel, weil das verbleibende Rollback-Fenster eine technische Randbedingung ist.

Validieren Sie den VM-Zustand: Boot, Konsole, Disks, Dateisysteme, Mounts, Netzwerkschnittstellen, Routen, DNS, NTP, Zertifikate, Server Agent und erforderliche Betriebssystem-Services.
Validieren Sie den Datenzustand: erwarteter Wiederherstellungspunkt, Datei- oder Datenbankkonsistenz, Checksummen oder Record Counts sowie keine unbeabsichtigten Schreibzugriffe auf der Quelle.
Starten Sie Abhängigkeiten und Anwendungen in Reihenfolge und führen Sie dann Health Checks, synthetische Transaktionen, Integrationen, geplante Jobs und verpflichtende Geschäftstests aus.
Bestätigen Sie Logs, Metriken, Alerts, Backups, administrativen Zugriff und Security Controls in der Zielumgebung.
Vergleichen Sie CPU, Memory, Disk-Latenz, IOPS, Durchsatz, Netzwerkverhalten, Applikationslatenz und Fehlerraten mit den freigegebenen Abnahmeschwellen.
Treffen Sie an der Entscheidungs-Deadline entweder die Zielabnahme oder führen Sie den dokumentierten Rollback aus. Weichen Sie nicht in ein ungebundenes Troubleshooting-Fenster aus.

Rollback ist nur sicher, solange die Data Ownership eindeutig bleibt. Wenn das Ziel bereits Schreibzugriffe akzeptiert hat, stoppen Sie die Zielverarbeitung und führen Sie die freigegebene Rücksynchronisations- oder Abstimmungsmethode aus, bevor die Quelle neu gestartet wird. Schalten Sie nie beide Kopien mit Produktionskonnektivität gleichzeitig ein, sofern das Anwendungsdesign keine gleichzeitigen Schreiber explizit unterstützt.

Abschluss und Quellaufbewahrung

Die Welle ist technisch abgeschlossen, wenn:

verpflichtende technische und funktionale Prüfungen bestanden sind und das Ziel das deklarierte System of Record ist;
Monitoring- und Backup-Nachweise aus STACKIT vorliegen;
Defekte, temporäre Ausnahmen und Folgeaktionen Owner und Fristen haben;
tatsächliche Dauern für Replikation, Freeze, Cutover und Validierung für die nächste Welle erfasst sind;
Quell-VMs für den freigegebenen Aufbewahrungszeitraum ausgeschaltet und zugriffskontrolliert bleiben;
das Löschen der Quelle erst nach Ablauf der Aufbewahrung, Wiederherstellungsbestätigung und expliziter Freigabe erfolgt;
das initiale Ziel-Sizing mit seinen Messwerten und Abnahmeschwellen an Optimize übergeben ist.

Primäre Referenzen

Externe Quelle cloudbase.it Cloudbase Coriolis Externe Seite öffnen Führt von der Route weg Externe Quelle hystax.com Hystax Acura Live Migration Externe Seite öffnen Führt von der Route weg

Migration design-and-mobilize use-cases relocate vmware coriolis acura cutover rollback

Ausführung einer VMware-Relocate-Welle

STACKIT

Führen Sie kontrollierte VMware-Relocate-Wellen nach STACKIT über vollständige Coriolis- oder Hystax-Acura-Pfade aus, mit Testmigration, Cutover, Validierung und Rollback.

Cloud Framework VMware Relocate Source Readiness Seite öffnen Cloud Framework STACKIT VM Target Sizing and Storage Selection Seite öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Zweck

Verwenden Sie dieses Runbook, um eine freigegebene VMware-Relocate-Welle nach STACKIT auszuführen. Es enthält zwei vollständige Tool-Pfade: Cloudbase Coriolis und Hystax Acura. Wählen Sie für die gesamte Welle genau einen Pfad und behalten Sie dasselbe Tool, dieselben Inventar-Kennungen, Mappings und Nachweise durch Testmigration und finalen Cutover bei.

Das Runbook geht davon aus, dass Anwendungen VM-basiert bleiben. Architekturmodernisierung, Datenbank-Replatforming und Applikations-Refactoring erfordern separate Pläne und Abnahmekriterien.

Eingangskriterien

Starten Sie die Replikation erst, wenn alle Eingangskriterien erfüllt sind:

Der Wellenumfang und die Abhängigkeitsgruppen sind eingefroren und jede VM hat eine stabile Quellkennung.
Die VMware-Quellbereitschaft, tool-spezifische Voraussetzungen und Wiederherstellungspunkte sind verifiziert.
Ziel-Maschinentypen, Volumes, Performance-Klassen, Netzwerke, Adressen, Security Groups und Platzierung sind freigegeben und innerhalb der Quoten verfügbar.
Anwendungsseitige Konsistenz, Testfälle, Wartungsfenster, erwartete Downtime und maximale Cutover-Dauer sind dokumentiert.
Source Freeze, Traffic Switch, Monitoring-Aktivierung und Rollback-Aktionen haben benannte technische Owner.
Der Quellaufbewahrungszeitraum und die Befugnis zum Löschen der Quell-VMs sind vor dem Cutover definiert.

Wellen-Steuerungsprotokoll

Legen Sie ein versionskontrolliertes Steuerungsprotokoll für die Welle an. Es enthält:

Source- und Target-Mappings für VM, Disk, Netzwerk, Adresse und Security Group;
gewähltes Tool sowie Appliance- oder Service-Version;
Start der Erstkopie, letzte erfolgreiche Delta-Synchronisation und gemessenen Replikations-Lag;
geordnete Shutdown- und Startup-Prozeduren der Anwendung;
technische und funktionale Testfälle mit objektiven Pass-Kriterien;
Cutover-Zeitplan, Checkpoints, Hold Points und Entscheidungsbefugnis;
Rollback-Trigger, letzte sichere Entscheidungszeit, Methode zur Datenabstimmung und Quellaufbewahrung;
Links zu Logs, Screenshots, Checksummen, Testergebnissen und Freigaben.

Führen Sie das Verfahren zuerst mit einem risikoarmen Piloten aus, der die vorgesehenen Muster für Betriebssystem, Disk, Netzwerk und Anwendung repräsentiert. Überführen Sie das Runbook erst dann in größere Wellen, wenn Pilot-Erkenntnisse eingearbeitet wurden.

Coriolis-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Cloudbase Coriolis das freigegebene Migrationstool ist.

Coriolis auf STACKIT bereitstellen

Führen Sie den Coriolis STACKIT Installer Dry Run und den Cloud Check gegen das freigegebene Projekt, die Region, den Maschinentyp, die Storage-Performance-Klasse sowie die Netzwerk-, DNS- und TLS-Konfiguration aus.
Stellen Sie die lizenzierte Appliance bereit, speichern Sie ihr strukturiertes Ergebnis und erzeugte Zugangsdaten sicher und führen Sie den Installer erneut aus, um die Wiederverwendung der vorgesehenen Ressourcen zu bestätigen.
Verifizieren Sie Appliance-Backup, administrativen Zugriff, TLS, Zeitsynchronisation, Monitoring, Quoten sowie die Migrations-Datenpfade, die nicht von der HTTPS-Benutzeroberfläche abgedeckt sind.

Cloud Framework Cloudbase Coriolis Seite öffnen Cloud Framework Coriolis STACKIT Installer Stellt die Coriolis-Appliance auf STACKIT bereit und konfiguriert sie vor Endpoint- und Migrations-Setup. Seite öffnen

Endpoints und Minion-Pools konfigurieren

Erstellen Sie den VMware-Source-Endpoint und den STACKIT-Destination-Endpoint mit dedizierten Zugangsdaten. Testen Sie Authentifizierung, Zertifikatsvertrauen, Inventar-Erkennung und API-Zugriff unabhängig voneinander.
Konfigurieren Sie die Source- und Destination-Minion-Pools, die Coriolis-Operationen ausführen. Verifizieren Sie Worker-Zustand, Kapazität, Concurrency-Grenzen, Routing, Namensauflösung und Zugriff auf beide Endpoints.
Bestätigen Sie, dass ein Worker jeden benötigten Management- und Data-Transfer-Service erreichen kann. Browser-Zugriff auf die Coriolis-Appliance allein belegt keine Endpoint-zu-Endpoint- Transfer-Bereitschaft.
Dokumentieren Sie Endpoint- und Minion-Pool-Identitäten sowie Versionen im Wellen-Steuerungsprotokoll, damit Wiederholungen und Cutover dieselbe Ausführungstopologie verwenden.

Coriolis Transfer entwerfen und ausführen

Erstellen Sie pro freigegebener VM oder Konsistenzgruppe genau eine Migrations-Transfer-Definition. Wählen Sie die Quellinstanz und lösen Sie jede Source-Disk und jedes Netzwerk auf das freigegebene STACKIT-Zieldesign auf.
Bestätigen Sie Coriolis-Gastunterstützung und das OS-Morphing-Verhalten. Fügen Sie erforderliche Remediation für Bootloader, Storage-Treiber, Netzwerk oder Cloud-Initialisierung im Steuerungsprotokoll hinzu.
Starten Sie die erste Transfer-Ausführung, während der Quell-Workload aktiv bleibt. Überwachen Sie Source-Snapshots, Worker-Zustand, übertragene Bytes, Durchsatz, Zielkapazität und Fehler.
Führen Sie weitere Transfer-Ausführungen aus, um geänderte Disks zu synchronisieren. Wiederholen Sie, bis die gemessene Delta-Dauer in das Cutover-Fenster passt, und sichern Sie danach die erfolgreiche Ausführungs-ID samt Nachweisen.

Coriolis Deployment testen

Erstellen Sie eine Deployment-Definition aus dem freigegebenen Transfer und mappen Sie Ziel-Maschinentyp, Boot- und Daten-Volumes, Netzwerke, Adressen, Security Groups und Deployment-Optionen.
Führen Sie eine Deployment-Ausführung in ein isoliertes Zielnetzwerk aus, ohne Produktionsverkehr umzuschalten.
Verifizieren Sie Boot, Disk-Erkennung, Dateisystem-Integrität, NIC-Benennung, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent. Aktivieren Sie den Agent Service einmalig für das Zielprojekt, bevor Sie Agent-Befehle verwenden. Dies ist von der Installation und Bereitstellung des Agents auf einzelnen Servern getrennt. Starten Sie Abhängigkeiten und die Anwendung in der freigegebenen Reihenfolge.
Führen Sie technische und funktionale Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services. Protokollieren Sie Defekte und Zeitwerte und löschen oder isolieren Sie danach die Test-VM vor einer weiteren Generalprobe.
Korrigieren Sie Transfer-Mapping, Deployment-Definition oder Guest-Remediation und wiederholen Sie Transfer- und Deployment-Ausführungen, bis alle verpflichtenden Tests bestanden sind.

Cutover mit Coriolis

Bestätigen Sie am Cutover-Start-Gate die letzte erfolgreiche Transfer-Ausführung, den aktuellen Source-Zustand, Zielkapazität, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, führen Sie die finale Transfer-Ausführung aus und verifizieren Sie deren Abschluss, den Zustand der übertragenen Disks und Konsistenznachweise.
Führen Sie aus diesem Transfer die produktive Deployment-Ausführung aus. Wenden Sie nur die freigegebenen produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Hystax-Acura-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Hystax Acura das freigegebene Migrationstool ist.

Hystax Acura und Quelle vorbereiten

Stellen Sie die mandantenisolierten Acura-Komponenten gemäß der freigegebenen STACKIT-Zielarchitektur bereit und lizenzieren Sie sie. Verifizieren Sie Administrationszugriff, Backup, Zeitsynchronisation, Monitoring, Ziel-Storage und Ziel-API-Zugriff.
Registrieren Sie VMware-Quelle und STACKIT-Ziel mit dedizierten Zugangsdaten und validieren Sie die dokumentierten Management- und Data-Transfer-Pfade.
Stellen Sie die für die ausgewählte VMware-Integration erforderlichen Hystax-Replikationsagenten bereit und verifizieren Sie sie. Bestätigen Sie VMware Tools, Changed Block Tracking, Snapshot-Sicherheit, Datastore-Headroom und erforderliche vCenter- oder ESXi-Konnektivität, bevor Sie eine VM schützen.
Frieren Sie die Quell-VM-Kennungen und Ziel-Mappings ein, die von der Migrationswelle verwendet werden.

Cloud Framework Hystax Acura Live Migration Seite öffnen

Acura-Replikation starten und Zielzustand speichern

Starten Sie die Hintergrundreplikation für freigegebene Anwendungs-VMs, deren Disks und benötigte Metadaten. Überwachen Sie Source-Snapshots, Agent-Zustand, Durchsatz, Datastore-Wachstum und Fehler.
Verifizieren Sie, dass replizierte Daten als erwartete Volumes und Snapshots in der Ziel-Cloud gespeichert werden und die Aufbewahrung die Zielquote nicht ausschöpft.
Lassen Sie Voll- und inkrementelle Replikate laufen, bis Replikations-Lag und das erwartete finale Delta in das Cutover-Fenster passen.
Beheben Sie Agent-, Snapshot-, CBT-, Kapazitäts- oder Konnektivitätsfehler, bevor ein Wiederherstellungspunkt akzeptiert wird.

Acura-Migrationsplan erstellen

Erstellen Sie den Migrationsplan aus den freigegebenen Mappings für VM, Disk, Netzwerk, Maschinentyp, Adresse und Security Group.
Kodieren Sie Abhängigkeitsreihenfolge und Application-Launch-Sequenz im Orchestrierungsplan. Halten Sie DNS, Load-Balancer und weitere Produktions-Traffic-Switches im Wellen-Steuerungsprotokoll fest.
Prüfen Sie den Plan gegen das eingefrorene Zieldesign und dokumentieren Sie die für die Generalprobe ausgewählte Version.

Hystax-Acura-Migration testen

Starten Sie aus dem ausgewählten Wiederherstellungspunkt eine Testmigration in einem isolierten STACKIT-Netzwerk, ohne Produktionsverkehr umzuleiten. Acura kann diese Generalprobe wiederholen, ohne die Replikation zu stoppen.
Verifizieren Sie orchestrierte Startreihenfolge, Boot, Disks, Dateisysteme, NICs, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent.
Führen Sie die freigegebenen funktionalen und Performance-Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services aus dem isolierten Ziel.
Dokumentieren Sie Defekte und Zeitwerte, räumen Sie die Testumgebung auf oder isolieren Sie sie, aktualisieren Sie den Migrationsplan und wiederholen Sie die Testmigration, bis alle verpflichtenden Prüfungen bestanden sind.

Cutover mit Hystax Acura

Bestätigen Sie am Cutover-Start-Gate das letzte gesunde Replikat, den aktuellen Source-Zustand, Zielkapazität, den freigegebenen Migrationsplan, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, vervollständigen Sie die finale inkrementelle Replikation und verifizieren Sie den resultierenden Wiederherstellungspunkt.
Führen Sie den finalen Cutover über den freigegebenen Orchestrierungsplan aus und wenden Sie anschließend die geplanten produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Gemeinsames Validierungs- und Rollback-Gate

Starten Sie die Validierung, sobald die Zielinstanzen erreichbar sind. Erfassen Sie Zeitstempel, weil das verbleibende Rollback-Fenster eine technische Randbedingung ist.

Validieren Sie den VM-Zustand: Boot, Konsole, Disks, Dateisysteme, Mounts, Netzwerkschnittstellen, Routen, DNS, NTP, Zertifikate, Server Agent und erforderliche Betriebssystem-Services.
Validieren Sie den Datenzustand: erwarteter Wiederherstellungspunkt, Datei- oder Datenbankkonsistenz, Checksummen oder Record Counts sowie keine unbeabsichtigten Schreibzugriffe auf der Quelle.
Starten Sie Abhängigkeiten und Anwendungen in Reihenfolge und führen Sie dann Health Checks, synthetische Transaktionen, Integrationen, geplante Jobs und verpflichtende Geschäftstests aus.
Bestätigen Sie Logs, Metriken, Alerts, Backups, administrativen Zugriff und Security Controls in der Zielumgebung.
Vergleichen Sie CPU, Memory, Disk-Latenz, IOPS, Durchsatz, Netzwerkverhalten, Applikationslatenz und Fehlerraten mit den freigegebenen Abnahmeschwellen.
Treffen Sie an der Entscheidungs-Deadline entweder die Zielabnahme oder führen Sie den dokumentierten Rollback aus. Weichen Sie nicht in ein ungebundenes Troubleshooting-Fenster aus.

Rollback ist nur sicher, solange die Data Ownership eindeutig bleibt. Wenn das Ziel bereits Schreibzugriffe akzeptiert hat, stoppen Sie die Zielverarbeitung und führen Sie die freigegebene Rücksynchronisations- oder Abstimmungsmethode aus, bevor die Quelle neu gestartet wird. Schalten Sie nie beide Kopien mit Produktionskonnektivität gleichzeitig ein, sofern das Anwendungsdesign keine gleichzeitigen Schreiber explizit unterstützt.

Abschluss und Quellaufbewahrung

Die Welle ist technisch abgeschlossen, wenn:

verpflichtende technische und funktionale Prüfungen bestanden sind und das Ziel das deklarierte System of Record ist;
Monitoring- und Backup-Nachweise aus STACKIT vorliegen;
Defekte, temporäre Ausnahmen und Folgeaktionen Owner und Fristen haben;
tatsächliche Dauern für Replikation, Freeze, Cutover und Validierung für die nächste Welle erfasst sind;
Quell-VMs für den freigegebenen Aufbewahrungszeitraum ausgeschaltet und zugriffskontrolliert bleiben;
das Löschen der Quelle erst nach Ablauf der Aufbewahrung, Wiederherstellungsbestätigung und expliziter Freigabe erfolgt;
das initiale Ziel-Sizing mit seinen Messwerten und Abnahmeschwellen an Optimize übergeben ist.

Primäre Referenzen

Externe Quelle cloudbase.it Cloudbase Coriolis Externe Seite öffnen Führt von der Route weg Externe Quelle hystax.com Hystax Acura Live Migration Externe Seite öffnen Führt von der Route weg

BASE

Technische Umsetzung mit Coriolis

STACKIT Neu

Relocate to STACKIT: VMware mit Coriolis migrieren

Migrieren Sie VMware-VMs mit Coriolis nach STACKIT: Endpoints vorbereiten, Zieldisks synchronisieren, neue VMs bereitstellen und prüfen sowie Cutover und Übergabe abschließen.

Migration relocate vmware coriolis technical +1

Trail Steps

Transfer und Deployment verstehen
Migrationsobjekte unterscheiden
Zugriffe und Berechtigungen vorbereiten
Migrationsnetzwerke verbinden

+ 11 more steps

SAFE

Validieren oder Rollback

Migration design-and-mobilize use-cases relocate vmware coriolis acura cutover rollback

Ausführung einer VMware-Relocate-Welle

STACKIT

Führen Sie kontrollierte VMware-Relocate-Wellen nach STACKIT über vollständige Coriolis- oder Hystax-Acura-Pfade aus, mit Testmigration, Cutover, Validierung und Rollback.

Cloud Framework VMware Relocate Source Readiness Seite öffnen Cloud Framework STACKIT VM Target Sizing and Storage Selection Seite öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Zweck

Verwenden Sie dieses Runbook, um eine freigegebene VMware-Relocate-Welle nach STACKIT auszuführen. Es enthält zwei vollständige Tool-Pfade: Cloudbase Coriolis und Hystax Acura. Wählen Sie für die gesamte Welle genau einen Pfad und behalten Sie dasselbe Tool, dieselben Inventar-Kennungen, Mappings und Nachweise durch Testmigration und finalen Cutover bei.

Das Runbook geht davon aus, dass Anwendungen VM-basiert bleiben. Architekturmodernisierung, Datenbank-Replatforming und Applikations-Refactoring erfordern separate Pläne und Abnahmekriterien.

Eingangskriterien

Starten Sie die Replikation erst, wenn alle Eingangskriterien erfüllt sind:

Der Wellenumfang und die Abhängigkeitsgruppen sind eingefroren und jede VM hat eine stabile Quellkennung.
Die VMware-Quellbereitschaft, tool-spezifische Voraussetzungen und Wiederherstellungspunkte sind verifiziert.
Ziel-Maschinentypen, Volumes, Performance-Klassen, Netzwerke, Adressen, Security Groups und Platzierung sind freigegeben und innerhalb der Quoten verfügbar.
Anwendungsseitige Konsistenz, Testfälle, Wartungsfenster, erwartete Downtime und maximale Cutover-Dauer sind dokumentiert.
Source Freeze, Traffic Switch, Monitoring-Aktivierung und Rollback-Aktionen haben benannte technische Owner.
Der Quellaufbewahrungszeitraum und die Befugnis zum Löschen der Quell-VMs sind vor dem Cutover definiert.

Wellen-Steuerungsprotokoll

Legen Sie ein versionskontrolliertes Steuerungsprotokoll für die Welle an. Es enthält:

Source- und Target-Mappings für VM, Disk, Netzwerk, Adresse und Security Group;
gewähltes Tool sowie Appliance- oder Service-Version;
Start der Erstkopie, letzte erfolgreiche Delta-Synchronisation und gemessenen Replikations-Lag;
geordnete Shutdown- und Startup-Prozeduren der Anwendung;
technische und funktionale Testfälle mit objektiven Pass-Kriterien;
Cutover-Zeitplan, Checkpoints, Hold Points und Entscheidungsbefugnis;
Rollback-Trigger, letzte sichere Entscheidungszeit, Methode zur Datenabstimmung und Quellaufbewahrung;
Links zu Logs, Screenshots, Checksummen, Testergebnissen und Freigaben.

Führen Sie das Verfahren zuerst mit einem risikoarmen Piloten aus, der die vorgesehenen Muster für Betriebssystem, Disk, Netzwerk und Anwendung repräsentiert. Überführen Sie das Runbook erst dann in größere Wellen, wenn Pilot-Erkenntnisse eingearbeitet wurden.

Coriolis-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Cloudbase Coriolis das freigegebene Migrationstool ist.

Coriolis auf STACKIT bereitstellen

Führen Sie den Coriolis STACKIT Installer Dry Run und den Cloud Check gegen das freigegebene Projekt, die Region, den Maschinentyp, die Storage-Performance-Klasse sowie die Netzwerk-, DNS- und TLS-Konfiguration aus.
Stellen Sie die lizenzierte Appliance bereit, speichern Sie ihr strukturiertes Ergebnis und erzeugte Zugangsdaten sicher und führen Sie den Installer erneut aus, um die Wiederverwendung der vorgesehenen Ressourcen zu bestätigen.
Verifizieren Sie Appliance-Backup, administrativen Zugriff, TLS, Zeitsynchronisation, Monitoring, Quoten sowie die Migrations-Datenpfade, die nicht von der HTTPS-Benutzeroberfläche abgedeckt sind.

Cloud Framework Cloudbase Coriolis Seite öffnen Cloud Framework Coriolis STACKIT Installer Stellt die Coriolis-Appliance auf STACKIT bereit und konfiguriert sie vor Endpoint- und Migrations-Setup. Seite öffnen

Endpoints und Minion-Pools konfigurieren

Erstellen Sie den VMware-Source-Endpoint und den STACKIT-Destination-Endpoint mit dedizierten Zugangsdaten. Testen Sie Authentifizierung, Zertifikatsvertrauen, Inventar-Erkennung und API-Zugriff unabhängig voneinander.
Konfigurieren Sie die Source- und Destination-Minion-Pools, die Coriolis-Operationen ausführen. Verifizieren Sie Worker-Zustand, Kapazität, Concurrency-Grenzen, Routing, Namensauflösung und Zugriff auf beide Endpoints.
Bestätigen Sie, dass ein Worker jeden benötigten Management- und Data-Transfer-Service erreichen kann. Browser-Zugriff auf die Coriolis-Appliance allein belegt keine Endpoint-zu-Endpoint- Transfer-Bereitschaft.
Dokumentieren Sie Endpoint- und Minion-Pool-Identitäten sowie Versionen im Wellen-Steuerungsprotokoll, damit Wiederholungen und Cutover dieselbe Ausführungstopologie verwenden.

Coriolis Transfer entwerfen und ausführen

Erstellen Sie pro freigegebener VM oder Konsistenzgruppe genau eine Migrations-Transfer-Definition. Wählen Sie die Quellinstanz und lösen Sie jede Source-Disk und jedes Netzwerk auf das freigegebene STACKIT-Zieldesign auf.
Bestätigen Sie Coriolis-Gastunterstützung und das OS-Morphing-Verhalten. Fügen Sie erforderliche Remediation für Bootloader, Storage-Treiber, Netzwerk oder Cloud-Initialisierung im Steuerungsprotokoll hinzu.
Starten Sie die erste Transfer-Ausführung, während der Quell-Workload aktiv bleibt. Überwachen Sie Source-Snapshots, Worker-Zustand, übertragene Bytes, Durchsatz, Zielkapazität und Fehler.
Führen Sie weitere Transfer-Ausführungen aus, um geänderte Disks zu synchronisieren. Wiederholen Sie, bis die gemessene Delta-Dauer in das Cutover-Fenster passt, und sichern Sie danach die erfolgreiche Ausführungs-ID samt Nachweisen.

Coriolis Deployment testen

Erstellen Sie eine Deployment-Definition aus dem freigegebenen Transfer und mappen Sie Ziel-Maschinentyp, Boot- und Daten-Volumes, Netzwerke, Adressen, Security Groups und Deployment-Optionen.
Führen Sie eine Deployment-Ausführung in ein isoliertes Zielnetzwerk aus, ohne Produktionsverkehr umzuschalten.
Verifizieren Sie Boot, Disk-Erkennung, Dateisystem-Integrität, NIC-Benennung, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent. Aktivieren Sie den Agent Service einmalig für das Zielprojekt, bevor Sie Agent-Befehle verwenden. Dies ist von der Installation und Bereitstellung des Agents auf einzelnen Servern getrennt. Starten Sie Abhängigkeiten und die Anwendung in der freigegebenen Reihenfolge.
Führen Sie technische und funktionale Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services. Protokollieren Sie Defekte und Zeitwerte und löschen oder isolieren Sie danach die Test-VM vor einer weiteren Generalprobe.
Korrigieren Sie Transfer-Mapping, Deployment-Definition oder Guest-Remediation und wiederholen Sie Transfer- und Deployment-Ausführungen, bis alle verpflichtenden Tests bestanden sind.

Cutover mit Coriolis

Bestätigen Sie am Cutover-Start-Gate die letzte erfolgreiche Transfer-Ausführung, den aktuellen Source-Zustand, Zielkapazität, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, führen Sie die finale Transfer-Ausführung aus und verifizieren Sie deren Abschluss, den Zustand der übertragenen Disks und Konsistenznachweise.
Führen Sie aus diesem Transfer die produktive Deployment-Ausführung aus. Wenden Sie nur die freigegebenen produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Hystax-Acura-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Hystax Acura das freigegebene Migrationstool ist.

Hystax Acura und Quelle vorbereiten

Stellen Sie die mandantenisolierten Acura-Komponenten gemäß der freigegebenen STACKIT-Zielarchitektur bereit und lizenzieren Sie sie. Verifizieren Sie Administrationszugriff, Backup, Zeitsynchronisation, Monitoring, Ziel-Storage und Ziel-API-Zugriff.
Registrieren Sie VMware-Quelle und STACKIT-Ziel mit dedizierten Zugangsdaten und validieren Sie die dokumentierten Management- und Data-Transfer-Pfade.
Stellen Sie die für die ausgewählte VMware-Integration erforderlichen Hystax-Replikationsagenten bereit und verifizieren Sie sie. Bestätigen Sie VMware Tools, Changed Block Tracking, Snapshot-Sicherheit, Datastore-Headroom und erforderliche vCenter- oder ESXi-Konnektivität, bevor Sie eine VM schützen.
Frieren Sie die Quell-VM-Kennungen und Ziel-Mappings ein, die von der Migrationswelle verwendet werden.

Cloud Framework Hystax Acura Live Migration Seite öffnen

Acura-Replikation starten und Zielzustand speichern

Starten Sie die Hintergrundreplikation für freigegebene Anwendungs-VMs, deren Disks und benötigte Metadaten. Überwachen Sie Source-Snapshots, Agent-Zustand, Durchsatz, Datastore-Wachstum und Fehler.
Verifizieren Sie, dass replizierte Daten als erwartete Volumes und Snapshots in der Ziel-Cloud gespeichert werden und die Aufbewahrung die Zielquote nicht ausschöpft.
Lassen Sie Voll- und inkrementelle Replikate laufen, bis Replikations-Lag und das erwartete finale Delta in das Cutover-Fenster passen.
Beheben Sie Agent-, Snapshot-, CBT-, Kapazitäts- oder Konnektivitätsfehler, bevor ein Wiederherstellungspunkt akzeptiert wird.

Acura-Migrationsplan erstellen

Erstellen Sie den Migrationsplan aus den freigegebenen Mappings für VM, Disk, Netzwerk, Maschinentyp, Adresse und Security Group.
Kodieren Sie Abhängigkeitsreihenfolge und Application-Launch-Sequenz im Orchestrierungsplan. Halten Sie DNS, Load-Balancer und weitere Produktions-Traffic-Switches im Wellen-Steuerungsprotokoll fest.
Prüfen Sie den Plan gegen das eingefrorene Zieldesign und dokumentieren Sie die für die Generalprobe ausgewählte Version.

Hystax-Acura-Migration testen

Starten Sie aus dem ausgewählten Wiederherstellungspunkt eine Testmigration in einem isolierten STACKIT-Netzwerk, ohne Produktionsverkehr umzuleiten. Acura kann diese Generalprobe wiederholen, ohne die Replikation zu stoppen.
Verifizieren Sie orchestrierte Startreihenfolge, Boot, Disks, Dateisysteme, NICs, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent.
Führen Sie die freigegebenen funktionalen und Performance-Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services aus dem isolierten Ziel.
Dokumentieren Sie Defekte und Zeitwerte, räumen Sie die Testumgebung auf oder isolieren Sie sie, aktualisieren Sie den Migrationsplan und wiederholen Sie die Testmigration, bis alle verpflichtenden Prüfungen bestanden sind.

Cutover mit Hystax Acura

Bestätigen Sie am Cutover-Start-Gate das letzte gesunde Replikat, den aktuellen Source-Zustand, Zielkapazität, den freigegebenen Migrationsplan, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, vervollständigen Sie die finale inkrementelle Replikation und verifizieren Sie den resultierenden Wiederherstellungspunkt.
Führen Sie den finalen Cutover über den freigegebenen Orchestrierungsplan aus und wenden Sie anschließend die geplanten produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Gemeinsames Validierungs- und Rollback-Gate

Starten Sie die Validierung, sobald die Zielinstanzen erreichbar sind. Erfassen Sie Zeitstempel, weil das verbleibende Rollback-Fenster eine technische Randbedingung ist.

Validieren Sie den VM-Zustand: Boot, Konsole, Disks, Dateisysteme, Mounts, Netzwerkschnittstellen, Routen, DNS, NTP, Zertifikate, Server Agent und erforderliche Betriebssystem-Services.
Validieren Sie den Datenzustand: erwarteter Wiederherstellungspunkt, Datei- oder Datenbankkonsistenz, Checksummen oder Record Counts sowie keine unbeabsichtigten Schreibzugriffe auf der Quelle.
Starten Sie Abhängigkeiten und Anwendungen in Reihenfolge und führen Sie dann Health Checks, synthetische Transaktionen, Integrationen, geplante Jobs und verpflichtende Geschäftstests aus.
Bestätigen Sie Logs, Metriken, Alerts, Backups, administrativen Zugriff und Security Controls in der Zielumgebung.
Vergleichen Sie CPU, Memory, Disk-Latenz, IOPS, Durchsatz, Netzwerkverhalten, Applikationslatenz und Fehlerraten mit den freigegebenen Abnahmeschwellen.
Treffen Sie an der Entscheidungs-Deadline entweder die Zielabnahme oder führen Sie den dokumentierten Rollback aus. Weichen Sie nicht in ein ungebundenes Troubleshooting-Fenster aus.

Rollback ist nur sicher, solange die Data Ownership eindeutig bleibt. Wenn das Ziel bereits Schreibzugriffe akzeptiert hat, stoppen Sie die Zielverarbeitung und führen Sie die freigegebene Rücksynchronisations- oder Abstimmungsmethode aus, bevor die Quelle neu gestartet wird. Schalten Sie nie beide Kopien mit Produktionskonnektivität gleichzeitig ein, sofern das Anwendungsdesign keine gleichzeitigen Schreiber explizit unterstützt.

Abschluss und Quellaufbewahrung

Die Welle ist technisch abgeschlossen, wenn:

verpflichtende technische und funktionale Prüfungen bestanden sind und das Ziel das deklarierte System of Record ist;
Monitoring- und Backup-Nachweise aus STACKIT vorliegen;
Defekte, temporäre Ausnahmen und Folgeaktionen Owner und Fristen haben;
tatsächliche Dauern für Replikation, Freeze, Cutover und Validierung für die nächste Welle erfasst sind;
Quell-VMs für den freigegebenen Aufbewahrungszeitraum ausgeschaltet und zugriffskontrolliert bleiben;
das Löschen der Quelle erst nach Ablauf der Aufbewahrung, Wiederherstellungsbestätigung und expliziter Freigabe erfolgt;
das initiale Ziel-Sizing mit seinen Messwerten und Abnahmeschwellen an Optimize übergeben ist.

Primäre Referenzen

Externe Quelle cloudbase.it Cloudbase Coriolis Externe Seite öffnen Führt von der Route weg Externe Quelle hystax.com Hystax Acura Live Migration Externe Seite öffnen Führt von der Route weg

Zweck

Verwenden Sie dieses Runbook, um eine freigegebene VMware-Relocate-Welle nach STACKIT auszuführen. Es enthält zwei vollständige Tool-Pfade: Cloudbase Coriolis und Hystax Acura. Wählen Sie für die gesamte Welle genau einen Pfad und behalten Sie dasselbe Tool, dieselben Inventar-Kennungen, Mappings und Nachweise durch Testmigration und finalen Cutover bei.

Das Runbook geht davon aus, dass Anwendungen VM-basiert bleiben. Architekturmodernisierung, Datenbank-Replatforming und Applikations-Refactoring erfordern separate Pläne und Abnahmekriterien.

Eingangskriterien

Starten Sie die Replikation erst, wenn alle Eingangskriterien erfüllt sind:

Der Wellenumfang und die Abhängigkeitsgruppen sind eingefroren und jede VM hat eine stabile Quellkennung.
Die VMware-Quellbereitschaft, tool-spezifische Voraussetzungen und Wiederherstellungspunkte sind verifiziert.
Ziel-Maschinentypen, Volumes, Performance-Klassen, Netzwerke, Adressen, Security Groups und Platzierung sind freigegeben und innerhalb der Quoten verfügbar.
Anwendungsseitige Konsistenz, Testfälle, Wartungsfenster, erwartete Downtime und maximale Cutover-Dauer sind dokumentiert.
Source Freeze, Traffic Switch, Monitoring-Aktivierung und Rollback-Aktionen haben benannte technische Owner.
Der Quellaufbewahrungszeitraum und die Befugnis zum Löschen der Quell-VMs sind vor dem Cutover definiert.

Cloud Framework VMware Relocate Source Readiness Seite öffnen Cloud Framework STACKIT VM Target Sizing and Storage Selection Seite öffnen

Wellen-Steuerungsprotokoll

Legen Sie ein versionskontrolliertes Steuerungsprotokoll für die Welle an. Es enthält:

Source- und Target-Mappings für VM, Disk, Netzwerk, Adresse und Security Group;
gewähltes Tool sowie Appliance- oder Service-Version;
Start der Erstkopie, letzte erfolgreiche Delta-Synchronisation und gemessenen Replikations-Lag;
geordnete Shutdown- und Startup-Prozeduren der Anwendung;
technische und funktionale Testfälle mit objektiven Pass-Kriterien;
Cutover-Zeitplan, Checkpoints, Hold Points und Entscheidungsbefugnis;
Rollback-Trigger, letzte sichere Entscheidungszeit, Methode zur Datenabstimmung und Quellaufbewahrung;
Links zu Logs, Screenshots, Checksummen, Testergebnissen und Freigaben.

Führen Sie das Verfahren zuerst mit einem risikoarmen Piloten aus, der die vorgesehenen Muster für Betriebssystem, Disk, Netzwerk und Anwendung repräsentiert. Überführen Sie das Runbook erst dann in größere Wellen, wenn Pilot-Erkenntnisse eingearbeitet wurden.

Coriolis-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Cloudbase Coriolis das freigegebene Migrationstool ist.

Coriolis auf STACKIT bereitstellen

Führen Sie den Coriolis STACKIT Installer Dry Run und den Cloud Check gegen das freigegebene Projekt, die Region, den Maschinentyp, die Storage-Performance-Klasse sowie die Netzwerk-, DNS- und TLS-Konfiguration aus.
Stellen Sie die lizenzierte Appliance bereit, speichern Sie ihr strukturiertes Ergebnis und erzeugte Zugangsdaten sicher und führen Sie den Installer erneut aus, um die Wiederverwendung der vorgesehenen Ressourcen zu bestätigen.
Verifizieren Sie Appliance-Backup, administrativen Zugriff, TLS, Zeitsynchronisation, Monitoring, Quoten sowie die Migrations-Datenpfade, die nicht von der HTTPS-Benutzeroberfläche abgedeckt sind.

Cloud Framework Cloudbase Coriolis Seite öffnen Cloud Framework Coriolis STACKIT Installer Stellt die Coriolis-Appliance auf STACKIT bereit und konfiguriert sie vor Endpoint- und Migrations-Setup. Seite öffnen

Endpoints und Minion-Pools konfigurieren

Erstellen Sie den VMware-Source-Endpoint und den STACKIT-Destination-Endpoint mit dedizierten Zugangsdaten. Testen Sie Authentifizierung, Zertifikatsvertrauen, Inventar-Erkennung und API-Zugriff unabhängig voneinander.
Konfigurieren Sie die Source- und Destination-Minion-Pools, die Coriolis-Operationen ausführen. Verifizieren Sie Worker-Zustand, Kapazität, Concurrency-Grenzen, Routing, Namensauflösung und Zugriff auf beide Endpoints.
Bestätigen Sie, dass ein Worker jeden benötigten Management- und Data-Transfer-Service erreichen kann. Browser-Zugriff auf die Coriolis-Appliance allein belegt keine Endpoint-zu-Endpoint- Transfer-Bereitschaft.
Dokumentieren Sie Endpoint- und Minion-Pool-Identitäten sowie Versionen im Wellen-Steuerungsprotokoll, damit Wiederholungen und Cutover dieselbe Ausführungstopologie verwenden.

Coriolis Transfer entwerfen und ausführen

Erstellen Sie pro freigegebener VM oder Konsistenzgruppe genau eine Migrations-Transfer-Definition. Wählen Sie die Quellinstanz und lösen Sie jede Source-Disk und jedes Netzwerk auf das freigegebene STACKIT-Zieldesign auf.
Bestätigen Sie Coriolis-Gastunterstützung und das OS-Morphing-Verhalten. Fügen Sie erforderliche Remediation für Bootloader, Storage-Treiber, Netzwerk oder Cloud-Initialisierung im Steuerungsprotokoll hinzu.
Starten Sie die erste Transfer-Ausführung, während der Quell-Workload aktiv bleibt. Überwachen Sie Source-Snapshots, Worker-Zustand, übertragene Bytes, Durchsatz, Zielkapazität und Fehler.
Führen Sie weitere Transfer-Ausführungen aus, um geänderte Disks zu synchronisieren. Wiederholen Sie, bis die gemessene Delta-Dauer in das Cutover-Fenster passt, und sichern Sie danach die erfolgreiche Ausführungs-ID samt Nachweisen.

Coriolis Deployment testen

Erstellen Sie eine Deployment-Definition aus dem freigegebenen Transfer und mappen Sie Ziel-Maschinentyp, Boot- und Daten-Volumes, Netzwerke, Adressen, Security Groups und Deployment-Optionen.
Führen Sie eine Deployment-Ausführung in ein isoliertes Zielnetzwerk aus, ohne Produktionsverkehr umzuschalten.
Verifizieren Sie Boot, Disk-Erkennung, Dateisystem-Integrität, NIC-Benennung, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent. Aktivieren Sie den Agent Service einmalig für das Zielprojekt, bevor Sie Agent-Befehle verwenden. Dies ist von der Installation und Bereitstellung des Agents auf einzelnen Servern getrennt. Starten Sie Abhängigkeiten und die Anwendung in der freigegebenen Reihenfolge.
Führen Sie technische und funktionale Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services. Protokollieren Sie Defekte und Zeitwerte und löschen oder isolieren Sie danach die Test-VM vor einer weiteren Generalprobe.
Korrigieren Sie Transfer-Mapping, Deployment-Definition oder Guest-Remediation und wiederholen Sie Transfer- und Deployment-Ausführungen, bis alle verpflichtenden Tests bestanden sind.

Cutover mit Coriolis

Bestätigen Sie am Cutover-Start-Gate die letzte erfolgreiche Transfer-Ausführung, den aktuellen Source-Zustand, Zielkapazität, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, führen Sie die finale Transfer-Ausführung aus und verifizieren Sie deren Abschluss, den Zustand der übertragenen Disks und Konsistenznachweise.
Führen Sie aus diesem Transfer die produktive Deployment-Ausführung aus. Wenden Sie nur die freigegebenen produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Hystax-Acura-Ausführungspfad

Wählen Sie diesen vollständigen Pfad, wenn Hystax Acura das freigegebene Migrationstool ist.

Hystax Acura und Quelle vorbereiten

Stellen Sie die mandantenisolierten Acura-Komponenten gemäß der freigegebenen STACKIT-Zielarchitektur bereit und lizenzieren Sie sie. Verifizieren Sie Administrationszugriff, Backup, Zeitsynchronisation, Monitoring, Ziel-Storage und Ziel-API-Zugriff.
Registrieren Sie VMware-Quelle und STACKIT-Ziel mit dedizierten Zugangsdaten und validieren Sie die dokumentierten Management- und Data-Transfer-Pfade.
Stellen Sie die für die ausgewählte VMware-Integration erforderlichen Hystax-Replikationsagenten bereit und verifizieren Sie sie. Bestätigen Sie VMware Tools, Changed Block Tracking, Snapshot-Sicherheit, Datastore-Headroom und erforderliche vCenter- oder ESXi-Konnektivität, bevor Sie eine VM schützen.
Frieren Sie die Quell-VM-Kennungen und Ziel-Mappings ein, die von der Migrationswelle verwendet werden.

Cloud Framework Hystax Acura Live Migration Seite öffnen

Acura-Replikation starten und Zielzustand speichern

Starten Sie die Hintergrundreplikation für freigegebene Anwendungs-VMs, deren Disks und benötigte Metadaten. Überwachen Sie Source-Snapshots, Agent-Zustand, Durchsatz, Datastore-Wachstum und Fehler.
Verifizieren Sie, dass replizierte Daten als erwartete Volumes und Snapshots in der Ziel-Cloud gespeichert werden und die Aufbewahrung die Zielquote nicht ausschöpft.
Lassen Sie Voll- und inkrementelle Replikate laufen, bis Replikations-Lag und das erwartete finale Delta in das Cutover-Fenster passen.
Beheben Sie Agent-, Snapshot-, CBT-, Kapazitäts- oder Konnektivitätsfehler, bevor ein Wiederherstellungspunkt akzeptiert wird.

Acura-Migrationsplan erstellen

Erstellen Sie den Migrationsplan aus den freigegebenen Mappings für VM, Disk, Netzwerk, Maschinentyp, Adresse und Security Group.
Kodieren Sie Abhängigkeitsreihenfolge und Application-Launch-Sequenz im Orchestrierungsplan. Halten Sie DNS, Load-Balancer und weitere Produktions-Traffic-Switches im Wellen-Steuerungsprotokoll fest.
Prüfen Sie den Plan gegen das eingefrorene Zieldesign und dokumentieren Sie die für die Generalprobe ausgewählte Version.

Hystax-Acura-Migration testen

Starten Sie aus dem ausgewählten Wiederherstellungspunkt eine Testmigration in einem isolierten STACKIT-Netzwerk, ohne Produktionsverkehr umzuleiten. Acura kann diese Generalprobe wiederholen, ohne die Replikation zu stoppen.
Verifizieren Sie orchestrierte Startreihenfolge, Boot, Disks, Dateisysteme, NICs, Routen, DNS, NTP, Zertifikate und den Zustand des STACKIT Server Agent.
Führen Sie die freigegebenen funktionalen und Performance-Tests aus und verhindern Sie dabei Produktionsnachrichten, Jobs und Schreibzugriffe auf Shared Services aus dem isolierten Ziel.
Dokumentieren Sie Defekte und Zeitwerte, räumen Sie die Testumgebung auf oder isolieren Sie sie, aktualisieren Sie den Migrationsplan und wiederholen Sie die Testmigration, bis alle verpflichtenden Prüfungen bestanden sind.

Cutover mit Hystax Acura

Bestätigen Sie am Cutover-Start-Gate das letzte gesunde Replikat, den aktuellen Source-Zustand, Zielkapazität, den freigegebenen Migrationsplan, Entscheidungs-Owner und die Rollback-Deadline.
Setzen Sie den Write Freeze der Anwendung um und stoppen Sie Services in der freigegebenen Abhängigkeitsreihenfolge.
Fahren Sie Quell-VMs dort herunter, wo es nötig ist, um neue Schreibzugriffe zu verhindern, vervollständigen Sie die finale inkrementelle Replikation und verifizieren Sie den resultierenden Wiederherstellungspunkt.
Führen Sie den finalen Cutover über den freigegebenen Orchestrierungsplan aus und wenden Sie anschließend die geplanten produktiven Adressen, Routen, Security Groups sowie DNS- und Load-Balancer-Änderungen an.
Fahren Sie mit dem gemeinsamen Validierungs- und Rollback-Gate fort. Halten Sie die Quell-VMs ausgeschaltet und vor automatischem Neustart geschützt.

Gemeinsames Validierungs- und Rollback-Gate

Starten Sie die Validierung, sobald die Zielinstanzen erreichbar sind. Erfassen Sie Zeitstempel, weil das verbleibende Rollback-Fenster eine technische Randbedingung ist.

Validieren Sie den VM-Zustand: Boot, Konsole, Disks, Dateisysteme, Mounts, Netzwerkschnittstellen, Routen, DNS, NTP, Zertifikate, Server Agent und erforderliche Betriebssystem-Services.
Validieren Sie den Datenzustand: erwarteter Wiederherstellungspunkt, Datei- oder Datenbankkonsistenz, Checksummen oder Record Counts sowie keine unbeabsichtigten Schreibzugriffe auf der Quelle.
Starten Sie Abhängigkeiten und Anwendungen in Reihenfolge und führen Sie dann Health Checks, synthetische Transaktionen, Integrationen, geplante Jobs und verpflichtende Geschäftstests aus.
Bestätigen Sie Logs, Metriken, Alerts, Backups, administrativen Zugriff und Security Controls in der Zielumgebung.
Vergleichen Sie CPU, Memory, Disk-Latenz, IOPS, Durchsatz, Netzwerkverhalten, Applikationslatenz und Fehlerraten mit den freigegebenen Abnahmeschwellen.
Treffen Sie an der Entscheidungs-Deadline entweder die Zielabnahme oder führen Sie den dokumentierten Rollback aus. Weichen Sie nicht in ein ungebundenes Troubleshooting-Fenster aus.

Rollback ist nur sicher, solange die Data Ownership eindeutig bleibt. Wenn das Ziel bereits Schreibzugriffe akzeptiert hat, stoppen Sie die Zielverarbeitung und führen Sie die freigegebene Rücksynchronisations- oder Abstimmungsmethode aus, bevor die Quelle neu gestartet wird. Schalten Sie nie beide Kopien mit Produktionskonnektivität gleichzeitig ein, sofern das Anwendungsdesign keine gleichzeitigen Schreiber explizit unterstützt.

Abschluss und Quellaufbewahrung

Die Welle ist technisch abgeschlossen, wenn:

verpflichtende technische und funktionale Prüfungen bestanden sind und das Ziel das deklarierte System of Record ist;
Monitoring- und Backup-Nachweise aus STACKIT vorliegen;
Defekte, temporäre Ausnahmen und Folgeaktionen Owner und Fristen haben;
tatsächliche Dauern für Replikation, Freeze, Cutover und Validierung für die nächste Welle erfasst sind;
Quell-VMs für den freigegebenen Aufbewahrungszeitraum ausgeschaltet und zugriffskontrolliert bleiben;
das Löschen der Quelle erst nach Ablauf der Aufbewahrung, Wiederherstellungsbestätigung und expliziter Freigabe erfolgt;
das initiale Ziel-Sizing mit seinen Messwerten und Abnahmeschwellen an Optimize übergeben ist.

Primäre Referenzen

Externe Quelle cloudbase.it Cloudbase Coriolis Externe Seite öffnen Führt von der Route weg Externe Quelle hystax.com Hystax Acura Live Migration Externe Seite öffnen Führt von der Route weg

OPS

Optimize

Sammeln Sie nach akzeptiertem Cutover repräsentative STACKIT-Laufzeitnachweise und überführen Sie Erkenntnisse zu Performance, Stabilität und Kosten in kontrollierte Infrastruktur-Änderungen mit Rollback-Checkpoints.

In 7 Trails

Überblick: Optimize-Modul

Optimize startet, sobald Workloads auf STACKIT laufen und reale Daten aus dem Betrieb vorliegen. Das Modul überführt Beobachtungen aus dem Betrieb in messbare Verbesserungen für Performance, Stabilität und Wirtschaftlichkeit.

Optimize ist keine einmalige Aufgabe, sondern ein iterativer Zyklus, der sich mit früher Stabilisierung und Unterstützung direkt nach dem Cutover überschneiden kann.

Warum Optimize nach dem Cutover liegt

Viele Entscheidungen zu Rightsizing und Tuning sind erst unter echter Last belastbar. Nach dem Cutover lassen sich Annahmen mit Daten aus dem Betrieb validieren und präzisieren.

Optimize-Zyklus

Laufzeitdaten erfassen: Auslastung, Latenz, Fehlerquoten, Durchsatz und Kostentreiber.
Engpässe und Verschwendungsmuster auf Workload-, Plattform- und Datenebene identifizieren.
Maßnahmen nach Business-Effekt, Risikoreduktion und FinOps-Nutzen priorisieren.
Tuning-Änderungen in kontrollierten Inkrementen umsetzen.
Ergebnisse gegen SLO-, Stabilitäts- und Kostenziele validieren.
Erkenntnisse in Folgewellen und Betriebsstandards zurückführen.

Typische Bereiche

Rightsizing: Compute-, Storage- und Netzwerkressourcen an reale Last anpassen.
Performance-Tuning: Latenz und Durchsatz durch Konfiguration, Skalierung und Architekturmaßnahmen verbessern.
Reliability-Hardening: Incident-Häufigkeit durch Resilienz-, Monitoring- und Fehlerbehandlungsmaßnahmen reduzieren.
FinOps-Steuerung: Kostentransparenz verbessern, Verschwendung abbauen und Run-Rate optimieren.

Von der Theorie zur Umsetzung

Optimierungsentscheidungen sollten auf Laufzeitdaten basieren, nicht auf Annahmen. Für die praktische Umsetzung werden Workload-Telemetrie, Alerting und kontrollierte Infrastrukturänderungen kombiniert.

Managed-Observability-Basis: Mit STACKIT Observability Metriken, Logs und Traces mit Grafana, Prometheus, Thanos, Loki und Tempo erfassen.
Erkennungslogik: Klare Schwellwerte und Beobachtungsfenster für Unterauslastung und Überlast definieren.
Umsetzungspfad: Rightsizing über IaC-Änderungen (zum Beispiel VM-Flavors) mit Rollback-Checkpoints umsetzen.
Validierungsschleife: Nach jedem Tuning-Inkrement SLO, Fehlerquote und Laufkosten erneut messen.

Dimensioniert verlagerte STACKIT VMs anhand repräsentativer Telemetrie neu, mit kontrollierten Machine-Type-Änderungen, Storage-Migration, Validierung und Rollback.

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

Migration

Runbook

Replatform-Optimierungsdimensionen

Für Replatform-Workloads auf Kubernetes umfasst Optimierung mehrere Ebenen und sollte als gemeinsamer Regelkreis gesteuert werden.

Pod-Skalierung: HPA nutzen, um die Replikazahl anhand von Last mit klaren Min-/Max-Grenzen anzupassen.
Node-Pool-Skalierung: Ausreichend Cluster-Headroom sicherstellen und den Maschinentyp (Flavor) für CPU-/Memory-Dichteanforderungen abstimmen.
Ingress-Skalierung: Den Serviceplan des Load Balancers neu bewerten, wenn Ingress-Durchsatz oder Verbindungsverhalten zum Engpass werden.
Storage-Rightsizing: Storage-Klassen nach Performance-Anforderungen persistenter Workloads auswählen.
Validierungsdisziplin: Nach jeder inkrementellen Tuning-Änderung Latenz, Fehlerquote und Kosten erneut prüfen.

Eingaben und Ergebnisse

Zentrale Eingaben

Cutover-Berichte, Incident-Trends, SLO-Messwerte, Telemetrie-Baselines und Kostenberichte.

Ergebnisse

Priorisiertes Verbesserungs-Backlog, validierte Tuning-Änderungen und aktualisierte Betriebsstandards.

Governance-Effekt

Nachvollziehbare Trade-off-Entscheidungen zwischen Performance, Stabilität und Kosten.

Abgrenzung zu anderen Modulen

Optimize folgt auf die technische Umsetzung in Migrate.
Aktivitäten direkt nach dem Cutover können parallel laufen, die fachliche Verankerung erfolgt jedoch in der Run-Phase.
Umfassende Umbauten bleiben im Modul Refactor.

GOAL

Verlagerte VMs bedarfsgerecht dimensionieren

Migration migrate optimize relocate vm observability rightsizing block-storage

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

STACKIT

Dimensioniert verlagerte STACKIT VMs anhand repräsentativer Telemetrie neu, mit kontrollierten Machine-Type-Änderungen, Storage-Migration, Validierung und Rollback.