De keuze tussen VMDK vs RDM voor Microsoft SQL Server-workloads in VMware is een cruciale beslissing die IT-beheerders moeten nemen bij het inrichten van hun infrastructuur. Beide bieden opslag voor gebruik met SQL Server in gevirtualiseerde omgevingen, maar welke optie de voorkeur verdient hangt af van de vraag of uw use case prioriteit geeft aan prestaties of aan flexibiliteit.
Deze gids legt de praktische verschillen tussen beide uit, zodat u de juiste keuze maakt voor het draaien van SQL Server onder VMware-virtualisatie.
Wat is VMDK?
Virtual machine disk (VMDK) is een draagbaar, krachtig en zeer schaalbaar virtueel schijfformaat dat wordt gebruikt in gevirtualiseerde omgevingen met VMware vSphere. Het gaat om een gevirtualiseerde harde schijf die eenvoudig van formaat kan veranderen en waarvan u een back-up, snapshot of herstel kunt maken. U kunt de schijf bovendien losmaken van en koppelen aan VM’s, wat VMDK flexibel en eenvoudig beheersbaar maakt.
Wat is RDM?
Raw device mapping (RDM) stelt VMware vSphere in staat om opslag rechtstreeks toe te wijzen aan een SAN-LUN (Logic Unit Number). Dat geeft directe toegang tot functies van de fysieke opslag. Het kan ook betere prestaties opleveren (al is dat voordeel ten opzichte van VMDK inmiddels kleiner, zoals hieronder wordt besproken) en het geeft software in gevirtualiseerde omgevingen – bijvoorbeeld clustersoftware – directe toegang tot de opslaghardware. Daar staan wel nadelen tegenover op het gebied van flexibiliteit, schaalbaarheid en beheer.
vVol is nog een opslagtechnologie van VMware vSphere, maar die wordt uitgefaseerd en zou niet meer in nieuwe implementaties gebruikt moeten worden. Bestaande gebruikers van vVol doen er goed aan te beoordelen of zij moeten migreren naar een andere ondersteunde opslagtechnologie.
Wat is het verschil tussen VMDK en RDM?
Samengevat: VMDK is een virtueel schijfbestand dat vanuit het virtualisatieplatform VMware vSphere wordt benaderd, terwijl RDM een VM rechtstreeks koppelt aan een fysiek opslagapparaat. Beide verschijnen als gewone volumes voor gast-besturingssystemen, maar er zijn verschillen die invloed hebben op SQL Server-workloads. Elke technologie heeft bovendien gevolgen voor prestaties en beheer.
Waar u op let bij de keuze van een VMware-opslagtechnologie voor SQL Server
De juiste keuze voor Microsoft SQL Server-workloads hangt af van uw use case, maar over het algemeen kiezen gebruikers om de volgende redenen voor VMDK.
Prestatieverschillen tussen VMDK en RDM
RDM geldt van oudsher als sneller dan VMDK, maar dat verschil weegt voor de meeste gebruikers nauwelijks nog mee in de afweging. VMDK is inmiddels sterk geoptimaliseerd voor prestaties, waardoor het praktische verschil minimaal is (soms niet meer dan 1%).
Prestatiewinst met RDM is tegenwoordig vooral workload-specifiek, met zeer beperkte use cases waarin het gastsysteem directe toegang nodig heeft tot functies van de opslaghardware.
Afwegingen in beheer en gebruik tussen gevirtualiseerde opslag en hardwareopslag
VMDK is aantoonbaar eenvoudiger te beheren dan RDM dankzij de volgende eigenschappen:
- Flexibele back-up en herstel in één beweging: VMDK ondersteunt snapshots, replica’s en klonen
- Eenvoudiger beheer: dankzij virtualisatie kunt u opslag naar wens inrichten, vergroten of verkleinen, optimaliseren en weer vrijgeven
- Portabiliteit en schaalbaarheid: opslag hot swappen en schijven of VM’s eenvoudig tussen omgevingen migreren
- Integratie met de virtualisatietools van VMware: u benut de voordelen van volledig gevirtualiseerde omgevingen optimaal in plaats van afhankelijk te zijn van specifieke onderliggende devices
Het ontbreken van snapshots en andere beheerfuncties maakt het bij RDM juist lastiger om een back-up te maken en terug te zetten, complexer om te onderhouden en minder draagbaar en schaalbaar. Daarbij zijn de compatibiliteit met en ondersteuning voor precies die functies die virtualisatie voor SQL Server-hosting aantrekkelijk maken beperkt.
Aandachtspunten voor SQL Server-workloads
Bij het plannen van de infrastructuur voor uw SQL Server-implementatie geeft u het beste prioriteit aan consistente schijfprestaties en aan betrouwbare back-up en herstel. Denk daarnaast na over de behoefte aan high availability-configuraties en over de voordelen van aanvullende virtualisatiefuncties. Mits correct gespecificeerd voldoet VMDK aan deze eisen.
Wanneer RDM nog steeds een bruikbaar alternatief is voor VMDK
Voor de meeste organisaties is VMDK de duidelijke keuze voor Microsoft SQL Server-workloads. Toch kan RDM nog nodig zijn bij specifieke hardware- en clusterconfiguraties die als uitzondering gelden. Ook oudere systemen of software die directe toegang tot de opslaghardware vereisen – bijvoorbeeld clustersoftware – kunnen RDM noodzakelijk maken.
Overweegt u RDM, denk dan goed na: zelfs VMware adviseert doorgaans VMDK, behalve bij workload-specifieke use cases of wanneer u legacy-eisen moet ondersteunen.
Prestaties bewaken, beheren en back-ups maken van VMware-hosts en VM’s
Eén van de belangrijkste voordelen van VMDK is de mogelijkheid om snapshots te maken, zodat u kunt terugkeren naar een bekende goede staat of een volledige back-up kunt terugzetten. Voor systemen die op VMDK of RDM draaien is het belangrijk om problemen snel te kunnen vaststellen, zeker in gedistribueerde systemen, en om bij een storing of een cybersecurity-incident een volledig systeem te kunnen herstellen.
NinjaOne biedt VMware-monitoring en -beheer als onderdeel van een complete IT-toolchain die endpoint management, cybersecuritytools en netwerkbeheer samenbrengt voor overzicht over uw volledige IT-infrastructuur: op locatie, in de cloud en gevirtualiseerd.
Quick-start guide
De VM-mogelijkheden van NinjaOne:
– VM-bewaking: NinjaOne kan zowel Hyper-V als Virtual Monitoring (VMWare) – NinjaOne monitoren
– SQL Server-back-up: NinjaOne Device Backup kan een back-up maken van machines waarop Microsoft SQL Server draait (met VSS-ondersteuning voor databaseconsistentie)
– Beheer van VM-hosts: NinjaOne kan VM-hosts beheren en acties uitvoeren op VM’s
Wat NinjaOne niet dekt:
De keuze tussen VMDK en RDM is een architectuurbeslissing over de VMware-infrastructuur en valt buiten het bereik van NinjaOne. Die beslissing ligt doorgaans bij:
– VMware-beheerders
– Infrastructuurteams
– Storage-architecten
