Network Load Balancing – Unicast vs Multicast

Nel primo post abbiamo visto le caratteristiche principali del Network Load Balancing (NLB), mentre in questo approfondiremo le modalità di funzionamento: Unicast e Multicast.

Come abbiamo visto nel precedente post, è fondamentale che tutti i nodi ricevano le richieste dei client destinate al Virtual IP assegnato al cluster. L’algoritmo, su ciascun host, potrà in questo modo processare le richieste e stabilire quale di questi sarà designato a gestire la richiesta, mentre gli altri semplicemente la scarteranno.

Entrambi i metodi permettono di raggiungere quest’obiettivo, vediamo come funzionano.

UNICAST

Questa è la configurazione di default ed è quella che la stragrande maggioranza dei nostri clienti adotta.
Quando questa modalità è abilitata, un MAC Address “virtuale” rimpiazza quello della NIC, per cui sia il Virtual IP (VIP) che l' IP dedicato (DIP) verranno risolti con questo nuovo indirizzo.

Il nuovo MAC Address avrà questa forma:
02-bf-WW-XX-YY-ZZ
dove WW-XX-YY-ZZ è il valore esadecimale del VIP.

Al fine di distribuire le richieste per il VIP a tutti i nodi, e per evitare che l’utilizzo di un unico MAC Address per tutti gli host del cluster causi un conflitto, NLB “maschera” il MAC di tutti i pacchetti in uscita.

Ogni nodo appartenente al cluster è identificato da un numero progressivo univoco configurabile da interfaccia grafica: il "masking" avviene sostituendo il secondo byte dell’indirizzo MAC virtuale con l' host ID del nodo, che sarà quindi diverso per ogni interfaccia che partecipa al cluster.

Ad esempio:

02-bf-0a-00-00-01 -> 02-09-0a-00-00-01

Diamo un’occhiata ad una ARP reply di una richiesta per il MAC address del VIP:

Come possiamo vedere nella risposta, il frame ethernet riporta il MAC address “mascherato” del nodo 2, 02:02:c0:a8:00:01; da notare invece che l’ ARP header mostra il MAC address del cluster 02:bf:c0:a8:00:01; ricordiamo che i router, e i client, controllano il MAC address presente nell' ARP header e non nell’ethernet header, mentre gli switch, per mappare un indirizzo ad una porta utilizzano quello contenuto nell’Ethernet header.

Quando un client dovrà raggiungere il Virtual IP del cluster, questo sarà risolto correttamente con il MAC virtuale comune a tutti gli host, ma lo switch non lo potrà mappare ad alcuna porta specifica e non avremo alcun conflitto sullo switch stesso.

Il vantaggio dell'Unicast è che funziona nella quasi totalità delle configurazioni senza particolari interventi sugli switch o i router.

L’unica accortezza è dovuta al fatto che la condivisione dello stesso indirizzo MAC non permette la comunicazione tra host, per cui occorre avere almeno due NIC; non avendole disposizione è possibile comunque aggirare il problema impostando su ogni nodo la chiave di registro “UnicastInterHostCommSupport” documentata dall'articolo KB898867.

Lo svantaggio principale dell’Unicast riguarda invece il flooding, che è però possibile limitare:

• creando una VLAN dedicata al cluster che comprenda solo le porte a cui i nodi sono collegati;
• collegando tutti i nodi ad un hub in cascata allo switch.

In questo caso il masking deve essere disabilitato da registry in modo che lo switch mappi il MAC address del cluster alla porta su cui è collegato l’hub.

Il metodo indicato non è sempre praticabile per grandi realtà ma può essere una soluzione con cluster di piccole dimensioni.

Il parametro da impostare nel registry è "MaskSourceMAC":

• Windows 2000: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parameters
• Windows Server 2003: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parameters\Interface\<GUID>

MULTICAST

In Multicastmodel'indirizzo MAC built-in non è disabilitato ma ne è aggiunto uno Multicast, in questo modo il VIP sarà risolto con il nuovo MAC mentre il DIP continuerà ad essere risolto con il suo MAC originario.

Il MAC Address generato ha questa forma:

03-bf-WW-XX-YY-ZZ

anche in questo caso WW-XX-YY-ZZ è il valore esadecimale del VIP

Riporto lo screenshot di una ARP reply di una richiesta per il MAC address del VIP:

