Limites de configuration et prise en charge des baies SAN 100 % Flash
Suggérer des modifications
PDF
Les limites de configuration et la prise en charge varient en fonction de la ONTAP version du système ASA.
Les détails les plus récents sur les limites de configuration prises en charge sont disponibles dans "NetApp Hardware Universe".
|
Ces limitations s'appliquent aux systèmes ASA actuels. Si vous disposez d'un système ASA r2 (ASA A1K, ASA A70 ou ASA A90), reportez-vous à la section "Limites de stockage du système ASA r2". |
Protocoles SAN et nombre de nœuds pris en charge par cluster
Les protocoles SAN pris en charge et le nombre maximum de nœuds par cluster dépendent de votre configuration non MetroCluster ou MetroCluster :
Le tableau suivant présente la prise en charge des protocoles SAN par ASA et le nombre de nœuds pris en charge par cluster dans des configurations non MetroCluster :
| Depuis ONTAP… | Protocoles pris en charge | Nombre maximal de nœuds par cluster |
|---|---|---|
9.11.1 |
|
12 |
9.10.1 |
|
2 |
9.9.1 |
|
2 |
|
12 |
|
9.7 |
|
2 |
Le tableau ci-dessous présente la prise en charge des protocoles SAN par ASA et le nombre de nœuds pris en charge par cluster dans les configurations MetroCluster IP :
| Depuis ONTAP… | Protocoles pris en charge | Nombre maximal de nœuds par cluster |
|---|---|---|
9.15.1 |
|
2 nœuds par cluster dans des configurations IP MetroCluster à quatre nœuds |
9.12.1 |
|
2 nœuds par cluster dans des configurations IP MetroCluster à quatre nœuds |
9.9.1 |
|
4 nœuds par cluster dans des configurations IP MetroCluster à 8 nœuds |
9.7 |
|
2 nœuds par cluster dans des configurations IP MetroCluster à quatre nœuds |
Prise en charge des ports persistants
Depuis la version ONTAP 9.8, les ports persistants sont activés par défaut sur les baies SAN 100 % Flash (ASA) configurées pour utiliser le protocole FC. Les ports persistants sont uniquement disponibles pour FC et requièrent l'appartenance de zone identifiée par WWPN (World Wide Port Name).
Les ports persistants réduisent l'impact des basculements en créant une LIF « shadow » sur le port physique correspondant du partenaire haute disponibilité. Lorsqu'un nœud est repris, la LIF shadow sur le nœud partenaire assume l'identité du LIF d'origine, y compris le WWPNe. Avant que le chemin d'accès au nœud mis en service ne soit modifié en défectueux, le shadow LIF apparaît sous la forme d'un chemin actif-optimisé vers la pile MPIO hôte, ainsi que de transferts d'E/S. Cela réduit les perturbations d'E/S car l'hôte voit toujours le même nombre de chemins vers la cible, même lors des opérations de basculement de stockage.
Pour les ports persistants, les caractéristiques de port FCP suivantes doivent être identiques dans la paire haute disponibilité :
-
Nombre de ports FCP
-
Noms des ports FCP
-
Vitesses du port FCP
-
Segmentation basée sur le WWPN FCP LIF
Si l'une de ces caractéristiques n'est pas identique au sein de la paire HA, le message EMS suivant est généré :
EMS : scsiblade.lif.persistent.ports.fcp.init.error
Pour plus d'informations sur les ports persistants, reportez-vous à la section "Rapport technique de NetApp 4080 : meilleures pratiques pour le SAN moderne".