There are many interesting items coming out of VMware’s 28 Days of February where customers can learn more about “One Cloud, Any Application, Any Device”. A couple of the biggest items are the announcements of vSphere 6.0 and Virtual SAN 6.0. In this article, we will look at what is new with two of the more popular vSphere features: vSphere Data Protection and vSphere Replication. Perhaps the biggest news with these two features is around vSphere Data Protection. Before vSphere 6.0 and vSphere Data Protection 6.0, there were two editions of vSphere Data Protection: vSphere Data Protection, included with vSphere, and vSphere Data Protection Advanced, which was sold separately. With the release of vSphere Data Protection 6.0, all vSphere Data Protection Advanced functionality has been consolidated into vSphere Data Protection 6.0 and included with vSphere 6.0 Essentials Plus Kit and higher editions. Keep reading to learn more about the advanced functionality now included as part of vSphere Data Protection 6.0.
vSphere Data Protection (VDP) is a backup and recovery solution based on the industry-leading EMC® Avamar® deduplication backup and recovery software. VDP is deployed as a virtual appliance and managed using vSphere Web Client. VDP can back up and restore entire virtual machines. There is no need to install and manage a backup agent for every virtual machine as VDP utilizes vSphere APIs for Data Protection (VADP). VDP can also perform file level restores using a web browser. Backup data storage consumption is minimized using the same variable length segment deduplication algorithm found in Avamar.
One of the new advanced features in VDP 6.0 is the addition of backup agents for Microsoft SQL Server, Exchange, and SharePoint. The agents enable application consistent backup and recovery of these applications on virtual and physical machines including the ability to select individual databases for backup and restore, enable multiple stream backups, and truncate database logs. These agents support SQL Server Failover and AlwaysOn Clusters and Exchange Database Availability Groups.
VDP integrates with EMC Data Domain® systems using Data Domain Boost software. Backup data from VDP can optionally be stored on a Data Domain system to increase scale and reliability with Data Domain Data Invulnerability Architecture. In this configuration, backup jobs are configured and managed using VDP. The backup data is stored in the Data Domain system where it is compressed to minimize backup data storage consumption. If the VDP virtual appliance is lost, it is possible to deploy a new VDP appliance, configure it for use with the Data Domain system, and perform restores using the existing backup data.
Another advanced feature VDP 6.0 includes is replication of backup data between VDP 6.0 virtual appliances. VDP replication is very efficient – VDP backup data is deduplicated and only unique backup data segments are transmitted from the source to the target making it possible to send backup data across a WAN for offsite retention and disaster recovery. The replication stream is encrypted for security. VDP supports a variety of replication topologies such as 1:1, N:1, and 1:N. The example below shows VDP at both the main data center and a remote office replicating backup data to a disaster recovery data center.
Since VDP is leveraging Avamar deduplication backup and recovery software, VDP can also replicate backup data to an Avamar Data Store at your site or hosted by a cloud service provider.
Backup data is good only if it can be restored. The best way to verify the integrity of backup data is to perform routine “practice restores”. In many cases, this is a manual task that is seldom done. VDP 6.0 features automated backup verification. Jobs can be created that restore virtual machines on a scheduled basis to verify backup data integrity. When a virtual machine is restored as part of this process, it is disconnected from the network to avoid interference with production systems. Once the restore has been verified, the restored virtual machine is deleted and the result of the verification job is reported.
Switching gears, let’s dig into vSphere Replication. This technology is a host-based asynchronous replication engine that is included as a feature of vSphere Essentials Plus Kit and higher editions. It is deployed as one or more virtual appliances and managed using vSphere Web Client. Replication can be configured per-virtual machine with a recovery point objective (RPO) between 15 minutes and 24 hours. vSphere Replication can be used to replicate virtual machines between different types of storage. For example, an administrator could replicate virtual machines from traditional SAN to VMware Virtual SAN. vSphere Replication supports storage policy based management (SPBM) – a storage policy for the recovered virtual machine can be specified when configuring vSphere Replication.
Recovering a virtual machine takes only a few minutes. However, it is important to note that with vSphere Replication alone, virtual machines are recovered one at a time. This is fine for a few virtual machines, but for larger recovery efforts involving many virtual machines, VMware vCenter Site Recovery Manager (SRM) is recommended. SRM can orchestrate the recovery of large numbers of virtual machines, automate IP address changes during failover, and provide automated fail-back capabilities. SRM can be used in conjunction with array replication and with vSphere Replication to enable faster, more reliable data center migrations and disaster recoveries.
What’s New with vSphere Replication 6.0? For starters, end-to-end network compression has been added. When configuring replication for one or more virtual machines, compression can be enabled to reduce the amount of bandwidth consumed and time required to replicate a virtual machine. Typical compression ratios are 1.6:1 to 1.8:1. For example, a virtual machine containing 37.5GB of data took 52 minutes to replicate with compression off (default setting). With compression enabled, that same 37.5GB of replicated data was compressed to 20.2GB and took only 29 minutes to replicate.
Another feature that was commonly requested is the ability to isolate replication traffic from management traffic. This is supported in vSphere Replication 6.0. Segregation of replication traffic can help improve performance and security. Traffic types can be isolated at both the source and target locations. This feature also enables management of replication traffic using vSphere Network IO Control.
Performance of a vSphere Replication full synchronization is improved in version 6.0. With previous versions, vSphere Replication would compare the entire contents of the source and target using checksums regardless of whether each region of the virtual disk contained data (allocated) or not. With vSphere Replication 6.0, allocation information is requested from the underlying storage and checksum comparisons are done only where necessary. For example, if the both the source and target regions are reported as not allocated, vSphere Replication will simply skip these regions and move to next. This method can reduce IO and time required for full synchronization. It is important to note not all virtual disk types and storage types are supported. For example, this is supported for thin provisioned disks on VMFS datastores, but not on NFS datastores. Virtual SAN is supported.
vSphere Replication can utilize Microsoft Volume Shadow Copy Services (VSS) for Windows file systems and VSS-aware applications. Support for quiescing Linux file systems has been added to vSphere Replication 6.0. The quiescing method involves the use of “freeze” and “thaw” scripts and VMware Tools to quiesce a Linux file system just before replication occurs. VSS and Linux file system quiescing improves the reliability of virtual machines recovered with vSphere Replication. Quiescing is disabled by default.
Another improvement is support for Storage vMotion and Storage DRS at the target location. Previous versions of vSphere Replication required a full synchronization whenever a replica was moved from one datastore to another. That is no longer the case with vSphere Replication 6.0.
