VMWARE → STACKIT · SPEICHER
VMFS- und vSAN-Speicher für den Umzug zu STACKIT planen
RVTools nennt den Datastore jeder VM und jeder Platte in den Pfaden, sagt aber nicht, ob dieser Datastore VMFS oder vSAN ist, und enthält keine vSAN-Richtlinie. StackToIT entwirft deshalb jede Datenplatte als gleich großes Volume mit einer einzigen Variable für die Performance-Klasse. Speicherplanung für STACKIT heißt: ein kurzes Inventar je Datastore und eine Entscheidung je Tier. Diese Seite zeigt beides an einer Demo-Umgebung mit sieben VMs.
Speicherplanung in fünf Schritten
Datastores lesen
Jede Plattenzeile im Blatt vDisk trägt einen Pfad, der mit dem Datastore in eckigen Klammern beginnt. Das Blatt vInfo macht dasselbe für die Konfigurationsdatei der VM. Der Lauf hält den Namen in Klammern als Datastore der VM und je Platte als Datastore dieser Platte fest und gibt beides als zu entscheidende Einstellung zurück.
Je Datastore summieren
Addieren Sie die bereitgestellte Kapazität und zählen Sie die VMs je Datastore. Ein Datastore ist meist ein Tier: gleiche Hardware, gleiche Richtlinie, gleicher Verantwortlicher.
Jedem Tier eine Performance-Klasse geben
Bei STACKIT wählen Sie die Performance-Klasse beim Anlegen des Volumes. Entscheiden Sie je Tier, welche Klasse es braucht, anhand gemessener IOPS und Durchsätze der Quelle, nicht anhand des Datastore-Namens.
Volume-Regeln prüfen
Ein Datenvolume fasst 1 GB bis 16 TB, hängt immer nur an einem Server und wächst nur im abgehängten Zustand. Ein Single-AZ-Volume ist fest einer Verfügbarkeitszone zugeordnet und wird nicht zonenübergreifend gespiegelt; ein Metro-Volume wird über zwei Zonen gespiegelt.
Festlegen, wie die Daten übertragen werden
Der Lauf führt die Volumes auf; er kopiert kein einziges Byte. Wählen Sie je Tier eine Methode nach Größe und der Ausfallzeit, die die Anwendung verträgt.
Die Demo-Umgebung im Blatt vDisk
Eine für diese Seite geschriebene Demo-Umgebung, am 4. November 2026 von StackToIT bewertet: drei Portgruppen, sieben VMs auf drei Datastores. Links das ganze Blatt vDisk. Rechts das Datenvolume, das der Lauf für die große Platte von arch-fs01 entwirft; Review-Kommentare über den Blöcken sind weggelassen.
VM,Disk,Capacity MiB,Raw,Disk Mode,Sharing mode,Thin,Controller,Shared Bus,Disk Path,VM UUID
crm-web01,Hard disk 1,61440,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] crm-web01/crm-web01.vmdk,4204-d010-0001
crm-app01,Hard disk 1,81920,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] crm-app01/crm-app01.vmdk,4204-d010-0002
crm-app01,Hard disk 2,204800,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] crm-app01/crm-app01_1.vmdk,4204-d010-0002
crm-db01,Hard disk 1,102400,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[vmfs-ssd-db] crm-db01/crm-db01.vmdk,4204-d010-0003
crm-db01,Hard disk 2,819200,False,persistent,sharingNone,False,SCSI controller 1,noSharing,[vmfs-ssd-db] crm-db01/crm-db01_1.vmdk,4204-d010-0003
crm-db02,Hard disk 1,102400,False,persistent,sharingNone,False,SCSI controller 0,noSharing,[vmfs-ssd-db] crm-db02/crm-db02.vmdk,4204-d010-0004
crm-db02,Hard disk 2,819200,False,persistent,sharingNone,False,SCSI controller 1,noSharing,[vmfs-ssd-db] crm-db02/crm-db02_1.vmdk,4204-d010-0004
arch-fs01,Hard disk 1,51200,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vmfs-nl-archive] arch-fs01/arch-fs01.vmdk,4204-d010-0005
arch-fs01,Hard disk 2,18432000,False,persistent,sharingNone,True,SCSI controller 1,noSharing,[vmfs-nl-archive] arch-fs01/arch-fs01_1.vmdk,4204-d010-0005
bkp-proxy01,Hard disk 1,40960,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] bkp-proxy01/bkp-proxy01.vmdk,4204-d010-0006
batch01,Hard disk 1,61440,False,persistent,sharingNone,True,SCSI controller 0,noSharing,[vsan-prod] batch01/batch01.vmdk,4204-d010-0007
batch01,Hard disk 2,1048576,False,persistent,sharingNone,True,SCSI controller 1,noSharing,[vmfs-nl-archive] batch01/batch01_1.vmdk,4204-d010-0007resource "stackit_volume" "vm_arch_fs01_disk2" {
project_id = var.project_id
name = "arch-fs01-disk2"
availability_zone = var.availability_zone
size = 18000
performance_class = var.vmware_volume_performance_class
}
resource "stackit_server_volume_attach" "vm_arch_fs01_disk2" {
project_id = var.project_id
server_id = stackit_server.vm_arch_fs01.server_id
volume_id = stackit_volume.vm_arch_fs01_disk2.volume_id
}Kapazität wird übernommen, der Datastore nicht
Das Volume hat size 18000, die Kapazität der Quellplatte in GiB, und die gemeinsame Variable für die Performance-Klasse. Aus welchem Datastore die Platte stammt, steht nicht in der Datei.
Vor der Größe warnt der Entwurf nicht
18000 GiB sind rund 17,6 TiB. Die STACKIT-Seite zu den Konzepten nennt 16 TB als größtes Datenvolume. Der Lauf hat den Block ohne Befund dazu entworfen; prüfen Sie Plattengrößen daher selbst gegen dieses Limit.
Die Umgebung je Datastore
Berechnet aus dem Blatt vDisk oben. Die Datastore-Namen stammen aus der Demo; in Ihrem Export steht, was Ihre Pfade sagen.
| Datastore | VMs und Platten | Bereitgestellt |
|---|---|---|
| vsan-prod | 4 VMs, 5 Platten: crm-web01, crm-app01 (2), bkp-proxy01, Boot-Platte von batch01 | 440 GiB |
| vmfs-ssd-db | 2 VMs, 4 Platten, alle thick: crm-db01 und crm-db02 mit je 100 GiB und 800 GiB | 1800 GiB |
| vmfs-nl-archive | 2 VMs, 3 Platten: arch-fs01 (50 GiB und 18000 GiB), Datenplatte von batch01 (1024 GiB) | 19074 GiB |
| Gesamte Umgebung | 7 VMs, 12 Platten | 21314 GiB |
batch01 liegt auf zwei Tiers: Die Boot-Platte auf vsan-prod, die Datenplatte auf vmfs-nl-archive. Der Lauf hält den Datastore deshalb je Platte fest.
Was der Lauf als Entscheidung zurückgibt
Aus der Aktionsliste desselben Laufs. Beide Einstellungen gehen an den Platform Architect; die Variable darunter ist die eine Performance-Klasse, die der Entwurf auf jedes Datenvolume anwendet.
- `datastore` (Platform Architect; decision register record DEC-OPS-VM-ARCH-FS01)
- Why: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. The datastore (the [name] prefix of the vInfo Path) carries the storage tier; the draft takes stackit_volume.performance_class from the variable vmware_volume_performance_class, so the source placement is a person's input, not carried.
- Done when: A person confirms the value against the target, or the knowledge base gains a rule that decides this setting.
- `disk-datastore` (Platform Architect; decision register record DEC-OPS-VM-ARCH-FS01)
- Why: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. Each disk's datastore says which performance class its volume needs; the draft applies one performance-class variable to every data disk, so the per-disk placement is not carried.variable "vmware_volume_performance_class" {
type = string
description = "STACKIT block-storage performance class for migrated VM data disks."
}Eine Variable für alle Tiers
Der Entwurf wendet eine Klasse auf jede migrierte Datenplatte an. Datenbank-Tier und Archiv-Tier kommen daher gleich heraus, bis Sie die Volume-Blöcke anpassen oder die Variable aufteilen.
Den Wert legen Sie fest
Die Quelle sagt nichts über IOPS, und der Lauf rät nicht. Füllen Sie die Variable mit einer Klasse aus der STACKIT-Seite zu den Serviceplänen.
VMware-Speicher im Vergleich zu STACKIT-Volumes
| Thema | VMware-Seite | STACKIT-Seite |
|---|---|---|
| Schutz der Daten | Bei vSAN legt die Speicherrichtlinie die Failures to tolerate fest: n Ausfälle bedeuten n+1 Orte für jedes Datenstück, und ein Objekt von 100 GB belegt mit RAID-1 200 GB. Bei VMFS hängt es vom darunterliegenden Speichersystem ab, das RVTools nicht sieht. | Im Ruhezustand mit AES-256 verschlüsselt; für Volumes gibt es Snapshots sowie volle und inkrementelle Backups. Der Schutz ergibt sich aus dem Setup, nicht aus einer Richtlinie: Single-AZ-Daten werden nicht zonenübergreifend gespiegelt, Metro-Daten über zwei Zonen. Eine mit FTT vergleichbare Kopienzahl wird nicht genannt. |
| Zu planende Kapazität | Bei vSAN enthält die belegte Kapazität den Aufschlag der Richtlinie: 100 GB mit RAID-1 bei FTT 1 belegen 200 GB. | Dimensionieren Sie nach der bereitgestellten Kapazität der VM-Platten, nicht nach der Datastore-Belegung. |
| Leistung | Vom Tier oder der Richtlinie des Datastores bestimmt. | Eine Performance-Klasse je Volume, unabhängig von der Größe. perf2 nennt 1000 IOPS und 100 MB/s, perf6 nennt 5000 IOPS und 200 MB/s; die Seite führt höhere Klassen weiter. |
| Gemeinsame Nutzung | Multi-Writer-Platten auf VMFS oder vSAN. | Kein Multi-Attach; ein Datenvolume gehört zu einem Server. |
| Größe ändern | Platten lassen sich vergrößern, und Thin-Platten bleiben klein. | Wachsen nur im abgehängten Zustand; kein Schrumpfen. Entworfene Größen entsprechen der Quellkapazität. |
| Größte Platte | Was die Quellplatte hat; die Demo enthält eine Platte mit 18000 GiB. | 1 GB bis 16 TB je Datenvolume. |
Backup-Aufbewahrung, Snapshot-Grenzen und die Auswahl eines Metro-Volumes stehen nicht auf den Seiten, die dieser Leitfaden nutzt, und die Seite zu den Serviceplänen nennt Leistungswerte nur für die Region eu01; klären Sie diese Punkte für Ihre Zielregion.
Entscheidungen, die bei Ihren Architekten liegen
Tier zu Klasse
Ordnen Sie vsan-prod, vmfs-ssd-db und vmfs-nl-archive drei Klassen zu oder einer. Messen Sie vor der Entscheidung die lastreichste Stunde der Quelle.
Größe nach bereitgestellt oder belegt
Das Blatt vInfo nennt je VM die bereitgestellten und die belegten MiB. Volumes schrumpfen nicht; eine Thin-Platte mit 1024 GiB, die zur Hälfte leer ist, sollte daher ein kleineres Volume bekommen, das Sie bei Bedarf vergrößern.
Die Platte mit 18000 GiB
Sie überschreitet das Volume-Maximum. Verteilen Sie den Inhalt auf Anwendungsebene auf mehrere Volumes oder ersetzen Sie den Dateiserver durch Objektspeicher oder einen Dateidienst; der Lauf kann das nicht für Sie entscheiden.
VMs über mehrere Tiers
batch01 braucht für das Datenvolume eine andere Klasse als für das Boot-Volume. Mit einer einzigen Variable lässt sich das nicht abbilden.
Snapshots auf bkp-proxy01 und crm-app01
Der Lauf meldet Snapshots auf beiden. Konsolidieren Sie vor der letzten Kopie; migriert wird nur der aktuelle Stand.
Wie die Daten umziehen
Üblich sind eine Blockkopie der Platte, ein Datei-Abgleich wie rsync oder eine Kopie auf Anwendungsebene wie Datenbank-Replikation. Das ist gängige Praxis, nichts, was der Lauf wählt oder ausführt.
Fragen zu VMFS, vSAN und STACKIT
Unterscheidet der Lauf VMFS von vSAN?
Nein. Er liest den Datastore-Namen aus dem Pfad und kennt weder Datastore-Typ noch vSAN-Richtlinie noch die Kapazität des Datastores. Dieses Inventar führen Sie aus vCenter.
Hat die vSAN-Richtlinie eine Entsprechung bei STACKIT?
Nicht als Richtlinie. FTT und RAID-5/6 sind vSAN-Einstellungen. Bei STACKIT wählen Sie je Volume eine Performance-Klasse und ein Single-AZ- oder Metro-Setup: Single-AZ-Daten werden nicht zonenübergreifend gespiegelt, Metro-Daten über zwei Zonen. Für Daten, die Zonenredundanz brauchen, ist Metro die dokumentierte Option; Backups sind eine eigene Entscheidung.
Warum nutzt der Entwurf nur eine Performance-Klasse?
Weil der Export nicht sagt, was jede Platte braucht. Der Lauf nennt das selbst und überlässt die Wahl je Platte einer Person.
Wo sehe ich die Datastore-Entscheidung?
In execution/manual/actions.md unter den Einstellungen datastore und disk-datastore jeder VM sowie im Entscheidungsregister des Laufs.
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.