VM /ETC

Great post. The simple solution is often the most elegant.

For Windows 2003 guests, add a secondary IP address and default GW for the DR network.

For Windows 2008 and up, you use the Alternate Configuration (TCP/IP Properties) to set a complete different network configuration.

All VM in DR scope have 2 IPs for the 2 networks, Prod and DR. no need to create anything in vCenter. Even much simpler

There's quite a few missing bits, isn't there? What about if an app on the VM tries to communicate with another VM with a direct IP address – the IP addresses are different in the DR site, so that won't work.

Also, if you have two NICs then which NIC is used to route to a completely different network (e.g. http://www.google.com)? In this case, because the IP for google.com is on a different network the IP stack needs to know which NIC to route that request out of. Normally the default gateway is used – but in this case you need to pick the correct vSwitch vNIC depending on which site you are in – so how does this work?

It's the routing I don't quite understand – perhaps you have some screen shots of the ipconfig + route commands in the prod and dr vms?

Thanks!
Steve

Steve,

Great points. It's not a solution that eliminates all configuration changes, but to that point what solution is? Not even VMware SRM stands up to the routing measuring stick. Maybe the only true all encompassing solution is to configure a physical networking bridge between the DR site and the primary site so they are both on the same ip subnet. Then the ip addresses won't have to change. Can any of the physical networking config be pre staged to account for some of these routing challenges?

I just discovered this strategy yesterday so I don't have experience or screen shots with/of the implementation. I just threw the concept in a post to kick it around just like we are doing now! So thanks for making me think!

Some replies to your comments:

What about if an app on the VM tries to communicate with another VM with a direct IP address – the IP addresses are different in the DR site, so that won't work.

You're right, but those apps won't work with SRM, any other ip change automation, and even if you manually change them.You could change the app to look for a DR ip too or better yet a hostname. I know, easier said then done.

if you have two NICs then which NIC is used to route to a completely different network (e.g. http://www.google.com)? In this case, because the IP for google.com is on a different network the IP stack needs to know which NIC to route that request out of. Normally the default gateway is used – but in this case you need to pick the correct vSwitch vNIC depending on which site you are in – so how does this work?

Again, great point. I am assuming that if a gateway exists on both interfaces and there is routing available either gateway will work. That may cause a waste of cycles / effort as the VM figures out which way to go when it is resurrected at a new site, but it serves the main point which is get the VM online.

The major benefit is that last point. If the VM is online then the administrator responsible for the app can make the changes via RDP, web interface, remote console, etc. There is still a DR workflow to understand and complete, but the virtualization admin doesn't shoulder as much of the responsibility.

I'm assuming you have one default gateway that points all traffic for unknown networks to an IP on the known network that can route (ie. your router).

If you have two active NICs that have different network addresses, you still normally only have one default gateway plus any static routes.

For your solution to work you need more than this, probably multiple gateways with metrics.

See what I mean? There is more to this than meets the eye!

It might work if you could “switch off” the switch after all is configured. So on Primary Site the DR Switch would be off, and on the DR Site the Primary is off. This way the links of the according interfaces would be down, and no default gateway routing would happen over the “link down” interfaces.

Your next problem is then DNS resolution, if you are using hostnames and not direct ip's.

And for that I'm using a script that pushes out to all VMs up in DR the new values for DNS, GW and eventually WINS, Search Order and so on.
Here is a sample script for whom might be interested:
$lines = $(get-content “c:DRServersNewDNS.in”)
$backendDNS = “xxx.xxx.xxx.xxx”,”yyy.yyy.yyy.yyy”
$frontendDNS = “zzz.zzz.zzz.zzz”
foreach ($line in $lines) {
$parts = $line.Split(“,”,[StringSplitOptions]::RemoveEmptyEntries)
$strComputer = $parts[0]
$strComputer = $strComputer.TrimEnd()
$colItems = get-wmiobject -class “Win32_NetworkAdapterConfiguration” `
-computername $strComputer | Where{$_.IpEnabled -Match “True”}
foreach ($objItem in $colItems) {
if ($objItem.IPAddress -match “^xyz.abc”){
$objItem.SetDNSServerSearchOrder($backendDNS)
}else{
$objItem.SetDNSServerSearchOrder($frontendDNS)
}
}
}

Andy,

Thanks! That sounds like another great alternative for simplifying the
switch to a DR site.

Hi,

Wouldn’t be simpler just to replicate VMs as they are (same Ip/hostname) in DR?

IMO DR should be a dark environment and it should be only turned on when Production is not running.

So I am wondering if someone has experienced with this: SAN to SAN replication to DR and zero reconfiguration to get DR up and running.

Thanks,
-Nestor