Druva Phoenix for VMware Cloud on AWS
search cancel

Druva Phoenix for VMware Cloud on AWS

book

Article ID: 320060

calendar_today

Updated On:

Products

VMware Cloud on AWS

Issue/Introduction

This article provides information about the support of Druva Phoenix on VMware Cloud that covers VMware Cloud on AWS and VMware Cloud on Dell EMC.

Disclaimer: The partner solution referenced in this article is a solution that is developed and supported by a partner. The use of this product is also governed by the end-user license agreement of the partner. You must obtain from the partner the application, support, and licensing for using this product. For more information, see druva.com.

Resolution

This section provides a summary of:

VMware Cloud on AWS

Use cases supported on VMware Cloud on AWS 

Druva Phoenix can back up virtual machines created in VMware Cloud (VMC) Software-Defined Data Center (SDDC) similar to the on-premise vSphere-based data center and supports the following use cases:
  • The backed-up virtual machines can be restored to:
    • Same VMC SDDC from where they were backed up.
    • Different SDDC in VMC. 
    • An on-premise data center.  
  • Similarly, virtual machines backed up from an on-premise data center can be restored to a VMC SDDC.
  • Uses native VMware API to back up and restore data.
  • Leverages VMware CBT to track incremental changes.
  • Offers file-level recovery to a virtual machine.
  • Leverages hot add transport mode for backups. 
  • Ability to configure virtual machines based on tags, datastores, clusters, and automated policy configuration.
  • Automated disaster recovery in AWS with orchestration and failback capabilities. 
  • ROBO backup / restore and DRaaS to AWS

Solution Architecture   

Druva Phoenix is built on cloud-native architecture. Unlike traditional solutions that are hosted in AWS and leverage S3 or Glacier, Druva Phoenix is built on top of AWS services leveraging native AWS services like S3, Glacier, EC2, and DynamoDB. This helps to reduce the storage and compute needed, and with the scalability of metadata index. 

The following diagram illustrates the Druva Phoenix architecture for VMC on AWS.

image.png

As illustrated in the diagram:
  • To back up and restore virtual machines hosted on your VMware Cloud setup, deploy the Phoenix backup proxy. The Phoenix backup proxy is the client-side component that detects the virtual machines running on your setup and executes the backup and restore requests from the Phoenix Cloud. 
  • Data is processed at the backup proxy end for deduplication and the deduplicated data is then sent over to the Phoenix Cloud. 
  • By default, data flows over the public network to the Phoenix Cloud.
  • Automated disaster recovery in AWS with orchestration and failback capabilities. 
    You can failback to your on-premises VMware setup or to the VMware Cloud.
  • Optional software component—CloudCache is used for ROBO use case to store data locally on-premise.

Solution Components    

The Druva Phoenix backup proxy is required for backing up virtual machines. Backup proxy is the critical component that sits between your data center and Phoenix cloud and is responsible for performing backup and restore of virtual machines. For more information, see About Phoenix backup proxy for VMware.

Optional software component—CloudCache is used for ROBO use case to store data locally on-premise. For more information, see Phoenix CloudCache.
 

Steps to configure VMC with Phoenix

  1. Review the prerequisites to install the backup proxy.
  2. Deploy the backup proxy and register your VMware setup with Druva Phoenix.  For more information, see Deploy the first backup proxy and register the VMware setup. 
  3. Configure your virtual machines for backup. Configure Virtual Machines for Backup.

VMware Cloud on AWS Network configuration  

Ensure VMC SDDC firewall rules are configured to enable http/https traffic over port 443 for the communication through Compute and Management Gateways.
The backup proxy communicates with Druva on port 443. The communication is outbound only and you need to create an outbound traffic rule. The backup proxy also communicates with the vCenter on port 443 to understand the VMware hierarchy and communicates with the virtual machines to perform backups and restores. 


Features of the Backup Solution

 
What backup repositories are supported? AWS S3
How is backup data transmitted to the repository? DX, Public Internet 
Describe the implementation of the Datamover component
  • Single Proxy
  • Multi Proxy
Datamover Scale 
  • One per SDDC 
  • One per cluster 
  • Multiple per SDDC 
  • Multiple per cluster 
 In large SDDCs (>500 VMs, >nTBs), your solution may scale data movers.  How do you scale?
 
  • Deploy multiple proxies based on the number of VMs, change rate (amount of data being generated).
  • Deploy the proxies directly from the Druva Management Console.
  • Scale out or scale up by either increasing the number of proxies or increasing the number of concurrent backup jobs a proxy can process.
