Announced in September 2021 as the newest file system offering for AWS FSx, alongside Windows File Server, OpenZFS, and Lustre, NetApp ONTAP is bringing its versatile and scalable feature set to the cloud. At its core, FSx for NetApp ONTAP is storage software that runs on AWS infrastructure, services we all know and love like EBS and S3, to integrate its native features seamlessly within the AWS platform for better ease of use in your environment.
How is FSx for NetApp ONTAP different from other flavors?
You can expect excellent performance from all the FSx offerings, such as sub-millisecond latency, built-in data compression, and a long list of compliance and certification compatibility. FSx for NetApp stands out from the others with its supported protocols, NFS, SMB, and iSCSI, its virtually unlimited storage space, and the fact that it is currently the only FSx flavor with anti-virus integration. Above that, NetApp is a very feature-rich tool, with built-in tools like SnapMirror for disaster recovery, backups and cross-region replication, auto-sizing volumes, Capacity Pool Tiering, and more.
NetApp ONTAP – file system breakdown
Starting from scratch with FSx for NetApp ONTAP in the AWS Console, the second option to fill in after Name with both Quick Create and Standard Create is SSD Storage Capacity, with a range of 1024 GiB to 192 TiB. This SSD is not referencing the storage capacity of the file system, rather it is related to the performance of the file system itself, as well as the Performance storage tier. It should be set to a minimum of 10% of the total storage used or needed on the file system, and it can be increased after creation, based on the needs of your workload.
Once you have the NetApp cluster created, a Storage Virtual Machine (SVM) will have been created and attached to the cluster. This SVM is what will be referred to in the NetApp CLI as the ‘VServer’, which is needed to set up a peering connection between clusters down the road, so a logical and workable name is helpful. Inside this VServer is where the volumes, NetApp's version of a folder or share, will be built. Volumes are storage partitions of an Aggregate, the raw, physical storage space, that can be created and modified to fit your workload's needs, including the ability to auto-size based on the percent of the total volume being utilized. Auto-sizing as a feature allows for a volume to have its minimum and maximum size set, in KB, MB, GB or TB, growing, shrinking, or both (depending on the selected mode) when the utilized space crosses the min-max-percent-threshold. Auto-sizing gives the freedom to use a volume as a simple landing zone for a client migrating into AWS, with no added stress of whether or not the provisioned volume size will work.
For example, let's start with a 1 TiB SSD for the file system, giving appropriate performance for up to 10 TiB. A client needs to migrate data into a single volume over the course of two months, data totaling 12 TiB. Once the volume is created, auto-size can be set with a maximum volume size of 12 TiB, a minimum volume size of 1 TiB, a maximum percent threshold of 80%, and a minimum percent threshold of 60%. The volume on creation will shrink down to 1 TiB, the minimum size until a data transfer begins when the volume auto-grows to allow for the transfer to complete and the volume to be between 60-80% utilized. Once the total volume size begins to get close to 10 TiB, the SSD of the file system can be updated to 1.2 TiB or even 2 TiB to allow for more headroom on performance. This ensures that file system performance doesn't take a dip when the total storage on the system breaks 10 TiB.
NetApp ONTAP – feature-rich storage management
NetApp ONTAP comes with a long list of built-in features externally, bringing functionality to a wide range of workloads for situations when caching may be needed, either on-premises or in the cloud, or backups and disaster recovery are crucial.
NetApp Global File Cache (GFC) extends the storage footprint of the volumes in AWS into offices globally, removing the need for in-office backups, increasing productivity, and consolidating on-premises infrastructure, all while staying high-performant for the end user. NetApp FlexCache operates similarly, though it is focused more on caching read-intensive data for applications or multiple locations operating on the same data, removing the excess of a global solution when a regional or more local solution is necessary.
Capacity Pool Tiering comes ready in FSx for NetApp ONTAP, configurable in the AWS Console at the creation of the file system, moving data from active storage, the Performance tier, to inactive storage, the Capacity tier. Setting the tiering policy to ALL will mark data, without metadata, as cold and move it to the Capacity tier as it hits the volume, while AUTO and SNAPSHOT ONLY begin to mark data as cold when the aggregate has reached 50% capacity. Once the aggregate reaches 50%, the internal timer begins and will view data and mark inactive data as cold after the cooldown period. By default, this period is 31 days for AUTO and two days for SNAPSHOT ONLY and can be configured to be between 2 days and 183 days.
NetApp SnapMirror is a feature allowing for replication of a Source Volume to a Destination Volume, either within the same file system or between two, asynchronously (at regular, configurable intervals), synchronously (immediately), or semi-synchronously (synchronously but with a 10 second lag behind the Source Volume, allowing for more optimized performance). After a peering relationship has been configured between clusters and then vservers, SnapMirror will be created and initialized from the Destination cluster, effectively looking for and then pulling data from the Source, based on the configured schedule. Volume auto-sizing works with SnapMirror, allowing for seamless cross-region replication into a disaster recovery volume that is constantly tiering data into cold storage, optimizing savings and maintenance as your source volume grows.
NetApp ONTAP – migration use case
A client with 350-400 TB of data on a SAN needs to move into AWS, ultimately planning to land in S3 as their storage platform but needing something functionally similar to a SAN while their application is updated to support S3. One FSx for Windows File Server cluster is created for each segment of data, Archive, Logs, PrimaryShare1 and 2, WorkingLib1 and 2, leaving six total FSx clusters with varying total sizes and throughputs set, all managed through Active Directory. In the time leading up to a Snowball arriving at the data center, the on-prem SAN approaches a critical storage utilization (90-95%), forcing data to be pushed over the wire into AWS, and an FSx for NetApp ONTAP cluster is created to catch the data. The simplicity of standing up the cluster, customizing and managing the volume, creating a disaster recovery volume in a different region, and seamlessly SnapMirroring data onto it forced a conversation about moving the existing six Windows’ clusters into NetApp. Once the decision was made and an official list of volumes to be created and SnapMirrored was handed off, the volumes could be created, configured to auto-size and with SnapMirror, mounted as Shares in Active Directory, and ready to receive data within the hour. Comparing the potential cost of ~$60,000USD/month for the Windows’ clusters to ~$13,000USD/month of the NetApp cluster, on top of the incredible lack of maintenance and overhead required, FSx for NetApp ONTAP has become our new first recommendation for FSx clusters. We are only scratching the surface of what we believe NetApp will be able to do for our clients and us.
