CommServe Design Fundamentals

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

COMMVAULT PROPRIETARY/CONFIDENTIAL – FOR COMMVAULT PARTNERS UNDER NDA USE – NOT TO BE FURTHER DISTRIBUTED
CommServe Design Fundamentals
CommServe®
Design
Fundamentals
FOR SALES ENGINEERS
Presented by
COMMVAULT
Notes:
Welcome to the “CommServe Design Fundamentals” learning module.

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
Learning Goals
01 Optimally Architect CommServe Server Positioning
02 CommServe Server Deployment Specifications
03 CommServe Considerations for HA and DR
04 Global Command Center (GCC)
05 Sizing Methodologies and Planning
Notes:
In this module you will learn:
The design fundamentals and specifications of the CommServe Server component and apply
knowledge learned from the solution discovery phase for optimally placing CommServe server in
environment.
You will understand the options and considerations in planning for CommServe high availability and
disaster recovery. You will then learn about monitoring multiple CommCell® environments using a
Global Command Center. Finally, you will learn specific sizing methodologies and planning for the
CommServe deployment.
CommServe Placement Considerations
CommServe® Placement Considerations
CommServe Positioning:
• Production CommServe in production
On-prem Multi-cloud Hybrid-cloud
Apps
data center
Data Center VMs Files DBs Mail
and • DR CommServe in DR site
Workloads
Pros:
• WAN availability is not necessary for
Production Site DR Site
production backups
Control Plane
Control Plane
WAN
Prod CommServe DR CommServe
Notes:
When determining CommServe placement in an environment, there are two key components to
consider.
The first is the production CommServe and the second is the DR CommServe.
The DR CommServe is prepared with the CommServe package to recover from a CommCell disaster.
We will discuss CommServe’ s high availability and disaster recovery in further detail later in this
module.
But for the time being, as seen in here, the production CommServe is placed in the primary
production datacenter and the DR CommServe is placed in the DR site. The biggest benefit of this
method is that it allows backup and recovery operations to continue normally in the event of a WAN
disruption.
This is a common approach to deploy CommServe in customer’s environment, but we will also cover
a few of the other possibilities next.
CommServe Positioning:
• Production CommServe in DR Site and
DR CommServe in Production Site
Apps VMs Files DBs
Data Center Mail
and
Workloads Pros:
• In a DR situation, no CS recovery or
failover required
Control Plane
Control Plane Cons:
• Poor WAN availability causes failure or
WAN
delay of backups/recoveries
DR CommServe Prod CommServe
DR CommServe & Prod CommServe switched*
Notes:
The production CommServe® could be placed in the DR site having less operational capacity than
the production site and the DR CommServe could be put in the production site.
In this situation, Commcell disaster at the production site would not impact the production
CommServe and it would not need to be recovered or failed over.
However, it is important to understand that WAN availability is a critical factor in the success of such
a deployment. Remember that if the WAN link goes down, jobs do not run and although the
CommServe is not directly user facing, it is required to be online for users to recover their data and
perform other tasks such as searches or recalls.
CommServe Positioning: Cons:

• Single Active CommServe in Production data center • DR process requires hardware acquisition after the
disaster
Pros:
• Usually requires off sited DR backups
• Less hardware
• Significantly longer CommServe recovery process
• Less Expensive

Apps VMs Files DBs Mail
Control Plane DR Backups
WAN
Prod CommServe DR CommServe
Notes:
It may sound odd, but in some situations, it may not be possible to have a standby CommServe,
dedicated equipment and connectivity at DR site.
Although it is now becoming increasingly less common, some customers still maintain traditional DR
contracts, whereby the provider arrives at their location in a truck and the systems are all built from
scratch on hardware that is provided at the time.
In this case, the production data center only has a single production CommServer server, with no
standby in DR site. Some customers just prefer to go with a more economical path that requires
fewer pieces of hardware equipment.
This is where an engineer needs to express concern about this architecture. It is certainly less
expensive, but the DR process will take significantly longer to achieve, especially considering the
scarcity of hardware in a regional disaster scenario.
Also, unless the DR backups are exported offsite, such a disaster would result in a no recovery
scenario.
The use of a single production CommServe is possible, but it is not an approach that is
recommended.
CommServe Positioning for Multiple Sites:

