Comprehensive data protection for all workloads
Post Reply
kzhang
Influencer
Posts: 18
Liked: never
Joined: Nov 16, 2010 9:29 pm
Full Name: ke zhang
Contact:

Strategy for replication

Post by 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
SVP, Product Management
Posts: 26706
Liked: 4277 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Strategy for replication

Post by 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
Influencer
Posts: 18
Liked: never
Joined: Nov 16, 2010 9:29 pm
Full Name: ke zhang
Contact:

Re: Strategy for replication

Post by 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
SVP, Product Management
Posts: 26706
Liked: 4277 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Strategy for replication

Post by 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
Influencer
Posts: 18
Liked: never
Joined: Nov 16, 2010 9:29 pm
Full Name: ke zhang
Contact:

Re: Strategy for replication

Post by 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
Novice
Posts: 7
Liked: 1 time
Joined: Dec 17, 2009 5:00 pm
Full Name: Jeremy Fowler
Contact:

Re: Strategy for replication

Post by 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
Influencer
Posts: 19
Liked: never
Joined: Jun 22, 2010 3:11 pm
Full Name: Nick Ferrar
Contact:

Re: Strategy for replication

Post by 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.

Post Reply

Who is online

Users browsing this forum: No registered users and 24 guests