Auf VMware-VMs gehostete Datenbanken zu STACKIT migrieren

Die VMs, die der Lauf zurückgibt

Links die Disks von ora19c-01, einem Knoten eines Oracle-Paares mit Shared Disk, und von rdm-san01, einer VM mit Raw Device Mapping, aus dem Blatt vDisk. Rechts der Teil von terraform/README.md, der aufführt, was der Lauf dem Architekten überlässt.

VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
ora19c-01,Hard disk 1,102400,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[ds-db-01] ora19c-01/ora19c-01_0.vmdk,4202-vm16-0004
ora19c-01,Hard disk 2,512000,False,independent_persistent,sharingMultiWriter,False,SCSI controller 1,virtualSharing,[ds-db-01] ora19c-01/ora19c-01_1.vmdk,4202-vm16-0004
rdm-san01,Hard disk 1,61440,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[ds-db-02] rdm-san01/rdm-san01_0.vmdk,4202-vm16-0007
rdm-san01,Hard disk 2,2097152,True,independent_persistent,sharingNone,False,SCSI controller 1,noSharing,[ds-db-02] rdm-san01/rdm-san01_1.vmdk,4202-vm16-0007

| Source | Class | Why |
|---|---|---|
| `vm.ora19c-01` | MANUAL_REVIEW / MEDIUM | Shared or multi-writer disks (clusters such as WSFC or Oracle RAC). |
| `vm.ora19c-02` | MANUAL_REVIEW / MEDIUM | Shared or multi-writer disks (clusters such as WSFC or Oracle RAC). |
| `vm.rdm-san01` | MANUAL_REVIEW / MEDIUM | Raw device mapping: the LUN is not part of the VM image, so an image export does not carry its data; it needs a block- or application-level copy to a STACKIT volume. |

• Shared Disk, kein automatischer Entwurf

  Beide Oracle-Knoten haben eine Disk im Sharing-Modus Multi-Writer an einem geteilten Bus. Der Lauf klassifiziert sie als MANUAL_REVIEW und schreibt keinen Server für sie. Ein STACKIT-Daten-Volume hängt immer nur an einem Server; ein Shared-Disk-Cluster braucht also ein neues Design statt einer Kopie.

• Raw-Mapping, Daten außerhalb des Images

  Die Spalte Raw steht bei der zweiten Disk von rdm-san01 auf True. Der Lauf hält fest, dass die LUN nicht Teil des VM-Images ist, dass ein Export ihre Daten also nicht mitnimmt und dass eine Kopie auf Block- oder Anwendungsebene nötig ist.

• Drei von neun Einheiten

  Bewertet wurden neun Einheiten: zwei Netzwerke und sieben VMs. Sechs wurden als Terraform entworfen; drei bleiben bei einer Person.

Ein PostgreSQL-Primary, per Rehost umgesetzt

Links die drei Disks von pg-prod01. Rechts der Server und die zwei Daten-Volumes des Entwurfs, ohne die Prüfkommentare über den Blöcken.

VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
pg-prod01,Hard disk 1,81920,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[ds-db-01] pg-prod01/pg-prod01_0.vmdk,4202-vm16-0001
pg-prod01,Hard disk 2,1048576,False,persistent,sharingNone,False,SCSI controller 1,noSharing,[ds-db-01] pg-prod01/pg-prod01_1.vmdk,4202-vm16-0001
pg-prod01,Hard disk 3,204800,False,persistent,sharingNone,False,SCSI controller 2,noSharing,[ds-db-01] pg-prod01/pg-prod01_2.vmdk,4202-vm16-0001

resource "stackit_server" "vm_pg_prod01" {
  project_id        = var.project_id
  name              = "pg-prod01"
  machine_type      = var.vm_pg_prod01_machine_type
  availability_zone = var.availability_zone
  boot_volume = {
    source_type = "image"
    source_id   = var.vm_pg_prod01_image_id
    size        = 80
  }
  network_interfaces = [stackit_network_interface.vm_pg_prod01_nic1.network_interface_id]
}

resource "stackit_volume" "vm_pg_prod01_disk2" {
  project_id        = var.project_id
  name              = "pg-prod01-disk2"
  availability_zone = var.availability_zone
  size              = 1024
  performance_class = var.vmware_volume_performance_class
}

resource "stackit_server_volume_attach" "vm_pg_prod01_disk2" {
  project_id = var.project_id
  server_id  = stackit_server.vm_pg_prod01.server_id
  volume_id  = stackit_volume.vm_pg_prod01_disk2.volume_id
}

