Supporto Tecnico Enterprise : Network Load Balancing

Network Load Balancing – Unicast vs Multicast

itentblg — Mon, 29 Dec 2008 03:00:00 GMT

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 Multicast mode l'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

Network Load Balancing – Introduzione

itentblg — Mon, 22 Dec 2008 03:00:00 GMT

Questo è il primo di una serie di post in cui parleremo di NLB: Network Load Balancing.

Nella prima parte faremo un’introduzione delle caratteristiche principali di questa tecnologia, mentre nelle successive ci focalizzeremo più in dettaglio su alcuni aspetti tecnici.

Panoramica generale

NLB è una tecnologia cluster implementata a livello di sistema operativo e disponibile in Windows Server 2000, 2003 e 2008.

Lo scopo principale è fornire scalabilità e alta disponibilità a servizi e applicazioni basati su TCP/IP come Internet Information Services (IIS), Virtual Private Networking (VPN), Internet Security and Acceleration (ISA) e Terminal Services (TS).

I servizi da bilanciare dovranno essere configurati in maniera identica su ogni host che partecipa al cluster NLB, e le richieste da parte dei client saranno gestite dai singoli server in base all’algoritmo di bilanciamento.

Le principali caratteristiche dell’NLB in Windows Server 2003 sono:

High availability
Efficiency
Scalability
Ease of maintenance

In Windows Server 2008 sono state introdotte e migliorate molte funzionalità tra cui le principali sono:

Supporto a IPv6
Supporto a NDIS 6.0
Migliore integrazione con ISA Server

La tecnologia NLB è in grado di fornire una soluzione economica e alternativa ai bilanciatori hardware e per le sue caratteristiche, l’utilizzo ottimale avviene in presenza di scenari con un grande numero di client e servizi stateless.

Architettura

NLB è un NDIS intermediate filter driver inserito tra la scheda di rete fisica (NIC) e i protocolli dello stack TCP/IP come illustrato nella seguente immagine:

In Windows Server 2008 il driver è stato totalmente riscritto adottando il nuovo Lightweight Filters Driver model (LWF) che ha portato a miglioramenti nelle performance del driver stesso, mantenendo la retro compatibilità con le versioni NDIS precedenti.

Il driver deve essere installato su ogni server che partecipa al cluster, e agirà effettivamente come un rule-based filter per il traffico in ingresso verso l’host.

L'architettura così distribuita elimina la necessità di indirizzare le richieste verso un host specifico, il processo è quindi più veloce rispetto a ricevere, analizzare, riscrivere e rispedire le richieste; inoltre permette di massimizzare la disponibilità delle risorse: N host forniscono N-1 possibilità di failover mentre un classico dispacher deve essere ridondato per non creare un single point of failure.

Network Load Balancing automaticamente rileva e ricompone il cluster se un server ha un malfunzionamento o è disconnesso dalla rete, ma non è consapevole dello strato software che ha sopra, per cui i servizi e le applicazioni non vengono monitorate dal driver che continuerà a fare il suo lavoro anche se una di queste ha un qualsiasi problema. Per avere un monitoring delle applicazioni e dei servizi bilanciati bisogna ricorrere a dei software di management quali il Systems Center Operations Manager.

Algoritmo

L'algoritmo mappa le richieste dei client ad uno specifico host in base ad alcuni parametri, tutti gli host eseguono quest'operazione contemporaneamente per determinare quale di loro sarà designato a gestire la richiesta mentre gli altri la scarteranno.

L'algoritmo utilizzato da NLB è proprietario e quindi non è disponibile della documentazione pubblica che ne illustri il funzionamento, ma ci sono alcuni parametri che possono essere modificati per influenzare la distribuzione delle richieste:

Host priorities
Multicast o Unicast mode
Port rules
Affinity
Load percentage distribution
Client IP address
Client port number
Other internal load information

Il mapping rimarrà valido fino ad un eventuale cambiamento del numero di nodi o delle regole impostate.

Una nota importante per un corretto funzionamento dell’algoritmo: è essenziale che tutti i nodi ricevano le richieste in ingresso in quanto il processo decisionale per servire i client avviene separatamente su ogni singolo host.

Nei prossimi post vedremo le modalità di funzionamento Unicast e Multicast.

Maggiori informazioni e approfondimenti:

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Platforms Support