Now before I get into a large debate on why you would want (or not want) to virtualize DCs. Keep in mind that DCs are not like other typical Windows servers (i.e. web, proxy, file, print, etc...). DCs are very finicky and don't respond well to hardware changes very easily and they are certainly heavily dependant on time synchronization across all the other DCs and global catalog (GC).
With that in mind, leverage the following ideals when virtualizing DC's onto a VMware platform...
- Time Synchronization - Control clock drifting by synchronizing with a reliable source (NTP to a root source that is shared across the domain) - This is due to the fact that idle VM's aren't granted the necessary CPU cycles necessary to ensure clock synchronization with the host. This also means you want to NOT synchronize the time with the host in VMware Tools. NTP is the way to go here and use a very reliable time source that controls time for all domain joined resources.
- Optimize network performance - This generally means ensure you have a reliable connection but also leverage teamed network interfaces on your virtual switch and set your link status to beacon probing so that if your links go down, you can ensure that you always have a reliable connection to the DC in the event of a network related event.
- DNS Optimizations - This can vary on the size of your organization but is more for large enterprises. Modify the weight and priority levels of your SRV records in DNS to ensure that the PDC Emulator FSMO role isn't inundated with requests which can result in slower application performance where they are specifically designed to contact the PDC.
- Database Replication - This simply means know how your sites/services are setup and where your replication connection points are at. This may mean using the AD Replication Monitor (replmon) to outline that information but it's vital to have (in a virtualized or physical AD environment).
- Establishing Appropriate Access Control - This is a no brainer, only Domain Admins or Enterprise Admins can login to a DC. Don't give everyone and their brother access to the console of a DC. vCenter permissions are very granular now with releases 4.x and up. Just be sure to exercise least privileges.
- HA and DRS - There are arguments on DCs in a vCenter cluster that has HA and DRS enabled. Some prefer affinity rules to ensure that the DC doesn't leave the physical host. In that case, don't specify a DRS aggressiveness that will vMotion the DC. However, HA restart priorities are a good idea to migrate the DC in the event of a host failure. Just specify a very high restart priority and set your isolation response to leave on (to avoid SYSVOL versioning mismatches due to time lapses)...
- Disaster Recovery - This is more process oriented than anything and should be in place regardless of whether you deploy virtual or physical DCs. This boils down to having a good backup plan and ensuring frequent backups of the DCs system state information. When doing a restoration, leverage Microsoft's best practices using both the authoritative and non-authoritative techniques.
Now with these best practices in mind we also want to avoid a few things as well. Here are the DON'TS on virtualizing DCs.
- Don't do snapshots. Leverage system state backups when needing to backup the system. This will capture/set the appropriate IDs and USNs of the appropriate areas where as a snapshot simply captures the data into memory and won't make the necessary preparations on the AD levels. The result could be SYSVOL mismatched versions which will significantly impact replication of policies and services like NETLOGON.
- Try not to suspend VMs for a long period of time. The result could be the same as previously mentioned regarding SYSVOL mismatched versioning.
- Never attempt to recover an Active Directory database from a backup copy of an old virtual disk. This is looked at as a significant hardware change and possible replication issue. Leverage the system state backups of the VM operations and Microsoft best practices for authoritative and non-authoritative techniques.
At the end of the day, proper engineering, planning, and coordination will successfully prepare an organization on virtualizing DC's. As a best practice, Microsoft recommends that you maintain at least one physical DC for consistency purposes in the event your virtual infrastructure were to encounter any catastrophic failures. As always, failover sites and COOP capabilities are key when designing any AD environment.
For more detailed information, please refer to the VMware white paper on Active Directory Virtualization below.
http://www.vmware.com/files/pdf/Virtualizing_Windows_Active_Directory.pdf
No comments:
Post a Comment