Data Center & Apps VMs Files DBs Mail
• Production CommServe based on Client
Workloads
Count
Production Site A Production Site B

Pros
Control Plane Control Plane
• Minimizes WAN traffic by reducing
connections
Prod CommServe WAN DR CommServe • Less backups delayed when WAN link fails
Local Copy Local Copy Cons

• Client count not necessarily indicative of
importance
Data Plane
Secondary Secondary
Copy Copy
Notes:
In some situations, there is not a defined DR site. Take an active-active example, with two
production datacenters, which perform local backups and secondary copies to the opposing
location. This architecture involves a trade-off between speed of DR and impact of operations.
One way we could determine where to place the CommServe® would be by client count. To impact
the least number of clients, the CommServe would be placed in the data center with the higher
client count. However, the client count doesn’t indicate the importance of the data. Perhaps a
more qualitative analysis is needed.
Maybe there are DR considerations to consider. Perhaps production site B has less IT staff with less
knowledge or access to the backup system. To simplify the DR plan, we could place the production
CommServe in that location.
Again, in this design scenario, understanding the pros and cons of CommServe placement will help
you align the proper design to your customer’s goals.
CommServe Positioning: Pros:

• In the cloud infrastructure • Less likely for need of failover
• Improved flexibility and agility
Cons:
• Distance and dependency between the data
center and the cloud must be considered
On Prem Data Center
Region A Region B
High
Availability
Notes:
Another popular choice is placing the CommServe® in the cloud. For customers who are adopting
either an all-out cloud strategy or who are migrating and running a large proportion of workloads in
the cloud, this may potentially be a good option.
It would almost certainly mean there is less likelihood of the need to failover due to the inherent
resiliency of public cloud infrastructures that help you achieve high availability for cloud workloads,
across compute, databases, and storage services. It would also provide improved flexibility and
agility; for example, if the customer wanted to perform testing, upgrades, or migrations of the
CommServe.
On the downside if the customer still has a physical footprint on-prem then there would be distance
and dependency factors between the datacenter and the cloud to consider. Remember if
communication is lost to the CommServe then jobs would fail to run.
Leverage Industry-ready
Command Center to Secure
On-premises & Cloud
Workloads
https://documentation.commvault.com/
Notes:
No matter what kind of CommServe design you choose—on-premises, in the cloud, or hybrid – it is
easy and simple to set up Command Center to protect a wide range of different workloads.
Command Center is industry ready, and can support several cloud apps, databases, and object
storage repositories on all major cloud platforms.
For the most up-to-date information on supported cloud or on-premises workloads, though, please
refer to CommVault documentation site.
CommServe Deployment Considerations
Physical, or Virtual?
• Virtual CommServe Server can provide increased flexibility and lower costs (if no additional hardware is required)
• Supports Linux and Windows operating systems
• Hardware specifications for Virtual CommServe server must be the same as physical
• VM requires dedicated resources
Physical and Virtual CommServe Server
MEMORY
PROCESSOR
MEMORY
PROCESSOR
Notes:
A virtualized CommServe server can be a good option for many organizations as it generally
provides greater flexibility, higher availability, and reduced costs (since separate CommServe
hardware is not required). CommServe servers that are installed on physical or virtual machines are
supported by both Windows and Linux operating systems, please refer to the Commvault
documentation website to check system requirements. Deployment of the CommServe Server on a
virtual machine must meet the same hardware specifications as a physical server, such as CPU &
RAM, and with dedicated resources for the VM. If the virtual environment is not properly scaled,
the CommServe server could become a bottleneck when conducting data protection jobs.
Stand Alone, or Clustered?

• Stand Alone deployments are most common
• Clustered configuration provides high-availability
• Good for large environments where 24/7 availability is critical
Stand Alone CommServe Clustered CommServe
Active Node Active Node

Passive Node
Active Node
Notes:
Another consideration is whether the CommServe® should be Stand Alone, or Clustered.

