VMware Global Community
tcampio
Contributor
Contributor
Jump to solution

Chiarimenti vswitch

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

Reply
0 Kudos
1 Solution

Accepted Solutions
ldelloca
Virtuoso
Virtuoso
Jump to solution

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.

Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"

View solution in original post

Reply
0 Kudos
24 Replies
AndreTheGiant
Immortal
Immortal
Jump to solution

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.

Andre | http://about.me/amauro | http://vinfrastructure.it/ | @Andrea_Mauro
tcampio
Contributor
Contributor
Jump to solution

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?

Reply
0 Kudos
ldelloca
Virtuoso
Virtuoso
Jump to solution

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.

Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
Reply
0 Kudos
fbonez
Expert
Expert
Jump to solution

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

-- If you find this information useful, please award points for "correct" or "helpful". | @fbonez | www.thevirtualway.it
Reply
0 Kudos
tcampio
Contributor
Contributor
Jump to solution

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? Smiley Sad

Grazie ancora

Reply
0 Kudos
ldelloca
Virtuoso
Virtuoso
Jump to solution

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.

Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
tcampio
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
AndreTheGiant
Immortal
Immortal
Jump to solution

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

Andre | http://about.me/amauro | http://vinfrastructure.it/ | @Andrea_Mauro
Reply
0 Kudos
tcampio
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
ldelloca
Virtuoso
Virtuoso
Jump to solution

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.

Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
Reply
0 Kudos
tcampio
Contributor
Contributor
Jump to solution

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?

Reply
0 Kudos
ldelloca
Virtuoso
Virtuoso
Jump to solution

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&doc...

Ciao,

Luca

Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
Reply
0 Kudos
tcampio
Contributor
Contributor
Jump to solution

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?

Reply
0 Kudos
ldelloca
Virtuoso
Virtuoso
Jump to solution

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.

Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
Reply
0 Kudos
tcampio
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
ldelloca
Virtuoso
Virtuoso
Jump to solution

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.

Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
Reply
0 Kudos
ErreaIT
Contributor
Contributor
Jump to solution

@ 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

Reply
0 Kudos
ldelloca
Virtuoso
Virtuoso
Jump to solution

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=100674...

Ciao,

Luca

Luca Dell'Oca | vExpert 2011-2012-2013-2014-2015-2016-2017, VCAP-DCD, CISSP #58353 | http://www.virtualtothecore.com | @dellock6 | http://www.linkedin.com/in/lucadelloca | If you find this post useful, please consider awarding points for "Correct" or "Helpful"
Reply
0 Kudos
ErreaIT
Contributor
Contributor
Jump to solution

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?

Reply
0 Kudos