At July 12 VMware announced the soon to be released Site Recovery Manager 5.0 (SRM). In short SRM 5.0 enables to fully automate a test and actual failover of a VMware infrastructure to a recovery site. Needed are a protected and a recovery site, a cluster of VMware hosts at each site, storage at both sides and a vCenter Server instance at each site. Also each sites needs to have an instance of SRM running.
Lots of interesting new features has been added to the 5.0 release. Also the pricing has been adjusted wth two editions available.
-changes to the user interface
-more granular control over VM startup order
Site Recovery Manager 5.0 will be available in two editions. The Standard edition list price is $195 per protected virtual machine. The Enterprise Edition is $495 per protected virtual machine. The difference between the two editions is Standard Edition is limited to protection of 75 virtual machines (per site and SRM instance) while the Enterprise Edition has no limit. All features of the Enterprise edition are availble in the Standard edition as well.
As SRM 5.0 focusses on the SMB-market, mind SRM 5.0 is not supported on Essentials and Essentials Plus kits! You will need vSphere Standard edition or higher to run SRM 5.0!
vSphere Replication (used to be called Host Based Replication during the development).
This enables replication of all kinds of storage without the need for a storage adapter. It is a simple, cost efficient replication for Tier 2 application or for SMB, branch and remote offices. This feature will directly compete with host based replication in products like Veeam and Vizioncore. The storage based replication we know of SRM 4 can be used for high-performance replication of business critical applications.
The advantage of vSphere Replication is that the storage at the protected and recovery site can be different. With SRM 5.0 replication costs for license at the storage layer are not needed. The RPO can be anything between 15 minutes and 24 hours. Because only changed disk data (changed block tracking is used) is replicated there is a low network utilization. And it can protect 500 VM’s.
vSphere Replication does not support automated failback , fault tolerance, templates, linked clones and physical RDM’s. It also has file level consistency only (no application consistency). vSphere Replication needs ESXi 5. vSphere 4 or lower hosts are not supported!
Storage based replication is the choice when synchronous replication is needed of high data volumes and application consistency is needed.
Management of vSphere Replication will be less complex than with storage-based replication. For storage-based replication the vSphere admin needs to talk with the storage admin about which LUN’s needs to be replicated to the recovery site. The vSphere admin needs to be sure about which datastores to select to place the VMDK’s of protected VM’s on. Setting up SRM can be difficult. VM’s that do not need protection needs to be moved to another datastore to make sure it is not wasting replication capacity. (storage and network)
For management of vSphere Replication just vCenter Server is needed. Protection is done at the VM level.
Current SRM customer do not protect all of their VM’s with SRM. Only business critical ones are protected, mainly because of the costs for protection. Tier 2 and tier 3 apps get protected by backup.
vSphere Replication architecture
The hosts at the protected site run a vSphere Replication agent. This agent will send all the changed blocks (delta) of protected virtual machines to the vSphere Replication Server on the recovery site. The replication process is managed by vSphere Replication Management Server which needs to be installed on both sites and it is integrated in vCenter Server and Site Recovery Manager. The Replication Manager Server can be stacked. You will need around 1 server to protect 100 VMs. Mind the replication schedule (which defines the RTO) is set on the ESXi host. So all VM’s running on that host will have the same replication schedule!
When the protected , original site has been restored, a failback can be executed automatically. In previous version failback had to be done manually. Now the same recovery plan used for the failover can be used for the failback. Mind the original site needs to be intact to perform an automated failback. If the site is destroyed and new hardware is used to rebuilt it, SRM does not know the config and a manual failback needs to be performed. Automated failback is not available for vSphere Replication.
Planned migration is a new workflow that can be applied to any recovery plan. This ensures no data loss, application consistent migrations of virtual machines. Planned migration is used by customers for various reasons:
-Disaster avoidance because of a hurricane, flooding, power failure in the datacenter
-planned maintenance of the datacenter (replacement of a core switch)
-for datacenter consolidation (companies merge)
-loadbalancing of virtual machines over datacenters.
In the case of planned migration there are hours to prepare the move. The planned migration is a much cleaner migration process with no data loss compared to the DR migration plan. In a disaster recovery plan all VM’s are migrated as soon as possible and it might lead to data lose because it is not application consistent. The planned migration workflow will do a clean shutdown of the vms at the protected site, sync data, stop the replication and present the LUN’s in the recovery site to the ESX hosts there.