The most common stand-alone deployments use a single Production CommServer.
Clustering provides high availability of the CommServe. In a clustered configuration multiple
compute nodes work together as a single entity, if a failure occurs on one node in a cluster,
resources are redirected and the workload is redistributed to another compute node in the cluster,
this ensures constant access to the CommServe in the event of a local system failure.
Clustering the CommServe does increase the cost and complexity of an overall solution, however it
can make sense in certain enterprise environments where automation and availability are critical.
Clustering relies on Microsoft Clustering technology or a supported third-party software solution,
please refer to the Commvault® documentation website to check support and compatibility.

SQL Database
• SQL 2019 Standard Edition automatically installed during CommServe Software installation
• Microsoft SQL Server Database should be dedicated (not shared) with other applications
• Configure Existing SQL Instance or manually Install SQL Server Database
• Consult http://documentation.commvault.com for current list of supported SQL server versions / editions
Clustered
• You must install the CommServe software on the active node first, and then on the passive nodes of the cluster
Other Databases
• MongoDB Installed as Default or Standalone
• MongoDB provide performance improvements for some list-based pages on the Command Center
SQL DB
Notes:
The Commvault software uses Microsoft SQL Server as its database engine. By default, Commvault
installs Microsoft SQL Server 2019 Standard Edition during the installation of the CommServe
software for both Windows and Linux, which is covered under Microsoft’s independent software
vendor Royalty Licensing Program. The Microsoft SQL Server database that is installed on the
CommServe computer must be used exclusively by the Commvault Application and cannot be
shared with other applications. Depending on their individual environment requirements,
organizations can also optionally configure an existing SQL Instance or manually install SQL Server
before installing Commvault server packages. Please consult Commvault documentation for a
current list of supported SQL server versions and editions for use with the CommServe database.
For clustered deployments, you install the CommServe software on the active node first, and then
on the passive nodes of the cluster.
MongoDB is installed as a default package when the CommServe, Webserver, or WebserverLite
packages are installed. Alternatively, you can install MongoDB as a standalone package. Commvault
software uses the MongoDB database engine to provide performance improvements for some list-
based pages on the Command Center. Since MongoDB database engine handles some of
Commvault software's operations, therefore it is very much possible to see MongoDB expand on its
role to offload additional operation.
CommServe Disaster Recovery Options
CommServe® Disaster Recovery Options
Manual DR Backups
CommServe LiveSync
Microsoft SQL database mirroring is not recommended*
Notes:
CommServe placement should be favorable to disaster recovery situations.
There are commonly two types of CommServe disaster recovery solutions that can be implemented
based on the Recovery Point Objectives and Recovery Time objectives of the customer.
The first is Manual DR with DR backups and Restore.
Next, is CommServe LiveSync for High Availability Disaster Recovery
We will discuss each of them shortly.
SQL database mirroring feature has been deprecated by Microsoft and may not be available in
future versions of Microsoft SQL Server to protect customers CommServe databases. Because of
this, it is recommended that you build customer’s CommServe Disaster Recovery solution using the
CommServe Live Sync method.
Recovery Using Disaster Recovery (DR)

Manual DR via DR Backup/Restore Backups
• Daily Schedule DR backups
Network Share Local Drive • Use DR backups to Recover
• Default CS protection methodology
Prod
Staging directory • Longest Recovery Time
CommServe
• Configuration can be customized based on
Cloud storage library Metallic Cloud RPO/RTO
Export Destination
Microsoft SQL database

mirroring method is not
recommended
Backup Phase
Notes:
The first DR option is to recover the CommServe by utilizing the default Disaster Recovery backups.
In this method all the necessary data required for DR is automatically backed up at least once per
day. In the event of an actual disaster, you can use the DR backups to recover the CommServe
database onto the same or to DR CommServe server to minimize the recovery time
The process of a CommServe DR backup is as follows:
First an export process copies a metadata backup of the CommServe database to the default staging
directory and then exported to the specified export destination.
You can specify a local path or a network path as an export destination. Ideally, these export
destinations have metadata of CommServe database and should be located away from the
Production CommServe.
Additionally, Commvault supports export destinations like Metallic Cloud or Third-party Cloud
storage to store copy of DR backups automatically. Metallic cloud uses Azure to store a copy of DR
backup metadata. To configure DR backup uploads to the Metallic Cloud, you will need a working
Commvault Cloud Services Portal account. This service stores 5 DR backup copies by default, which
includes the latest five full’s taken on each day, along with the latest Differential copy, if any, and is
retained in the cloud for 90 days. This ensures that a recent copy of the database is offsite and
cannot be accessed by a rogue process such as a ransomware attack.
Finally in backup phase the DR Metadata is backed up to a storage policy location, where it can be
retrieved if the export copy does not exist. All processes, schedules, and export/backup location are
customizable to meet the customer’s recovery point and time objectives.

