Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Remplacez les commutateurs de cluster Cisco Nexus 3132Q-V par des connexions sans commutateur

Contributeurs netapp-yvonneo netapp-karunesh
PDF

Dans ONTAP 9.3 et versions ultérieures, vous pouvez migrer d'un cluster avec un réseau de cluster commuté vers un cluster où deux nœuds sont directement connectés.

Remarque

NetApp recommande de mettre à jour votre version ONTAP avant de procéder à la conversion d'un cluster commuté en cluster sans commutateur pour les commutateurs Cisco Nexus 3132Q-V.

Voir ce qui suit pour plus de détails :

Vous pouvez migrer d'un cluster avec un réseau de cluster commuté vers un cluster où deux nœuds sont directement connectés pour ONTAP 9.3 et versions ultérieures.

Exigences de révision

Lignes directrices

Veuillez consulter les directives suivantes :

  • La migration vers une configuration de cluster sans commutateur à deux nœuds est une opération non perturbatrice. La plupart des systèmes disposent de deux ports d'interconnexion de cluster dédiés sur chaque nœud, mais vous pouvez également utiliser cette procédure pour les systèmes comportant un plus grand nombre de ports d'interconnexion de cluster dédiés sur chaque nœud, tels que quatre, six ou huit.

  • Vous ne pouvez pas utiliser la fonction d'interconnexion de cluster sans commutateur avec plus de deux nœuds.

  • Si vous disposez d'un cluster existant à deux nœuds utilisant des commutateurs d'interconnexion de cluster et exécutant ONTAP 9.3 ou une version ultérieure, vous pouvez remplacer les commutateurs par des connexions directes et dos à dos entre les nœuds.

Avant de commencer

Assurez-vous d'avoir les éléments suivants :

  • Un cluster sain composé de deux nœuds connectés par des commutateurs de cluster. Les nœuds doivent exécuter la même version ONTAP .

  • Chaque nœud dispose du nombre requis de ports de cluster dédiés, qui fournissent des connexions d'interconnexion de cluster redondantes pour prendre en charge la configuration de votre système. Par exemple, un système comporte deux ports redondants et deux ports d'interconnexion de cluster dédiés sur chaque nœud.

Déplacer les commutateurs

À propos de cette tâche

La procédure suivante supprime les commutateurs de cluster dans un cluster à deux nœuds et remplace chaque connexion au commutateur par une connexion directe au nœud partenaire.

Les commutateurs de cluster ont été remplacés par des connexions directes.
À propos des exemples

Les exemples de la procédure suivante montrent des nœuds qui utilisent « e0a » et « e0b » comme ports de cluster. Vos nœuds peuvent utiliser des ports de cluster différents, car ceux-ci varient selon le système.

Étape 1 : Préparer la migration

  1. Modifiez le niveau de privilège en avancé, puis saisissez y lorsqu'on vous invite à continuer :

    set -privilege advanced

    L'invite avancée *> apparaît.

  2. ONTAP 9.3 et versions ultérieures prennent en charge la détection automatique des clusters sans commutateur, qui est activée par défaut.

    Vous pouvez vérifier que la détection des clusters sans commutateur est activée en exécutant la commande avec privilèges avancés :

    network options detect-switchless-cluster show

    Afficher un exemple

    L'exemple de résultat suivant indique si l'option est activée.

    cluster::*> network options detect-switchless-cluster show
   (network options detect-switchless-cluster show)
Enable Switchless Cluster Detection: true

    Si « Activer la détection de cluster sans commutateur » est false , contactez le support NetApp .

  3. Si AutoSupport est activé sur ce cluster, supprimez la création automatique de cas en envoyant un message AutoSupport :

    system node autosupport invoke -node * -type all -message MAINT=<number_of_hours>h

    où h Il s'agit de la durée de la fenêtre de maintenance en heures. Ce message informe le support technique de cette tâche de maintenance afin qu'il puisse désactiver la création automatique de tickets pendant la période de maintenance.

    Dans l'exemple suivant, la commande désactive la création automatique de cas pendant deux heures :

    Afficher un exemple 
    cluster::*> system node autosupport invoke -node * -type all -message MAINT=2h

