Plusieurs techniques d'équilibrage de charge sont disponibles pour l'association de cartes réseau, et chaque technique a ses avantages et ses inconvénients.

Itinéraire basé sur le port virtuel d'origine

Dans les configurations de type Actif/Actif ou Actif/Passif, utilisez Itinéraire basé sur le port virtuel d'origine pour l'association des cartes réseau de base. Lorsque cette stratégie est effective, une seule carte réseau physique est utilisée par port VMkernel.

Avantages

  • Il s'agit de la méthode d'association de cartes réseau la plus simple, qui requiert une configuration de commutateur physique minimale.

  • Cette méthode n'exige qu'un seul port pour le trafic vSAN, ce qui simplifie le dépannage.

Inconvénients

  • Une interface VMkernel unique est limitée à la bande passante d'une seule carte réseau physique. Étant donné que les environnements vSAN types utilisent un seul adaptateur VMkernel, une seule carte réseau physique est utilisée dans l'association.

Route basée sur la charge de carte réseau physique

La méthode Route basée sur la charge de carte réseau physique repose sur la méthode Route basée sur le port virtuel d'origine. Dans cette dernière, le commutateur virtuel vérifie la charge réelle des liaisons montantes et prend des mesures pour la réduire la charge sur les liaisons montantes surchargées. Cette méthode d'équilibrage de charge n'est disponible qu'avec un vSphere Distributed Switch, pas sur les commutateurs vSphere Standard.

Le commutateur distribué calcule les liaisons montantes pour chaque port VMkernel en utilisant l'ID de port et le nombre de liaisons montantes dans l'équipe de cartes réseau. Le Distributed Switch vérifie les liaisons montantes toutes les 30 secondes. Si la charge est supérieure à 75 %, l'ID de port du port VMkernel dont les E/S sont les plus élevées est déplacé vers une autre liaison montante.

Avantages

  • Aucune configuration de commutateur physique n'est requise.

  • Bien que vSAN possède un port VMkernel, les mêmes liaisons montantes peuvent être partagées par d'autres ports VMkernel ou services réseau. vSAN peut bénéficier de différentes liaisons montantes provenant d'autres services en conflit, tels que vMotion ou la gestion.

Inconvénients

  • Étant donné que vSAN n'a généralement qu'un seul port VMkernel configuré, son efficacité est limitée.

  • Le VMkernel ESXi réévalue la charge de trafic après chaque intervalle de temps, ce qui peut provoquer une surcharge de traitement.

Paramètres : détection de pannes réseau

Utilisez le paramètre par défaut : État de lien seulement. N'utilisez pas le sondage de balise pour la détection de défaillances de liaison. Le sondage de balise requiert au moins trois cartes réseau physiques pour éviter les scénarios split-brain. Pour de plus amples informations, consultez l'article 1005577 de la base de connaissances VMware.

Paramètres : avertir les commutateurs

Utilisez le paramètre par défaut : Oui. Les commutateurs physiques disposent de tables de transfert d'adresses MAC pour associer chaque adresse MAC à un port de commutateur physique. Lorsqu'une trame arrive, le commutateur détermine l'adresse MAC de destination dans la table et détermine le port physique approprié.

Si un basculement de carte réseau se produit, l'hôte ESXi doit informer les commutateurs réseau que quelque chose a changé ou le commutateur physique peut continuer à utiliser les anciennes informations et envoyer les trames au port incorrect.

Lorsque vous définissez Avertir les commutateurs sur Oui, si une carte réseau physique est défectueuse et que le trafic est réacheminé vers une autre carte réseau physique dans l'équipe, le commutateur virtuel envoie des notifications sur le réseau pour mettre à jour les tables de recherche sur les commutateurs physiques.

Ce paramètre n'intercepte pas les problèmes de configuration VLAN ou les pertes de liaison montante qui se produisent plus en amont dans le réseau. Le contrôle de santé des partitions de réseau vSAN peut détecter ces problèmes.

Paramètres : retour arrière

Cette option détermine le mode de retour en activité d'un adaptateur physique lors de la récupération après échec. Un événement de basculement déclenche le trafic réseau pour passer d'une carte réseau à une autre. Lorsqu'un état de liaison montante est détecté sur la carte réseau d'origine, le trafic revient automatiquement à l'adaptateur réseau d'origine lorsque le retour arrière est défini sur Oui. Lorsque le retour arrière est défini sur Non, un retour arrière manuel est nécessaire.

La définition du retour arrière sur Non peut être utile dans certains cas. Par exemple, après la récupération d'un port de commutateur physique suite à une panne, le port peut être actif, mais peut mettre plusieurs secondes à démarrer le transfert du trafic. Le retour arrière automatique a été connu pour provoquer des problèmes dans certains environnements qui utilisent le protocole STP (Spanning Tree Protocol). Pour de plus amples informations sur le protocole STP (Spanning Tree Protocol), consultez l'article 1003804 de la base de connaissances VMware.

Définition de l'ordre de basculement

L'ordre de basculement détermine les liens actifs pendant les opérations normales et les liens actifs en cas de basculement. Différentes configurations prises en charge sont possibles pour le réseau vSAN.

Liaisons montantes Actif/En veille : si une panne se produit lors d'une configuration Actif/En veille, le pilote de la carte réseau avertit vSphere d'un événement de liaison inactive sur la liaison montante 1. La liaison montante en veille 2 devient active et le trafic reprend sur la liaison montante 2.

Liaisons montantes Actif/Actif : si vous définissez l'ordre de basculement sur Actif/Actif, le port virtuel utilisé par le trafic vSAN ne peut pas utiliser simultanément les deux ports physiques.

Si la configuration d'association de cartes réseau pour la liaison montante 1 et la liaison montante 2 est active, il n'est pas nécessaire que la liaison montante en veille devienne active.

Note : En cas d'utilisation d'une configuration de type Actif/Actif, assurez-vous que le retour arrière est défini sur Non. Pour de plus amples informations, consultez l'article 2072928 de la base de connaissances VMware.