VMWARE → STACKIT · OPSLAG
VMFS- en vSAN-opslag plannen voor de overstap naar STACKIT
RVTools noemt in zijn paden de datastore van elke VM en disk, maar zegt niet of die datastore VMFS of vSAN is en bevat geen vSAN-policy. StackToIT werkt daarom elke datadisk uit als een volume van dezelfde grootte met één variabele voor de prestatieklasse. Opslagplanning voor STACKIT is een korte inventarisatie per datastore en één beslissing per tier; deze pagina toont beide aan de hand van een demo-omgeving van zeven VM's.
Opslagplanning in vijf stappen
Lees de datastores
Elke diskrij van de vDisk-sheet bevat een pad dat begint met de datastore tussen rechte haken. De vInfo-sheet doet hetzelfde voor het configuratiebestand van de VM. De run legt de naam tussen haken vast als datastore van de VM en, per disk, als datastore van die disk, en geeft beide terug als instellingen waarover u beslist.
Tel ze op per datastore
Tel de ingerichte capaciteit op en tel de VM's per datastore. Een datastore is meestal een tier: dezelfde hardware, hetzelfde beleid, dezelfde eigenaar.
Geef elke tier een prestatieklasse
STACKIT kiest de prestatieklasse wanneer u een volume aanmaakt. Beslis per tier welke klasse nodig is, op basis van gemeten IOPS en doorvoer op de bron, niet op basis van de naam van de datastore.
Controleer de volumeregels
Een datavolume is 1 GB tot 16 TB groot, wordt aan één server tegelijk gekoppeld en kan alleen groeien terwijl het is losgekoppeld. Een Single AZ-volume ligt vast in één availability zone en wordt niet over zones gespiegeld; een Metro-volume wordt over twee zones gespiegeld.
Kies hoe de data wordt verplaatst
De run somt de volumes op en kopieert geen enkele byte. Kies per tier een methode, op basis van de omvang en de downtime die de applicatie verdraagt.
De demo-omgeving in de vDisk-sheet
Een demo-omgeving, voor deze pagina geschreven en op 4 november 2026 door StackToIT beoordeeld: drie port groups, zeven VM's op drie datastores. Links: de hele vDisk-sheet. Rechts: het datavolume dat de run uitwerkt voor de grote disk van arch-fs01; beoordelingscommentaren boven de blokken zijn weggelaten.
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
}De capaciteit wordt overgenomen, de datastore niet
Het volume krijgt een grootte van 18000, de capaciteit van de brondisk in GiB, en de gedeelde variabele voor de prestatieklasse. Van welke datastore de disk kwam, komt niet in het bestand terecht.
Het concept waarschuwt niet voor de grootte
18000 GiB is ongeveer 17,6 TiB. De pagina met concepten van STACKIT noemt 16 TB als grootste datavolume. De run werkte het blok uit zonder bevinding hierover, dus toets de diskgroottes zelf aan die limiet.
De omgeving per datastore
Berekend uit de vDisk-sheet hierboven. De namen van de datastores zijn die van de demo; in uw export zijn het de namen die uw paden vermelden.
| Datastore | VM's en disks | Ingericht |
|---|---|---|
| vsan-prod | 4 VM's, 5 disks: crm-web01, crm-app01 (2), bkp-proxy01, bootdisk van batch01 | 440 GiB |
| vmfs-ssd-db | 2 VM's, 4 disks, allemaal thick: crm-db01 en crm-db02 met elk 100 GiB en 800 GiB | 1800 GiB |
| vmfs-nl-archive | 2 VM's, 3 disks: arch-fs01 (50 GiB en 18000 GiB), datadisk van batch01 (1024 GiB) | 19074 GiB |
| Hele omgeving | 7 VM's, 12 disks | 21314 GiB |
batch01 staat op twee tiers: de bootdisk op vsan-prod en de datadisk op vmfs-nl-archive. De run legt de datastore per disk vast juist daarom.
Wat de run als beslissing teruggeeft
Uit de actielijst van dezelfde run. Beide instellingen gaan naar de Platform Architect, en de variabele hieronder is de enige prestatieklasse die het concept op elk datavolume toepast.
- `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."
}Eén variabele voor alle tiers
Het concept past één klasse toe op elke gemigreerde datadisk, dus een databasetier en een archieftier komen identiek uit totdat u de volumeblokken aanpast of de variabele splitst.
De waarde is aan u
De bron zegt niets over IOPS en de run gokt niet. Vul de variabele in met een klasse van de pagina met STACKIT-serviceplannen.
VMware-opslag tegenover STACKIT-volumes
| Onderwerp | VMware-kant | STACKIT-kant |
|---|---|---|
| Bescherming van de data | Op vSAN stelt de storage policy Failures to tolerate in: n storingen betekenen n+1 plaatsen voor elk stuk data, en een object van 100 GB verbruikt 200 GB met RAID-1. Op VMFS hangt het af van het opslagsysteem eronder, dat RVTools niet ziet. | Versleuteld in rust met AES-256; voor volumes bestaan snapshots en volledige en incrementele back-ups. Bescherming kiest u met de inrichting, niet met een policy: Single AZ-data wordt niet over zones gespiegeld, Metro-data wordt over twee zones gespiegeld. Een aantal kopieën vergelijkbaar met FTT wordt niet genoemd. |
| Te plannen capaciteit | Op vSAN omvat de verbruikte capaciteit de overhead van de policy: 100 GB met RAID-1 bij FTT 1 verbruiken 200 GB. | Dimensioneer vanuit de ingerichte capaciteit van de VM-disks, niet vanuit het gebruik van de datastore. |
| Performance | Bepaald door de tier of de policy van de datastore. | Een prestatieklasse per volume, onafhankelijk van de grootte. perf2 noemt 1000 IOPS en 100 MB/s, perf6 noemt 5000 IOPS en 200 MB/s; de pagina vervolgt met hogere klassen. |
| Delen | Multi-writer-disks op VMFS of vSAN. | Geen multi-attach; één datavolume hoort bij één server. |
| Grootte wijzigen | Disks kunnen groeien en thin disks blijven klein. | Groeien kan alleen terwijl het volume is losgekoppeld; krimpen kan niet. De uitgewerkte groottes zijn gelijk aan de broncapaciteit. |
| Grootste disk | Wat de brondisk heeft; de demo heeft een disk van 18000 GiB. | 1 GB tot 16 TB per datavolume. |
Bewaartermijn van back-ups, snapshotlimieten en hoe een Metro-volume wordt gekozen worden niet genoemd op de pagina's die deze gids gebruikt, en de pagina met serviceplannen noemt alleen prestatiecijfers voor de regio eu01; bevestig ze voor de regio die u beoogt.
Beslissingen die bij de architect blijven
Tier naar klasse
Koppel vsan-prod, vmfs-ssd-db en vmfs-nl-archive aan drie klassen, of aan één. Meet het drukste uur op de bron voordat u beslist.
Dimensioneren op ingericht of op gebruikt
De vInfo-sheet vermeldt per VM de ingerichte en de gebruikte MiB. Volumes kunnen niet krimpen, dus een thin disk die op 1024 GiB is ingericht maar half leeg is, verdient een kleiner volume dat u laat groeien wanneer dat nodig is.
De disk van 18000 GiB
Die overschrijdt het maximum voor een volume. Verdeel de inhoud op applicatieniveau over meerdere volumes, of vervang de fileserver door een objectopslag of bestandsdienst; de run kan dit niet voor u beslissen.
VM's verspreid over tiers
batch01 heeft voor het datavolume een andere klasse nodig dan voor het bootvolume. De ene variabele kan dat niet uitdrukken.
Snapshots op bkp-proxy01 en crm-app01
De run meldt snapshots op beide. Consolideer vóór de laatste kopie; alleen de huidige status wordt gemigreerd.
Hoe de data wordt verplaatst
Gangbare methoden zijn een blokkopie van de disk, een synchronisatie op bestandsniveau zoals rsync, of een kopie op applicatieniveau zoals databasereplicatie. Dit is praktijk; de run kiest dit niet en voert het niet uit.
Vragen over VMFS, vSAN en STACKIT
Herkent de run het verschil tussen VMFS en vSAN?
Nee. De run leest de naam van de datastore uit het pad en kent geen datastoretype, geen vSAN-policy en geen capaciteit van de datastore. Haal die inventaris uit vCenter.
Heeft de vSAN-policy een equivalent op STACKIT?
Niet als policy. FTT en RAID-5/6 zijn vSAN-instellingen. Op STACKIT kiest u per volume een prestatieklasse en een Single AZ- of Metro-inrichting: Single AZ-data wordt niet over zones gespiegeld, Metro-data wordt over twee zones gespiegeld. Voor data die zoneredundantie nodig heeft, is Metro de gedocumenteerde optie; back-ups zijn een aparte beslissing.
Waarom gebruikt het concept één prestatieklasse?
Omdat de export niet zegt wat elke disk nodig heeft. De run meldt dat zelf en laat de keuze per disk aan een persoon over.
Waar zie ik de beslissing over de datastore?
In execution/manual/actions.md, onder de instellingen datastore en disk-datastore van elke VM, en in het beslissingsregister van de run.
Bronnen
Uw volgende stap: STACKIT.
Vertel ons over uw omgeving, dan laten wij zien wat StackToIT daarvoor oplevert: doelarchitectuur, Terraform-artefacten en een gestructureerd migratieplan.
Laat uw gegevens achter, onze specialisten nemen contact met u op.
Liever zelf een e-mail sturen? connect@stacktoit.com
Hartelijk dank.
Uw verzoek is bij ons binnengekomen. Onze specialisten nemen contact met u op.