Meer en meer krijgen wij als consultant de vraag of het nuttig is om SQL Server te virtualiseren. Buiten het licentieverhaal, waar virtualisatie alleen al een enorme impact heeft, zijn er ook technische redenen om wel of niet te virtualiseren. Dit is vooral zo wanneer de bestaande omgeving veel kleine fysieke servers heeft of enkele grote machines met meerdere instances. In deze post lijsten we dan ook de voor- en nadelen op van het virtualiseren van SQL Server.

Wat vaak vergeten wordt, is dat instances een harde limiet hebben, deels wegens de hardware maar ook door de extra load die ze toevoegen aan het OS. Vaak vergeten we dat elke instance zijn eigen WMI-load genereert, vooral in combinatie met monitoringtools, maar dat de WMI-pool op OS-level afgehandeld wordt.

Belangrijkste issues voor multiple instances zijn back-ups, security en patch stability. Vaak moeten we hier helaas scalability aan toevoegen als alle instances alle resources mogen gebruiken (en wanneer dit niet gewijzigd kan worden). Los van de opsomming van de voor- en nadelen zal ik eerst deze drie eerst apart bekijken.

1. Back-ups:

Vaak worden bij multiple instances dezelfde (snapshot) back-up procedures gebruikt. Dit heeft meestal tot gevolg dat deze niet in parallel lopen maar eerder één snapshot-moment krijgen voor de gehele host. Daardoor bestaat er een risico dat als er een probleem is, meerdere instances geen geldige back-up hebben. Bij virtualisatie heeft elke host zijn eigen back-up agent, en daalt dit risico terwijl het parallelisme toeneemt.

2. Security:

Een vaak vergeten issue is dat als iemand admin-rechten heeft op één instance, het veel eenvoudiger wordt om zichzelf toegang te geven tot andere instances. SQL Server, vooral in combinatie met PowerShell, zorgt voor krachtige tools in de handen van iemand die goed weet wat hij of zij doet. Omgekeerd geldt ook en dit probleem wordt versterkt als alle instances met dezelfde service-accounts of het local system draaien.

Het volstaat om in SQL Server PowerShell volgende query te draaien en om alle instance-namen te verkrijgen: Get-ItemProperty ‘HKLM:\Software\Microsoft\Microsoft SQL Server\Instance Names\SQL’

Als we deze lijst eenmaal hebben, wordt het helaas alleen maar eenvoudiger om toegang te krijgen. Een andere manier is om via de SQL SA account jezelf local admin te maken en dan Windows authentication te gebruiken op de andere instances. Let op, dit kan op meerdere manieren. Wanneer de SQL Services op de verkeerde manier geïnstalleerd zijn, kan het zelfs via xp_cmdshell.

Bij VM’s wordt dit alles veel moeilijker omdat je jezelf dan toegang dient te geven tot de Host, wat vanuit de guest een stuk moeilijker wordt (tenzij je je SQL Server services onder een domain admin account laat draaien).

3. Stability:

Multiple instances hebben één groot probleem: ze zijn zeer moeilijk te patchen of uit te breiden omdat bij het uitvoeren van één patch het niet uitgesloten kan worden dat de andere instances hier geen effect van ondervinden. Zo zullen de client components iedere keer beïnvloed worden. Ook kan de installatie van een nieuwe instance zorgen voor een resource-verschuiving waar de andere instances ook last van kunnen hebben. Dit is zeker zo als er verschillende editions van SQL Server op dezelfde host moeten draaien. Bij een gevirtualiseerde omgeving waar we een instance per VM hebben, is deze impact veel kleiner. We kunnen dan zonder risico het rolling upgrade-principe van Microsoft toepassen zonder dat dit andere installaties zal beïnvloeden.

Omdat we bij virtuele servers gebruik kunnen maken van snapshots is het terugdraaien van patches veel sneller en betrouwbaarder, vooral omdat er geen restjes blijven staan. Om hier maximaal gebruik van te kunnen maken is het wel cruciaal dat SQL Server zelf voor de availability zorgt door bijvoorbeeld gebruik te maken van AlwaysOn.

