Migrating on-premises file shares to Amazon FSx for NetApp ONTAP

UPDATE (17 January 2023): 

Organizations of all sizes want to increase agility, accelerate innovation, improve security, and reduce costs by migrating on-premises applications to Amazon Web Services (AWS). Many of these applications store the data they rely on in NAS (network-attached storage) appliances powered by NetApp ONTAP, which provide storage and data management features that make it easy to manage applications and workloads. Migrating on-premises ONTAP to the cloud has traditionally been challenging due to no cloud solution having all the ONTAP features customers have relied on, resulting in a significant amount of overhead with cloud migration.

At AWS Storage Day 2021, AWS announced a new service – Amazon FSx for NetApp ONTAP. With Amazon FSx for ONTAP, you can now launch, run, and scale fully managed NetApp ONTAP file storage on AWS with just a few clicks. It enables you to migrate your on-premises applications that rely on NetApp or other NAS devices to AWS without modifying your application code or how you manage your data.

In this blog, we provide an overview of methods to migrate data from on-premises NAS to Amazon FSx for ONTAP. The majority of this guide is focused on using NetApp SnapMirror for online migration of on-premises ONTAP file systems to Amazon FSx for ONTAP.

Online vs. offline migration

There are two migration methods, online and offline data migration, to migrate on-premises data to Amazon FSx for NetApp ONTAP. The tools used for data migration depend on the methodology chosen.

Online migration enables data transfer to Amazon FSx for ONTAP via AWS Direct Connect or VPN. Some of the most widely used methods are NetApp SnapMirror, NetApp Cloud Sync, NetApp XCP, and Robocopy/Rsync. The amount of available bandwidth and total data to migrate directly influences total migration time.

Offline migration is recommended when there is unreliable or no external network connectivity, or when the data you are migrating is too large to transfer over your network in a reasonable timeframe. The recommended method for transferring data in these scenarios is through the AWS Snow Family service: Snowcone, Snowball Edge, and Snowmobile.

Determine your migration approach

The following flowchart can help you decide the best way to migrate your data to Amazon FSx for ONTAP. For additional considerations, refer to the “Online migration” and “Offline migration with AWS Snow Family” sections of this blog.

Figure 1: Flowchart to choose the right migration method

Online migration

A complete list of feature comparisons is given in the following table:

*Requires SnapMirror license for on-premises ONTAP file systems

Figure 2:  Amazon FSx for ONTAP online-migration architecture

NetApp SnapMirror

SnapMirror is a native NetApp ONTAP feature and is fully supported by Amazon FSx for NetApp ONTAP. SnapMirror is the recommended migration approach from on-premises ONTAP file systems to Amazon FSx for ONTAP.

SnapMirror employs block-level replication between two ONTAP file systems, replicating data from a specified source volume to a destination volume. SnapMirror’s block-level replication is more efficient than alternatives whenever the file directory structure is complex, the number of files is in the millions (50 million +), or file sizes are very small (kilobytes). Data is encrypted and remains deduplicated and compressed in-transit. Snapshots on the source ONTAP volume are preserved at the destination.

SnapMirror migration guide

This guide assumes you have created an Amazon FSx for NetApp ONTAP file system and storage virtual machine (SVM), but have not yet created a destination volume that will house your migrated data. We take you through the process of creating a peering relationship between a source and destination ONTAP cluster and their respective SVMs using their intercluster logical interfaces (LIFs). After the peering relationship is set up, you establish a SnapMirror relationship to replicate data from the source to the destination. In addition, you can optionally perform incremental updates after the initial transfer until you are ready for migration. Finally, you break the SnapMirror relationship from your Amazon FSx for ONTAP volume so it can be mounted and used.

To easily understand where to plug your values into the CLI, we have the following aliases for clusters, SVMs, and volumes:

• FSx-Dest is the destination cluster’s identifier (FsxIdxxxxxxxxxxxxx).
• OnPrem-Source is the source cluster’s identifier.
• DestSVM is the destination SVM name.
• SourceSVM is the source SVM name.
• Both the source and destination volume names are vol1.

1. Log in to the destination cluster and create your destination volume

Start by accessing your Amazon FSx for ONTAP file system (the destination cluster) via Secure Shell (SSH). You can get the <ManagementIP> from the AWS Management Console.

$ ssh fsxadmin@<ManagementIP>

Prior to creating the SnapMirror relationship, you need a volume on the destination cluster with a capacity at least equal to the volume to be replicated on the source. It also must be created with -type DP, so that it can serve as a destination for a SnapMirror relations.

FSx-Dest::>vol create -volume vol1 -aggregate aggr1 -size 1g -type DP

2. Gather the source and destination intercluster LIFs

SnapMirror uses intercluster LIFs to facilitate data transfer between source and destination clusters. These intercluster LIFs map to IP addresses and are used when establishing cluster peering.

