Bilanciamento del carico

Il bilanciamento del carico migliora la disponibilità e la scalabilità di un sito Web organizzando in cluster server proxy e server delle applicazioni, in modo trasparente. La scalabilità di un'infrastruttura IT viene di gran lunga migliorata dal momento che la potenza dell'elaborazione back-end può essere aggiunta in modo trasparente.

Bilanciamento del carico di più host di contenuti

Una forte domanda può essere soddisfatta duplicando il contenuto su più host; in tal caso però sarà necessario trovare un modo per bilanciare il carico tra le varie macchine. Il servizio DNS (Domain Name Service) può offrire un bilanciamento del carico round-robin di base, che tuttavia in molte condizioni non funziona in modo ottimale.

Una soluzione più sofisticata per bilanciare il carico tra più host di contenuti è quella che prevede l'uso del componente Dispatcher di Load Balancer, come illustrato nella Figura 5. In questa configurazione, tutti gli host di contenuti (le macchine contrassegnate col numero 5) memorizzano lo stesso contenuto. Gli host vengono definiti in modo da formare un cluster con bilanciamento del carico mentre a una delle interfacce di rete della macchina Load Balancer (4) vengono assegnati un nome host e un indirizzo IP dedicati al cluster. Quando un utente finale che utilizza la macchina contrassegnata col numero 1 richiede il file X, la richiesta passa attraverso Internet (2) ed entra nella rete interna dell'azienda mediante il gateway Internet (3). Il Dispatcher intercetta la richiesta poiché il proprio URL è mappato sul nome host e sull'indirizzo IP del Dispatcher. Il Dispatcher determina quale host di contenuti nel cluster è attualmente il più adatto a supportare la richiesta, quindi inoltra la richiesta a quell'host, che, quando il metodo di inoltro MAC è configurato, restituisce il file X direttamente al client (ossia, il file X non passa attraverso Load Balancer).

Figura 5. Bilanciamento del carico di più host di contenuti
La figura qui riportata illustra il bilanciamento del carico di più host di contenuti
Legenda: 1—Client   2—Internet   3—Router/Gateway   4—Dispatcher   5—Host di contenuti
Nota:
il Dispatcher fornisce tre metodi di inoltro:

Per impostazione predefinita, il Dispatcher usa un bilanciamento del carico simile al tipo round-robin del servizio DNS, ma riesce a risolvere molte delle inefficienze del servizio DNS. A differenza di DNS, individua la mancata disponibilità o l'inaccessibilità di un host di contenuti, ma non continua ad indirizzare i client a un host di contenuti non disponibile. Inoltre, individuando nuove connessioni attive e terminate, tiene conto dell'effettivo carico degli host di contenuti. È inoltre possibile ottimizzare il bilanciamento del carico attivando i componenti gestore e advisor di Load Balancer, che individuano lo stato di un host di contenuti con maggiore accuratezza e includono informazioni più dettagliate nel processo decisionale relativo al bilanciamento del carico. Il gestore consente di assegnare carichi differenti in base ai diversi fattori del processo decisionale, quindi di personalizzare ulteriormente il bilanciamento del carico di un sito.

Bilanciamento del carico di più server proxy inversi

Il componente Dispatcher di Load Balancer può eseguire il bilanciamento del carico anche per più macchine Caching Proxy. Nel caso di un sito Web molto visitato, la richiesta di contenuti può essere di gran lunga superiore rispetto a quella che potrebbe soddisfare un solo server proxy e ciò può ridurne le prestazioni.

È possibile disporre di più sistemi Caching Proxy che eseguono funzioni proxy per un solo host di contenuti (simile alla configurazione illustrata nella Figura 1), ma se il sito è visitato da un numero di utenti tale da richiedere più server proxy, probabilmente saranno necessari più host di contenuti i cui carichi siano bilanciati da Load Balancer. La Figura 6 illustra questa configurazione. Il Dispatcher contrassegnato col numero 4 bilancia il carico di due server proxy (5) mentre il Dispatcher contrassegnato col numero 7 bilancia il carico di un cluster di tre host di contenuti (8).

Figura 6. Bilanciamento del carico di più server proxy inversi e host del contenuto
La figura qui riportata illustra il bilanciamento del carico di più server proxy e host di contenuti
Legenda: 1—Client   2—Internet   3—Router/Gateway   4—Dispatcher   5—server proxy   6—Cache   7—Dispatcher   8—Host di contenuti

Il nome host del cluster del Dispatcher, contrassegnato col numero 4, è il nome host che appare negli URL del contenuto Web dell'azienda (ossia, il nome del sito Web visualizzato su Internet). Il nome host del cluster del Dispatcher, contrassegnato col numero 7, non è visibile su Internet, quindi è possibile assegnargli un valore a scelta. Ad esempio, per l'azienda ABC Corporation, un nome host adeguato per il Dispatcher, contrassegnato col numero 4, potrebbe essere www.abc.com, mentre per il Dispatcher, contrassegnato col numero 7, potrebbe essere http-balancer.abc.com.

