Ce document décrit la mise en oeuvre du mode d'équilibrage de charge réseau (NLB) de Microsoft sur la gamme Cisco Unified Computing System-B (UCS-B) avec interconnexion de fabric (FI) en mode hôte final. Il existe également un certain nombre de conditions requises sur les périphériques en amont pour faciliter le transfert correct du trafic NLB, décrites dans ce document. L'exemple de configuration se concentre sur le mode IGMP (Internet Group Management Protocol) de multidiffusion.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Microsoft NLB fonctionne en trois modes opérationnels différents : IGMP de monodiffusion, multidiffusion et multidiffusion. Un groupe de noeuds NLB est collectivement appelé cluster NLB. Un cluster NLB gère une ou plusieurs adresses IP virtuelles (VIP). Les noeuds du cluster NLB utilisent leur algorithme d’équilibrage de charge afin de convenir du noeud individuel qui desservira le flux de trafic particulier destiné au VIP NLB.
Ce document ne fait pas de recommandations de déploiement spécifiques pour Microsoft NLB sur UCS. Comme décrit dans ce document, NLB utilise des méthodes non conventionnelles pour la livraison du trafic lié aux clusters. Il a été observé que les modes IGMP multicast et multicast semblent fonctionner de manière stable et cohérente sur les serveurs de la gamme UCS-B. Bien que les directives de dimensionnement NLB ne soient pas comprises dans ce document, il s'agit d'une solution généralement recommandée pour les déploiements plus petits.
Par défaut, le NLB est défini en mode unicast. En mode unicast, NLB remplace l’adresse MAC réelle de chaque serveur du cluster par une adresse MAC NLB commune. Généralement, quelque chose se trouve dans la plage 02bf:xxxx:xxxx. Tous les noeuds du cluster NLB comprennent ce qu'est le VIP et l'adresse MAC NLB. Le trafic, qui inclut les réponses ARP (Address Resolution Protocol) des noeuds NLB, n'est jamais issu de l'adresse MAC ou IP NLB. Au lieu de cela, les noeuds NLB utilisent une adresse MAC attribuée en fonction de l’ID d’hôte du membre. L'adresse MAC se trouve généralement dans la plage 0201:xxxx:xxxx, 0202, 0203, etc., une pour chaque noeud du cluster. Il s’agit de l’adresse source de l’en-tête de couche 2 (L2) lorsqu’une requête ARP est traitée. Cependant, les informations d’en-tête ARP contiennent l’adresse MAC NLB. Ainsi, les hôtes qui souhaitent correspondre à l’adresse VIP NLB envoient le trafic vers l’adresse MAC NLB.
Les commutateurs conformes à la norme IEEE (périphériques de couche 2) créent leur table d'adresses MAC en fonction de l'en-tête source de couche 2 et non des informations contenues dans la charge utile ARP. Cela signifie que le trafic transféré au cluster NLB est envoyé à l'adresse MAC NLB, qui n'est jamais la source du trafic. Par conséquent, le trafic destiné à l'adresse MAC NLB est diffusé en monodiffusion inconnue.
Le mode de multidiffusion attribue l'adresse IP virtuelle de monodiffusion du cluster à une adresse MAC de multidiffusion IANA (Internet Assigned Numbers Authority) non Internet (03xx.xxxx.xxxx). La surveillance IGMP n'enregistre pas dynamiquement cette adresse, ce qui entraîne l'inondation du trafic NLB dans le VLAN en tant que multidiffusion inconnue.
Le mode IGMP de multidiffusion attribue l'adresse IP virtuelle du cluster et une adresse MAC de multidiffusion dans la plage IANA (01:00:5E:XX:XX:XX). Les noeuds en cluster envoient des rapports d'appartenance IGMP pour le groupe de multidiffusion configuré et donc l'IF remplit dynamiquement sa table de surveillance IGMP pour pointer vers les serveurs en cluster.
Il y a un léger avantage opérationnel à l'utilisation du mode IGMP multicast, car les informations d'état (via les rapports d'appartenance IGMP et la surveillance IGMP) sur les ports L2 intéressés peuvent être conservées en amont et en aval. Sans l'optimisation de la surveillance IGMP, NLB s'appuie sur l'inondation de multidiffusion inconnue dans le VLAN NLB pour la remise au cluster via le récepteur de diffusion/multidiffusion UCS désigné. Dans les versions ultérieures à UCS version 2.0, le récepteur de diffusion/multidiffusion désigné est choisi par VLAN.
Un résumé des étapes requises pour prendre en charge NLB en mode IGMP multicast est présenté ici :
Ce schéma illustre une configuration de base de NLB, les noeuds pouvant être des machines virtuelles (VM) ou une installation sans système d'exploitation Windows Server.
NLB VLAN 10 qui possède le sous-réseau IP 10.1.1.0 /24. L’adresse MAC est tronquée pour plus de concision.
VIP NLB (MAC = 01, IP = 10.1.1.1)
NODE-A (MAC = AA, IP = 10.1.1.10)
NODE-B (MAC = BB, IP = 10.1.1.11)
NODE-C (MAC = CC, IP = 10.1.1.12)
L'entrée ARP statique sur l'interface SVI du commutateur en amont pointe vers l'adresse VIP 10.1.1.1 à MAC 01.
Les noeuds NLB Microsoft envoient le rapport d'appartenance IGMP. Notez que le remplissage de la table de surveillance IGMP peut prendre entre 30 et 60 secondes.
Avec IGMP Snooping et le demandeur VLAN, la table de surveillance est remplie avec l'adresse MAC NLB et les groupes qui pointent vers les ports L2 corrects.
Pour plus d'informations, reportez-vous aux documents suivants :
Le Nexus 1000v prend uniquement en charge le mode NLB Microsoft de monodiffusion. Ainsi, sur les déploiements de Nexus 1000v avec UCS, le mode IGMP multicast ne fonctionnera qu'après la désactivation de la surveillance sur Nexus 1000v. Lorsque cela est fait, les paquets NLB Microsoft sur ce VLAN sont diffusés en tant que multidiffusion inconnue.
Afin de minimiser l'impact des inondations :
Les procédures de vérification des exemples de configuration décrits dans ce document sont fournies dans les sections respectives.
Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
14-Aug-2014 |
Première publication |