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
A complete list of feature comparisons is given in the following table:
|NetApp Cloud Sync
|NetApp XCP, Robocopy/rsync
|How to install
|Native ONTAP feature*
|Cloud Manager integrated
XCP is client software offered for free by NetApp
Robocopy/Rsync are OS native
|NFS, SMB, iSCSI
|ONTAP 9.6+ supports encryption
|NFS and Object data transfer supports encryption; SMB does not.
|Supported when encryption is enabled on source and destination
|Licensed per cluster
|Pay as you go
|Block-level replication, which provides the fastest transfer speeds.
1. Fully managed end-to-end transfer.
2. Only service that supports object-based migration.
|XCP File Analytics provides insights into the filesystem.
|Best use case scenario
1. When data frequently changes between source and destination.
2. When file structure is complex with millions of small files sizes.
|GUI-based managed migration experience offers the simplest migration after SnapMirror.
|Robocopy and rsync are built into Windows and Linux/macOS respectively, enabling migration without additional software
*Requires SnapMirror license for on-premises ONTAP file systems
Figure 2: Amazon FSx for ONTAP online-migration architecture
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-Destis the destination cluster’s identifier (
OnPrem-Sourceis the source cluster’s identifier.
DestSVMis the destination SVM name.
SourceSVMis the source SVM name.
- Both the source and destination volume names are
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_2. We refer to these for FSx-Dest as
dest_inter_2 and for OnPrem-Source as
3. Establish cluster peering between source and destination
Establish a cluster peer relationship on the destination cluster by providing
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_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
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
<SourceLocalName>as the name the source SVM goes by on the destination cluster, we called it
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::> 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
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
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
FSx-Dest::> snapmirror quiesce -destination-path <DestSVM>:vol1
Verify that the
Relationship Status has changed to
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 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.”
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.