= Disaster Recovery :toc: :icons: :linkattrs: :imagesdir: ../resources/images == Summary This section will cover the SnapMirror feature available with your Amazon FSx for NetApp ONTAP file system. SnapMirror is NetApp ONTAP's native block level replication technology for disaster recovery and data migrations. You can use SnapMirror to: * Replicate data between two Amazon FSx for ONTAP file systems located in different VPC's to simulate Cross-Region Replication (CRR) for disaster recovery. * Migrate data from on-premises NetApp hardware into Amazon FSx for ONTAP file systems. * Create a second copy of your data on a second Amazon FSx for ONTAP file system within the same region or across regions. * Setup a DR in the cloud and replicate data between your on-premises NetApp storage and FSx for ONTAP file system. TIP: Consider using Amazon FSx Backups, which provide cost efficient offsite backup of your FSx for ONTAP volumes when planning for disaster recovery. FSx backups are stored in highly durable storage within the same region. === SnapMirror Overview SnapMirror is a disaster recovery technology in ONTAP which can be used to failover from your *Primary* FSx file system to a *Secondary* FSx file system in the same or different region. SnapMirror can also be used to configure disaster recovery between your NetApp storage on-premises and an FSx file system in the Cloud or migrate data from on-premises NetApp storage arrays into the FSx file system. You can perform SnapMirror volume replication on Amazon FSx for NetApp ONTAP. SnapMirror Volume replication ensures that all data from a source system is copied to the target and is available in the event of a system failure or disaster. A peer relationship must be created between the Inter Cluster LIFs on the source and destination file systems and the SVMs. The first time you create a SnapMirror relationship, a snapshot is created on the source to perform the baseline transfer from source to destination volume. == Duration NOTE: It will take approximately 10 minutes to complete this section. == Diagram You will be using resources deployed in *Primary VPC* and *Secondary VPC* for this section of the workshop. image::primary-dr-architecture.png[align="center"] == Step-by-step Guide (SnapMirror volume replication) IMPORTANT: Read through all steps before continuing. //image::xxx.gif[align="left", width=600] === Examine your *DR/Secondary* file system in DR VPC. . Go to the link:https://console.aws.amazon.com/fsx/[Amazon FSx] console. *_Click_* the *File system ID* of your *DR/Secondary* Amazon FSx for NetApp ONTAP file system with name *FSxNetAppOntap-DR*. . Make sure you are in the *AWS Region* of your workshop environment. If you need to change the *AWS Region* of the Amazon FSx console, in the top right corner of the browser window *_click_* the region name next to *Support* and *_click_* the appropriate *AWS Region* from the drop-down menu. . *_Examine_* the *Storage virtual machines(SVMs)* section of the file system. *_Click_* the *Storage virtual machines* tab. *_Find_* the values of the following file system attributes: * SVM Name * SVM ID . *_Examine_* the *Volumes* section of the file system. *_Click_* the *Volumes* tab. *_Find_* the values of the following file system attributes: * Volume Name === SnapMirror steps NOTE: If you are creating a SnapMirror relationship between FSx file systems in a different accounts or different region you will need to establish VPC communication using link:https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html[VPC peering] or link:https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html[Transit gateway]. Once the VPC communication is in place, you will need to create cluster and SVM peering between your FSx file systems. The workshop environment has already created VPC peering between the Primary VPC and Secondary VPC along with Cluster peering between the two FSx file systems and SVM peering between SVM in the Primary VPC and SVM in the Secondary VPC. . *_Return_* to the Session Manager connection of the *FSx for ONTAP Workshop Linux Instance* and *_run_* the command below to SSH to the cluster management endpoint of your *Primary* FSx for ONTAP file system. + TIP: If the Session Manager window has timed out, e.g. the session is unresponsive, close the session window and create a new one. Return to the link:https://console.aws.amazon.com/ec2/[Amazon EC2] console. *_Click_* the radio button next to the instance with the name *FSx for ONTAP Workshop Linux Instance*. *_Click_* the *Connect* button. Connect using AWS Systems Manager - *_Select_* *Session Manager* tab and *_click_* the Connect button to open a session in your browser. Change the shell back to bash by typing the command ***bash*** and then return. + + [source,bash] ---- ssh ${ADMINUSER}@${MGMTENDPOINT} ---- + . *_Verify_* the Cluster Peer Relationship created by the workshop environment between your *Primary* FSx file system and *DR/Secondary* FSx file system. + [source,bash] ---- cluster peer show ---- + . *_Verify_* the SVM Peer Relationship created by the workshop environment between your *Primary* file system SVM and *DR/Secondary* file system SVM. + [source,bash] ---- vserver peer show ---- + . *_Run_* the command below to quit the ONTAP CLI session. + [source,bash] ---- quit ---- + . *_Run_* the command below to SSH to the cluster management endpoint of your *DR/Secondary* FSx for ONTAP file system. + [source,bash] ---- ssh ${ADMINUSER}@${DRMGMTENDPOINT} ---- + . *_Enter_* *yes*, if you get the authenticity warning to trust the host on the SSH connection. At the *_Password_* prompt, Enter the password for your file system; in this workshop the password is the same for the Primary and DR/Secondary FSx file systems. You can retrieve the password using link:https://console.aws.amazon.com/secretsmanager[AWS Secrets Manager]. *_Select_* the secret name *FSxadmin->* and *_Click_* on *Retrieve Secret value* to get the fsxadmin user password. Upon successful login you will see the prompt as shown below: + NOTE: The passwords are the same between the **Primary** and **DR/Secondary** file systems in the workshop. + + [source,bash] ---- FsxId08361928e949c6b55::> ---- + . *_Verify_* the Cluster Peer Relationship created by the workshop environment between your *Primary* FSx file system and *DR/Secondary* FSx file system. + [source,bash] ---- cluster peer show ---- + . *_Verify_* the SVM Peer Relationship created by the workshop environment between your *Primary* file system SVM and *DR/Secondary* file system SVM. + [source,bash] ---- vserver peer show ---- + . *_Verify_* the SnapMirror relationship from the *DR/Secondary* file system. If you see the status as *Transferring* or *Finalizing*, *_wait_* for the status to change to *Idle*. + [source,bash] ---- snapmirror show ---- + NOTE: The workshop environment has already created the SnapMirror relationship and initialized it. To learn more about SnapMirror best practices refer link:https://www.netapp.com/media/17229-tr4015.pdf?v=127202175503P[SnapMirror Best Practices]. + . *_Check_* detailed information about your SnapMirror relationship by running the below command from your *DR/Secondary* FSx file system. Examine the output and check for *Throttle (KB/sec)*. + [source,bash] ---- snapmirror show -instance ---- + . Was your SnapMirror transfer bandwidth throttled? + TIP: To identify if a SnapMirror relationship is throttled, review the *Current Throttle* value. You can configure per-relationship throttle to restrict amount of bandwidth used. + . *Create* a *_Junction Path_* for the destination volume using *ONTAP CLI*. + [source,bash] ---- volume mount -vserver svm01-dr -volume vol1_dr -junction-path /vol1_dr ---- + . *_Run_* the command below to quit the ONTAP CLI session. + [source,bash] ---- quit ---- + . On your *FSx for ONTAP Workshop Linux Instance* *mount* the volume from your *DR* storage virtual machine. + [source,bash] ---- sudo mkdir ${SMMOUNT} sudo mount -t nfs ${DRNFSENDPOINT}:/vol1_dr ${SMMOUNT} ---- + . *_Run_* the below command to set the *user:group* Unix permissions for the mount point. + [source,bash] ---- sudo chown ssm-user:ssm-user ${SMMOUNT} ---- + . Did the permission change work? Since the volume is data protected by the SnapMirror relationship, you can only mount it read-only. + . *_Run_* the command below to SSH to the cluster management endpoint of your *DR/Secondary* FSx for ONTAP file system. + [source,bash] ---- ssh ${ADMINUSER}@${DRMGMTENDPOINT} ---- + . *_Verify_* the status of the SnapMirror relationship shows *snapmirrored idle*, *quiesce* the relationship and *break* the relationship to make the destination volume *_read-write_*. + [source,bash] ---- snapmirror show snapmirror quiesce -destination-path svm01-dr:vol1_dr snapmirror break -destination-path svm01-dr:vol1_dr ---- + . *_Verify_* SnapMirror relationship status from your *DR/Secondary* FSx file system. You should see the status as *broken-off*. + [source,bash] ---- snapmirror show ---- + . *_Run_* the command below to quit the ONTAP CLI session. + [source,bash] ---- quit ---- + . *Write* data on your destination volume to confirm your destination is now read-write. + [source,bash] ---- sudo chown ssm-user:ssm-user ${SMMOUNT} echo "Writing to snapmirrored volume" >> ${SMMOUNT}/snapmirror.txt cat ${SMMOUNT}/snapmirror.txt ---- + == Next section Click the button below to go to the next section. image::flexcache.png[link=../09-flexcache/, align="left",width=420]