Using VMs for offsite disaster recovery - IP range problem
Hi
We're currently testing a disaster recovery solution for a network with a number of WinXP machines, and a number of servers. The primary server is SBS2003, which acts as the domain controller and Exchange server, and a number of other servers, with various functions (one is a terminal server, another is a backup DC and printer server, one runs a bespoke database application etc).
The idea is that we take images of each server, convert them into virtual machines and the set them up as an offsite network. We're using VMware Server for this. Each VM has been configured with a bridged connection so it will act exactly like a normal machine on a network.
The problem that we've run into is that in order to bring each VM machine online in place of the usual live machine, they need to have a VPN connection to the main network (no problem there). However, if we want the VMs to talk to each other, we've found it extremely problematic if they are not on their original IP range. The problem comes in that if they are on their original range, we get conflicts when we try to get them back on the original network via the VPN, because they are on the same range.
A second issue is that in the event of a disaster and the entire main network goes down, we will need the VMs to be on the original IP range so that the users can VPN on to the DR network!
So that's the background. My main question is, when setting up a VM network using imaged servers, is it advisable to change the IP range of the imaged machines to facilitate the VPN connections working, or to leave the IP range the same? How is this type of environment best configured with regards to getting the VMS and the original network talking?
Thanks
We're currently testing a disaster recovery solution for a network with a number of WinXP machines, and a number of servers. The primary server is SBS2003, which acts as the domain controller and Exchange server, and a number of other servers, with various functions (one is a terminal server, another is a backup DC and printer server, one runs a bespoke database application etc).
The idea is that we take images of each server, convert them into virtual machines and the set them up as an offsite network. We're using VMware Server for this. Each VM has been configured with a bridged connection so it will act exactly like a normal machine on a network.
The problem that we've run into is that in order to bring each VM machine online in place of the usual live machine, they need to have a VPN connection to the main network (no problem there). However, if we want the VMs to talk to each other, we've found it extremely problematic if they are not on their original IP range. The problem comes in that if they are on their original range, we get conflicts when we try to get them back on the original network via the VPN, because they are on the same range.
A second issue is that in the event of a disaster and the entire main network goes down, we will need the VMs to be on the original IP range so that the users can VPN on to the DR network!
So that's the background. My main question is, when setting up a VM network using imaged servers, is it advisable to change the IP range of the imaged machines to facilitate the VPN connections working, or to leave the IP range the same? How is this type of environment best configured with regards to getting the VMS and the original network talking?
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ylandrum: The idea was to have a system where we could bring up a single server, or the whole network. We're syncing our data across to our DR server using the ViceVersa software, over asecondary network created using Hamachi, and the VMs have mapped network drives corresponding to the live servers physical drives that look at the correct data, so the idea is as long as the image is up to date, the data is already on the DR box.
Setting 2 network adapters sounds like a good solution. Currently the DR box hosting the VMs is on the same IP range as our main network, which obviously stuffs us a bit if we need to VPN one of the servers back into the main network. So just to get this clear, I would set the DR box / VMs on a different IP range to our main system, to facilitate bringing up a single VM in the event of a live server going down, but configure them all with disabled 2nd network adapters which would come online in the event of a complete disaster where we had to bring up the entire network in a DR environment. In this instance, we would have to reconfigure the DR host box and local network as well to be on the same range as the live (or in this case, dead!) network, and then users would VPN to the DR site rather than the live site.
Do I have that about right? Cheers!
Setting 2 network adapters sounds like a good solution. Currently the DR box hosting the VMs is on the same IP range as our main network, which obviously stuffs us a bit if we need to VPN one of the servers back into the main network. So just to get this clear, I would set the DR box / VMs on a different IP range to our main system, to facilitate bringing up a single VM in the event of a live server going down, but configure them all with disabled 2nd network adapters which would come online in the event of a complete disaster where we had to bring up the entire network in a DR environment. In this instance, we would have to reconfigure the DR host box and local network as well to be on the same range as the live (or in this case, dead!) network, and then users would VPN to the DR site rather than the live site.
Do I have that about right? Cheers!
Yes, sounds like you've got it.
I am intrigued by Dextertronic's idea though...
I am intrigued by Dextertronic's idea though...
In your prod site have two subnets each on their own VLAN.
e.g. 192,168.1.1 for servers and 192.168.1.2 for workstations
When you do a DR test take the local 192.168.1.1 VLAN offline then bring it online in your DR centre.
Restore your servers as you would normally.
You can the happily route between the 1.1 subnet and the 1.2 subnet with addition of a route on your main switch.
The next step is to have a third subnet in your DR centre which is permanently enabled containing a DC for AD replication and a cold swap exchange server running replication; or in your case just the one box running SBS and a software package like Doubletake for SBS which would allow you to do High Availbility Failover to your DR centre SBS box with a single click with near to real time replication of data..