Update:
My esteemed colleague Lee Dilworth, recently co-presented a session on this topic at VMworld US and will be repeating at VMworld EMEA (Oct 9-11) session BCO-1436. If you want to see the content it is freely available:
vSphere Replication
And now finally a subject you will all know is very close to my heart – vSphere Replication (VR) and Site Recovery Manager (SRM). As you have probably heard vSphere Replication is now available as core-feature of the vSphere Platform. That might sound a little odd given the name of the product/technology. But it used to be to get your sticky-paws on vSphere Replication you had to be a SRM customer. That’s no longer the case – you can run VR independently of SRM. That doesn’t diminish the value-prop of SRM. It’s product that’s done very well even before the rise of VR, and there’s still a truckload of automation that SRM brings to the table that isn’t present in VR on its own. VR is engine room for replicating VMs around, but I personally think you still need a captain steering the ship! VR has very simple UI that allows you to protect a VM and then failover and failback. When a VR-only VM is recovered it’s powered on, but with its virtual NIC disconnected. That’s to avoid potential mishaps and conflicts because its portgroup settings remain unchanged and not remapped. To get that sort of automation you would be really looking at a full SRM implementation. I suspect the SMB community will be very interested the baked in version of VR because currently they have to pay for 3rd party software to achieve this sort of functionality.
VR offers some flexibility that wasn’t available in the first release. So you can replicate within a cluster, across clusters and across vCenter instances if you require. Remember though the requirements for two vCenter servers with SRM remains part of the SRM design. As with SRM when you protect the VM with VR a “Shadow” or “Placeholder” VM will be created at the destination location. Some of the caveats of the first revision of VR remain, so care must be taken when your using it. Most of this is “common-sense” as that there are certain administrative tasks that could cause a full-sync event to take place. The two that come to mind are snapshots and Storage VMotion. So you can use snapshots on a VM that’s protected by VR, but these will not appear at the destination. Managing a snapshot can trigger a full-synch such as reverting or committing a snapshot. The same situation applies to Storage VMotion. So if you move a VM from one datastore to another – the blocks all change as this essentially a file copy, and delete process.
VR now comes as single virtual appliance, whereas previously there were two virtual appliances – the VR (that did the work receiving block level changes from the ESX host where the VM resides) and the VRMS (a management system that held your configuration – which VMs are protected, their disks and replication frequency). This rationalisation should make the deployment process much simpler. There is improved VSS integration – the support has always been there from day one – but now its more “application aware” so it can level VSS relative to Sharepoint, Exchange and SQL. If the VSS Application Provider isn’t there, then VR keeps working but you get message/warning about the lack of a VSS Application Provider.
As with other features in vSphere5.1, VR can be managed through the new web-client without the need to toggle between plug-ins and views.
Site Recovery Manager
Site Recovery Manager benefits from range enhancements in the platform that I’ve mentioned earlier such as VR new application-aware VSS and improved disk handling (the “All Paths Down” that was covered in part7). One of the big changes in SRM is the move away from 32-bit to 64-bit. There’s no direct impact on performance or the scalability maximum configurations (SRM still protects 1,000 VMs for example), but it means all the “Site Recovery Adapters” (or SRAs) are being rechecked against a 64-bit build. Remember that SRM needs a backend database so a 64-bit DNS is now needed.
If you kept up to date with your SRM configuration you should know the “Forced Failover” feature is tucked away in the release. This was a 5.0.1 feature, but I suspect it slipped under many peoples radar (despite the commendable work of Duncan Epping). The option is not exposed directly in the UI, and needs to be enabled in SRM’s Advanced Settings.
- Right click in the left pane on your site
- Click “Advanced Settings”
- Click “Recovery”
- Select the “recovery.forcedFailover” setting
“Forced Failover” allows you to run the recovery plan without SRM trying to synch the arrays. The option is kind of there when you run a test, but was not exposed when you ran the recovery plan “for real”.
The other good bit of news concerns automated failback. It’s now available for both array-based replication (ABR) and vSphere Replication (VR). Previously, it was only an ABR feature. I dare say the boffins in the labs had VR working with auto failback working for a while, but it need to go through sufficient QA testing before it could be let loose. That’s important because customer now have the freedom to choose what replication they prefer without worrying about feature differences. There are many excellent use cases for VR – such as spinning up a PoC without having to speak to the storage team; not having to have matching arrays; being able to apply replication at the VM-level rather than the blunt stick which is the LUN/Volume. I’m thinking now the only real question is whether VR’s RTO object is small enough to meet your needs – that’s still 15mins minimum. In my experience the vast majority of customers don’t have massive need for synchronous replication – or find the laws of physics apply long before they hit any replication features.
Finally, the last change concerns licensing. Previously, SRM wasn’t support on the SKU’s aimed at the SMB market. It’s good to hear that it is now possible to use the vSphere Essentials Plus. That might help make SRM more attractive to the SMB market. To a lesser degree some customers who have a modest number of VMs to protect could use the vSphere Essentials Plus SKU at the recovery site.