Description

Cet article vous guide dans la configuration, l'activation, la désactivation et la vérification du protocole LACP (Link Aggregation Control Protocol) sur les hôtes AHV avec les éléments suivants :

• Avantages/Avantages du LACP
• Configuration de commutateur recommandée
• Solution
  • Pour AOS 5.19 ou version ultérieure
  • Méthode manuelle
  • Présentation du flux de travail
• Configuration, vérification et désactivation de LACP
  • Comment vérifier le nom de l'obligation et le nom du pont/commutateur
  • Comment configurer LACP dans AHV
  • Comment vérifier si LACP est configuré
  • Comment désactiver LACP sur l'hôte
  • Comment trouver l'adresse MAC d'une carte réseau hôte AHV

Pour plus d'informations, consultez le Guide des meilleures pratiques de mise en réseau AHV i. n Portail Nutanix pour une documentation complète sur la configuration de la mise en réseau pour les hôtes AHV.

Avantages/Avantages du LACP

• Une machine virtuelle mono-utilisateur avec plusieurs flux TCP peut utiliser jusqu'à 20 Gbit/s de bande passante dans un nœud AHV avec deux adaptateurs de 10 Go .
• Un algorithme de hachage du trafic tel que balance-TCP peut répartir le trafic entre plusieurs liens de manière active-active. Étant donné que les liaisons montantes apparaissent comme une seule liaison L2, l'algorithme peut équilibrer le trafic entre les membres de la liaison sans aucune considération pour les tables d'adresses MAC du commutateur.
• Avec LACP, plusieurs liaisons vers des commutateurs physiques distincts apparaissent comme une seule liaison de couche 2.
  Remarque : Pour utiliser plusieurs commutateurs en amont, vous devez configurer MLAG ou vPC sur le commutateur physique.

[ Retour au sommet ]

Configuration de commutateur recommandée

Il est recommandé d'activer le repli LACP sur le commutateur utilisé pour connecter les nœuds AHV. Des exemples de commandes peuvent être trouvés ci-dessous. Pour les autres fournisseurs de commutateurs, reportez-vous à leurs manuels de produits.

Ariste :

 port-channel lacp repli individuel

Cisco Nexus :

 pas de suspension lacp-individuel

**Le mode de repli est désactivé par défaut

Catalyseur Cisco :

 pas de désactivation autonome du canal de port

**Le mode de repli est désactivé par défaut

Genévrier QFX :

 forcer

**Voir Nutanix KB-15541 pour des considérations spécifiques avec les commutateurs Juniper.

[ Retour au sommet ]

Solution

AOS 5.19 ou version ultérieure

Il est possible d'activer LACP à l'aide de l'interface utilisateur de Prism Element (PE) ou de Prism Central (PC). Reportez-vous au chapitre À propos du commutateur virtuel du Guide d'administration AHV pour plus d'informations sur les commutateurs virtuels. Reportez-vous au chapitre Création ou mise à jour d'un commutateur virtuel pour plus d'informations sur la façon de gérer les commutateurs virtuels.

Il est possible qu'un commutateur virtuel ne soit pas déployé correctement en raison d'une configuration de liaison incohérente entre les nœuds, puis la configuration de liaison doit être mise à jour manuellement pour que la configuration de liaison/pont corresponde sur tous les nœuds. N'utilisez PAS les commandes ovs-vsctl pour effectuer les modifications au niveau du pont (comme Désactiver ou Activer LACP). Utilisez plutôt les commandes manage_ovs .
Avant d'utiliser manage_ovs pour apporter des modifications au niveau OVS, le commutateur virtuel doit être temporairement désactivé.

La séquence d'étapes ci-dessous peut être suivie :

1. Liste des commutateurs virtuels

    nutanix@cvm$ acli net.list_virtual_switch
   

2. Désactivez le commutateur virtuel sur le cluster en exécutant la commande ci-dessous sur une machine virtuelle contrôleur (CVM) :

    nutanix@cvm$ acli net.disable_virtual_switch
   

