1.4 Performance

1.4.1 About Product Performance Characteristics

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.

1.4.2 Data Compression

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.

1.4.3 Bandwidth Throttling

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.

1.4.4 RPO, RTO, and TTO Specifications

  • Recovery Point Objective (RPO): Describes the acceptable amount of data loss measured in time. The RPO is determined by the time between incremental replications of a protected workload and 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): Describes the time required for a failover operation (bringing a failover workload online to temporarily replace a protected production workload).

    The RTO for failing a workload over to its virtual replica is affected by the time it takes to configure and execute the failover operation (10 to 45 minutes). See Failover.

  • Test Time Objective (TTO): Describes the time required for testing disaster recovery with some confidence of service restoration.

    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.

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.

1.4.5 Scalability

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 5 and 40, 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 ESX 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.