Migrating file shares to Amazon FSx for NetApp ONTAP using AWS DataSync

When planning a data migration you need to evaluate migration tools, determine whether you have the available bandwidth for an online migration and understand the characteristics of the source and target destination. There are situations where you may be looking to migrate data from on-premises storage or other AWS storage services to Amazon FSx for NetApp ONTAP and are not coming from a NetApp ONTAP source or do not have a SnapMirror license. When migrating to FSx for NetApp ONTAP you need to factor in the characteristics of volume data tiering policies as part of your migration strategy.

Amazon FSx for NetApp ONTAP file systems have two storage tiers: primary storage and capacity pool storage. Primary storage is provisioned, high-performance solid state drive (SSD) storage for the active or latency-sensitive portion of your dataset. Capacity pool storage is a fully elastic storage tier that can scale to petabytes in size and is cost-optimized for the infrequently accessed portion of your data. When you create an Amazon FSx for NetApp ONTAP file system, you set the level of provisioned SSD capacity you have. You can increase this after your file system is created, but you cannot decrease it.

In general, it’s recommended to not consume greater than 80% of your SSD tier capacity at any time. But what happens if your dataset that’s being migrated is greater than your allocated SSD primary tier capacity?

In this post, I explain how different policies can affect your migration and look at some techniques to ensure you are taking your primary storage capacity into consideration.

Get to know your volume data tiering policies

Amazon FSx for NetApp ONTAP automatically transitions data between your system’s SSD and capacity pool storage tiers, based on your data access patterns. With data tiering, you can achieve SSD levels of performance for your workload while paying for SSD storage for only a small fraction of your data. As a result, you need to provision primary SSD storage only for the active portion of your dataset, with the rest of your data stored in lower-cost capacity pool storage.

Each volume in your Amazon FSx for NetApp ONTAP file system has a data tiering policy associated with it. This tiering policy determines how the data within that volume is transitioned between the primary tier and the capacity pool tier. You can choose from one of four tiering policies outlined in the FSx for NetApp ONTAP managing volumes documentation. In this post, I focus on the Auto and All policies for migrations.

• Auto moves cold user data blocks in both the active file system and the snapshot copies to the storage pool tier. If data is read from the capacity pool tier in a random fashion, the cold data blocks in the capacity tier become hot and move to the primary storage tier. If read by sequential reads, such as those associated with index and antivirus scans, the cold data blocks stay cold and do not move to the primary storage tier.
• All moves cold user data blocks in both the snapshot copies and the active file system to the storage pool tier. If read, cold data blocks on the storage pool tier stay cold and are not written back to the primary storage tier.

You can set a specific cooling period for the Snapshot Only and Auto policies that range from 2–183 days with a default of 2 days and 31, respectively.

Amazon FSx for NetApp ONTAP data migrations can have a tiering policy set to All

In designing for a balance of performance and cost, many customers choose to migrate data into volumes that have the tiering policy set to All. This enables customers to size the primary tier (i.e., SSD) smaller than the dataset being migrated, which allows the majority of the data to end up in the capacity tier. Setting the tiering policy to All marks all data blocks as cold and moves the data to the capacity tier without a cooling period.

When performing a data migration into an Amazon FSx for NetApp ONTAP volume, you are writing directly into the SSD primary storage tier. Knowing how the volume tiering policies affect the system is important so you don’t keep that migrated data in SSD, which takes up valuable space in your high-performance primary tier!

For example, if you were to keep a volume tiering policy set to Auto, that migrated data would stay in the primary storage tier for a minimum of 31 days unless you changed the default cooling period. Even if you could fit all the migrated data within the 80% recommended capacity, you should immediately consider if you want to keep that data in the performance tier or let the system know when to move the data based on access patterns. Once your migration is complete, you can then set the policy back to Auto to allow your active data to move and stay in the primary storage tier.

You can start your migration with AWS DataSync by creating a source location for your on-premises storage system or storage service and an FSx for NetApp ONTAP destination location.

