• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1851
  • Last Modified:

VMWARE DR site subnet

Hi,
I have a newly installed MPLS network with a DR site linked via 10mb leased line and 27 ADSL2+ sites connected, I have tested the theory of if the main site goes down 192.168.1.0 then all the 27 sites can still see DR site 192.168.2.0. I have 2 VMWare hosts setup on main site with the VM's installed on DAS for testing, using Veeam I have replicated to DR site, the issue I am having is finding a suitable way for the VM's to run using the same IP scheme, is there a specific tested way of doing it?. I dont have any experience in VLan's but I am thinking it probably has something to do with it?
0
jdpipes
Asked:
jdpipes
  • 8
  • 5
  • 3
  • +2
1 Solution
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
There are a few ways on conducting or enacting a DR site

1. Change all the IP addresses at the DR Site.
2. Leave the IP addresses the same and extend your production LAN via VLAN across the WAN link.
3. Use VMware Site Recovery Manager.
http://www.vmware.com/products/site-recovery-m you'veanager/

As you discovered, extending you production LAN, to your DR site, is the easiest option. This would invole connecting your ESX servers via Trunk Ports to the Switches at the DR site, and using VLAN Tagging on the Trunk Ports, then creating Virtual Machine Network Port Groups that use the same VLAN Tag, traffic will then enter the correct VLAN.

0
 
Kerem ERSOYPresidentCommented:
Hi,

As far as I understand:
- You have 2 sites. 1 main site and a backup site.
- You have your ESX servers on both.
- For the time being your Virtual Machines are located over the DAS on each system.
- You've replicated your vVM's and DATA with Veeam and there2s no active replication.
- Your main site VM goes offline you can start the copy of same VM in the remote site.
- Your problem is when the VM runs in the remote site the IP address of your VM's are different.

If this is your problem you have 2 options:
- You'll have DNS servers at both sites. Whan you do a switchover you'll also switch DNS servers so that your clients will get the new address when they can't contact the new DNS.
- You'll install VMWare Site Recovery Manager and you'll also setup something like F5 Systems Big-IP in combination with SRM on both sites so that your IP's will stay the same after the switch.
Please check here: http://www.f5.com/pdf/deployment-guides/vmware-srm-dg.pdf

BTW don't forget that what you have now is a Proof of Concept work. So it has limited ability to run your WM from a remote location. This is it.  But a live Disaster Recovery system will require at least:
- Replicating VM's to the remote site on-line (Such as VSRM)
- Replication of your live application data to the remote site on Real Time (such as vStorage, veeam smartCDP, SAN replication etc.)
- Backup strategies

Cheers,
K.


To be in place.
0
 