resource "stackit_volume" "vm_pg_prod01_disk3" {
  project_id        = var.project_id
  name              = "pg-prod01-disk3"
  availability_zone = var.availability_zone
  size              = 200
  performance_class = var.vmware_volume_performance_class
}

resource "stackit_server_volume_attach" "vm_pg_prod01_disk3" {
  project_id = var.project_id
  server_id  = stackit_server.vm_pg_prod01.server_id
  volume_id  = stackit_volume.vm_pg_prod01_disk3.volume_id
}

• Disks behalten ihre Rollen

  Die 80-GiB-Systemdisk wird das Boot-Volume, die 1-TiB-Datendisk ein Volume mit 1024 GiB, die 200-GiB-Disk (in dieser Umgebung das Write-Ahead-Log) ein Volume mit 200 GiB. Die Namen stammen aus dem Entwurf, die Rollen aus Ihrer Kenntnis der Datenbank.

• Daten werden später kopiert

  Jeder Volume-Block vermerkt, dass die Daten nach dem Anlegen kopiert werden. Der Lauf überträgt nie Daten.

• Innerhalb der Volume-Grenzen

  Die Block-Storage-Dokumentation nennt für Daten-Volumes einen Bereich von 1 GB bis 16 TB je Volume; ein Volume mit 1 TiB passt also.

Dem Lauf sagen, wie viel Ausfallzeit eine Anwendung erlaubt

Links eine Anwendungsdatei, für diese Umgebung geschrieben. Sie benennt die Einheiten zweier Anwendungen und hält RTO, RPO und tolerierbare Ausfallzeit fest, wie die Verantwortlichen sie nannten. Rechts die Zeilen aus migration/waves.csv, die das Ergebnis zeigen. Die Datei wird mit dem Schalter --applications übergeben.

applications:
  - id: orders-db
    name: Orders database
    selectors:
      - vm.pg-prod01
      - vm.pg-prod02
    environment: production
    owners:
      business: sales
      technical: dba-team
    business_criticality: critical
    availability:
      rto: 2h
      rpo: 5m
      downtime_tolerance: 30m
  - id: wiki
    name: Team wiki
    selectors:
      - vm.mysql01
    environment: production
    business_criticality: low
    availability:
      downtime_tolerance: 8h

wave,wave_state,unit,type,module_call,presence,class,confidence,application,application_status,proposed_group
2,MEMBER,vm.mysql01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,wiki,CONFIRMED,
2,MEMBER,vm.ora19c-01,vmware_vm,,KNOWN_PRESENT,MANUAL_REVIEW,MEDIUM,UNASSIGNED,UNASSIGNED,
2,MEMBER,vm.pg-prod01,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,orders-db,CONFIRMED,
2,MEMBER,vm.pg-prod02,vmware_vm,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,orders-db,CONFIRMED,

• Nur Benanntes wird zugeordnet

  pg-prod01 und pg-prod02 gehören zu orders-db, mysql01 zu wiki. ora19c-01 bleibt UNASSIGNED, weil kein Selektor es nennt.

• Werte werden wie geschrieben übernommen

  RTO 2h, RPO 5m und eine tolerierbare Ausfallzeit von 30m stehen in migration/applications.csv genau so, wie sie angegeben wurden. Die Datenklassifizierung bleibt NOT_PROVIDED, wo die Datei schweigt.

• Der Lauf rechnet nicht

  Aus diesen Werten wird weder eine Übertragungszeit noch ein Umstellungsfenster abgeleitet. Sie bilden den Rahmen für die Entscheidung, die Sie weiter unten treffen.

Was der Lauf zum Datenumzug sagt

Aus migration/data-movement.md desselben Laufs, zwei Zeilen, die für jede Datenbank in einer VM wichtig sind.

StackToIT never moves data. The source holds no database, cache, search domain, warehouse, volume, file share or object store, but it holds servers or virtual machines. Data that lives on the disks of a server or virtual machine is not looked at, so whether data has to move is not assessed.

State: NOT ASSESSED.

• Nicht bewertet, mit Absicht

  Eine Datenbank auf einer VM-Disk ist für den Lauf eine Disk. Er listet dafür weder Datenbank noch Größe noch Verfahren.

• Das Verfahren wählen Sie

  Größe, Änderungsrate, tolerierte Ausfallzeit und die nötige Konsistenz der Anwendung entscheiden zwischen Disk-Kopie, Dump und Restore, Backup-Import oder Replikation.

