Sie sind auf Seite 1von 61

Public Cloud

Architecture Guide
Commvault Version 11 SP5

VERSION 2.2 / SEPTEMBER 2016


COMMVAULT PRODUCTS
FOR GENERAL RELEASE Page |1
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Table of Contents
Abstract .................................................................................................................................. 8

The Cloud Difference ................................................................................................................. 8


Infrastructure as Programmable, Addressable Resources...................................................................... 8
Global, Flexible and Unlimited Resources ............................................................................................. 9
Transforming The Disaster Recovery Model For A More Agile, Cost-Conscious Solution ........................ 9

Design Principles ...................................................................................................................... 10


Native Cloud Connectivity .................................................................................................................. 10
Scalability .......................................................................................................................................... 10
De-duplication Building Blocks ............................................................................................................................. 10
Client-side De-Duplication.................................................................................................................................... 10
Design For Recovery .......................................................................................................................... 11
Crash Consistency vs. Application Consistency .................................................................................................... 11
Storage-level Replication vs. Discrete Copies ....................................................................................................... 11
Deciding What to Protect..................................................................................................................................... 11

Automation ....................................................................................................................................... 12
Programmatic Data Management ........................................................................................................................ 12
Workload Auto-Detection and Auto-Protection................................................................................................... 12
Self-Service Access and Restore ........................................................................................................................... 12

Cloud Use Cases with Commvault Software ................................................................................. 13


Backup/Archive to the Cloud .............................................................................................................. 13
Disaster Recovery to the Cloud........................................................................................................... 14
Migration to the Cloud ....................................................................................................................... 15
Protection in the Cloud ...................................................................................................................... 16

Architecture Sizing ................................................................................................................... 17


Amazon ............................................................................................................................................. 17
AWS CommServe Specifications......................................................................................................................... 17
AWS Media Agent Specifications ......................................................................................................................... 17
Azure ................................................................................................................................................. 18
Azure CommServe Specifications ....................................................................................................................... 18

COMMVAULT PRODUCTS
FOR GENERAL RELEASE Page |2
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Azure Media Agent Specifications ........................................................................................................................ 18

Architecture Considerations ....................................................................................................... 19


Networking ........................................................................................................................................ 19
Virtual Private Cloud / Azure Virtual Network ...................................................................................................... 19
Bridging On-Premise Infrastructure VPN & DirectConnect/ExpressRoute ........................................................ 20

Infrastructure Access ......................................................................................................................... 21


Hypervisor access in Public Cloud ........................................................................................................................ 21
Amazon VPC Endpoints ........................................................................................................................................ 21

Data Security ..................................................................................................................................... 21


In-flight................................................................................................................................................................. 21
At-rest .................................................................................................................................................................. 21
HTTPS Proxies....................................................................................................................................................... 21

Data Seeding...................................................................................................................................... 22
Over-the-wire ................................................................................................................................................... 22
Drive Shipping ...................................................................................................................................................... 22

Consumption / Cost ........................................................................................................................... 23


Network Egress .................................................................................................................................................... 23
Storage I/O ........................................................................................................................................................... 23
Data Recall ........................................................................................................................................................... 23

Performance / Storage ....................................................................................................................... 24


Multi-Streaming with Object Storage................................................................................................................... 24
Cloud Connector Best Practices ........................................................................................................................... 24
Compression vs. De-duplication........................................................................................................................... 24
Block Storage vs. Object Storage.......................................................................................................................... 24
Micro Pruning ...................................................................................................................................................... 25
Selecting the right Storage Class for Backup and Archive data ............................................................................ 25
Infrequent Access storage class support .............................................................................................................. 27

Performing Disaster Recovery to the Cloud ................................................................................... 28


Amazon ............................................................................................................................................. 28
Restoring Applications (Automated or On-Demand)............................................................................................ 28
Virtual Machine Recovery into AWS EC2 Instances .............................................................................................. 28
Replicating Active Workloads............................................................................................................................... 29

COMMVAULT PRODUCTS
FOR GENERAL RELEASE Page |3
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Azure ................................................................................................................................................. 29
Restoring Applications (Automated or On-Demand)............................................................................................ 29
Virtual Machine Recovery into Azure Instances ................................................................................................... 29
Replicating Active Workloads............................................................................................................................... 29
Using Workflow to Automate DR ........................................................................................................ 29

Protecting and Recovering Active Workloads in the Cloud ................................................................ 30


Amazon ............................................................................................................................................. 30
Agent-less EC2 Instance Protection (Virtual Server Agent for AWS) .................................................................... 30
Agent-In-Guest (Streaming) ................................................................................................................................. 33
Snapshot-based Agent-In-Guest (EBS IntelliSnap)................................................................................................ 34
Continuous Data Replicator (CDR) ....................................................................................................................... 37
Azure ................................................................................................................................................. 38
Agent-less VM Protection (Virtual Server Agent for Azure).................................................................................. 38
Agent-In-Guest (Streaming) ................................................................................................................................. 40
Azure Snapshots................................................................................................................................................... 40
Continuous Data Replicator (CDR) ....................................................................................................................... 40
Machine Export from Azure ................................................................................................................................. 41
Other Public Cloud Environments ....................................................................................................... 42
Agent-In-Guest ..................................................................................................................................................... 42
Continuous Data Replicator (CDR) ....................................................................................................................... 42

Application Migration ............................................................................................................... 44


Virtual Machine Restore & Convert (Lift and Shift, AWS/Azure only) .................................................................. 44
Oracle Application Migration (Linux, AWS only)................................................................................................... 44
Application Out-of-Place Restore (All supported platforms) ................................................................................ 44

Deployment ............................................................................................................................ 45
Remote Access / Bring Your Own Software ......................................................................................... 45
Installation Basics ................................................................................................................................................. 45
CommServe Disaster Recovery Solution Comparison ........................................................................................ 45

Pre-packaging Commvault Software within a VM Template .............................................................. 46


Automating Deployment with Continuous Delivery............................................................................. 46
Cloud Library Configuration................................................................................................................ 47
Unsupported Cloud Storage Configurations ........................................................................................ 47

COMMVAULT PRODUCTS
FOR GENERAL RELEASE Page |4
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Additional Resources ................................................................................................................ 48


Documentation .................................................................................................................................. 48
Books Online Cloud Storage .............................................................................................................................. 48
AWS IAM Permissions ........................................................................................................................ 48
Videos ............................................................................................................................................... 48
Backup and Archive to the Cloud with Microsoft Azure and Commvault ............................................................. 48
2 Clicks to the Cloud with AWS and Commvault .................................................................................................. 48
2 Clicks to the Cloud with Azure and Commvault................................................................................................. 48
Backup in AWS (Technical Feature, VSA for AWS)................................................................................................ 49
Backup in Azure (Technical Feature, VSA for Azure) ............................................................................................ 49

Appendix A: AWS Reference Architecture Diagrams ........................................................................ 50


Backup and Archive to AWS ............................................................................................................... 50
Cold/Warm Disaster Recovery to AWS................................................................................................ 51
Migration into AWS............................................................................................................................ 52
Backup in AWS ................................................................................................................................... 53

Appendix B: Azure Reference Architecture Diagrams ....................................................................... 54


Backup and Archive to Azure .............................................................................................................. 54
Cold/Warm Disaster Recovery to Azure .............................................................................................. 55
Migration to Azure............................................................................................................................. 56
Backup in Azure ................................................................................................................................. 57

Appendix C: AWS/Azure Concepts and Terminology ........................................................................ 58


Amazon (AWS) ................................................................................................................................... 58
Region .................................................................................................................................................................. 58
Availability Zone ................................................................................................................................................... 58
Elastic Compute Cloud (EC2) ................................................................................................................................ 58
Instance Reservation ............................................................................................................................................ 58
EBS-Optimized Instances...................................................................................................................................... 58
Elastic Block Storage (EBS) ................................................................................................................................... 59
EBS Snapshots ...................................................................................................................................................... 59
Simple Storage Service (S3) .................................................................................................................................. 59
Glacier .................................................................................................................................................................. 59
Azure ................................................................................................................................................. 60

COMMVAULT PRODUCTS
FOR GENERAL RELEASE Page |5
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Regions................................................................................................................................................................. 60
Virtual Machines .................................................................................................................................................. 60
Blob Storage......................................................................................................................................................... 60
ExpressRoute ....................................................................................................................................................... 61

Notices
This document is provided for informational purposes only. It represents Commvaults current product
offerings and practices as of the date of issue of this document, of which are subject to change without
notice. The responsibilities and liabilities of Commvault to its customers are controlled by Commvault
agreements, and this document is not part of, nor does it modify, any agreement between Commvault and
its customers.

1999-2016 Commvault Systems, Inc. All rights reserved.


Commvault, Commvault and logo, the C Hexagon logo, Commvault Systems, Solving Forward,
SIM, Singular Information Management, Simpana, Simpana OnePass, Commvault Galaxy, Unified
Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault,
QuickSnap, QSnap, Recovery Director, CommServe, CommCell, IntelliSnap, ROMS, Commvault
Edge, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All
other third party brands, products, service names, trademarks, or registered service marks are the
property of and used to identify the products or services of their respective owners. All
specifications are subject to change without notice.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE Page |6
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Revision History
Version Data Changes
1.0 March 2015 Initial Version
1.1 May 2015 Updated AWS Architecture recommendations
1.2 June 2015 Added new Architecture Consideration sections - Networking (AWS
VPC/Azure AVN), Infrastructure Access, Performance / Storage
Added new Installation sections - Bring Your Own License / Software
sections (Installation), Video Tutorial links
Added new Additional Architecture Resources section
Updated document & layout for new Commvault branding
Updated core cloud concepts and technology, AWS & Azure Sizing
Recommendations and Security (Architecture Considerations) section
Modified section layout
Removed Data Aging caveats with SP11 Micro-pruning for Cloud Storage
release, replaced text to refer to this only for pre-SP11 sites
1.3 July 2015 Updated with new trademark guidelines
1.4 August 2015 Minor reformatting
Added new links to video content
1.5 September 2015 Added Selecting the right Storage Class section
Minor reformatting
1.6 November 2015 New logo style
Updated requirements for Disaster Recovery to the Cloud
Updated cloud use case diagrams
Updated VM Recovery to AWS feature, and updated documentation links
for VM Recovery to Azure
Added Unsupported Cloud Configurations section
2.0 March 2016 Updated to reflect new Virtual Server Agent for AWS methodologies,
deployment and changes to use cases
Updated Backup to the Cloud, DR to the Cloud and Protection in the Cloud
use case scenarios and requirements
Updated Micro Pruning section
Updated Drive Shipping to add note about Snowball support arriving 2016
Updated all BOL links to use Commvault Version 11 documentation
Added new Documentation section to Additional Resources
Added Automating Deployment with Puppet/Chef section
Added Pre-packaging Commvault within a VM Template section
Removed Azure Marketplace component
Minor reformatting changes
2.1 June 2016 Updated Backup to the Cloud use case for more clear language around
DDB requirements
Added VSA for Azure
Added IntelliSnap functionality into VSA for AWS
2.2 September 2016 Added Migration to the Cloud use case and Application Migration section
Fixed error in data seeding table
Minor updates to Backup/Archive to the Cloud use case verbiage
Updated links to 2 Clicks to the Cloud videos, added new Backup videos for
AWS and Azure
Updated Micro pruning statement on Azure page blobs
Updated all original Agent-in-Guest references to Agent-in-Guest
(Streaming)
Added Snapshot-based Agent-in-Guest approach to Amazon Web Services
Added AWS and Azure Reference Architectures
Updated verbiage on Selecting the right Storage Class

