Nexus 5548 -> Virtual Connect -> vSphere, correct design?

[Paul]

Recent zijn we voor een blade enclosure (HP c7000) overgegaan van 1 GBit Cisco-switches interconnects naar HP Flex-10 modules. Omdat die dingen toch iets anders in elkaar zitten dan ik had gedacht weet ik niet zeker of ik wel alles goed heb ikgesteld, en dat is waarom ik dit topic open

Eerst de topologie: We hebben een VSS-core (2x Cisco 6509 die samen één zijn) met port channels naar 2 stuks Cisco Nexus 5548 in vPC (die twee lijken voor client devices samen één maar intern doen ze maar alsof).

Van de Nexus-laag lopen er port channels (LACP, één Po per interconnect) naar de Flex-10-modules. Intern knopen de Flex-10-modules zichzelf ook aan elkaar met interne uplinks. Samen vormen ze één Virtual Connect-domein. Alle fysieke poorten en port channels staan op de Cisco's op switchport mode trunk.

Plaatje (poorten zijn ter indicatie, maakt als het goed is voor de principes niet uit):


Op iedere Flex-10-module is een Shared Uplink Set aangemaakt met alleen de uplinks van die module. Op die manier zijn beide poorten active. Maak ik er één grote SUS van dan staat de helft van de poorten standby ipv active. Ik heb dus UplinkSet_Links en UplinkSet_Rechts.

Ik wil/kan geen poorten 'opofferen' aan VLAN Tunneling dus ik zit helaas vast aan Mapped Mode.

Omdat ik 2 uplinkSets heb, moet ik ieder VLAN ook 2x definieren:
Network_10_Links
Network_10_Rechts
Network_11_Links
Network_11_Rechts
...
Network_99_Links
Network_99_Rechts

Tot slot maak ik 6 virtuele netwerkadapters aan in het server profile, 3 op 'links' en 3 op 'rechts, met daaraan de volgende netwerken toegekend:
vmnic0 - Netwerk_10_Links
vmnic1 - Network_10_Rechts
vmnic2 - Netwerk_11_Links
vmnic3 - Network_11_Rechts
vmnic4 - Alle 'links'-netwerken behalve 10 en 11
vmnic5 - Alle 'rechts'-netwerken behalve 10 en 11

In VMware hang ik vmnic0 en vmnic1 aan de vSwitch met de VMkernel voor management, vmnic2 en vmnic3 hang ik aan de vSwitch met de VMkernel voor vMotion en vmnic4 en vmnic5 hang ik aan de dvSwitch met de server-VLANs.

Uitgangspunt voor dit geheel was HP Virtual Connect FlexFabric Module and VMware vSphere 5 maar in ons geval betreft het Flex-10 ipv FlexFabric en vSphere 4.1 ipv 5

Mijn vragen hierbij zijn:
- Klopt dit een beetje?
- Klopt het dat een Server Profile maar aan exact één server gekoppeld kan zijn en ik bij het toevoegen van een VLAN dit dus op 2 (SUS) + 2x (aantal VMware hosts) plekken moet doen in de VCM?
- Waarom zie ik 0,4% discards op de individuele poorten van de SUS? Counters op de Nexus laten minder dan 3 error packets zien terwijl de discards in de miljoenen lopen.

[ Voor 4% gewijzigd door Paul op 19-06-2013 16:44 ]

[WhizzCat]

Ik heb geen idee waarom je die errors ziet maar je concept lijkt in principe correct te zijn. Ik ga je even een dm sturen met een uitgeklede versie van ons blade technisch ontwerp. Dat is gebaseerd op hp procurve, masr wel met c7000 en die flex apparaten. Allicht kun je daar nog iets mee.

Je Server profile kan idd maar aan 1 server gekoppeld zijn. Waarom weet ik niet, maar dit is zoals het is. Mijn TO is vrij helder met screenies, dus dat zou je een eind op weg moeten helpen

Edit,

HP vind het trouwens hip om je failover weer op de blade server zelf te doen ipv aan je netwerk meuk over te laten. Dat is ook een beetje onderdeel van het spelletje. Dus op OS niveau met hp teaming en consorten. Vandaar dat die flex wat raar omgaat met netwerk. In principe is het geen switch meer maar een end device.

[ Voor 25% gewijzigd door WhizzCat op 19-06-2013 22:33 ]

[erikver]

Mag ik vragen waarom gekozen is voor de HP Flex-10 modules en niet voor de Cisco Nexus B22HP Fabric Extenders?

Wij zijn onlangs overgestapt van 1GB passtrough naar de B22HP Fabric Extenders. Wij hebben juist gekozen voor dit type omdat de rest van het netwerk ook Cisco gebaseerd is net zoals bij jullie. Wellicht dat het aan mij ligt maar de HP virtual connect infrastructuur komt op mij niet bepaald logisch over.

[Paul]

WhizzCat schreef op woensdag 19 juni 2013 @ 22:22:
Ik ga je even een dm sturen met een uitgeklede versie van ons blade technisch ontwerp.

