Lowering Disaster Recovery Costs with Site Recovery Manager
June 22, 2012Setting up a disaster recovery site can be a costly endeavor. VMware Site Recovery Manager has made disaster recovery much simpler, but it’s still expensive to get a DR site up and going. Rack space, power, cooling, bandwidth, storage and compute can all add up pretty quickly, not to mention that hopefully you’ll never have to use this equipment.
Replication Bandwidth
Bandwidth could be very expensive depending on how much data needs to be replicated. Consider some of these techniques to make the best use of your bandwidth.
- Do you need to replicate all of your production data? If not, select the most important servers to replicate and leave the labdev servers behind. It might not be ideal if a disaster happens, but at least the business can continue to run while you rebuild some lab servers.
- Consider using cheaper asynchronous bandwidth. For the most part, the DR site is going to be doing heavy downloads but not heavy uploads. This might allow you to use some cheaper DSL type services, but be weary; if you do have a disaster you’ll likely need to replicate that data back, which will be very difficult with this type of bandwidth.
- Try using a point to point type connection instead of a VPN Tunnel. VPN tunnels require encryption because they are using the public Internet to route traffic. If you have a private point to point connection you can save bandwidth by removing this encryption. Of course, consult your security managers first on this.
- Test a WAN optimizer. Buying extra equipment doesn’t seem like a way to save money, but it’s possible to get away with much less bandwidth if you have some optimized replication going. It may be cheaper to buy a couple of WAN optimizers as opposed to paying for higher bandwidth.
- Cut out unnecessary file replication. SQL TempDBs, page files and temp files don’t need to be replicated. If you can, try to setup your servers so that these files don’t need to be replicated.
Hardware Costs
It’s frustrating to buy expensive equipment for the disaster site, knowing that it might never be used. Here are a few options to get you started if you can’t bite the bullet and buy the hardware.
- Instead of using Array Based replication, try using the built in VMware Replication that is in SRM 5.0. A SAN may be one of the most expensive pieces of equipment in your datacenter. Especially if you’re paying for the maintenance contracts. Luckily SRM 5 has a way to do replication without have expensive storage.
- Use lower cost servers in the DR Site. It might be possible to use fewer servers, or less powerful servers as long as your users know that the performance might not be as good as it is in production. Again, this might not be ideal, but as long as you can still run the business the hard part is over. You can always buy some equipment to beef up the DR site once a disaster happens.
Site Costs
Just having a DR site can be the most difficult pill to swallow when it comes to paying the bills. Here are a few ideas that might help.
- Do you already have a second location? Use that for your DR Site instead of creating a third site for the DR location. There is no point in paying someone to host your data if you already have two sites. In fact, if you don’t have a second site already perhaps consider opening a second office as opposed to renting space from someone. If you’re going to need a second site anyway, maybe you can grow your business at the same time to help offset the costs.
- How do your users connect to the DR site if it needs to be used? If you have a business that needs people onsite it could be difficult to find a cheap enough place to host your data and your users, but if your users can just VPN into your network, all you’ll need is space for your server equipment.
Another option to lower hardware costs is to use the hardware in the DR site to run your lab/dev workloads. When a DR event occurs SRM can shut down those lab/dev workloads and bring up your production workloads on those servers. Obviously there may be latency issues if your DR site and production site are too far apart.
Great Point Ben!
Thanks for the comment.