MediaAgent Design Downloadable Resource

COMMVAULT PROPRIETARY AND CONFIDENTIAL INFORMATION- INTERNAL AND PARTNER UNDER NDA USE ONLY- DO NOT DISTRIBUTE
MediaAgent Design Fundamentals

COMMVAULT PROPRIETARY/CONFIDENTIAL – FOR COMMVAULT PARTNERS UNDER NDA USE – NOT TO BE FURTHER DISTRIBUTED
MediaAgent
Design
Fundamentals
FOR SALES ENGINEERS
Presented by
COMMVAULT
Copyright © 2022 Commvault | All Rights Reserved
COMMVAULT CONFIDENTIAL AND PROPRIETARY. INTERNAL AND PARTNER UNDER NDA USE ONLY.
Notes:
Welcome to the “MediaAgent Design Fundamentals” module, presented by Commvault.
For your information, a PDF version of this e-learning module can be downloaded by clicking on the
resources link in the top right-hand corner of the training window.
commvault.com | 888.746.3849
©1999-2023 Commvault Systems, Inc. All rights reserved. Commvault, Commvault and logo, the “C hexagon” logo, and “Be ready” are trademarks or registered
trademarks of Commvault Systems, Inc. A complete list of trademarks owned by Commvault can be found here. All other third party brands, product names, and
trademarks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Learning Goals
Understand
MediaAgent placement considerations and

design methodology
MediaAgent sizing and hardware specifications

for deduplication
MediaAgent availability and anatomy
Design
Architect optimal MediaAgent Server placement

and sizing
COMMVAULT CONFIDENTIAL AND PROPRIETARY. INTERNAL AND PARTNER UNDER NDA USE ONLY. Copyright © 2022 Commvault | All Rights Reserved 2
Notes:
In this module you will learn the fundamentals of MediaAgent design for a Commvault® solution.
You will learn how to use the information that you gathered through the solution discovery phase,
including the environment overview and data profiles. This information will help you determine the
locations where MediaAgents should be placed, how many are required, and what specification
they should be. We’ll cover certain sizing and hardware specifications for MediaAgents along with a
deeper view into their technology and anatomy.
On completion of this module, you will be able to architect a solution with the optimal MediaAgent
design that is supported by Commvault®.
Components and Placements
Components
and
Placements
Notes:
Now let’s look at MediaAgent components and how to properly place them.
MediaAgent Components
Notes:
The MediaAgent, an essential part of every solution’s data plane, comprises of various physical and
logical components that we’ll cover next.
The first physical component of a MediaAgent is the compute layer. Although typically deployed on
physical hardware, an increasing number of MediaAgents are deployed as virtual instances, either
on prem or in the cloud. MediaAgents typically generate significant I/O, so careful planning of
virtual resources is required.
The second physical component of a MediaAgent is the storage targets that are used to hold the
various copies of production data. At least one Media Agent must have written capabilities to copy
production data to storage. The storage can be direct attached (including block storage), network
attached storage, or cloud storage. Storage targets can also be removable media like tape or cloud
migration devices, for example Amazon Snowball storage.
The next component of a MediaAgent is the logical storage plans. A plan defines where data gets
copied, how long that data remains there, the SLA, and the various storage utilization features. This
information is covered in the Plans module.
Another component of a MediaAgent is the software agent or agents required to communicate
with production systems. Depending on the requirements, additional software can be installed on
the MediaAgent, which enables native communication with the production systems, reduces
overhead, and enables data translation, for example reading from one Hypervisor and writing to
another.
The final component of a MediaAgent are the functions that it can perform as directed by
workflow, plan, or administrator action. Three primary functions that are performed by a
MediaAgent are backup, restore, and data replication through several methods and mechanisms.
MediaAgent Placement Considerations
Notes:
MediaAgent placement is key to delivering a successful solution and is answered very easily by
asking a single question. Where are we writing data to?
There’s a bit more to it when we factor in scale, resiliency, and security, but in its simplest form,
anywhere you need to write a local copy of data, will require at least one MediaAgent.
In this example our same customer that we’ve profiled back in an earlier module, would require at
least one MediaAgent in their Active, production data center, located in Chicago for local backup
copies. There would be another in the DR (disaster recovery) site, over in San Jose where we have
a DR CommServe® standing by alongside an always-on MediaAgent, to receive the additional copy
of data.
Finally, the small remote site in Santa Clara, also requires a local copy of data residing in this office
for recovery purposes, so we place at least one MediaAgent there too to then pass it along to the
active data center for redundancy purposes.
This is just a typical configuration when customers want to keep their data on premises, but what if
your customer wants to pursue a more forward-thinking solution, like public cloud?
Public Cloud MediaAgent Considerations
Public Cloud MediaAgent Considerations

