Skip to main content
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Limiti di configurazione e supporto degli array SAN all-flash

Collaboratori

I limiti di configurazione e il supporto degli array SAN all-flash (ASA) variano in base alla versione di ONTAP.

I dettagli più aggiornati sui limiti di configurazione supportati sono disponibili in "NetApp Hardware Universe".

Protocolli SAN e numero di nodi supportati per cluster

I protocolli SAN supportati e il numero massimo di nodi per cluster dipendono dalla configurazione non MetroCluster o MetroCluster:

Configurazioni non MetroCluster

La tabella seguente mostra il supporto ASA per i protocolli SAN e il numero supportato di nodi per cluster nelle configurazioni non MetroCluster:

Inizio con ONTAP…​ Supporto del protocollo Numero massimo di nodi 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

Configurazioni IP MetroCluster

La tabella seguente mostra il supporto di ASA per i protocolli SAN e il numero supportato di nodi per cluster nelle configurazioni IP di MetroCluster:

Inizio con ONTAP…​ Supporto del protocollo Numero massimo di nodi per cluster

9.15.1

  • NVMe/TCP

2 nodi per cluster in configurazioni MetroCluster IP a quattro nodi

9.12.1

  • NVMe/FC

2 nodi per cluster in configurazioni MetroCluster IP a quattro nodi

9.9.1

  • FC

  • ISCSI

4 nodi per cluster in configurazioni MetroCluster IP a 8 nodi

9.7

  • FC

  • ISCSI

2 nodi per cluster in configurazioni MetroCluster IP a quattro nodi

Supporto per porte persistenti

A partire da ONTAP 9,8, le porte persistenti sono abilitate per impostazione predefinita sugli array All-Flash SAN (ASA) configurati per utilizzare il protocollo FC. Le porte persistenti sono disponibili solo per FC e richiedono l'appartenenza alla zona identificata dal World Wide Port Name (WWPN).

Le porte persistenti riducono l'impatto dei takeover creando una LIF ombra sulla porta fisica corrispondente del partner ad alta disponibilità (ha). Quando un nodo viene sostituito, la LIF shadow sul nodo partner assume l'identità della LIF originale, inclusa la WWPNe. Prima che lo stato del percorso verso il nodo preso in consegna venga modificato in difettoso, la LIF shadow viene visualizzata come percorso attivo/ottimizzato verso lo stack MPIO host e l'i/o viene spostato. In questo modo si riducono le interruzioni di i/o perché l'host rileva sempre lo stesso numero di percorsi verso la destinazione, anche durante le operazioni di failover dello storage.

Per le porte persistenti, le seguenti caratteristiche della porta FCP devono essere identiche all'interno della coppia ha:

  • Numero di porte FCP

  • Nomi delle porte FCP

  • Velocità delle porte FCP

  • Zoning basato su WWPN FCP LIF

Se una di queste caratteristiche non è identica all'interno della coppia ha, viene generato il seguente messaggio EMS:

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

Per ulteriori informazioni sulle porte persistenti, vedere "Report tecnico NetApp 4080: Best practice per le SAN moderne".