Chiarimenti vswitch

[tcampio]

Ciao a tutti,

avrei bisogno di capire meglio come funziona il vswitch di vmware. Mi spiego: abbiamo un enclosure da 4 blade con 2 virtual connect (active/passive). Lato rete abbiamo fatto creare un trunk da 4gb e creato uno shared uplink set su cui sono attestati 4 link attivi e 4 in standby.

Lato vmware abbiamo la management, la vmkernel, il vswitch e le varie vlan. Le 4 lan sono in teaming e nel load balancing e' settata l'opzione "Route based on the originating virtual port ID".

Questa la premessa. Da un'analisi fatta lato rete pare che il traffico non venga "spalmato" su tutte le nic, ma soprattutto durante la notte, quando girano i backup il traffico passa tutto da una singola nic (che di notte in notte cambia).

E' normale? E' possibile lato vmware implementare un vero load balancing che spalmi il traffico su tutte le nic?

Grazie

[AndreTheGiant]

L'aggregazione delle schede e delle linee non corrisponde a moltiplicare la banda disponibile.

Proprio per come funziona l'IP hash, dati 2 IP (sorgente e destinazione) solo 1 scheda sarà utilizzata!

Su diverse connessioni la media e la statistica darà un traffico distribuito, ma quando è solo la connessione verso il backup server... allora non c'è molto da fare.

[tcampio]

Non mi torna molto. Se lato rete e' stato creato un trunk che permette di avere 4 GB, perche' non si ha un'ampliamento della banda?

Se ho capito bene quello che tu mi hai spiegato,  ogni vm avra' una connessione punto punto, passando da un singolo cavo. Quindi, in teoria a me non serve a nulla avere un portchannel a 4 GB , visto che la singola vm si connette a 1 GB.

Altra domanda: saturata la banda della linea su cui si attesta quella macchina, i pacchetti cominciano a passare su un altro cavo, o finisce per andare a tappo?

[ldelloca]

Ciao,

funziona così anche nel mondo fisico, ad esempio connettendo due switch tra di loro tramite etherchannel/802.3ad. Hai un trunk di 4 gb, composto però sempre da 4 linee da 1 gb. Ci guadagni comunque perchè gli switch non gestiscono connessioni punto-punto ma instradano connessioni tra numerosi endpoint, che possono essere VM o server fisici.

Anche se ogni connessione IP-IP passano sempre da un solo canale, avrai in contemporanea più connessioni punt'-punto, e queste possono essere instradate sui vari canali, aumentando quindi effettivamente la banda disponibile.

Per l'altra domanda, no se una connessione punto-punto va a tappo, i pacchetti non possono usare anche l'altro canale. I casi d'uso di connessioni 1 gbit riempite costantemente però non sono tantissimi, e si risolvono alla fine con le reti 10G, oppure creando sistemi multi scheda con ip differenti, però poi bisogna che l'applicativo di turno sia in grado di usarli. Ad esempio creando record multipli nei dns e invocando poi i servizi via fqdn e non via indirizzo ip.

Se vuoi approfondire l'argomento, ti consiglio tra i tanti questo link:

http://kensvirtualreality.wordpress.com/2009/04/05/the-great-vswitch-debate%E2%80%93part-3/

Ciao,

Luca.

[fbonez]

tcampio ha scritto:

Non mi torna molto. Se lato rete e' stato creato un trunk che permette di avere 4 GB, perche' non si ha un'ampliamento della banda?

I Trunk, o meglio ancora LACP sono stati ideati per interconnettere gli switch tra di loro. In base al tipo di policy L2 L3 ... cambia come viene gestito l'agregazione di banda. 2 switch collegati tra di loro faranno passare il traffico di molti host, pertanto la scelta di quale canale usare ti porterà a saturare tutti i canali. Come ti diceva Andrea, se colleghi 2 host ci sarà un collegamento punto-punto.

tcampio ha scritto:

Se ho capito bene quello che tu mi hai spiegato,  ogni vm avra' una connessione punto punto, passando da un singolo cavo. Quindi, in teoria a me non serve a nulla avere un portchannel a 4 GB , visto che la singola vm si connette a 1 GB.