Nell'ARP header notiamo il MAC del cluster con la forma 03:bf:c0:a8:00:01; l'indirizzo 00:15:5d:b0:d2:0a è in questo caso il MAC reale della NIC.

Il traffico Multicast è generalmente di default trattato come quello broadcast e quindi inoltrato su tutte le porte dello switch a meno di configurare manualmente lo switch. In Windows 2003, abbiamo però la possibilità di abilitare il protocollo IGMP (Internet Group Management Protocol), per cui basterà abilitare IGMP Snooping sullo switch e il traffico verrà instradato correttamente in automatico, eliminando il flooding.

Un ulteriore vantaggio di questa modalità risiede nel fatto che il MAC address reale viene ritenuto, permettendo di fatto il traffico tra host senza necessità di aggiungere una seconda scheda di rete.

Il principale svantaggio riguarda invece l’incompatibilità con alcuni device dovuta all’associazione Unicast IP address-Multicast MAC Address. Ad esempio i router Cisco non accettano tale mappatura e per far si che tutto funzioni è necessario aggiungere delle entry statiche a mano. Sul sito di Cisco è possibile reperire alcune indicazioni, ad esempio per quanto riguarda gli switch Catalyst: Catalyst Switches for Microsoft Network Load Balancing Configuration Example.

In conclusione, entrambe le modalità presentano vantaggi e svantaggi, ma la modalità di default Unicast è quella probabilmente più immediata da implementare. Chi volesse invece sfruttare IGMP per eliminare il flooding dovrà scegliere Multicast, tenendo a mente che alcuni apparati non accettano ARP reply per Unicast IP address che contengano un Multicast Mac Address e necessitano una configurazione manuale.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Platforms Support

Comments

• Anonymous
  January 01, 2003
  Ciao a.tumiotto, Ok, quindi convertono correttamente tutti e tre e dovrebbe bilanciare correttamente. Per quanto riguarda il problema di gestione dalla console, di solito capita quando si usa una sola NIC, in quel caso si deve seguire quanto riportato qui: http://support.microsoft.com/default.aspx?scid=kb;EN-US;898867 Hai il firewall abilitato sui nodi? Nel caso prova a dare questo comando: netsh firewall set service RemoteAdmin enable all o a disabilitarlo totalmente (solo per il test). Ricordati anche che il protocollo ICMP non è bilanciato, quindi se esegui un Ping verso il VIP dovresti ottenere 3 reply se tutti i nodi rispondono; puoi controllare usando netmon o wireshark. Ciao Alessandro

• Anonymous
  January 01, 2003
  Ciao il problema potrebbe essere legato al tipo di NIC di Hyper-V. Controlla quanto riportato qui: http://support.microsoft.com/kb/953828/en-us cè anche un ottimo articolo scritto dal collega Pierluigi al seguente link: http://blogs.technet.com/pgmalusardi/archive/2008/09/24/hyper-v-e-network-load-balancing.aspx Cioa Alessandro

• Anonymous
  January 01, 2003
  Ciao Alberto, Si potrebbe essere anche quello il problema, ti descrivo il motivo; per comodità chiamiamo la NIC sulla quale hai configurato l’NLB "cluster NIC" e l’altra, quella senza il driver NLB, "NIC dedicata". Non conosco la tua configurazione ma tipicamente, un NLB configurato con due NIC ha il cluster VIP e l’ IP primario della stessa cluster NIC nella stessa subnet e il default gateway configurato su questa scheda; la NIC dedicata può avere un IP nella stessa subnet della cluster NIC o in un’altra. Abbiamo detto nell’articolo che il driver NLB configura tutte le cluster NIC con lo stesso MAC Address quindi un tentativo di connessione con un altro nodo del cluster fallirà in quanto l’IP sarà risolto con lo stesso MAC e la richiesta non lascerà mai la NIC stessa. Per risolvere il problema potresti provare a configurare le due NIC in questo modo:

1. Sulla cluster NIC imposti il VIP address e l’IP primario su due subnet diverse;
2. La NIC dedicata la imposti sulla stessa subnet del VIP;
3. Imposta il default gateway sulla NIC dedicata;
4. Entrambe le NIC lasciale connesse allo stesso switch. In questo modo dovremmo ottenere che le richieste  da un nodo all’altro passino dalla NIC dedicata che dovrebbe permettere la connessione con gli altri nodi. Fammi sapere se risolvi. Ciao Alessandro

