by Duncan Epping
Yesterday VMware released a patch for the Site Recovery Manager Client:
Client Patch for Site Recovery Manager 1.0 Update 1
This client patch for Site Recovery Manager 1.0 Update 1 corrects a performance problem observed at sites that support more than seven ESX hosts.
If you are running SRM, it might worth downloading the patch and installing it! The download page contains a section on how to apply this patch, besure to read it cause it’s not a case of “next, next, finish”.
When we were playing around with Site Recovery Manager last week we had the opportunity to ask a bunch of questions to Lee Dilworth. Lee is a Specialist System Engineer for Site Recovery Manager. During the discussion Lee told us about a document that Horst Mundt, also a VMware employee, wrote about using trusted certificates. We received the document via email and I wanted to share this with you. After a quick search on the internet I noticed that Horst already uploaded his document to VI:OPS:
SRM establishes a secure connection between the protected and the recovery site.
There are two options for authentication: Credential based or certificate based.
If you install SRM into an existing environment, make sure to choose the method that is appropriate for your environment.
If you have not changed the default certificates that were installed by the VMware vCenter server setup then go for credential based authentication. You do not need to read the this document.
If you have installed SSL certificates issued by a trusted CA on your VMware vCenter servers then go for certificate based authentication. The document explains how certificates need to be setup in order for this to work.
When reading several SRM docs I was wondering if Microsoft Clustering was supported or not. I knew that in version 1.0 it wasn’t supported. When reading the Release Notes I noticed the following:
Full Support for RDM devices
SRM now provides full support for virtual machines that use raw disk mapping (RDM) devices. This enables support of several new configurations, including Microsoft Cluster Server. (Virtual machine templates cannot use RDM devices.)
Microsoft Clustering Services is supported as of Update 1. But you will need to keep in mind when creating your Recovery Plan that all nodes of the cluster will belong to the same Protection Group and can possibly be started up or shutdown at the same time….. I haven’t configured SRM in combination with MSCS so far, if any of you has any tips/tricks let me know.
I’ve been playing around with Site Recovery Manager these last couple of days. Installing it was really easy and same goes for the basic configuration. I already wrote a blog about this topic a month ago or so but now I’ve experienced it myself. Most of the time during a Site Recover Manager project will be spent during the Plan & Design phase and writing documentation. I will just give you one example why. The following was taken from the SRM Course material:
Datastore Group
Replicated datastores containing the complete set of virtual machines that you want to protect with SRM
Protection Group
A group of virtual machines that are failed over together during test and recovery
For those who don’t know, there’s a one on one mapping between Datastore Groups and Protection Groups. So in other words, once you’ve mapped a Datastore Group to a Protection Group there’s no way of changing it without having to recreate the Protection Group.
I think a picture says more than a 1000 words so I stole this one from the Evaluator Guide to clarify the relationship between datastore, Datastore Groups and Protection Groups:
Notice that there are multiple datastores in Datastore Group 2 because VM4 has disks in both datastores. So these datastores are joined into one Datastore Group. This Datastore Group will have a one to one relationship with a Protection Group. Keep in mind, this is really important: a Protection Group contains VM’s that are failed over together during test and recovery.
If you’ve got VM’s with multiple disks on multiple datastores with no logic in which disk is placed on which datastore you could and probably will end up with all datastores being member of the same Datastore Group. Being member of the same Datastore Group means being part of the same Protection Group. Being part of the same Protection Group will result in a less granular fail-over. It’s all or nothing in this case and I can imagine most companies would like to have some sort of tiering model in place or even better fail over services one at a time. (This doesn’t mean by the way that if you create multiple Protection Group that you can’t fail over everything at the same time, they can all be joined in a Recovery Plan)
Some might think that you would be able to randomly add disks to datastores after you finished configuring. This clearly isn’t the case. If you add a disk to a protected(!) VM the Datastore Group will be recomputed. In our situation this meant that all VM’s in the “Medium Priority” Protection Group were moved over to the “High Priority” Protection Group. This was caused by the fact that we added a disk to a “Medium Priority” VM and placed it on a “High Priority” datastore. As you can imagine this also causes your Recovery Plans to end up with a “warning”, you will need to reconfigure the moved VM’s before you can fail them over as part of your “High Priority” datastore. (Which probably wasn’t the desired strategy…)
When I was searching the internet for information on SRM I stumbled upon this article on the VMware Uptime blog by Lee Dilworth. I’ve taken the following from the “What we’ve learnt” post, which confirms what we’ve seen the last couple of days:
Datastore Group computation is triggered by the following events:
- Existing VM is deleted or unregistered
- VM is storage vmotioned to a different datastore
- New disk is attached to VM on a datastore previously not used by the VM
- New datastore is created
- Existing datastore is expanded
So in other words, moving VM’s from one Datastore to another or creating a new disk on a different Datastore can cause problems because the Datastore Group computation will be re-run. Not only do you need to take virtual disk placement in consideration when configuring SRM, you will also need to be really careful when moving virtual disks. Documentation, Design and Planning is key here.
I would suggest documenting current disk placement before you even start implementing SRM, and given the results you might need to move disks around before you start with SRM. Make sure to check your documentation and design before randomly adding virtual disks when SRM has been implemented. Documenting your current disk placement can be done easily with the script that Hugo created this week by the way, and I would suggest to regularly create reports and save them.
Expect some more SRM stuff coming up over the next couple of weeks.
VMware just released vCenter Site Recovery Manager 1.0 Update 1. Scott already dropped the news that it doesn’t contain NFS support, and that has always kept me away from NFS and iSCSI for that matter. But with 10GB ethernet becoming more mainstream this focus might change.
Anyway, the following features have been added:
- New Permission Required to Run a Recovery Plan
SRM now distinguishes between permission to test a recovery plan and permission to run a recovery plan. After an SRM server is updated to this release, existing users of that server who had permission to run a recovery plan no longer have that permission. You must grant Run permission to these users after the update is complete. Until you do, no user can run a recovery plan. (Permission to test a recovery plan is unaffected by the update.)- Full Support for RDM devices
SRM now provides full support for virtual machines that use raw disk mapping (RDM) devices. This enables support of several new configurations, including Microsoft Cluster Server. (Virtual machine templates cannot use RDM devices.)- Batch IP Property Customization
This release of SRM includes a tool that allows you to specify IP properties (network settings) for any or all of the virtual machines in a recovery plan by editing a comma-separated-value (csv) file that the tool generates.- Limits Checking and Enforcement
A single SRM server can support up to 500 protected virtual machines and 150 protection groups. This release of SRM prevents you from exceeding those limits when you create a new protection group. If a configuration created in an earlier release of SRM exceeds these limits, SRM displays a warning, but allows the configuration to operate.- Improved Support for Virtual Machines that Span Multiple Datastores.
This release provides improved support for virtual machines whose disks reside on multiple datastores.- Single Action to Reconfigure Protection for Multiple Virtual Machines
This release introduces a Configure All button that applies existing inventory mappings to all virtual machines that have a status of Not Configured.- Simplified Log Collection
This release introduces new utilities that retrieve log and configuration files from the server and collect them in a compressed (zipped) folder on your desktop.- Improved Acceptance of Non-ASCII Characters
non-ASCII characters are now allowed in many fields during installation and operation.
Be sure to read the “known issues” section before you start implementing.