For Amazon FSx for ONTAP systems, get the IP addresses from the AWS Management Console by navigating to your file system and then the Network & security section. In this section, under Endpoints, you find the Inter-cluster endpoint – IP address.

Figure 3: Finding intercluster LIF IPs in the AWS Management Console

You can also get the intercluster LIF IPs from the ONTAP CLI by using the following command:

OnPrem-Source::> network interface show -role intercluster

Logical                          Network 
Vserver     Interface  Status  Address/Mask
----------- ---------- ------- ------------
FSx-Dest
             inter_1    up/up  10.0.0.36/24 
             inter_2    up/up  10.0.1.69/24

Save the IP addresses of inter_1 and inter_2. We refer to these for FSx-Dest as dest_inter_1 and dest_inter_2 and for OnPrem-Source as source_inter_1 and source_inter_2.

3. Establish cluster peering between source and destination

Establish a cluster peer relationship on the destination cluster by providing source_inter_1 and source_inter_2 from the source cluster. This command requests you create a passphrase, which will be entered when establishing cluster peering on the source cluster.

FSx-Dest::> cluster peer create -address-family ipv4 -peer-addrs <source_inter_1>,<source_inter_2>

Next, establish the cluster peer relationship on the source cluster, providing dest_inter_1 and dest_inter_2 from the destination cluster. You need to enter the passphrase you created previously to authenticate.

OnPrem-Source::> cluster peer create -address-family ipv4 -peer-addrs <dest_inter_1>,<dest_inter_2>

Verify the peering was successful using the following command on the source cluster. Availability should read Available.

OnPrem-Source::> cluster peer show

Peer Cluster Name  Availability   Authentication
-----------------  -------------- --------------
FSx-Dest           Available      ok

4. Create an SVM peering relationship

With peer clustering established, the next step is peering SVMs. Create an SVM peering relationship on destination cluster (FSx-Dest) using the following commands, where in addition to the aliases we listed at the beginning, we have:

• <DestLocalName> as the name the destination SVM goes by on the source cluster, we called it destsvm01.
• <SourceLocalName> as the name the source SVM goes by on the destination cluster, we called it sourcesvm01.

FSx-Dest::> vserver peer create -vserver <DestSVM> -peer-vserver <SourceSVM> -peer-cluster <OnPrem-Source> -applications snapmirror -local-name <SourceLocalName>

Info: [Job 207] 'vserver peer create' job queued

Then accept the peering relationship on the source cluster (OnPrem-Source):

OnPrem-Source::> vserver peer accept -vserver <SourceSVM> -peer-vserver <DestSVM> -local-name <DestLocalName>

Info: [Job 211] 'vserver peer accept' job queued

Verify the SVM peering status using the following command. Peer State should read peered:

OnPrem-Source::> vserver peer show

Peer    Peer     Peer   Peering  Remote
vserver Vserver  State  Cluster  Applications  Vserver
------- -------- ------ -------- ------------- ---------
svm01   destsvm1 peered FSx-Dest snapmirror    svm01

5. Create and initialize the SnapMirror relationship

With SVMs peered, the next step is to create and initialize the SnapMirror relationship on the destination cluster. You can optionally use the -throttle flag, which sets the maximum bandwidth (in Kbytes/sec) that the SnapMirror relationship can use.

FSx-Dest::> snapmirror create -source-path <SourceLocalName>:vol1 -destination-path <DestSVM>:vol1 -vserver <DestSVM> -throttle unlimited

Operation succeeded: snapmirror create for the relationship with destination "DestSVM:vol1".

After the SnapMirror relationship has been created, initialize the SnapMirror relationship on the destination cluster with the following command. This begins the transfer of a snapshot of data from the source volume to the destination volume.

FSx-Dest::> snapmirror initialize -destination-path <DestSVM>:vol1 -source-path <SourceLocalName>:vol1

6. Maintain an updated destination cluster

If you are migrating data that is actively used, you need to ensure that your destination cluster remains up to date with your source cluster. You also need to schedule a maintenance window to complete the migration without any data loss. These actions are not done automatically. To perform a one-time update to the destination cluster, run the following command:

FSx-Dest::> snapmirror update -destination-path <DestSVM>:vol1

You may want to schedule updates on an hourly or daily cadence before moving your clients to Amazon FSx for ONTAP. You can establish a SnapMirror schedule using the following command:

FSx-Dest::> snapmirror modify -destination-path <DestSVM>:vol1 -schedule hourly

7. Break the SnapMirror relationship

If you are doing a one-time transfer from a source cluster to a destination cluster in Amazon FSx for ONTAP, you need to break the SnapMirror relationship to use Amazon FSx for ONTAP as a read/write volume (SnapMirror destination volumes are read-only until the relationship is broken).

