Informatique unifiée : Serveurs à lame Cisco UCS B-Series

Équilibrage de charge de réseau Microsoft sur l'exemple de configuration de déploiement de serveurs de gamme UCSB

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit l'implémentation du mode de l'Équilibrage de charge de réseau Microsoft (NLB) sur la gamme du système-b de Cisco Unified Computing (UCSB) avec Fabric Interconnect (fi) dans le mode de Fin-hôte. Il y a également un certain nombre de conditions requises sur les périphériques en amont de faciliter l'expédition correct du trafic NLB qui sont décrits dans ce document. Les foyers d'exemple de configuration sur le mode de Protocole IGMP (Internet Group Management Protocol) de Multidiffusion.

Contribué par Charles Stizza, Vishal Mehta, et La Bua de Vincent, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

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

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Informations générales

Microsoft NLB fonctionne en trois modes opérationnels différents : unicast, Multidiffusion, et Multidiffusion IGMP. Un groupe de Noeuds NLB est collectivement connu comme batterie NLB. Une batterie NLB entretient un ou plusieurs adresses virtuelles IP (VIP). Les Noeuds dans la batterie NLB emploient leur algorithme d'Équilibrage de charge afin de convenir sur quel noeud individuel entretiendra la circulation particulière destiné pour le VIP NLB.

Ce document n'émet pas des recommandations spécifiques de déploiement pour Microsoft NLB sur l'UCS. Comme décrit dans ce document, NLB se fonde sur des méthodes peu conventionnelles pour la livraison du trafic de limite de batterie. On l'a observé que la Multidiffusion et les modes de la Multidiffusion IGMP semblent avoir à exécution stable et cohérente sur des serveurs de gamme UCSB. Tandis que les instructions de dimensionnement NLB sont hors de portée de ce document, c'est une solution généralement recommandée pour de plus petits déploiements.

Configuration

Modes de Microsoft NLB

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. Typiquement, quelque chose dans la plage 02bf:xxxx:xxxx. Tous les Noeuds dans la batterie NLB comprennent ce qu'est le VIP et l'adresse MAC NLB. Trafiquez, qui inclut des réponses de Protocole ARP (Address Resolution Protocol) des Noeuds NLB, n'est jamais originaire du MAC ou de l'adresse IP NLB. Au lieu de cela les Noeuds NLB utilisent une adresse MAC assignée basée sur l'ID d'hôte du membre. L'adresse MAC est habituellement dans le 0201:xxxx:xxxx, 0202, 0203, et ainsi de suite plage, une pour chaque noeud dans la batterie. C'est l'adresse source dans l'en-tête de la couche 2 (L2) quand une demande d'ARP est répondue. Cependant, les informations d'en-tête d'ARP contiennent l'adresse MAC NLB. Ainsi, les hôtes qui souhaitent correspondre à l'adresse de VIP NLB envoient le trafic vers l'adresse MAC NLB.

Les Commutateurs conformes d'IEEE (périphériques L2) construisent leur table d'adresse MAC basée sur l'en-tête de la source L2 et pas les informations contenues dans la charge utile d'ARP. Ceci signifie que le trafic expédié à la batterie NLB est envoyé à l'adresse MAC NLB, qui n'est jamais la source de trafic. Par conséquent le trafic destiné pour l'adresse MAC NLB est inondé en tant qu'unicast inconnu.

Attention : NLB en mode d'unicast se fonde sur l'inondation inconnue d'unicast pour la livraison des paquets attachés de batterie. Le mode d'Unicast ne travaillera pas sur des serveurs de B-gamme UCS quand le fi est en mode de Fin-hôte puisque des trames de monodiffusion inconnues ne sont pas inondées selon les exigences de ce mode. Pour plus de détails sur le comportement de l'expédition L2 de l'UCS en mode de Fin-hôte, voir les modes de commutation Ethernet de Système d'informatique unifiée Cisco.

Mulitcast/mode de la Multidiffusion IGMP

Le mode de Multidiffusion assigne à l'unicast de batterie l'adresse IP virtuelle à une adresse MAC de Multidiffusion de l'autorité d'assigned number de non-Internet (IANA) (03xx.xxxx.xxxx). La surveillance IGMP n'enregistre pas dynamiquement cette adresse, que les résultats dans l'inondation du NLB trafiquent du VLAN en tant que Multidiffusion inconnue.

Le mode de la Multidiffusion IGMP assigne à la batterie l'adresse IP virtuelle et une adresse MAC de Multidiffusion dans la marge IANA (01:00:5E:XX:XX:XX). Les Noeuds groupés envoient des rapports d'adhésion IGMP pour le groupe de multidiffusion configuré et le fi remplit ainsi dynamiquement sa table de surveillance IGMP pour se diriger vers les serveurs en cluster.