Étape 2 : Configurer les ports et le câblage

  1. Organisez les ports de cluster de chaque commutateur en groupes de sorte que les ports de cluster du groupe 1 soient connectés au commutateur de cluster 1 et les ports de cluster du groupe 2 au commutateur de cluster 2. Ces groupes seront nécessaires plus tard dans la procédure.

  2. Identifiez les ports du cluster et vérifiez l'état et la santé des liaisons :

    network port show -ipspace Cluster

    Dans l'exemple suivant pour les nœuds avec des ports de cluster « e0a » et « e0b », un groupe est identifié comme « node1:e0a » et « node2:e0a » et l'autre groupe comme « node1:e0b » et « node2:e0b ». Vos nœuds peuvent utiliser des ports de cluster différents car ils varient selon le système.

    Les connexions de commutation du cluster entre le nœud 1 et le nœud 2

    Vérifiez que les ports ont une valeur de up pour la colonne « Lien » et une valeur de healthy pour la colonne « État de santé ».

    Afficher un exemple 
    cluster::> network port show -ipspace Cluster
Node: node1
                                                                 Ignore
                                             Speed(Mbps) Health  Health
Port  IPspace   Broadcast Domain Link  MTU   Admin/Oper	 Status  Status
----- --------- ---------------- ----- ----- ----------- ------- -------
e0a   Cluster   Cluster          up    9000  auto/10000  healthy false
e0b   Cluster   Cluster          up    9000  auto/10000  healthy false

Node: node2
                                                                 Ignore
                                             Speed(Mbps) Health  Health
Port  IPspace   Broadcast Domain Link  MTU   Admin/Oper	 Status  Status
----- --------- ---------------- ----- ----- ----------- ------- -------
e0a   Cluster   Cluster          up    9000  auto/10000  healthy false
e0b   Cluster   Cluster          up    9000  auto/10000  healthy false
4 entries were displayed.

  3. Vérifiez que toutes les interfaces réseau du cluster sont bien connectées à leurs ports d'origine.

    Vérifiez que la colonne « est à la maison » est true pour chacun des LIF du cluster :

    network interface show -vserver Cluster -fields is-home

    Afficher un exemple 
    cluster::*> net int show -vserver Cluster -fields is-home
(network interface show)
vserver  lif          is-home
-------- ------------ --------
Cluster  node1_clus1  true
Cluster  node1_clus2  true
Cluster  node2_clus1  true
Cluster  node2_clus2  true
4 entries were displayed.

    Si certaines interfaces logiques (LIF) du cluster ne sont pas connectées à leurs ports d'origine, rétablissez leur connexion à ces LIF sur leurs ports d'origine :

    network interface revert -vserver Cluster -lif *

  4. Désactiver la restauration automatique pour les LIF du cluster :

    network interface modify -vserver Cluster -lif * -auto-revert false

  5. Vérifiez que tous les ports mentionnés à l'étape précédente sont connectés à un commutateur réseau :

    network device-discovery show -port cluster_port

    La colonne « Périphérique découvert » doit indiquer le nom du commutateur de cluster auquel le port est connecté.

    Afficher un exemple

    L'exemple suivant montre que les ports de cluster « e0a » et « e0b » sont correctement connectés aux commutateurs de cluster « cs1 » et « cs2 ».

    cluster::> network device-discovery show -port e0a|e0b
  (network device-discovery show)
Node/     Local  Discovered
Protocol  Port   Device (LLDP: ChassisID)  Interface  Platform
--------- ------ ------------------------- ---------- ----------
node1/cdp
          e0a    cs1                       0/11       BES-53248
          e0b    cs2                       0/12       BES-53248
node2/cdp
          e0a    cs1                       0/9        BES-53248
          e0b    cs2                       0/9        BES-53248
4 entries were displayed.

  6. Vérifiez la connectivité des interfaces du cluster distant :

ONTAP 9.9.1 et versions ultérieures

Vous pouvez utiliser le network interface check cluster-connectivity commande permettant de lancer une vérification d'accessibilité pour la connectivité du cluster, puis d'afficher les détails :

