Informazioni su bilanciamento del carico in Exchange 2010

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2016-11-28

Il bilanciamento del carico consente di stabilire e gestire i server che devono ricevere traffico. Il bilanciamento del carico fornisce ridondanza di failover per garantire agli utenti la continuità di servizio da parte di Exchange in caso di problemi del computer. Inoltre, consente all'ambiente di distribuzione di gestire più traffico di quello che potrebbe elaborare un server fornendo, allo stesso tempo, un solo nome host per tutti i client.

Oltre al bilanciamento del carico, Microsoft Exchange Server 2010 offre diverse soluzioni per la ridondanza di failover e lo switchover. Tali soluzioni consistono in:

• Elevata disponibilità e resilienza del sito   È possibile distribuire due siti Active Directory geograficamente separati, mantenere i dati delle cassette postali sincronizzati tra di essi e fare in modo che uno gestisca l'intero carico di lavoro in caso di problemi dell'altro. Per mantenere più copie delle cassette postali sincronizzate sui diversi server, Exchange 2010 utilizza i gruppi di disponibilità del database (DAG).

• Spostamento delle cassette postali in linea Durante lo spostamento delle cassette postali in linea, gli utenti finali possono comunque accedere agli account di posta elettronica. L'account diventa inaccessibile solo per un breve periodo di tempo alla fine del processo (quando si verifica la sincronizzazione finale). Lo spostamento delle cassette postali in linea è possibile tra i database di Exchange 2010 e tra i database di Exchange Server 2007 Service Pack 3 (SP3), o una versione successiva di Exchange 2007, e quelli di Exchange 2010. È possibile eseguire spostamenti delle cassette postali in linea tra foreste o nell'ambito di una stessa foresta.

• Ridondanza shadow   La ridondanza shadow protegge la disponibilità e il ripristino dei messaggi durante il transito degli stessi. Con la ridondanza shadow, l'eliminazione di un messaggio dai database di trasporto viene ritardata finché il server di trasporto non verifica il completamento di tutti gli hop successivi relativi a quel messaggio. Se uno degli hop successivi restituisce un risultato negativo prima di segnalare la consegna del messaggio, il messaggio viene inviato nuovamente all'hop in questione.

Sommario

Cenni preliminari sul bilanciamento del carico

Informazioni sui carichi di traffico in Exchange 2010

Informazioni sulle opzioni di bilanciamento del carico

Consigli sul bilanciamento del carico

Opzioni di affinità

Cenni preliminari sul bilanciamento del carico

Il bilanciamento del carico ha due funzioni principali: riduce le conseguenze di errori imprevisti verificatisi su un server Accesso client di un sito Active Directory e garantisce che il carico sia equamente distribuito sul server Accesso Client e sui computer Trasporto Hub.

Modifiche all'architettura di bilanciamento del carico in Exchange 2010

Grazie a diverse modifiche introdotte con Exchange 2010, il bilanciamento del carico è diventato un fattore di grande rilevanza per le organizzazioni. Il servizio Accesso client RPC di Exchange e il servizio Rubrica sul ruolo server Accesso client di Exchange migliorano l'utilizzo in caso di failover del server Cassette postali spostando gli endpoint di connessione per l'accesso alle cassette postali da Outlook e altri client MAPI sul ruolo server Accesso client (invece che al ruolo server Cassette postali). Nelle versioni precedenti di Exchange, Outlook si collegava direttamente al server Cassette postali su cui era ubicata la cassetta postale dell'utente e le connessioni di directory venivano gestite dal ruolo server Cassette postali o inviate direttamente a un determinato server di catalogo globale Active Directory. Ora che tali connessioni vengono gestite dal ruolo server Accesso client, per ottenere un'adeguata tolleranza d'errore nell'organizzazione, il bilanciamento del carico delle connessioni esterne ed interne di Outlook deve essere eseguito nell'ambito dell'array dei server Accesso client.

Si consiglia di predisporre un array di server Accesso client con bilanciamento del carico per ciascun sito Active Directory e per ciascuna versione di Exchange. Non è possibile utilizzare un unico array di server Accesso client con bilanciamento del carico per più siti Active Directory, né combinare versioni diverse di Exchange o differenti versioni Service Pack di Exchange all'interno dello stesso array.

