-
- Influencer
- Posts: 18
- Liked: never
- Joined: Nov 16, 2010 9:29 pm
- Full Name: ke zhang
- Contact:
Strategy for replication
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.
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.
-
- Chief Product Officer
- Posts: 31746
- Liked: 7250 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Strategy for replication
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!
2. If you can ping main office VM from offsite host VM today, then sure!
-
- Influencer
- Posts: 18
- Liked: never
- Joined: Nov 16, 2010 9:29 pm
- Full Name: ke zhang
- Contact:
Re: Strategy for replication
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.
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.
-
- Chief Product Officer
- Posts: 31746
- Liked: 7250 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Strategy for replication
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!
-
- Influencer
- Posts: 18
- Liked: never
- Joined: Nov 16, 2010 9:29 pm
- Full Name: ke zhang
- Contact:
Re: Strategy for replication
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?
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?
-
- Novice
- Posts: 7
- Liked: 1 time
- Joined: Dec 17, 2009 5:00 pm
- Full Name: Jeremy Fowler
- Contact:
Re: Strategy for replication
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.
-
- Influencer
- Posts: 19
- Liked: never
- Joined: Jun 22, 2010 3:11 pm
- Full Name: Nick Ferrar
- Contact:
Re: Strategy for replication
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.
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.
Who is online
Users browsing this forum: AdsBot [Google] and 2 guests