network interface check cluster-connectivity start`et `network interface check cluster-connectivity show

cluster1::*> network interface check cluster-connectivity start

REMARQUE : Attendez quelques secondes avant d’exécuter le programme. show commande pour afficher les détails.

cluster1::*> network interface check cluster-connectivity show
                                  Source           Destination      Packet
Node   Date                       LIF              LIF              Loss
------ -------------------------- ---------------- ---------------- -----------
node1
       3/5/2022 19:21:18 -06:00   node1_clus2      node2-clus1      none
       3/5/2022 19:21:20 -06:00   node1_clus2      node2_clus2      none
node2
       3/5/2022 19:21:18 -06:00   node2_clus2      node1_clus1      none
       3/5/2022 19:21:20 -06:00   node2_clus2      node1_clus2      none
Toutes les versions ONTAP

Pour toutes les versions ONTAP , vous pouvez également utiliser cluster ping-cluster -node <name> commande pour vérifier la connectivité :

cluster ping-cluster -node <name>

cluster1::*> cluster ping-cluster -node local
Host is node2
Getting addresses from network interface table...
Cluster node1_clus1 169.254.209.69 node1 e0a
Cluster node1_clus2 169.254.49.125 node1 e0b
Cluster node2_clus1 169.254.47.194 node2 e0a
Cluster node2_clus2 169.254.19.183 node2 e0b
Local = 169.254.47.194 169.254.19.183
Remote = 169.254.209.69 169.254.49.125
Cluster Vserver Id = 4294967293
Ping status:

Basic connectivity succeeds on 4 path(s)
Basic connectivity fails on 0 path(s)

Detected 9000 byte MTU on 4 path(s):
Local 169.254.47.194 to Remote 169.254.209.69
Local 169.254.47.194 to Remote 169.254.49.125
Local 169.254.19.183 to Remote 169.254.209.69
Local 169.254.19.183 to Remote 169.254.49.125
Larger than PMTU communication succeeds on 4 path(s)
RPC status:
2 paths up, 0 paths down (tcp check)
2 paths up, 0 paths down (udp check)

  1. [[étape 7]] Vérifiez que le cluster est sain :

    cluster ring show

    Toutes les unités doivent être soit principales, soit secondaires.

  2. Configurez la configuration sans commutateur pour les ports du groupe 1.

    Important Pour éviter d'éventuels problèmes de réseau, vous devez déconnecter les ports du groupe 1 et les reconnecter l'un après l'autre le plus rapidement possible, par exemple, en moins de 20 secondes.

    1. Débranchez simultanément tous les câbles des ports du groupe 1.

      Dans l'exemple suivant, les câbles sont déconnectés du port « e0a » sur chaque nœud, et le trafic du cluster continue via le commutateur et le port « e0b » sur chaque nœud :

      ClusterSwitch1 déconnecté

    2. Câblez les ports du groupe 1 dos à dos.

      Dans l'exemple suivant, « e0a » sur le nœud 1 est connecté à « e0a » sur le nœud 2 :

    Connexion directe entre les ports « e0a »

  3. L'option de réseau cluster sans commutateur passe de false à true . Cela peut prendre jusqu'à 45 secondes. Vérifiez que l'option sans interrupteur est bien réglée sur true :

    network options switchless-cluster show

    L'exemple suivant montre que le cluster sans commutateur est activé :

    cluster::*> network options switchless-cluster show
Enable Switchless Cluster: true

  4. Vérifiez la connectivité des interfaces du cluster distant :

ONTAP 9.9.1 et versions ultérieures

Vous pouvez utiliser le network interface check cluster-connectivity commande permettant de lancer une vérification d'accessibilité pour la connectivité du cluster, puis d'afficher les détails :

network interface check cluster-connectivity start`et `network interface check cluster-connectivity show

cluster1::*> network interface check cluster-connectivity start

REMARQUE : Attendez quelques secondes avant d’exécuter le programme. show commande pour afficher les détails.

cluster1::*> network interface check cluster-connectivity show
                                  Source           Destination      Packet
