AWS → STACKIT · RUNBOOK
Cutover- und Rollback-Runbook für AWS zu STACKIT
Ein Cutover besteht aus vielen kleinen, umkehrbaren Schritten und am Ende einem unumkehrbaren. Dieses Runbook ordnet die Schritte so, wie StackToIT sie für eine Demo-Umgebung ordnet (PostgreSQL-Datenbank, Bucket, Server und DNS-Zone), nennt je Schritt einen Verantwortlichen, eine Prüfung und einen Rückweg und markiert den Punkt, ab dem der Rückweg ein Neuaufbau aus Backups ist.
So nutzen Sie dieses Runbook
Die Reihenfolge stammt aus dem Ausführungsplan des Laufs, Verantwortliche und Rollback-Zeilen aus den manuellen Schritten, die er schreibt (execution/manual/actions.md). Zeilen mit „Praxis“ sind allgemeine gute Praxis, die der Lauf nicht schreibt.
Woher die Reihenfolge kommt
Abhängigkeiten bestimmen die Wellen; die Cutover-Schritte verweisen auf die Schritte, nach denen sie kommen („after“). Daher folgt die Bereitschaft dem letzten Datenabgleich, die Umschaltungen folgen der Bereitschaft und die Rollback-Entscheidung folgt jeder Prüfung.
Nichts läuft von selbst
StackToIT erzeugt, ändert und löscht nichts. Jeden Schritt führt eine Person, OpenTofu oder ein Skript Ihres Teams aus.
Keine Zeitangaben
Der Plan nennt kein Wartungsfenster und erfindet keines. Nehmen Sie Dauern aus Ihrem Probelauf, nicht aus einer Tabelle.
Die Aufbau-Reihenfolge: drei Wellen
Aus migration/technical-sequencing.md des Demo-Laufs: neun Einheiten in drei Wellen. Einheiten einer Welle können parallel umziehen; die Datei nennt das einen Ausgangspunkt für Ihren Wellenplan, keinen Terminplan.
## Wave 1 — 4 unit(s)
| Unit | Class | Target |
|---|---|---|
| `aws_route53_zone.main` | DIRECT / MEDIUM | STACKIT DNS |
| `aws_s3_bucket.uploads` | RECONFIGURE / MEDIUM | STACKIT Object Storage |
| `aws_secretsmanager_secret.api_key` | RECONFIGURE / MEDIUM | STACKIT Secrets Manager |
| `aws_vpc.app` | RECONFIGURE / MEDIUM | STACKIT project networking / Network Area (SNA) |
## Wave 2 — 3 unit(s)
| Unit | Class | Target |
|---|---|---|
| `aws_security_group.db` | RECONFIGURE / MEDIUM | STACKIT security group |
| `aws_subnet.app_a` | RECONFIGURE / MEDIUM | STACKIT network |
| `aws_subnet.app_b` | RECONFIGURE / MEDIUM | STACKIT network |
## Wave 3 — 2 unit(s)
| Unit | Class | Target |
|---|---|---|
| `aws_db_instance.orders` | REPLATFORM / MEDIUM | STACKIT PostgreSQL Flex |
| `aws_instance.app` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |Phase 1 · Vor dem Fenster
| Schritt | Verantwortlich · erledigt, wenn | Rückweg |
|---|---|---|
| Offene Entscheidungen beantworten: Methode des Datenumzugs für Datenbank und Bucket, Opt-in für die S3-API-Aufrufe, Boot-Image des Servers, Vorgaben zu Größe und Endpunkt | Ihre Architekten · die auf Entscheidungen wartenden Schritte sind frei (executive/decisions.md; der Demo-Lauf hat 6 Entscheidungen, 5 davon halten Schritte auf) | Noch nichts geändert |
| Variablen füllen (project_id, Zugriffsbereich, Client-CIDRs, Storage-Klasse, Image, Maschinentyp), die Vorschritte aus execution/terraform/apply.md erledigen, dann das geprüfte Terraform anwenden (OpenTofu wendet alle seine Schritte in einem Apply an) | Plattformteam · jeder Punkt in execution/verify/checks.md abgehakt | Neue STACKIT-Ressourcen zerstören; die Quelle bleibt unberührt (Praxis) |
| TTL der Zone und ihrer Delegation senken, dann die alte TTL abwarten (größte TTL der Demo-Zone: 300 s) | Network Architect · alte TTL ist abgelaufen | TTL wieder anheben (Praxis) |
| Jeden Eintrag direkt an einem STACKIT-Nameserver abfragen und mit Route 53 vergleichen | Network Architect · Antworten stimmen überein, außer wo der Wert ein AWS-Endpunkt ist | Den Registrar nicht anfassen, bevor sie übereinstimmen |
| Datenprüfung vorab und Probelauf für Datenbank und Bucket; Erstkopie und Replikationsüberwachung, wo die Methode sie hat | Data Architect · die Dauer jedes Teilschritts ist notiert, das Schreibstopp-Fenster ist daraus vereinbart | Temporäre Instanz löschen; die Quelle bleibt unverändert |
| Restore-Check: die neue PostgreSQL-Flex-Instanz auf einen Zeitpunkt klonen, lesen, vergleichen, Dauer festhalten, Klon löschen | Storage Architect · Klon stimmt mit der Quelle überein; Aufbewahrungsdatum der AWS-Backups notiert | Eine Prüfung ändert nichts; temporäre Ressourcen löschen |
| Jetzt festlegen, ob nach dem Umschalten auf dem Ziel geschriebene Daten zurückkopiert oder als verloren akzeptiert werden | Migration Owner · Entscheidung vor dem Fenster festgehalten, nicht im Störfall | Entfällt |
Phase 2 · Schreibstopp und Abschlusskopie
| Schritt | Verantwortlich · erledigt, wenn | Rückweg |
|---|---|---|
| Cutover-Bereitschaft: bestätigen, dass jeder Workload-Schritt und jeder Datenumzug vor der ersten Umschaltung erledigt ist | Migration Owner · jeder vorangehende Schritt ist als erledigt festgehalten | Eine Bestätigung ändert nichts |
| Schreibstopp: Schreibende auflisten, Verbindungseinstellungen jedes Clients festhalten, schreibende Dienste, Jobs und Migrationen stoppen | Migration Owner · kein Client schreibt auf die Quelle | Die schreibenden Dienste wieder gegen die Quelle starten: Es wurde nichts geändert |
| Abschlusskopie: Dump und Restore während des Schreibstopps oder auf eine Replikationsverzögerung von 0 warten, Sequenzen kopieren und die Subscription deaktivieren; letzte Objekte des Buckets kopieren | Data Architect · Replikationsverzögerung war 0, Sequenzen des Ziels nicht niedriger als die der Quelle | Der Slot liegt noch auf der Quelle, die Quelle ist unberührt: die schreibenden Dienste wieder auf die Quelle richten |
| Abgleich: Zeilenzahlen, Prüfsummen, Sequenzen und eine Abfrage der Anwendung; Objektzahlen und Listen der Objektschlüssel für den Bucket; GO oder NO-GO festhalten | Data Architect · Zahlen auf beiden Seiten gleich | Bei NO-GO den Rollback nehmen, ohne etwas umzuschalten |
Phase 3 · Das Umschalten
| Schritt | Verantwortlich · erledigt, wenn | Rückweg |
|---|---|---|
| Verbindung der Anwendungen zur Datenbank umschalten: Host, Port, Datenbankname und Zugangsdaten | Data Architect · jede Anwendung verbindet sich mit PostgreSQL Flex, die AWS-Instanz sieht keine Lese- oder Schreibzugriffe | Konfiguration zurücksetzen; was inzwischen aufs Ziel geschrieben wurde, ist nicht in AWS |
| Anwendungen des Buckets umschalten: Endpunkt, Bucket-Name und Zugriffsschlüssel | Storage Architect · Anwendungen nutzen den STACKIT-Bucket, der AWS-Bucket sieht keine Anfragen | Konfiguration auf den AWS-Bucket zurücksetzen |
| Traffic-Umschaltung des Servers: Clients von seiner AWS-Adresse auf seine STACKIT-Adresse umlenken | Network Architect · Anfragen erreichen die STACKIT-Adresse, die AWS-Adresse bekommt keine | Clients zurückstellen; die AWS-Ressourcen bleiben bis zum GO |
| Delegationswechsel der Zone: die Route-53-Nameserver beim Registrar oder in der übergeordneten Zone durch die von STACKIT angezeigten ersetzen | Network Architect · die übergeordnete Zone antwortet mit den STACKIT-NS-Einträgen und ein Resolver, den Sie nach Ablauf einer NS-TTL der Elternzone abfragen, liefert dasselbe | NS-Einträge auf Route 53 zurücksetzen; die STACKIT-Zone mindestens eine NS-TTL der Elternzone lang weiterbetreiben |
| Cutover-Abschluss: bestätigen, dass jede Umschaltung als erledigt festgehalten ist | Migration Owner · der Verantwortliche hält fest, dass der Cutover abgeschlossen ist | Eine Bestätigung ändert nichts |
Die zwei Schritte, die den Rollback tragen
Zeilenbereiche im Wortlaut aus execution/manual/actions.md des Demo-Laufs: Risiko und Rollback des Delegationswechsels, dann Kopf und Rollback des Schritts der Rollback-Entscheidung. Die langen Abhängigkeits- und Statuszeilen dazwischen sind weggelassen.
- Risk: while resolvers hold the old delegation (one parent NS TTL) some answer from Route 53 and some from STACKIT: a record changed in one zone and not in the other is seen by part of the clients only, so both zones hold the same records until the TTL has passed
- Rollback (manual): set the NS records at the registrar (or the parent zone) back to the Route 53 name servers; resolvers that hold the STACKIT delegation keep it for one parent NS TTL, so the STACKIT zone stays in service for at least that long after the rollback, and the Route 53 zone is retired only after the GO recorded at the rollback decision step#### The rollback decision step (`MAN/verify/rollback-decision`)
- Phase: Verification
- What: Decide GO or ROLLBACK for the migration once every check of the verification is done: GO lets the source resources be retired, ROLLBACK reverts the cutover and keeps AWS serving
- Why: reverting the cutover is a change of addresses only while the AWS resources exist; after the first decommission step the way back is a rebuild from backups
- Who: Migration Owner
- When: after every check of the verification- Risk: the decision point follows every check of the verification (each is also an action-complete precondition); the retirement steps depend on it, and through it on the checks
- Rollback (manual): on ROLLBACK, revert each cutover step as its rollback says (the traffic switch of aws_instance.app, the delegation change of the hosted zone of aws_route53_zone.main, the switch of the applications that use aws_s3_bucket.uploads, the switch of the applications that use aws_db_instance.orders) and start no decommission step; on GO nothing is revertedPhase 4 und 5 · Prüfen, entscheiden, stilllegen
| Schritt | Verantwortlich · erledigt, wenn | Rückweg |
|---|---|---|
| Endpunkt-Check direkt nach der Traffic-Umschaltung, dann die Datenchecks für Datenbank und Bucket: Zahlen stimmen, die Anwendung liest migrierte Datensätze, ein geschriebener Testdatensatz wird zurückgelesen | Network, Data und Storage Architect · Status und Inhalt entsprechen dem, was die AWS-Adresse lieferte | Checks ändern nichts; den Testdatensatz entfernen, den sie geschrieben haben |
| Rollback-Entscheidung: GO oder ROLLBACK mit Datum und Ergebnis jedes Checks festhalten | Migration Owner · Entscheidung festgehalten | Bei ROLLBACK jede Umschaltung nach ihrem eigenen Rollback zurücknehmen und keinen Stilllegungsschritt starten |
| Datenumzug aufräumen: Subscription und Publication löschen, Umzugs-Host aus der Zugriffsliste nehmen, Dump-Dateien löschen, Zugangsdaten rotieren, einen letzten Snapshot der Quelle behalten; rds.logical_replication zurückzusetzen erfordert einen Neustart und damit einen zweiten Ausfall der Quelle, falls Sie sie behalten | Data Architect · kein Slot, keine Subscription, keine Publication und keine Dump-Datei übrig, der Umzugs-Host ist aus der Zugriffsliste entfernt | Keiner: nach dem Aufräumen ist der Rückweg der letzte Snapshot der Quelle |
| Jede AWS-Ressource einzeln stilllegen (Datenbank, Secret, Server, Bucket, Zone, Security Group, Subnetze, Netzwerk), jede erst, wenn die von ihr abhängigen Ressourcen entfernt sind | Der Verantwortliche der jeweiligen Ressource · die Ressource existiert im AWS-Konto nicht mehr und ihre Kosten erscheinen nicht mehr auf der Rechnung | Bei der Datenbank unmöglich: nur das letzte Backup stellt ihre Daten wieder her, in eine neue Ressource |
| Instanzschutz für kritische Produktionsinstanzen von PostgreSQL Flex einschalten (Praxis; die Release Notes von STACKIT empfehlen ihn, weil das Löschen einer Instanz ohne Schutz die Daten sofort vernichtet) | Data Architect · Schutz aktiv | Bewusst deaktivieren, wenn gelöscht werden soll |
Der DNS-Entwurf hinter dem Delegationsschritt
Die STACKIT-DNS-Zone und das Record Set, die der Demo-Lauf schrieb (terraform/dns.tf, ohne Kommentare). Der Eintrag behält die 300-s-TTL der Quelle.
resource "stackit_dns_zone" "main" {
project_id = var.project_id
name = "orders.example.com"
dns_name = "orders.example.com"
}
resource "stackit_dns_record_set" "app" {
project_id = var.project_id
zone_id = stackit_dns_zone.main.zone_id
name = "www.orders.example.com"
type = "A"
records = ["203.0.113.10"]
ttl = 300
}Regeln für den Rollback
Wo der Rückweg endet und was Sie unterwegs aufgeben.
Die Quelle bis zum GO unangetastet lassen
Der Plan setzt die Quelle nie auf schreibgeschützt und ändert sie nach dem Schreibstopp nicht; ein Rollback setzt also nur Konfiguration zurück. Löschen Sie vor der Rollback-Entscheidung GO nichts in AWS.
Schreibzugriffe nach dem Umschalten
Was die Anwendungen nach dem Umschalten nach STACKIT schrieben, ist nicht in AWS. Kopieren Sie es mit einer eigens geprobten Methode zurück oder akzeptieren Sie den Verlust – und entscheiden Sie das vor dem Fenster.
DNS braucht Geduld
Resolver behalten die alte Delegation nach einer Änderung eine NS-TTL der Elternzone lang; deshalb müssen beide Zonen so lange dieselben Einträge enthalten. Die TTL der Delegation beim Registrar steht nicht in der Quelle.
DNSSEC (Praxis)
AWS dokumentiert für die Gegenrichtung, dass eine Domain nicht von zwei Anbietern gleichzeitig signiert werden kann und der DS-Eintrag zuerst entfernt werden muss. Ist Ihre Zone signiert, planen Sie den DS-Eintrag in beide Richtungen ein.
Der Punkt ohne Rückkehr
Nach dem ersten Stilllegungsschritt ist der Rückweg ein Neuaufbau aus Backups. Deshalb ist der Entscheidungsschritt getrennt und trägt Datum und Ergebnis jedes Checks.
Fragen aus den Teams
Wie lang soll das Wartungsfenster sein?
Der Plan nennt kein Fenster und erfindet keines. Nehmen Sie die Kopierzeiten aus Ihrem Probelauf, rechnen Sie Abgleich und Umschaltung hinzu und stimmen Sie das Fenster mit den Anwendungsverantwortlichen ab.
Kann StackToIT den Cutover für uns ausführen?
Nein. Es schreibt die Schritte, die Verantwortlichen und die Prüfungen. Ein Executor, der den Plan Schritt für Schritt ausführen würde, ist im Paket als entworfen und nicht implementiert beschrieben.
Erst DNS oder erst die Daten umschalten?
Der Plan ordnet zuerst den Datenabgleich, dann die Bereitschaft, dann die Umschaltungen. Der Delegationswechsel wartet, bis die STACKIT-Zone jeden Eintrag hält und die gesenkte TTL abgelaufen ist.
Was, wenn der Abgleich scheitert?
Den Rollback nehmen, ohne etwas umzuschalten. Die Clients zeigen noch auf die Quelle, die bis zum Schreibstopp aktuell ist.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.