COMMVAULT PRODUCTS
FOR GENERAL RELEASE Page |7
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Abstract
This document serves as an architecture guide for solutions architects and Commvault customers who are
building Data Management solutions utilizing Public Cloud environments and the Commvault Cloud
Solution sets.

It includes Cloud concepts, architectural considerations, and sizing recommendations to support


Commvault Cloud Solution Sets. The approach defined in this guide extends existing functionality into
easily sellable, re-usable architecture patterns to cover disaster recovery to the cloud as well as protecting
running workloads in the cloud use cases.

Currently this guide delivers architecture considerations and sizing recommendations for the Amazon AWS
and Microsoft Azure public offerings, along with a generic architecture for other public cloud Infrastructure-
as-a-Service offerings.

The Cloud Difference


The Cloud megatrend is one of the most disruptive and challenging forces impacting customers
applications and infrastructure, requiring new business models and new architecture decisions, which
impact how Commvault solutions protect and manage their data.

In general, Commvault believes the cloud contains these attributes that we can focus upon.

Infrastructure as Programmable, Addressable Resources


In a non-cloud environment: (i) infrastructure assets require manually configured, (ii) capacity requires
manual tracking, (iii) capacity predictions are based on the guess of a theoretical maximum peak, and (iv)
deployment can take weeks.

Within the cloud, these building blocks that represent the Infrastructure are not only provisioned as
required, following actual demand and allowing pay-as-you-go, but can also be programmed and addressed
by code. This greatly enhances flexibility for both Production/Dev/Test environments as well as Disaster
Recovery scenarios.

Resources can be provisioned as temporary, disposable units, freeing users from the inflexibility and
constraints of a fixed and finite IT infrastructure. Infrastructure can be automated through code, allowing
for greater self-service and more automated delivery of desired business and technical outcomes.
Consumption is measured by what you consume, not what you could consume, drastically changing the DR
cost modelling challenges experienced today.

This represents a major, disruptive reset for the way in which you approach Disaster Recovery, testing,
reliability and capacity planning.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE Page |8
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Global, Flexible and Unlimited Resources


Public Cloud providers offer global infrastructure available to Customers on a pay-as-you-go model,
allowing for more flexibility in meeting requirements for Data Protection & Disaster Recovery.

Resources, bandwidth and their availability can now be localized to your corporate assets and human
resources, allowing for a more distributed footprint that reduces backup windows and simplifies data
protection that otherwise would be cost prohibitive with a physical datacenter or co-located approach, all
while maintaining a simplified, unified pay-as-you-go billing approach.

Commvault software is designed as a software-driven, hardware and cloud agnostic, highly modular,
distributed solution that conforms with this new architecture reality, allowing Data Management solutions
to be built to support and remain flexible with a highly distributed infrastructure built on-top of Cloud.

Transforming The Disaster Recovery Model For A More Agile, Cost-Conscious


Solution
The cost model implications of Pay-as-you-Go dont just extend to Production workloads, but also to the
ever present challenge of providing a flexible, agile yet capable DR solution for your applications.

Today, many physical DR environments have less capacity than their Production, or Dev/Test counterparts,
resulting in degraded service in the event of a failover. Even more so, hardware is often re-purposed to
fulfill the DR environments requirements, resulting in higher than expected maintenance costs.

With the Public Cloud model, this hardware availability and refresh aspect is disrupted by removing the
need to maintain a hardware fleet that can meet both your DR requirements and sustain your service level
agreements.

You can provision instances to meet your needs, when you need them, and for specific DR events both
real and test and the underpinning hardware is maintained and upgraded by the Cloud provider without
any need for technical input, and no upgrade costs are incurred by the organization.

This dynamic shift allows you to begin costing per DR event, instead of paying for availability, improving
your level of Disaster Recovery Preparedness through the application of flexible, unlimited resources to
stage both DR tests and execute actual DR events all without requiring pre-purchased hardware or
disrupting production operations.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE Page |9
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Design Principles
In this section, we provide design principles and architecture options for organizations planning to leverage
the Cloud as part of their Data Management strategy.

Native Cloud Connectivity


The Cloud Connector is the native integration within the Media Agent module that directly communicates
with Object Storage providers such as AWSs S3 and Azure, without requiring translation devices, gateways,
hardware appliances or VTLs.

This Connector works by communicating directly with Object Storages REST API interface over HTTPS,
allowing for Media Agent deployments on both Virtual and Physical compute layers to perform read/write
operations against Cloud Storage targets, reducing the Data Management solutions TCO.

For more information on supported vendors, please refer to this comprehensive list:

Cloud Storage - Support

Scalability
Applications grow over time, and a Data Management solution needs to adapt with the change rate to
protect the dataset quickly and efficiently, while maintaining an economy of scale that continues to
generate business value out of that system.

Commvault addresses scalability in Cloud architecture by providing these key constructs:

De-duplication Building Blocks


Commvault software maintains a Building Block approach for protecting datasets, regardless of the
origin or type of data. These blocks are sized based on the Front-End TB (FET), or the size of data
they will ingest, pre-compression/de-duplication. This provides clear scale out and up guidelines
for the capabilities and requirements for each Media Agent.

De-duplication Building Blocks can also be grouped together in a grid, providing further de-
duplication scale, load balancing and redundancy across all nodes within the grid.

Client-side De-Duplication
As is the nature of de-duplication operations, each block must be hashed to determine if it is a
duplicate block, or unique and then must be captured. While this is seen as a way to improve the
ingest performance of the data mover (Media Agent), it has the secondary effect of reducing the
network traffic stemming from each Client communicating through to the data mover.

In public cloud environments where network performance can vary, the use of Client-side De-
Duplication can reduce backup windows and drive higher scale, freeing up bandwidth for both
Production and Backup network traffic.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 10
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Design For Recovery


Using native cloud provider tools, such as creating a snapshot of a Cloud-based instance is easy to
orchestrate, but does not deliver the application-consistency possibly required by a SQL or Oracle Database
residing within the instance, and may even require additional scripting or manual handling to deliver a
successful application recovery.

As part of any Data Management solution, it is important to ensure that you design for Recovery in order
to maintain and honor the RPO and RTO requirements identified for your individual applications.

Crash Consistency vs. Application Consistency


While Crash-consistency within a recovery point may be sufficient for a file-based dataset or EC2
instance, it may not be appropriate for an Application such as Microsoft SQL, where the database
instance needs to be quiesced to ensure the database is valid at time of backup. Commvault
software supports both Crash and Application consistent backups, providing flexibility in your
design.

Storage-level Replication vs. Discrete Copies


Many cloud providers support replication at the Object Storage layer from one region to another,
however, in the circumstance that bad or corrupted blocks are replicated to the secondary region,
your recovery points are invalid.

While Commvault software can support a Replicated Cloud Library model, we recommend you
configure Commvault software to create an independent copy of your data, whether to another
region or cloud provider to address that risk. De-duplication is also vital as part of this process, as
it means that Commvault software can minimize the cross-region/cross-provider copy by ensuring
only the unique changed blocks are transferred over the wire.

Deciding What to Protect


Not all workloads within the Cloud need protection for example, with micro services
architectures, or any architecture that involve worker nodes that write out the valued data to an
alternate source, mean that there is no value in protecting the worker nodes. Instead, the
protection of the gold images and the output of those nodes provides the best value for the
business.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 11
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Automation
The cloud encourages automation, not just because the infrastructure is programmable, but the benefits
in having repeatable actions reduces operational overheads, bolsters resilience through known good
configurations and allows for greater levels of scale. Commvault software provides this capability through
three key tenants:

Programmatic Data Management


Commvault software provides a robust Application Programming Interface that allows for
automated control over Deployment, Configuration, Backup and Restore activities within the
solution.

Whether you are designing a continuous delivery model that requires automated deployment of
applications, data collection and protection, or automating the refresh of a data warehouse or
Dev/Test application that leverages data protection, Commvault software can provide the controls
to reduce administrative overhead and integrate with your toolset of choice.

Workload Auto-Detection and Auto-Protection


The Commvault Intelligent Data Agents (iDA), whether the Virtual Server Agent for AWS, or the SQL
Server iDA provide auto-detection capabilities to reduce administrative load.

Fresh instances, new volumes recently attached to a VM, or databases imported and created in a
SQL instance are just examples of how Commvault software can automatically detect new datasets
for inclusion in the next Data Protection window, all without manual intervention. Even agent-in-
guest deployments can be auto-detected by Commvault and included in the next Data Protection
schedule through intelligent Client Computer Groups.

This Auto-Detection and Auto-Protection level removes the requirement for a backup or cloud
administrator to manually update the solution to protect the newly created datasets, improving
your operational excellence and improving resiliency within your cloud infrastructure, ensuring
new data is protected and recovery points maintained.

Self-Service Access and Restore


