VM Application Landing Zone für Relocate

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.

1. Erstellen Sie getrennte Gruppen für Management des Migrationstools, Transfer-Traffic, Workload-Ingress und Workload-East-West-Abhängigkeiten, wenn ihre Lebenszyklen sich unterscheiden.
2. Erlauben Sie Administration nur aus freigegebenen Operator- oder Bastion-Bereichen.
3. 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.
4. Überführen Sie die Discovery-Abhängigkeitsmatrix in explizite Workload-Regeln; übernehmen Sie keinen breiten VMware-VLAN-Zugriff per Kopie.
5. Begrenzen Sie ausgehenden Traffic auf erforderliche Platform-Services, Repositories, DNS, Zeit, Telemetrie, Backup und Anwendungsabhängigkeiten.
6. Dokumentieren Sie Eigentümer, Zweck, Nachweis, Ablaufdatum und Rollback für jede temporäre Migrationsregel.
7. 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

1. 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.
2. 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.
3. Fügen Sie die Workload-Umgebung der Accelerator-landing_zones-Map hinzu und aktivieren Sie Corporate Networking, Secrets Manager und Observability nach Bedarf.
4. 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.
5. Erstellen und genehmigen Sie die Security Groups manuell aus der Abhängigkeitsmatrix und den gewählten Control- und Transfer-Pfaden des Migrationstools.
6. Übergeben Sie die freigegebene Projekt-ID, Netzwerk, DNS, Secrets Manager, Observability-Endpunkte, Security Groups, Quotas und Ziel-Mappings an das Coriolis- oder Acura-Runbook.
7. Lassen Sie das gewählte Tool nur seine erforderlichen Appliance-, Worker-, Server-, Volume-, Image- und Migrationsinhalte in die Application Landing Zone deployen.
8. 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