Voordelen van virtualisatie

• Elke VM voegt zijn eigen HAL-level toe, hierdoor zal je WMI-issue opgelost worden
• VM’s schalen beter dan instances omdat er betere dynamische memory en CPU management mogelijk is. Hypervisor doet dit ook beter dan de individuele SQL instances
• Individueel resourceverbruik is per VM te monitoren en aan te passen
• Mogelijkheid om de machines onafhankelijk van elkaar te patchen en de maintenance windows beter te spreiden
• Je behoudt AlwaysOn als high availability, dus geen wijziging ten opzichte van de huidige set-up, maar je kan de individuele machines ook verplaatsen als er maintenance is aan één host, dit verhoogt effectief je availability
• Eenvoudiger om prod stabiel te houden omdat je per VM dedicated resources en prio’s kan toewijzen
• Diskmanagement hoeft niet complexer te worden, maar vereist minstens drie en liefst vier virtual drives per VM (OS, eventueel Temp, Data,Log); deze drives mogen niet thin provisioned zijn, of de DB-sizes moeten vooraf goed gesized zijn (netto-effect is hetzelfde)
• Manageability via CMS is identiek aan multiple instances
• Client side impact is minimaal; AlwaysOn listners blijven dezelfde
• Mogelijkheid om snel in te grijpen bij workload changes (hot plug RAM en/of CPU, move naar een minder belaste host, enzovoort)
• Machines kunnen snel afgeroepen worden via templates (templates moeten wel gemaakt worden, wat dan weer een nadeel is); maar de installatie van een nieuwe VM kan de bestaande omgeving niet destabiliseren
• Technieken zoals bijvoorbeeld Vmotion en dynamic load balancing kunnen ervoor zorgen dat je resourcegebruik optimaal is zonder al te veel manuele interventie.
• Kan sneller schalen als de omgeving moet groeien, je kan je VM’s eenvoudig over meerdere machines spreiden als het zou nodig zijn, met instances moet je ze opnieuw installeren en/of deactiveren
• Maakt het eenvoudiger om machines naar de cloud te verplaatsen (zoals de DR-node)
• Kan een hoger level van availability geven aan een standard edition
• Memory overhead is minder dan men denkt omdat de host via SLAT-pages die hetzelfde bevatten, maar één keer in memory draait; dit gaat bijvoorbeeld over OS, SQL Agent, SQL Engine, Drivers, waardoor de memory overhead zelfs kleiner is dan bij het werken met instances

Nadelen

• Gemiddeld tussen de 3 en 10% performance hit, moet gecompenseerd worden met RAM. Zeer CPU-intensieve servers virtualiseren daardoor niet zo goed.
• Overcommit van resouces moet goed gecontroleerd worden
• VM’s zijn gelimiteerd tot de max capacity van één numa-node qua CPU en RAM, anders krijgen we een zware performance hit
• Installatie moet gebeuren volgens een template omdat kleine verschillen ervoor kunnen zorgen dat de hypervisor zijn werk niet optimaal kan uitvoeren
• Windows patching moet geautomatiseerd kunnen worden, bijvoorbeeld met een WSUS (zie hier https://technet.microsoft.com/en-us/windowsserver/bb332157.aspx voor een gratis plug-in in Windows Server)
• Er wordt gewerkt met vcores (wat een SQL Server instance ziet als core); dit zijn dus threads en geen echte cores, dit wil zeggen dat een quad core-server in essentie vijf of zes vcores nodig heeft om dezelfde CPU-capaciteit te verkrijgen. Dit moet echter per instance bekeken worden.
• Werkt met een Standard Edition (of lager) maar om de meeste voordelen uit virtualisatie te halen is een Enterprise Edition met SA echt wel aan te raden.
• Je moet actief je resources managen; dat moet nu best door een samengesteld team van DBA’s en Hypervisor admins gebeuren