Nutzen Sie dieses Runbook, nachdem eine verlagerte VM die Cutover-Abnahme bestanden und auf STACKIT repräsentative Telemetrie erzeugt hat. Ziel ist es, initiale Compute- und Storage-Annahmen zu korrigieren, ohne Kostensenkung gegen Instabilität zu tauschen oder die Anwendungsarchitektur zu ändern.
Initiales Migrations-Sizing und Rightsizing nach dem Cutover sind getrennte Entscheidungen. Behalten Sie das Migrationsprofil bei, bis Zielmessungen Normalbetrieb, Peak-Phasen, Batch-Verarbeitung, Backups sowie bekannte saisonale oder Monatsende-Ereignisse des Workloads abdecken.
Einstiegskriterien
Abschnitt betitelt „Einstiegskriterien“- Cutover ist abgenommen und es gibt keine offenen Migrationsdefekte, die Messwerte verfälschen.
- Monitoring, Logs, Alerts, Backups und Health Checks der Anwendung funktionieren auf STACKIT.
- Aktueller Machine Type, Volume-Größen, Performance-Klassen und initiale Sizing-Annahmen sind in Infrastructure as Code oder einer anderen versionskontrollierten Konfiguration dokumentiert.
- Beobachtungsfenster und workloadspezifische Service-Level-Schwellen sind vor der Auswahl von Kandidaten freigegeben.
- Ein Wartungsfenster, ein getesteter Recovery Point, ein Rollback-Typ und ein technischer Entscheidungsverantwortlicher sind vorhanden.
Ziel-Baseline aufbauen
Abschnitt betitelt „Ziel-Baseline aufbauen“Korrelieren Sie Infrastruktur- und Anwendungsverhalten, statt aus nur einer Metrik zu optimieren.
- CPU: Prüfen Sie Auslastungsverteilung, p95- und Peak-Last, Load, Steal Time, Run Queue und Burst-Dauer. Untersuchen Sie anhaltende Sättigung, Contention oder ungenutzte Cores über alle repräsentativen Zeitfenster.
- Memory: Prüfen Sie Working Set, verfügbaren Memory, Cache, Swap, Paging, OOM-Ereignisse und Application Heap. Untersuchen Sie Swap- oder OOM-Druck sowie dauerhaft ungenutzte Allokation ohne Cache-Nutzen.
- Storage: Prüfen Sie IOPS, Throughput, Latenz, Queue-Tiefe, I/O-Wait, Blockgröße, Backup-Überlappung und Wachstum. Untersuchen Sie Klassensättigung, instabile Latenz, Kapazitätsdruck oder ungenutzten Headroom.
- Netzwerk: Prüfen Sie Throughput, Paketverlust, Retransmits, Verbindungsdruck und Latenz. Schließen einen Netzwerkengpass aus, bevor Druck CPU oder Storage zugeschrieben wird.
- Anwendung: Prüfen Sie Request-Rate, p95- und p99-Latenz, Fehler, Job-Dauer, Timeouts und Abhängigkeitsgesundheit. Verwerfen Sie eine Kostenverbesserung, die Workload-Akzeptanzschwellen verletzt.
Schließen Sie Zeiträume aus, die durch Migrationskopien, einmaliges Cache-Warm-up, ausgefallene Abhängigkeiten oder Messlücken beeinflusst sind, außer dieselbe Bedingung wird auch im Normalbetrieb erwartet. Halten Sie ausgeschlossene Zeiträume und den Ausschlussgrund im Nachweis fest.
Rightsizing-Maßnahme auswählen
Abschnitt betitelt „Rightsizing-Maßnahme auswählen“Klassifizieren Sie den Befund vor jeder Kapazitätsänderung:
- Keine Änderung: Das aktuelle Profil erfüllt Performance-, Resilienz- und Kostenerwartungen.
- Compute-Downsize: CPU und Memory behalten über repräsentative Last den freigegebenen Headroom.
- Compute-Upsize oder Familienwechsel: CPU, Memory oder CPU-zu-Memory-Verhältnis begrenzen den Workload.
- Wechsel auf einen nicht overprovisioned Typ: Anhaltende CPU-Last, Latenz-Sensitivität oder Steal Time erfordern besser planbaren CPU-Zugriff.
- Volume-Kapazität erhöhen: Prognostizierte nutzbare Kapazität erreicht die freigegebene Schwelle.
- Storage-Performance ändern: IOPS- oder Throughput-Grenzen, Latenz oder I/O-Wait zeigen eine Klassenfehlanpassung, nachdem Anwendungs- und Guest-Ursachen ausgeschlossen sind.
- Zuerst untersuchen: Das begrenzende Signal wird durch Konfiguration, Anwendungsverhalten, Abhängigkeitslatenz, Netzwerkverlust oder unzureichende Nachweise verursacht und nicht durch Ressourcenkapazität.
Ändern Sie nach Möglichkeit jeweils nur eine dominierende Dimension. Das hält Ergebnisse zurechenbar und macht Rollback-Entscheidungen belastbar.
Machine Type ändern
Abschnitt betitelt „Machine Type ändern“- Wählen Sie den kleinsten aktuellen Machine Type, der gemessene CPU- und Memory-Last plus freigegebenen Headroom erfüllt. Bewerten Sie Type-Familie und CPU-Overprovisioning-Entscheidung erneut, statt nur das Größensuffix zu ändern.
- Bestätigen Sie regionale Verfügbarkeit, Quota, Prozessorarchitektur, Guest-Support, Lizenzierung, Wartungsverhalten und die erwarteten Auswirkungen auf das Betriebssystem.
- Aktualisieren Sie die versionskontrollierte Konfiguration und prüfen Sie den vollständigen Infrastruktur-Plan. Stoppen Sie, wenn unbeabsichtigte Ersetzungen von Server, Volume, NIC, Adresse oder Attachment vorgeschlagen werden.
- Erfassen Sie einen getesteten Recovery Point, stoppen Sie die Anwendung sauber und führen Sie das Machine-Type-Resize im freigegebenen Wartungsfenster aus.
- Verifizieren Sie Boot, guest-seitige CPU und Memory, Treiber, Disks, NICs, Routen, Services, Monitoring und Application Health, bevor Traffic zurückgeschaltet wird.
- Vergleichen Sie Anwendungs- und Infrastrukturtelemetrie mit der Baseline vor der Änderung für das definierte Validierungsfenster.
By changing the machine-type the server will have a short downtime.
Resizing a server
$ stackit server resize <SERVER_ID> --machine-type <TYPE_NAME>
$ stackit server resize xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxxx --machine-type g2i.4<TYPE_NAME>should be replaced with the name of the new machine-type that should be used<SERVER_ID>should be replaced with the ID of the server you want to resize
After the resize it could be necessary to do changes in your operating system.
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.
Nutzen Sie das Portal, die CLI, API oder den vom Workload verantworteten Infrastructure-as-Code-Workflow, aber mischen Sie keine Steuerungspfade ohne anschließende Zustandsabstimmung.
Volume-Kapazität erhöhen
Abschnitt betitelt „Volume-Kapazität erhöhen“Ein gemanagtes STACKIT-Volume kann nur auf eine größere Größe aktualisiert werden. Kapazitätswachstum ändert die gewählte Performance-Klasse nicht automatisch, da Klassenlimits unabhängig von der Volume-Größe sind.
- Bestätigen Sie Kapazitätsprognose, Backup-Auswirkung, Quota und die vom Guest-Partitionstyp und File System unterstützte maximale Größe.
- Aktualisieren Sie die Volume-Größe über den kontrollierten Provisioning-Pfad und prüfen Sie den Plan.
- Erweitern Sie Guest-Partition, Physical Volume, Logical Volume und File System nur entsprechend dem Betriebssystem-Layout.
- Verifizieren Sie nutzbare Kapazität, File-System-Integrität, Backup-Verhalten, Monitoring und Anwendungs-I/O.
Volume-Verkleinerung erfordert ein neues kleineres Volume und eine Datenmigration. Versuche nicht, das gemanagte Volume zu reduzieren und davon auszugehen, dass das Guest-File-System diesen Vorgang sicher macht.
Führen Sie den folgenden Befehl aus, um die Größe eines Volumes zu ändern:
stackit beta volume resize <VOLUME_ID> --size <DRIVE_SIZE> --project-id <PROJECT_ID>Ersetzen Sie die Platzhalter im Befehl wie folgt:
<PROJECT_ID>: Ihre STACKIT Projekt-ID<VOLUME_ID>: Die ID des Volumes, dessen Größe Sie ändern möchten<DRIVE_SIZE>: Die neue Größe des Volumes in Gigabyte (GB)
Nachdem die Größe des Volumes geändert wurde, müssen Sie je nach Betriebssystem möglicherweise zusätzliche Schritte durchführen, um den zusätzlichen Speicherplatz zu nutzen. Diese Schritte umfassen in der Regel das Erweitern des Dateisystems, damit der neu zugewiesene Speicherplatz erkannt und verwendet werden kann.
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.
Storage-Performance ändern
Abschnitt betitelt „Storage-Performance ändern“Wählen Sie die neue Performance-Klasse getrennt aus gemessenen IOPS- und Throughput-Anforderungen. Die gewählte Klasse muss beide Grenzen erfüllen und Headroom für Backup, Recovery, Bursts und Wachstum enthalten.
Die folgende Tabelle listet die derzeit verfügbaren Leistungs-Klassen für die Region EU01 auf:
| 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.
Behandeln Sie eine Performance-Klassen-Änderung als Replacement-Workflow, sofern aktuelle API und Provisioning-Plan nicht explizit einen In-Place-Vorgang für diese Ressource belegen. Bei Terraform-verwalteten Volumes prüfen Sie den Plan vor Freigabe auf Replacement.
- Erstellen Sie ein Ziel-Volume mit erforderlichem Verfügbarkeitsmodell, Kapazität, Verschlüsselung und Performance-Klasse.
- Hängen Sie es in einem wartungssicheren Zustand an und bereiten Sie Partitionierung, File System, Berechtigungen, Mount-Optionen und Monitoring vor.
- Kopieren Sie die Bulk-Daten bei laufendem Workload nur dort, wo Anwendungskonsistenz dies zulässt.
- Stoppen Sie Schreibvorgänge, führen Sie die finale Synchronisierung oder das anwendungsnative Konsistenzverfahren aus und verifizieren Sie Prüfsummen, Datensatzanzahl oder Recovery-Status.
- Fahren Sie die VM vor finalen Detach-/Attach-Vorgängen herunter, wechseln Sie Mount- oder Device-Mapping und starten Sie dann den Workload zur Validierung.
- Behalten Sie das vorherige Volume ohne Schreibzugriffe für das freigegebene Rollback-Fenster und löschen Sie es erst, wenn Backup- und Abnahmenachweise vollständig sind.
Für Boot-Volumes oder zustandsbehaftete Systeme, die sich auf Dateiebene nicht sicher verschieben lassen, nutzen Sie ein getestetes Snapshot-, Image-, Block-Copy- oder anwendungsnatives Migrationsverfahren. Definieren Sie neuen Boot- und Rollback-Pfad vor dem Wartungsfenster.
Abnahme und Rollback
Abschnitt betitelt „Abnahme und Rollback“Nehmen Sie die Änderung nur ab, wenn alle workloadspezifischen Kriterien erfüllt sind:
- VM- und Anwendungsservices starten ohne neue Warnungen oder Geräteänderungen.
- Request-Latenz, Fehlerrate, Throughput und Batch-Dauer bleiben innerhalb freigegebener Grenzen.
- CPU, Memory, Storage und Netzwerk behalten den dokumentierten Headroom unter repräsentativer Last.
- Backup, Monitoring, Alerts, administrativer Zugriff und Security Controls bleiben funktionsfähig.
- Das gemessene Kosten- und Kapazitätsergebnis entspricht der erwarteten Verbesserung.
Bei fehlgeschlagener Machine-Type-Änderung stellen Sie den vorherigen unterstützten Typ über denselben Steuerungspfad wieder her und wiederholen Sie Boot- und Anwendungstests. Bei fehlgeschlagener Storage-Migration stoppen Sie Schreibzugriffe auf das Ziel und stellen Sie das vorherige Attachment oder die vorherige Datenquelle gemäß Konsistenzplan wieder her. Erhalten Sie alle Nachweise, auch wenn ein Kandidat verworfen wird.
Rightsizing-Nachweis
Abschnitt betitelt „Rightsizing-Nachweis“Dokumentieren Sie Beobachtungszeitraum, ausgeschlossene Intervalle, Metrikabfragen, aktuelle und Kandidatenprofile, Headroom, erwarteten Kosteneffekt, Infrastruktur-Plan, Wartungszeitachse, Testergebnisse, Entscheidung und Rollback-Ergebnis. Planen Sie eine erneute Prüfung, wenn sich Workload-Last, Anwendungsarchitektur, Retention oder Wachstumsannahmen wesentlich ändern.