Quando si installa Exchange 2010 in un'organizzazione esistente e si configura lo spazio dei nomi legacy per la coesistenza con versioni precedenti di Exchange, i client verranno automaticamente connessi al server o all'array di server Accesso client di Exchange 2010. Il server Accesso client o l'array di server Accesso client di Exchange 2010 invierà o reindirizzerà le richieste client per cassette postali ubicate nelle versioni precedenti di Exchange ai server front-end di Exchange 2003 o ai server Accesso client di Exchange 2007 corrispondenti alla versione delle cassette postali. Per ulteriori informazioni, vedere Informazioni sull'aggiornamento a Exchange 2010.

La configurazione del bilanciamento del carico ha un impatto diretto sui nomi host che i client utilizzano per la connessione e sui certificati SSL (Secure Sockets Layer) in uso. Per ulteriori informazioni sui certificati di Exchange 2010, vedere Informazioni sui certificati digitali e SSL.

Configurazione dell'array di server Accesso client

È possibile configurare un array di server Accesso client per ciascun sito Active Directory. Non appena l'array di server Accesso client è stato configurato, è possibile configurare il database delle cassette postali in modo che, come endpoint MAPI, utilizzi questo array e non un server Accesso client specifico.

Per ulteriori informazioni sugli array di server Accesso client e su come configurare il database delle cassette postali in modo che utilizzi un array di server Accesso client per un sito Active Directory specifico, vedere Informazioni su Accesso client RPC.

Informazioni sui carichi di traffico in Exchange 2010

Prima di configurare il bilanciamento del carico, è opportuno conoscere quali siano i carichi che deve gestire un server Accesso client di Exchange 2010. Un server Accesso client di Exchange 2010 riceve tre tipi di flussi di traffico:

• Traffico da client esterni

• Traffico da client interni

• Traffico proxy da altri server Accesso client

Il traffico proxy proveniente da altri server Accesso client è il traffico inviato originariamente da un client esterno o interno a un server Accesso client e poi inoltrato a un altro server Accesso client. Ciò può avvenire per diverse ragioni. In particolare, avviene perché il client originario non riesce a connettersi direttamente al server Accesso client di destinazione. Un caso tipico è quando un utente cerca di accedere via Internet a una cassetta postale ubicata in un sito Active Directory senza accesso a Internet. Per ulteriori informazioni sull'inoltro, vedere Concetti relativi all'inoltro e al reinstradamento.

Ciascun tipo di flusso di traffico che ricevono i server Accesso client comprende richieste da diversi protocolli e proviene da dispositivi e computer client con caratteristiche diverse. A seconda delle caratteristiche è possibile utilizzare diverse strategie di bilanciamento del carico.

Inizio pagina

Informazioni sulle opzioni di bilanciamento del carico

Dal punto di vista tecnologico esistono differenze importanti tra le varie soluzioni di bilanciamento del carico esistenti.

• Prestazioni Numero di richieste al secondo che la soluzione può gestire.

• Gestibilità Facilità nel configurare e distribuire la soluzione di bilanciamento del carico.

• Automazione e rilevamento dei failover Capacità della soluzione di bilanciamento del carico di rilevare un errore imprevisto di un server o di un servizio Accesso client.

• Affinità Tipi di affinità tra server Accesso client e client supportati dalla soluzione di bilanciamento del carico.

Informazioni sull'affinità

Quando una soluzione di bilanciamento del carico offre l'affinità tra server Accesso client e client, significa che garantisce un'associazione stabile tra un client e un server Accesso client specifici. Il client può essere Outlook su un computer portatile, Microsoft Exchange ActiveSync su un dispositivo mobile, Microsoft Office Outlook Web App, Servizi Web di Exchange o qualsiasi altra applicazione client.

Grazie a questa associazione stabile, o affinità, tutte le richieste inviate dal client vengono inviate allo stesso server Accesso client. Alcuni protocolli di Exchange 2010 richiedono l'affinità, al contrario di altri protocolli di Exchange.

