Part 3 - Disaster Recovery with SRM and vSphere Replication
In the previous articles I have described the setup of SRM and vSphere Replication as well as configuring a small and simple recovery plan (one single machine). Bursting the test bubble when doing a test failover though an additional machine.
In this part the focus will be on the more complex situation when you have a system over multiple VLANs that you want to failover. In the protected site load balancing and routing is done by the load balancer and for multicast by the firewall. Unfortunately these are still HW appliances in my case and I don't feel like running to the datacenter and move them each time someone does a test failover :-)
So we need to figure out a way to provide that functionality in the test bubble. Who knows in the end the network guys might actually be willing to discuss virtual load balanced and firewalls.
 |
| Protected Setup |
To keep it simple let us only consider two Vlan's in the Protected Setup. Vlan01 and Vlan50. VM01 communicates over the load balancer with VM50/VM51.
Whoa - and there it goes
After quite a few years in the business I no longer get surprised or upset by the volatile decisions and directions. I had quite a struggle to get the bits and pieces together to do the final tests when a change in direction came. So from now on I will be investigating Xen as our weapon of choice. That certainly is going to be interesting even though I doubt that the ecosystem surrounding the hyper-visor will be on par with VMware I am confident that it will be what we need it to be (maybe after some shaping and pounding).
Conclusions from the SRM effort - did I get any?
First of all Site Recovery Manager is in my opinion a brilliant tool for the right challenge. In out case it did not solve all of our issues. The lowest RPO of SRM is 15 minutes and in our case that is way to slow for the information. Thus information needs to be replicated in another way, as it is today. For the non-information part we have many environments built after the same "blueprint" and the churn on these machines are low. Thus SRM would make a very good job taking care of these - but then there are other things such as configuration over all our environments and non virtualized equipment that needs to be dealt with anyway.
Thus the conclusion is that SRM is the choice if we need a D/R solution soon but for the long run we would solve more of our issues by concentrating on rebuilding the environments automatically and injecting the information. By doing it this way we will gain configuration control over more parts, even non-virtualized stuff, and also gain speed in development and tests setups.
Well - that was that - now I'm off to get Xen and start that journey.
Conclusions from the SRM effort - did I get any?
First of all Site Recovery Manager is in my opinion a brilliant tool for the right challenge. In out case it did not solve all of our issues. The lowest RPO of SRM is 15 minutes and in our case that is way to slow for the information. Thus information needs to be replicated in another way, as it is today. For the non-information part we have many environments built after the same "blueprint" and the churn on these machines are low. Thus SRM would make a very good job taking care of these - but then there are other things such as configuration over all our environments and non virtualized equipment that needs to be dealt with anyway.
Thus the conclusion is that SRM is the choice if we need a D/R solution soon but for the long run we would solve more of our issues by concentrating on rebuilding the environments automatically and injecting the information. By doing it this way we will gain configuration control over more parts, even non-virtualized stuff, and also gain speed in development and tests setups.
Well - that was that - now I'm off to get Xen and start that journey.
Comments