A common task performed by system administrators is facilitating access to recovery points for
end-users and application owners, shifting their attention away from other day-to-day operations
and strategic projects.

Commvault softwares self-service interfaces empower users to access their datasets through a
Web-based interface, allowing security mapped access to individual files & folders within the
protected dataset, freeing up administrators to work on critical tasks.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 12
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Cloud Use Cases with Commvault Software

Backup/Archive to the Cloud


Protecting data at the primary on-premise location by writing directly to an external cloud providers
storage solution, or retaining a local copy and replicating the backup/archive data (either in full, or only
selective portions of that data) into an external cloud providers storage service. This is suitable for both
short and long term retention configurations.

Scenario / Suitability Requirements

Offsite Storage / Tape Replacement Minimum 1x Media Agent On-Premise


Scenario no DR to the Cloud No VM in Cloud required for B&R to the
requirement, but can be extended if Cloud
required
1x DDB for the Cloud Library, hosted on
Native, Direct connectivity to 35+ Object On-Premise Media Agent. If a local copy
Storage endpoints no is desirable, an additional DDB will be
translation/gateway/hardware de-dupe required.
devices required.
For Archiving, it would be recommended
Cloud/Object Storage target can be
provided by either Public IaaS (AWS, Can use direct internet connection, or
Azure) or a Service Provider (BaaS) dedicated network to cloud provider for
best performance (AWS Direct Connect,
Azure ExpressRoute)

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 13
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Disaster Recovery to the Cloud


Providing operational recovery of primary site applications to a secondary site from an external cloud
provider.

Scenario / Suitability Requirements

Off-site Storage Requirement & Cold DR Minimum 1x Media Agent On-Premise,


Site in the Cloud only use infrastructure and minimum 1x Media Agent in Cloud
when a DR event occurs, saving time &
money (IaaS, DRaaS) Media Agent in Cloud only needs to be
powered on for Recovery operations
VM Restore & Convert convert VMware
and Hyper-V (Gen1) based Virtual Highly Recommended to use dedicated
Machines into AWS/Azure instances on- network to cloud provider for best
demand performance (AWS Direct Connect, Azure
ExpressRoute)
Database/Files restore out-of-place,
whether on-demand or scheduled, to
refresh DR targets

DR Runbook as Code turn your DR


runbook into a Workflow for easy
simplified DR automation, whether for
test or real DR scenarios

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 14
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Migration to the Cloud


Protecting data at the primary on-premise location, Commvault can assist in the migration of application
workloads into the cloud, either at the VM container level or the application level, all while providing
protection during the migration lifecycle while workloads are in a transition phase between on-premise
and public cloud.

Scenario / Suitability Requirements

Lift & Shift Virtual Machines (AWS & Azure Minimum 1x Media Agent On-Premise to
only) Application-consistent VM backups protect and capture workloads
are used to restore and convert
VMware/Hyper-V (Gen1) VMs into Minimum 1x Media Agent (& DDB) in
AWS/Azure instances as part of a Cloud to protect workloads post-
migration phased cut-over strategy migration in-cloud, and for optimal
migration performance
Oracle Migration Feature (Linux, AWS
only) Version 11 Service Pack 5 Oracle Migration feature supports Oracle
introduces an Oracle Application on Linux only, and requires AMI with
Migration feature to both synchronize the Oracle software pre-installed
baseline and any incremental changes as
part of a migration lifecycle. Highly Recommended to use dedicated
network to cloud provider for best
Application Restore Out-of-Place performance (AWS Direct Connect, Azure
Leverage the iDataAgents for your ExpressRoute)
supported workload to restore the target
application out-of-place to a warm
instance residing in cloud

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 15
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Protection in the Cloud


Providing operational recovery active workloads and data within an external providers cloud.

Scenario / Suitability Requirements

Data Protection for Cloud-based Workload (AWS & Azure only) Virtual Server Agent
protecting active workloads within an and Media Agent deployed on a proxy
existing IaaS Cloud (Production, within IaaS provider for agentless backup.
Dev/Test). Applications will require agent-in-guest
deployed in each VM. (AWS requires
Agent-less Instance Protection (AWS & v11 SP3 and newer. Azure requires v11
Azure only) protect instances with an SP4 and newer.)
agent-less and automated/script-less
protection mechanism through the Virtual (Applications requiring application-level
Server Agent (AWS - requires v11 SP3 and consistency, and all other cloud providers)
newer. Azure requires v11 SP4 and Agents deployed in each VM within IaaS
newer.) provider

DASH Copy to another Region, Cloud, or Minimum 1x Media Agent in Cloud, and
back to On-Premise complete data (optional) minimum 1x Media Agent at
mobility replicate to another secondary site (whether cloud or On-
geographical region with IaaS provider, a Premise)
different IaaS provider, or back to On-
Premise sites 1x DDB hosted on Media Agent

Recommended to use dedicated network


from cloud provider to On-Premise for
best performance when replicating back
to On-Premise (AWS Direct Connect,
Azure ExpressRoute)

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 16
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Architecture Sizing

Amazon

AWS CommServe Specifications


Express / Workgroup Data Center Enterprise

C4.2xlarge (8 vCPU, 15GB C4.4xlarge VM instance (16 vCPU, C4.8xlarge instance


RAM) 30GB RAM)
1x 300GB EBS General
1x 100-150GB EBS 1x 300GB EBS General Purpose Purpose volume for
General Purpose volume volume for CS Software & CSDB CS Software & CSDB
for CS Software & CSDB
Windows 2012R2 Windows 2012R2
Windows 2012 R2

AWS Media Agent Specifications


Express / 10TB FET Data Center / 25-30TB FET Enterprise / 60TB FET

Up to 10TB estimated front Up to 25-30 TB estimated front Up to 60TB estimated


end data end data front end data

C4.2xlarge VM instance C4.4xlarge VM instance (EBS- C4.4xlarge VM


(EBS-optimized, 8x vCPU, optimized, 16x vCPU, 30GB RAM) instance (EBS-
16GB RAM) optimized, 16x vCPU,
1x 600GB EBS General Purpose 30GB RAM)
1x 200GB EBS General volume for DDB
Purpose volume for DDB 1x 1TB EBS
1x 1TB EBS General Purpose for Provisioned volume
1x 400GB EBS General Index Cache for DDB @ 6500 IOPS
Purpose volume for Index
Cache Linux or Windows 2012R2 1x 1TB EBS General
Purpose for Index
Linux or Windows 2012 R2 Cache

Linux or Windows
2012R2

Important: EBS-optimized instances are recommended as they provide dedicated network bandwidth for
EBS volumes, improving De-duplication & Index Cache performance and freeing up bandwidth to
send/receive from clients, other Media Agents & S3 endpoints

Bandwidth Considerations: Should additional network bandwidth be required on the Enterprise sizing, a
C4.8xlarge instance can be used in-place of the C4.4xlarge

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 17
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Azure

Azure CommServe Specifications


Workgroup Data Center Enterprise

A6 (4 vCPU, 28GB RAM) A7 (8 vCPU, 56GB RAM) DS13 (8 vCPU, 56GB


RAM)
1x 150GB volume for CS 1x 300GB volume for CS Software
Software & CSDB & CSDB 1x 300GB Premium
Storage volume for CS
Windows 2012 R2 Windows 2012R2 Software & CSDB (P20
type)

Windows 2012R2

Azure Media Agent Specifications


Express / 10TB FET Data Center / 25-30TB FET Enterprise / 60TB FET

Up to 10TB estimated front Up to 25-30 TB estimated front Up to 60TB estimated


end data end data front end data

DS3 (4 vCPU, 14GB RAM) DS4 (8 vCPU, 28GB RAM) DS14 (16 vCPU, 112GB
RAM)
1x 200GB Premium Storage 1x 600GB Premium Storage
volume for DDB (P20 type) volume for DDB (P30 type) 1x 1TB Premium
Storage volume for
1x 400GB Storage volume 1x 1TB Storage volume for Index DDB (P30 type)
for Index Cache (non- Cache (non-premium)
premium) 1x 1TB Storage volume
Windows 2012R2 for Index Cache (non-
Windows 2012 R2 premium)

Windows 2012R2

Important: Azure VMs provide a single, fast SSD free of charge, however this storage is temporary and if
the instance is moved to another host or rebooted, all data on this volume will be lost. For performance
reasons, you can move the CommServe TempDB SQL Database to this volume, but scripting may be
required to ensure that on-reboot any required directory structures are re-created prior to SQL Server
startup, otherwise the SQL Instance (and the CommServe services) will not start successfully.

See Using SSDs in Azure VMs to store SQL Server TempDB for more information

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 18
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Architecture Considerations

Networking

Virtual Private Cloud / Azure Virtual Network


AWS and Azure both have the capability to establish an isolated logical network, referred to within
AWS as Virtual Private Cloud (VPC), and Azure Virtual Network (AVN) within Azure.

Figure 1 - AWS VPC Example


Instances/Virtual Machines deployed within a VPC/AVN by default have no access to Public
Internet, and utilize a subnet of the Customers choice. Typically VPC/AVNs are used when
creating a backbone between Virtual Machines, and also when establishing a dedicated network
route from a Customers existing on premise network directly into AWS/Azure via AWS Direct
Connect or Azure ExpressRoute.

Figure 2 - Azure Virtual Network Example


COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 19
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Bridging On-Premise Infrastructure VPN & DirectConnect/ExpressRoute


Customers may find a need to bridge their existing On-Premise infrastructure to their Public Cloud
provider, or bridge systems and workloads running between different Cloud providers to ensure a
common network layer between compute nodes and storage endpoints.

This is particularly relevant to solutions where you wish to Backup/Archive directly to the Cloud, or
DASH Copy existing backup/archive data to Object Storage within a Cloud provider.

To provide this, there are two primary choices available:

VPN Connection network traffic is routed between network segments over Public
Internet, encapsulated in a secure, encrypted tunnel over the Customers existing
Internet Connection. As the connection will be shared, bandwidth will be limited and
regular data transfer fees apply as per the Customers current contract with their ISP.

AWS Direct Connect / Azure ExpressRoute a dedicated network link is provided at the
Customers edge network at an existing On-Premise location that provides secure
routing into an AWS Virtual Private Cloud / Azure Virtual Network.