Bilanciamento carico di rete di Microsoft Windows (WNLB)

Bilanciamento carico di rete di Microsoft Windows (WNLB) è il software di bilanciamento del carico più comunemente usato con i server Exchange. Per poter utilizzare questo software con Microsoft Exchange è necessario considerare una serie di limitazioni.

• Il software non può essere utilizzato su server Exchange ove sono in uso anche gruppi di disponibilità del database (DAG) dal momento che è incompatibile con il clustering di failover di Windows. Se è in uso un gruppo di disponibilità del database di Exchange 2010 e si desidera utilizzare Bilanciamento carico di rete di Microsoft Windows, occorrerà che il ruolo server Accesso client e il ruolo server Cassette postali siano eseguiti da server distinti.

• Per problemi di prestazioni, è sconsigliabile creare un array con più di otto server se il bilanciamento del carico viene eseguito da Bilanciamento carico di rete di Microsoft Windows.

• Il software Bilanciamento carico di rete di Microsoft Windows non rileva le interruzioni di servizio, ma solo le interruzioni del server tramite l'indirizzo IP. Ciò significa che, nel caso di errore di un particolare servizio Web, come, ad esempio, Outlook Web App, con il server ancora in funzione, il software non rileverà l'errore e continuerà a instradare le richieste al server Accesso client. Pertanto, occorrerà intervenire manualmente per rimuovere dal pool di bilanciamento del carico il server Accesso client su cui si è verificato l'errore.

• La configurazione di Bilanciamento carico di rete di Microsoft Windows può causare un traffico eccessivo sulle porte, il che può determinare un sovraccarico sulle reti.

• Dal momento che esegue l'affinità dei client utilizzando l'indirizzo IP di origine, Bilanciamento carico di rete di Microsoft Windows non è una soluzione efficace se il pool IP di origine è ridotto, come, ad esempio, quando questo proviene da una subnet di una rete remota o quando l'organizzazione utilizza la conversione degli indirizzi di rete.

Consigli sul bilanciamento del carico

Sono disponibili diverse opzioni di bilanciamento del carico. La scelta dell'opzione dipende dalle dimensioni e dalla configurazione della rete.

Bilanciamento carico di rete di Microsoft Windows con affinità basata sull'IP di origine

La prima opzione di bilanciamento del carico è costituita da Bilanciamento carico di rete di Microsoft Windows con affinità basata sull'IP di origine. Questa soluzione è adatta agli ambienti in cui per ciascun sito Active Directory vi è più di un server Accesso client ma meno di otto. Questa soluzione è integrata in Windows e non richiede ulteriori computer.

In due casi l'utilizzo di Bilanciamento carico di rete di Micorsoft Windows non è opportuno.

• L'organizzazione è provvista di un server proxy inverso che comunica direttamente con il server Accesso client e non attraverso l'indirizzo IP virtuale di Bilanciamento carico di rete di Microsoft Windows. Il server proxy inverso nasconde gli indirizzi IP client all'array di server Accesso client. Pertanto, l'affinità basata sull'IP di origine non funziona come previsto. Tuttavia, è possibile utilizzare Bilanciamento carico di rete di Microsoft Windows per eseguire il bilanciamento di carico del traffico interno.

• Nell'organizzazione molti client accedono ai server Accesso client tramite una serie molto ridotta di indirizzi IP. Bilanciamento carico di rete di Microsoft Windows tende ad associare un'intera subnet di classe C a un singolo server Accesso client.

Bilanciamento del carico hardware

Se i server Accesso client per un singolo sito Active Directory sono più di otto, l'organizzazione necessita di una soluzione di bilanciamento del carico più affidabile. Nonostante siano disponibili software di bilanciamento del carico affidabili, le soluzioni hardware offrono la massima efficienza. Per ulteriori informazioni sulle soluzioni di bilanciamento del carico del server Exchange 2010, vedere Microsoft Unified Communications Hardware Load Balancer Deployment.

