The BaaS service is offered as a Platform as a Service (PaaS) offering with full management of the backend infrastructure. In this offering, the tenant is responsible for:
-
Application administration
-
Application data
The Service Provider is responsible for the remaining components, such as runtime applications, Middleware, O/S, virtualization layer, servers, storage, and networking.
The service is deployed in a shared responsibility model where the tenant must maintain a functioning application environment, and access to their data. The Service Provider) has responsibility for capturing that data, per SLA and storage on alternate storage infrastructure.
Compatibility
This service will have a number of key infrastructure components that must be catered for:
-
Dedicated physical or virtual compute is required for the Commvault application.
-
IPV4 and/or IPV6 network connectivity between all components will be required
-
Specialized network functions (firewalls, network address translation) must be provided by the network layer
-
A modular, resilient secondary storage technology is required for on-premises backup copies
-
A modular, offsite, on-demand tertiary storage technology is required for offsite backup, long-term retention and archive copies (Public cloud is an option here)
-
A floating Domain Name System (DNS) entry for the CommServe® will be required to provide Commvault Disaster Recovery services
-
Web components of Commvault infrastructure will require a local Certificate Authority (CA) to sign HTTPS certificates for secure client access.
Infrastructure
Commvault has a number of key components that must be deployed to deliver a secure, scalable, multi-tenanted data services platform.
Commvault advocates use of virtualization for all components. Deploy only the size required for { today + 12 months } and re-assess sizing quarterly to ensure Commvault best practices are still being maintained.
The following infrastructure guiding principles should be applied to your new services platform:
-
CommServe® must be deployed on a current generated MS Windows Server (System Requirements) with a minimum 25 server capable configuration of:
-
4 x CPU cores,
-
16GB RAM
-
100GB diskspace (database)
See Hardware Specifications for CommServe for additional sizes.
-
-
Media Agents are responsible for accepting, storing, and replication backup data. They must be deployed in GridStor® pairs to ensure uninterrupted operation. Commvault recommends:
-
One Media Agent installed on the CommServe for the ‘default’ server plan, which perform CommCell-based internal protection (DR backups, index backups)
-
One Media Agent Pair for in Deduplication Two Partitioned Extended Mode to provide deduplicated storage, backup service resiliency, and scale to receive backup copies from remote site. At minimum each server will require (at minimum):
-
12 x CPU cores
-
64GB RAM
-
400GB on Operating System disk (for Commvault software)
-
1.2TB SSD Class disk for the DeDuplication Database 1 (DDB)
-
1.2TB SSD Class disk for the DeDuplication Database 2 (DDB)
-
1TB SSD Class disk for the Index Cache disk
-
-
-
Disk Libraries are responsible for persisting backup copies. Commvault recommends selecting a resilient, secure, and modular storage technology. Available options include:
-
NFS accessible network attached storage
-
CIFS/SMB accessible network attached storage
-
Commvault HyperScaleTM scale-out software-defined storage
-
-
Virtual Server Agents (VSAs) provide native API integration into the protected Hypervisor, VMs and applications. You will require a virtual VSA per tenant. The VSA is a current generation Windows server with the following characteristics to protect up to 10TB of front-end data:
-
2 x vCPU cores
-
24GB RAM
See Hardware Specifications for Virtual Server Agent for scaling the VSA resources to protect more data.
-
There are a number of centralized management entitles deployed with a standard CommCell deployment, these components are recommended to be deployed on the CommServe:
-
Command Center self-service administration portal, System Requirements request:
-
2.5GB of local disk storage for software and log files
-
1GB of temp space
-
-
Metrics Reporting Server for ChargeBack and advanced reporting & trending, System Requirement request the following for a small configuration:
-
4 x CPU cores
-
16GB RAM
-
100GB disk space (database)
Metrics Reporting Server can be deployed separate to the CommServe, but this is not required until the number of client CommServe(s) exceeds ten (10).
-
Web Server for API-based access to Commvault infrastructure, System Requirements request the following for up to 400 concurrent users access the Command Center:
-
8 x CPU cores
-
16GB RAM
-
200GB of disk space for web cache
Web Server can be deployed separate to the CommServe, but this is not required until the number of concurrent users exceeds 1000.
Additionally, consider whether you will segregate components for preferential treatment to higher-value subscriptions. Segregating or dedicating infrastructure to a specific service-level is not required but can provide additional justification for customers to upgrade. Consider:
-
Sharing Media Agents and Disk Libraries for Essential & Standard services but delivering dedicated Media Agents / Disk Libraries for Premium subscribers.
-
Essential services could be deployed without Media Agent high-availability configurations to reduce cost.
-
Premium services with dedicated Media Agents and Disk Libraries are not affected by performance or availability issues affecting Essential/Standard subscribers
Scalability
Commvault can be scaled from protecting a mere 25 servers and 10TB of data to multi-PB configurations protecting 80K entities. Consider the following scaling recommendations:
-
Define alerts to alarm the number of protected servers, virtual machines, and desktop/laptops and scale your CommServe per Hardware Specifications for the CommServe Server
-
Define alerts to alarm the managed Back End TB (BETB) managed per Media Agent, and scale your Media Agent size from Large to Extra Large, per Number of Media Agents, Grid Backend Storage, and CPU/RAM
- Add another two (2) server grid when a Grid is exhausted.
-
Define (implement) the recommended Deduplication Alerts to ensure your DeDuplication Database (DDB) Query & Insert time stays within recommended thresholds. Q&I time degradation indicates that the IOPS of the DDB volumes are being exhausted.
-
Define alerts to alarm concurrent user connections exceeding the Web Server thresholds and look to vertically scale the Web Server (add CPU, RAM) or horizontally scale the Web Server behind a load-balancer.
For further information, consult the CommCell Scalability Guide
Availability
There are a number of components within a Commvault deployment that must be considered for availability. They are discussed below from most important to least important.
-
At a minimum, you must configure CommServe DR backups to be stored away from your CommServe.
-
Commvault can store up to seven (7) days of CommServe DR backups at cloud.commvault.com, see Configuring Automatic Uploads of DR Backups.
-
Commvault recommends that DR backups outside seven (7) days be stored in Public Cloud libraries for extended retention and low-cost storage – Configuring a Cloud Library as the Export Destination for Disaster Recovery Backups.
After you configure your CommServe database appropriately, you should consider the availability of each component in your CommCell.
-
CommServe® Disaster Recovery (failover, failback) can be provided by CommServe LiveSync to a remote/alternate site,
-
No additional licensing is required.
-
A physical/virtual server matching the Production CommServe is required
-
A floating CommServe DNS name is required to failover/failback
See Installing High Availability CommServe Host for details.
-
-
Media Agents deployed in GridStor® configurations will automatically direct backup activity to available resources.
-
Virtual Server Agents (VSA) should be deployed in proxy teams to balance workload across all available VSAs.
Security
Commvault as a data protection solution is inherently secure out-of-the-box. Commvault has the following built-in security controls:
-
All communications between clients and servers occur over mutually authenticated SSL (MA-SSL) connections.
-
Commvault manages certificate generation, revocation and renewal.
-
Certificates are stored within the Commvault database, which has been certified FIPS-140-2 compliance for sensitive key handling / encryption practices (see Certification and Compliance).
Commvault recommends the following additional network controls, per your customer and service offering:
-
Encrypt all data in transit when leaving your data-center
-
Command and control traffic are encrypted by default.
-
Payload traffic can be optionally encrypted as well.
-
-
Consider encrypting data on disk when storing data outside your data-center.
-
Implement network security controls to control the direction of traffic flows to/from tenant networks.
-
Commvault has the ability to utilize Commvault Network Gateways to tunnel traffic between tenant networks and Commvault.
-
Consider the additional management burden of configuring network, firewall flows inside Commvault before implementing Commvault network firewalls.
-