There are multiple replication approaches, but two methods are highly recognized in the storage industry: asynchronous and synchronous. PowerStore supports asynchronous replication of block and file volumes and synchronous replication with Metro Volume (block).
Synchronous replication 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. Synchronous replication provides a blend of data consistency and high availability with uniform storage presentation.
Note: PowerStore uses a Symmetric Active/Active Metro Volume architecture. This means that either volume may be a synchronous replication source and either volume may be a synchronous replication destination. Synchronous replication happens bidirectionally between clusters that support Metro Volumes.
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 also applies to Metro Volumes built on top of synchronous replications. 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:
This process is repeated for each write I/O requested by the application or server.
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 snapshot rules and 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.
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:
Steps 1 through 3 are repeated for each write I/O requested by the application or server.