I sistemi hardware di bilanciamento del carico supportano flussi di traffico molto elevati e possono essere configurati in molti modi. La maggior parte dei fornitori di queste soluzioni dispongono di documentazione dettagliata sul funzionamento dei propri prodotti con Exchange 2010. Il modo più semplice di configurare una soluzione hardware di bilanciamento del carico è creare un elenco di fallback dei metodi di affinità che verranno applicati dalla soluzione. Ad esempio, la soluzione tenterà dapprima l'affinità basata su cookie, poi quella basata sull'ID di sessione SSL e, infine, l'affinità basata sull'IP di origine.

Soluzioni proxy inverse

Se si è provvisti di una soluzione proxy inversa in grado di eseguire il bilanciamento del carico per i server che pubblica in Internet, come, ad esempio, Microsoft Forefront Threat Management Gateway (TMG) o Forefront Unified Access Gateway (UAG), se ne consiglia l'utilizzo.

Dal momento che, per raggiungere i server Accesso client, il traffico passa attraverso il server proxy inverso, l'indirizzo IP originale del client viene sostituito dall'indirizzo IP del server proxy inverso. Ciò interrompe l'affinità basata sull'IP di origine. Questo problema può essere risolto in vari modi, come, ad esempio, configurando il server proxy inverso come gateway predefinito per la subnet utilizzata per l'inoltro.

Tuttavia, la maggior parte dei server proxy inversi sono in grado di eseguire il bilanciamento del carico per i servizi che pubblicano su Internet. Questi server supportano il bilanciamento del carico tramite i cookie creati dalla soluzione di bilanciamento per i servizi Exchange compatibili con tale metodo. Questo metodo è più affidabile del bilanciamento del carico basato sull'IP di origine. Affinchè possa essere adottato, il server proxy inverso deve poter leggere e modificare il flusso di dati HTTP. Se si utilizza SSL, il server proxy inverso dovrà decodificare il traffico per poterne leggere i contenuti e creare i cookie nel flusso dati. Si noti che, in alcune circostanze, la decodifica non è possibile (ad esempio, nei casi in cui si utilizza l'autenticazione del certificato client quando il client si collega al server Accesso client).

Inizio pagina

Opzioni di affinità

Soluzioni di bilanciamento del carico diverse offrono metodi diversi per associare i client a server Accesso client specifici. Tra i tipi di affinità offerti dalle soluzioni di bilanciamento del carico, sia hardware che software, alcuni sono molto diffusi. Per ciascuna opzione di bilanciamento del carico non sono disponibili tutti i tipi di affinità:

• Bilanciamento carico di rete di Microsoft Windows fornisce solo l'affinità basata sull'IP di origine o non fornisce nessun tipo di affinità.

• Una soluzione software di bilanciamento del carico in un array di server distinto può utilizzare i cookie creati dal sistema di bilanciamento del carico con i protocolli che li supportano e l'affinità basata sull'IP di origine con i protocolli restanti.

• Le soluzioni hardware di bilanciamento del carico con ripartizione del carico SSL consentono di configurare comportamenti più complessi. Ad esempio, è possibile configurare un insieme di cookie esistenti in modo da gestire i protocolli che li supportano, nonché l'IP di origine, l'ID di sessione SSL e il cookie creato dalla soluzione di bilanciamento del carico.

Oltre alle opzioni supportate dai diversi sistemi di bilanciamento del carico, è possibile configurare alcune di queste procedure in modo che vengano applicate soltanto a certi protocolli e servizi di Exchange. Poiché ciascun protocollo funziona diversamente, ciò consente di ottimizzare le prestazioni.

Cookie o intestazioni HTTP esistenti

L'uso di cookie o intestazioni HTTP esistenti costituisce il modo più affidabile per identificare un client e associarlo a un server Accesso client specifico. Tali cookie e intestazioni vengono creati dal client o dal server come parte del protocollo di comunicazione. In questo modo la soluzione di bilanciamento del carico non deve modificare il traffico e ciò contribuisce ad ottimizzare le prestazioni.

Quando si utilizza questa opzione di affinità, tenere presente quanto segue:

