When Veeam Backup & Replication v11 went Generally Available on the 24th of February I posted the What’s in it for Service Providers blog. In that post I briefly outlined all the new features and enhancements in v11 as it related to our Veeam Cloud and Service Provider Partners. As mentioned each new major feature and enhancement listed below deserves its own seperate post. While these posts are targeted at Service Providers, the majority of these features can be levered by all types of organizations. In this post I am looking at the long awaited VMware Cloud Director to Cloud Direct replication.
As a reminder here are the top new features and enhancements in Backup & Replication v11 for VCSPs (with links as created)
- Linux Backup Proxy Enhancements and other Linux Enhancements
- Data Integration API Enhancements supporting more platforms
- Continuous Data Protection for VMware Platforms
- VMware Cloud Director to Cloud Director Replication
- VMware Cloud Director Native HTML5 Tenant Portal, SSP Enhancements and 10.2 Support
- Archive Tier, Object Storage and other SOBR Enhancements
- Hardened Linux Repository for Immutability on Primary Landing Zones
- New PowerShell Module and RESTful API
- Enhanced Linux File-Level Recovery
- Veeam Agents for Windows and Linux v5.0 and Agent for Mac v1.0
More than ever VMware Cloud Director plays a pivotal role in helping Service Providers offering Infrastructure as a Service on VMware based platforms. Leveraging traditional snapshot-based replication, service providers now have the ability to replicate workloads at the vApp, virtual data center or organization level, on their tenants’ behalf. This can be done either between a source and target VCD instance, or within the same VCD instance. Service providers can create VCD replication jobs as well as perform failover and failback operations with replicated VM workloads that are part of the vAPP. VCD replication jobs contain all metadata for the VCD construct being replicated, such as networking or VM start order.
Replicating VCD Workloads Site-to-Site or Inter-Site
VCD replication allows the replication of VM workloads between production and disaster recovery sites, to the original Organization VDC or to another Organization VDC within the same VCD environment. Like the backup of VCD, Veeam Backup & Replication captures all the relevant metadata with the following VM constructs able to be chosen as the top level of the replication tree:
- Organization VDCs
In v11 the technology utilizes is the same mechanisms as traditional Veeam VM replicas and has the same recovery scenarios. It should be noted again, as mentioned in the CDP blog that CDP is not supported yet for VCD to VCD. In terms of the setup, the VCD replica target is an Organization VDC and this needs to be set up before replication jobs are configured at the destination VCD instance. The minimal unit of a VCD replication is the vApp, meaning you cannot replicate a single VM that is part of the vApp. The VCD replica snapshots are created on the VMs that are added to the target vApp and a single restore point of the VCD replica contains snapshots of all VMs added to a vApp.
The same functionality as a normal VM replication is possible in v11 for VCD except that you can not create Failover Plans based on VCD2VCD replicas. Failovers can only be performed at the individual vApp level. Failover and failback are as expected. When a failover is initiated, you shift from the original vApp in the source Organization VDC to the vApp replica in the target Organization VDC. Once failed over…permanent failovers, perform failback or undo failover are possible.
For migration purposes, when performing permanent failovers, the source vApp swaps over to the replica target vApp and use this replica as the production vApp and the original vApp is excluded from the job processing. When undoing a failover, the original vApp is reverted with all changes made to the vApp replica while it was failed over discarded. This can be used for testing and staging purposes. For failback, the original vApp has all changes that took place while the replica was running.
When you perform failback, changes are only sent to the original or recovered vApp but not published. You must test whether the original or recovered vApp works with these changes. Depending on the test results, the replica can be commited or undone. As shown above there are new options related to the Failback mode which gives more control over when this takes place. Of most interest to Service Providers would be the scheduled mode which specifies a time to commit it.
Automation wise, there is a complete set of PowerShell Commandlets that can be used to help providers build VCD2VCD into their offerings.
Benefit to Service Providers
Being able to offer VMware Cloud Director Tenants the ability to replicate workloads to a secondary target, be it local to the same VCD instance, or offsite to a target VCD instance is significant for Service Providers leveraging Cloud Director for IaaS. While CDP isn’t part of the equation yet, starting now with snapshot based replication and developing a productised VCD DRaaS service offering with the functionality in v11 will give tenants the ability to achieve workload resiliency while also offering migration and testing use cases today. When looking at competitive offerings, Veeam VCD2VCD replication should also be compelling from a pricing point of view.