Region 1 Region 2
Chicago San Jose
Customer Tenant Customer Tenant
"Cloud Storage
Managed Accelerator Installed
IaaS SQL PaaS SQL CA Managed
Control Plane CS CC
VMs individually on hosts to
write direct to blob/MRR" Media VMs
IaaS SQL PaaS SQL
Agent
Auto scale Access Cloud CommServe®

Nodes
(VSA/MA – Virtual
1x + Media
Server Agents)
Agents
VSA Access Nodes
AN Backup
Chunks MA for Restore into
Customer Tenant
1x + (add more for Scale)
Customer Tenant AirGap Metallic Recovery

Data Plane Dedupe Media Agents Reserve™
(Data Managers)
Standard_D8s_v3 Commvault DASH
Copy MRR
DM
(Deduped
Incremental
(LRS Hot) SaaS Airgap
forever copy)
1x + Media Agent (LRS Cool)
Azure Blob CV MRR

(Dedupe Media Agents(s) in
Azure with auto Power Mgmt.
(Add more MAs for redundancy

& Scale)
Notes:
Building your data plane in the cloud is possible with Commvault® with availability for even the
CommServe® to be built into the cloud as well. Bad design here can lead to significant egress costs
that could outweigh the benefits of performing operations in the cloud. Let’s look at an optimal
design for a customer using Azure.
Let’s say that in our prior example both, Chicago and San Jose are kept in separate regions in
Azure’s cloud. Chicago’s data to be backed up is all squared away in its respective region while San
Jose is also in its own respective region. Data may be commonly segregated this way to maximize
their own operations.
With Chicago being the main production center of our customer’s operations, the CommServe® will
be located in that region along with a lightweight software package, cloud controller, more on that
in a bit.
Access nodes are used to read the data in question, and as such, are deployed as virtual machines
within Azure which can be scaled automatically using Commvault® technologies to meet the
demand as it happens. With Commvault’s intelligent data services, assessments of your defined
recovery point objective and throughput averages, are automatically calculated to determine how
many more access nodes may need to be deployed through Commvault’s auto scaling features.
MediaAgents are also located within the region to act as the data movers and hosts of the
deduplication databases that will help on data savings. High performing disks are provisioned here
to manage deduplication related operations.
One last piece of the puzzle is a cloud accelerator that will help expedite data transfer to storage by
having each of the clients write directly to Azure storage, helping to reduce traversal costs
normally associated with cloud.
In this configuration, egress charges are minimized whenever data protection operations occur.
With the use of the deduplication databases held on the respective MediaAgents, only metadata
signatures are sent to the MediaAgent to perform hash comparison which determines when to
write unique blocks of data to an available Azure Blob through the cloud storage accelerator
deployed on the clients being protected.
As the needs of the environment scale and access nodes are deployed automatically to meet the
necessary demand, the cloud controller will handle all of the necessary power management to
avoid the costs that come with running persistent compute. The cloud storage accelerator removes
the need for data to land on the MediaAgent to write to storage by allowing each of the individual
clients, write directly to the Azure Blob.
San Jose will act as a catch all for data to be copied over from Chicago. Using deduplicated auxiliary
copy, otherwise know as DASH copies, data transfer will thin out as the data is deduplicated over
time further minimizing bandwidth related costs. By storing the data in longer term storage, like
Metallic Recovery Reserve, a fully air gapped solution can be achieved with a design like this.
Public cloud configurations yield multiple opportunities for businesses to leverage the benefits of
cloud computing’s on demand resources and global accessibility for their data protection needs.
MediaAgent Sizing
MediaAgent
Sizing
Notes:
Now that we talked about placement options lets move on to MediaAgent sizing.
MediaAgent Design Methodology
MediaAgent Design
Methodology Solution Requirements
Considerations:
 How many MediaAgents are required? File

Database
Site Total BET System VMs
 What size? Data
Data
Chicago ~300 TBs 10 TBs 200 TBs 500

1. Number of sites where we are writing a
local copy of data
2. Profile of source data to ingest in each site
• How much data (FET)
INGEST STORE
• Data profile (type, change rate %, MA
growth rate %) Front End (FE) TB Back End (BE) TB
3. How much data (BET) do we need to store

(retain) in each site?
• Retention
• Replication retention
Notes:
There are two basic but important considerations when designing MediaAgents…. How many are
needed and what size should they be?
You should start by identifying all of the sites where a local copy of data needs to be written. You
should have a good idea on this from the solution discovery phase already.
Next, factor in the amount of front-end terabytes and the profile of that data, which will be
ingested in each site. You can use the information gained from the data profiling exercise for this
step. These figures are not a sizing metric of the MediaAgents themselves but are used in the next
step.
Step three, calculate the back-end terabytes to be stored to meet the retention and replication
retention requirements for each site.
Four, match the back-end terabytes to the appropriate MediaAgent grid or grids, in order to meet
the solution requirements.
Customers are likely to refine different criteria and requirements along the way. You should always
avoid situations where this aspect of a solution is under-sized, which will inevitably cause problems
later on. For example, having one too many deduplication databases on a single MediaAgent, could
cause performance bottlenecks across the board. Conversely, over-sizing a solution at this stage
could exclude you from a deal entirely. Your end goal here is to balance your design with a number
of correctly sized MediaAgents and storage to satisfy all requirements of the solution while
providing room for scalable growth. Remember that design architectures tend to evolve over time,
and you will likely have to factor in customer demands such as future growth, budget constraints,
or allegiance to a particular hardware vendor.
Hardware Specs for Deduplication Mode MediaAgents
Notes:
Commvault® provides a detailed specification guide for MediaAgents using Deduplication mode,
which can be found on the Commvault® documentation website. The specifications themselves are
categorised into various sizes that make it easy to select the correct MediaAgents to support the
requirements of your design.
Details about non-deduplicated environments can *also* be found on our documentation site.
Each option provides a specific number of identically sized nodes, from as few as 1 or as many as 4,
in a grid. Each grid equates to a back-end terabyte figure, up-to a specific threshold i.e., the amount
of actual data it can store on the back-end disk library with some different recommendations for
cloud-based libraries.
The provided grid sizing automatically factors in the use of deduplication partitioned mode where
required for scale.
This single back-end metric makes sizing the MediaAgent grid a simple process.
Please keep in mind that the suggested workloads are not software limitations but rather design
guidelines for sizing under specific conditions.
For MediaAgent's that are deployed as a cloud or virtual instance remember to follow both virtual
compute and memory recommendations and ensure that resources are guaranteed.
Please read the Commvault® documentation carefully, as there are other important guidance notes
provided. Also, the sizing metrics are updated from time to time, for example following product
feature releases.
Commvault Solution Design Tool
Notes:
MediaAgent sizing is able to be completed with the help of the Commvault® Solution Design tool.
The discovery tool is created specifically to help any Commvault® employee or partner to scope a
solution properly. Workload information collected from your data profiling sessions with your
customer can be entered here. The tool will then provide a breakdown of the kind of resources
that are going to be required for the environment, along with projecting the future needs that
same environment may require down the road. Be sure to use the tool to easily build, see, and
share designs to deliver a complete proposal to your customer.
Availability and Anatomy
Availability
and
Anatomy
Notes:
Understanding the make up and functionality of certain MediaAgent related procedures, will help
guide you in design.
MediaAgent Anatomy
MediaAgent Anatomy
MA
OR
C:\ D:\IndexCache E:\globalddb G:\mountpath\disklib1 \\cifsserver\diskshare
RAID SET 2 RAID SET 3 SAN RAID SET 5

RAID SET 1
DISK
LIBRARY
https://documentation.commvault.com/
Notes:
This slide describes the best practices for physical disk and logical drive layouts when planning your
MediaAgent deployments on Windows. We have chosen Windows as it is the most common
MediaAgent deployment, but the Commvault® MediaAgent software is supported on many other
varieties of Operating systems. Please refer to the Commvault® documentation website to check
supported OS types and versions.
The Windows Operating system and Commvault® installation binaries should be installed on the
C:\ and placed on a RAID disk set configured on fast disk. Some additional disk space is required for
temporary files copied during the installation or upgrade and for log file growth. The MediaAgent
binaries may be installed on a separate disk set if you wish but this is not essential.
Whenever installing or reconfiguring a MediaAgent, verify that the volume hosting the Index Cache
Directory has sufficient disk space and performance as per documented requirements. Our general
recommendation is to use SSD, if possible, especially for larger environments. This cannot be
located on network storage under any circumstances.
For optimal performance the Deduplication Database needs to be on fast, dedicated disk. This will
have the most significant impact on the performance of a MediaAgent so be sure to check the disk
is capable of the IOPS documented for the size of building block you are designing.
Finally the Disk Library can be designed using either Direct or SAN Attached Block Storage or
Network Attached Storage (NAS). Commvault® provides added flexibility here as the customer does
not need expensive SAN or NAS storage for the disk library, they can shop for lower-cost, high-
capacity storage from any number of vendors, this can also be a real selling point as customers do
not feel tied in to a particular hardware vendor.
Availability Considerations
Notes:
Remember MediaAgents are the primary data handler between servers and storage targets. In
order to determine the level of availability required in the design, you should refer to the SLAs
required for the backup system captured during the solution discovery phase.
An important differentiator for Commvault® is that the Deduplication database is only required to
perform backups. When a recovery is performed the index is identified within the CommServe®
database, the index is accessed, the storage location identified and the restore is performed. This
underlying architecture also means that a MediaAgent can be easily recovered in the event of a
disaster. Additionally, both the index cache and deduplication databases themselves are
automatically protected and recovered if unavailable.
To provide a higher level of availability for MediaAgents that use deduplication, you should always
design with 2, 3, or 4 nodes in a grid, using partitioned deduplication. Partitioned deduplication
distributes the DDB across these multiple MediaAgent nodes. This provides partition failover by
automatically redirecting the deduplication process if one partition is temporarily unavailable.
MediaAgents also utilize GridStor® technology to provide automatic path failover should a
MediaAgent or storage target become inaccessible.
This leads us on to the availability of the storage targets and the resident data itself. Resiliency may
be built into the underlying storage targets themselves, however in the case of disk-based storage
targets, it is worth noting the difference between Direct Attached Block Storage and NAS. With
Direct Attached Block Storage, the mount paths are locally attached to the MediaAgent. If a
MediaAgent goes offline, then so does the storage target. With NAS storage, if a MediaAgent goes
offline, the disk storage is still accessible through other MediaAgents.
The Commvault® index spans intelligently across multiple plans. If, when a restore is initiated the
appropriate media is not available then the software automatically identifies the media in which the
data resides and performs the restore from that storage target.
Finally, when you are having availability-type discussions, keep in mind Commvault HyperScale™
technology. HyperScale™ was designed specifically to provide improved resiliency of the
MediaAgent and Storage components, with lower-costs and simplified management compared to
traditional compute and storage architectures.
Replication of Deduplicated Data
Replication of
Deduplicated Data
DASH Copy
WAN
• Enables transmission of data in
deduplicated, reduced form between
MediaAgents
MA A
B B
C D
C D
E MA
BCD
• Reduction in bandwidth consumption
Hash References
Only Initial
New Operation
Recorded
Blocks in DDB
Transferred
facilitates disaster recovery
• Eliminates need for vendor-specific array

replication for DR
https://documentation.commvault.com/
Notes:
Next, a quick refresher on a couple of other Commvault® deduplication features that are likely to
influence your design. Let’s start with DASH Copy.
DASH copy is a technology that enables the transmission of data in its deduplicated, reduced form
factor between media agents. This includes the capability to recover data and maintain different
retention periods, independently from the primary copy.
This reduction in bandwidth consumption facilitates disaster recovery and eliminates the need for
vendor specific appliances or third-party replication technologies for disaster recovery purposes.
When sizing a solution that utilizes DASH copy, the primary copy of data and any additional copies
should be sized independently. This also includes DASH copy configurations using cross-site
replication. A DDB is also required on the destination MediaAgent for dedupe signature
comparison.
Again, please refer to documentation.commvault.com for the latest hardware specifications for
deduplication mode.
Synthetic and DASH Full Backups
Synthetic and DASH Full backups

Synthetic Full Operation
Most current version of objects
Updated “baseline” full created
present at last backup identified
• Consolidates backups without placing
load on the client
• DASH full only updates index and
dedupe records = faster due to less
I/O Incremental from
client before or after
• Consolidates Backups - does not Synthetic Full
protect data independently
• Recommended for space
management and compliance
• Useful for tape-out operations
• Follow documented recommendations
for scheduling Full
Incremental
Incremental
Incremental
Incremental
MA
Notes:
We will now discuss Synthetic and DASH full backups and some best practices on using them.
Synthetic full backups consolidate the data from the latest full backup or synthetic full backup
together with any subsequent incremental backups, instead of reading and backing up data directly
from the client computer. Since synthetic full backups do not back up data from the client computer,
this operation imposes no load on the client computer.
With deduplicated data, a synthetic full by default utilizes a faster variation of a synthetic full called
DASH full where only the deduplication and index records are updated, without the need to read
each block and generate a signature. Since the associated disk I/O is reduced significantly, a DASH
full results in much faster completion compared to a regular synthetic full.
A common misconception is that synthetic fulls are a new backup, in fact the actual data protection
is done by the latest incremental. The synthetic full itself is used to consolidate these previous
backups for space reclamation via the data aging process.
It is important to note that synthetic fulls have little or no impact on restore performance on disk or
cloud storage targets. Commvault’s single pass recovery process creates a recovery point image,
which represents the context of the whole data set at that time. Often you will hear customers
state that they require a full backup once per week, a typical hangover from their usage of legacy
products and methodologies. With Commvault® they really get that outcome every day in the
recovery point and that is thanks to smart indexing. The single pass recovery is still applicable with
tape media, however job-based restores from tape media can still benefit from full or synthetic full
backups as these jobs consolidate data on the tape media. This consolidation can reduce the load
and seek time and improve read efficiency.
You should refer to the documented recommendations on scheduling synthetic full backups. It is
strongly recommended that they are not run excessively, especially with deduplicated data as this
can lead to unnecessary load on the deduplication database.
Wrap Up
Wrap Up
• MA components and their placement considerations
• MA sizing guidance and tool assistance
• Availability and anatomy considerations
• Quick refresher on Commvault® deduplication features
• Best practices of Synthetic and DASH full backups
Notes:
In the span of this module, we’ve covered:

1) The pieces that make up a MediaAgent along with a couple of placement examples that can
mitigate common factors in designs.
2) Properly sizing MediaAgents and the Commvault® Solution Discovery tool that can be used to aid
in designing an environment.
3) The anatomy of a common MediaAgent along with availability considerations on how recovery
works when losing key MediaAgent items like a deduplication database and index cache.
And lastly, a quick refresher on deduplication and how it works with DASH copies while also
highlighting the key differences between synthetic full operations and DASH full operations.
Thank You
Copyright © 2022 Commvault | All Rights Reserved 17