• La soluzione di bilanciamento del carico deve supportare questo tipo di affinità. Al momento questo tipo di affinità è supportato solo dai sistemi di bilanciamento del carico hardware.

• Questa affinità funziona solo per i protocolli che gestiscono il traffico attraverso l'HTTP.

• In questo caso, deve esservi un cookie o un'intestazione esistente che rimane costante durante la sessione client ed è univoca per ciascun client (o ciascun piccolo gruppo di client) specifico del protocollo.

• La soluzione di bilanciamento del carico deve essere in grado di leggere ed interpretare il flusso di dati HTTP. Se si utilizza SSL, la soluzione deve decodificare il traffico per leggerne i contenuti. Talvolta ciò determina un sovraccarico di lavoro per il sistema di bilanciamento del carico. Inoltre, in alcune circostanze, la decodifica non è possibile (ad esempio, nei casi in cui si utilizza l'autenticazione del certificato client con la sessione SSL quando il client si collega al server Accesso client).

I cookie e le intestazioni HTTP esistenti adatte per il bilanciamento del carico che sono disponibili nei protocolli di Exchange 2010 sono:

• Intestazione di autorizzazione all'autenticazione di base HTTP   Questa intestazione si esegue quando viene utilizzata l'autenticazione di base HTTP. L'autenticazione di base è il tipo di autenticazione predefinito e maggiormente utilizzato per Exchange ActiveSync. Questa intestazione è inconsueta per gli altri protocolli e metodi di autenticazione. L'intestazione di autorizzazione all'autenticazione di base invia allo stesso server Accesso client tutto il traffico che utilizza l'autenticazione di base e che proviene da un utente specifico. Questa intestazione viene utilizzata anche quando il traffico di Outlook viene trasmesso interamente attraverso il protocollo HTTP e i client si trovano dietro un server proxy inverso.

• Cookie UserContext OWA HTTP   Questo cookie viene eseguito con Outlook Web App, il solo client che lo utilizza. Quando l'autenticazione utilizzata con Outlook Web App è del tipo FBA, ossia basata su moduli, che è la configurazione predefinita, un piccolo numero di richieste viene eseguito all'inizio di una sessione di Outlook Web App prima che il cookie UserContext venga creato. Per garantire che tali richieste utilizzino l'affinità per connettere il client allo stesso server Accesso client, condizione essenziale affinché l'autenticazione basata su moduli riesca, quando si utilizza il cookie UserContext è necessario che sia disponibile un'opzione di affinità di fallback. Si consiglia di utilizzare, come fallback, l'ID di sessione SSL o l'affinità basata sull'IP di origine in modo da garantire l'affinità a queste richieste iniziali, prima che il sistema di bilanciamento del carico ottenga il cookie UserContext da usare.

  Nota

  Le richieste di Outlook Web App che utilizzano l'accesso esplicito per accedere a una cassetta postale specifica portano all'utilizzo di un cookie UserContext con un nome e un ID diversi. Il cookie inizia con UserContext, ma vi è aggiunta una stringa che identifica la singola cassetta postale. L'esecuzione del bilanciamento del carico tramite il cookie UserContext risulta complicata perché la soluzione di bilanciamento del carico deve prima individuare un cookie che inizi con UserContext. Ciò può determinare la diminuzione del livello delle prestazioni.

• Cookie msExchEcpCanary del Pannello di controllo di Exchange HTTP   Questo cookie funziona solo con il Pannello di controllo di Exchange.

• Cookie OutlookSession di Outlook 2010 HTTP   I sistemi hardware di bilanciamento del carico supportano il cookie OutlookSession e altri cookie generici. Nella tabella seguente sono indicati i requisiti per il supporto del cookie client OutlookSession per RPC e HTTP:

  	Windows XP	Windows Vista	Windows 7
  Outlook 2003	Non supportata	Non supportata	Non supportata
  Outlook 2007	Non supportata	Non supportata	Non supportata
  Outlook 2007 Hosting Pack (KB2544404)	Non supportata	Supportata	Supportata
  Outlook 2010	Non supportata	Supportata	Supportata

  Nota

  Microsoft Outlook eseguito in Windows XP non supporta il cookie OutlookSession per il bilanciamento del carico. In questo scenario, è consigliabile utilizzare il bilanciamento del carico IP.

• Cookie OutlookSession di Remote PowerShell HTTP   Questo metodo funziona solo con Remote PowerShell.

Inizio pagina

Cookie creato dal sistema di bilanciamento del carico

Il secondo metodo più affidabile per associare una sessione client a un server Accesso client è quello che si basa sull'uso di un cookie creato dal sistema di bilanciamento del carico. Tale sistema aggiunge un cookie HTTP nella conversazione del protocollo client/server che poi utilizza per determinare quale server Accesso client debba gestire le richieste in arrivo. Le applicazioni di Exchange 2010 che supportano questo metodo sono Outlook Web App, il Pannello di controllo di Exchange e Remote PowerShell. Questo tipo di cookie presenta numerose limitazioni.

• Il sistema di bilanciamento del carico deve supportare questo tipo di affinità. Al momento questo tipo di affinità è supportato solo dalle soluzioni di bilanciamento del carico hardware e software in esecuzione su livelli di server distinti.

• Questo metodo è valido solo per i protocolli che gestiscono il traffico attraverso l'HTTP. Non è possibile utilizzarlo per il servizio Accesso client RPC, il servizio Rubrica di Exchange, POP3 o IMAP4.

• La soluzione di bilanciamento del carico deve essere in grado di leggere ed interpretare il flusso di dati HTTP. Se si utilizza SSL, la soluzione deve decodificare il traffico per leggerne i contenuti. Talvolta ciò determina un sovraccarico di lavoro per il sistema di bilanciamento del carico. In altri casi l'intepretazione del flusso di dati HTTP da parte del sistema di bilanciamento del carico non è possibile (ad esempio, quando si utilizza l'autenticazione del certificato client sul server Accesso client).

