ONTAP is a robust and versatile storage platform, known for its comprehensive feature set and adaptability to a wide range of storage requirements. While this flexibility makes it an excellent choice for organizations with diverse workloads, some customers can benefit from a more tailored storage solution optimized for the needs of their specific environment.

To address these specialized needs, some NetApp storage systems offer distinct ONTAP personalities, each of which includes a feature set designed to support the unique customer requirements. An ONTAP personality is typically a combination of hardware and software capabilities and purpose-built to deliver an optimized experience for targeted use cases. NetApp provides three ONTAP personalities:

By offering these distinct ONTAP personalities, NetApp enables organizations to select a storage solution aligned with their operational requirements and application workloads.

No. The personality of your ONTAP storage system is immutable and cannot be changed. For example, you cannot convert or upgrade a FAS or AFF storage system (which run the Unified ONTAP personality) to an AFX storage system.

In System Manager, select Cluster in the left navigation pane and then Overview. You'll see the personality displayed on the page. As an alternative, you can issue the command "system node show" at the CLI. You can also determine the personality of an ONTAP cluster using the REST API; see Your first AFX system REST API call for details.

The term "disaggregated" can have two different though related meanings with AFX depending on the context.

An important concept to begin with is the decoupling of the compute capability in the controller nodes from the storage shelves. With AFX, the cluster compute and storage components are no longer tightly coupled as they are with FAS and AFF systems, which run the Unified ONTAP personality. Instead they are connected through cluster switches. Each AFX node controller has a complete view of the entire cluster storage pool.

The second related concept with disaggregated storage is that the aggregates and RAID management are removed as administrable entities. A storage abstraction layer within AFX automatically configures and manages the low-level aspects of storage, including the physical disks and RAID groups. This allows the AFX administrator to focus on the high-level storage configuration based on volumes and buckets.

No. Each ONTAP personality is different. For example, you cannot mix AFX and Unified ONTAP nodes in the same cluster.

The SnapMirror version rules for AFX are identical to Unified ONTAP. This means that to replicate from Unified ONTAP, the source system must be within the supported version range. To replicate from AFX, the Unified ONTAP system must be at ONTAP 9.16.1 or later (the earliest release the Advanced Capacity Balancing feature is supported). For FlexCache, the same rules apply for source and destination systems as described in TR-4743.

There are some differences in the support for FlexGroup volumes. A FlexGroup volume on AFX cannot be an origin volume for a FlexCache volume using the Writeback mode.

No. Only the ONTAP REST API is supported with AFX. Any automation code that uses ZAPI needs to be converted to the REST API for use with AFX.

The data protocols supported with AFX include the following:

No. The data protocols in AFX operate the same way as with AFF and FAS systems.

No. ADP is not used with AFX. Because there are no root aggregates with AFX, the ADP feature is not needed to maximize disk space efficiency.

No. Only switches specifically approved for and provided with the AFX storage platform are supported for the backend network.

All the disks and storage shelves attached to an AFX cluster are part of a Storage Availability Zone (SAZ). Each AFX cluster supports only one SAZ which cannot be shared across AFX clusters (except for SnapMirror replication and FlexCache operations).

Every node has visibility to all the storage in the SAZ. When storage shelves are added to a cluster, ONTAP automatically adds the disks.

With Unified ONTAP, it is possible to relocate a volume nondisruptively from one node or aggregate to another in the cluster. This is performed using a background copy operation with SnapMirror technology, where a new destination volume is created at the new location. Depending on the size of the volume and the utilization of cluster resources, the time it takes for a volume move to complete can vary.

With AFX, there are no aggregates. All storage is contained within a single Storage Availability Zone that's accessible by every node in the cluster. As a result, volume moves never need to actually copy the data. Instead, all volume moves are performed with pointer updates between nodes. This is referred to as a Zero Copy Volume Move (ZCVM) and happens instantaneously because no data is actually copied or moved. This is essentially the same volume move process used with Unified ONTAP without the SnapMirror copy.

Note that in the initial release, volumes will move only in storage failover scenarios and when nodes are added or removed from the cluster. These moves are controlled only through ONTAP.

AFX includes a feature known as Automated Topology Management (ATM) which responds to system and user object imbalances. The primary objective of ATM is to balance volumes across the AFX cluster. When an imbalance is detected, an internal job is triggered to evenly distribute the data across the active nodes. The data is reallocated using ZCVM which only needs to copy and update the object metadata.