---
title: "Microsoft NLB Alternativa VMware: problemi di multicast e unicast risolti"
canonical: "https://safekit.eviden.com/it/best-practises/microsoft-nlb-vmware-multicast-unicast-alternative/"
description: "Hai difficoltà con il multicast o l'unicast NLB Microsoft in VMware? SafeKit propone un cluster farm senza SAN come semplice alternativa. Ottieni bilanciamento del carico e failover automatici su Windows e Linux senza voci ARP statiche, spoofing MAC o configurazioni di rete specializzate."
category: "best-practises"
lang: "it"
topics: "Microsoft Modalità multicast NLB, Microsoft Modalità unicast NLB, Alternativa con SafeKit, Come funziona il cluster SafeKit in modalità farm con Windows ?"
---

# Microsoft Alternativa NLB VMware: problemi multicast e unicast risolti {#microsoft-nlb-vmware-alternative-multicast-and-unicast-issues-solved}

## Microsoft Modalità multicast NLB {#microsoft-nlb-multicast-mode}

Come spiegato nella knowledge base di VMware relativa alla configurazione della modalità multicast di bilanciamento del carico di rete (NLB) [ ](<https://knowledge.broadcom.com/external/article?articleNumber=414968>) , è necessario configurare manualmente la risoluzione ARP statica sullo switch o sul router per ogni porta connessa al cluster. L'implementazione della modalità multicast NLB Microsoft in un ambiente di rete sconosciuto può rivelarsi un'operazione complessa e impegnativa.

## Microsoft Modalità unicast NLB {#microsoft-nlb-unicast-mode}

Con la modalità unicast NLB Microsoft , è necessario configurare l'host ESXi/ESX in modo che non invii pacchetti RARP quando una delle sue macchine virtuali è accesa. Ecco perché [ Microsoft NLB non funzionano correttamente in modalità unicast con VMware ](<https://knowledge.broadcom.com/external/article/344421/microsoft-nlb-not-working-properly-in-un.html>) .

## Alternativa con SafeKit {#alternative-with-safekit}

La configurazione degli indirizzi IP virtuali [ SafeKit ](<https://safekit.eviden.com/it/best-practises/how-a-virtual-ip-address-works/>) non richiede alcuna configurazione di rete particolare e il bilanciamento del carico di rete può funzionare in qualsiasi ambiente. Una caratteristica importante quando la soluzione deve essere implementata in un'infrastruttura sconosciuta: switch o router, server fisici o virtuali non noti.

## Come funziona il cluster SafeKit in modalità <span class="notranslate farm-term" translate="no">farm</span> con Windows ? {#safekit-farm-cluster}

### Indirizzo IP virtuale in un cluster in modalità <span class="notranslate farm-term" translate="no">farm</span> {#virtual-ip-address-farm}

![Come il cluster SafeKit implementa il bilanciamento del carico della rete Windows e il failover](https://safekit.eviden.com/wp-content/uploads/2023/02/safekit-up-up-up-300.png "w:300")

Nella figura precedente, l’applicazione Windows è in esecuzione sui 3 server (3 è un esempio, possono essere 2 o più). Gli utenti sono connessi a un indirizzo IP virtuale.

L’[indirizzo IP virtuale](https://safekit.eviden.com/it/best-practises/how-a-virtual-ip-address-works/) è configurato localmente su ciascun server nel cluster in modalità <span class="notranslate farm-term" translate="no">farm</span>.  
Il traffico in ingresso all’indirizzo IP virtuale viene ricevuto da tutti i server e suddiviso tra di essi da un filtro di rete all’interno del kernel di ciascun server.

SafeKit rileva guasti hardware e software, riconfigura i filtri di rete in caso di guasto e offre controlli delle applicazioni configurabili e script di ripristino.

### Bilanciamento del carico in un filtro di rete {#network-load-balancing}

L’algoritmo di bilanciamento del carico di rete all’interno del filtro di rete si basa sull’identità dei pacchetti client (indirizzo IP del client, porta TCP del client). A seconda dell’identità del pacchetto client in ingresso, solo un filtro in un server accetta il pacchetto; gli altri filtri in altri server lo rifiutano.

Una volta che un pacchetto viene accettato dal filtro su un server, solo la CPU e la memoria di questo server vengono utilizzate dall’applicazione Windows che risponde alla richiesta del client. I messaggi di output vengono inviati direttamente dal server dell’applicazione al client.

Se un server si guasta, il protocollo heartbeat <span class="notranslate farm-term" translate="no">farm</span> riconfigura i filtri nel cluster di bilanciamento del carico di rete per ribilanciare il traffico sui server rimanenti disponibili.

### Applicazioni con o senza stato {#stateful-stateless}

Con un’applicazione Windows con stato, esiste un’affinità di sessione. Lo stesso client deve essere connesso allo stesso server su più sessioni TCP per recuperare il suo contesto sul server. In questo caso, la regola di bilanciamento del carico SafeKit è configurata sull’indirizzo IP del client. Pertanto, lo stesso client è sempre connesso allo stesso server su più sessioni TCP. E i diversi client sono distribuiti su diversi server nel <span class="notranslate farm-term" translate="no">farm</span>.

Con un’applicazione Windows senza stato, non vi è alcuna affinità di sessione. Lo stesso client può essere connesso a server diversi nel <span class="notranslate farm-term" translate="no">farm</span> su più sessioni TCP. Non vi è alcun contesto memorizzato localmente su un server da una sessione all’altra. In questo caso, la regola di bilanciamento del carico SafeKit è configurata sull’identità della sessione client TCP. Questa configurazione è la migliore per distribuire le sessioni tra i server, ma richiede un servizio TCP senza affinità di sessione.

### Come configurare un cluster SafeKit in modalità <span class="notranslate farm-term" translate="no">farm</span> per Windows ? {#safekit-farm-cluster-configuration}

![SafeKit Web Console: configurazione del cluster per il bilanciamento del carico della rete Windows e la gestione degli IP virtuali.](https://safekit.eviden.com/wp-content/uploads/2026/01/safekit-farm-cluster-config.png "w:966")

Il **cluster SafeKit in modalità <span class="notranslate farm-term" translate="no">farm</span>** è progettato per un’elevata disponibilità e scalabilità dei servizi. La configurazione si concentra sulla distribuzione del traffico in entrata su entrambi i nodi contemporaneamente:

  * **Servizi con bilanciamento del carico (scheda Macro):** definire i servizi applicativi specifici (ad esempio, Apache, IIS, Nginx) da mantenere attivi su tutti i nodi.
  * **Rete/i heartbeat:** percorso/i di comunicazione utilizzato/i per rilevare se un nodo ha lasciato la <span class="notranslate farm-term" translate="no">farm</span>, attivando una ridistribuzione immediata del carico.
  * **IP virtuale (<span class="notranslate farm-term" translate="no">Farm</span> VIP):** a differenza di un cluster mirror, il <span class="notranslate farm-term" translate="no">Farm</span> VIP è condiviso tra i nodi e utilizza un algoritmo di filtraggio del kernel per distribuire il traffico di rete.
  * **Regole di bilanciamento del carico:** definisci la politica di distribuzione del traffico in base all’indirizzo IP o alla porta di origine.
  * **Checkers:** monitora lo stato dell’applicazione e avvia il riavvio automatico in caso di rilevamento di un errore di processo.

### Come monitorare un cluster SafeKit in modalità <span class="notranslate farm-term" translate="no">farm</span> per Windows ? {#safekit-farm-cluster-monitoring}

![SafeKit Console: monitoraggio di un cluster in modalità farm a 2 nodi che mostra entrambi i nodi Windows nello stato UP con bilanciamento del carico attivo.](https://safekit.eviden.com/wp-content/uploads/2026/01/safekit-farm-cluster-monitor.png "w:473")

Il monitoraggio di un cluster in modalità <span class="notranslate farm-term" translate="no">farm</span> fornisce visibilità sulla natura **Active-Active** dell’infrastruttura, in cui tutti i nodi contribuiscono alle prestazioni dell’applicazione (mostrando 2 nodi in questo esempio):

  * **Stato UP (50% su 2 nodi):** in una <span class="notranslate farm-term" translate="no">farm</span> sana, entrambi i nodi sono nello stato " UP " (50%), il che significa che entrambi ricevono ed elaborano attivamente le richieste dei client tramite l’IP virtuale condiviso.
  * **Riequilibrio automatico:** se un nodo si guasta, la console mostra visivamente che il nodo rimanente gestisce il 100% del traffico. Non c’è alcun ritardo di "failover", poiché il nodo superstite è già attivo (a parte un tempo di rilevamento di pochi secondi).
  * **Inserimento del nodo:** quando un nodo riparato viene riavviato, passa da " STOP " a " UP " e inizia automaticamente a ricevere la sua porzione di carico senza l’intervento dell’amministratore.
  * **Nessuna sincronizzazione dei dati:** si noti che in un cluster in modalità <span class="notranslate farm-term" translate="no">farm</span> non esiste lo stato di risincronizzazione "Arancione", poiché i nodi devono essere senza stato o condividere un database di backend (che può essere protetto separatamente in un cluster mirror).

Oltre alle semplici icone di stato, l’interfaccia fornisce la gestione dei nodi con un solo clic, consentendo di arrestare o avviare manualmente un nodo per la manutenzione pianificata, mentre l’IP virtuale condiviso ridistribuisce automaticamente il traffico senza interrompere l’attività dell’utente.