Uno switch virtuale può essere connesso a più interfacce di rete fisiche (quelle dell'host ESXi) e sfruttare la presenza di più uplink per il collegamento con la rete fisica; la funzionalità che permette l’uso contemporaneo di più uplink è chiamata NIC Teaming.

Le interfacce fisiche di uno stesso team devono trovarsi nello stesso dominio di broadcast. Per intenderci, non devono essere attestate su porte appartenenti a VLAN diverse. Il NIC Teaming è configurabile sia a livello di switch virtuale che di port group. Se per un port group non vengono specificate impostazioni, allora vengono ereditate le impostazioni dello switch virtuale. Le impostazioni possibili riguardano principalmente due aspetti:il bilanciamento del carico e i failover.

• Il bilanciamento del carico (Load Balancing) permette di distribuire il traffico tra macchine virtuali e rete fisica attraverso 2 o più uplink. In pratica si ottiene un throughput più alto, e la quantità di dati trasmessi nell'unità di tempo sarà superiore a quella disponibile con un solo uplink.
• Il failover è il meccanismo per cui il traffico di rete viene instradato su un'altra interfaccia di rete fisica quando la prima ha un problema.

I parametri di Teaming e failover

Load Balancing

VMware vSphere prevede tre diversi metodi per il bilanciamento del carico:

●     Route based on the originating port ID - con questo metodo il traffico in uscita dalla rete virtuale viene mappato ad una specifica interfaccia fisica. L’algoritmo utilizzato prevede che l’interfaccia fisica sia scelta in base all’ID della porta virtuale su cui è collegata la VM. Per capire meglio, ogni macchina virtuale ha un port-ID che identifica la sua associazione allo switch virtuale: il carico è bilanciato in base all'ID e nient'altro. E' un meccanismo che abbraccia tutti i protocolli. Quando si utilizza questa impostazione, il traffico in uscita da un'interfaccia virtuale è inviato sempre allo stesso uplink (stessa interfaccia fisica dell'host ESXi), purché non avvenga un failover verso un'altra interfaccia fisica. Anche le risposte sono ricevute sulla stessa interfaccia fisica, perché lo switch fisico esterno memorizza l'associazione con essa (associazione porta - indirizzo MAC). Questa impostazione fornisce una distribuzione uniforme del traffico se il numero di interfacce di rete virtuali è superiore al numero di uplink fisici.

Con l'instradamento basato sul port ID, il traffico in uscita da una macchina virtuale è mappato in modo statico a un'interfaccia fisica: non importa quanto sia occupata la scheda di rete, il traffico continuerà a transitare per la stessa scheda e non sarà mai inoltrato verso un'interfaccia inattiva o più scarica (a meno di failover). Tuttavia, poiché il calcolo per la scelta della scheda di rete è eseguito solo una volta, questo metodo impegna pochissimo la CPU. Inoltre, poiché ci si basa sulle porte, se una macchina virtuale è stata configurata con più interfacce di rete virtuali, si ha la certezza che per ognuna di queste saranno utilizzati uplinks diversi.

●     Route based on source MAC hash - con questo metodo l'instradamento è basato sull'hash dell'indirizzo MAC sorgente. In pratica il traffico in uscita da una VM è indirizzato ad uno specifico uplink in base all'indirizzo MAC dell'interfaccia virtuale. Valgono le stesse considerazioni del punto precedente: il traffico proveniente da un'interfaccia di rete virtuale è inviato sempre alla stessa scheda fisica dell'host ESXi ed anche le risposte vengono ricevute sulla stessa scheda fisica, in quanto lo switch fisico esterno memorizza l'associazione con essa (associazione porta - indirizzo MAC). Una macchina virtuale non può utilizzare più di un uplink a meno che non utilizzi più indirizzi MAC sorgenti (e quindi più interfacce virtuali) per il traffico in uscita.

Con il metodo basato su MAC sorgente, il traffico in uscita da ogni macchina virtuale è associato a una specifica scheda di rete fisica, in base all'indirizzo MAC della vNIC. Questo comportamento è quasi identico al precedente, ma per macchine con più NIC virtuali non è garantito l'uso di schede di rete fisiche differenti; per questo motivo quest’opzione non viene quasi mai consigliata.

●     Route based on IP hash - l'instradamento è basato sull’hash degli indirizzi IP (sorgente e destinazione) di ogni pacchetto. Affinché questo metodo possa funzionare, è necessario che lo switch fisico esterno aggreghi le porte tramite protocollo EtherChannel o secondo standard 802.3ad (in particolare il protocollo LACP che rappresenta una parte delle specifiche 802.3ad). Il bilanciamento viene eseguito per il traffico in uscita: si utilizza un uplink differente per ogni sessione “IP-sorgente/IP-destinazione”. Ad esempio, se una VM con un determinato IP comunica con 2 destinazioni IP differenti (esterne all'host ESXi), impegna 2 interfacce fisiche (uplinks) distinte.

L'instradamento basato su IP è l'unico metodo che permette, a una machina virtuale dotata di una sola vNIC, di utilizzare la larghezza di banda complessiva di più interfacce di rete fisiche. Richiede tuttavia una modifica sulla configurazione dello switch fisico esterno, con l'attivazione di funzioni (EtherChannel) che non tutti gli switch supportano.

●     Use explicit failover order - con questa impostazione non c'è bilanciamento del carico ma solo failover, in base alle impostazioni di failover specificate nel riquadro "Failover order". Quando accade un evento di failover, la scelta del nuovo uplink da utilizzare ricade su quello in linea da più tempo, in base al valore di reported uptime.

Failover

La configurazione del failover prevede la scelta fra i 2 metodi seguenti:

●     Link Status only - si basa esclusivamente sullo stato del collegamento (link status) fornito dall’interfaccia fisica dell’host ESXi. Possono essere rilevati guasti dovuti ad un cavo di rete staccato o allo switch fisico con problemi di alimentazione. Non è possibile tuttavia rilevare errori di configurazione, come ad esempio una porta dello switch fisico bloccata dal protocollo spanning tree, o configurata in modo errato a livello di VLAN.

●     Beacon Probing - si inviano pacchetti “sonda” (beacon packets, pacchetti per il rilevamento di errori sulla rete) e si rimane in ascolto di essi. I pacchetti beacon sono inviati in broadcast da tutti gli uplinks del team. Lo switch fisico esterno inoltra (per sua natura) i pacchetti su tutte le porte appartenenti allo stesso dominio di broadcast. Ogni uplink rimane in attesa di ricevere i pacchetti dagli altri uplinks dello stesso team; se un uplink non riceve pacchetti per 3 volte consecutive, è marcato come "failed". In tal caso la caduta del link può essere dovuta sia a problemi sull’interfaccia fisica connessa allo switch esterno, sia a problemi a valle che non permettono ai pacchetti beacon di raggiungere l'uplink. Questo metodo permette di rilevare problemi sui collegamenti in maniera più precisa della semplice modalità "Link Status only".

Notify switch

L'opzione Notify Switch, quando attiva, permette all'hostESXi di notificare immediatamente, allo switch fisico esterno, i cambiamenti avvenuti a seguito di failover. Le notifiche avvengono anche quando un'interfaccia virtuale di una qualsiasi VM viene collegata allo switch virtuale, nell'ottica di diminuire i tempi di latenza.

Failback

Per impostazione predefinita, le interfacce fisiche dello stesso team lavorano secondo una logica di Failback: se una scheda fisica in stato "failed" torna in linea, riprende servizio immediatamente, rimpiazzando l'interfaccia che aveva assunto il suo ruolo. Di default, la modalità Failback è impostata su Yes. Al contrario, impostando il Failback su No, l'interfaccia di rete è tenuta inattiva anche dopo il suo ritorno in linea (ovviamente finchè l'altra interfaccia non va in errore e si riattiva una nuova procedura di failover).

Failover order

L'opzione Failover Order specifica come distribuire il carico di lavoro sulle interfacce di rete fisiche.

Le opzioni sono 3:

1.    Active Uplinks - le interfacce in questo gruppo sono tutte up e parte attiva del team.

2.    Stanby Uplinks - le interfacce in questo gruppo rimangono in standby per entrare in funzione in situazioni di failover, prendendo il posto di quelle andate in down.

3.    Unused Uplinks - le interfacce in questo gruppo semplicemente non vengono utilizzate.

Configurazione del Teaming e del failover con vSphere Client

1)    All'interno del tab Configuration dell’host selezionato, andare nella sezione Networking e fare clic sulla voce Properties relativa allo switch da modificare.

2)    Selezionare lo switch virtuale o un port group, quindi fare clic su Edit.

3)    per modificare le impostazioni di Failover e Load Balancing, fare clic su NIC Teaming:

Configurazione del Teaming e del failover con vSphere Web Client

1)    Nel pannello di navigazione a sinistra, individuare l’host desiderato, fare clic sul tab Manage, quindi su Networking > Virtual Switches.

2)    Selezionare lo switch dalla lista e fare clic su Edit settings. Se le impostazioni devono essere assegnate ad un port group, selezionarlo nello schema di rete che appare più sotto e fare clic su Edit Settings.

3)    Fare clic su Teaming and failover e impostare i parametri come desiderato.