Hardware Specifications for Deduplication Mode

Review the suggested hardware specifications for MediaAgents to host the deduplicated data.

For more details about the supported platforms, see Building Block Guide - Deduplication System Requirements.

Sizing Guidelines

You can scale up or scale down your setup by adding or deleting the number of MediaAgents required to process your data. The following factors affect the number of MediaAgents that are required in your setup:

• The back-end size of the data. For example, to support 1 PB of storage, you need two large MediaAgents. Each large MediaAgent supports up to 650 TB of storage.

• Resiliency for backups allows for node failover by automatically redirecting the backup process to another node if 1 node is temporarily unavailable.

You can use these scaling and resiliency factors to set up partitioned deduplication databases in any of following configurations:

• Partition mode: In this mode only 1 storage pool is configured using all the MediaAgents in a grid with 1, 2, 4, or 6 partitions. Use 6 partition DDB for 6 or more nodes.

• Partition extended mode: In this mode the MediaAgents host partitions from multiple storage pools (up to 20 storage pools per grid). Each storage pool can be configured with 1, 2, 4, or 6 partitions.

  You can use the partition extended mode in the following scenarios:

  • When you want the primary copy of the data on the disk and the secondary copy on the cloud. In this case, create 1 disk storage pool and 1 cloud storage pool using the same MediaAgents.

  • In case of multi-tenancy, where the total back-end size of multiple tenants together is within the limit of the grid. In this case, to segregate data for each tenant you can configure the partition in extended mode by creating a separate storage pool for each tenant using the same MediaAgents.

The software scales the DDBs horizontally. For more information, see Deduplication Building Block Guide.

Capacity

Metadata Disk Capacity

The required metadata disk capacity varies by workload. As a guideline, Commvault recommends allocating 1% of the total storage capacity for metadata, which is sufficient for most environments.

For workloads with high deduplication ratios or a large number of small files, allocate additional metadata disk capacity to ensure optimal performance.

Storage Capacity and Hardware Requirements

The storage capacity supported by a MediaAgent depends on both system size and workload characteristics. As a guideline, Commvault recommends the CPU and RAM configurations listed below, which are sufficient for most deployments.

If the MediaAgent is also used for additional features (for example, Access Node or Threat Scan), you may need to:

• Increase CPU and RAM resources, or
• Deploy additional MediaAgents to distribute the workload.

Use the following table to calculate the storage requirements. Please contact your software vendor for assistance with more advanced design cases.

Deploying MediaAgent in Cloud/Virtual Environments

Installing a MediaAgent in a cloud or virtual environment is supported. For more details about AWS and Azure sizing, see the following:

• Public Cloud Architecture Guide for Amazon Web Services

• Public Cloud Architecture Guide for Azure

• Public Cloud Architecture Guide for Google Cloud

Configuration

After determining the number of MediaAgents for your setup by using the back-end-size table, you must create a network storage pool using these MediaAgents. For more information about creating a network storage pool, see Network Storage Pool.

If you have multiple sites, then create a network storage pool per site for cross-site replication. For information about cross-site replication, see Cross-site Replication.

Footnotes

1. SSD class disk indicates internal dedicated endurance value drives. Use MLCs (Multi-Level Cells) class or better SSDs. It is recommended to use the mixed use enterprise class SSDs.

2. The back-end storage size (BET) requirement typically ranges from 1.0 to 1.6 times the front-end data size (FET). The exact factor depends on the data retention period and the daily change rate of the front-end data.

   • Shorter retention periods reduce back-end storage requirements.

   • Extended retention applied to a larger portion of the managed data increases back-end storage consumption.

   The FET estimate can be used during storage policy design to determine the appropriate resource sizing for the use case. The supported capacity values provided apply to the most common configurations. However, capacity may be reduced if the MediaAgent is also used for advanced operations such as reading data from a backup source as an access node, performing threat analysis, or running other resource-intensive processes.

   The following are examples of commonly used settings for the backup retention.

   Example 1:

   • 80% VM/File data

   • 20% Database data

   • Daily change rate 2%

   • Compression rate 50%

   • Daily backups are retained for 30 days

   Factoring in these parameters, the back-end storage size requirements can range from 1.0 - 1.2 times the front-end data size.

   Example 2:

   • 80% VM/File data

   • 20% Database data

   • Daily change rate 2%

   • Compression rate 50%

   • Daily backups are retained for 30 days

   • 8 weekly backups are retained for 1 year

   • 9 monthly backups are retained for 1 year

   • 1 yearly backup is retained

   Factoring in these parameters, the back-end storage size requirements can range from 1.4 - 1.6 times the front-end data size.

   Please contact your software vendor for assistance with more advanced design cases.

3. You can use multiple smaller disks to meet the total metadata disk capacity requirement.

   Example: For an extra large MediaAgent, you can configure either 2 × 3.2 TB disks or 4 × 1.6 TB disks.

   During MediaAgent installation, only one metadata path can be specified. Additional paths can be added later from the Command Center.