Exemple de configuration de l'équilibrage de charge réseau Microsoft sur les serveurs de la gamme UCS-B

Introduction

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.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Équilibrage de charge réseau Microsoft
• Serveurs Cisco UCS série B
• Commutateurs Cisco Catalyst et/ou Nexus

Components Used

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.

Informations générales

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.

Configuration

Modes NLB Microsoft

Mode Unicast

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.

Attention : La NLB en mode monodiffusion repose sur une diffusion unicast inconnue pour la livraison des paquets liés au cluster. Le mode monodiffusion ne fonctionne pas sur les serveurs UCS série B lorsque le FI est en mode hôte final, car les trames de monodiffusion inconnues ne sont pas diffusées comme le requiert ce mode. Pour plus d'informations sur le comportement de transfert de couche 2 d'UCS en mode hôte final, consultez Modes de commutation Ethernet Cisco Unified Computing System.

Mode IGMP multidiffusion/multidiffusion

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.

Attention : Quelle que soit la version du mode de multidiffusion choisie, l'adresse VIP NLB nécessite une entrée ARP statique sur le périphérique en amont, généralement l'interface virtuelle commutée (SVI) pour le VLAN. Il s'agit d'une solution de contournement car les réponses ARP des noeuds NLB contiennent une adresse MAC de multidiffusion. Selon RFC 1812, les réponses ARP qui contiennent une adresse MAC de multidiffusion doivent être ignorées. Par conséquent, l'adresse MAC VIP ne peut pas être apprise dynamiquement sur les périphériques compatibles RFC 1812.

Un résumé des étapes requises pour prendre en charge NLB en mode IGMP multicast est présenté ici :

1. Les entrées ARP statiques pour les adresses IP NLB virtuelles se trouvent généralement sur l'interface SVI du VLAN. Si vous utilisez le protocole HSRP (Hot Standby Router Protocol) ou FHRP (First Hop Redundancy Protocol), assurez-vous que les deux périphériques ont l'entrée ARP statique.
2. Requête IGMP Snooping dans le VLAN NLB. Dans les versions ultérieures à UCS version 2.1, la fonctionnalité Snooping querier est prise en charge dans UCS Manager.
3. La surveillance IGMP doit être activée sur tous les commutateurs, y compris UCS. Notez que la plupart des plates-formes qui incluent UCS ont la surveillance IGMP activée par défaut.

Astuce : Ces guides de configuration sont destinés aux commutateurs Cisco. Ils incluent des détails sur la façon d'implémenter différents modes de Microsoft NLB.

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)

Flux de données Microsoft NLB

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.

1. Les clients hors sous-réseau envoient le trafic à l’adresse VIP NLB 10.1.1.1.
2. Ce trafic est acheminé vers l'interface VLAN 10 qui utilise une entrée ARP statique afin de résoudre l'adresse MAC (01) du VIP NLB.
3. Comme il s'agit d'une destination de trame de multidiffusion, elle est transmise par la table de surveillance IGMP.
4. La trame arrive sur tous les noeuds NLB (Noeud A, B, C).
5. Le cluster NLB utilise son algorithme d'équilibrage de charge afin de déterminer quel noeud desservira le flux. Un seul noeud répond.

Pour plus d'informations, reportez-vous aux documents suivants :

• Exemple de configuration de commutateurs Catalyst pour l'équilibrage de charge réseau Microsoft
• Exemple de configuration de l'équilibrage de charge réseau Microsoft sur Nexus 7000

Considération spéciale pour Nexus 1000v

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 :

1. Désactivez la surveillance uniquement sur ce VLAN dans le Nexus 1000v.
2. Utilisez un VLAN dédié pour le trafic NLB Microsoft.

Vérification

 Les procédures de vérification des exemples de configuration décrits dans ce document sont fournies dans les sections respectives.

Dépannage

 Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.

Informations connexes

• Présentation technique de l'équilibrage de charge réseau
• Discussion de la communauté d'assistance Cisco
• Modes de commutation Ethernet de Cisco Unified Computing System (recherchez Microsoft Network Load Balancing)
• Support et documentation techniques - Cisco Systems