Creating an AFM-based DR relationship

This topic lists the steps to create an AFM-based Async DR relationship.

Complete the following steps to create and use an AFM-based Asynchronous DR relationship:

Create a new primary fileset. Run on a primary cluster.
Create the primary fileset using mmcrfileset command. The primary can be connected to the secondary using NFSv3 protocol or the NSD protocol. All AFM parameters for writable filesets (single writer / independent writer) are applicable to a primary fileset. A primary fileset is not revalidated and does not check the secondary for changes because it is expected that changes always originate from the primary.

A primary fileset is a writable fileset so all file operations performed on this fileset are replayed at the secondary fileset using the same mechanism as single writer and independent writer modes. Unlike other AFM modes the secondary, or target fileset is an AFM fileset that has a relationship with a primary. The secondary fileset is enforced as read-only. AFM parameters such as Async Delay, number of flush threads and parallel write can be used on primary filesets.

When a primary fileset is created a unique primary ID is generated. When creating the primary fileset you need to specify the path to the secondary fileset though it may not exist at the time of primary creation. In the following example, the secondary is not created but the path is provided in mmcrfileset command.
```
# mmcrfileset fs1 primary2 -p afmMode=primary --inode-space=new -p
afmTarget=nfs://c2m3n06/ibm/fs1/secondary2 -p afmRPO=720
Fileset primary2 created with id 19 root inode 7340035.
Primary Id (afmPrimaryId) 15997179941099568310-C0A8747F557F0086-19
```
Note: If you are using CES NFS at home, replace c2m3n06 with ces_ip_of_secondary_node.
Create the secondary fileset. Run on a secondary cluster.
Get the primary id of the GPFS fileset on the primary side (afmPrimaryId) before the actual conversion. Use mmafmctl getPrimaryId command on the GPFS fileset on the primary side.
```
# mmafmctl fs1 getPrimaryId -j primary2
Primary Id (afmPrimaryId) 15997179941099568310-C0A8747F557F0086-19
```
Create the secondary fileset using the mmcrfileset command.
```
mmcrfileset fs1 secondary2 -p afmMode=secondary –p
afmPrimaryId=15997179941099568310-C0A8747F557F0086-19
--inode-space new
```
Link the secondary fileset on the secondary cluster using the mmlinkfileset command.
Run mmlinkfileset fs1 secondary2 -J /ibm/fs1/secondary2.

The primary does not check the secondary for changes. If you are using quotas, ensure that the same value is set for quotas on primary and secondary. On a primary fileset, eviction is disabled by default and filesets do not expire. If you are using NFS, ensure that the NFS export on the secondary site is accessible from the gateway nodes in the primary cluster. If you are using the NSD protocol, the secondary file system needs to be mounted on the gateway nodes at the primary cluster.
Restart NFS on secondary.
Note: If you are using CES NFS, restart is not required.
Link the primary fileset on the primary cluster. Link the primary fileset using mmlinkfileset command. Linking the fileset creates the first RPO snapshot on the primary called psnap0.
```
mmlinkfileset fs1 primary2 -J /ibm/fs1/primary2
```
After the primary and secondary are linked, the RPO snapshot (psnap0) gets queued from the primary fileset which gets replayed on the secondary fileset. The Async DR filesets are now ready for use.

Do not run mmafmconfig command on the secondary site. Run mmafmctl gpfs0 getstate on the primary to know the primary gateway node.
Check fsid and primary id on the secondary, and ensure that any two secondary filesets do not share the same fsid or primary id.
psnap0 must be created at both sites for the filesets to synchronize. In cases like node shutdown, process failure; psnap0 might not be created. Hence, filesets do not synchronize with the secondary. Unlinking and re-linking the filesets re-creates psnap0. The filesets then synchronize with the secondary.