Wohin welche Datenbank gehen kann

Aussagen zu STACKIT-Diensten stammen aus den Dokumentationsseiten in den Quellen und können sich ändern; prüfen Sie die aktuellen Seiten. StackToIT selbst entwirft für diese VMs nur den Rehost-Weg.

Die Migration Schritt für Schritt

1. 01

   Datenbanken selbst finden

   Der Export enthält VMs, keine Engines. Nutzen Sie die Spalte Annotation, Ihre CMDB und die DBAs: Der Lauf erkennt Datenbanksoftware weder an Namen noch an Notizen.

2. 02

   Ziel pro Datenbank wählen

   Rehost behält Engine und Version und lässt Patching, Backup und Hochverfügbarkeit bei Ihnen. Ein Managed Service nimmt diese Arbeit ab, verlangt aber eine unterstützte Version und einen Datenumzug.

3. 03

   Ausfallzeit- und Wiederherstellungswerte festhalten

   Tragen Sie RTO, RPO und tolerierbare Ausfallzeit in eine Anwendungsdatei ein, damit sie mit dem Plan mitgehen, und führen Sie die Bewertung erneut aus.

4. 04

   Das Ziel aufbauen

   Beim Rehost füllen Sie die Variablen des Entwurfs: Maschinentyp, Image-ID, Performance-Klasse der Volumes, Netzwerkpräfixe. Einen Managed Service legen Sie selbst an; der Entwurf schreibt keinen.

5. 05

   Daten einspielen

   Beispiele für allgemeine Praxis: Dump und Restore bei PostgreSQL, Backup-Import bei SQL Server oder Replikation, die das Ziel bis zur Umstellung aktuell hält. Üben Sie mit einer Kopie und messen Sie die Zeit.

6. 06

   Prüfen, dann umstellen

   Vergleichen Sie auf dem Ziel Zeilenzahlen und führen Sie Anwendungstests durch, stellen Sie Verbindungszeichenfolgen oder DNS-Namen um und lassen Sie die Quell-VM heruntergefahren, aber unverändert, bis die verantwortliche Person freigibt. Das ist gängige Praxis, keine Ausgabe des Laufs.

7. 07

   Den Rückweg behalten

   Bis zur Freigabe bleibt die Quelle das führende System. Halten Sie fest, wie Anwendungen wieder auf sie zeigen.

Entscheidungen des Architekten

• Rehost oder Managed Service

  Pro Datenbank, nicht pro Umgebung. Ein Managed Service nimmt Arbeit ab und bringt Vorgaben zu Version, Erweiterungen und Zugriff mit.

• Version

  Der Wechsel zu einem Managed Service bedeutet oft, eine dort unterstützte Version zu wählen. Stand November 2026 nennt die Lifecycle-Seite für PostgreSQL 14 das Lebensende November 2026 und für 13 November 2025. Wählen Sie keine der beiden für ein neues Ziel; 16 oder 17 lassen die meiste Zeit.

• Hochverfügbarkeit

  Zwei VMs mit Streaming-Replikation, wie in dieser Umgebung, und ein Replica Set mit drei Knoten sind verschiedene Designs. Entscheiden Sie, welches Sie wollen, und testen Sie den Failover.

• Ausfallzeit

  Die Anwendungsdatei hält fest, was jeder Verantwortliche akzeptiert. Wählen Sie ein passendes Einspielverfahren: Replikation für enge Fenster, Dump und Restore, wo Stunden vertretbar sind.

• Speicherklasse

  Die Performance-Klasse der Volumes ist im Entwurf eine Variable für die ganze Umgebung. Datenbanken mit Log-Disk brauchen womöglich eine andere Klasse als Dateiserver.

• Cluster-Design

  Shared-Disk-Cluster und Raw-Mappings sind die VMs, die der Lauf zurückgibt. Sie brauchen eine Designentscheidung vor jeder Kopie.

Fragen aus den Datenbankteams

Quellen

• STACKIT-Dokumentation: Architektur von PostgreSQL Flex
• STACKIT-Dokumentation: Versions-Lebenszyklus von PostgreSQL Flex
• STACKIT-Dokumentation: SQL-Server-Backup in SQLServer Flex importieren
• STACKIT-Dokumentation: Transaktionale Replikation zu STACKIT
• STACKIT-Dokumentation: Konzepte von Block Storage
• STACKIT-Dokumentation: Einführung in MariaDB