The performance characteristics of your PlateSpin Forge product depend on a number of factors, including:
Hardware and software profiles of your source workloads
Hardware and software profiles of your target containers
The specifics of your network bandwidth, configuration, and conditions
The number of protected workloads
The number of volumes under protection
The size of volumes under protection
File density (number of files per unit of capacity) on your source workloads’ volumes
Source I/O levels (how busy your workloads are)
The number of concurrent replications
Whether data encryption is enabled or disabled
Whether data compression is enabled or disabled
For large-scale workload protection plans, you should perform a test protection of a typical workload, run some replications, and use the result as a benchmark, fine-tuning your metrics regularly throughout the project.
If necessary, PlateSpin Forge can compress the workload data before transferring it over the network. This enables you to reduce the overall amount of data transferred during replications.
Compression ratios depend on the type of files on a source workload’s volumes, and might vary from approximately 0.9 (100MB of data compressed to 90 MB) to approximately 0.5 (100MB compressed to 50MB).
NOTE:Data compression utilizes the source workload’s processor power.
Data Compression can be configured individually for each workload or in a Protection Tier. See Protection Tiers.
PlateSpin Forge enables you to control the amount of network bandwidth consumed by direct source-to-target communication over the course of workload protection. You can specify a throughput rate for each protection contract. This provides a way to prevent replication traffic from congesting your production network and reduces the overall load of your PlateSpin Server.
Bandwidth throttling can be configured individual for each workload or in a Protection Tier. See Protection Tiers.
Recovery Point Objective (RPO): The RPO setting describes the tolerable amount of data loss as measured in time in the event of a major IT outage. You define the RPO with a configurable interval between incremental replications of a protected workload.
The RPO is affected by current utilization levels of PlateSpin Forge, the rate and scope of changes on the workload, your network speed, and the chosen replication schedule.
Recovery Time Objective (RTO): The RTO setting describes a workload’s tolerable downtime as measured by the time a failover operation takes to complete. The failover operation brings a failover workload online to temporarily replace a protected production workload.
The RTO is affected by the time it takes to configure and execute the failover operation (10 to 45 minutes). See Failover.
Test Time Objective (TTO): The TTO setting describes the time required for testing disaster recovery with some confidence of service restoration. It is similar to RTO, but includes the time needed for a user to test the failover workload.
Use the Test Failover feature to run through different scenarios and generate benchmark data. See Using the Test Failover Feature.
Among factors that have an impact on RPO, RTO, and TTO is the number of required concurrent failover operations; a single failed-over workload has more memory and CPU resources available to it than multiple failed-over workloads, which share the resources of their underlying infrastructure.
When you test the failover response, you should note the actual values associated with the configured RPO, RTO, and TTO:
Recovery Point Actual (RPA): The RPA is the actual data loss measured in time and defined by the actual measured interval between incremental replications of a protected workload that occurs during a failover test. RPA is also known as Actual Recovery Point Objective (Actual RPO).
Recovery Time Actual (RTA): The RTA is a measure of a workload’s actual downtime defined by the time a failover operation takes to complete. RTA is also known as Actual Recovery Time Objective (Actual RTO).
Test Time Actual (TTA): The TTA is a measure of the actual time in which a disaster recovery plan can be tested. It is similar to Actual RTO, but includes the time needed for a user to test the failover workload. TTA is also known as Actual Test Time Objective (Actual TTO).
You should determine average failover times for workloads in your environment by doing test failovers at various times, then use them as benchmark data in your overall data recovery plans. See Generating Workload and Workload Protection Reports.
Scalability encompasses (and depends on) the following major characteristics of your PlateSpin Forge product:
Workloads per Server: The number of workloads per PlateSpin Server might vary between 10 and 50, depending on several factors, including your RPO requirements and the hardware characteristics of the server host.
Protections per Container: The maximum number of protections per container is related to (but is not the same as) the VMware specifications pertaining to the maximum number of VMs supported per ESXi host. Additional factors include recovery statistics (including concurrent replications and failovers) and hardware vendor specifications.
You should conduct tests, incrementally adjust your capacity numbers, and use them in determining your scalability ceiling.