Figure 1 is an example using AWS DataSync for a data migration to FSx for NetApp ONTAP configured with a throughput capacity of 512 MB/s and a destination volume policy set to All. This migration used a source dataset of random data consisting of 1-GB files making up 1.1 TiB in total. The destination file system has a provisioned SSD tier of 1540 GiB with an available capacity of 1.37 TiB targeting a 2-TB volume. The data I am migrating fits within the available primary storage. This migration achieved an average of 450 MiB/s, and you can see that the primary storage tier capacity is consumed, as indicated by the green line while data is simultaneously migrated to the capacity tier as indicated by the red line.

Figure 1 shows the primary storage tier usage of an Amazon FSx for NetApp ONTAP filesystem during a data migration that fits within the allocated primary storage capacity.

Racing against writes

Of course, the goal is to perform your data migration as quickly and efficiently as possible. However, even with a tiering policy set to All, if your dataset is larger than your available primary storage capacity there is the possibility you write faster than the policy can move the incoming data to the capacity tier. Your ability to consume the primary tier has a number of factors, such as how fast you can read from the source file system, the number and size of the source files, your network bandwidth, and the provisioned throughput capacity of the destination FSX for NetApp ONTAP file system.

Let’s look at another migration use case with a configuration like the previous example. However, this time the available primary storage capacity is only 910 GiB, which is less than the 1.1-TiB dataset. Using AWS DataSync this migration averaged 472 MiB/s of data throughput, which exhausts the primary tier under the recommended 80% free capacity as seen in figure 2. Consuming the tier to a 90% threshold prevents active data being read from moving into the primary tier and is close to the 98% threshold where all tiering operations stop entirely. Filling the performance tier can affect performance of other running applications as well as the data migration itself.

Figure 2 shows the primary storage tier usage of an FSX for NetApp ONTAP filesystem during a data migration that does not fit within the allocated primary storage capacity

In an ideal scenario, you could increase the SSD capacity for your migration but that may end up adding cost for performance you won’t use after. In addition, the current limit of the SSD tier is 192 TiB, which could become the limiting factor for your migration if your dataset is greater than 192 TiB.

AWS DataSync provides a feature to limit bandwidth for each individual task execution allowing you to control how fast you can ingest data into the performance tier, which provides time for incoming data to be transitioned to the capacity tier.

For the last migration scenario, I migrate a 27-TiB dataset to an undersized SSD tier with 1.37 TiB available targeting a 33-TB volume. However, this time I configure the DataSync task with a bandwidth throttle of 100 MiBs. Now when monitoring the primary storage capacity, you can see that the bandwidth throttle allows the tiering policy to keep up with the incoming writes allowing us to avoid consuming 80% of the performance tier.

Figure 3 shows the primary storage tier usage of an Amazon FSx for NetApp ONTAP filesystem during a data migration that is bandwidth limited and does not fit within the allocated primary storage capacity.

Configuring the bandwidth limit for DataSync can be dynamically changed during an in-progress task execution. This provides the ability to adjust the throttle based on how fast Amazon FSx for NetApp ONTAP is writing to the capacity tier. In figure 3, you see a period where there is a higher fluctuation of usage in primary storage capacity. During that window, the bandwidth limit of the DataSync task execution was changed to 200 MiB/s. The bandwidth limit was then set back to 100 MiBs for the remainder of the migration. FSX for NetApp ONTAP provides detailed metrics so you can calculate writes to the capacity tier over a time duration during your migration to dial in the bandwidth limit settings.

Conclusion

In this post, I discussed the differences between the primary storage and capacity tier in an Amazon FSx for NetApp ONTAP file system and the different effects volume data tiering policies have on the primary storage tier. I talked about considerations for planning a data migration and taking the available capacity of the performance tier into account.

I then walked through some examples of using AWS DataSync to migrate to FSx for NetApp ONTAP where the migrated dataset is less than the available primary storage tier, as well as a scenario of how a migration can consume the entire primary storage tier. I then showed how to use bandwidth throttling along with configuring your volume tiering policies to All can balance primary storage tier consumption with the capacity tier.

Using these techniques can assist your planning and help complete your data migrations while maintaining sufficient capacity in your primary storage tier for normal operations, minimizing downtime or disruption of your key workloads.

Get your Amazon FSx for NetApp ONTAP migrations started today using AWS DataSync.