3. Utilisez ensuite les commandes manage_ovs mentionnées dans la section « Comment désactiver LACP sur l'hôte » pour modifier la configuration de liaison de LACP à active-backup/balance-slb.
   REMARQUE : Pour AOS >= 5.19 et < 5.20.2
   • Il existe un problème connu dans le commutateur virtuel en raison duquel le commutateur virtuel est automatiquement recréé même après l'avoir désactivé. Ce problème est résolu à partir d’AOS 5.20.2.
   • Il est automatiquement recréé dans le scénario où le commutateur virtuel n'est pas présent sur le cluster et que l'un des premiers nœuds AHV du cluster se déconnecte du réseau et restaure la connectivité réseau. Vous pouvez éventuellement rencontrer ce scénario pendant le processus de modification de la configuration des liaisons sur AHV et/ou de modification de la configuration des ports côté commutateur physique.
   • Si le commutateur virtuel est réactivé en raison de ce problème, les commandes manage_ovs échoueront avec l'erreur suivante :

      2021-08-24 17:46:20,254Z INFO manage_ovs:400 L'UUID pour l'hôte local est ecb39f18-fdfe-465e-a944-2506f189ee72
     2021-08-24 17:46:20,261Z CRITIQUE manage_ovs:450 Nom du pont : br0 est utilisé par le commutateur virtuel : vs0. Pont OVS : br0 utilisé par le commutateur virtuel ne peut pas être modifié avec manage_ovs.

   • Dans une telle situation, suivez les étapes (a) et (b) pour vérifier si le commutateur virtuel est présent sur le cluster, puis désactivez-le à nouveau avant de passer au nœud suivant pour apporter des modifications à la configuration des liaisons.

4. Une fois la configuration de liaison rendue cohérente sur tous les nœuds, migrez le(s) pont(s) correspondant(s) vers le(s) commutateur(s) virtuel(s), comme indiqué dans l'exemple ci-dessous.

    nutanix@cvm$ acli net.migrate_br_to_virtual_switch brX vs_name=vsX
   
   Exemple:
   nutanix@cvm$ acli net.migrate_br_to_virtual_switch br0 vs_name=vs0

[ Retour au sommet ]

Méthode manuelle

• Reportez-vous au guide des meilleures pratiques de mise en réseau AHV.
• Les ports liés regroupent les interfaces physiques sur l’hôte AHV. Par défaut, le système crée une liaison nommée br0-up dans le pont br0 contenant toutes les interfaces physiques. Les modifications apportées à la liaison par défaut (br0-up) à l'aide des commandes manage_ovs peuvent la renommer en bond0 lorsque vous utilisez des exemples plus anciens, alors gardez à l'esprit que votre système peut être nommé différemment des exemples ci-dessous.
• Les versions précédentes de ce guide utilisaient le nom d'obligation bond0 au lieu de br0-up (bond0 était le nom par défaut). Nutanix recommande d'utiliser le nom br0-up pour identifier rapidement cette interface comme liaison montante du pont br0. L'utilisation de ce schéma de dénomination permet de distinguer facilement les liaisons montantes des ponts supplémentaires les unes des autres.

Dans les exemples ci-dessous, nous utilisons br0-up comme nom de liaison au lieu de bond0 ou de tout autre schéma de dénomination personnalisé.

AVERTISSEMENT : la mise à jour des liaisons montantes à l'aide de "manage_ovs" supprimera et recréera le lien avec la configuration par défaut.
Tenez compte des points suivants avant de mettre à jour les liaisons montantes :

• Si le mode d'équilibrage de charge de sauvegarde active est utilisé, une mise à jour de liaison montante peut provoquer une brève déconnexion du réseau hôte.
• Si le mode d'équilibrage de charge balance-slb ou balance-tcp (LACP) est utilisé, une mise à jour de liaison montante réinitialisera la configuration sur actif-passif. Les liaisons réseau s'appuyant sur LACP diminueront à ce stade lorsque l'hôte cessera de répondre aux keepalives. Cette condition peut être atténuée en exécutant la commande suivante sur le CVM local dans les versions AOS 5.5.3+ et 5.6.1+ :

   nutanix@cvm$ manage_ovs --bridge <nom du pont> --interfaces <noms d'interface> --bond_name <nom de la liaison> --bond_mode balance-tcp --lacp_mode fast --lacp_fallback true update_uplinks

Il est fortement recommandé d'effectuer des modifications sur un nœud à la fois après s'être assuré que le cluster peut tolérer une panne de nœud. L'utilisation de la commande allssh manage_ovs update_uplinks peut entraîner une panne du cluster. Utilisez-le uniquement si le cluster n'est pas en production et qu'aucune machine virtuelle utilisateur n'est en cours d'exécution.

[ Retour au sommet ]

