After conducting a business impact analysis and documenting all application resiliency requirements, IT organizations can determine which workloads is best hosted in a stretch clustering environment. Due to certain constraints, not all workloads are suited for a stretch clustering configuration, as described in the section Prescriptive guidance for running stretch clustering.

In general, stretch clustering on Azure Stack HCI is an ideal DR solution for the following types of scenarios:

• Introducing automatic failover with orchestration for recovery of a web-based application’s front-end server tier after a disaster renders one hosting location unavailable.
• Distributing primary and secondary instances of infrastructure core services, such as Microsoft Active Directory, across two physical locations.
• Hosting applications with lower write I/O performance characteristics.
• Running file-system-based services and other business services that can tolerate being hosted on crash-consistent volumes. For database workloads such as Microsoft SQL Server, which often cannot sustain the loss of even a single transaction, using application-layer recoverability solutions such as SQL Always-On might be more appropriate.

Stretch clusters are either active/passive or active/active:

• Active/passive—In an active/passive setup, business consumers actively connect to a preferred site for their application and workload resources. The infrastructure at the secondary site essentially remains idle until a failover occurs. When a failover occurs, active workloads are migrated to the secondary site, and business consumers connect to their applications running on that secondary site.

Figure 1.   Active/passive stretch clustering architecture

• Active/active—In an active/active setup, replication occurs bidirectionally from either site. Business consumers connect to active applications in both sites at any given time. This setup tends to be a more efficient use of an organization’s investment in infrastructure because resources in both sites are being used.

Figure 2.   Active/active stretch clustering architecture

The Storage Replica service supports synchronous and asynchronous replication:

• Synchronous replication—Mirrors data across low-latency networks with crash-consistent volumes to help ensure that no data loss occurs at the file-system level during a failover. This replication technique enables workloads to come back online automatically. With synchronous replication, data blocks are written to log files on both sites before being committed.
• Asynchronous replication—Mirrors data across greater distances over networks with higher latencies. This strategy does not guarantee that both sites have identical copies of the data at the time of failure. This replication technique does not enable workloads to be brought back online automatically after a failover. With asynchronous replication, the remote node accepts blocks of replicated data and lazily acknowledges back to the source copy.

Note: Asynchronous replication does not affect application performance unless the rate of data change is faster than the bandwidth of the replica link between the sites for longer periods of time. Ensure that ample consideration is given to this critical factor during the solution design.