Clusters must be joined in a peer relationship before replication between different clusters is possible.
Cluster peering is a one-time operation that must be performed by the cluster administrators.
An intercluster LIF must be created on an intercluster-capable port, which is a port assigned the role of intercluster or a port assigned the role of data.
NOTE: Ports that are used for the intracluster cluster interconnect may not be used for intercluster replication.
Cluster peer requirements include the following:
- The time on the clusters must be in sync within 300 seconds (five minutes) for peering to be successful.
Cluster peers can be in different time zones
- At least one intercluster LIF must be created on every node in the cluster.
- Every intercluster LIF requires an IP address dedicated for intercluster replication.
- The correct maximum transmission unit (MTU) value must be used on the network ports that are used for replication.
- All paths on a node used for intercluster replication should have equal performance characteristics.
- The intercluster network must provide connectivity among all intercluster LIFs on all nodes in the cluster peers.
- Every intercluster LIF on every node in a cluster must be able to connect to every intercluster LIF on every node in the peer cluster.
- Check the role of the ports in the cluster.
cluster01::> network port show
- Change the role of the port used on each node to intercluster.
cluster01::> network port modify -node cluster01-01 -port e0e -role intercluster
- Create an intercluster LIF on each node in cluster01.
This example uses the LIF naming convention <nodename>_icl# for intercluster LIF.
cluster01::> network int create -SVM cluster01-01 -lif cluster01-01_icl01 -role intercluster -home-node cluster01-01 -home-port e0e -address 192.168.1.201 -netmask 255.255.255.0
- Repeat the above steps for destination Cluster Cluster02
- Configure Cluster Peers
cluster01::> cluster peer create -peer-addrs
192.168.2.203,192.168.2.204 –username admin
- Display the newly created cluster peer relationship.
cluster01::> cluster peer show –instance
- Preview the health of the cluster peer relationship.
cluster01::> cluster peer health show
- Create SVM peer relationship
cluster01::> vserver peer create -vserver vs1.example0.com -peer-vserver vs5.example0.com -applications snapmirror -peer-cluster cluster02
- Verify SVM peer relationship status
cluster01::> vserver peer show-all
Complete the following requirements before creating an intercluster SnapMirror relationship:
- Configure the source and destination nodes for intercluster networking.
- Configure the source and destination clusters in a peer relationship.
- Configure source and destination SVM’s in a peer relationship.
- Create a destination NetApp SVM; volumes cannot exist in Cluster-Mode without a SVM.
- Verify that the source and destination SVMs have the same language type.
- Create a destination volume with a type of data protection (DP), with a size equal to or greater than that of the source volume.
- Assign a schedule to the SnapMirror relationship to perform periodic updates.
- Create a snapmirror schedule on Destination Cluster
cluster02::> job schedule cron create -name Hourly_SnapMirror -minute 0
- Create a SnapMirror relationship with –type DP and assign the schedule created in the previous step. Vs1 and vs5 are the SVM’s.
cluster02::>snapmirror create -source-path vs1:vol1 -destination-path vs5:vol1 -type DP -schedule Hourly_SnapMirror
- Review the SnapMirror relationship.
- Initialize the SnapMirror relationship in the destination cluster.
cluster02::>snapmirror initialize -destination-path vs5:vol1
- Verify the progress of the replication.
SnapMirror relationships can be failed over using the snapmirror break command and resynchronized in either direction using the Snapmirror resync command.
In order for NAS clients to access data in the destination volumes, CIFS shares and NFS export policies must be created in the destination SVM and assigned to the volumes.