The performance characteristics of your PlateSpin Protect product depend on a number of factors, including:
Hardware and software profiles of your source workloads
Hardware and software profiles of your target containers
Hardware and software profile of your PlateSpin Server host
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.
Scalability encompasses (and depends on) the following major characteristics of your PlateSpin Protect 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 fail-overs) and hardware vendor specifications.
In a VMware DRS Cluster, ensure that you balance protection targets across multiple hosts in the cluster for best performance.
You should conduct tests, incrementally adjust your capacity numbers, and use them in determining your scalability ceiling.
PlateSpin Protect includes Microsoft SQL Server Express Edition. The PlateSpin Server database instance might grow up to 0.5 GB per month per workload, depending on the number of incremental replications that are scheduled.
We recommend that you periodically archive or discard the historical reporting data to make room for new reporting data.
The capabilities of SQL Server Express are sufficient for a single PlateSpin Server that protects up to 50 workloads. See Section 1.4.2, Scalability.
NOTE:Microsoft SQL Server Express has a database size limit of 10 GB and can use only one CPU core at a time. For more information about system requirements and limitations for SQL Server Express, see the Microsoft SQL Server 2014 Express documentation.
We recommend that you configure the PlateSpin Server to use a database instance on your existing Microsoft SQL Server Standard Edition or Enterprise Edition database server in the following environments:
Deployments of multiple PlateSpin Servers that use the same remote Microsoft SQL Server database server for their database instances
Deployments where keeping all history of the reporting data is important
While multiple PlateSpin Servers can use the same remote database server, each server requires a separate database instance.
To set up a remote database instance for your PlateSpin Server, see Configuring Your Remote Microsoft SQL Server Database Server
in the PlateSpin Protect Installation and Upgrade Guide.
In your protection environment, you will have different expectations for recovery points and recovery times required for a variety of workloads.
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 Protect, 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.
If necessary, PlateSpin Protect 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 Protect 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.