La singola VM si, ma il traffico di tutte le VM sarà spalmato sui 4 canali.

tcampio ha scritto:

Altra domanda: saturata la banda della linea su cui si attesta quella macchina, i pacchetti cominciano a passare su un altro cavo, o finisce per andare a tappo?

Finisce per andare a tappo.

Ciao

[tcampio]

E' un piacere fare domande, a voi vista la competenza :smileylaugh:.

Un'altra domandina: il gruppo di rete ci suggerisce di passare da un load balance port based ad uno di tipo IP hash.

Da quello che ho letto pare che sia il modo migliore di implementare il load balance poiche' se un server si connette a piu' IP il traffico passa da piu' porte.

Al contrario i limiti sarebbero dovuti a:

1) Deve esserci dietro un'implementazione sullo switch fisico

2)il calcolo della scelta della NIC fisica viene fatto per ogni connessione, quindi se una VM comunica sempre o molto spesso solo con un IP, ESX è impegnato per fare un calcolo che darà sempre lo stesso risultato;

3)il sistema non tiene conto del carico di lavoro della NIC quindi in un ambiente ricco di VM è possibile che il calcolo restituisca una NIC fisica già fortemente utilizzata.

Concordate?

A parte la configurazione lato rete (che fara' il gruppo competente), lato mio cosa devo implementare oltre ad impostare il nuovo parametro? C'e' qualcosa a cui devo prestare particolare attenzione onde evitare che mi crolli tutta la rete? :smileysad:

Grazie ancora

[ldelloca]

Nulla, se non due cose:

- concordare i tempi di attivazione per non ritrovarti fuori rete, al massimo come trucco puoi mettere in disable tutte le nic tranne una e riaggiungerle in seguito, gli omini del network ogni tanto si incasinano e dicono che non è mai colpa loro

- soprattutto, controlla la configurazione della management network: per default ha un override sul failover order, e quindi o togli l'override in modo che erediti sempre i parametri del vswitch che lo ospita, oppure imposti manualmente ip hash anche li

Ciao,

Luca.

[tcampio]

Grazie Luca, ho aggiunto un paio di considerazioni al mio ultimo post. Ti va di commentarle?

[ldelloca]

1) Deve esserci dietro un'implementazione sullo switch fisico

questo in assoluto è il più grosso limite di questa configurazione, e il motivo per cui spesso si preferisce portID. Dato che comunque tutte e due splafonano a 1 gbits per singola connessione, col secondo si è indipendenti dal network, e ciò non solo per le battutacce sui rapporti con "quelli del network", ma anche e soprattutto perchè se devi riconnettere un nodo, cambiare schede, aggiungere un nuovo nodo, lato switch fisico devi solamente connetterlo. Ma anche lato switch si possono fare manutenzioni senza troppi problemi.

Altro vantaggio: solo switch di fascia medio-alta permettono il "cross-stack-etherchannel" chiamato in altri modi dai vari produttori. Ovvero il trunk suddiviso tra più switch. Se non lo puoi fare, tutto il trunk deve essere attestato su un unico switch fisico, che quindi diventa subito un single point of failure. Col portID suddividere gli uplink tra più switch è un attimo.

Con 5.1 e il dynamic LACP probabilmente cambieranno le cose, dato che si potrà usare finalmente il protocollo LACP a pieno. Ad esempio con l'attuale IP hash non puoi verificare lo stato del trunk dallo switch, connetti i cablaggi e "speri" che tutti i canali siano funzionanti. Infatti quando c'è qualche problema solitamente lo si scopre scollegando uno alla volta gli uplink...

3)il sistema non tiene conto del carico di lavoro della NIC quindi in un ambiente ricco di VM è possibile che il calcolo restituisca una NIC fisica già fortemente utilizzata.

Per questo devi passare al "load based team balancing" che però è disponibile solo tramite NIOC, ovvero con licenza Enteprise Plus.

Ciao.

[tcampio]

Luca,

noi abbiamo la licenza enterprise plus, ma io nel menu' a tendina del nic teaming non vedo la voce "load based team balancing".

Questa configurazione e' la migliore?

