Now that SRM 4.0 is here it seemed like a good time to take quick tour around a few of the new features and also highlight some less obvious elements of the vSphere platform that make working with SRM 4.0 simpler.
A sensible place to start would be at the beginning. As with previous SRM releases your first task after installing the SRM components is to login to your vSphere client and download the SRM 4.0 plug-in.
Once the plug-in is installed and enabled you will finally have access to SRM from the vSphere client
Customers who have upgraded from SRM 1.x or have previous experience of SRM 1.x will be familiar with the SRM site pairing and login process (both of which are covered in the SRM admin guide.
One new feature in SRM 4.0 is the ability to configure a multi-tenancy shared site setup. If you have this feature enabled then you willbe presented with an additional step during your login process:
At this stage you simply select the SRM site name you wish to connect to and the system will then authenticate your account with that site. It is possible through the simple privilege and permissions model to allow users access to one site but not others which is obviously a key requirement for a multi-tenancy setup.
Note to reader and myself: let use know via the comments section if you would like the shared site feature covered in more detail in a future blog post?
So once you are logged in to SRM 4.0 the UI layout and operation looks very much the same as SRM 1.x (if you've worked with that before) so what is new? What makes your life simpler? One configuration option outside of SRM that can make working with SRM very slick is the vCenter 4 linked mode option. Linked mode basically allows you to administer multiple vCenter instances from within a single vSphere client:
The SRM architecture always involves the use of two vCenter instances. One at your protected site and one at your recovery site. During SRM usage / configuration when performing tasks such as creating protection groups, inventory mappings, ip-customization setup or running recovery plan test there was always a need to have at least two VI client windows open in SRM 1.x and vCenter 2.x setups.
With SRM 4.0 and the vSphere platform if we now utilize linked mode vCenter we can control and monitor the whole environment from within a single vSphere client session as we can now see both the protected and recovery site inventories side by side. As an example as simple operation such as "Create Protection Group" results in placeholder VM's being created at the recovery site. We can now see these objects appear in real time within our client window and sanity check for ourselves that these have appeared as we expected and within the right vCenter object locations (resource pool/folders/network).
That mention of inventory mapping's and networks is a nice lead into another common question that has come up in recent weeks, that question being "Will SRM 4.0 recognize and work with distributed network objects such as vDS and/or 3rd party virtual switches?" The short answer is yes and I can illustrate this quite simply by showing an inventory mapping screenshot from my SRM 4.0 setup which has access to 3rd party virtual switches at both the protected and recovery sites:
What other things can we quickly find in SRM 4.0 that can make life easier? Well one of the nice things is that most if not all of the tweaks or advanced options if you like used to be configurable by editing your vmware-dr.xml file on each of your SRM servers. This was all well and good but editing xml files in production is not really ideal and I guess you don't really want to have to drop out to a editor every time you want to make a change.
The good news is in SRM 4.0 you can now make the changes if any are needed from with the SRM 4.0 UI itself. To find the way into this screen you simply need to right click on the work "Site Recovery" that appears in the left hand pane tree menu of any SRM screen, here is a quick look at this in my environment:
Another nice little feature (there are MANY others but this is a blog and I have already rambled on too long in this post!!!) is something that caught a LOT of customers (and me included) out in SRM 1.x. Essentially the issue was if I replicated a new datastore to my recovery site and had not got around to actually creating any VM's in it yet I would not see the datastore in the SRM "Review Replicated Datastores" screen.
The result of this was a lot of head scratching, storage replication configuration sanity checking and general confusion until you suddenly put a VM in the datastore and then ZAP the datastore suddenly appears. The logic behind why SRM 1.x chose not to display empty replicated datastores was a sound one (SRM is all about protecting VM's, if there is an empty datastore there are no VM's to protected) but it made more sense going forward to at least show the datastores (or exports now we have NFS support) are there even if they are empty:
At that point I think I have gone on for long enough and there are a stack of emails waiting for responses in my inbox so its back to work for me……..actually one final quick pic….lets see SRM 4.0 recovering a NFS export:
Nice thing here is that during the failover or test recovery there was no need for us to prime the recovery array at all. The new SRA's that support NFS handle all of the export creation / mappings for the recovery site ESX hosts.