Il y a un léger avantage opérationnel à l'utilisation du mode de la Multidiffusion IGMP puisque les informations d'état (par l'intermédiaire des rapports d'adhésion IGMP et de la surveillance IGMP) sur les ports L2 intéressés peuvent être des deux mis à jour en amont et en aval. Sans optimisation de surveillance IGMP, NLB se fonde sur l'inondation inconnue de Multidiffusion dans le NLB VLAN pour la livraison à la batterie par l'intermédiaire de l'émission/du récepteur multicast indiqués par UCS. Dans les versions plus tard que la version 2.0 UCS, l'émission indiquée/récepteur multicast est choisie sur une base par-VLAN.

Attention : Indépendamment de la version du mode de Multidiffusion choisie, l'adresse de VIP NLB exige une entrée statique d'ARP sur le périphérique en amont, qui est typiquement l'interface virtuelle commutée (SVI) pour le VLAN. C'est un contournement puisque les réponses d'ARP des Noeuds NLB contiennent une adresse MAC de Multidiffusion. Par RFC 1812, des réponses d'ARP qui contiennent une adresse MAC de Multidiffusion devraient être ignorées. Par conséquent l'adresse MAC de VIP ne peut pas être dynamiquement apprise sur les périphériques conformes RFC 1812.

Un résumé de l'étape nécessaire pour prendre en charge NLB en mode de la Multidiffusion IGMP est affiché ici :

  1. Les entrées statiques d'ARP pour les adresses IP virtuelles NLB sont typiquement sur le VLAN SVI. Si vous utilisez le Protocole HSRP (Hot Standby Router Protocol) ou la première Redondance Protocol (FHRP) de saut, soyez sûr que les deux périphériques ont l'entrée statique d'ARP.
  2. Une surveillance IGMP querier dans le NLB VLAN. Dans les versions plus tard que la version 2.1 UCS, la fonctionnalité querier snooping est prise en charge dans les UCS Manager.
  3. La surveillance IGMP doit être activée sur tous les Commutateurs, qui inclut l'UCS. Notez que la plupart des Plateformes qui incluent l'UCS ont la surveillance IGMP activée par défaut.

Conseil : Ces guides de configuration sont pour des Commutateurs de Cisco. Ils incluent des détails sur la façon dont implémenter des modes différents de Microsoft NLB.

Une installation de base de NLB, les Noeuds peut être les virtual machine (VMs) ou l'installation de nu-métal du SYSTÈME D'EXPLOITATION de Windows Server, est affichée dans ce diagramme.

NLB VLAN 10 qui a l'IP de sous-réseau 10.1.1.0 /24. L'adresse MAC est tronquée par souci 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 de Microsoft NLB

Entrée statique d'ARP sur les points en amont du commutateur SVI à l'adresse 10.1.1.1 de VIP au MAC 01.

Les Noeuds de Microsoft NLB envoient le rapport d'adhésion IGMP. Notez que la table de surveillance IGMP peut prendre 30-60 secondes pour la remplir.

Avec la surveillance IGMP et le VLAN querier, la table pillante est remplie avec l'adresse MAC et les groupes NLB qui indiquent les ports L2 corrects.

  1. les clients de Hors fonction-sous-réseau envoient le trafic à l'adresse 10.1.1.1 de VIP NLB.
  2. Ce trafic est conduit dans l'interface VLAN 10 qui emploie une entrée statique d'ARP afin de résoudre l'adresse MAC (01) du VIP NLB.
  3. Puisque c'est une destination de trame de Multidiffusion, il est expédié par table de surveillance IGMP.
  4. La trame arrive à tous les Noeuds NLB (noeud A, B, C).
  5. La batterie NLB emploie son algorithme d'Équilibrage de charge afin de déterminer quel noeud entretiendra l'écoulement. Seulement un noeud répond.

Voir le ces pour en savoir plus de documents :

Considération spéciale pour le Nexus 1000v

Le Nexus 1000v prend en charge seulement le mode de Microsoft NLB d'unicast. Ainsi sur des déploiements du Nexus 1000v avec l'UCS, le mode de la Multidiffusion IGMP fonctionnera seulement après que vous désactiviez piller sur le Nexus 1000v. Quand ceci est fait, des paquets de Microsoft NLB sur ce VLAN sont inondés en tant que Multidiffusion inconnue.

Afin de réduire l'incidence de l'inondation :

  1. Désactivez piller seulement sur ce VLAN dans le Nexus 1000v.
  2. Utilisez un VLAN dédié pour le trafic de Microsoft NLB.

Vérifiez

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

Dépannez

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

Informations connexes


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118262