How are additional data movers provisioned?  Customer controlled
Describe additional functionalities of image-based backups 
File level recovery of a file to either a CIFS share or directly to a VM

 
Describe if in-guest backup options are available Agentless, application-aware backup capabilities for Microsoft SQL databases inside the virtual machine.
 
Describe security features 
  • Encryption in-rest 
  • Encryption in transit 
Describe network bandwidth/utilization control features Configurable bandwidth 
 
Describe design of deduplication/compression features Source Side (VMC) data is processed at the backup proxy end for deduplication wherein, the deduplicated data is then sent to the Phoenix Cloud.
 
Describe added-value services/features not listed above 
  • Ability to configure virtual machines based on Tags, Datastores, Folders, Clusters.
  • Ability to perform File Level Recovery.
  • Intelligent scheduling and load balancing of proxies to ensure high availability and maximum performance.
For a 1TB VM Full backup/Full restore, describe:
  1. Network Bandwidth usage
  2. Time to backup/restore
  3. RTO/RPO estimates
Full backup/Full restore takes approximately 2 hours to complete.
The network bandwidth usage depends on the amount of data that can be compressed and deduplicated. Typically, a 500 Mbps pipe is required for an on-Premise environment.
Hybrid centralized management: Describe how on-premises and VMC backups can be managed. Do you support single management console?
 
  • Single management console for both On-Premises and VMC environments.
  • The architecture remains the same as well.
  • Architecture is built on top of AWS with an optional software component—CloudCache, for ROBO use case to store data locally on premise.

Hybrid restore/migration mode:
Describe how a VM can be restored from on-premises backup to VMC or from VMC to on-premises 




 		The target repository for both--On-Premise / VMC remains the same i.e Druva storage (S3).
  • On-premises virtual machines can be restored to a VMC SDDC.
  • If an on-premises virtual machine is migrated to a VMC SDDC, Druva detects the virtual machine in the VMC SDDC and takes a backup with deduplication. Thus, there will still be a single copy of the data on in the Druva backend repository (S3).
For example, let’s say that you have a hybrid configuration.  On-premise with local backup, in VMC with cloud backup.  What happens if an on-premise VM is migrated to VMC?  Will the backup solution automatically update the location of the repository or will the VM still be backed up on premise? Since our backup repository is in AWS i.e. the data always gets backed up to S3, whether the VM resides in an On-Premise VMware infrastructure or VMC doesn’t really matter to us. The customer will get the benefit of deduplication. The backup solution will not automatically update the repository, but the VM will continue to be backed up to AWS. If the VM was being backed up to the optional CloudCache component, the component since it won’t be reachable from the VMC, the VM will automatically fallback to back up directly to AWS.
Scale:
  1. What are your supported maximums (# of VMs, # of TBs) both in number, and/or in simultaneous backup streams?
  2. Given your SLA, then what is the max bandwidth between VMC and repository?
There is no limit for the number of virtual machines or amount of data that can be backed up.

By default, a single proxy can process 3 virtual concurrently. The deployment can be either scaled up or scaled out depending on requirements.
 

Interoperability with VMware Cloud on AWS Features
NA

 

VMware Cloud on Dell EMC

Solution Architecture    

The Druva Phoenix architecture remains the same for both VMC and Datacenter use cases. For ROBO use cases, there is no need of multiple storage / hardware deployments thus, experience a single pane of glass for all ROBO offices. No need of multiple backup repositories / backup servers at each location thus, effectively manage the TCO.
An optional software component—CloudCache is available to store data locally on-premises. CloudCache holds data for 30 days locally if there are sites with weak WAN bandwidth. CloudCache can upload data to the AWS S3 storage. All the data is deduplicated, compressed, and encrypted.

The following diagram illustrates the Druva Phoenix architecture for VMC.

A screenshot of a computer screen Description automatically generated

The minimum bandwidth required depends on the amount of data that needs to be processed in a given time. Given that we have an option component in CloudCache, we have had customers with extremely low bandwidth backing up the data locally and slowly replicating it to the AWS S3 storage. Our primary repository is S3 and the On-Premise component is a block storage as well. It is a software component which can reside on any commodity hardware.
 
 StorageBandwidth (minimum)Latency
Backup (Datacenter architecture)S3Depends on RPODepends on the destination (backup) AWS region
Restore (Datacenter architecture)S3Depends on RTODepends on restore destination
Backup ROBO architectureS3, optional block storage software - CloudCacheDepends on RPODepends on the source (backup) AWS region
Restore ROBO architectureS3, optional block storage software - CloudCacheDepends on RTODepends on restore destination


 
 
 

Additional Information

For more information on Druva Phoenix, see druva.com.

Powered by Wolken Software