MediaAgent Design Downloadable Resource

Uploaded by

Copyright:

Available Formats

MediaAgent Design Downloadable Resource

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MediaAgent Design Downloadable Resource

Uploaded by

Copyright:

Available Formats

COMMVAULT PROPRIETARY AND CONFIDENTIAL INFORMATION- INTERNAL AND PARTNER UNDER NDA USE ONLY- DO NOT DISTRIBUTE

MediaAgent Design Fundamentals

MediaAgent Design Fundamentals

Copyright © 2022 Commvault | All Rights Reserved

Welcome to the “MediaAgent Design Fundamentals” module, presented by Commvault.

MediaAgent Design Fundamentals

MediaAgent placement considerations and

MediaAgent sizing and hardware specifications

MediaAgent availability and anatomy

Architect optimal MediaAgent Server placement

Components and Placements

MediaAgent Placement Considerations

Public Cloud MediaAgent Considerations

Public Cloud MediaAgent Considerations

Auto scale Access Cloud CommServe®

Customer Tenant AirGap Metallic Recovery

Azure Blob CV MRR

(Add more MAs for redundancy

MediaAgent Design Methodology

 How many MediaAgents are required? File

Chicago ~300 TBs 10 TBs 200 TBs 500

3. How much data (BET) do we need to store

Hardware Specs for Deduplication Mode MediaAgents

Commvault Solution Design Tool

Availability and Anatomy

C:\ D:\IndexCache E:\globalddb G:\mountpath\disklib1 \\cifsserver\diskshare

RAID SET 2 RAID SET 3 SAN RAID SET 5

Replication of Deduplicated Data

• Eliminates need for vendor-specific array

Synthetic and DASH Full Backups

Synthetic and DASH Full backups

• MA components and their placement considerations

• MA sizing guidance and tool assistance

• Availability and anatomy considerations

• Quick refresher on Commvault® deduplication features

• Best practices of Synthetic and DASH full backups

In the span of this module, we’ve covered:

Copyright © 2022 Commvault | All Rights Reserved 17

You might also like