Strategy for replication

[kzhang]

We have recently bought v 5.0. The backup is been going fine.
We now want to do a replication execercise to an offsite host.
First off, would it make sense to use a site-to-site VPN to the replication target? or is there other better altenatives?
Second, I'm guessing this is a networking question, if we do a fail over, would the VM's on the target host be able to communicate back to the main office via the site to site VPN?

thanks.

[Gostev]

1. Yes, and that's the only option really, at least today.
2. If you can ping main office VM from offsite host VM today, then sure!

[kzhang]

Thanks Gostev, I think my question is more of a network architecture question. Here's the scenario.

main office subnet: 192.168.1.x
vm's are also 192.168.1.x

VPN site: 192.168.2.x
The ESX host replication targets: 192.168.2.x
VM's that are replicated to this box are the ones from the main office: 192.168.1.x

If I do a failover / DR, I turn on one of these VM's in the DR box, will it even work since it lives in a different subnet?

as you can tell, I'm not a network admin. hope you understand my question.

[Gostev]

Hi, if you use static IPs on your VMs, this is not going to work... you may want to consider using DHCP instead of static IP addresses in both sites, or updating IP addresses manually after failover. Thanks!

[kzhang]

DHCP won't work since the vm's being replicated are all domain controllers, DNS, mail servers, SQl servers.
Here's what I'm thinking, bu I don't know if it makes sense.
in case of DR, Option 1: bring back the box to main office.
option 2; power on VM's at DR site, change Ip of all VM's, setup a terminal server for people to connect remotely.
Do these make sense?

what are other people practices when designing a DR solution?? whats other options are there for doing a failover?

[jfowler]

You can have hosts with different IP ranges on the same ESX host. In a DR environment, you can still keep the same IPs, you just need to have a router vm (Vyatta) or layer-3 switch as the default gateway which will point to the vpn/firewall for .1.x when your not in a DR scenario or back locally when you are in one.

[nickf]

We actually have the same IP ranges in DR which makes things easier, to do it we have layer 3 Cisco switches (3560's I think but I'm not a network guy either...)at each site and they connect via HSRP. By default the main site switches do the routing, if they fail then the DR site switches pick up the routing. For testing we just logically kill the WAN link between the two sites, bring up all the replica VMs in the DR site (main site VMs carry on running so there is no disruption and you can test during office hours). Remote connections into both the main and DR sites have routers at the remote sites with backup routes configured so if the link to the main office goes down the traffic is routed to the DR site (mostly we do this with manual control though as we usually don't want the traffic re-routing to the DR site if just the WAN link has gone down rather than the main office itself).

You just need to remember when testing to snapshot the replicas after bringing down the WAN link (so you preserve the state they were in after the last replication job, otherwise they won't match and you will need to re-seed the job) and shutdown the replicas post-testing and clean up the snapshots before bringing the link back up.