Part 2.5 - Disaster Recovery with SRM and vSphere Replication

Networking Revised

After adding a few more NICs to bubblebridge for the production Vlan's I realize that this starts to become ridiculous.
50 Vlans means 51 NIC's in bubblebridge...

 There has to be a better way!

So in my case I believe that this alternative setup for bubblebridge is more maintainable. In this scenario I create a vlan trunk for all vlans in the recovery setup. This means that there only has to be one NIC attached to the vlan trunk in the bubblebridge server. Unfortunately its still a ton of configuration to do.

This is the alternative setup and the steps to reach it.
  1. As root - fix the 70-persistent-net.rules file.
    
# This file was automatically generated by the /lib/udev/write_net_rules
    

    
# program, run by the persistent-net-generator.rules rules file.
    

    
#
    

    
# You can modify it, as long as you keep each rule on a single
    

    
# line, and change only the value of the NAME= key.
    

    


    

    
# PCI device 0x15ad:0x07b0 (vmxnet3)
    

    
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:96:7a:d6", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
    

    


    

    
# PCI device 0x15ad:0x07b0 (vmxnet3)
    

    
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:96:b2:81", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
  2. Change /etc/sysconfig/network-scripts/ifcfg-eth1 file
    

    

    
DEVICE=eth1
    

    
BOOTPROTO=none
    

    
NM_CONTROLLED=yes
    

    
ONBOOT=no
    

    
TYPE=Ethernet
  3. Add etc/sysconfig/network-scripts/ifcfg-eth1. example ifcfg-eth1.662le
    

    

    

    

    
DEVICE=eth1.662
    

    
BOOTPROTO=static
    

    
NM_CONTROLLED=yes
    

    
ONBOOT=yes
    

    
TYPE=Ethernet
    

    
IPADDR=172.18.51.251
    

    
NETMASK=255.255.255.0
    

    
VLAN=yes
  4. I opt for diablig of IPv6 by adding below to /etc/sysctl.conf
    

    

    

    

    
net.ipv6.conf.all.disable_ipv6 = 1
    

    
net.ipv6.conf.default.disable_ipv6 = 1
  5. To make it stick run
    

    

    

    

    
sysctl -p 

Bubblebridge and VLan trunking
The result of above should be a configuration like the one above. Even though there will be a ifcfg-eth1.XXX per VLAN its still much simplified.

Comments

Anonymous said…
Disaster recovery plan is essential for data backup recovery of lost data from the system. This blog provide very good information on disaster recovery development.
1:00 PM
Post a Comment

Popular posts from this blog

Possible SYN flooding on port 3306 (MySQL)

The system setup is such that the MySQL servers that put the "Possible SYN flooding on port 3306" in the log files only are exposed to system internal backend services. These in turn aren't exposed to the wild wild web. Fronting the system we have the servers publishing services to internet. Thus I was kind of stunned when the log messages started to appear and even though we had done a release of the system I found it far fetched that we should start to DOS our self. So why did the messages appear? Two different error messages could be identified in the log files and they seem to be related, especially since the Java servers with link failure do communicate with the MySQL servers. Possible SYN flooding on port 3306 @ MySQL server Communication link failure @ Java backend servers After some tcpdumping, head scratching and googling I think I have it down to the root cause, hidden in how TCP works in general, and the OS config in combi...
Read more

Part 1 - Disaster Recovery with SRM and vSphere Replication

Image
Abstract  The company I work for has needs for disaster recovery but there is also external demands for it. The company not being very big has so far not been able to implement any automated disaster recovery solution although we do have a documented disaster recovery plan. The plan regardless of how good or bad it is isn't tested in a long time and the RTO (Recovery Time Objective) is wished by management to be days but I can't see that it is anything else than weeks. Since we virtualized our production system I've been looking at VMware vCenter Site Recovery Manager as a driver but the cost array based replication has stopped any attempts dead in their tracks. VMware vSphere® Replication has been around for a while now and we hope that it's hardened enough for a slightly bigger production critical implementation. In this article I will try to document and explain how we experiment, design and implement disaster recovery and even more important, in my opinion...
Read more

Part 2 - Disaster Recovery with SRM and vSphere Replication

Image
In the previous article we went through the installation and configuration of the SRM and vSphere infrastructure. The time has now come to actually doing some tests and failover some VM's.  In the simple scenario I expect everything to go smoothly but there are a few things that I'm concerned about at this point since the protected environment I'm ultimately is failing over isn't so simple. It has multiple dvSwitches, vLans, load balancer, firewall, ldap, a set of test drivers to verify the integrity of the system and access to the system in a sensible way for administrators so there are a few things that needs to be resolved. Protected Setup Test Failover The small test In this scenario I do a test failover of a single machine and verifies that it starts and that I can log into it. The steps are: Setup the machine running RHEL 5.5.  Install VMware tools  Kick of the vSphere Replication Create a Protection Group and ... no that didn...
Read more