• Anonymous
  January 01, 2003
  Ciao a.tumiotto, Devi prima capire se l’NLB converge correttamente. Lo puoi vedere con il comando: NLB display alla fine dell’output controlla che tutti i nodi convergano. Prova anche a cliccare con il tasto destro sulla voce in alto a sinistra "Network load balancing Clusters" nell'NLB Manager ed aggiungere il tuo cluster, quale errore ottieni? Ciao Alessandro

• Anonymous
  January 01, 2003
  Ciao Michele, L'algoritmo non prende decisioni al variare delle condizioni di carico dell'host; nel primo post ho inserito alcune informazioni su come funziona l'agoritmo, qualche ulteriore dettaglio lo trovi anche nelle faq alla voce: "How Does the NLB Load Balancing Algorithm Work?" http://technet.microsoft.com/en-us/library/cc738464.aspx Grazie a te per aver lasciato un feedback sull'articolo e fammi pure sapere se hai qualche altra curiosità. Ciao Alessandro

• Anonymous
  January 01, 2003
  Ciao Alessandro, scusa la mia ignoranza riguardo alle reti ma vorrei capire meglio il discorso sui gli host del cluster collegati ad uno switch layer 2 o ad uno layer 3. Che cosa bisogna tener presente? Perchè Microsoft scrive così: "If you connect Network Load Balancing hosts with a switch, the switch must be layer 2 instead of layer 3 or higher, because all the hosts share the same IP address (the cluster IP address), and layer 3 switches direct network packets (incoming client requests) according to the IP address of the destination computer". Che significa? Grazie

• Anonymous
  January 01, 2003
  Semplicemente gli switch layer 3 sono in grado di instradare le richieste basandosi anche sull'indirizzo ip di destinazione e quindi il meccanismo sopra descritto non funziona più :)

• Anonymous
  January 01, 2003
  Ciao Antonio, Il multicast non sostituisce il MAC Address quindi non ha il problema citato, l’unica cosa è che sia compatibile con lo switch che usi ma sembra proprio di si se funziona. Ciao Alessandro

• Anonymous
  January 02, 2009
  Grazie, finalmente ho capito un pò di cose. Ho una domanda: su cosa si basa la scelta di un nodo piuttosto che un altro? Nel senso che io sto utilizzando un cluster NLB con 2 nodi terminal server. Ora, le richieste dei client che si collegano tramite RDP vengono instradate su uno o l'altro in base al numero di connessioni presenti su un nodo piuttosto che un altro? O sul carico della CPU/memoria di un nodo?Grazie

• Anonymous
  March 09, 2009
  Ciao Alessandro, ho configurato un NLB con tre nodi. Gli host hanno 2 schede di rete e il cluster è configurato in unicast. Se testo l'applicazione sembra funzionare ma se apro la console di gestione vede soltanto l'ho locale sul quale mi collego. Se pingo gli ip della rete pubblica non mi rispondono mentre se pingo quella della rete privata si. Il problema può dipendere dal fatto che sia la rete pubblica che quella privata hanno lo stesso indirizzamento e che sono sullo stesso switch. Grazie

• Anonymous
  March 10, 2009
  The comment has been removed

• Anonymous
  March 11, 2009
  Ciao Alessandro, il mio problema è che ho due nic collegate una per la parte public e l'altra per la private. Il mio dubbio è che avendo la stessa classe di indirizzi ed essendo collegate allo stesso switch possano darsi "fastidio". Per quanto riguarda il firewall sui tre nodi win 2003 std non è installato. Ciao e ancora grazie per la disponibilità Alberto

• Anonymous
  March 11, 2009
  Ciao Alessandro, purtroppo non posso utilizzare due subnet diverse per quesitoni di configurazione di rete quindi ho optato per il multicast con scheda singola e adesso oltre che a funzionare da fuori anche dalla console vedo i nodi attivi. grazie per l'aiuto.

• Anonymous
  March 23, 2009
  Stiamo testando un cluster  NLB Multicast su 16 VM Hyper-V distribuite su due host. Usiao schede di rete Host dedicsate solo al traffico rete dell VM ma abbiamo notato che in maniera random le VM si riavviano senza motivi apparenti. Se scolleghiamo dal clsuter NLB le VM  il problema non si pone. In questo moemnto sto provando con un clsuter configurato in unicast per verificare se risolvo. Inoltre ti chiededevo se esiste l modo di eveitare il flooding lavorndo con le VM . Grazie GAetano