bgoeringCommented:
You might want to look into something like vShield Edge (http://www.vmware.com/products/vshield-edge/overview.html)

"Get essential security capabilities including port group isolation, network security gateway services and web load balancing for performance and availability. vShield Edge is deployed as a virtual appliance to provide firewall,VPN, Web load balancer, NAT, and DHCP services. Eliminate the need for VLANs by creating a barrier between the virtual machines protected by vShield Edge and the external network for port group isolation."

This lets you set up an Internal network on ESX with the same IP addressing as your home site, and accessability to the outside world via NAT to the unique 192.168.2.0 subnet at the DR site.

Good Luck
0
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
Kerem ERSOYPresidentCommented:
@bgoering: I think vSheilp is more appropriate when you need load balancing i.e., Both nodes are active and this is not the case for most of the DR solutions. THhs solution is more at High Availability side of the solution than DR.

Cheers,
K.
0
 
jdpipesAuthor Commented:
Hi thanks for your opinions, the option of the extending the production LAN is more favourable for me, the other options have a pretty heft price tag, I am trying to save on costs, would anybody know if the extended LAN setup could be achived with the below HP switch, again cost savings!, I could then purchase 2 and get some testing done?
HP V1810-24G
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Yes, it supports VLANs.
0
 
jdpipesAuthor Commented:
for extending the production LAN using VLANS does the switch need to be layer 2 or 3?
Thanks
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
No, the switch needs to support VLAN tagging also called 802.1Q.

If you want to route via VLANs, then you need Layer 3 or a router.

0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
e.g. for network traffic to commiunicate from VLAN 10 to VLAN 20, it must route through layer 3.
0
 
jdpipesAuthor Commented:
sorry just so I get this right, if I do VLAN tagging 802.1Q then all I require are layer 2 switches?
0
 
jdpipesAuthor Commented:
or the mentioned HP v1810 24g?
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
yes, HP v1810 24g supports VLANs, we use two in the lab!

0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
check the spec sheet here

http://h18000.www1.hp.com/products/quickspecs/13447_na/13447_na.PDF

Page 2

VLAN support and tagging: support up to 64 port-based VLANs and dynamic configuration of IEEE 802.1Q VLAN tagging, providing security between workgroups
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
You need a switch that supports VLAN Tagging. 802.1Q.
0
 
jdpipesAuthor Commented:
Excellent help and well explained on a subject I am not experienced on
Thanks
0
 
bgoeringCommented:
VLANs are a layer 2 concept. In most cases I don't recommend tunneling a VLAN over a WAN connection - do you really want a single broadcast domain across your WAN? If so take a look at http://www.experts-exchange.com/Networking/Misc/Q_21711634.html for a discussion of some techniques for doing so.

You might be looking for some kind of IP failover routing - such as using BGP to move your production block of IP addresses to the DR site in the case of a disaster. But even in that scenario it is often best to have some layer of abstraction such as NAT...
0
 
Kerem ERSOYPresidentCommented:
I agree with bgoering It is not recommended to route a VLAN traffic over VLAN. If it were this simple why do you think both VMWare and other third parties have different products for DRS ove Remote LANs?

I don't thin ak working project could be implemented with just a switch and VLAN. Besides if you make VLAN's you would need to change the addresss once your VMs started at the remote location.
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
I just line to add one, we have many clients that do just this, extended their production VLAN between Production and DR sites. (with no additional VMware Products). When they enact a DR situation and test every six months, they shutdown the main production datacentre. So all traffic failsover to DR site.
0
 
daviddionneCommented:
Greetings,  I'm struggling with the "extend your layer 2" concept as an option for SRM.  It's my understanding that SRM has been designed as a datacenter DR or disaster recovery solution...as in the case where your datacenter (including all of it's network infrastructure) in one way or another becomes a smoking crater.

So for example, dc1 and dc2 each have a 6509, each 6509 has it's own dedicated tail and the 6509's are also interconnected by a 100G link.  dc1 tail is 1.1.1.2/30, dc2's tail is 2.2.2.2/30.  dc1-6509 is the vtp master with dc2-6509 as it's only client and I have only 1 public network 111.111.111.0/24 on vlan 111.  dc1-6509 vlan111 is 111.111.111.1, dc2-6509 vlan111 has no ip.  The 111.111.111.0/24 network is advertised to through 1.1.1.2.  vlan 222 is a private vlan used to provide synchronous replication.  SRM is protecting 50 publicly accessible vm's all with 111.111.111.0 addresses.

If dc1 and it's 6509 (the public route for 1111.111.111.0) gets wiped out of existence how could having previously HAD vlan 111 extended from dc1 to dc2 do anything for me?  At the very least I'd have to manually assign an ip to dc2's vlan111 and manually change 111.111.111.0 route advertisement to 2.2.2.2.

Sorry for the tone, i just can't believe how many times ive run across the "extend layer 2" as the answer for srm, which certainly has many outstanding uses for srm as long as as the datacenters are directly connected in some way but in my mind provides NO answers for srm during a disaster...but I could very easily be missing it all together.

To me this sounds like something perfectly suited for BGP or active/passive distributed LVS/TUN
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 8
  • 5
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now