Typically, these links are cheaper when compared to a Customers regular internet
connection, as pricing is charged on a monthly dual-port fee, with all inbound and
outbound data transfers included free of charge, with bandwidth from 10Mbit/s to
10Gbit/s.

Figure 3 - An example of Azure ExpressRoute Public and Private Peering

Figure 4 - Azure ExpressRoute Peering example

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 20
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Infrastructure Access

Hypervisor access in Public Cloud


Public Cloud providers do not allow direct access to the underlying hypervisor, instead access to
functionality such as VM power on/off, Console access are provided through an REST API.

Amazon VPC Endpoints


Amazon provides VPC Endpoints which enables you to create private connections between a given
VPC and another AWS service without having to route via public Internet space. Support for S3
VPC Endpoints was announced May 2015, and while it is only supported within the same region as
the VPC, it is highly recommended as it reduces availability risks and bandwidth constraints on the
VPCs link through to public Internet.

An S3 VPC Endpoint must first be defined by creating an Endpoint Policy within the Amazon
console, but there is no change to the FQDN hostname used to define the Cloud Library within
Commvault. Instead, Amazon will ensure that DNS queries for the hostname will resolve against
the S3 VPC Endpoint, instead of the public address, and apply appropriate routing (provided the
Endpoint Policy was successfully created).

For more information on VPC Endpoints, please refer to AWS documentation:

VPC Endpoints

Data Security

In-flight
By default, all communication with Cloud Libraries utilize HTTPS which ensures that all traffic is
encrypted while in-flight between the Media Agent and the Cloud Library end-point, but traffic
between Commvault nodes is not encrypted by default. We recommend that any network
communications between Commvault modules routing over public Internet space should be
encrypted to ensure data security. This can be employed by using standard Commvault firewall
configurations (Two-Way & One-Way).

At-rest
Data stored in a public Cloud is usually on shared infrastructure logically segmented to ensure
security. Commvault recommends adding an extra layer of protection by encrypting all data at-
rest. Most Cloud providers require that any seeded data be shipped in an encrypted format.

HTTPS Proxies
Please take note of any HTTP(S) proxies between Media Agents and endpoints, whether via public
Internet or private space, as this may have a performance impact upon any backup/restore
operations to/from an Object Storage endpoint. Where possible, Commvault software should be
configured to have direct access to an Object Storage endpoint.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 21
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Data Seeding
Data Seeding is moving the initial set of data from its current location to a cloud provider in a method or
process that is different from regular or normal operations. For seeding data to an external cloud provider,
there are two primary methods:

Over-the-wire
Usually this is initially performed in small logical grouping of systems to maximize network
utilization in order to more quickly complete the data movement per system. Some organizations
will purchase burst bandwidth from their network providers for the seeding process to expedite
the transfer process.

Major cloud providers offer a direct network connection service option for dedicated network
bandwidth from your site to their cloud such as AWS Direct Connect or Azure ExpressRoute.

Please see the chart below for payload transfer time for various data sizes and speeds.

Data Set Size


Link Size 1 GB 10 GB 100 GB 1 TB 10 TB 100 TB 1 PB 10 PB
22.2 9.2 92.6
10Mbit 14m 2.2 hrs - - -
hrs days days
2.2 22.2 9.2 92.6
100Mbit 1m 20s 13m 20s - -
hrs hrs days days
13m 2.2 22.2 9.2 92.6
1Gbit 8s 1m 20s -
20s hrs hrs days days
13m 2.2 22.2 9.2 92.6
10Gbit 0.8s 8s 1m 20s
20s hrs hrs days days

Drive Shipping
If the data set is too large to copy over the network then drive seeding maybe required. Drive
seeding is coping the initial data set to external physical media and then shipping it directly to the
external cloud provider for local data ingestion.

Please refer to the Books Online Seeding the Cloud Library procedure for more information:

http://documentation.commvault.com/commvault/v11/article?p=features/cloud_storage/cloud_
library_seeding.htm

In addition to this, please note that each external cloud provider has their own process for drive
seeding:

Amazon Azure:
AWS Import Services Azure Import Services

Note: Amazon Snowball support for seeding data transfers into AWS S3 is available in both Version 10
and 11.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 22
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Consumption / Cost

Network Egress
Moving data into a cloud provider in most cases is no cost, however moving data outside the cloud
provider, virtual machine instance, or cloud provider region usually has a cost associated with it.
Restoring data from the cloud provider to an external site or replicating data between provider
regions are examples of activities that would be classified as Network Egress and usually have
additional charges.

Storage I/O
The input and output operations to storage attached to the virtual machine instance. Cloud storage
is usually metered with a fixed allowance included per month and per unit overage charges
beyond the allowance. Frequent restores, active data, and active databases may go beyond a cloud
providers Storage I/O monthly allowance, which would result in additional charges.

Data Recall
Low-cost cloud storage solutions may have a cost associated with accessing data or deleting data
before an agreed upon time period. Storing infrequently accessed data on a low-cost cloud storage
solution may be attractive upfront, however Commvault recommends modeling realistic data recall
scenarios. In some cases, the data recall charges maybe more than the potential cost savings vs.
an active cloud storage offering.

As a best practice, Commvault recommends developing realistic use case scenarios and modeling
cost against the identified scenarios to ensure the cloud solution will meet your organizations SLAs
as well as cost objectives.

Please see the links below for both the Amazon and Azure cost calculators:

Amazon Cost Calculator | Azure Cost Calculator

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 23
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Performance / Storage

Multi-Streaming with Object Storage


Object Storage performs best with concurrency, and as such with any Cloud Libraries configured
within Commvault, performance will be best attained when configured for multiple readers /
streams.

Cloud Connector Best Practices


There are additional Data Path settings and registry keys that can be modified to control the
behavior of the Cloud Connector which will have an impact on the overall performance of the
solution. For information on these settings/registry keys, please refer to Cloud Connection
Performance Tuning within Books Online here:

Cloud Connection Performance Tuning

Compression vs. De-duplication


It is recommended that De-duplication should be used where possible, with the exception of
environments where there are significant bandwidth concerns for re-baselining operations, or for
Archive only use cases.

While additional compute resources are required to provide the necessary foundation for optimal
De-duplication performance, using De-duplication even in a cloud context can still achieve greater
than a 10:1 reduction.

Even with sealing of the DDB, reduction can be better than 7:1 reduction, providing significant
network savings and reduced backup/replication windows (DASH Copy).

In comparison, Software Compression will achieve 2:1 reduction on average, and will constantly
consume the same bandwidth when in-flight between endpoints (no DASH Copy).

Block Storage vs. Object Storage


While Public IaaS environments do allow for block-based storage to be provisioned and leveraged
as Disk Libraries, the overall cost of those volumes can quickly exceed that of Object Storage. Based
on AWS pricing June 2015, an internal case study showed that Object Storage could store 3x as
much data as block-based storage (EBS General Purpose) for 33% less cost.

Additionally, with the inclusion of Micro Pruning in v10 SP11 for Object Storage, it is highly
recommended that Object Storage be the primary choice for writing data to the Cloud, and other
forms of storage by exception.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 24
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

With Azure, it should be noted that there exist both object blobs as well as page blobs. While
Commvault supports and can consume page blobs, this selection incurs a higher cost compared to
standard Block blobs, and this cost should always be evaluated first before making this decision.

If you are unsure as to which offering to use, you should consume regular object storage blobs
instead.

Micro Pruning
The Micro pruning support for Object Storage introduced in Version 10 SP11 (and subsequently
rolled up into Version 11) is effective for any new data written into the active store.

For customers who have upgraded from Version 10, but have not yet enabled micro pruning
support, Macro pruning rules will still apply to existing data within the active store until the store
has been sealed. But once the active store has been sealed, there will no longer be a need for
continued periodic sealing against that store.

Selecting the right Storage Class for Backup and Archive data
Depending on the provider, there may be different tiers of Object Storage available which offer
different levels of cost, performance and access/SLAs. This can have a significant impact on both
the cost and the user experience for the datasets within.

For example, storing infrequently accessed Backups within a Cool or Infrequent Access tier can
significantly lower the cost of your cloud bill, while storing Archives in a Cool/Infrequent Access tier
vs. a Deep Storage tier (ie. Glacier) can greatly impact accessibility for end-users to the archived
data.

To delve into further detail, these storage classes can be broken into three primary categories:

Standard / Hot this storage class represents the base offering of any Object Storage
platform inexpensive, instant access to storage on-demand. Offerings in this category
include AWS S3 (Standard), Azures Hot Blob storage and Google Cloud Storage Standard,
at an avg. price of $0.03/GB/month (as of October 2015 and depending on geographic
region).

Typically it is expected that this tier would be used for Backup & Archive workloads in a
short-term retention configuration.

Infrequent Access / Cool this is a relatively new offering that addresses what was a gap
between Standard offering and Deep Archive storage tiers, in that it is offered at a lower
price point than Standard storage ($0.01 - $0.012/GB/month) but is aimed at scenarios
where data is infrequently accessed

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 25
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

While the storage is always accessible, similar to the Standard offering, the cost model is
structured to enforce an infrequent access use case by charging $0.01/GB for any retrieval
from this storage tier. Some providers may also choose to limit the performance of this
tier as well, requiring an accurate expectation for any RTOs that you may have in your
intended architecture/design.

Offerings in this category include AWSs S3 Standard Infrequent Access tier, Azures Cool
tier and Google Nearline storage (also offered via vCloud Air).

Typically it is expected that this tier would be used for Backup workloads in a medium to
long-term retention configuration, and for Archive workloads that require instant access
to the archived data.

Deep Archive sometimes referred to as cold storage, this tier is intended for data that
will probably not be accessed again, but must be retained in the event of compliance, legal
action, or another business reason.

The cost of this storage class is the lowest compared to all three offerings avg. $0.007 to
$0.01/GB/month (as of October 2015, depending on geographic region) but as with the
Infrequent Access class, the Deep Archive classs cost model is also structured with the
expectation that retrievals are infrequent and unusual, and data will be stored for an
extended period of time.

Typically providers will charge if data is deleted prior to 30-90 days of an objects creation,
and if more than a set % of your data set per month is retrieved, then additional costs may
apply.

