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.

• EBS Optimization – This feature is required for best performance.

• 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 is automatically configured if using one of the SIOS 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). 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).

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.