This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
As you have seen, one of biggest challenges in SRM in the post-configuration stages is network communication. Not only must your vCenter/SRM servers be able to communicate with one another from the Protected Site to the Recovery Site, but the SRM server must be able to communicate with your array manager also. In the real world, this will be a challenge which may only be addressed by sophisticated routing, NATing, intra-VLAN communication, or by giving your SRM server two network cards to speak to both networks.
It's perhaps worth saying that the communication we allow between the SRM and the storage layer via the vendor's SRA could be very contentious with the storage team. Via the vSphere client you are effectively managing the storage array. Historically, this has been a manual task purely in the hands of the storage team (if you have one), and they may react negatively to the level of rights that the SRM/SRA needs to have to function under a default installation. To some degree we are cutting them out of the loop. This could also have a negative impact on the internal change management procedures used to handle storage replication demands in the business or organization within which you work. This shouldn't be something new to you.
In my research, I found a huge variance in companies' attitudes toward this issue, with some seeing it as a major stumbling block and others as a stumbling block that could be overcome as long as senior management fully backs the implementation of SRM—in other words, the storage team would be forced to accept this change. At the opposite extreme, those people who deal with the day-to-day administration of storage were quite grateful to have their workload reduced, and noted that the fewer people involved in the decision-making process the quicker their precious virtual machines will be online.
Virtualization is a very political technology. As "virtualizationists" we frequently make quite big demands on our network and storage teams that can be deemed as very political. I don't see automating your DR procedures as being any less political. We're talking about one of the most serious decisions a business can take with its IT: invoking its DR plan. The consequences of that plan failing are perhaps even more political than a virtualization project that goes wrong.
Of course, it is totally impossible for me to configure every single storage vendor's arrays and then show you how VMware SRM integrates with them, but hopefully I've given you at least a feel for what goes on at the storage level with these technologies together with insight into how SRM configuration varies depending on your storage vendor's technology. I hope you have enough knowledge now to both communicate your needs to the storage guys as well as understand what they are doing at the storage level to make all this work. In the real world, we tend to live in boxes—I'm a server guy, you're a storage guy, and he's a network guy. Quite frequently we live in ignorance of what each guy is doing. Ignorance and DR make for a very heady brew.
Lastly, I hope you can see how important inventory mappings and Protection Groups are going to be in the recovery process. Without them a Recovery Plan would not know where to put your virtual machines in vCenter (folder, resource pool, and network) and would not know on which LUN/volume to find those virtual machine files. In the next chapter we will look at creating and testing Recovery Plans. I'm going to take a two-pronged approach to this topic. Chapter 10 gets you up and running, and Chapter 11 takes Recovery Plans up to their fully functional level. Don't worry; you're getting closer and closer to hitting that button labeled "Test my Recovery Plan."