I was working on a customer design recently for Hyper-V Replica. The customer was going to have their own dedicated DR site, using Hyper-V Replica for DR replication. It looks something like this:
All production VMs would run in the primary site on a WS2012 Hyper-V cluster. Hyper-V Replica would replicate VMs to the DR site, and remain in the cold offline state until the business continuity plan (BCP) was invoked in response to a disaster. Test failovers could be conducted (this uses copies of the replica VMs). All good so far!
The DCs in the primary site would run WS2012. Using VMGeneration-ID and cluster bootstrapping, those DCs can be virtualised. This bootstrapping works for both the primary and secondary site clusters. Excellent! Less hardware is required. That VMGeneration-ID feature also means we can consider replicating virtual WS2012 DCs using Hyper-V Replica to the secondary site.
What happens if we have a disaster and for some reason the primary site virtual DCs refuse to come online after being failed over to the DR site? I know, it’s a longshot. But so is the disaster that could shut down the primary site. If this happens then there goes your business because all of your on-premises services are tied to that domain.
When it comes to AD, I am very cautious. I like having it available and online. And AD replication is pretty solid.
Options?
Run a virtual DC in the public cloud? Sure, you could. There’s a cost to that. But, if there is a disaster, and like with 9/11, the Internet becomes swamped, good luck at authenticating and authorizing against a DC across a VPN link. If that happens, your BCP fails.
What about running a DC in the DR site? Yes, a virtual DC could be installed in the secondary site and left to replicate via normal means via a VPN across the DR link. That will do the trick … if you’re ultra-cautious like myself.
The problem I’m countering with this design option is a very low risk. I’m being very conservative and keeping my options open, e.g. if I ran a mid/large environment again, I’d run virtual DCs and back them up as VMs (VMGeneration-ID), use an agent in a single DC to get a system state backup, and use Windows Server Backup to also get a system state backup. In my mind, you can’t have enough options for restoring an AD. It’s like triple-insuring yourself, but at least I would have contingency plans when Murphy comes calling and the brown stuff hits the fan.
I have actually made the same call myself. I use Replica in my home deployment and I setup DCs on either side – simply so that I can have 100% guarantee that AD services are available no matter what happens.
This was my conslusion with a customer this morning as well. Having a working DC on the DR site is still low cost and makes you sleep well 🙂
PDC could not be cloned, must be WS 2012 and also should be online. If the PDC is not running at DR site there is no sense to have DC replica there!? Or i am wrong?
As you said a running virtual DC at the DR site is best choise and maybe the only way 🙂
You can seize the roles in the DR site if you really need to. PDCE is best kept where all the activity is, i.e. the production site.
Quick question, how do I ensure clients are using my production DCs to authenticate and not the DR? I guess it could be a slow logon if the client tries to go over VPN to authenticate.
This is AD fundamentals: configure your sites and subnets and place your DCs correctly in AD Sites & Services.