• Il client deve poter ricevere cookie arbitrari dal server per poi includerli in tutte le richieste successive che invia a quel server. I client di Exchange ActiveSync, quelli di Outlook Anywhere ed alcuni del Servizio Web di Exchange, come, ad esempio, i dispositivi di Microsoft Office Communications Server 2007, non supportano questo metodo.

ID di sessione SSL

Il bilanciamento del carico basato sull'ID di sessione SSL fornisce maggiori dettagli rispetto all'affinità basata sull'IP di origine e consente di distribuire il traffico proveniente da client diversi anche se questi utilizzano lo stesso indirizzo IP. Il bilanciamento del carico tramite l'ID di sessione SSL ha l'ulteriore vantaggio di poter essere eseguito senza decodifica del traffico SSL e ciò è necessario quando si utilizza l'autenticazione del certificato client e quando la connessione SSL termina sul server Accesso client.

L'affinità basata sull'ID di sessione SSL è sconsigliata nelle due situazioni seguenti:

• Alcuni client, come Internet Explorer 8, ricreano la sessione SSL per ciascun processo del browser in esecuzione sul computer client. Di conseguenza, viene avviata una nuova sessione SSL per ciascuna finestra di Outlook Web App. Poiché questa situazione interrompe l'affinità del client per Outlook Web App, tale metodo di bilanciamento del carico non è supportato in Exchange 2010. Alcuni dispositivi portatili, come, ad esempio, iPhone di Apple, creano anch'essi nuove sessioni SSL per alcune porzioni della comunicazione tra Exchange ActiveSync e Exchange.

  Nota

  Quando si utilizza l'autenticazione del certificato client, i browser utilizzano la stessa sessione SSL per tutto il traffico indirizzato verso un determinato nome host. Fintanto che l'autenticazione del certificato client è abilitata, l'ID di sessione SSL rappresenta una valida opzione di affinità per Outlook Web App e il Pannello di controllo Exchange.

• Nel caso di Outlook Anywhere, i server Accesso client utilizzeranno il componente proxy RPC Windows per accoppiare le connessioni RPC_DATA_IN e RPC_DATA_OUT. Ciò può influire negativamente sulle prestazioni.

IP di origine

