Een vraag die mij zeer regelmatig wordt gesteld betreft het al dan niet virtualiseren van Active Directory Domain Controllers.
Om maar meteen met mijn advies in huis te vallen: Virtualiseren van Domain Controllers kan uitstekend, maar er zijn wel enkele zaken waarmee men rekening moet houden. Ik adviseer vrijwel altijd om 1 DC (het aantal is uiteraard afhankelijk van de grootte en de opbouw van de omgeving) gecombineerd met DNS en (stand-by) DHCP op fysieke hardware te draaien.
Waarom toch nog een fysieke DC? Veel omgevingen maken gebruik van een virtualisatie platform en de bijbehorende management oplossing. Vaak wordt daarbij gebruik gemaakt van Accounts en groepen binnen Active Directory om rechten uit te delen voor het beheer van datzelfde virtualisatie platform. Een storing aan dat platform (of aan de onderliggende storage!) kan ertoe leiden dat de virtuele servers niet meer bereikbaar zijn, inclusief de Domain Controllers. En ja, hoe ga je dan inloggen op je management oplossing waarmee je je virtualisatie platform beheert…. (daar zijn uiteraard wel oplossingen voor, maar dat moet je je dan wel van tevoren bedenken). Daarnaast zijn er vaak nog fysieke servers, appliances (telefooncentrales, firewalls, netwerk apparatuur etc.), of fat clients die baat hebben bij een fysieke DC (vaak gecombineerd met DNS en DHCP). Dan draaien die in ieder geval (al dan niet gedeeltelijk functioneel) door als de virtuele servers even niet bereikbaar zijn.
Mag je dan niet alle DC’s virtualiseren? Jawel, en daar kunnen prima argumenten voor zijn, maar zoals zoveel in de IT is het een kwestie van afwegen en keuzes maken…
Waar moeten we rekening mee houden bij het virtualiseren van Domain Controllers?
Write back wordt automatisch uitgeschakeld op een DC
Normaliter wordt write back caching automatisch uitgeschakeld op een DC om zodoende meer zekerheid te bieden bij bijvoorbeeld stroomuitval. De meeste virtualisatie platformen herkennen dit en houden hier rekening mee (FUA, Forced Unit Access). Daarnaast zal hopelijk vrijwel iedereen zijn fysieke hosts met 2 voedingen en een UPS uitrusten…
Maak op de juiste wijze backups, geen snapshots!
Wordt vaak vergeten, backuppen kan immers op andere manieren in een virtuele omgeving en snapshots zijn zo gemakkelijk…. Gebruik echter nooit snapshots om een DC te restoren of terug te zetten. Snapshots worden NIET ondersteund, de Domain Controller zal dan niet gaan repliceren en wat dan rest is het het verwijderen en opnieuw installeren van die DC… Dat laatste is sinds Windows Server 2008 trouwens simpel, gooi gewoon het DC computerobject weg, ntdsutil is niet meer nodig.
Uiteraard moet er als absoluut minimum 1 backup op de juiste wijze plaatsvinden binnen de ‘tombstone lifetime’. Die is 60 dagen voor 2003 en 180 dagen voor 2008 (R2). Een backup terugzetten die ouder is dan dat geeft issues… (en ja ik kom het weleens tegen dat er zo lang geen goede AD backup is gemaakt…)
Er zijn meer dan genoeg backup producten, zelf gebruik ik onder 2003 vaak ntbackup voordat ik met werkzaamheden aan / upgrades van AD begin, lekker makkelijk, snel en gegarandeerd te restoren. En in de praktijk blijkt dat af en toe een restore test doen geen kwaad kan ;-)
Let er in het kader van de tombstone tijd ook op dat een VM niet te lang uit staat, hiervoor geldt hetzelfde als voor een fysieke server.
Disk configuratie
Ga geen oude virtuele disks files kopiëren/terugplaatsen van Domain Controllers, hiermee kun je niet restoren! Het gebruik van ‘passthrough disks’ kan ook een optie zijn, al zal niet iedereen die gebruiken. Maak bij voorkeur gebruik van fixed virtual disks in plaats van differentials.
Beveiliging
Domain Controllers bevatten gevoelige informatie, het is belangrijk dat men zich realiseert dat beheerder van het virtualisatie platform meestal ook toegang heeft tot de VM’s (in ieder geval tot de disken). De vergelijking gaat enigszins op met fysieke toegang tot de serverruimte.
Let op met klonen, P2V etc.
Bij klonen is het altijd goed om SYSPREP te gebruiken, dit is natuurlijk bij Domain Controllers extra belangrijk. Twijfels over de status van de template? Installeer dan gewoon een schone server, het kost weinig tijd en dan weet je zeker dat de DC op een zuiver OS wordt geïnstalleerd.
O ja, ik hoef natuurlijk niet te zeggen dat het klonen van DC’s uit den boze is…
Voor P2V geldt dat dit in offline mode moet gebeuren zodat een consistente DC wordt gevirtualiseerd, er wordt dan gebruik gemaakt van Windows PE om het OS om te zetten naar een VM. Je kunt natuurlijk ook van de gelegenheid gebruik maken om je DC’s direct te upgraden naar 2008 R2 door virtuele in te richten en de fysieke uit te faseren.
Draai virtuele DC’s op aparte hosts
Het is aan te raden om de DC’s die wel virtueel draaien te verdelen over de diverse hosts, zodat het uitvallen van 1 fysieke host niet direct alle virtuele DC’s raakt.
Let op de tijdsynchronisatie
De tijd is belangrijk binnen een Active Directory. AD heeft zelf een prima tijdsynchronisatiemechanisme, normaliter hoeft alleen de PDC emulator de tijd met een externe bron te synchroniseren, de rest van alle domain members volgt dan automatisch. Echter, het virtualisatie platform kan roet ik het eten gooien door zich met de tijd van de virtuele DC’s te bemoeien… Schakel dus synchronisatie met de host (het virtualisatie platform) uit en gebruik de standaard time commando’s om de tijdsynchronisatie in te stellen. Grote tijdverschillen binnen AD zorgen voor authenticatie issues.
Samengevat
Het virtualiseren van Domain Controllers is, als je rekening houdt met bovenstaande, geen enkel probleem en het wordt ook steeds vaker gedaan. Laat echter 1 fysieke DC over voor het geval dat….