Uno switch virtuale può essere connesso a più interfacce di rete fisiche (quelle dell'host ESXi) e sfruttare più uplink per il collegamento alla 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 il failover.

  • Il bilanciamento del carico (Load Balancing) permette di distribuire il traffico tra macchine virtuali e rete fisica attraverso due 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 con cui il traffico di rete viene instradato su un'altra interfaccia di rete fisica quando la prima non è più operativa. Configurazione del Teaming e del Failover

Procedura 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.vsphere standard virtual switch teaming failover client 1
  3. Per modificare le impostazioni di Failover e Load Balancing, selezionare il tab NIC Teaming.vsphere standard virtual switch teaming failover client 2

Procedura 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.vsphere standard virtual switch teaming failover web client 1
  3. Fare clic su Teaming and failover e impostare i parametri come desiderato. vsphere standard virtual switch teaming failover web client 2

I parametri di Teaming e Failover

Load Balancing

  • 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. È 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, 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 uplink 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 dell’interfaccia virtuale. Questo comportamento è quasi identico al precedente, ma per macchine con più interfacce virtuali non è garantito l'uso di uplink differenti; per questo motivo il metodo in oggetto non è quasi mai consigliato.

  • 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 due destinazioni IP differenti (esterne all'host ESXi), impegna due interfacce fisiche (uplink) distinte.

    L'instradamento basato su IP è l'unico metodo che permette, a una macchina 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

  • Link Status only - si basa esclusivamente sullo stato del collegamento (link status) fornito dall’interfaccia fisica dell’host ESXi. Possono essere rilevati guasti dovuti a 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 – vengono inviati dei 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 uplink 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 uplink dello stesso team; se un uplink non riceve pacchetti per tre 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'host ESXi 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.

  • Active Uplinks - le interfacce in questo gruppo sono tutte parte attiva del team.
    Standby Uplinks - le interfacce in questo gruppo rimangono in standby per entrare in funzione nelle situazioni di failover, in cui prendono il posto di quelle andate in down.
    Unused Uplinks - le interfacce in questo gruppo semplicemente non sono utilizzate.

Le istruzioni presenti in questa pagina fanno riferimento alla versione 5.x di VMware vSphere.

L'autore

Alessio Carta

Responsabile sistemi presso un System Integrator con sede in Sardegna, si occupa di informatica e telecomunicazioni da oltre 10 anni. La sua formazione comprende una laurea in ingegneria, una specializazione IFTS in progettazione di reti telematiche, certificazioni Cisco CCNA, Cisco CCNA Security, MCP sui sistemi Windows Server e VCP su VMware vSphere (5.1, 5.5, 6.0). È istruttore presso una VMware IT Academy con sede a Cagliari.