Il metodo più comune per stabilire l'affinità tra client e server Accesso client è l'affinità basata sull'IP di origine. Il sistema di bilanciamento del carico esamina un indirizzo IP del client e invia tutto il traffico da un IP di origine specifico a un server Accesso client specifico. Questo è l'unico tipo di affinità supportato da Bilanciamento carico di rete di Microsoft Windows. Due sono gli aspetti importanti da considerare quando si utilizza l'affinità basata sull'IP di origine.

• L'affinità viene interrotta quando il client cambia indirizzo IP. Un caso tipico è quando un computer portatile viene disconnesso da una rete LAN cablata e connesso a una rete Wi-Fi oppure quando si connette in roaming a più reti Wi-Fi. La modifica dell'indirizzo IP del client ha un impatto diretto sugli utenti. Ad esempio, quando usano Outlook Web App, gli utenti dovranno autenticarsi ogniqualvolta il proprio computer ottiene un nuovo indirizzo IP.

• Se i client che accedono alla soluzione di bilanciamento del carico dallo stesso indirizzo IP sono numerosi, la distribuzione del carico diverrà irregolare. Le dimensioni di tale irregolarità dipendono dal numero di client con un dato indirizzo IP. Ad esempio, se i server Accesso client sono quattro e il 50% dei client accedono al sistema di bilanciamento del carico dallo stesso indirizzo IP, almeno il 50% del traffico verrà inoltrato a un server Accesso client e gli altri tre gestiranno il restante 50%. Due sono i motivi principali per cui la maggior parte dei client accedono all'organizzazione Exchange attraverso un singolo indirizzo IP.

  • Server NAT (Network Address Translator) o server proxy in uscita, come, ad esempio, Microsoft Forefront Threat Management Gateway (TMG). Quando tra i client e i server Accesso client si trova un server NAT (Network Address Translator) o un server proxy in uscita, gli indirizzi IP client originari vengono schermati dall'indirizzo IP di questo server.

  • Traffico proxy tra server Accesso client. In alcuni casi, un server Accesso client inoltra il traffico a un altro server Accesso client. Di norma, questo avviene tra siti Active Directory perché un client deve accedere al server Accesso client ubicato nello stesso sito Active Directory in cui si trova la sua cassetta postale. Per ulteriori informazioni sull'inoltro, vedere Concetti relativi all'inoltro e al reinstradamento.

Nessuna affinità

L'ultimo metodo di bilanciamento del carico consiste nel mancato utilizzo dell'affinità. Quando l'affinità non viene utilizzata, ciascuna richiesta proveniente da un client viene assegnata a un server Accesso client in modo casuale. Questo metodo è sconsigliato con i protocolli che richiedono l'affinità o che traggono vantaggio in termini di prestazioni dall'affinità.

Si consiglia di non utilizzare l'affinità con i protocolli che non la necessitano quando è configurata la ripartizione del carico SSL.

Inizio pagina

Riepilogo delle opzioni di bilanciamento del carico

Nella tabella che segue vengono riepilogate le opzioni di bilanciamento del carico disponibili.

Ciascuno dei metodi illustrati presenta vantaggi e svantaggi.

• Le soluzioni hardware di bilanciamento del carico offrono funzionalità per l'ottimizzazione delle prestazioni e della protezione (ad esempio, la ripartizione del carico SSL e la verifica del traffico).

• Le soluzioni software di bilanciamento del carico disponibili su un livello server separato vengono normalmente fornite all'interno di pacchetti software più ampi e dispongono di funzioni di proxy inverso come la preautenticazione, la ripartizione del carico SSL e la verifica accurata del traffico. Quando tali soluzioni software eseguono la preautenticazione degli utenti, questi non devono autenticarsi nuovamente in caso di errore imprevisto sul server Accesso client a cui sono associati dall'affinità. Tuttavia, alcuni software di bilanciamento del carico necessitano dell'affinità tra il client e il server proxy inverso. In questo caso, occorrerà posizionare un altro livello di bilanciamento del carico prima dei server proxy inversi, in modo che questi possano eseguire le attività di bilanciamento del carico per i server Accesso client.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.