It is highly recommended that you review the cost options and considerations of each of these
storage classes against the use case for your architecture in order to gain the best value for your
cost model.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 26
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Infrequent Access storage class support


Support for the following Infrequent Access storage classes was introduced in Commvault v10
Service Pack 12 and Version 11 GA:

Amazon S3 Standard Infrequent Access


Google Nearline Storage (full API support)1
vCloud Air (powered by Google)2

Support for Microsoft Azures Cool storage was added in Version 11 Service Pack 4 (June-15).

1
Google Nearline Storage support via the Interoperability API was made available in Version 10 Service Pack 11.
SP12 provides enhancements and support for the full Google Cloud Storage API, allowing for the use of Service
Accounts, OAuth 2.0 authentication and Project support.
2
vCloud Air (powered by EMC) is already supported as a S3-compatible provider.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 27
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Performing Disaster Recovery to the Cloud


This section will cover the steps required to perform DR into the Amazon and Azure public cloud platforms.
We will look at the recovery methods available for both image and agent based protection. This will also
cover different recovery scenarios that may be needed to meet short recovery time objectives.

Amazon

Restoring Applications (Automated or On-Demand)


An agent in guest approach can be used to recover a wide variety of operating systems and
applications. These can be captured at the primary site and replicated to the cloud based Media
Agent in a de-duplication efficient manner. Once replicated the data can be held and restored in
the event of a DR scenario or automatically recovered to existing instances for the more critical
workloads.

Virtual Machine Recovery into AWS EC2 Instances


With the release of Version 11, the Commvault Virtual Server Agent allows for the ability to easily
perform direct conversion of protected VMware or Hyper-V (Generation 1) virtual machines into
AWS EC2 instances, from backups stored either within S3/S3-IA storage, another Cloud Library or
from an on premise Disk Library.

This process could be used as part of a Disaster Recovery strategy using Amazon as a Cold DR site,
or as a migration strategy (Lift-and-Shift).

Additional information on the Conversion feature can be located using the link below.

Converting Virtual Machines to Amazon (from VMware)


Converting Virtual Machines to Amazon (from Microsoft Hyper-V)

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 28
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Replicating Active Workloads

Continuous Data Replicator (CDR) allows near time continuous data replication for critical
workloads. These VMs will need a similarly sized EC2 instance running in AWS to receive any
replicated data. In order for CDR to operate, an EC2 instance must be running at all times to receive
application changes. Additional information on CDR can be located using the link below.

ContinuousDataReplicator (CDR)

Azure

Restoring Applications (Automated or On-Demand)


An agent in guest approach can be used to recover a wide variety of operating systems and
applications. These can be captured at the primary site and replicated to the cloud based Media
Agent in a de-duplication efficient manner. Once replicated the data can be held and restored in
the event of a DR scenario or automatically recovered to existing instances for the more critical
workloads.

Virtual Machine Recovery into Azure Instances


The Commvault Virtual Server Agent allows for the ability to easily perform direct conversion of
protected VMware or Hyper-V (Generation 1) virtual machines into Azure instances, from backups
stored either within Azure Blob storage, another Cloud Library or from an on premise Disk Library.

This process could be used as part of a Disaster Recovery strategy using Azure as a Cold DR site, or
as a migration strategy (Lift-and-Shift). Additional details can be located using the link below.

Virtual Machine Conversion to Microsoft Azure

Replicating Active Workloads


Continuous Data Replicator (CDR) allows near time continuous data replication for critical
workloads. These VMs will need a similarly sized running Azure instance to receive any replicated
data. In order for CDR to operate, an Azure instance must be running at all times to receive
application changes. Additional information on CDR can be located using the link below.

ContinuousDataReplicator (CDR)

Using Workflow to Automate DR


The Commvault Workflow engine provides a framework in which the DR runbook process, covering the
deployment of new instances, recovery of data and applications, and validation aspects of a DR operation
can be automated to deliver a simplified, end-to-end GUI-driven DR process. This can be developed and
maintained by your administrators, or with the assistance of Commvaults Personalization Services team.

For more information on Commvaults Personalization Services team, please contact your Account team.

For more information on the Workflow engine, please refer to the Workflow Overview link.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 29
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Protecting and Recovering Active Workloads in the Cloud


This section will cover the basics on protecting active workloads running on both the Amazon and Azure
public cloud offerings. Included will be the various protection approaches as well as replication and
recovery to different geographic regions. We will also touch on cross platform recovery as well as recovery
to onsite locations.

Amazon

Agent-less EC2 Instance Protection (Virtual Server Agent for AWS)


Introduced in Version 11 Service Pack 3, the Virtual Server Agent for AWS (VSA for AWS) delivers
an agent-less, block-level capture of EC2 instances and their attached EBS volumes. Restoration
options include both Full Virtual Machine recovery and limited Granular-level file recovery.

When to use the VSA for AWS

Agent-less protection approach for EC2 instances & file-level data no agents are required
in-guest to perform a block-level backup to provide Instance and File-level recovery

When not to use the VSA for AWS

When you require application-consistent backups the VSA for AWS approach creates a
Crash-consistent image of the source EC2 instance and its EBS volumes. If you require
application consistency, use an agent-in-guest either standalone or in conjunction with the
VSA for AWS backup schedule.
Protecting worker/stateless instances Worker nodes may generate valued data that is
moved to another centralized repository, and the nodes themselves do not require
protection. It is recommended to instead target that centralized repository for Data
Protection instead of the individual worker nodes, whether with VSA for AWS or agent-in-
guest, depending on the required level of backup (crash vs. application consistent)

How Instances are qualified for protection

Each VSA can be configured with 1 or more subclients. Each subclient defines a rule set on
which to Auto-Detect and Protect EC2 instances, based on a user-defined criteria of
Instance Name, Region, Availability Zone or Tags.
During the Discovery phase of the backup job, the VSA will use the subclients rule to qualify
instances to add/remove for protection within that job.

The VSA for AWS is an Early Release feature, meaning that the feature is available for use in
environments that meet all the necessary requirements validated by Commvault. For more
information on Early Release products, requirements and status, please e-mail
EarlyRelease@commvault.com

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 30
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Commvault software does not require access to the AWS hypervisor-level, instead using the
EC2/EBS REST APIs to create a Full VM Clone (AMI creation) of each EC2 instance, attaching the
EBS volumes to a nominated proxy (EC2-based VSA / Media Agent) to read and de-duplicate the
blocks before writing out to a S3 Bucket.

IntelliSnap functionality introduced in Version 11 Service Pack 4 for the VSA for AWS modifies this
behavior by simply creating an EBS snapshot and retaining the snapshot based on the Storage Policys
Snap Primary retention setting.

This has the effect of reducing backup windows considerably, providing fast, snapshot-based restoration
capability and offloading the task of extracting blocks from the snapshot into S3 for longer term
retention through the Backup Copy operation.

On snapshot cost: Use of the IntelliSnap method does mean that snapshots remain available for longer
than the backup window, however we recommend that snapshots be retained only for as long as
required. The Snap Primary can be configured to retain at least 1 snapshot, keeping snapshot costs at a
minimum while providing fast backup and restoration capabilities.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 31
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Architecture Requirements for the VSA for AWS

Minimum 1x VSA/MA per Region,


Recommended 1x VSA/MA per Availability Zone
o Each 1x VSA/MA node represents a single Windows 2012 R2 EC2 instance with
the Virtual Server Agent and Media Agent modules deployed. The EC2 instance
specifications should match the Media Agent specifications within this
Architecture Guide.
o If the environment contains more than >25 VMs within a single Availability Zone,
it is recommended to scale out with additional VSA proxies (1 or more) placed
inside of the source AZ to improve performance and reduce cross-zone traffic.

Architecture Recommendations

Use of the IntelliSnap configuration is highly recommended (requires Verson 11 Service


Pack 4) to improve backup & restore times. Use of this method does mean that snapshots
remain available for longer than the backup window, however we recommend that
snapshots be retained only for as long as required. The Snap Primary can be configured to
retain at least 1 snapshot, keeping snapshot costs at a minimum while providing fast
backup and restoration capabilities.
If the AMI was sourced from the Marketplace, any volumes that were deployed as part of
that AMI cannot be targeted for snapshots. Only new volumes created and attached post-
instance launch can be snapshotted. This is by Amazon Web Services design.
(Backup Copy / Streaming) Use of the S3 VPC Endpoint is highly recommended to improve
throughput to/from S3 buckets.
(Backup Copy / Streaming) Configuring more than 10 readers for a single VSA for AWS
proxy may cause snapshot mount operations to fail. Consider scaling out with multiple
VSA proxies if higher concurrency is required.
(Backup Copy / Streaming) Use of Provisioned IOPS for the De-Duplication Database used
by the Media Agent module is highly recommended for optimal performance.
(Backup Copy / Streaming) Disable Granular Recovery of files if granular recovery is not
required, or agents-in-guest are being used to collect large file system datasets. This will
improve the backup window by removing the need to walk the file system structure
within the EBS volumes.

Notes on VSA for AWS Granular-level File Recovery: Granular-level file recovery is currently limited to
NTFS (Windows), and ext2/3 file systems. Restoration of granular-files to a EC2 instances requires the
deployment of a File System Agent (Recovery Only) within the EC2 instance. Agent-less file recovery in
AWS is not supported due to API limitations.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 32
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Agent-In-Guest (Streaming)
An agent in guest approach can be used to protect a wide variety of operating systems and
applications. These can be captured on the production workload and protected to the Media Agent
residing in AWS, using Client-side De-Duplication to reduce the network consumption within the
Cloud. These can also be replicated to a secondary Media Agent residing in a different geographic
region. Once replicated the data can be held and restored in the event of a DR scenario or
automatically recovered to existing instances for the more critical workloads.

When to use Agent-in-Guest approach:

When you require application-consistent backups use an agent-in-guest either


standalone or in conjunction with the VSA for AWS backup schedule. Deployment of
agents can either be pushed by Commvault software, baked into AMI templates using de-
coupled installation, or deployed as part of a continuous deployment method (ie.
Puppet/Chef/Ansible).
When you require granular-level protection and restoration features for applications the
Commvault iDataAgents can deliver granular-level protection for supported application
workloads, such as SQL Server or Oracle Database, in comparison to a Full VM or File-level
approach.

