Best Practices

The following recommendations should be followed for optimal performance. They include considerations specific to both the Windows operating system and AWS Cloud configuration. The primary component of SIOS DataKeeper is an upper filter volume driver. This driver tracks and processes every request sent to a source volume, and therefore incurs some overhead for all volume operations. When properly configured this overhead can be as low as 2%, but this is not usually expected in cloud environments. The average customer should see somewhere between 10% and 20% overhead when operating in the cloud.

• Instance Size – Replication performance relies on several factors. CPU usage is minimal, but RAM utilization depends entirely on network performance, peak active workload, volume read/write latency, and the number of concurrent mirrors under load. With these considerations in mind SIOS recommends using instance sizes that have at least medium network performance, enable EBS optimization by default, and provide at least one instance storage volume that is NOT EBS-only. The r3.xlarge instance size is the smallest recommended instance size if performance is a concern. However, SIOS DataKeeper can be installed on any size currently available. For a full list of sizes supported refer to Supported Instance Sizes.

• Instance Storage Automatic Initialization – If you are using Instance Storage for DataKeeper Bitmaps, make sure that the Amazon EC2Launch Disk Initialization script is set to automatically initialize the instance storage disks. You can run the Powershell script “get-scheduledtasks” and verify that the Amazon “InitializeDisks.ps1” script is set to be automatically executed at system boot. If your system is using the EC2Launch V2 service, look at the Volume initialization tab and verify that volumes are chosen to be initialized at boot time.

  
  These Amazon initialization scripts initialize instance storage disks and create volumes on them, assigning the highest available drive letter (Z: by default – Y: if Z: is already in use, etc.). Set your bitmap drive to be the correct letter assigned by the Amazon script.

*Before checking for the following two features (EBS Optimization and ENA Support), verify the AWS CLI client software is installed on the system and then run “aws configure“.

• EBS Optimization – This feature needs to be Enabled / True for performance in AWS with DK. Confirm using the following command:
  

  aws ec2 describe-instances —instance-ids instance_id —region region —query “Reservations[].Instances[].EbsOptimized”

• ENA Support (Enhanced Networking) – This feature needs to be Enabled / True for performance in AWS with DK. Confirm using the following command:
  

  aws ec2 describe-instances —instance-ids instance_id —region region —query “Reservations[].Instances[].EnaSupport”

• Instance Storage – Several features of SIOS DataKeeper rely on very low latency volume access. Bitmap storage must be configured to reside on a *non*-EBS-only instance storage volume. This should be automatically configured if using one of the general purpose SIOS DataKeeper AMIs, but any nodes in which SIOS DataKeeper is installed manually will need to configure this manually as well (refer to Relocation of Intent Log). Manual configuration will also be needed if using the SIOS DataKeeper for SAP ASCS/ERS on Windows AMIs as they do not have this setting pre-configured. It is also possible to place the bitmap file on either a storage pool volume consisting of several disks striped together or low latency io1 volumes. There is a cost-performance trade-off that should be evaluated and performance tested before using either of these methods in production. Using instance storage volumes however is extremely low cost, and offers comparable performance without unnecessary configuration required.

• Volume Properties – While a simple volume is all that is required for proper mirror operation, more advanced techniques can be used to minimize read/write latency. SIOS recommends creating identical Storage Pools to support mirror volumes on both source and target systems. This QuickStart does not configure Storage Pools during deployment. Storage Spaces Direct is not compatible with SIOS DataKeeper and should not be used (refer to https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Using-the-Storage-Pools-page-in-Server-Manager-to-create-storage/ba-p/424656 for more information).

• Rolling Back A System Snapshot – The snapshot taken gives you the state of the system at that time. Using AWS / Azure as an example – if that system is restored with that full system snapshot then you have to force a full resync for all of the mirrors (whether it is the source system or the target system) to make sure the data is the same on both systems after the restore is done.

RTO and RPO – SIOS DataKeeper does not add significantly to a typical cluster single-server outage failover RTO. Assuming appropriate instance sizes are utilized, resource contention is not an issue, SIOS DataKeeper is properly configured and in the mirroring state, and assuming trivial application recovery time an RTO of <1 minute is possible. Realistically an RTO of between 2 and 5 minutes should be expected unless the application being protected (MSSQL, SAP, etc.) has an unusually large recovery time.

Assuming the same conditions, RPO should be only a few milliseconds larger than the current network write latency between the source and target nodes. RPO can be measured with this counter Performance Monitor Counters.

In many cases the RPO will be measured in milliseconds, but things like network congestion, abnormally high disk write activity, or slow write performance on the target server can impact RPO greatly. SIOS DataKeeper does not conflict with EBS snapshots, and can be used in conjunction with them on the source system. However, restoring a source volume from snapshot is not trivial, and will require a full resync of all data protected by the applicable mirror before the above RPO guidelines are applicable again.