[ldelloca]

Ehm, lo puoi usare sui distributed switch, li stai usando o sono standard?

http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&externalId=1022590&sliceId=1&docTypeID=DT_KB_1_1&dialogID=420142763&stateId=1%200%20420162268

Ciao,

Luca

[tcampio]

Opps. Mi sa che mi sto infilando in un ginepraio :smileyconfused:.

Noi avevamo una licenza enterprise semplice, per cui i vswitch sono stati configurati stand alone sulle singole lame.

Adesso siamo passati ad un enterprise plus. Consigli di passare al dswitch e poi passare al load based team balancing?

E' una procedura complessa?

[ldelloca]

Ciao,

no la procedura non è complessa, anzi vSphere prevede un wizard per effettuare la migrazione sia degli uplink che delle VM a caldo e in modo che non ci siano rischi di perdere connettività.

Ci sarebbero poi una serie di discussioni infinite sull'uso esteso dei VDS, c'è chi preferisce tenere almeno la rete di management su standard per evitare problemi di gestione, ma è argomento di un altro (corposo) thread.

Potresti iniziare a passare ai distributed, e da qui "giocare" con il balancing per vedere sel il load based può aiutarti.

Ciao,

Luca.

[tcampio]

Grazie ancora Luca. Ma in condizioni normali fra port based e ip hash tu passeresti a IP hash? Perche' Ken Cline non mi sembrava cosi' convinto.. Dice che spesso e volentieri non si hanno miglioramenti nelle performance e ci si complica parecchio la vita.

[ldelloca]

No, assolutamente. Anzi i miei precedenti interventi e il link erano proprio a favore di portID, credevo si capisse ma lo ribadisco ulteriormente. Ad oggi onestamente non ho ancora trovato casi d'uso in cui dover consigliare ip hash al posto di portID. Ciao, Luca.

[tcampio]

Ora sono ancora piu' confuso. Perche' (al di la' della necessita' della configurazione lato switch fisico) sconsigli IP-Hash?

In teoria dei 2 e' quello che consente qualcosa di simile al load balancing, seppur in mancanza di bilanciamento di carico.

Scusa se insisto, ma se devo rispondere picche alla richiesta del nostro gruppo di rete voglio essere sicuro di quello che dico.

[ldelloca]

Rileggi bene i miei post precedenti, avevo spiegato pro e contro di portID vs IPhash... Ciao, Luca.

[tcampio]

Ok, mi riguardo i tuoi post passati.

Grazie.

Tony

[AndreTheGiant]

Occhio che se passi a IP hash devi essere sicuro che gli switch siano configurati in modo corretto.

[tcampio]

@AndreTheGiant si, per quello non dovrebbero esserci problemi perche' sara' il gruppo di rete ad occuparsene.

[ErreaIT]

@ tutti: questo spiega perchè alla voce "ip observed" di un dato vswitch con ip-hash composto da 2 schede, vedo che i range ip sono diversi tra le 2?

ciao

[ldelloca]

Ciao,

no gli observed ip dipendono dai segnali broadcast che le nic dei server ESXi ricevono, se una scheda riceve solo segnali unicast o multicast potrebbe non visualizzare nulla, non è un metodo infallibile...

Il metodo migliore per verificare la connettività di una nic resta sempre CDP o, se si hanno i distributed switches, anche LLDP.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006744

Ciao,

Luca

[ErreaIT]

scusa spero di non andare OT...

a 2 miei nodi esx è collegato un hp5406 ma quando visualizzo i dati del lldp mi fa vedere ovviamente gli altri switch ma non i server; c'è qualche conf. a livello di esx da attivare? devo aggiornare i driver dei miei nodi?

[fbonez]

LLDP funziona solo con i dvSwitches.

[ldelloca]

Quegli switch sono in grado di vedere anche il protocollo CDP, però devi abilitarlo sui vari vswitch, via command line. Sullo switch creato per default vado a memoria essendo fuori ufficio dovrebbe essere

esxcfg-vswitch -B both vswitch0

il parametro both serve a impostare CDP per effettuare sia trasmissione che ricezione dei pacchetti.

Ciao,

Luca.