Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
E2E Deployment and Operations Guide with Stretched Cluster: Integrated System for Microsoft Azure Stack HCI
About using this guide Introduction Solution overview Solution deployment
Solution deployment
Introduction
Install roles and features
Configuring a cluster witness
Registry settings
Deployment prerequisites for stretched clusters
Customer network team requirements
Design principles and best practices
Validated network topology
Creating a stretched cluster Virtual Machines Failure/Recovery from failure of Site/Node Appendices Day 1 operations Managing and monitoring clusters with Windows Admin Center Dell OpenManage Integration with Windows Admin Center Updates and maintenance References

Design principles and best practices

Home > Integrated Products > Microsoft HCI Solutions from Dell Technologies > Guides 22H2 and earlier > E2E Deployment and Operations Guide with Stretched Cluster: Integrated System for Microsoft Azure Stack HCI > Design principles and best practices

Design principles and best practices

  • Stretched clusters and Storage Replica

    A stretched cluster setup has two sites and two storage pools. Replicating data across WAN and writes on both sites results in lower performance compared to a standalone Storage Spaces Direct Cluster. Low latency inter-site links are necessary for optimum performance of workloads. Low bandwidth and high latency between sites can result in very poor performance on the primary site in the case of both synchronous and asynchronous replication.

    Synchronous replication involves data blocks being written to log files on both sites before being committed. In asynchronous replication, the remote node accepts the block of replicated data and acknowledges back to the source copy. Application performance is not affected unless the rate of change of data is faster than the bandwidth of the replica link between the sites for large periods of time. This point is critical and must be taken into consideration when you are designing the solution.

    The size of the log volume has no bearing on the performance of the solution. A larger log collects and retains more write I/Os before they are wrapped out. This allows for an interruption in service between the two sites (such as a network outage or the destination site being offline) to go on for a longer period.

    Table 3. Disk writes
    Scenario Writes in two-way mirrored volumes Writes in three-way mirrored volumes
    Standalone storage spaces 2x 3x
    Replication to secondary site 4x 6x
    Note: WAN latency and additional writes to log volumes on both sites causes higher write latency. Along with writes to the log and data disks, the inter-site bandwidth and latency also play a role in limiting the IOPs in the environment. For this reason, we highly recommend using all-flash configurations for stretched clusters.

    Note: In a Storage Spaces Direct environment both data and log volumes eventually reside on the same SSD pool because multiple storage pools per site are not supported.

    The following figure illustrates the difference between synchronous and asynchronous replication:

    Figure 2. Synchronous and asynchronous replication

    Synchronous replication: A block of data written by an application to a volume on Site A (1) is written first to the corresponding log volume on the same site (2), and is then replicated to Site B (2). At site B, the block of data is written to the Replica log volume (3) before a commit is sent back to the application using the same route (4 and 5). The block is subsequently pushed to the data volumes on both sites. For each block of data that the application writes, the commit is issued only after data is written to the secondary site. Thus there is no data loss at file system level in the event of a site failure. This results in a lower application write performance compared to a standalone deployment.

    Asynchronous replication: A block of data written by an application to a volume on Site A (1) is written first to the corresponding log volume on the same site (2). A commit is immediately sent back to the application. At the same time, the block of data is replicated to Site B and written to the Replica log volume. In the case of a site failure, the cluster ensures that no data is lost beyond the configured Recovery Point Objective (RPO). Application performance is not affected unless the rate of change of data is faster than the bandwidth of the replica link between the sites for large periods of time. This is critical and must be taken into consideration when designing the solution.

    Note: Both replication scenarios affect application performance because each data block has to be written multiple times, assuming that all volumes are configured for replication.

    Note: Stretched cluster with Storage Replica is not a substitute for a backup solution. Stretched cluster is a disaster recovery solution that keeps a business running in the event of a site failure. Customers should still rely on application and infrastructure backup solutions to recover lost data due to user error or application/data corruption.