Node   Date                       LIF              LIF              Loss
------ -------------------------- ---------------- ---------------- -----------
node1
       3/5/2022 19:21:18 -06:00   node1_clus2      node2-clus1      none
       3/5/2022 19:21:20 -06:00   node1_clus2      node2_clus2      none
node2
       3/5/2022 19:21:18 -06:00   node2_clus2      node1_clus1      none
       3/5/2022 19:21:20 -06:00   node2_clus2      node1_clus2      none
Toutes les versions ONTAP

Pour toutes les versions ONTAP , vous pouvez également utiliser cluster ping-cluster -node <name> commande pour vérifier la connectivité :

cluster ping-cluster -node <name>

cluster1::*> cluster ping-cluster -node local
Host is node2
Getting addresses from network interface table...
Cluster node1_clus1 169.254.209.69 node1 e0a
Cluster node1_clus2 169.254.49.125 node1 e0b
Cluster node2_clus1 169.254.47.194 node2 e0a
Cluster node2_clus2 169.254.19.183 node2 e0b
Local = 169.254.47.194 169.254.19.183
Remote = 169.254.209.69 169.254.49.125
Cluster Vserver Id = 4294967293
Ping status:

Basic connectivity succeeds on 4 path(s)
Basic connectivity fails on 0 path(s)

Detected 9000 byte MTU on 4 path(s):
Local 169.254.47.194 to Remote 169.254.209.69
Local 169.254.47.194 to Remote 169.254.49.125
Local 169.254.19.183 to Remote 169.254.209.69
Local 169.254.19.183 to Remote 169.254.49.125
Larger than PMTU communication succeeds on 4 path(s)
RPC status:
2 paths up, 0 paths down (tcp check)
2 paths up, 0 paths down (udp check)
Important Avant de passer à l'étape suivante, vous devez attendre au moins deux minutes pour confirmer une connexion directe et fonctionnelle sur le groupe 1.

  1. [[étape 11]] Configurez la configuration sans commutateur pour les ports du groupe 2.

    Important Pour éviter d'éventuels problèmes de réseau, vous devez déconnecter les ports du groupe 2 et les reconnecter l'un après l'autre le plus rapidement possible, par exemple, en moins de 20 secondes.

    1. Débranchez simultanément tous les câbles des ports du groupe 2.

      Dans l'exemple suivant, les câbles sont déconnectés du port « e0b » sur chaque nœud, et le trafic du cluster continue via la connexion directe entre les ports « e0a » :

      ClusterSwitch2 déconnecté

    2. Câblez les ports du groupe 2 dos à dos.

      Dans l'exemple suivant, « e0a » sur le nœud 1 est connecté à « e0a » sur le nœud 2 et « e0b » sur le nœud 1 est connecté à « e0b » sur le nœud 2 :

    Connexion directe entre les ports du nœud 1 et du nœud 2

Étape 3 : Vérifier la configuration

  1. Vérifiez que les ports des deux nœuds sont correctement connectés :

    network device-discovery show -port cluster_port

    Afficher un exemple

    L'exemple suivant montre que les ports de cluster « e0a » et « e0b » sont correctement connectés au port correspondant sur le partenaire de cluster :

    cluster::> net device-discovery show -port e0a|e0b
  (network device-discovery show)
Node/      Local  Discovered
Protocol   Port   Device (LLDP: ChassisID)  Interface  Platform
---------- ------ ------------------------- ---------- ----------
node1/cdp
           e0a    node2                     e0a        AFF-A300
           e0b    node2                     e0b        AFF-A300
node1/lldp
           e0a    node2 (00:a0:98:da:16:44) e0a        -
           e0b    node2 (00:a0:98:da:16:44) e0b        -
node2/cdp
           e0a    node1                     e0a        AFF-A300
           e0b    node1                     e0b        AFF-A300
node2/lldp
           e0a    node1 (00:a0:98:da:87:49) e0a        -
           e0b    node1 (00:a0:98:da:87:49) e0b        -
