Windows 2003/2008 NLB - Sfatiamo alcuni miti

  • Article

Il componente di Network Loab Balancing di Microsoft è in circolazione da parecchio tempo, ma durante il mio lavoro quotidiano mi scontro spesso con clienti che hanno false aspettative verso di esso. Con questo breve post vorrei sfatare alcuni dei concetti che possono essere causa di queste errate convinzioni.

1. NLB instrada le chiamate sul nodo più scarico

FALSO. Il componente NLB non si occupa di gestire la parte applicativa della macchina.

Esso è stato pensato per fornire servizio all’intera macchina e non al singolo applicativo, quindi non tiene conto di nessun dato di performance. Su di un nodo NLB possiamo aver più servizi contemporaneamente, da web servers a semplici applicativi in ascolto; tutti quanti beneficiano del bilanciamento.

I nodi si coordinano ma non si scambiano dati sulle risorse disponibili, quindi la decisione di “routing” è presa senza tener conto dello stato della macchina e dei servizi. L’instradamento è semplicemente fatto in base all’IP del client.

2. NLB bilancia esattamente il carico sui vari nodi

IN PARTE FALSO. L’algoritmo di bilanciamento non garantisce sempre una disribuzione equa delle richieste in entrata. Una distribuzione omogenea delle richieste sui vari nodi la iniziamo ad ottenere solamente quanto i client in ingresso sono almeno 5 volte tanto i nodi del cluster. Quindi quando la popolazione d’ingresso è statisticamente rilevante. Inoltre tutto l’algoritmo è parametrizzato secondo “l’affinity” e “l’host priority” scelte. Rimando alla documentazione ufficiale per quanto riguarda i dettagli dell’affinity.

3. Le applicazioni sui nodi si conoscono e comunicano tra loro, è possibile fare failover

FALSO. A meno di particolari settaggi o particolari estensioni, le applicazioni non sono a conoscenza dell’esistenza degli altri nodi quindi non si coordinano a livello applicativo. Non è quindi possibile fare failover, come in un “failover cluster”. Generalmente si tende a “duplicare” il contenuto di un nodo sui vari membri del cluster NLB.

4. NLB ha bisogno della scheda di HeartBeat

FALSO. NLB utilizza un messaggio di HeartBeat per coordinare i vari nodi (frequenza di 1 secondo). Questo messaggio è sempre e comunque inviato sulla scheda che partecipa all’NLB, quindi assieme al traffico bilanciato! Anche inserendo una seconda scheda questo traffico non verrà mai inviato su di essa. Questa concezione di scheda di HearBeat deriva dal fatto che in modalità UNICAST è utile (ma non necessario) avere una seconda scheda di rete. La seconda scheda serve solamente per permette ai due nodi di “vedersi”, operazione impossibile altrimenti (visto il MAC address modificato sulla scheda NLB).

5. Il traffico viene rediretto verso un singolo nodo

FALSO. Tutti i nodi vedono lo stesso traffico in ingresso, quindi un singolo pacchetto è sempre duplicato N volte e processato da tutti i nodi. Solo un nodo risponderà alla richiesta, gli altri N-1 scarteranno il pacchetto. Il traffico non viene mai rediretto.

Vorrei concludere lasciandovi un semplice metodo per capire remotamente, quanti nodi di un cluster NLB sono attivi e raggiungibili.

NLB bilancia tutto il traffico TCP e UDP, quindi se richiediamo una qualunque risorsa tramite questi protocolli veniamo bilanciati ed otteniamo una sola risposta. Se invece utilizziamo ICMP (ping) ogni nodo risponderà alla nostra richiesta! Per ogni richiesta ICMP otteniamo una risposta per ogni nodo attivo e raggiungibile!

Tuttavia ping.exe visualizza solamente la prima risposta ricevuta quindi non ci è di aiuto.

La soluzione consiste nel catturare una traccia di rete, durante il ping dell’indirizzo virtuale del cluster.

Ad esempio per un cluster a 2 nodi otterremo 8 messaggi Reply a fronte dei 4 Messaggi di Request inviati.

clip_image002

172.30.0.4 172.20.0.20 ICMP ICMP:Echo Request Message, From 172.30.0.4 To 172.20.0.20

172.20.0.20 172.30.0.4 ICMP ICMP:Echo Reply Message, From 172.20.0.20 To 172.30.0.4

172.20.0.20 172.30.0.4 ICMP ICMP:Echo Reply Message, From 172.20.0.20 To 172.30.0.4

172.30.0.4 172.20.0.20 ICMP ICMP:Echo Request Message, From 172.30.0.4 To 172.20.0.20

172.20.0.20 172.30.0.4 ICMP ICMP:Echo Reply Message, From 172.20.0.20 To 172.30.0.4

172.20.0.20 172.30.0.4 ICMP ICMP:Echo Reply Message, From 172.20.0.20 To 172.30.0.4

172.30.0.4 172.20.0.20 ICMP ICMP:Echo Request Message, From 172.30.0.4 To 172.20.0.20

172.20.0.20 172.30.0.4 ICMP ICMP:Echo Reply Message, From 172.20.0.20 To 172.30.0.4

172.20.0.20 172.30.0.4 ICMP ICMP:Echo Reply Message, From 172.20.0.20 To 172.30.0.4

172.30.0.4 172.20.0.20 ICMP ICMP:Echo Request Message, From 172.30.0.4 To 172.20.0.20

172.20.0.20 172.30.0.4 ICMP ICMP:Echo Reply Message, From 172.20.0.20 To 172.30.0.4

172.20.0.20 172.30.0.4 ICMP ICMP:Echo Reply Message, From 172.20.0.20 To 172.30.0.4

Buona Giornata Sorriso

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support