Configuratievoorbeeld voor Microsoft Network Taakverdeling op UCS B Series servers

Downloadopties

  • PDF     (127.6 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (110.4 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (99.0 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:14 augustus 2014
Document-id:118262

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inleiding

In dit document wordt de implementatie van Microsoft Network taakverdeling (NLB) beschreven in de Cisco Unified Computing System-B (UCS-B)-serie met Fabric Interconnect (FI) in End-of-Host modus. Ook zijn er een aantal eisen aan de stroomopwaarts geplaatste voorzieningen die de correcte doorgifte van NLB-verkeer vergemakkelijken, die in dit document worden beschreven. De configuratiesteekproef richt zich op de multicast Internet Group Management Protocol (IGMP)-modus.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

  • Microsoft Network-taakverdeling
  • Cisco UCS B-Series servers
  • Cisco Catalyst 3800-X en/of Nexus-switches

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Achtergrondinformatie

Microsoft NLB werkt in drie verschillende operationele modi: unicast, multicast en multicast IGMP. Een groep NLB-knooppunten wordt collectief bekend als een NLB-cluster. Een NLB-cluster services één of meer virtuele IP-adressen (VIP). Knooppunten in het NLB-cluster gebruiken hun belastingsbalanceringsalgoritme om het eens te worden over welke afzonderlijke knooppunten de specifieke verkeersstroom voor de NLB VIP zal bedienen.

Dit document bevat geen specifieke implementatierichtlijnen voor Microsoft NLB op UCS. Zoals in dit document beschreven, is NLB afhankelijk van onconventionele methoden voor de levering van clustergebonden verkeer. Er is vastgesteld dat zowel multicast als multicast IGMP-modi een stabiele en consistente werking op UCS-B Series-servers lijken te hebben. Hoewel NLB-richtsnoeren voor omvangbepaling buiten het toepassingsgebied van dit document vallen, is deze oplossing over het algemeen aanbevolen voor kleinere implementaties.

Configuratie

Microsoft NLB-modi

Unicast-modus

De standaardinstelling van NLB is eenastmodus. In unicast modus vervangt NLB het eigenlijke MAC-adres van elke server in de cluster naar een gemeenschappelijk NLB-MAC-adres. Meestal iets in het bereik 02bf:xxxx:xxxx. Alle knooppunten in de NLB-cluster begrijpen wat het NLB VIP- en MAC-adres is. Verkeer, dat adresresolutie Protocol (ARP)-antwoorden bevat van NLB-knooppunten, is nooit afkomstig van het NLB MAC- of IP-adres. In plaats daarvan gebruiken NLB-knooppunten een toegewezen MAC-adres dat is gebaseerd op de host-ID van het lid. Het MAC-adres is meestal in het nummer 0201:xxxx:xxxx, 0202, 0203 enzovoort, één voor elk knooppunt in het cluster. Dit is het bronadres in Layer 2 (L2) header wanneer een ARP-verzoek wordt beantwoord. De ARP-headerinformatie bevat echter het NLB-adres. Host dat met het NLB-VIP-adres wil corresponderen, verzenden dus verkeer naar het NLB-MAC-adres.

De IEEE-conforme switches (L2-apparaten) bouwen hun MAC-adrestabel op basis van de L2-bronheader en niet de informatie in de ARP-lading. Dit betekent dat het verkeer dat naar het NLB-cluster wordt doorgestuurd naar het NLB-adres, dat nooit de bron van het verkeer is. Daarom wordt het verkeer dat bestemd is voor het NLB-adres overstroomd als onbekend unicast.

Voorzichtig: NLB in de modus unicast is afhankelijk van ongekende overstroming van unicast voor de levering van clustergebonden pakketten. De onicastmodus werkt niet op UCS B-Series servers wanneer de FI in End-Host Mode is, aangezien onbekende eenastframes niet overstroomd worden zoals vereist door deze modus. Zie Cisco Unified Computing System Ethernet-switchingmodules voor meer informatie over het L2-verzendgedrag van UCS in End-of-Host modus.

Multicast/multicast IGMP-modus

Multicast-modus wijst het virtuele IP-adres van het cluster-centrum toe aan een autoriteit voor niet-internet Assigned Numbers (IANA) voor multicast MAC-adres (303xx.xxxx.xxxx). IGMP-snooping registreert dit adres niet dynamisch, wat leidt tot overstroming van het NLB-verkeer in het VLAN als onbekende multicast.

Multicast IGMP-modus kent het virtuele IP-adres van het cluster en een multicast MAC-adres binnen het IANA-bereik (1:01:00:5E:XX:XX:XX) toe. De geclusterde knooppunten verzenden IGMP-lidmaatschapsrapporten voor de geconfigureerde multicast-groep en zo vult de FI dynamisch zijn IGMP-snoopingtabel in om naar de geclusterde servers te wijzen.

Er is een klein operationeel voordeel voor het gebruik van de multicast IGMP-modus, aangezien de overheidsinformatie (via IGMP-lidmaatschapsrapporten en IGMP-snooping) over de betrokken L2-poorten zowel upstream als downstreamer kan worden bewaard. Zonder optimalisatie van IGMP-sneoping is NLB afhankelijk van onbekende multicast-overstromingen in het NLB-VLAN voor levering aan het cluster via de door UCS aangewezen broadcast/multicast-ontvanger. In releases later dan UCS release 2.0 wordt de aangewezen uitzending/multicast ontvanger op basis van per-VLAN geselecteerd.

Voorzichtig: Ongeacht de gekozen versie van de multicast modus, vereist het NLB-VIP-adres een statische ARP-ingang op het upstream-apparaat, dat doorgaans de Switched Virtual Interface (SVI) voor VLAN is. Dit is een tijdelijke oplossing aangezien de ARP-antwoorden van de NLB-knooppunten een multicast MAC-adres bevatten. Per RFC 1812, zouden ARP antwoorden die een multicast MAC-adres bevatten, moeten worden genegeerd. Daarom kan het VIP MAC-adres niet dynamisch worden geleerd op RFC 1812-conforme apparaten.

Hier wordt een samenvatting gegeven van de stappen die nodig zijn om NLB in multicast IGMP-modus te ondersteunen:

  1. Statische ARP-vermeldingen voor Virtual NLB IP-adressen zijn doorgaans op VLAN SVI actief. Als u Hot Standby Router Protocol (HSRP) of First Hop Redundancy Protocol (FHRP) gebruikt, zorg er dan voor dat beide apparaten de statische ARP-ingang hebben.
  2. Een IGMP-snooping in het NLB-VLAN. In releases later dan UCS release 2.1 wordt snooping querier functionaliteit ondersteund in UCS Manager.
  3. IGMP-snooping moet op alle switches worden ingeschakeld, inclusief UCS. Merk op dat de meeste platforms die UCS omvatten IGMP-snooping standaard ingeschakeld hebben.

Tip: Deze configuratiegidsen zijn voor Cisco switches. Ze bevatten informatie over het implementeren van verschillende modi van Microsoft NLB.

In dit diagram worden de basisinstellingen van NLB weergegeven, de knooppunten kunnen virtuele machines (VM's) of de installatie van Windows Server OS met metalen voorwerpen zijn.

NLB VLAN 10 dat IP-plus 10.1.1.0/24 heeft. Het MAC-adres is ingekort.

NLB VIP (MAC = 01, IP = 10.1.1)

KNOOPPUNT-A (MAC = AA, IP = 10.1.1.10)     

KNOOPPUNT-B (MAC = BB, IP = 10.1.1.11)

KNOOPPUNT-C (MAC = CC, IP = 10.1.1.12)

Microsoft NLB-gegevensstroom

Statische ARP-vermeldingen op de stroomopwaartse schakelaar SVI wijzen naar VIP-adres 10.1.1.1 naar MAC 10.1.

Microsoft NLB-knooppunten verzenden het IGMP-lidmaatschapsrapport. Merk op dat de IGMP-snoopingtafel 30-60 seconden kan kosten om te bevolken.

Met IGMP-snooping en de VLAN-querier wordt de snoopingtabel bevolkt met het NLB-adres en de groepen die naar de juiste L2-poorten wijzen.

  1. Off-net klanten verzenden verkeer naar NLB VIP adres 10.1.1.1.
  2. Dit verkeer wordt in de VLAN 10-interface routeerd die een statische ARP-ingang gebruikt om het MAC-adres (10) van de NLB VIP op te lossen.
  3. Aangezien dit een multicast frame-bestemming is, wordt deze per de IGMP-snoopingtabel doorgestuurd.
  4. Het frame wordt aangeleverd op alle NLB-knooppunten (knooppunt A,B,C).
  5. Het NLB-cluster gebruikt zijn taakverdelingsalgoritme om te bepalen welk knooppunt de stroom zal ondersteunen. Slechts één knooppunt reageert.

Zie deze documenten voor meer informatie:

Speciale overweging voor Nexus 1000v

Nexus 1000v ondersteunt alleen de unieke Microsoft NLB-modus. Dus bij implementaties van Nexus 1000v met UCS zal de multicast IGMP-modus alleen werken nadat u het sneeuwen op Nexus 1000v hebt uitgeschakeld. Wanneer dit wordt gedaan, worden de pakketten van Microsoft NLB op dat VLAN overstroomd als onbekende multicast.

Zo minimaliseert u de gevolgen van overstromingen:

  1. Schakel alleen snooping op dat VLAN uit in Nexus 1000v.
  2. Gebruik een specifiek VLAN voor Microsoft NLB-verkeer.

Verifiëren

 De verificatieprocedures voor de in dit document beschreven voorbeelden van configuratie worden in de desbetreffende delen beschreven.

Problemen oplossen

 Er is momenteel geen specifieke troubleshooting-informatie beschikbaar voor deze configuratie.

Gerelateerde informatie

TAC Authored

Bijgedragen door Cisco-engineers

  • Charles Stizza, Vishal Mehta, and Vincent La Bua
    Cisco TAC Engineers.

Was dit document nuttig?

FeedbackFeedback

Contact Cisco

Dit document is van toepassing op deze producten