On Fri, Feb 5, 2016 at 2:18 PM, Brian Desmond <[email protected]> wrote: > Essentially you’re circumventing AD’s replication engine with something that > isn’t going to enforce consistency which has the potential to turn out very > poorly.
I'm not sure if this is truly the case here, tho. I will admit to being unfamiliar with VMware replication (as opposed to the way we do it, which is SAN replication via RecoverPoint). But in our situation, what is happening is that the LUN that holds the VM is being replicated (synchronously, in my case) to another LUN at a different site. Basically the LUN at the DR site is a non-active copy. So if the LUN at the main production site becomes unavailable, then the LUN at the DR site is marked as active copy, and the VM on that LUN is started. That doesn't interfere with AD replication, which happens via IP to other VMs/hosts. Effectively, the VM at the production site is shutdown, and then the *same* VM is powered on at the DR site. Effectively, it's just like replication failed temporarily. Same VM, same name, same IP, etc. I know that in my case, that is what happened - we had no replication breaks, corruption, etc. Granted, I do have other physical Dcs that never went offline, during this test. But I never had to seize roles, etc. The roles that were on Prod-DC-1 are still on Prod-DC-1 - it's just that Prod-DC-1 was inaccessible for a few minutes. It wasn't like it was out of commission for so long, it tombstoned. You'd get the same effect if you pulled the network cable out of Prod-DC-1 for 15 minutes, wouldn't you?
