I wanted to start detailing my findings of my almost 8 month project of deploying SRM in my environment. As I started looking at the design of SRM I began to notice some issues with my current environment. In keeping in line with some in-house best practices we have multiple virtual machines spanning across multiple datastore. One of the keys things we were trying to accomplish was placement of vmdk files by performance needs. For example, my Exchange server has it’s root volume vmdk stored on a larger datastore while I have it’s mail stores on smaller, higher performance datastores. I have also placed various other high I/O vmdk on the same datastore when the performance requirements and LUN I/O capacity made sense. In comes SRM with it’s protection rooted in a LUN.
With that, well, someone beat me to a greater discussion on storage design for SRM. Here’s a better post that I would probably write. blog.vTacit.com – Site Recovery Manager: Minimizing Data Store Group Pigeonholes. (relocated to: blog.vTacit.com – Site Recovery Manager: Minimizing Data Store Group Pigeonholes)
This is what has led me to a project that’s 8 months in duration. It’s to my advantage to be able to demonstrate the capability of fail over of an application, this makes my management happy. When management is happy with the outcome of money I’ve spent I get more money. I like this, a lot. So, I design for application fail over. The storage design requirements for this are huge.
I’ve heard rumor of single VM fail over from some of my contacts, although intriguing I’m curious to see how VMware is going to pull this off!