Run the following command to ensure that the transfer is complete. Verify that Mirror State is Snapmirrored, and Relationship Status is Idle. You also should ensure that the Last Transfer End Timestamp is recent, as it reflects the recency of data on the destination volume.

FSx-Dest::> snapmirror show -fields state,status,last-transfer-end-timestamp

Source     Destination   Mirror        Relationship Last Transfer End  
Path       Path          State         Status       Timestamp
---------- -----------   ----------    -------      --------------- 
Svm01:vol1 svm02:DestVol Snapmirrored  Idle         09/02 09:02:21

You then need to disable any future SnapMirror transfers by using the quiesce command:

FSx-Dest::> snapmirror quiesce -destination-path <DestSVM>:vol1

Verify that the Relationship Status has changed to Quiesced using snapmirror show:

FSx-Dest::> snapmirror show

Source           Destination   Mirror        Relationship
Path             Path          State         Status
-----------      ------------  ------------- --------
sourcesvm1:vol1  svm01:DestVol Snapmirrored  Quiesced

Once this has been verified, the SnapMirror relationship can be broken by using the following command:

FSx-Dest::> snapmirror break -destination-path <DestSVM>:vol1

Operation succeeded: snapmirror break for destination "DestSVM:vol1".

Now the volume is available with the data from the source volume fully mirrored to the destination volume and available for read/write. To make this data accessible to clients and applications, you need to mount NAS shares (SMB/NFS) or iSCSI LUNs.

NetApp Cloud Sync

NetApp Cloud Sync uses NetApp Data Broker to sync data from a source to a target (this is called a sync relationship). Data Broker controls the sync relationships between sources and targets. After setting up a sync relationship, Cloud Sync analyzes source data, breaks it into multiple replication streams, and pushes it to the target in a highly parallelized fashion to optimize bandwidth utilization. After the initial copy, the service syncs any changed data based on the schedule you configure. Cloud Sync is part of NetApp Cloud Manager.

NetApp XCP

NetApp XCP is a free offering by NetApp that is compatible with NFS and SMB (CIFS) protocols. You can use it to migrate data from on-premises storage (ONTAP or otherwise) to Amazon FSx for NetApp ONTAP. XCP supports live data migration, syncing, and additionally comes with XCP File Analytics, providing a dashboard where you can view file insights. XCP is client software installed on a Linux or Windows host that has the source and destination volumes mounted, with commands run on the host to facilitate data migration.

Native tools: Robocopy and rsync

Robocopy and rsync are native CLI tools available in Windows and in Linux/macOS respectively. Both solutions require a host that has both the source and destination volumes mounted, with the Windows or Linux/macOS host executing the Robocopy or rsync commands respectively.

Offline migration with AWS Snow Family

If you have limited bandwidth or have unreliable or no internet connectivity, the AWS Snow Family can support your offline migration with speeds faster than the internet.

It can take months to migrate large amounts of data through the internet, even with high-speed connectivity. For example, transferring 100 TB on a reliable 100-Mbps connection can take over 100 days to complete, while limiting the bandwidth available for other purposes. You can accomplish the same transfer in less than one day, plus shipping time, using two AWS Snowball Edge devices.

Saving data transfer time is not the sole application of the AWS Snow Family. It is additionally the recommended method of transfer from locations where a WAN connection is unreliable or unavailable, when metering is in effect, or when there are legacy environment challenges that would complicate online transfer.

The AWS Snow Family consists of AWS Snowcone, AWS Snowball Edge, and AWS Snowmobile. Each offering comes with a varying amount of capacity and built-in compute capabilities. Snow Family devices are owned and managed by AWS and integrate with AWS security, monitoring, storage management, and computing capabilities.

We will follow up with another blog covering best practices on migration to Amazon FSx for NetApp ONTAP using AWS Snow Family. In the meantime, you can check out these blog posts on migration using Snowball Edge: “Data migration using AWS Snowball Edge,” and “Best practices for accelerating data migration with AWS Snowball Edge.”

Conclusion

In this blog, we provided an overview of the online and offline migration options you can use to migrate your data to Amazon FSx for NetApp ONTAP, with a full guide for on-premises ONTAP migration using SnapMirror.

Online migration is best suited for smaller amounts of data with a reliable, high-bandwidth connection. Offline migration is best suited for very large amounts of data or from locations with connection limitations. With an understanding of the different migration technologies available to you and their tradeoffs, you can better plan a simple, easy, and successful migration to Amazon FSx for NetApp ONTAP.

For more information, refer to the Amazon FSx for NetApp ONTAP documentation. If you are still unsure what your best option is for migration, talk to your AWS account team.

Thank you for reading this blog post! If you have any comments or questions, don’t hesitate to leave them in the comments section.