Tnx, inzicht hoe anderen het doen is altijd fijn Online staan wel 1 of 2 dingen maar het meeste is flink ingezoomd op 1 kabeltje of juist tever uitgezoomd Dat is gebaseerd op hp procurve, masr wel met c7000 en die flex apparaten. Allicht kun je daar nog iets mee.

Dus op OS niveau met hp teaming en consorten. Vandaar dat die flex wat raar omgaat met netwerk. In principe is het geen switch meer maar een end device.

Het probleem dat ik een beetje met het concept is, dat ik nu een port channel heb naar de linker Flex-10 en een port-channel naar de rechter Flex-10, en VMware maakt weer een port channel / NIC team van dingen die door die port channels komen. Aan de Cisco kant zijn die 2 port channels die naar de afzonderlijke interconnects gaan niet aan elkaar gekoppeld. VMware denkt dus te kunnen LACP'en maar noch de Nexus noch de Flex-10 heeft dat door... Als het werkt (en performt), waarom niet, maar toch

erikver schreef op donderdag 20 juni 2013 @ 15:01:
Mag ik vragen waarom gekozen is voor de HP Flex-10 modules en niet voor de Cisco Nexus B22HP Fabric Extenders?

Geen idee, de Flex-10 modules zijn gekocht voordat ik hier kwam werken, het werd alleen tijd ze daadwerkelijk in te gaan zetten Als ik de datasheet van die FEX er even naast houdt lijk ik in ieder geval voor VMware een duidelijk voordeel te zien: 8 ipv 2 NICs

We zitten midden in de aanschaf van nog een paar enclosures en daar komen FlexFabric-modules in waardoor we HC mezzanines en SAN-interconnects uit kunnen sparen.

Wellicht dat het aan mij ligt maar de HP virtual connect infrastructuur komt op mij niet bepaald logisch over.

De verkooppraatjes waren goed, de implicaties worden (nu we het gekocht en ingezet hebben) langzaam duidelijk.

In een later stadium eens kijken of we het aanmaken van associated networks en het koppelen aan server profiles ergens kunnen scripten of zo, want aan het ESX-cluster worden regelmatig VLAN's toegevoegd, en dat is best veel rondklikken (en mogelijk fouten maken) in de interface...

[bigfoot1942]

Paul schreef op donderdag 20 juni 2013 @ 15:55:
[...]
Het probleem dat ik een beetje met het concept is, dat ik nu een port channel heb naar de linker Flex-10 en een port-channel naar de rechter Flex-10, en VMware maakt weer een port channel / NIC team van dingen die door die port channels komen. Aan de Cisco kant zijn die 2 port channels die naar de afzonderlijke interconnects gaan niet aan elkaar gekoppeld. VMware denkt dus te kunnen LACP'en maar noch de Nexus noch de Flex-10 heeft dat door... Als het werkt (en performt), waarom niet, maar toch
[...]

VMWare kan überhaupt geen LACP. De enige manier om echt LACP te doen is binnen de VM, ik heb het idee dat je dit wilt gaan doen.
Dan heb je een andere beperking te pakken, een LACP verbinding kan in principe niet over niet-gestackte switches. Ik betwijfel of die Flex switches dat kunnen aangezien je geen LACP uplink kan bouwen over beide switches.. SLB zou wel werken maar dan moet je dus niet verwachten dat je VM beide switches actief benut. Welke situatie je krijgt wanneer je LACP denkt te doen maar dit niet werkt zijn 1 van de volgende:
1. je werkt actief op 1 verbinding. de andere doet failover
2. je hebt een port-flapping probleem, worstcase krijg je STP issues en wordt een uplink poort geblokkeerd...

Heb dus zelf geen ervaring met HP meuk, dat had je vast wel door...

[blaataaps]

bigfoot1942 schreef op donderdag 20 juni 2013 @ 19:45:
[...]

VMWare kan überhaupt geen LACP.

Jawel. Hoewel ik nu pas zie dat hij nog op 4.1 zit.

[ Voor 23% gewijzigd door blaataaps op 20-06-2013 19:52 ]

[Paul]

We gaan 'binnenkort'™ over op VMware 5.1 en we hebben een licentie voor een dvSwitch. Ik wil in ieder geval geen LACP doen binnen een VM, heeft dat zin? Een guest heeft al 10 GBit, 20 GBit heb ik niet nodig en als alles goed is ingericht regelt VMware + je infrastructuur de redundancy

De reden dat ik over LACP begin is omdat ik naar een verklaring voor die discards zoek. 0,4% valt op zich wel mee, maar het zijn wel retransmits natuurlijk.

[Bl@ckbird]

Als je Enterprise plus licenties hebt met de distributed switch van VMware, kan je deze vervangen door de Nexus 1000v. Je kan dan gewoon LACP doen en andere NX-OS features. Bovendien kan je switch opnemen in je netwerk management van je Cisco spullen. Nexus1000v is gratis. De advanced versie is wel betaald. Een evaluatie versie is ook beschikbaar als je wil testen.

Als je een support contract op de hardware hebt, kan je eventueel een support case loggen bij Cisco. Ze zijn ook gewend om te troubleshooten op Cisco hardware i.s.m. third party hardware. Met VMware hebben ze een samenwerkingsverband dat ze samen aan supportcase werken, zodat je single point of contact hebt.