Si supponga che un browser, che risiede su una delle macchine client contrassegnata col numero 1, debba accedere a un file X memorizzato sui server di contenuti contrassegnati col numero 8. La richiesta HTTP passa attraverso Internet (2) ed entra nella rete interna dell'azienda dal gateway (3). Il router indirizza la richiesta al Dispatcher, contrassegnato col numero 4, che la inoltra al server proxy (5), in quel momento considerato il più adatto a gestirla, in base all'algoritmo di bilanciamento del carico. Se il server proxy dispone di un file X nella cache (6), lo restituisce direttamente al browser, ignorando il Dispatcher contrassegnato col numero 4.

Se il server proxy non dispone di una copia del file X nella cache, crea una nuova richiesta con il proprio nome host nel campo origine dell'intestazione e la invia al Dispatcher contrassegnato col numero 7. Load Balancer determina quale host di contenuti (8) è attualmente in grado di soddisfare la richiesta, quindi la indirizza a tale destinazione. L'host di contenuti richiama il file X dalla memoria e lo restituisce direttamente al server proxy, ignorando il Dispatcher contrassegnato col numero 7. Il server proxy memorizza il file X nella cache, se necessario, e lo inoltra al browser, ignorando il Dispatcher contrassegnato col numero 4.

Load Balancer con più server proxy diretti

Se si fornisce l'accesso a Internet a un numero elevato di clienti, questi possono generare una domanda di accesso a Internet maggiore di quella che un unico proxy possa fornire. Nel momento in cui il Caching Proxy viene sovraccaricato di richieste, i client possono avere tempi di risposta peggiore di quelli relativi a un accesso a Internet diretto. Inoltre, se il Caching Proxy riporta un errore o diventa non disponibile a causa di un errore di rete, l'accesso a Internet diventa impossibile. La soluzione consiste nell'installare più macchine di Caching Proxy e utilizzare il dispatcher di Load Balancer per bilanciare il carico tra questi.

Senza il Dispatcher, è possibile fornire un proxy trasparente con più macchine Caching Proxy solo se i router possono indirizzare lo stesso tipo di traffico a più di un Caching Proxy; non tutti i router supportano questa funzione. È possibile fornire un servizio proxy diretto regolare su più macchine Caching Proxy senza il Dispatcher, ma è necessario configurare esplicitamente i browser del client in modo che utilizzino una delle macchine del Caching Proxy come proxy primario. Se il Caching Proxy riporta un errore, diventa sovraccarico o inaccessibile, gli utenti finali non potranno più accedere a Internet. Per evitare questa situazione, è possibile creare un file PAC (proxy automatic configuration), come descritto in Caching Proxy diretto trasparente (solo sistemi Linux), che indica al browser di eseguire il failover su uno o più caching proxy secondari. Un file PAC non risolve la necessità di bilanciare il carico tra le macchine del Caching Proxy; tuttavia se un Caching Proxy riceve molte più richieste di un altro, le sue prestazioni vengono ridotte, implicando tempi di risposta più lunghi per i client del browser. Per tutti i client che verificano questo calo delle prestazioni, è necessario configurare un numero quasi uguale al numero di browser perutilizzare ogni Caching Proxy e tenere traccia della distribuzione manualmente in modo da poter conservare il carico anche se vengono aggiunti o rimossi i browser.

La Figura 7 illustra una configurazione di rete in cui il carico del Dispatcher bilancia un cluster di macchine di Caching Proxy. Una delle interfacce di rete della macchina del Dispatcher è configurata in modo da avere un nome host e un indirizzo IP dedicati per il cluster. I browser del client sono configurati per indirizzare le richieste Internet al nome host del cluster. Quando ad esempio un browser su una delle macchine del client contrassegnato come 1 deve accedere al file X su un host del contenuto (7), questo indirizza la richiesta al nome host o all'indirizzo del cluster, dove il Dispatcher (2) la intercetta e la invia al Caching Proxy appropriato (3). Il Caching Proxy crea una nuova richiesta, la inoltra mediante il gateway dell'azienda (5) e su Internet (6) e, se possibile, memorizza il file restituito nella cache (4), come descritto più dettagliatamente in Caching Proxy diretto

Nota:
La funzione proxy trasparente è disponibile solo su sistemi Linux.
Figura 7. Utilizzo del Dispatcher per il bilanciamento del carico di più caching proxy.
Questa illustrazione rappresenta un bilanciamento del carico di più proxy

