Eine VMware-Umgebung mit neun VMs, von Anfang bis Ende bewertet

Die Umgebung und was der Lauf daraus machte

Quelle: assessment.json, migration/technical-sequencing.md und terraform/README.md des Laufs. Dreizehn Ressourcen, dreizehn Einheiten, zwölf davon als Terraform entworfen.

Die Zahlen des Laufs

Die 105 nicht zugeordneten Eigenschaften stehen je Einheit in assessment.json; Beispiele sind Annotation, Ordner, Hardwareversion und die Adapterbezeichnung. Lesen Sie diese Liste, bevor Sie sich auf den Entwurf verlassen.

Den Webshop gruppieren und seine Betriebsreife lesen

Links die Anwendungsdatei, für diese Umgebung geschrieben. Sie nennt fünf der neun VMs als Webshop und hält RTO, RPO und tolerierbare Ausfallzeit fest. Rechts die Tabelle aus assurance/operational-readiness.md, die der Lauf für diese Anwendung gebaut hat.

applications:
  - id: webshop
    name: Webshop
    selectors:
      - vm.shop-web01
      - vm.shop-web02
      - vm.shop-app01
      - vm.shop-pg01
      - vm.shop-pg02
    environment: production
    owners:
      business: ecommerce
      technical: platform-team
    business_criticality: critical
    availability:
      rto: 4h
      rpo: 15m
      downtime_tolerance: 1h