Présentation du flux de travail

1. Connectez-vous à CVM (Controller VM) via SSH. Assurez-vous que vous êtes connecté au bon CVM en vérifiant son nom et son IP.
2. Suivez le chapitre Vérification de l'état du cluster dans le Guide d'administration AHV pour vous assurer que le cluster peut tolérer l'arrêt du nœud. Ne continuez pas si le cluster ne peut pas tolérer la panne d'au moins 1 nœud.
3. Mettez le nœud et le CVM dans le Mode de Maintenance:

un. Vérifiez la disponibilité du changement de mode de maintenance des hôtes cibles :

 nutanix@cvm$ acli host.enter_maintenance_mode_check <adresse IP de l'hôte>

b. Mettez l'hôte en mode maintenance. Cela migrera les VM en cours d'exécution vers d'autres hôtes :

 nutanix@cvm$ acli host.enter_maintenance_mode <adresse IP de l'hôte>

c. Activez le mode maintenance pour le CVM sur l'hôte cible. Cette étape vise à empêcher les services CVM d'être affectés par un éventuel problème de connectivité. Vous pouvez ignorer cette étape si les services CVM ne sont pas en cours d'exécution ou si le cluster s'est arrêté.

 nutanix@cvm$ ncli host edit id=<ID d'hôte> activate-maintenance-mode=true

Remarque : Vous pouvez trouver <host ID> dans la sortie de la commande "ncli host ls" :

 liste d'hôtes ncli
    Id : 00058977-c18c-af17-0000-000000006f89::2872 <--- "2872" est l'ID de l'hôte
    Uuid : ddc9d93b-68e0-4220-85f9-63b73d08f0ff
...