Prod Site DR Site ComServe LiveSync For High Availability

Disaster Recovery
Apps VMs Files DBs Mail
• Synchronizes CommServe metadata
Client Request (databases) across one-to-many offline
nodes
• Lower Recovery Point and Recovery Time
• One-click failover mechanism
Failover
ON • Does not rely on DNS or other network
related services
Notes:
The second DR option is The High Availability CommServe Host (also referred to as CommServe
LiveSync feature.)
This feature keeps the CommServe server ready for disaster recovery and provides the ability to
quickly failover to a designated standby host (or hosts) in the event of a disaster. Hyperscale X
appliances with CommServe installed can also be utilized as failover hosts if the customer's
environment has them.
When a failover is performed, a designated proxy client routes the requests to the standby
CommServe host so that the clients can seamlessly connect and continue operations with the
CommServe host.
This solution provides organizations with a lower recovery point and recovery time for disaster
recovery of the CommServe, when compared to using DR backups. The solution also features a
“one-click” failover mechanism that automates the multi-step recovery process, preventing human
error and speeding up recovery.
You can easily perform failover of the Production CommServe to a Standby CommServe, in both
planned and unplanned failover situations.
Additionally, you can perform maintenance failovers, for example to install service packs on the
production CommServe host, and then simply failback to production once the maintenance has
been completed.
Finally, a test failover ensures that the failover process is successful. Test failovers also ensure
successful restore operations after a production and or maintenance failover.
Global Command Center
Global Command Center

Primary CommCell
Command Center
Client Media Agent
CommCell 1
Service CommCell Service CommCell

Command Center Command Center
Client Media Agent Client Media Agent
CommCell 2 CommCell 3
Notes:
For solutions that consist of multiple discrete CommCell® environments, it might be worth
considering a global command center feature.
You can make any CommCell environment a Global Command Center and associate other CommCell
environments as a service CommCell environment.
The CommCell environments that are monitored by the primary commcell command center are
known as service commcell.
The Global Command Center feature provides seamless switching between different
service CommCell Command Center views and manages aggregated data across multiple
service CommCell environments.
For guidance on how to configure primary commcell and associate different service commcell
environment please refer to Commvault Documentation Website under global command center.
CommServe Planning
Notes:
This slide describes best practices for physical disk and logical drive layouts when planning your
CommServe® deployments on either physical or virtual machines.
The Microsoft Windows Operating system and Commvault® installation binaries should be installed
on the C:\ drive and placed on a RAID disk set configured to fast spinning or for larger
environments, solid state drives. Some additional disk space is required for temporary files copied
during the installation or upgrade of the CommServe and Microsoft SQL server software. The
CommServe binaries may be installed on a separate disk set if you wish but this is not essential.
The CommServe database running on Microsoft SQL should also be placed on a dedicated RAID disk
set configured on fast spinning disk, solid state disks, or enterprise class SSD, depending on the
hardware specifications for the environment.
On machines running Linux, the Commvault application binaries should be installed in ( /opt ) path
that is different from the path used by the Linux operating system. The Commvault database will be
installed by default under the path (/opt/commvaultDB), which can be customized during the
installation process.
For guidance on the latest disk sizes and recommend RAID configuration please refer to the
CommServe size and performance requirements on the Commvault Documentation Website under
Hardware specifications.
CommServe Hardware Specifications
CommServe® Hardware Specifications

