There are multiple replication approaches, but two methods are highly recognized in the storage industry: asynchronous and synchronous. PowerStore supports asynchronous replication of block volumes, vVols, and file. It also supports synchronous replication (active-passive) of file and block volumes. For Metro Volumes, PowerStore uses a Symmetric Active/Active architecture. This means that either volume can be a synchronous replication source and either volume can be a synchronous replication destination. Synchronous replication happens bidirectionally between clusters that support Metro Volumes.

Synchronous replication

Synchronous replication, introduced with PowerStoreOS 4.0, guarantees data consistency (zero data loss) between the replication source and destination volumes during normal operation. This data consistency is achieved by ensuring write I/O commitments at the replication source and destination before a successful write acknowledgment is sent back to the host and the requesting application. In a metro configuration synchronous replication provides a blend of data consistency and high availability with uniform storage presentation. Traditional synchronous replication requires a triggered failover to enable the DR storage resource.

With synchronous replication, any source of latency that impacts the source or destination volume, or the replication link in-between, adversely impacts applications in terms of latency (slowness) and availability. This applies to any kind of synchronous replication including Metro Volumes which is built on top of synchronous replication. For this reason, appropriate performance sizing is paramount for the source and destination storage, as well as the replication bandwidth and any other upstream infrastructure on which the storage depends.

Figure 1 demonstrates the write I/O sequence of synchronous replication:

1. The application or server sends a write request to the source volume.
2. The write I/O is mirrored to the destination volume.
3. The mirrored write I/O is committed to the destination volume.
4. The write commit at the destination volume is acknowledged back to the source volume.
5. The write I/O is committed to the source volume.
6. The write acknowledgment is sent to the application or server.

This process is repeated for each write I/O requested by the application or server.

Figure 1.   Block storage synchronous replication write I/O sequence

Note: PowerStore supports synchronous replication as part of the Metro Volume feature introduced in PowerStoreOS 3.0. For more information, see the Dell PowerStore: Metro Volume white paper.

Asynchronous replication

Asynchronous replication accomplishes similar data protection goals in that data is replicated from source storage to destination storage in a unidirectional way. However, the manner and frequency with which the data is replicated differs from synchronous replication. With asynchronous replication, instead of committing a write at both replication source and destination simultaneously, the write is committed only at the source and an acknowledgment is immediately sent to the host and application. The accumulated committed writes at the source volume are replicated to the destination volume in one batch at scheduled intervals and committed to the destination volume.

PowerStore replication rules combine to form a protection policy (applied granularly per volume or NAS server) that dictates the asynchronous replication intervals and RPO for the volume. A PowerStore protection policy can include a replication rule and snapshot rules at the same time for local and remote protection of storage resources.

Starting with PowerStoreOS 3.5, secure snapshots are available for volumes and volume groups. When the secure snapshot setting is enabled, the snapshot is protected from deletion until the retention period expires. If both the source and destination systems are running PowerStoreOS 3.5 or later, snapshots and snapshot rules that have secure snapshots enabled are replicated as secure to the destination system. However, if the destination system is running an earlier version of PowerStoreOS, snapshots and snapshot rules are replicated as regular snapshots and rules without the secure option. In a failover scenario, where the primary system is running a code earlier than the PowerStoreOS 3.5 release, the system takes regular snapshots instead. If secure snapshots are used, having both systems running PowerStoreOS 3.5 or later is recommended for compatibility purposes.

Volumes can adhere to their own independent replication schedule, or they can share a replication schedule with other volumes that leverage the same protection policy. Because asynchronously replicated transactions are not required to wait for write committals at the replica destination volume, the replication link and/or destination storage will not contribute to application or transaction latency at the source volume.

Figure 2 demonstrates the write I/O pattern sequence for asynchronous replication:

1. The application or server sends a write request to the source volume.

2. The write I/O is committed to the source volume.
3. The write acknowledgment is sent to the application or server.

Steps 1 through 3 are repeated for each write I/O requested by the application or server.

4. Periodically, a batch of write I/Os that have already been committed to the source volume are transferred to the destination volume.
5. The write I/Os are committed to the destination volume.
6. A batch acknowledgment is sent to the source.

Figure 2.   Block storage asynchronous replication write I/O sequence