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.
Important
-
The following hardware requirements are applicable for MediaAgents with deduplication. The requirements do not apply to tape libraries or MediaAgents without deduplication or in setups where third party deduplication applications are used.
-
In this page, for ease of use, the terms node and MediaAgents are used interchangeably.
-
The suggested workloads are not software limitations, rather design guidelines for sizing under specific conditions.
-
The TB values are base-2.
-
The hardware specifications are listed for the most common configurations. You can add as many MediaAgents as required depending on the storage capacity.
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
Use the following table to calculate the storage requirements.
Please contact your software vendor for assistance with more advanced design cases.
MediaAgent (Windows and Unix)
Size | CPU Cores | RAM | OS Disk Space | Data Disk Space (DDB + Index Cache) | Supported Back-End Size | Parallel Streams | Notes |
---|---|---|---|---|---|---|---|
X-Small | 8 cores | 16 GB | 200 GB | 1.6 TB | Up to 100 TB | - | SSD mandated |
Small | 8 cores | 32 GB | 200 GB | 3.2 TB | Up to 250 TB | 50 | SSD mandated |
Medium | 12 cores | 64 GB | 200 GB | 6.4 TB | Up to 450 TB | 100 | SSD mandated |
Large | 16 cores | 128 GB | 200 GB | 7.68 TB | Up to 650 TB | 200 | SSD mandated |
Extra Large | 24 cores | 192 GB | 200 GB | 15.36 TB | Up to 1000 TB | 200 | SSD mandated |
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:
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
-
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.
-
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.
-