Skip to main content

All-Flash SAN Array configuration limits and support

Contributors netapp-aoife netapp-aherbin netapp-revathid netapp-ahibbard
PDFs

All-Flash SAN Array (ASA) configuration limits and support varies by ONTAP version.

The most current details on supported configuration limits are available in NetApp Hardware Universe.

Note These limitations apply to current ASA systems. If you have an ASA r2 system (ASA A1K, ASA A70, or ASA A90), see ASA r2 system storage limits.

SAN protocols and supported number of nodes per cluster

The supported SAN protocols and maximum number of nodes per cluster depends on whether you have a non-MetroCluster or MetroCluster configuration:

Non-MetroCluster configurations

The following table shows the ASA support for SAN protocols and the supported number of nodes per cluster in non-MetroCluster configurations:

Beginning with ONTAP…​ Protocol support Maximum nodes per cluster

9.11.1

  • NVMe/TCP

  • NVMe/FC

12

9.10.1

  • NVMe/TCP

2

9.9.1

  • NVMe/FC

2

  • FC

  • iSCSI

12

9.7

  • FC

  • iSCSI

2
MetroCluster IP configurations

The following table shows the ASA support for SAN protocols and the supported number of nodes per cluster in MetroCluster IP configurations:

Beginning with ONTAP…​ Protocol support Maximum nodes per cluster

9.15.1

  • NVMe/TCP

2 nodes per cluster in four-node MetroCluster IP configurations

9.12.1

  • NVMe/FC

2 nodes per cluster in four-node MetroCluster IP configurations

9.9.1

  • FC

  • iSCSI

4 nodes per cluster in eight-node MetroCluster IP configurations

9.7

  • FC

  • iSCSI

2 nodes per cluster in four-node MetroCluster IP configurations

Support for persistent ports

Beginning with ONTAP 9.8, persistent ports are enabled by default on All-Flash SAN Arrays (ASAs) that are configured to use the FC protocol. Persistent ports are only available for FC and require zone membership identified by World Wide Port Name (WWPN).

Persistent ports reduce the impact of takeovers by creating a shadow LIF on the corresponding physical port of the high-availability (HA) partner. When a node is taken over, the shadow LIF on the partner node assumes the identity of the original LIF, including the WWPNe. Before the status of path to the taken over node is changed to faulty, the shadow LIF appears as an Active/Optimized path to the host MPIO stack, and I/O is shifted. This reduces I/O disruption because the host always sees the same number of paths to the target, even during storage failover operations.

For persistent ports, the following FCP port characteristics should be identical within the HA pair:

  • FCP port counts

  • FCP port names

  • FCP port speeds

  • FCP LIF WWPN-based zoning

If any of these characteristics are not identical within the HA pair, the following EMS message is generated:

EMS : scsiblade.lif.persistent.ports.fcp.init.error

For more information on persistent ports, see NetApp Technical Report 4080: Best Practices for Modern SAN.