Asynchronous Replication of a Global Folder

You can configure a global access protected path (global folder) and an asynchronous replication remote protected path on the same source path.

With this configuration, the replication source peer is also the origin of the global folder. In the event of failover, a peer that becomes the source of replication also becomes the origin for the global folder.

Requirements and Limitations

The following requirements and limitations apply to the configuration:

All participating clusters must be running VAST Cluster 5.3 (or later).
The destination paths for asynchronous replication and global access must be on different replication peers (different clusters).

Configuration Workflow for Asynchronous Replication with Global Access

To configure asynchronous replication of a path to a peer and to configure that same path as a global folder with global access from another peer, you need to configure all of the following:

A replication peer for each destination on the source path. That is, one for each replication destination peer and one for each global access destination. The replication peer configuration is mirrored to each destination peer.
A replication policy for replicating to each replication destination.
One protected path, configured first on the source peer, with multiple destinations, each one with the appropriate mode selected: replication or global access. This protected path configuration is mirrored to each destination peer.
An additional replication peer between each replication destination and each global access destination. This establishes connectivity between each possible failover replication peer and each global folder satellite, because in the event of replication failover, the new source peer becomes the origin of the global folder.
On each global access satellite, you need to modify the protected path (which is automatically mirrored to the satellite) and add a standby replication stream between each replication peer and the global access satellite.

The following example configures an asynchronous replication protected path on the path /examplepath on cluster A to a path to cluster B and then a global access protected path on cluster C:

Note
There is no requirement to create the replication first and then the global access afterwards. Both orders are supported.

Make sure there is a virtual IP pool for replication on the source cluster and on each of the destination clusters. The Virtual IP pool role must be set to replication. You can use this Virtual IP pool to control which CNodes are used to service replication and global access, although this is not mandatory.Managing Virtual IP Pools
Optional: If you want to configure secure mode on the connection between the clusters used for GA, with mTLS encryption, make sure that mTLS certificates are installed on every participating cluster. Encrypting Replication with mTLS
Optional: Make sure bucket replication is enabled so that an S3 bucket view of the global folder on the origin will be replicated to the satellite.
On cluster A, create a replication peer for cluster B and for cluster C.
On cluster B, create a replication peer for cluster C.
On cluster A, create a replication policy for replicating from A to B.
Still on cluster A, create a remote protected path to replicate /examplepath to a path on B using the replication policy you created in the previous step. (Alternatively, you could configure global access between two clusters first and then configure replication from one of the clusters to a third cluster afterwards.)
Initially, the protected path state is Initializing.
Wait while the protected path initializes, if this takes time. The next state after Initializing is Initial Sync. As soon as the state is no longer Initializing you can move to the next step.
On cluster A, modify the protected path to add C as a global access satellite:
1. Right-click the protected path and select Edit.
  add a new destination with the following configuration:
2. Click + Add Another to add another destination.
3. In the Create Destination dialog, set the following:
  - Mode: Global Access
  - Cluster: Cluster C
  - Remote tenant: the tenant on C where the destination path should reside.
  - Path: a new path on the remote tenant to be used for accessing the global folder on cluster C.
On cluster C, add a standby global access stream between clusters B and C to the protected path.This standby stream enables cluster B to become the new global folder origin for cluster C in the event of replication failover from cluster A to cluster B. After failover, cluster C will begin accessing cluster B's path as the global folder origin.
To add the stream:
1. Open the VAST Web UI of cluster C.
2. Open the Protected Paths tab of the Data Protection page.
  The protected path appears here with the role Standalone and the state Replication ready.
3. Right-click the protected path and select Edit.
  The message To complete the configuration please configure stream to Cluster B appears and the Create Destination dialog opens automatically.
  In the Create Destination dialog, the following settings are selected automatically:
  - Mode: Global Access
  - Cluster: Cluster B
  - Remote tenant: the tenant on B where the replication path resides.
4. In the Path field, enter the path that is the replication destination path on cluster B.
5. Click Update.
  The configuration is now complete.

Failover Scenarios for Asynchronous Replication of a Global Folder

Note
For general information about replication failover, see Failover Capabilities and Scenarios for Asynchronous Replication.

In ungraceful failover:

While replication is suspended and the peers are in standalone state, the global access path relationship is unchanged.
If a new source peer is selected, the notification sent to all replication group members about the source change is also sent to the global folder satellites.
Cached data on satellites becomes invalid and the satellites starts to work with the new source peer as the origin of the global folder.
The former replication source is also notified of the change and stops accepting requests from satellites as the origin of the global folder.

In graceful failover:

Switching source and destination roles between peers also switches the global folder origin to the new source peer. There is a period when writes are disabled at the original source, during which the global folder satellites cannot write either.
The new replication source peer, which is the new global folder origin, notifies global folder satellites. In case of notification failure, it continues to retry, marks the satellite as detached, and issues an alert.
When the satellite receives notification of the change in origin, its lease is revoked and its cached data becomes invalid.