Il Dispatcher rileva quando una delle macchine Caching Proxy non è disponibile e indirizza automaticamente le richieste a un'altra macchina. Ciò consente di arrestare una macchina Caching Proxy per la manutenzione senza interrompere l'accesso a Internet. Il Dispatcher ha numerose opzioni di configurazione che è possibile utilizzare per controllare i fattori da considerare quando si prendono decisioni relative al bilanciamento del carico. È inoltre possibile installare programmi Dispatcher ausiliari sulle macchine Caching Proxy per monitorarne lo stato e restituire le informazioni al Dispatcher. Per maggiori dettagli, fare riferimento al manuale WebSphere Application Server Load Balancer - Guida alla gestione. L'utilizzo di più macchine Caching Proxy introduce una possibile inefficienza in quanto più di un Caching Proxy può memorizzare nella cache lo stesso file se diversi client richiedono il file mediante macchine differenti. Per eliminare la ridondanza, è possibile configurare l'accesso alla cache remoto (RCA, remote cache access), che consente a tutti i proxy in un gruppo definito di condividere il contenuto delle proprie cache. I proxy nel gruppo RCA utilizzano tutti lo stesso algoritmo per determinare il Caching Proxy responsabile per un determinato URL. Quando un Caching Proxy intercetta un URL per cui non è responsabile, invia la richiesta al Caching Proxy appropriato. Il Caching Proxy responsabile esegue le operazioni necessarie a soddisfare la richiesta, richiamandole dalla cache o inoltrando la richiesta all'host del contenuto rilevante e memorizzando nella cache il file restituito. Il Caching Proxy responsabile invia quindi il file al Caching Proxy originale, che lo distribuisce all'utente finale richiedente.

Nel gruppo RCA, se il Caching Proxy responsabile per un determinato URL riporta un errore, allora il Caching Proxy originale, che ha ricevuto la richiesta client, accederà direttamente all'host del contenuto (o a un server Caching Proxy di backup, se definito). Ciò implica che gli utenti possano accedere ai file fino a che almeno un Caching Proxy in un gruppo RCA funziona correttamente.

Questa configurazione soddisfa una domanda elevata di accesso a Internet utilizzando il Dispatcher per bilanciare il carico di richieste su più macchine Caching Proxy. Un possibile problema sta nel fatto che il Dispatcher è un unico punto di errore. Se riporta un errore o diventa non disponibile a causa di un errore di rete, i client del browser non possono raggiungere i Caching Proxy o Internet. La soluzione consiste nel configurare un altro Dispatcher in modo che funzioni come backup per il Dispatcher primario, come illustrato nella Figura 8.

Figura 8. Utilizzo di un Dispatcher primario e di backup per fornire un accesso a Internet ad alta disponibilità.
Questo grafico illustra un Dispatcher primario e uno di backup per bilanciare il carico di più proxy

In questa figura è riportato un browser in esecuzione su una delle macchine contrassegnate con 1 che di solito indirizza la richiesta per un file X al Dispatcher primario (2), che a sua volta indirizza la richiesta al Caching Proxy (4) selezionato in base ai criteri di bilanciamento del carico del Dispatcher. Il Caching Proxy crea una nuova richiesta, la indirizza mediante il gateway dell'azienda (6) su Internet (7) all'host del contenuto (8) e memorizza il file X restituito nella cache (5) se possibile (per una descrizione più dettagliata di questa parte del processo, fare riferimento a Caching Proxy diretto).

In questa configurazione, il Dispatcher di backup (3) non esegue il bilanciamento del carico se quello primario è operativo. I Dispatcher primario e di backup tengono traccia dello stato l'uno dell'altro scambiando periodicamente messaggi detti heartbeat. Se il Dispatcher di backup rileva che quello primario ha riportato un errore, allora si assume automaticamente la responsabilità di bilanciare il carico intercettando le richieste dirette al nome host e all'indirizzo IP del Dispatcher primario. Inoltre è possibile configurare due Dispatcher che saranno in grado di garantirsi reciprocamente un'elevata disponibilità. In questo caso, ognuno di essi esegue attivamente il bilanciamento del carico per un cluster separato di caching proxy, funzionando simultaneamente da backup per l'altro dispatcher. Per maggiori informazioni, fare riferimento a WebSphere Application Server Load Balancer - Guida alla gestione.

Il Dispatcher generalmente non utilizza molte risorse di memoria o di elaborazione, quindi è possibile eseguire altre applicazioni sulla macchina del Dispatcher. Se è necessario ridurre al minimo i costi inerenti l'apparecchiatura, è addirittura possibile eseguire il Dispatcher di backup sulla stessa macchina di Caching Proxy. La Figura 9 illustra una tale configurazione, in cui il Dispatcher di backup viene eseguito sulla stessa macchina (3) del Caching Proxy.

Figura 9. Collocazione del Dispatcher di backup su una macchina Caching Proxy.
Questo grafico illustra un Dispatcher primario e uno di backup per bilanciare il carico di più proxy