Architecture Requirements for Agent-in-Guest:

Minimum 1x iDataAgent per Instance for the intended dataset (ie. SQL, File). Multiple
iDataAgents can be deployed on the same instance.
Minimum 1x Media Agent per region. Media Agents connect to the target Object Storage,
and can either be deployed on the same instance, or on a dedicated host for a fan-in
configuration. The EC2 instance specifications of the Media Agent should match the Media
Agent specifications within this Architecture Guide.
Check the Systems Requirements section in Books Online to determine if the iDataAgent
supports your application (http://documentation.commvault.com)

Architecture Recommendations

Use of multiple readers to increase concurrency to the Object Storage target is


recommended
Use of the S3 VPC Endpoint is highly recommended to improve throughput to/from S3
buckets

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 33
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Snapshot-based Agent-In-Guest (EBS IntelliSnap)


In addition to the standard agent-in-guest streaming approach, for supported configurations the
agent can integrate the EBS snapshot facility into a seamless framework that combines fast storage-
based snapshots with application consistency, without the need for a collection of scripts and
disparate snapshot, backup and recovery tools.

While the Snapshot-based Agent-in-Guest approach is currently only supported for Oracle on Linux,
and the Linux File System agent, there is no difference with the actual agents themselves agents
are capable of both Streaming and IntelliSnap backup approaches, and it only requires that
IntelliSnap be configured.

The agent is deployed on the production EC2 instance, orchestrating work between the target
workload and the EBS API, with additional support to extracting data from those snapshots to be
stored in a de-duplicated, compressed format within S3/S3-IA for long-term retention at a lower
cost point. (This process of extracting from the snapshot is known as a Backup Copy job.)

This allows you to keep cost at a minimum while also protecting against failure of single Availability
Zones and Regions by combining both EBS and S3 storage options and redundancy offerings.

When to use Snapshot-based Agent-in-Guest approach instead of the Streaming based approach:

When you require fast, snapshot-based recovery use the snapshot-based agent-in-guest
to leverage EBS snapshots while maintaining application consistency and granular-level
recovery options for workloads that require fast recovery.
When you require application-consistent backups with a shorter backup window the
snapshot-based agent-in-guest approach allows you to execute fast backups, reducing the
amount of time normally reserved for a backup window in order to extract the blocks.
When you require minimal load against the production server the snapshot-based agent-
in-guest approach operates with minimal load against the production host, and can be
instructed to perform the Backup Copy (extracting from snapshot to S3/S3-IA) using a
separate EC2 instance as a proxy.

Architecture Requirements for Snapshot-based Agent-in-Guest:

Minimum 1x iDataAgent per Instance for the intended dataset (ie. SQL, File). Multiple
iDataAgents can be deployed on the same instance.
Amazon must be configured as an array in Commvault under Array Management. For
more information, see Setting Up the Amazon Array Using Array Management here:
http://documentation.commvault.com/commvault/v11/article?p=features/snap_backup/
configuration/on_cs/t_snap_amazon_array_adding.htm
Any selected proxy must be in the same availability zone and region in order to both access
any volumes created from snapshots and for best performance.
(Backup Copy) Minimum 1x Media Agent per region. Media Agents connect to the target
Object Storage, and can either be deployed on the same instance, or on a dedicated host

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 34
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

for a fan-in configuration. The EC2 instance specifications of the Media Agent should
match the Media Agent specifications within this Architecture Guide.
Check the Systems Requirements section in Books Online to determine if the iDataAgent
supports your application
http://documentation.commvault.com/commvault/v11/article?p=features/snap_backup/
prerequisites/r_snap_amazon_sysreq.htm

Architecture Recommendations

While AWS snapshots are independent of the original volume, they are still only redundant
within a single Availability Zone. Extracting the data from the snapshot into object storage
is highly recommended to gain higher redundancy, whether just single region (store in
S3/S3-IA) or multiple regions (store in S3/S3-IA, DASH Copy/replicate to another region)
(Backup Copy) Use of multiple readers to increase concurrency to the Object Storage target
is recommended
(Backup Copy) Use of the S3 VPC Endpoint is highly recommended to improve throughput
to/from S3 buckets

Recommendations for Oracle

Take the sizing of the production Oracle instance into consideration when selecting a
backup frequency.
o As part of the backup, the target Oracle instance will be placed into backup mode
until the EBS snapshot has been successfully created, then Commvault will instruct
Oracle to exit backup mode.
o While this process is generally quite efficient, if this is the first snapshot taken for
the EBS volumes, the instance may be placed into backup mode for longer than
expected (minutes instead of seconds) and the instance and EC2 instance should
be sized appropriately for increased redo log activity until the conclusion of the
snapshot.
If the Oracle EC2 instance was provisioned as part of an Marketplace AMI, the volumes
packaged with that AMI cannot be targeted for EBS snapshots as per Amazon design.
Ensure that any desired instance data is stored on volumes created post-launch to enable
snapshot operations.
Use separate EBS volumes and mount points for both Oracle data and archive log files.
Do not use nested file system mounts for Oracle IntelliSnap.
The datafiles and archive log files for each database should be isolated on their own volume
groups. If volumes are shared for multiple databases, use the Multi Instance Snap
Optimization feature, which snaps and reverts all the databases together. For more
information, see Multi-Instance Snap Optimization:
http://documentation.commvault.com/commvault/v11/article?p=products/oracle/snap/
snap_optimization.htm

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 35
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

If you enable the block change tracking file, specify its location on a device that also
contains the data files for the database. If the instance is a Marketplace sourced AMI, you
should not place this on a volume that was packaged with the AMI, or the snapshot
creation operation will fail.
(Backup Copy) If configuring a proxy for the Backup Copy operation, please ensure that you
conform with requirements as stated under the Books Online section, Configuring Proxy
Clients for Backup Copy Operations
http://documentation.commvault.com/commvault/v11/article?p=products/oracle/snap/
config_adv.htm#Configuring_Proxy_Clients_for_Backup_Copy_Operations

Notes

The Oracle iDataAgent, when in an IntelliSnap configuration, will only snapshot EBS
volumes that contain the target database. At time of backup the agent interrogates the
Oracle instance to determine the source path for the data and log destinations back to the
OS mount path, before then resolving this to a EBS volume ID that is used during the
snapshot API call.
For more information on Oracle IntelliSnap, please consult the Books Online section:

http://documentation.commvault.com/commvault/v11/article?p=products/oracle/snap/
deployment.htm

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 36
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Continuous Data Replicator (CDR)


CDR allows near time continuous data replication for critical workloads. Replication can be
configured as Direct Replication (1:1 source to destination host), or as a Fan-in or Fan-out based
replication configuration.

Additional information on CDR can be located using the link below.

ContinuousDataReplicator (CDR)

When to use CDR approach:

Fan-in replication of File data-sets from Remote regions to a Cloud-based host CDR
supports a fan-in based replication approach (Many-to-1) in which data from remote sites
can be replicated in to a target Cloud-based host
Guest-level Replication of File and SQL/Exchange data-sets CDR can be used to perform
asynchronous block-based replication of File, SQL and Exchange datasets between hosts,
irrespective of the source/destination hardware/hypervisor and storage. This allows data
to be kept in-sync between an on-premise host and a cloud-based host.

When not to use CDR approach:

Replicating VMs/Hosts CDR is intended as a host-based data replication feature, and it


should not be used to attempt to replicate Virtual Machines or System volumes as a
replacement Bare Metal Recovery strategy.

Architecture Requirements for CDR:

Storage for the replication journal is required for each source and destination host ensure
that this volume is available and is sized to support both the daily change rate, and
sufficient storage in the event of loss of network connectivity between hosts
For Direct Replication configurations, a similar sized EC2 instance should be configured as
the destination target.
Check that the data set and Operating System is supported by the CDR agent3

3
ContinuousDataReplicator System Requirements -
http://documentation.commvault.com/commvault/v11/article?p=system_requirements/flr.htm

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 37
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Azure

Agent-less VM Protection (Virtual Server Agent for Azure)


Introduced in Version 11 Service Pack 4, the Virtual Server Agent for Azure (VSA for Azure) delivers
an agent-less, block-level capture of Azure VM instances and their attached block volumes.
Restoration options include both Full Virtual Machine recovery and limited Granular-level file
recovery.

When to use the VSA for Azure

Agent-less protection approach for Azure instances & file-level data no agents are
required in-guest to perform a block-level backup to provide Instance and File-level
recovery

When not to use the VSA for Azure

When you require application-consistent backups the VSA for Azure approach creates a
Crash-consistent image of the source VM and its block volumes. If you require application
consistency, use an agent-in-guest either standalone or in conjunction with the VSA for
Azure backup schedule.
Protecting worker/stateless instances Worker nodes may generate valued data that is
moved to another centralized repository, and the nodes themselves do not require
protection. It is recommended to instead target that centralized repository for Data
Protection instead of the individual worker nodes, whether with VSA for Azure or agent-
in-guest, depending on the required level of backup (crash vs. application consistent)

How Instances are qualified for protection

Each VSA can be configured with 1 or more subclients. Each subclient defines a rule set on
which to Auto-Detect and Protect Azure VMs, based on a user-defined criteria of Instance
Name or Resource Groups.
During the Discovery phase of the backup job, the VSA will use the subclients rule to qualify
instances to add/remove for protection within that job.

The VSA for Azure is an Early Release feature, meaning that the feature is available for use in
environments that meet all the necessary requirements validated by Commvault. For more
information on Early Release products, requirements and status, please e-mail
EarlyRelease@commvault.com

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 38
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Commvault software does not require access to the Azure hypervisor-level, instead using the REST
APIs to create snapshots of each block volume, attaching the snapshot to a nominated proxy (Azure
VM-based VSA / Media Agent) to read and de-duplicate the blocks before writing out to an Azure
Hot or Cool target.

Architecture Requirements for the VSA for Azure

Minimum 1x VSA/MA per Region,


Recommended 1x VSA/MA per Availability Set
o Each 1x VSA/MA node represents a single Windows 2012 R2 Azure VM with the
Virtual Server Agent and Media Agent modules deployed. The Azure instance
specifications should match the Media Agent specifications within this
Architecture Guide.
o If the environment contains more than >25-50 VMs within a single Availability Set,
it is recommended to scale out with additional VSA proxies (1 or more) placed
inside of the source Availability Set to improve performance and reduce cross-zone
traffic by containing it within the fault/update domain.

Architecture Recommendations

While the readers count can be increased to improve concurrency per VSA/MA node,
consider scaling out with multiple VSA proxies. Azure recommendations state that for
optimal performance, you will want to limit the number of highly utilized disks attached
per worker node to avoid possible throttling.4
Use of Premium Storage for the De-Duplication Database and Index Cache used by the
Media Agent module is highly recommended for optimal performance.
Disable Granular Recovery of files if granular recovery is not required, or agents-in-guest
are being used to collect large file system datasets. This will improve the backup window
by removing the need to walk the file system structure within the Azure block volumes.

4
Virtual Machine disk limits, from Azure Documentation: https://azure.microsoft.com/en-
us/documentation/articles/azure-subscription-service-limits/

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 39
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Agent-In-Guest (Streaming)
An agent in guest approach can be used to protect a wide variety of operating systems and
applications. These can be captured on the production workload and protected to the Media Agent
residing in Azure, using Client-side De-Duplication to reduce the network consumption within the
Cloud. These can also be replicated to a secondary Media Agent residing in a different geographic
region. Once replicated the data can be held and restored in the event of a DR scenario or
automatically recovered to existing instances for the more critical workloads.

When to use Agent-in-Guest approach:

When you require application-consistent backups Deployment of agents can either be


pushed by Commvault software, or baked into an Azure template using de-coupled
installation, or deployed as part of a continuous deployment method (ie.
Puppet/Chef/Ansible).
When you require granular-level protection and restoration features for applications the
Commvault iDataAgents can deliver granular-level protection for supported application
workloads, such as SQL Server or Oracle Database, in comparison to a Full VM or File-level
approach.

Architecture Requirements for Agent-in-Guest:

Minimum 1x iDataAgent per Instance for the intended dataset (ie. SQL, File). Multiple
iDataAgents can be deployed on the same instance.
Minimum 1x Media Agent per region. Media Agents connect to the target Object Storage,
and can either be deployed on the same instance, or on a dedicated host for a fan-in
configuration. The Azure instance specifications of the Media Agent should match the
Media Agent specifications within this Architecture Guide.
Check the Systems Requirements section in Books Online to determine if the iDataAgent
supports your application (http://documentation.commvault.com)

Architecture Recommendations

Use of multiple readers to increase concurrency to the Azure Blob endpoint is


recommended

Azure Snapshots
Azure snapshots allow for a crash consistent point in time copy of an Azure disk, and can be
automated with the use of Workflows. Additional details can be located using the link below.

Blob Snapshot Creation

Continuous Data Replicator (CDR)


CDR allows near time continuous data replication for critical workloads. Replication can be
configured as Direct Replication (1:1 source to destination host), or as a Fan-in or Fan-out based
replication configuration.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 40
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Additional information on CDR can be located using the link below.

ContinuousDataReplicator (CDR)

When to use CDR approach:

Fan-in replication of File data-sets from Remote regions to a Cloud-based host CDR
supports a fan-in based replication approach (Many-to-1) in which data from remote sites
can be replicated in to a target Cloud-based host
Guest-level Replication of File and SQL/Exchange data-sets CDR can be used to perform
asynchronous block-based replication of File, SQL and Exchange datasets between hosts,
irrespective of the source/destination hardware/hypervisor and storage. This allows data
to be kept in-sync between an on-premise host and a cloud-based host.

When not to use CDR approach:

Replicating VMs/Hosts CDR is intended as a host-based data replication feature, and it


should not be used to attempt to replicate Virtual Machines or System volumes as a
replacement Bare Metal Recovery strategy.

Architecture Requirements for CDR:

Storage for the replication journal is required for each source and destination host ensure
that this volume is available and is sized to support both the daily change rate, and
sufficient storage in the event of loss of network connectivity between hosts
For Direct Replication configurations, a similar sized Azure instance should be configured
as the destination target.
Check that the data set and Operating System is supported by the CDR agent5

Machine Export from Azure


Azure offers the ability to export running machines in vhd format. These allow for import into the
most commonly used hypervisors.

Export Azure VM

5
ContinuousDataReplicator System Requirements -
http://documentation.commvault.com/commvault/v11/article?p=system_requirements/flr.htm

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 41
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Other Public Cloud Environments


For Public Infrastructure-as-a-Service environments other than AWS or Azure, such as VMwares vCloud Air
offering, the following approaches can be adopted.

Agent-In-Guest
An agent in guest approach can be used to protect a wide variety of operating systems and
applications. These can be captured on the production workload and protected to the Media Agent
residing in Azure, using Client-side De-Duplication to reduce the network consumption within the
Cloud.

These can also be replicated to a secondary Media Agent residing in a different geographic region.
Once replicated the data can be held and restored in the event of a DR scenario or automatically
recovered to existing instances for the more critical workloads.

Both the agents and the Media Agent can be deployed within the Public Cloud environment on
compute nodes. Please refer to the CommVault De-Duplication Building Blocks guide for hardware
specifications to match against the service catalogue or customization options available:

http://documentation.commvault.com/commvault/v11/article?p=system_requirements/commce
ll_sizing/ma_standard_mode.htm

Continuous Data Replicator (CDR)


CDR allows near time continuous data replication for critical workloads. Replication can be
configured as Direct Replication (1:1 source to destination host), or as a Fan-in or Fan-out based
replication configuration.

Additional information on CDR can be located using the link below.

ContinuousDataReplicator (CDR)

When to use CDR approach:

Fan-in replication of File data-sets from Remote regions to a Cloud-based host CDR
supports a fan-in based replication approach (Many-to-1) in which data from remote sites
can be replicated in to a target Cloud-based host
Guest-level Replication of File and SQL/Exchange data-sets CDR can be used to perform
asynchronous block-based replication of File, SQL and Exchange datasets between hosts,
irrespective of the source/destination hardware/hypervisor and storage. This allows data
to be kept in-sync between an on-premise host and a cloud-based host.

When not to use CDR approach:

Replicating VMs/Hosts CDR is intended as a host-based data replication feature, and it


should not be used to attempt to replicate Virtual Machines or System volumes as a
replacement Bare Metal Recovery strategy.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 42
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Architecture Requirements for CDR:

Storage for the replication journal is required for each source and destination host ensure
that this volume is available and is sized to support both the daily change rate, and
sufficient storage in the event of loss of network connectivity between hosts
For Direct Replication configurations, a similar sized instance should be configured as the
destination target.
Check that the data set and Operating System is supported by the CDR agent6

6
ContinuousDataReplicator System Requirements -
http://documentation.commvault.com/commvault/v11/article?p=system_requirements/flr.htm

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 43
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Application Migration
Commvault can assist in Application Migration efforts when shifting from on-premise facilities to Public
Cloud providers such as AWS and Azure. By leveraging the power of the Data Management platform,
workloads can be migrated through a number of methods.

Virtual Machine Restore & Convert (Lift and Shift, AWS/Azure only)
The Virtual Server Agent can capture Virtual Machines from VMware and Hyper-V based platforms
in an application-consistent method (VSS call / VMware Guest Tools hooks / Hyper-V Integration
Tools) to ensure that a consistent image of the guest, and the applications residing within, is
captured correctly.

With this image, the Virtual Server Agent can then restore and convert (VMware & Hyper-V (Gen1))
the Virtual Machine into AWS EC2 instances, or Azure VMs directly, and the process can handle
single or multiple Virtual Machines.

This process can be performed interactively through the CommCell Console, via Commvault
Workflow or API calls.

Oracle Application Migration (Linux, AWS only)


Introduced in Version 11 Service Pack 5, the Oracle iDataAgent can now perform a migration of an
Oracle Instance from a physical or virtual machine on-premise into an Amazon EC2 Instance.

The process requires the Oracle iDataAgent for Linux to be deployed on the source machine. At
which point the migration process will automate:

Capturing the application server physical configuration


Protecting the application data
Provisioning the cloud instance and storage
Restoring the data
Validating the restore
Continuously applying changes from the production database backups to the migrated
database by using the Live Sync feature.

Application Out-of-Place Restore (All supported platforms)


All Application iDataAgents support the capability to restore a given source dataset out-of-place to
an alternate location. In this method, the data is captured from the source system (physical, or
virtual), and then either directly from the source copy or replicated to cloud (DASH Copy), a restore
to the destination is submitted.

The process required the supported iDataAgent to be deployed on both the source instance, and
the destination EC2 / Azure VM instance.

This process can be performed interactively through the CommCell Console, via Commvault
Workflow or API calls.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 44
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Deployment

Remote Access / Bring Your Own Software


As with all IaaS offerings, remote access to Virtual Machine instances can be achieved with your favorite
protocol / software (RDP for Windows, SSH for Linux instances) and Commvault module deployment can
be achieved with the current procedures listed in Books Online.

Installation Basics
The following links cover the steps when installing the CommServe in the cloud. This is only needed
when the primary CommServe will be running on the hosted cloud VM or used for DR recovery.
Multiple modules can be deployed in a single installation pass to streamline deployment.

Installation Overview -
http://documentation.commvault.com/commvault/v11/article?p=deployment/com
mon_install/c_install_overview.htm
Installing the CommServe -
http://documentation.commvault.com/commvault/v11/article?p=deployment/com
mon_install/p_commserve_install.htm
Installing the Media Agent -
http://documentation.commvault.com/commvault/v11/article?p=deployment/com
mon_install/p_mediaagent_install.htm
Installing the Virtual Server Agent (Amazon) -
http://documentation.commvault.com/commvault/v11/article?p=products/vs_amaz
on/c_vamz_deployment.htm

CommServe Disaster Recovery Solution Comparison


The following link covers CommServe DR Solution comparisons for building a standby DR
CommServe in the Cloud, or simply restoring on-demand (DR Backup restore):

CommServe Disaster Recovery

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 45
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Pre-packaging Commvault Software within a VM Template


For environments where deployment time is reduced by pre-preparing software and configuration within
VM templates, such as Amazon Machine Images, the Commvault iDataAgents can also be deployed in
Decoupled mode. This means that the iDataAgent is deployed within the instance, but will only be activated
upon registration with the CommServe.

For more information, please refer to the Installing the Custom Package instructions within Books Online:

Installing the Custom Package on Windows -


http://documentation.commvault.com/commvault/v11/article?p=deployment/install/custom_
package/t_custom_package_install_win.htm
Installing the Custom Package on Linux -
http://documentation.commvault.com/commvault/v11/article?p=deployment/install/custom_
package/t_custom_package_install_unix.htm

Automating Deployment with Continuous Delivery


For environments using Continuous Delivery toolsets such as Puppet, Chef or Ansible, Commvault supports
deployment methods that allow administrators to both control agent deployment and configuration to
provide an automated deploy & protect outcome for applications and servers.

For more information on creating an unattended installation package for inclusion in a recipe, please refer
to the Unattended Installation guide within Commvault Books Online:

Unattended Installation -
http://documentation.commvault.com/commvault/v11/article?p=deployment/install/c_silent_i
nstall.htm

For more information on using Commvault softwares XML / REST API interface to control configuration
post-deployment, please refer to the Command Line Overview section to review options available for
each iDataAgent:

REST API Overview -


http://documentation.commvault.com/commvault/v11/article?p=features/rest_api/rest_api_o
verview.htm
Command Line Overview -
http://documentation.commvault.com/commvault/v11/article?p=features/cli/command_line_
overview.htm

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 46
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Cloud Library Configuration


This section covers the steps needed to configure cloud storage as a primary or secondary storage target.
Please keep in mind that use cases outside of archive will require Commvault infrastructure in the cloud to
recover any protected data.

For most backup use cases (except for very small environments limited to 100 GB in payload size), cloud as
a direct storage target is not recommended. For performance and responsiveness, a primary copy should
be stored on an on-site disk library and a secondary copy should be hosted on the cloud storage. The
secondary copy should be setup as an encrypted network optimized DASH copy to the cloud.

The link below lists all of the supported direct cloud storage targets.

Supported Cloud Storage

The link below covers cloud storage target setup and management.

Cloud Storage - Overview

Details on performance tuning are covered below.

Cloud Connector Performance Tuning

Unsupported Cloud Storage Configurations


If a Cloud Storage target is not listed in the Cloud Storage Support table, but the cloud storage endpoints
are publically accessible, and provide either a S3-compatible or OpenStack-compatible REST API, you can
verify the compatibility of the storage offering with Commvault.

Depending upon your cloud device type you may choose to verify the compatibility between:

Amazon S3 supported vendors and Simpana

OpenStack Object Storage supported vendors and Simpana

For devices that are not publically accessible, please contact your account manager or Commvault Products
for more information on the Cloud Storage certification process (products@commvault.com).

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 47
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Additional Resources

Documentation

Books Online Cloud Storage


http://documentation.commvault.com/commvault/v11/article?p=features/cloud_storage/cloud_
storage_overview.htm

The Cloud Storage section from Commvaults Books Online documentation covers technical
procedures and information on Supported Cloud Targets, Advanced procedures, Troubleshooting
and FAQ sections for Commvault customers.

AWS IAM Permissions


All required Amazon user permissions can be accessed from Books Online here:

AWS User Permissions for Backup and Restore


http://documentation.commvault.com/commvault/v11/article?p=products/vs_amazon/r_us
er_permissions_backup_restore.htm
AWS User Permissions for VM Conversion
http://documentation.commvault.com/commvault/v11/article?p=products/vs_amazon/r_va
mz_user_permissions_conversion.htm

Videos

Backup and Archive to the Cloud with Microsoft Azure and Commvault
https://www.youtube.com/watch?v=ygtDuvvAl6M

Michael Porfirio, Director of Systems Engineering ANZ from Commvault discusses backing up and
archiving to Microsoft Azure with Commvault, covering file sync, file share, endpoint protection,
retaining on premise copies, automated provisioning and recovery and reference copy.

2 Clicks to the Cloud with AWS and Commvault


https://www.youtube.com/watch?v=H5MOG0NZV0Q

Focuses on creating an S3 container and configuring as a Cloud Library within Commvault v11.

2 Clicks to the Cloud with Azure and Commvault


https://www.youtube.com/watch?v=jVZFxMVhysk

Focuses on creating an Azure Storage Library within Commvault v11.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 48
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Backup in AWS (Technical Feature, VSA for AWS)


https://www.youtube.com/watch?v=h3L-FDdSD7w

Technical showcase for the Virtual Server Agent for AWS, demonstrating IntelliSnap functionality
(Version 11 SP4)

Backup in Azure (Technical Feature, VSA for Azure)


https://www.youtube.com/watch?v=Saqo_UvEfU0

Technical showcase for the Virtual Server Agent for Azure (Version 11 SP4)

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 49
Appendix A: AWS Reference Architecture Diagrams

Backup and Archive to AWS

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 50
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Cold/Warm Disaster Recovery to AWS

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 51
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Migration into AWS

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 52
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Backup in AWS

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 53
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Appendix B: Azure Reference Architecture Diagrams

Backup and Archive to Azure

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 54
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Cold/Warm Disaster Recovery to Azure

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 55
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Migration to Azure

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 56
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Backup in Azure

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 57
Appendix C: AWS/Azure Concepts and Terminology
The following section covers the basic concepts and technology used in the Amazon and Azure public cloud
service offerings.

Amazon (AWS)

Region
A Region is a separate geographic area where AWS services are offered. Services can be replicated
between regions for geographic redundancy. Not all services are available in every region.

Availability Zone
An Availability Zone is an isolated service location within a region connected via low-latency links.
Services can be replicated between Availability Zones for protection against single zone or
datacenter failures.

Region Product Page

Elastic Compute Cloud (EC2)


EC2 is the product name of the virtual machine IaaS

Instance Reservation
By default, all instances requested are On-Demand, however if instances are reserved for a period
of time then there can be significant discounts in consumption.

RESERVED - Reserved instances is where your organization would commit to usage for a
given time period (i.e. 1-3 years). Discounts can be significant depending on commitment
type.
ON -DEMAND - On-Demand instances is where your organization would have no
commitment, can start or stop at any time, and pay a simple hourly rate.
SPOT - Similar to On-demand, however your organization will have to bid for instances in
the AWS market place. Your organizations instances will keep on running until you stop
the instance or the current spot price exceeds your organizations bid price.

EBS-Optimized Instances
Specific EC2 instance types that have dedicated full-duplex network throughput for disk I/O.

EC2 Product Page

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 58
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Elastic Block Storage (EBS)


EBS is the product name of the classic block storage service attached to EC2 instances, which
traditional operating systems can lay a file system and use. EC2 instances utilize shared bandwidth
network and storage operations. For dedicated bandwidth for storage I/O, select an EC2 that is
EBS-Optimized.

GENERAL P URPOSE - General purpose is a hybrid storage offering that utilizes traditional HDDs
backed by SSD for performance. All new EBS storage provisioned with EC2 are general purpose
by default.
PIOPS - PIOPS is a pure SSD offering where your organization can pay for specific IOPS levels
and latency.
MAGNETIC - Magnetic is the legacy EBS offering that is comprised of traditional HDDs only,
hence the name magnetic. Use of Magnetic EBS volumes should be discouraged.

EBS Snapshots
EBS snapshots are a point-in-time compact copy of data in an EBS volume, which can be access
instantaneously, shared, or copied across regions.

EBS Product Page

Simple Storage Service (S3)


S3 is the product name for the object storage service. Object storage is fundamentally different
than file or block storage. S3 storage can only be accessed through the REST/API from AWS.

BUCKET - A bucket is a logical container of objects, where security permissions can be set and
inherited by the child objects. You cant have objects in S3 without a Bucket created first.
OBJECT - An Object is a reference to a single item of unstructured data such as file, backup, or
anything else. The key term is single because you cant put two files in a single object. Each file
would become an individual object that would be addressable separately including API access,
permissions, and metadata.

S3 Product Page

Glacier
Glacier is the product name for AWSs cold storage service. In general, your organizations data will
write to S3 and then will be aged off to Glacier by a data management policy set within S3.

Recall is hours not minutes


Recall can be expensive if your organization exceeds the allowed monthly allowance
Deleting data before 3 months will incur additional charges

Glacier Product Page

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 59
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Azure

Regions
A Region is a separate geographic area where Azure services are offered. Services can be replicated
between regions for geographic redundancy. Not all services are available in every region.

FACILITIES

Facilities are datacenters within a region utilized to offer increased availability and redundancy with
low-latency. Your organization can have services span multiple facilities for datacenter level fault
protection.

Region Product Page

Virtual Machines
Virtual Machine is the product name for virtual machine IaaS

Virtual Machine Product Page

Blob Storage
Blob Storage is the product name for Azures object storage for unstructured data. Object storage
is fundamentally different than file or block storage. Blob storage can only be accessed through the
REST/API from Azure.

S TORAGE ACCOUNT provides access to Azure storage and creates a unique namespace for your
organizations storage resources.

S TANDARD stores data on HDDs exclusively.

P REMIUM stores data on SSDs exclusively for high I/O and throughput workloads.

CONTAINER is a logical grouping of blobs where container level security policies can be enabled.

B LOB is a single item of unstructured data such as document, media file, logs, or backup.

REPLICATION AND REDUNDANCY Azure provides a variety of options to replicating your organizations
data.

L OCALLY REDUNDANT S TORAGE (LRS) maintains three copies of data within a single facility in a single
region.

ZONE R EDUNDANT S TORAGE (ZRS) maintains three copies of data across two to three facilities within
a single region.

GEO REDUNDANT STORAGE (GRS) maintains six total copies of data with three copies in the primary
region and three copies in a secondary region. GRS also has a read-only option where out of region
data can be accessed in the event the primary region is unavailable.

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 60
Public Cloud Architecture Guide v2.2 SEPTEMBER 2016

Blob Storage Product Page

ExpressRoute
Express Route is the product name for a private connection between Azure datacenter and your
premise in a co-location facility. Generally this is utilized for hybrid environments where significant
data throughput is needed or initial seeding.

ExpressRoute Product Page

COMMVAULT PRODUCTS
FOR GENERAL RELEASE P a g e | 61

Das könnte Ihnen auch gefallen