Ik heb al enkele keren een vraag gehad van klanten wat het beste is voor NIC teaming en load balancing op ESX 3.x , ESX 4 hosten.
Na verschillende forums en documentatie gelezen te hebben ben ik tot de conclusie gekomen dat dat is 2 of meerdere physieke adapters in een vSwitch en dan load balancing instellen op "route based on ip hash".
je moet dan ook aan de switch kant een configuratie maken van een etherchannel en ook zorgen dat de load balancing mode op src-dst-ip staat.
Als deze gekoppeld zit aan een cisco switch heb ik het volgende geconfigureerd op de switch

Elke interface waar de netwerk kaarten van de esx op zitten zullen opgenomen moeten worden in een etherchannel. voer het volgende commando op de interface in
channel-group 20 mode on (nummer is vrij te kiezen)

er wordt dan een interface port-channel 20 aangemaakt

controlleren load balancing mode kan met het commando
show etherchannel load-balancing
hier moet dus staan src-dst-ip (op een cisco WS-4510R-E met suppervisor module 6-E is dat default) anders moet je deze goed zetten. Dit geld voor de hele switch.

Deze configuratie heb ik al bij enkele klanten weg gezet en werkt!

Als iemand andere ervaringen of betere suggesties heeft hoor ik dat graag.

Een wijziging op je switch is niet nodig, er word geen gebruik gemaakt van enige form van link aggregation/trunking. Bij ip-hashing wordt 'geload-balanced' op basis van mac-return, de switch weet naar welke poort(adapter) het tcp/ip pakketje retour moet.

De wijziging die jij in je switch gedaan hebt zorgt er alleen maar voor dat bij verkeer naar je ESX host de data naar de pNIC's in je team wordt verzonden (je kan het zien als een static ARP met de ALLE MAC's van al je pNIC's), dit levert dus alleen maar dubbel RX verkeer (gezien vanuit je host) op.
Zonder trunk zal dat alleen maar naar de laatste pNIC zijn welke in de (dynamic) ARP tabel staat.. is deze niet bekend (kleine kans, maar bij lange idle time wel mogelijk) zal middels een who-has een discover worden gedaan en zal je ESX host automatisch load-balancen door te antwoorden vanaf de pNIC met de minste load.
Verkeer geïnitieerd vanuit je host zal er automatisch toe leiden dat de dynamic ARP table van je switch continue geupdate wordt (als de host veel wisseld tussen pNIC's).

Hoe dan ook is load balance op ip-hash altijd de beste (van de beschikbare) mogelijkheden qua performance MITS je switch snel genoeg is in het updaten van de dynamic ARP tables en je netwerk niet al te groot is (<4000 mac's in 1 subnet) en/of je switch RST (rapid spanningtree) kan.

Denk je voor deze heldere uitleg.

alleen als ik op de esx host "route based on ip hash" instel en doe niets op de cisco switch verlies ik connectie naar de vm machines die achter de pNIC's zitten.
als ik dan een port-channel aanmaak met daarin de pNIC's komt de connectie weer terug.

Ik zou zeggen, probeer het eens met een standaard unmanaged swtch, dan zal je zien dat Cisco er default vaak niet goed mee overweg kan.

Meestal komen dit soort problemen door een verkeerde instelling en/of implementatie van (R)STP. Met name op een Cisco die daar vele varianten van kent i.c.m. switches die geen Cisco-proprietary protocollen (zoals OOK een vSwitch) ondersteunen. Gelukkig kan je dit PER vlan instellen (Cisco-proprietary PVST).

Wat ook mogelijk is, dat je poorten nog op auto LACP mode staan o.i.d, daar kan Cisco (maar ook 3Com, HP en Huawei) niet mee overweg i.v.m. ip-hashing.
Een andere optie is nog dat je poorten door ULD een shutdown krijgen doordat je vSwitch via meerdere interfaces hetzelfde MAC doorgeeft (een teken van een mogelijke loop).

Ook bij iSCSI en dan met name Equallogic die ook op basis van ip-hash verstuurd (ontvangen gaat via het group-addres, dat gaat meestal wel goed omdat iedere NIC daar op antwoord) merk je (extreme !) performance verschillen op een 3Com of HP switch.. met Cisco moet je dan RST aanzetten anders heb je dezelfde beroerde performance als de 3Com.

Het zelfde zie je ook terug bij Microsoft's network loadbalance protocol (op basis van mac cloning), daar snappen de Cisco switches standaard ook niets van en gaan het verkeer maar broadcasten. Een static arp met tx port mirror lost dat op maar failover ben je dan kwijt omdat er er altijd 1 poort 'master' blijft.

Mocht je management netwerk bijvoorbeeld een ander VLAN zijn zou ik daar RSTP eens op uitzetten of zorgen dat je poorten geen shutdown krijgen. Voor iSCSI is dat ook aan te raden MITS je nergens natuurlijk een dubbele link hebt (die niet als trunk/link-aggregation is geconfigureerd).

foutje.

Dank je voor deze uitgebreide uitleg.
Volgens mij treed er geen probleem op met spanning tree. Maar hoe zou de spanning tree moeten staan volgens jou?

hoe kan je een poort het auto lacp uit zetten dan?
het commando "channel-group 20 mode on" (optie on geen pagp en lacp)
zet lacp uit maar dan maak je dus wel een channel.

dus mijn sinds moet je dus wel een channel maken.

Mijn config is altijd alles auto, LACP uit geen trunk/portgroup en geen static ARP's. Mits het een appart vlan is waar geen loops gecreëerd kunnen worden (R)STP uit.. anders alleen aan als er RSTP wordt ondersteund.

ben geen cisco expert maar voor zover ik weet moet je bij ip hash balancing een channel group (802.3ad) aanmaken.

zie pagina 24 van deze pdf: http://www.vmware.com/files/pdf/vmi_cisco_network_environment.pdf

rest van de pdf is ook wel zinnig

Dat is gewoon omdat Cisco zich niet aan de standaarden houdt.. het is (zoals ik eerder al schreef) een oplossing voor het probleem maar niet een mooie. Het zorgt ervoor dat al het RX verkeer (vanuit de host gezien) naar ALLE pNICS wordt gezonden doordat een channel group al het verkeer mirrort op alle poorten als het niet weet waar het naar toe moet aangezien het vanuit de ESX host gezien geen 802.3ad is.
Een van de weinige switches die hier wel helemaal goed mee omgaan zijn de HP procurves 2800 series en hoger.

Dan houdt 3Com zich ook niet aan de standaarden want daar moet ik voor IP-hash toch ook echt een aggregated link aanmaken. Is ook precies zoals het vmware het verteld: voor de default out-ID en alternatief out-mac hoe je de switch niet te configureren. Voor out-ip wel. Volgens vmware is het 802.3ad. En inderdaad: als ik niks instel op de switch werkt out-ip niet en als ik m vertel dat het 802.3ad is werkt het wel. Dat was bij ESX 2.1 zo en si bij ESX4 nog steeds zo. Dan trek ik de logische conclusie dat vmware kennelijk 802.3ad praat in out-ip mode. out-ID (default) en out-mac (rarely used) is een heel ander verhaal.