4. Connectez-vous à l'hôte via IPMI, car le processus de configuration LACP peut provoquer une déconnexion du réseau.
5. Effectuez les étapes de configuration requises ( Comment configurer LACP dans AHV , Comment désactiver LACP sur l'hôte ).
6. Une fois la configuration terminée, assurez-vous que l'hôte et le CVM sont accessibles via le réseau. Assurez-vous également que toutes les cartes réseau de la liaison sont opérationnelles en fermant les liaisons une par une et en vérifiant la connectivité.
7. Si tous les tests sont terminés avec succès, supprimez le CVM et le nœud du mode maintenance :

un. Depuis l'un des autres CVM, exécutez la commande suivante pour quitter le CVM concerné du mode maintenance :

 nutanix@cvm$ ncli host edit id=<ID d'hôte> activate-maintenance-mode=false

b. Quittez l'hôte en mode maintenance. Cela restaurera la localité de la VM :

 nutanix@cvm$ acli host.exit_maintenance_mode <adresse IP de l'hôte>

[ Retour au sommet ]

Comment vérifier le nom de l'obligation et le nom du pont/commutateur ?

Exécutez la commande depuis CVM pour obtenir le nom de la liaison et le nom du commutateur/pont :

 nutanix@cvm$ manage_ovs show_uplinks

Exemple

 nutanix@cvm$ manage_ovs show_uplinks
Pont br1 : ---> Nom du pont/commutateur
  Ports de liaison montante : br1-up ---> nom de la liaison
  Interfaces de liaison montante : eth1 eth0

Pont br0 : ---> Nom du pont/commutateur
  Ports de liaison montante : br0-up ---> nom de la liaison
  Interfaces de liaison montante : eth3 eth2

Dans cet exemple, le nom de la liaison est br0-up pour le pont/commutateur br0 et br1-up pour le pont/commutateur br1 .

[ Retour au sommet ]

Comment configurer LACP dans AHV

Pour reconfigurer des liaisons montantes spécifiques à distance à partir d'un autre CVM en mode sans maintenance dans le cluster lorsque l'hôte cible a accès au réseau, utilisez la commande manage_ovs . Utilisez des variables si nécessaire :

 nutanix@cvm$ manage_ovs --bridge 
  
   --interfaces 
   
  
    --bond_name 
    
   
     --hôte 
     
    
      --bond_mode balance-tcp --lacp_mode fast --lacp_fallback true update_uplinks
     
    
    
    
   
   
   
  
  
  
 

Voir ci-dessous pour un exemple :

 nutanix@cvm$ manage_ovs --bridge br0 --interfaces eth2,eth3 --bond_name br0-up --host hh.hh.hh.hh --bond_mode balance-tcp --lacp_mode fast --lacp_fallback true update_uplinks

Remarque : Tenez compte des options de temps LACP (lent et rapide). Si les commutateurs ont une configuration rapide, gardez à l'esprit que vous devez également définir le LACP de Nutanix Cluster en mode rapide. Sinon, vous pourriez subir une panne en raison d'une inadéquation dans la vitesse LACP.

[ Retour au sommet ]

Comment vérifier si LACP est configuré dans AHV

Exécutez les commandes suivantes.

 root@ahv# ovs-appctl lien/show br0-up 
root@ahv# ovs-appctl lacp/show br0-up

Exemples de travail :

Pour le lien/show ovs-appctl , notez « lacp_status : négocié »

 root@ahv# ovs-appctl lien/show br0-up  
---- br0-up ----  
bond_mode : balance-tcp  
la caution peut utiliser la recirculation : oui, Recirc-ID : 301  
base de hachage de liaison : 0  
délai de mise à jour : 0 ms  
délai de descente : 0 ms  
prochain rééquilibrage : 6757 ms  
lacp_status : négocié  
Mac esclave actif : 0c:c4:7a:1e:3e:6e(eth2)  
  
esclave eth2 : activé  
        esclave actif  
        may_enable : vrai  
        hachage 78 : 127 Ko de charge  
        hachage 108 : 13 Ko de charge  
        hachage 244 : 94 Ko de charge  
  
esclave eth3 : activé  
        may_enable : vrai  
        hachage 9 : 6 Ko de charge  
        hachage 11 : 11 Ko de charge  
        hachage 23 : 12 Ko de charge  
...

Pour ovs-appctl lacp/show , notez « statut : actif négocié » et « actuellement attaché » pour chaque interface :

 root@ahv# ovs-appctl lacp/show br0-up ---- br0-up ---- statut : actif négocié sys_id : 0c:c4:7a:2f:4f:9d sys_priority : 65534 clé d'agrégation : 1 lacp_time : esclave lent : eth2 : port_id actuellement connecté : 1 port_priority : 65535 may_enable : vrai acteur sys_id : 0c:c4:7a:2f:4f:9d acteur sys_priority : 65534 acteur port_id : 1 acteur port_priority : 65535 acteur clé : 1 acteur état : activité agrégation synchronisée collecte distribution partenaire sys_id : 00:2b:21:45:2d:12 partenaire sys_priority : 32768 partenaire port_id : 39 partenaire port_priority : 32768 clé du partenaire : 115 état du partenaire : agrégation d'activité synchronisée collecte distribution esclave : eth3 : port_id actuellement connecté : 2 port_priority : 65535 may_enable : vrai acteur sys_id : 0c:c4:7a:2f:4f:9d acteur sys_priority : 65534 acteur port_id : 2 acteurs port_priority : 65535 clé d'acteur : 1 acteur état : agrégation d'activités synchronisée collecte partenaire de distribution sys_id : 00 : 2b:21:45:2d:12 partenaire sys_priority : 32768 partenaire port_id : 40 partenaire port_priority : 32768 clé du partenaire : 115 état du partenaire : agrégation d'activités synchronisée collecte distribution

Exemples non fonctionnels

Pour ovs-appctl bond/show , notez « lacp_status : configuré » :

 root@ahv# ovs-appctl bond/show br0-up ---- br0-up ---- bond_mode : la liaison balance-tcp peut utiliser la recirculation : non, Recirc-ID : -1 bond-hash-basis : 0 updelay : 0 ms downdelay : 0 ms lacp_status : configuré lacp_fallback_ab : vrai primaire de sauvegarde active : 
  
   mac esclave actif : 00:e0:ed:8b:72:a1(eth2) < tronqué >
  
 

« configuré » indique que LACP a été configuré sur l'hôte AHV, mais que l'hôte n'a pas pu négocier LACP avec les ports du commutateur.

Pour ovs-appctl lacp/show br0-up , notez « status: active » et « defaulted attachment » pour chaque interface :

 root@ahv# ovs-appctl lacp/show br0-up ---- br0-up ---- statut : actif sys_id : ac:2f:7b:b6:fe:2e sys_priority : 65534 clé d'agrégation : 1 lacp_time : rapide esclave : eth0 : attaché par défaut port_id : 2 port_priority : 65535 may_enable : vrai acteur sys_id : ac:2f:7b:b6:fe:2e acteur sys_priority : 65534 acteur port_id : 2 acteurs port_priority : 65535 acteur clé : 1 acteur état : délai d'attente de l'activité agrégation synchronisée collecte distribution partenaire par défaut sys_id : 00:00:00:00:00:00 partenaire sys_priority : 0 partenaire port_id : 0 partenaire port_priority : 0 clé du partenaire : 0 état du partenaire : esclave : eth1 : attaché par défaut port_id : 3 port_priority : 65535 may_enable : vrai acteur sys_id : ac:2f:7b:b6:fe:2e acteur sys_priority : 65534 acteur port_id : 3 acteurs port_priority : 65535 acteur clé : 1 acteur état : agrégation de délai d'attente d'activité synchronisée collecte distribution par défaut

La sortie indique que LACP n’a pas été négocié. La valeur par défaut indique que l'hôte AHV n'a pas reçu de PDU LACP du commutateur. Si vous voyez cette configuration sur votre hôte, vérifiez la configuration LACP sur les commutateurs auxquels l'hôte est connecté.

[ Retour au sommet ]

Comment désactiver LACP sur l'hôte

Effectuez les étapes suivantes pour désactiver en toute sécurité LACP sur l'hôte. Consultez la section « Présentation du flux de travail » ci-dessus pour connaître les étapes à suivre pour effectuer les tâches de pré et post-configuration.

1. Configurez les hôtes pour utiliser un mode de liaison qui ne nécessite pas LACP à l'aide de l'une des commandes ci-dessous.

un. La commande suivante définit la stratégie d'équilibrage de charge sur active-backup, ce qui signifie qu'une seule liaison montante active est utilisée et que les adaptateurs de secours sont utilisés uniquement en cas de panne de l'adaptateur actif.

 nutanix@cvm$ manage_ovs --bridge 
  
   --interfaces 
   
  
    --bond_name 
    
   
     --hôte 
     
    
      --bond_mode sauvegarde active update_uplinks
     
    
    
    
   
   
   
  
  
  
 

Tous les membres de la liaison doivent être physiquement connectés, sinon la commande manage_ovs produit un avertissement et se termine sans configurer la liaison. Pour éviter cette erreur et fournir les interfaces de la liaison même si elles ne sont pas connectées, utilisez l'indicateur require_link=false.

 nutanix@cvm$ manage_ovs --bridge 
  
   --interfaces 
   
  
    --bond_name 
    
   
     --hôte 
     
    
      --bond_mode active-backup --require_link=false update_uplinks
     
    
    
    
   
   
   
  
  
  
 

b. La commande suivante définit la stratégie d'équilibrage de charge sur balance-slb, qui rééquilibre le trafic des machines virtuelles des interfaces très utilisées vers les interfaces moins utilisées, et utilise toutes les liaisons montantes disponibles. Vous pouvez consulter le guide des meilleures pratiques de mise en réseau AHV pour en savoir plus sur les stratégies d'équilibrage de charge.

2. Désactivez LACP sur les ports du commutateur.

[ Retour au sommet ]

Comment trouver l'adresse MAC d'une carte réseau hôte AHV

Pour trouver l'adresse MAC d'une carte réseau hôte AHV, utilisez l'une des commandes suivantes :

• Exécutez la commande suivante sur l'hôte AHV

 [root@ahv ~]# ethtool -P <interface>

Exemple de sortie :

 [root@ahv ~]# ethtool -P eth3
Adresse permanente : 00:25:90:cb:39:27

• Exécutez la commande suivante sur l'hôte AHV

 [root@ahv ~]# ifconfig <interface>

Exemple de sortie :

 [root@ahv ~]# ifconfig eth3
eth3 Link encap: Ethernet HWaddr 00:25:90:CB:39:27 UP BROADCAST RUNNING MULTICAST MTU:1500 Métrique:1 Paquets RX:46857327754 erreurs:0 abandonnés:228250 dépassements:0 trame:0 paquets TX:49134503170 erreurs:0 abandonné:0 dépassements:0 transporteur:0 collisions:0 txqueuelen:1000 octets RX:49893674683483 (45,3 TiB) octets TX:54855610562476 (49,8 TiB)

[ Retour au sommet ]

Informations Complémentaires

• Nutanix KB 3263 - Document original dans le portail Nutanix
• Page de destination de Nutanix
• Plan de support Lenovo ISG - Appliance ThinkAgile HX et Lenovo Converged HX Series