| Topic | What the run knows | Context |
|---|---|---|
| Log target | customer requirement (not in the source) | none of the 5 units of the application is a log resource of the source |
| Alarm owner | customer requirement (not in the source) | technical owner the applications file names: platform-team (who owns the alarms is the customer's to state) |
| Backup job | customer requirement (not in the source) | no backup resource in the source; RPO 15m as the applications file writes it |
| Restore | customer requirement (not in the source) | RTO 4h as the applications file writes it |

• Vier VMs bleiben draußen

  Berichtsserver, Monitoring-VM, CRM und Vorlage nennt kein Selektor. Der Lauf leitet Zuständigkeiten nicht aus Namen ab.

• Werte werden übernommen, nicht erfunden

  RPO 15m und RTO 4h stehen so da, wie die Datei sie schreibt. Log-Ziel, Alarm-Verantwortlicher, Backup-Job und Restore bleiben als Kundenanforderung markiert, weil die Quelle dazu nichts sagt.

• Ein Backup ist eine Entscheidung

  Der Export enthält keine Backup-Ressource. Bei einem RPO von 15 Minuten für den Webshop bleibt das Backup-Design Aufgabe des Teams.

Drei der neun VMs und die Reihenfolge ihres Umzugs

Links die vInfo-Zeilen eines Webservers, des Datenbank-Primary und des alten CRM. Rechts die Wellentabellen aus migration/technical-sequencing.md.

VM,Powerstate,Template,CPUs,Memory,NICs,Disks,Provisioned MiB,In use MiB,Primary IP Address,DNS Name,Datacenter,Cluster,Host,Folder,Firmware,HW version,Path,Annotation,OS according to the configuration file,OS according to the VMware Tools,VM UUID
shop-web01,poweredOn,False,2,8192,1,1,61440,30720,10.50.10.11,,DC-Munich,CL-Prod,esx11,prod,bios,vmx-19,[ds-prod-01] shop-web01/shop-web01.vmx,"Storefront, nginx",Ubuntu Linux (64-bit),Ubuntu 22.04.4 LTS,4202-vm20-0001
shop-pg01,poweredOn,False,8,32768,1,2,614400,368640,10.50.30.31,,DC-Munich,CL-Prod,esx11,prod,bios,vmx-19,[ds-prod-01] shop-pg01/shop-pg01.vmx,PostgreSQL 15 primary,Debian GNU/Linux 12 (64-bit),Debian GNU/Linux 12,4202-vm20-0004
legacy-crm01,poweredOn,False,2,4096,1,1,51200,25600,10.50.20.99,,DC-Munich,CL-Prod,esx11,prod,bios,vmx-19,[ds-prod-01] legacy-crm01/legacy-crm01.vmx,"Old CRM, vendor gone",CentOS 7 (64-bit),CentOS Linux 7,4202-vm20-0008

## Wave 1 — 4 unit(s)

| Unit | Class | Target |
|---|---|---|
| `network.PG-Shop-App` | RECONFIGURE / MEDIUM | STACKIT network |
| `network.PG-Shop-DB` | RECONFIGURE / MEDIUM | STACKIT network |
| `network.PG-Shop-Mgmt` | RECONFIGURE / MEDIUM | STACKIT network |
| `network.PG-Shop-Web` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 2 — 9 unit(s)

| Unit | Class | Target |
|---|---|---|
| `vm.legacy-crm01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.shop-app01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.shop-mon01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.shop-pg01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.shop-pg02` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.shop-rep01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.shop-web01` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.shop-web02` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |
| `vm.tpl-ubuntu2204` | REPLATFORM / MEDIUM | STACKIT image |

• Erst die Netzwerke

  Welle 1 enthält die vier Netzwerke. Ein Server zieht erst um, wenn alle Einheiten fertig sind, von denen er abhängt.

• Parallel innerhalb einer Welle

  Die neun Einheiten der Welle 2 können, soweit die Abhängigkeiten es zulassen, parallel umziehen. Die Datei nennt die Wellen einen Ausgangspunkt für den Plan des Architekten, keinen Zeitplan.

• Cutover-Fakten werden nicht geraten

  Dieselbe Datei hat einen Abschnitt zum Cutover. Er nennt die Fakten, die der Scan festgestellt hat; für diese Umgebung nennt er keine DNS- oder Zertifikats-Einheit, daher kommt der Cutover-Zeitpunkt von den Anwendungsverantwortlichen.

Der Windows-Berichtsserver als Terraform

Links die zwei Disks von shop-rep01. Rechts Schnittstelle, Server und Daten-Volume mit Attach-Block, ohne die Review-Kommentare.

VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
shop-rep01,Hard disk 1,81920,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[ds-prod-01] shop-rep01/shop-rep01_0.vmdk,4202-vm20-0006
shop-rep01,Hard disk 2,204800,False,persistent,sharingNone,True,SCSI controller 1,noSharing,[ds-prod-01] shop-rep01/shop-rep01_1.vmdk,4202-vm20-0006

resource "stackit_network_interface" "vm_shop_rep01_nic1" {
  project_id = var.project_id
  network_id = stackit_network.network_PG_Shop_App.network_id
  ipv4       = "10.50.20.51"
}

resource "stackit_server" "vm_shop_rep01" {
  project_id        = var.project_id
  name              = "shop-rep01"
  machine_type      = var.vm_shop_rep01_machine_type
  availability_zone = var.availability_zone
  boot_volume = {
    source_type = "image"
    source_id   = var.vm_shop_rep01_image_id
    size        = 80
  }
  network_interfaces = [stackit_network_interface.vm_shop_rep01_nic1.network_interface_id]
}

resource "stackit_volume" "vm_shop_rep01_disk2" {
  project_id        = var.project_id
  name              = "shop-rep01-disk2"
  availability_zone = var.availability_zone
  size              = 200
  performance_class = var.vmware_volume_performance_class
}

resource "stackit_server_volume_attach" "vm_shop_rep01_disk2" {
  project_id = var.project_id
  server_id  = stackit_server.vm_shop_rep01.server_id
  volume_id  = stackit_volume.vm_shop_rep01_disk2.volume_id
}

• Größen übernommen

  Die Systemdisk mit 80 GiB ist das Boot-Volume, die Disk mit 200 GiB ein Daten-Volume. Die Adresse 10.50.20.51 steht an der Schnittstelle.

• Ihnen überlassen

  Image-ID und Maschinentyp sind Variablen. Wählen Sie für Windows einen Maschinentyp, den die STACKIT-Tabelle als Windows-Server-kompatibel markiert, und entscheiden Sie den Lizenzweg; beides beschreibt der Windows-Leitfaden.

Die verbleibende Arbeit nach Verantwortlichen

Aus migration/work-packages.csv und execution/manual/actions.md. Jedes Paket kann sofort begonnen werden; keines wartet auf eine Entscheidung.

Die eine Anfrage beantworten, die den Entwurf blockiert

Der erste Lauf listete fünf offene Anfragen, und eine davon, die Zielregion, blockierte den Entwurf. Links die Antwort, eingetragen in eine als answers.yaml gespeicherte Kopie von review/inputs.yaml. Rechts die Zeile „Decisions“ des zweiten Laufs, gestartet mit dem Schalter --inputs.

  - id: INP-TSE-1eaf5b60fa62
    kind: TARGET_SELECTION
    topic: target.region
    scope:
      profile: default
    # options: eu01 | eu02
    value: eu01
    # explanation: why you chose this (optional; remove the # to write it)
    answered_by: CUSTOMER_ARCHITECT
    answered_at: "2026-11-04"   # YYYY-MM-DD

Decisions     13 units to review (136 critical settings) · no decision holds a plan step · Inputs: 0 design inputs wait · 4 open requests (0 block the draft, 4 are preferences this build cannot apply — inputs-template.yaml, NOT APPLICABLE IN THIS BUILD, says where to set each)

• Die Zählung ändert sich

  Die offenen Anfragen sinken von fünf auf vier, die blockierende von eins auf keine. Die Konsole meldet eine angewendete Antwort, keine veraltete, keine ungültige.

• Der Entwurfstext nicht

  Ein Vergleich der terraform-Ordner beider Läufe zeigt nur einen Unterschied in der Lauf-ID der README. Die Region stand in den Variablen schon auf eu01; die Antwort bestätigte sie also, statt etwas zu ändern.

• Vier Präferenzen warten

  Projekt, Observability, öffentlicher Ingress und Egress werden als Präferenzen geführt, die dieser Build nicht anwenden kann. Die Antwortdatei nennt, wo sie stattdessen gesetzt werden: das Projekt über die Variable project_id, Ingress und Egress in der Datei der Zielumgebung, Observability-Instanzen direkt im STACKIT-Projekt.

Entscheidungen, die den Plan geprägt haben

• Was zum Webshop zählt

  Fünf VMs sind die Anwendung. Berichtsserver, Monitoring und CRM blieben bewusst draußen; jedes braucht einen eigenen Verantwortlichen und ein eigenes RPO.

• Datenbank: Rehost oder Managed Service

  Das Paar ist als Server und Volumes entworfen. PostgreSQL Flex führt Version 15 bis November 2027 als unterstützt; ein verwaltetes Ziel ist also möglich. Der Datenbank-Leitfaden vergleicht beide Wege.

• Windows-Berichtsserver

  Lizenzweg und Maschinentyp sind offen. Der Lizenzleitfaden von STACKIT trennt ein Image mit enthaltener Lizenz von eigenem Image und eigenen Lizenzen.

• Das CRM unter CentOS 7

  Der Lauf warnt, dass öffentliche STACKIT-Images einen Gast nach Support-Ende nicht abdecken. Zuerst aktualisieren oder auf eigenes Risiko als eigenes Image migrieren.

• Die Vorlage

  Disk umwandeln und hochladen oder aus einem öffentlichen Image neu bauen. Die Seite zu eigenen Images begrenzt ein Image auf 70 GB; für diese Vorlage sind 30 GiB bereitgestellt.

• Präfixe und Adressen

  Eine Schnittstelle behält ihre Adresse nach dem Anlegen; daher klären Sie die vier Präfixe vor dem ersten Anwenden.

Von hier bis zum ersten Anwenden

1. 01

   WP-01 und WP-02 abschließen

   Präfixe und Namen schalten die vier Netzwerke frei. Tragen Sie die Antworten in review/ ein und starten Sie erneut; der nächste Lauf liest sie.

2. 02

   Die Anwendungsfragen entscheiden

   Datenbankziel, Lizenz des Berichtsservers, Upgrade-Weg des CRM und die Vorlage.

3. 03

   Variablen füllen

   Maschinentypen, Image-IDs und die Availability Zone. terraform/variables.tf deklariert 28 Variablen.

4. 04

   Images vorbereiten

   Den CRM-Snapshot konsolidieren, Disks in qcow2 oder raw umwandeln, hochladen und die Image-IDs festhalten.

5. 05

   In einem Testprojekt validieren

   Führen Sie den OpenTofu-Plan gegen ein Testprojekt aus. Das Paket hält fest, dass StackToIT nie apply ausführt.

6. 06

   Je Anwendung umstellen

   Nehmen Sie die Wellen als Ausgangspunkt und die von den Verantwortlichen genannte tolerierbare Ausfallzeit als Grenze.

Fragen zu diesem Durchlauf

Quellen

• STACKIT-Dokumentation: Lizenzleitfaden für Windows Server
• STACKIT-Dokumentation: Maschinentypen
• STACKIT-Dokumentation: Eigene Images mit der IaaS-API nutzen
• STACKIT-Dokumentation: Lebenszyklus der PostgreSQL-Flex-Versionen
• STACKIT-Dokumentation: Netzwerkschnittstellen, Konzepte