[bigfoot1942]

Paul schreef op vrijdag 21 juni 2013 @ 09:03:
We gaan 'binnenkort'™ over op VMware 5.1 en we hebben een licentie voor een dvSwitch. Ik wil in ieder geval geen LACP doen binnen een VM, heeft dat zin? Een guest heeft al 10 GBit, 20 GBit heb ik niet nodig en als alles goed is ingericht regelt VMware + je infrastructuur de redundancy

De reden dat ik over LACP begin is omdat ik naar een verklaring voor die discards zoek. 0,4% valt op zich wel mee, maar het zijn wel retransmits natuurlijk.

Check, als je gewoon port-id loadbalancing doet (default) kan je idd dit zonder poblemen aan je (d)vswitch knopen als uplinks. Blijft wel de vraag staan waar die retransmits vandaan komen. Je hebt je MTU sizes overal goedstaan?

[Paul]

Hmm, Nexus 1000v 'gratis', daar wil ik wel even mee stoeien.

Of de MTU _overal_ goed staat, wie zal het zeggen, dat zijn ongeveer 3000 machines Op de Nexus-laag in VMware en op de Flex10 staat het, voor zover ik heb kunnen achterhalen, allemaal default / 1500.

[p.m.]

Paul schreef op donderdag 20 juni 2013 @ 15:55:

In een later stadium eens kijken of we het aanmaken van associated networks en het koppelen aan server profiles ergens kunnen scripten of zo, want aan het ESX-cluster worden regelmatig VLAN's toegevoegd, en dat is best veel rondklikken (en mogelijk fouten maken) in de interface...

Je gaf aan geen gebruik te willen maken van een tunnel, op zich is dat wel jammer. Zeker als er regelmatig vlans bij komen, zou het mooi zijn om die via een trunk binnen te laten komen en dan te tunnelen naar ESX alwaar je ze laat uitkomen op een distributed switch, waar je ze untagged. Dan hoef je niet elke keer de VC in om een vlan toe te voegen. Nadat je het vlan hebt toegevoegd op de trunkpoort hoef je alleen maar een nieuwe portgroup aan te maken in de vds en klaar.

[Paul]

p.m. schreef op vrijdag 21 juni 2013 @ 14:49:
Je gaf aan geen gebruik te willen maken van een tunnel

Ik wil het wel gebruiken, graag zelfs, maar die modules kunnen dat niet zonder dedicated uplinks, als ik alle documentatie goed heb gelezen.

Dan moet ik dus meer uplinks aan gaan sluiten om op twee 'opgeknipte' NICs het management VLAN te zetten, op twee NICs het vMotion VLAN en op 2 NICs de trunk.

Nu valt daar mogelijk nog wel omheen te werken door 3 (of 6, net hoe je kijkt) trunks aan de blade te geven en een VLAN ID toe te wijzen aan de VMKernels, maar dan zit ik er mee dat er (in ieder geval momenteel) niet alleen VMware hosts in het enclosure zitten en ik dus toch aan een aantal blades een 'switchport mode access'-achtige poort moet toekennen.

Zoveel poortjes heb ik niet op de Nexus 5K

Binnenkort™ komen er meer enclosures en gaan we enclsoures dedicaten aan bepaalde rollen. Dan kan ik dus wel alles tunnelen in de enclosures met enkel VMware hosts Tot die tijd willen we wel graag een fatsoenlijke config voor ons ESX-cluster.

[ Voor 14% gewijzigd door Paul op 21-06-2013 15:03 ]

[p.m.]

Je zou management + vmotion kunnen combineren, die laat je bijv. middels een trunk op X1 en X2 uitkomen. Management verbruikt niet veel bandbreedte, vMotion is natuurlijk wel lekker als dat een beetje vlot gaat.
Dan zou je een tunnel kunnen doen op X3 en X4 voor het VM-verkeer en dat wordt dan untagged op de ESX-hosts. Dan houd je X5 en X6 over, in een shared uplink set, waarop je middels een trunk de vlans voor de niet-ESX hosts laat binnenkomen. Hierop maak je in de VC netwerken aan, die kun je vervolgens per server profile aan de (niet ESX-)blades koppelen. 't is maar een idee

[Paul]

p.m. schreef op vrijdag 21 juni 2013 @ 16:00:
trunk op X1 en X2 [..] tunnel kunnen doen op X3 en X4 [..] X5 en X6 over, in een shared uplink set

Euhm, dat zijn 12 touwtjes per enclosure terwijl ik er nu 4 gebruik en net heb aangegeven niet meer (upstream) poorten beschikbaar te hebben

[p.m.]

Paul schreef op vrijdag 21 juni 2013 @ 16:04:
[...]
Euhm, dat zijn 12 touwtjes per enclosure terwijl ik er nu 4 gebruik en net heb aangegeven niet meer (upstream) poorten beschikbaar te hebben

pardon, ik miste dat stukje even

Nou, voor als je ooit nog eens heel veel poorten over hebt dan.