Loading...

Live Sync Replication for Amazon

The Live Sync feature enables incremental replication from a backup of a VMware virtual machine (source VM) to a synced instance in the Amazon EC2 (destination). This feature enables the Amazon site to serve as a disaster recovery (DR) site.

You can configure Live Sync to initiate replication automatically after backups or on a scheduled basis (for example, daily or once a week), without requiring any additional action from users. Using backup data for replications minimizes the impact on the production workload by avoiding the need to read the source VM again for replication.

Disaster Recovery

Live Sync can be used to create and maintain warm recovery sites for virtual machines running critical business applications. Live Sync offers the following benefits:

  • The impact on production servers is minimized because Live Sync uses backup data to create replicated virtual machines; backup captures virtual machine data in a single pass, and Live Sync runs on backup infrastructure.
  • Live Sync is hardware agnostic. There is no need to reproduce the original hardware environment at the recovery site.
  • The recovery time objective (RTO), the time interval between a service interruption and the restoration of services from the recovery site, is the time needed to power on the virtual machines at the recovery site. Automated validation and the ability to specify new network connections at the recovery site ensure that the startup time is minimized.
  • The recovery point objective (RPO), the acceptable time interval within which virtual machine data must be recoverable, is determined by the frequency of backups.
  • You can configure an auxiliary copy operation to copy backup data to a remote location where Live Sync operations are performed. Deduplication and compression reduce the amount of data that needs to be transferred over the wide area network (WAN).
  • Orchestration features support continuity of operations:
    • Planned failover to validate the DR site or perform maintenance on the primary site
    • Unplanned failover for quick site recovery
    • Failback to move operations back to the primary site

HotAdd Restores

HotAdd restores for Amazon provide faster performance than traditional restores. By using a VSA proxy running on an Amazon instance, the restore operation can write directly to Elastic Block Storage (EBS) and inject Amazon drivers that are required for destination instances.

HotAdd restores are used for the following operations:

  • Restores
  • Live sync operations
  • Conversion from VMware to Amazon, for the following VMware guest operating systems:
    • Windows Server 2019, provided that the OS disk uses Master Boot Record (MBR) partitioning
    • Windows Server 2016
    • Windows Server 2012 R2
    • Windows Server 2008 R2

      Note: For VM conversion or live sync replication of guest VMs that run Windows Server 2008 R2, validation might fail for the converted instance in AWS. To resolve this issue, set the RealTimeIsUniversal registry key on the source VM as described in the AWS article Configuring Time Settings for Windows Server 2008 and later, and then perform a new backup to use as the source for the conversion or replication.

    • CentOS 7.x
    • RHEL 6.x
    • RHEL 7.x
    • Ubuntu 18.x

Requirements for HotAdd Restores

  • The Virtual Server Agent proxy selected for the operation must be an Amazon instance in the same zone as the destination instance.

Note: For cross-hypervisor restores or live sync replication from VMware to Amazon, you must use a VSA proxy that runs on Windows.

Requirements for VM Conversion and Live Sync Replication Operations when Amazon is the Destination

  • On the VSA proxy, create an Amazon folder under the software_install_path/Commvault/ContentStore folder, and extract the contents of the following zip files in the Amazon folder:
  • Make the following changes to source VMs before performing the backup that is used for conversions:
    • For both Windows and Linux source VMs, set the VMs to use DHCP. VMs with static IP addresses can only be converted or replicated using the import method.
    • Windows source VMs:
      • Install .NET 4.5.
      • Enable Remote Desktop Protocol (RDP).
      • Disable Windows Firewall.
      • Disable User Account Control (UAC).
      • Ensure that there is a minimum of 2 GB free space on the C: drive.
      • Verify that the Windows AutoAdminLogin feature is not disabled on the source VM, so that AWS drivers can be installed on the destination VM during conversion.
      • HotAdd conversion is not supported if the boot OS for the source VM uses GUID Partition Table (GPT) partitioning. Use the import method instead.
      • If the Windows security banner is enabled on the source VM, install the following components so that the converted instances can pass instance status checks:

        https://s3.amazonaws.com/ec2-downloads-windows/Drivers/AWSPVDriverSetup.zip

        https://s3.amazonaws.com/ec2-downloads-windows/EC2Config/EC2Install.zip

    • Linux source VMs:
      • Enable Secure Shell (SSH) for remote access.
      • The host firewall (such as Linux iptables) must permit access to SSH.
      • Ensure that Xen drivers are installed on the VM:

        xen-blkfront

        xen-netfront

        Installing Xen drivers on Linux guest VMs before backing up the VMs enables the required drivers to be in place when the Amazon instances are created, so that the Amazon instance can be started and users can access the instance.

      • Ensure that Linux VMs use GRUB (GRUB legacy) or GRUB 2 as the bootloader.
      • Linux VMs must use one of the following for the root file system: ext2, ext3, ext4, Btrfs, JFS, or XFS.
      • Linux VM /etc/fstab entries should use UUIDs instead of device names, because device names might change on conversion.

HotAdd Restore Process

Windows:

  1. Create empty EBS volumes.
  2. Attach EBS volumes to proxy.

    Up to 21 volumes can be attached to the VSA proxy during cross-hypervisor restores or live sync replication, occupying device slots xvdf - xvdz.

  3. Restore data to EBS volumes.
  4. Inject AWS components and drivers.
  5. Detach volumes from the VSA proxy.
  6. Create the Amazon instance from the EBS volumes.
  7. Automatically log on to the instance to install PV drivers and EC2 configuration service.

Linux:

  1. Create empty EBS volumes.

    Up to 21 volumes can be attached to the VSA proxy during cross-hypervisor restores or live sync replication, occupying device slots xvdf - xvdz.

  2. Attach EBS volumes to proxy.
  3. Restore data to EBS volumes.
  4. Detach volumes from the VSA proxy.
  5. Create the Amazon instance from the EBS volumes.

Last modified: 12/19/2018 9:16:23 PM