Nothing found

  • Nexus og VMware – Lastbalansering ved bruk av VMware mekanismer (og litt Nexus magi).

    30. januar 2015 av Jon Anders Frigård under temaet Datasenter

    vPC orphan-port suspend – et av mange gotchas i et vPC design.

    I dette blogg innlegget vil jeg vise den enkle løsningen på et ganske vanlig problem som kan oppstå når man kobler inn VMware eller andre virtualiserte plattformer til datasenter nettverket. Ved å forstå sammenhengen og samspillet mellom mekanismene i serverparken og nettverket kan en redusere tjenestebrudd til et minimum, når en switch som har blitt restartet eller har feilet og kommer opp igjen.

    Topologi

    Topologi

     

    I et vPC design må en Nexus være primary og den andre secondary, sammen fremstår de som en switch for enheter koblet til med vPC. I vårt scenario, har vi som vist i topologien, et vPC mot Kjerne- /aggregeringsnettet og klassiske tilkoblinger sørover mot servere.

    I vårt Cisco Nexus vPC design har vi vanlig port-channel/singel link sørover fra hver Nexus. Dette fordi vi her vil la VMware/hypervisor ta seg av load balancing/aktiv aktiv nick teaming. Noe som er et anbefalt design av mange for VMware. Både når vi kjører multihop FCoE/Unified fabric mot Cisco UCS B Serie. Eller for eksempel har en hypervisor på en Cisco UCS C serie server koblet til et Nexus vPC par.

    I vår eksempel topologi er UCS B serie med Fabric Interconnects representert på venstre side og en stand alone C serie server på den høyre side.

    Figur 1) Trafikk pinnes/lastdeles automatisk nordover

     

    Figur 1)

    Trafikk pinnes / lastdeles automatisk nordover.

     

    Jeg ønsker å vise hvordan vi kan håndtere VMware fra Nexus siden i vårt design. Det finnes selvfølgelig mekanismer i VMware som kan ta høyde for en slik feilsituasjon, men det går jeg ikke veldig i dybden på i dette innlegget.

    I en situasjon hvor secondary blir startet om som en del av planlagt vedlikehold eller i en feilsituasjon, vil VMware automatisk repinne trafikk fra VM’s til det «friske» beinet.

     

    Figur 2) Secondary Nexus feiler og trafikk repinnes

    Figur 2)

    Secondary Nexus feiler og trafikk repinnes

     

    Når den sekundære switchen igjen kommer opp vil den blokkere trafikk på sine vPCs som en del av mekanismen for å forhindre loop i nettverket. I vår topologi er ikke servere tilkoblet med vPC, men er tilkoblet vanlige porter (standalone eller port-channel).

    VMware detekterer at sin sekundære link er oppe så den forwarder data opp linken til sekundær vPC medlem. Denne har sitt vPC nede (i minimum 240 sekunder mens vPC gjør sine tester og sjekker – 240 sec default grace timer).

    Dette fører til at trafikken for VMware sin del forsvinner i et sort hull, helt til Nexusene igjen tar opp sitt vPC. Det kan føre til store konsekvenser for vm’s som plutselig mister nettverkstilkoblingen. Samt at en kan oppleve at bare halvparten av miljøet responderer.

    Figur 4

    Figur 3)

    Trafikk fra B vm’s «Blackholes» mens vPC gjør sin «magi».

     

    Det er flere mulige løsninger på dette problemet.

    Her er noen:

    • Vi kan bruke vPC orphan port-suspend
      NX(config-if)# vpc orphan-port suspend
    • Vi kan bruke VMware beacon probing
    • Vi kan styre trafikk nordover med STP og kjøre en link for non vPC VLAN mellom 5k paret.

    I vårt design foretrekker vi 1) og jeg har nedenfor illustrert hvordan dette fungerer.

    OBS: for å kjøre kommandoen vpc orphan-port suspend på porter som allerede er medlem av en port-channel, må portene tas ut av port-channelen først for så å melde de inn igjen. Dette kan gjøres non disruptive ved at en tar en og en port og melder de tilbake etter at de har fått den nye kommandoen.

    Figur 4) illustrerer hvordan vi med denne kommandoen kan diktere oppførselen til hypervisorene som er koblet til vår Nexus infrastruktur.

    Figur 4

    Figur 4)

     

    «vPC orphan port suspend» holder de portene vi har konfigurert nede, mens vPC «rekonvergerer» slik at trafikk fra B vm’s ikke blir pinnet om når dataplanet kommer opp.

    Figur 5

    Figur 5)

     

    vPC er fullkonvergert, og vPC har tatt opp igjen nordgående port og peer link. Trafikk fra A og B vm’s pinnes som normalt.

    Hverken problemet eller løsningen er spesielt vanskelig å forstå. Hensikten er her å illustrerer hvordan et virtualisert datasenter miljø krever en helhetlig forståelse av hvordan server og nettverk henger sammen.  vPC og virtualisering kan fremstå som et minefelt, og det er viktig å lage et helhetlig design som tar høyde for funksjonalitet og tilgjengelighet. Det er stort sett flere måter å løse et problem på, men det er viktig å ha kontroll på feilhåndteringsmekanismer. Ellers kan en fort få seg en ubehagelig overraskelse.

    Gi gjerne en tilbakemelding i kommentarfeltet dersom det er ønskelig med flere innlegg med litt teknisk vinkling.

     

    Jon-Anders

    Twitter: @jonandersf

     

     

     

    Jon Anders Frigård Jon Anders Frigård Senior konsulent Jon-Anders har jobbet i Datametrix i snart 3 år, og har sin faglige hovedtyngde og spesialisering innen design/implementering av datasenter og kjerne nettverk. Han har fra tidligere en solid bakgrunn innen drift av datasenter og nettverk. På fritiden er han en aktiv jeger og friluftsmann. Han dykker også titt og ofte ned i sitt eget lille private «enterprise» lab miljø på jakt etter ny kunnskap.
    comments powered by Disqus
    Jon Anders Frigård Jon Anders Frigård Senior konsulent Jon-Anders har jobbet i Datametrix i snart 3 år, og har sin faglige hovedtyngde og spesialisering innen design/implementering av datasenter og kjerne nettverk. Han har fra tidligere en solid bakgrunn innen drift av datasenter og nettverk. På fritiden er han en aktiv jeger og friluftsmann. Han dykker også titt og ofte ned i sitt eget lille private «enterprise» lab miljø på jakt etter ny kunnskap.