Small Medium Large Extra Large
Supports up to 25 Supports up to 500 Supports up to 2500 Supports up to 10,000
servers, or 100 virtual servers, or 1000 virtual servers, or 5000 virtual servers, or 20,000 virtual
machines, or 200 laptops machines, or 5000 machines, or 10,000 machines, or 50,000
in a single CommCell, laptops in a single laptops in a single laptops in a single
including Hardware CommCell environment. CommCell environment. CommCell environment.
Specifications for
Deduplication Mode.
4 CPU cores 8 CPU cores 12 CPU cores 16 CPU cores
24 GB RAM 32 GB RAM 64 GB RAM 128 GB RAM
100 GB of disk space for 200 GB of disk space for 300 GB of SSD disk 500 GB of enterprise
CommServe database CommServe database space for CommServe class SSD disk space for
database CommServe database
Additional Disk Space for Large and Extra-Large Environments

In large and extra-large environments, use a separate 100 GB SSD disk space for
the following:
• OS https://documentation.commvault.com/
• CV Application (binaries)
• TempDb drive
• Software cache and log files
Notes:
Commvault® provides a detailed Hardware specification guide to help you determine the correct
hardware to run the CommServe® that meets the scale of CommCell® you are designing.
Hardware and software Specifications can change from time to time with new releases of the
software, therefore it is recommended to ALWAYS refer to the Commvault documentation website
for the latest specifications, these can be found at documentation.commvault.com.
CommServe Solution Design Tool
Notes:
In support of appropriately sizing opportunities, the Commvault Solution Design tool has been
created.
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.
Wrap-up
Wrap-up
• Architect Optimal CommServe® Server Placement
• Specifications for Deployment of the CommServe Server Component
• CommServe Considerations for HA and DR
• Global Command Center (GCC)
• Sizing Methodologies and Planning
Notes:
In this module you learned about the design fundamentals of the CommServe Server component
and how to apply certain knowledge learned from the solution discovery phase.
You also learned about options and considerations in planning for CommServe high availability and
disaster recovery and then about monitoring multiple CommCells using a Global Command Center.
Finally, we covered specific sizing methodologies and planning for the CommServe deployment.
Thank You
20

CommServe Design Fundamentals

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

CommServe Design Fundamentals

Uploaded by

Copyright:

Available Formats

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

CommServe Design Fundamentals

CommServe Design Fundamentals

Welcome to the “CommServe Design Fundamentals” learning module.

01 Optimally Architect CommServe Server Positioning

02 CommServe Server Deployment Specifications

03 CommServe Considerations for HA and DR

04 Global Command Center (GCC)

05 Sizing Methodologies and Planning

CommServe Placement Considerations

CommServe® Placement Considerations

Prod CommServe DR CommServe

CommServe Placement Considerations

CommServe® Placement Considerations

DR CommServe & Prod CommServe switched*

CommServe Placement Considerations

CommServe® Placement Considerations

CommServe Positioning: Cons:

Production Site DR Site

Control Plane DR Backups

CommServe Placement Considerations

CommServe® Placement Considerations

CommServe Positioning for Multiple Sites:

Production Site A Production Site B

Local Copy Local Copy Cons

CommServe Placement Considerations

CommServe® Placement Considerations

CommServe Positioning: Pros:

CommServe Placement Considerations

CommServe® Placement Considerations

CommServe Deployment Considerations

CommServe Deployment Considerations

Physical and Virtual CommServe Server

CommServe Deployment Considerations

CommServe Deployment Considerations

Stand Alone, or Clustered?

Stand Alone CommServe Clustered CommServe

Active Node Active Node

Another consideration is whether the CommServe® should be Stand Alone, or Clustered.

CommServe Deployment Considerations

CommServe Deployment Considerations

CommServe Disaster Recovery Options

CommServe® Disaster Recovery Options

Microsoft SQL database mirroring is not recommended*

CommServe Disaster Recovery Options

CommServe® Disaster Recovery Options

Recovery Using Disaster Recovery (DR)

Microsoft SQL database

CommServe Disaster Recovery Options

CommServe® Disaster Recovery Options

Prod Site DR Site ComServe LiveSync For High Availability

Global Command Center

Global Command Center

Client Media Agent

Service CommCell Service CommCell

Client Media Agent Client Media Agent

CommServe Hardware Specifications

CommServe® Hardware Specifications

Additional Disk Space for Large and Extra-Large Environments

CommServe Solution Design Tool

You might also like