8 entries were displayed.

  2. Réactiver la restauration automatique pour les LIF du cluster :

    network interface modify -vserver Cluster -lif * -auto-revert true

  3. Vérifiez que tous les LIF sont bien à leur domicile. Cela peut prendre quelques secondes.

    network interface show -vserver Cluster -lif lif_name

    Afficher un exemple

    Les LIF ont été rétablis si la colonne « Est à la maison » est true , comme indiqué pour node1_clus2 et node2_clus2 dans l'exemple suivant :

    cluster::> network interface show -vserver Cluster -fields curr-port,is-home
vserver  lif           curr-port is-home
-------- ------------- --------- -------
Cluster  node1_clus1   e0a       true
Cluster  node1_clus2   e0b       true
Cluster  node2_clus1   e0a       true
Cluster  node2_clus2   e0b       true
4 entries were displayed.

    Si certains LIFS du cluster ne sont pas revenus à leurs ports d'origine, rétablissez-les manuellement depuis le nœud local :

    network interface revert -vserver Cluster -lif lif_name

  4. Vérifiez l'état du cluster des nœuds depuis la console système de l'un ou l'autre nœud :

    cluster show

    Afficher un exemple

    L'exemple suivant montre que epsilon est égal à false :

    Node  Health  Eligibility Epsilon
----- ------- ----------- --------
node1 true    true        false
node2 true    true        false
2 entries were displayed.

  5. Vérifiez la connectivité des interfaces du cluster distant :

ONTAP 9.9.1 et versions ultérieures

Vous pouvez utiliser le network interface check cluster-connectivity commande permettant de lancer une vérification d'accessibilité pour la connectivité du cluster, puis d'afficher les détails :

network interface check cluster-connectivity start`et `network interface check cluster-connectivity show

cluster1::*> network interface check cluster-connectivity start

REMARQUE : Attendez quelques secondes avant d’exécuter le programme. show commande pour afficher les détails.

cluster1::*> network interface check cluster-connectivity show
                                  Source           Destination      Packet
Node   Date                       LIF              LIF              Loss
------ -------------------------- ---------------- ---------------- -----------
node1
       3/5/2022 19:21:18 -06:00   node1_clus2      node2-clus1      none
       3/5/2022 19:21:20 -06:00   node1_clus2      node2_clus2      none
node2
       3/5/2022 19:21:18 -06:00   node2_clus2      node1_clus1      none
       3/5/2022 19:21:20 -06:00   node2_clus2      node1_clus2      none
Toutes les versions ONTAP

Pour toutes les versions ONTAP , vous pouvez également utiliser cluster ping-cluster -node <name> commande pour vérifier la connectivité :

cluster ping-cluster -node <name>

cluster1::*> cluster ping-cluster -node local
Host is node2
Getting addresses from network interface table...
Cluster node1_clus1 169.254.209.69 node1 e0a
Cluster node1_clus2 169.254.49.125 node1 e0b
Cluster node2_clus1 169.254.47.194 node2 e0a
Cluster node2_clus2 169.254.19.183 node2 e0b
Local = 169.254.47.194 169.254.19.183
Remote = 169.254.209.69 169.254.49.125
Cluster Vserver Id = 4294967293
Ping status:

Basic connectivity succeeds on 4 path(s)
Basic connectivity fails on 0 path(s)

Detected 9000 byte MTU on 4 path(s):
Local 169.254.47.194 to Remote 169.254.209.69
Local 169.254.47.194 to Remote 169.254.49.125
Local 169.254.19.183 to Remote 169.254.209.69
Local 169.254.19.183 to Remote 169.254.49.125
Larger than PMTU communication succeeds on 4 path(s)
RPC status:
2 paths up, 0 paths down (tcp check)
2 paths up, 0 paths down (udp check)

  1. [[étape 6]] Si vous avez désactivé la création automatique de dossiers, réactivez-la en envoyant un message AutoSupport :

    system node autosupport invoke -node * -type all -message MAINT=END

    Pour plus d'informations, voir "Article 1010449 de la base de connaissances NetApp : Comment désactiver la création automatique de tickets pendant les fenêtres de maintenance planifiées".

  2. Rétablir le niveau de privilège à administrateur :

    set -privilege admin