--- title: "STACKIT VM Ziel-Sizing und Block-Storage-Auswahl" description: "Überführt gemessene VMware-Last in STACKIT Machine Type- und Block-Storage-Profile mit explizitem Headroom, Verfügbarkeit und Prüfgrenzen nach dem Cutover." scfAsset: managed: false category: "guide" external: false tags: ["design-and-mobilize", "design", "relocate", "vmware", "vm", "sizing", "block-storage"] maintainers: - user: "lukas.weberruss" source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/stackit-vm-target-sizing-and-storage/" source_file: "docs/de/migration/assetcontainer/stackit/stackit-vm-target-sizing-and-storage.mdx" --- ## Zweck Nutzen Sie diesen Leitfaden, um das initiale STACKIT-Compute- und Storage-Profil für VMware-Workloads festzulegen, die als virtuelle Maschinen verlagert werden. Er überführt gemessene Last in ein explizites Ziel-Mapping, ohne bereitgestellte vCPU-, Memory- oder Datastore-Kapazität 1:1 zu übernehmen. Das initiale Ziel-Sizing schützt Migration und Cutover. Es ist nicht die endgültige Optimierungsentscheidung. Prüfen Sie das Profil erneut, nachdem der Workload auf STACKIT repräsentative Telemetrie erzeugt hat. ## Erforderliche Nachweise Erfassen Sie Messwerte über einen Zeitraum, der Normalbetrieb, Peak-Fenster, Batch-Verarbeitung, Backup-Aktivität, Monatsende- oder saisonale Ereignisse sowie bekannte Störungen enthält. - **CPU**: Erfassen Sie verbrauchte CPU, Peak- und p95-Last, Ready- oder Contention-Zeit sowie die Dauer anhaltender Last. Nutzen Sie die Anzahl bereitgestellter vCPUs nicht als einzige Eingabe. - **Memory**: Erfassen Sie aktiven und verbrauchten Memory, Working-Set-Peaks, Ballooning, Swapping und Cache-Verhalten. Gehen Sie nicht davon aus, dass zugewiesener VMware-Memory dauerhaft erforderlich ist. - **Storage-Kapazität**: Erfassen Sie genutzte Kapazität, Wachstumsrate, Retention, Snapshot-, Backup- und temporären Workspace-Bedarf. Migrieren Sie verwaiste Snapshots oder ungenutzte Disks nicht ohne Prüfung. - **Storage-Performance**: Erfassen Sie Read- und Write-IOPS, Throughput, Latenz, Queue-Tiefe, Blockgröße und Peak-Dauer pro Disk. Wählen Sie eine Klasse nicht allein anhand von Kapazität oder durchschnittlichen IOPS. - **Netzwerk**: Erfassen Sie Ingress, Egress, Verbindungsanzahl, Burst-Profil, Latenz und Paketverlust-Sensitivität. Beziehen Sie Backup- und Replikationstraffic ein. - **Verfügbarkeit**: Erfassen Sie Recovery-Ziele, Anforderungen an Failure-Domains, Wartungstoleranz und Restart-Verhalten. Betrachten Sie eine größere VM nicht als Verfügbarkeitsdesign. Dokumentieren Sie für jede Messung Quelle, Zeitraum, Perzentil, fehlende Samples, Wachstumsannahmen und Vertrauen. Wenden Sie einen benannten Sicherheitsaufschlag an, wenn Nachweise unvollständig sind, statt Unsicherheit in einem übergroßen Ziel zu verstecken. ## STACKIT Machine Type auswählen STACKIT Machine Types sind vordefinierte Hardware-Konfigurationen. Einzelne Kombinationen aus vCPU und RAM lassen sich außerhalb der angebotenen Varianten nicht frei zusammenstellen, daher ist die Auswahl ein zweidimensionaler Fit und keine direkte Umrechnung der VMware-Konfiguration. ### Typnamen verstehen > Aus der STACKIT-Doku: [Maschinentypen - EU01 › Maschinentyp-Bezeichnungen](https://docs.stackit.cloud/de/products/compute-engine/server/basics/machine-types/#maschinentyp-bezeichnungen) (Stand der Quelle 24.07.2026, übernommen 05.10.2026) Beispiel einer Maschinentyp-Bezeichnung: `c1a.8d` Der erste Teil des Namens, z. B. „**c**1a.8d”, bezeichnet die Variante eines Maschinentyps. Derzeit gibt es folgende Varianten: | Variante | Beschreibung | | --- | --- | | t | Kleinere Instanzen mit geringerer CPU und weniger RAM | | s | Prozessoroptimierte Instanzen mit einem CPU/RAM-Verhältnis von 1:1 | | c | Prozessoroptimierte Instanzen mit einem CPU/RAM-Verhältnis von 1:2 | | g | Allgemeine Instanzen mit einem CPU/RAM-Verhältnis von 1:4 | | m | Arbeitsspeicheroptimierte Instanzen mit einem CPU/RAM-Verhältnis von 1:8 | | b | Große, arbeitsspeicheroptimierte Instanzen mit CPU/RAM-Verhältnis 1:16 oder höher | | n | Instanzen mit NVIDIA-GPUs | Generation, Prozessorarchitektur, verfügbare Größen und exakte Memory-Werte variieren je Region und können sich im Zeitverlauf ändern. Ermitteln Sie den aktuellen Katalog in der Zielregion, bevor eine Welle freigegeben wird. ### Auswahlmethode 1. Wandeln Sie CPU-Messwerte in erforderliche Ziel-Cores für die Design-Last um und addieren Sie dann expliziten Headroom für Peaks, Wachstum und Messvertrauen. 2. Wandeln Sie den beobachteten Memory-Working-Set in erforderlichen RAM um und addieren Sie Headroom für Guest-Overhead, Cache-Verhalten, Wachstum und Cutover-Unsicherheit. 3. Identifizieren Sie die Machine-Type-Familie, deren CPU-zu-Memory-Verhältnis bei Erfüllung beider Anforderungen die geringste Verschwendung erzeugt. 4. Wählen Sie den kleinsten aktuellen Typ dieser Familie, der CPU und RAM gleichzeitig erfüllt; dokumentieren Sie, welche Dimension die Größe bestimmt. 5. Entscheiden Sie explizit zwischen CPU-overprovisioned und `d`-Typen. Bevorzugen Sie einen nicht overprovisioned Typ, wenn anhaltende CPU-Last, Latenz-Sensitivität oder beobachtete Contention planbaren CPU-Zugriff erfordern. 6. Prüfen Sie Prozessorarchitektur, Betriebssystem-Support, Lizenzierung, Placement in Availability Zones, Quotas und Wartungsverhalten. 7. Testen Sie den gewählten Typ mit einem repräsentativen Pilot und halten Sie den nächstgrößeren und nächstkleineren gültigen Typ für Rollback- und spätere Rightsizing-Entscheidungen fest. Leiten Sie äquivalente Performance nicht allein aus der vCPU-Anzahl ab. Prozessorgeneration, Overprovisioning, Guest-Treiber, Workload-Konkurrenz und Quell-Contention beeinflussen das beobachtete Ergebnis. ## Block Storage auswählen Behandeln Sie Storage-Kapazität, Performance und Verfügbarkeit als getrennte Entscheidungen. ### Kapazität und Platzierung 1. Dimensionieren Sie jedes Root- und Daten-Volume anhand genutzter Daten, erwartetem Wachstum, File-System-Anforderungen, Snapshots, Backup-Verhalten und temporärem Migration-Workspace. 2. Trennen Sie Disks, wenn Workload-Konsistenz, Backup-Policy, Performance-Isolation oder künftiges Wachstum unabhängige Steuerung erfordern. 3. Wählen Sie Single AZ oder Metro entsprechend dem Failure-Domain-Design des Workloads. Metro-Volumes sind über Availability Zones gespiegelt; das ersetzt weder Backups noch Recovery-Design auf Anwendungsebene. ### Performance-Klasse Eine STACKIT Block Storage Performance-Klasse definiert die maximalen IOPS und den Throughput für das gesamte Volume. Die Klasse ist unabhängig von der Volume-Größe, und alle Consumer dieses Volumes, einschließlich VM- und Backup-Reads, teilen sich ihr Performance-Limit. 1. Ermitteln Sie erforderliche Read- und Write-IOPS, Throughput, Latenz, Blockgrößenverteilung und Konkurrenz für jedes Ziel-Volume. 2. Addieren Sie expliziten Headroom für Peaks, Backup, Recovery und Wachstum getrennt für IOPS und Throughput. 3. Wählen Sie die niedrigste aktuelle Performance-Klasse, die beide Grenzen erfüllt. Eine Klasse, die bei IOPS besteht, aber bei Throughput scheitert, oder umgekehrt, ist nicht ausreichend. 4. Validieren Sie die Auswahl während Replikation und isolierter Testmigration, wenn Copy-Traffic einen anderen Engpass als der normale Anwendungsbetrieb sichtbar machen kann. 5. Dokumentieren Sie beobachtete Latenz, I/O-Wait, Queue-Tiefe, IOPS und Throughput nach dem Cutover für die Optimize-Prüfung. > Aus der STACKIT-Doku: [Service-Pläne › Derzeit verfügbare Servicepläne (Leistungs-Klassen)](https://docs.stackit.cloud/de/products/storage/block-storage/basics/service-plans/#derzeit-verfügbare-servicepläne-leistungs-klassen) (Stand der Quelle 20.01.2026, übernommen 05.10.2026) 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. Die Tabelle zeigt den EU01-Katalog. Ermitteln Sie immer die aktuellen Werte für die Zielregion. ## Ziel-Mapping-Nachweis Erstellen Sie pro VM und Volume jeweils eine versionierte Mapping-Zeile. - **Quell-VM und Workload**: Stabile Inventar-ID und Applikationszuordnung. - **Zielregion und Platzierung**: Region, Availability-Zone- oder Metro-Anforderung und Quota-Ergebnis. - **Machine Type**: Exakter Typ, CPU- und RAM-Anforderung, bestimmende Dimension, Headroom und Overprovisioning-Entscheidung. - **Root-Volume**: Kapazität, Performance-Klasse, Boot-Annahmen und Recovery-Annahmen. - **Daten-Volumes**: Source-to-Target-Disk-Mapping, Kapazität, Performance-Klasse und Konsistenzgruppe. - **Netzwerk**: Zielnetzwerk, Adressen, Security Groups, DNS und erwartete Bandbreite. - **Validierungsschwellen**: CPU, Memory, Latenz, IOPS, Throughput, Anwendungs-SLO und Beobachtungsfenster. - **Anpassungsoptionen**: Freigegebener größerer und kleinerer Typ, Storage-Alternative, Änderungsmethode und Rollback-Bedingung. Geben Sie das Mapping erst frei, wenn Zielprofil, erwartete Kosten, Quotas, Tool-Mapping und Akzeptanzschwellen vollständig bekannt sind. Übergeben Sie das exakte Mapping in die Coriolis- oder Acura-Testmigration, statt Zielressourcen erst während des Cutover auszuwählen. ## Primäre Referenzen