Recommended instance sizes for CPM Server instances

Recommended instance sizes and volume types for CPM Server instances

EC2 Instance sizing

Here are the recommended instance sizes for CPM Server instances:
  1. Up to 200 instances   -  t3.medium
  2. Up to 500 instances   -  m5.large, c5.large, R5.large, C6i.large, R6i.large, M6i.large, C7i.large, M7i.large
  3. Up to 1000 instances  - m5.xlarge, c5.xlarge, R5.xlarge,  C6i.xlarge,  R6i.xlarge, M6i.xlarge,C7i.xlarge, M7i.xlarge
  4. Up to 2000 instances - m5.2xlarge, c5.2xlarge, R5.2xlarge,  C6i.2xlarge,  R6i.2xlarge, M6i.2xlarge, C7i.2xlarge, M7i.2xlarge
  5. Up to 4000 instances - m5.4xlarge, c5.4xlarge, R5.4xlarge,  C6i.4xlarge,  R6i.4xlarge, M6i.4xlarge, C7i.4xlarge, M7i.4xlarge
  6. Over 4000 instances - please move additional instances to a new CPM Server

Important: when using the S3 Backup feature, please upgrade to the next available instance size, but no smaller than "large" - this feature can be very memory consuming

Please note:
  1. C5 and M5 families are only supported from CPM v2.6 and support for T3 family was added at 2.4
  2. Usage of T2/T3 families is not recommended for environments with over 200 protected instances, from version 2.6 and above always prefer M5/C5 types
  3. When Using T2/T3, it is always recommended to use the newer T3 Type which should cost the same.
  4. CPM is more IO-intensive than CPU-intensive, improving IO performance will usually gain better results than improving CPU performance.
  5. When using burstable instances (T2/T3 type), it is recommended to use unlimited mode: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html
  6. R5 support: we added support for R5 EC2 type in 2.7.x/3.0x, R5 instances are much more cost-effective per GB and have more memory then other types of the same size, So if the main sizing issue you have is memory usage, then it is better to switch to R5 Family in the same size instead of increasing the size. 
, 
When using T2 instances, it is recommended to monitor the CPU Credit Balance to make sure it doesn’t reach 0, as it may affect the instance’s performance.
Please read the following KB to better understand how CPU credit balance is calculated and how draining it may affect your instance’s performance.

This recommendation is based on the following assumptions:
  1. Instances have 3 volumes on average.
  2. No more than 20% of instances have Agents performing VSS/scripts.
  3. No more than 20% of instances are being backed up simultaneously (within 60 minutes from each other).
Exceeding these assumptions may require larger instance sizes.
To resize the instance, please follow this guide:
  1. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html

CPMDATA (EBS) Sizing

V3.2.0 - We added support for IO2 
V3.2.1 - We added support for GP3, which provide a lot more IOPS(3,000 IOPS free) for cheaper price compared with GP2

For 200 and more protected instances (or when running backups more frequently than hourly) we recommend to switch the CPMDATA volume's type from "GP2" to "GP3" (supported in v3.2.1 and up) with the default IOPS/Throughput:


If "GP3" is not available, you can switch to "io1" or "io2" with minimum 1000 IOPS:

You can switch the volume's type with zero downtime by following this guide:
  1. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/console-modify.html
Since achieving more IOPS might requires resizing the volume, please follow this guide to allow OS to see the new size correctly:
  1. https://support.n2ws.com/portal/kb/articles/resizing-the-cpmdata-volume
Note: Please make sure to first check AWS documentation for maximum IOPS per GB BEFORE resizing the volume

For over 200 instances or 600 volumes, you may need to raise IOPS further - we recommend to add another 500 IOPS per each 100 instances or 300 volumes above this limit.
For best results, it's recommended to switch to the M4/M5/C5/R5 family of instances, which is EBS-optimized and can take full advantage of the io1 volume.

When using GP2 volumes, it is recommended to monitor the BurstBalance to make sure that the volume can provide more than the default provisioned 100 IOPS:
  1. http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ebs-metricscollected.html

Using "gp2" volume for 200+ instances (or frequent backups) may cause severe performance issues, including failing backups/DR and unexpected restarts of CPM Agent/Server.



 




    • Related Articles

    • Recommended VM Types for CPM Server in Azure

      Recommended VM Types for CPM Server in Azure On this page • Azure VM Sizing Azure VM sizing Here are the recommended instance sizes for CPM Server instances when working in Azure: Up to 200 instances - Standard_A2_v2, Standard_B2s Up to 500 instances ...

    • How to change instance type of S3 worker instances CPM

      Some clients may need worker instances with more ram and CPU power. You can use this process to modify the ec2 instance type used for worker instances. We highly recommend not to change size unless it was suggested by the N2WS support team. Otherwise ...

    • How to fully encrypt CPM server root and data volumes in EBS

      The steps below will help you properly encrypt the CPM server root and data EBS volumes for an existing CPM server instance. If encrypting only the data volume, it is still necessary to launch a new CPM server instance. Then during initial CPM ...

    • Instance recovery may fail if volume over 1024GB is restored.

      Issue: Instance recovery appears successful in cpm, but when viewing in ec2, the restored instance is terminated with : State transition reason message Client.InvalidParameterCombination: Could not create volume with size 1025GiB from snapshot ...

    • CPM v3.0.x may launch unnecessarily large Cleanup workers, resulting in extra costs

      CPM v3.0.x may launch unnecessarily large Cleanup workers, resulting in extra costs. In order to reduce the costs, please use the following procedure: Connect (via ssh) to the machine running cpm (you will need to execute "sudo -i" to gain the root ...