Questo capitolo descrive i fattori che un responsabile della pianificazione di rete deve considerare prima di installare e configurare il componente Dispatcher.
Questo capitolo include le seguenti sezioni:
Dispatcher consiste delle seguenti funzioni:
Il Dispatcher fornisce inoltre degli advisor che non scambiano informazioni specifiche sul protocollo, come l'advisor DB2 che riporta lo stato dei server DB2 e l'advisor ping che comunica se il server risponde o meno a un ping. Per un elenco completo degli advisor, vedere Elenco di advisor.
È possibile anche scrivere advisor personalizzati (vedere Creazione di advisor personalizzati).
L'uso degli advisor è facoltativo ma consigliato.
Le tre funzioni chiave del Dispatcher (executor, gestore e advisor interagiscono per bilanciare e distribuire le richieste in entrata tra i server. Insieme al bilanciamento del carico delle richieste, l'executor controlla il numero delle nuove connessioni, delle connessioni attive e delle connessioni terminate. L'executor esegue inoltre la raccolta di dati inutili di connessioni completate o ripristinate e comunica tali informazioni al gestore.
Il gestore raccoglie le informazioni provenienti dall'executor, dagli advisor e da un programma di monitoraggio del sistema, quale Metric Server. In base alle informazioni ricevute, il gestore regola il peso delle macchine server su ciascuna porta e comunica all'executor i nuovi pesi da utilizzare nel bilanciamento delle nuove connessioni.
Gli advisor controllano ciascun server sulla porta assegnata, per determinare il tempo di risposta del server e la disponibilità, quindi, comunicano queste informazioni al gestore. Anche gli advisor controllano se un server è attivo o meno. Senza il gestore e gli advisor, l'executor esegue una pianificazione con il metodo round-robin basata sui pesi attuali dei server.
Con il Dispatcher, è possibile selezionare uno dei tre metodi di inoltro specificati a livello di porta: inoltro MAC, NAT/NAPT o CBR (content-based routing).
Utilizzando il metodo di inoltro MAC del Dispatcher (il metodo di inoltro predefinito), il Dispatcher bilancia il carico delle richieste in entrata al server selezionato e il server restituisce la risposta direttamente al client senza coinvolgere il Dispatcher. Con questo metodo di inoltro, il Dispatcher controlla soltanto il traffico entrante dai client verso i server Esso non gestisce il traffico uscente dai server verso i client. Ciò riduce significativamente il suo impatto sull'applicazione e migliora le prestazioni della rete.
Il metodo di inoltro può essere selezionato quando si aggiunge una porta con il comando dscontrol port add cluster:port method value. Il valore del metodo di inoltro predefinito è mac. Il parametro method può essere specificato solo quando si aggiunge la porta. Dopo aver aggiunto la porta, non è possibile modificare l'impostazione del metodo di inoltro. Consultare dscontrol port -- configura le porte per ulteriori informazioni.
Limitazione per Linux: Linux impiega un modello basato su host per comunicare gli indirizzi hardware agli indirizzi IP utilizzando ARP. Questo modello non è compatibile con i requisiti del server backend o del server con disponibilità elevata, per quel che riguarda il metodo di inoltro mac di Load Balancer. Vedere Alternative per l'aggiunta dell'alias loopback Linux quando si utilizza il metodo di inoltro mac di Load Balancer, che contiene un numero di soluzioni per modificare il funzionamento del sistema Linux in modo da renderlo compatibile con l'inoltro mac di Load Balancer.
Su Linux, esistono delle limitazioni quando si utilizzano server zSeries o S/390 che hanno schede Open System Adapter (OSA). Consultare Problema: su Linux, esistono delle limitazioni quando si utilizzano server zSeries o S/390 che hanno schede OSA (Open System Adapter), per le possibili soluzioni alternative.
Utilizzando la capacità NAT (Network Address Translation) o NAPT (Network Address Port Translation) del Dispatcher si elimina la limitazione che prevede di dover posizionare i server sottoposti a bilanciamento del carico su una rete collegata localmente. Se si desidera collegare server situati in ubicazioni remote, è possibile utilizzare la tecnica del metodo di inoltro NAT anziché la tecnica di incapsulamento GRE/WAN. È anche possibile utilizzare la funzione NAPT per accedere a più daemon server che risiedono su ciascuna macchina sottoposta a bilanciamento del carico, dove ogni daemon è in ascolto su una specifica porta.
È possibile configurare un server con più daemon in due modi differenti:
Questa applicazione funziona bene con protocolli di applicazioni di livello superiore come HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, ecc.
Limitazioni:
Saranno necessari tre indirizzi IP per la macchina Dispatcher - indirizzo nfa, cluster e mittente. Per implementare NAT/NAPT, effettuare quanto segue (vedere anche Operazioni di esempio per configurare i metodi di inoltro nat o cbr del Dispatcher):
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
Mappa il numero di porta (specifico per il Dispatcher) di destinazione della richiesta client sul numero di porta del server che il Dispatcher utilizza per bilanciare il carico delle richieste del client. Il parametro mapport consente a Load Balancer di ricevere una richiesta del client su una porta e di trasmetterla a una porta differente sulla macchina server. Con il parametro mapport è possibile bilanciare il carico delle richieste di un client su una macchina server che potrebbe disporre di più daemon server attivi. Il valore predefinito per mapport è il numero di porta di destinazione della richiesta client.
L'indirizzo mittente è un indirizzo univoco o un nome host configurato sulla macchina Dispatcher. Il Dispatcher utilizza l'indirizzo mittente come indirizzo di origine quando bilancia il carico delle richieste del client al server. In questo modo, il server restituisce il pacchetto alla macchina Dispatcher, anziché inviarlo direttamente al client. (Il Dispatcher inoltra quindi il pacchetto IP al client.) Quando si aggiunge il server, è necessario specificare il valore dell'indirizzo mittente. Non è possibile modificare l'indirizzo mittente, a meno il server non venga prima rimosso quindi riaggiunto. L'indirizzo mittente non può essere uguale all'indirizzo cluster, server o NFA.
Quando si utilizzano i metodi di inoltro nat o cbr, definire un indirizzo di ritorno per le comunicazioni tra Load Balancer e i server di backend. Il numero di connessioni che Load Balancer può mantenere attive con il server di backend è limitato dal numero di indirizzi di ritorno definiti. Load Balancer utilizza porte che si basano solo sull'indirizzo di ritorno, non sulla combinazione di indirizzo di ritorno e server. Quando tutte le porte disponibili sono in uso, connessioni aggiuntive non riescono. In un ambiente occupato, utilizzare indirizzi di ritorno per evitare una diminuzione di porte disponibili.
L'indirizzo del router al server remoto. Se questo è un server collegato in locale, immettere l'indirizzo del server, a meno che questo non si trovi sulla stessa macchina di Load Balancer. In tal caso, continuare a utilizzare l'indirizzo reale del router.
Il componente Dispatcher consente di eseguire l'instradamento basato sul contenuto per HTTP (utilizzando la regola di tipo "contenuto") e HTTPS (utilizzando l'affinità ID di sessione SSL) senza la necessità di utilizzare Caching Proxy. Per il traffico HTTP e HTTPS, il metodo di inoltro cbr del componente Dispatcher può offrire un instradamento basato sul contenuto più rapido rispetto a quello offerto dal componente CBR, che richiede Caching Proxy.
Per HTTP: la selezione del server per l'Instradamento basato sul contenuto di Dispatcher è basata sui contenuti di un'intestazione URL o HTTP. La configurazione avviene utilizzando la regola di tipo "contenuto". Quando si configura la regola contenuto, specificare il "modello" della stringa di ricerca e un insieme di server per la regola. Durante l'elaborazione di una nuova richiesta in entrata, questa regola confronta la stringa specificata con l'URL del client o con l'intestazione HTTP specificata nella richiesta client.
Se il Dispatcher trova la stringa nella richiesta client, inoltra la richiesta a uno dei server nella regola. Il Dispatcher trasmette quindi i dati della risposta dal server al client (metodo di inoltro "cbr").
Se il Dispatcher non trova la stringa nella richiesta client, non seleziona alcun server dall'insieme dei server nella regola.
Per HTTPS (SSL): l'instradamento basato sul contenuto (cbr) del Dispatcher bilancia il carico in base al campo sessione ID SSL della richiesta client. Con SSL, una richiesta client contiene l'ID sessione SSL di una sessione precedente e i server mantengono una memoria cache delle connessioni SSL precedenti. L'affinità di sessione ID SSL del Dispatcher consente al client e al server di stabilire una nuova connessione utilizzando i parametri di sicurezza della precedente connessione al server. Eliminando la rinegoziazione dei parametri di sicurezza SSL, come le chiavi condivise e gli algoritmi di codifica, i server salvano i cicli della CPU e il client riceve una risposta più velocemente. Per abilitare l'affinità ID di sessione SSL: il tipo protocol specificato per la porta deve essere SSL e la porta stickytime deve essere impostata su un valore diverso da zero. Quando il valore di stickytime viene superato, il client potrebbe essere inviato a un server diverso dal precedente.
Saranno necessari tre indirizzi IP per la macchina Dispatcher - indirizzo nfa, cluster e mittente. Per implementare Instradamento basato sul contenuto di Dispatcher (vedere anche Operazioni di esempio per configurare i metodi di inoltro nat o cbr del Dispatcher):
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern pattern
Dove pattern specifica il modello da utilizzare per il tipo di regola content. Per ulteriori informazioni sul tipo di regola content, vedere Utilizzo delle regole basate sul contenuto delle richieste. Per ulteriori informazioni sulle espressioni valide per pattern, vedere Appendice B. Sintassi della regola di contenuto (modello).
Saranno necessari almeno tre indirizzi IP per la macchina Dispatcher. Per la Figura 12, le operazioni riportate di seguito sono indispensabili per configurare al minimo i metodi di inoltro nat o cbr del Dispatcher:
1.Avviare l'executor
dscontrol executor start
2.Definire il gateway client
dscontrol executor set clientgateway 1.2.3.5
NOTA: se la sottorete non dispone di un router locale, è necessario
configurare una macchina per eseguire l'inoltro IP e utilizzarla come
clientgateway. Consultare la documentazione del sistema operativo
per determinare come attivare l'inoltro IP.
3.Definire l'indirizzo cluster
dscontrol cluster add 1.2.3.44
4.Configurare l'indirizzo cluster
dscontrol executor configure 1.2.3.44
5.Definire la porta con un metodo nat o cbr
dscontrol port add 1.2.3.44:80 method nat
o
dscontrol port add 1.2.3.44:80 method cbr protocol http
6.Configurare un indirizzo mittente alias su Load Balancer (utilizzando la scheda ethernet 0)
NOTA: su sistemi Linux, non è necessario creare un alias per l'indirizzo di restituzione se si utilizza
l'inoltro nat su una macchina posizionata.
dscontrol executor configure 10.10.10.99
o utilizzare il comando ifconfig (solo per Linux o UNIX):
AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0
HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up
Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up
Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up
7.Definire i server backend
dscontrol server add 1.2.3.4:80:192.10.10.10
router 10.10.10.6 returnaddress 10.10.10.99
Il gateway client (1.2.3.5) è l'indirizzo router 1 tra Load Balancer e il client. Il router (10.10.10.6) è l'indirizzo router 2 tra Load Balancer e il server backend. In caso di dubbi sull'indirizzo clientgateway o router 2, è possibile utilizzare un programma denominato traceroute con l'indirizzo client (o server) per determinare l'indirizzo router. La sintassi esatta di questo programma differisce in base al sistema operativo utilizzato. È preferibile consultare la documentazione del sistema operativo per ulteriori informazioni circa questo programma.
Se il server si trova sulla stessa rete di Load Balancer (ossia, non vengono restituiti router mediante traceroute), specificare l'indirizzo server come indirizzo router. Tuttavia, se il server si trova sulla stessa macchina di Load Balancer, nel campo del router va immesso l'indirizzo del router e non l'indirizzo del server. L'indirizzo router è l'indirizzo utilizzato nel comando "server add" sulla macchina Load Balancer al punto 7.
Con la suddivisione in partizioni del server, è possibile distinguere ulteriormente tra URL particolari e relative applicazioni specifiche. Ad esempio, un server Web può supportare pagine JSP, pagine HTML, file GIF, richieste database e così via. Load Balancer consente ora di suddividere in partizioni un server specifico di una porta o di un cluster in più server logici. In questo modo, l'utente può fornire informazioni su uno specifico servizio su una macchina per rilevare se un motore servlet o una richiesta database è in esecuzione più velocemente o non lo è affatto.
La suddivisione in partizioni del server consente a Load Balancer di individuare, ad esempio, se il servizio HTML sta servendo le pagine velocemente ma la connessione al database è interrotta. Ciò consente di distribuire il carico in base a un carico di lavoro differenziando i diversi servizi, piuttosto che calcolare solo i pesi dei vari server.
La suddivisione in partizioni del server può essere utile se utilizzata insieme agli advisor HTTP e HTTPS. Ad esempio, con un server HTML che gestisce pagine HTML, GIF e JSP, se si definisce una volta (mediante aggiunta) il server nella porta 80, si riceve solo un valore di carico per l'intero server HTTP. Ciò può essere fuorviante in quanto è possibile che il servizio GIF non sia operativo sul server. Il Dispatcher continua a inoltrare pagine GIF al server ma il client riscontra un timeout o un errore.
Se si definisce il server tre volte (ad esempio, ServerHTML, ServerGIF, ServerJSP) nella porta e si definisce il parametro advisorrequest del server con una stringa differente per ciascun server logico, è possibile eseguire una query relativa allo stato di uno specifico servizio sul server. ServerHTML, ServerGIF e ServerJSP rappresentano tre server logici che sono stati suddivisi in partizioni da un unico server fisico. Per ServerJSP, è possibile definire la stringa advisorrequest per eseguire una query relativa al servizio sulla macchina che gestisce le pagine JSP. Per ServerGIF, è possibile definire la stringa advisorrequest per eseguire la query relativa al servizio GIF. Infine, per ServerHTML, si definisce la stringa advisorrequest per eseguire una query relativa al servizio HTML. In questo modo, se il client non riceve risposta da advisorrequest alla query relativa al servizio GIF, il Dispatcher contrassegnerà il server logico (ServerGIF) come inattivo, mentre gli altri due potrebbero essere attivi. Il Dispatcher non inoltra altre pagine GIF al server fisico ma può ancora inviare richieste JSP e HTML al server.
Per ulteriori informazioni sul parametro advisorrequest, vedere Configurazione dell'advisor HTTP o HTTPS utilizzando l'opzione richiesta/risposta (URL).
All'interno della configurazione del Dispatcher, è possibile rappresentare un server fisico o un server logico utilizzando la gerarchia cluster:port:server. Il server può essere un indirizzo IP univoco della macchina (server fisico) espresso come nome simbolico o in formato indirizzo IP. Altrimenti, se si definisce il server per rappresentare un server suddiviso in partizioni, è necessario specificare un indirizzo server risolvibile per il server fisico sul parametro address del comando dscontrol server add. Consultare dscontrol server -- configura i server per ulteriori informazioni.
Segue un esempio di suddivisione in partizioni di server fisici in server logici, per gestire differenti tipi di richieste.
Cluster: 1.1.1.1
Port: 80
Server: A (IP address 1.1.1.2)
HTML server
Server: B (IP address 1.1.1.2)
GIF server
Server: C (IP address 1.1.1.3)
HTML server
Server: D (IP address 1.1.1.3)
JSP server
Server: E (IP address 1.1.1.4)
GIF server
Server: F (IP address 1.1.1.4)
JSP server
Rule1: /*.htm
Server: A
Server: C
Rule2: /*.jsp
Server: D
Server: F
Rule3: /*.gif
Server: B
Server: E
In questo esempio, il server 1.1.1.2 è suddiviso in 2 server logici: "A" (che gestisce le richieste HTML) e "B" (che gestisce le richieste GIF). Il server 1.1.1.3 è suddiviso in 2 server logici: "C" (che gestisce le richieste HTML) e "D" (che gestisce le richieste JSP). Il server 1.1.1.4 è suddiviso in 2 server logici: "E" (che gestisce le richieste GIF) e "F" (che gestisce le richieste JSP).
La funzione di disponibilità elevata implica l'uso di una seconda macchina Dispatcher. La prima macchina Dispatcher esegue il bilanciamento del carico per tutto il traffico client, come in una configurazione a un solo Dispatcher. La seconda macchina Dispatcher controlla lo "stato" della prima e assume il controllo delle attività di bilanciamento del carico se rileva un malfunzionamento sulla prima macchina Dispatcher.
A ciascuna delle due macchine viene assegnato un ruolo specifico, ossia primary (principale) o backup (secondario). La macchina principale invia continuamente i dati di connessione alla macchina secondaria. Mentre la macchina principale è attiva (ed esegue il bilanciamento del carico), la macchina secondaria si trova in standby, aggiornata di continuo e pronta ad assumere il controllo, se necessario.
Le sessioni di comunicazione tra le due macchine vengono denominate heartbeat. Gli heartbeat consentono a ciascuna macchina di controllare lo stato dell'altra.
Se la macchina secondaria rileva un malfunzionamento della macchina attiva, assumerà il controllo e inizierà a eseguire il bilanciamento del carico. A quel punto, gli stati delle due macchine si invertono: la macchina secondaria diventa attiva mentre la macchina principale passa in standby.
nella configurazione ad alta disponibilità, le macchine principale e di backup devono essere sulla stessa sottorete con configurazione identica.
Per informazioni sulla configurazione della disponibilità elevata, vedere Disponibilità elevata.
La funzione di disponibilità elevata reciproca implica l'uso di due macchine Dispatcher. Entrambe le macchine eseguono attivamente il bilanciamento del carico del traffico client e fungono da backup l'una per l'altra. In una configurazione a disponibilità elevata di tipo semplice, solo una macchina esegue il bilanciamento del carico. In una configurazione a disponibilità elevata reciproca, entrambe le macchine eseguono il bilanciamento del carico di una parte del traffico client.
Per la disponibilità elevata reciproca, il traffico client viene assegnato a ciascuna macchina Dispatcher in base all'indirizzo cluster. Ciascun cluster può essere configurato con l'NFA (nonforwarding address) del Dispatcher principale. La macchia Dispatcher principale normalmente esegue il bilanciamento del carico per quel cluster. Nel caso di un malfunzionamento, l'altra macchina eseguirà il bilanciamento del carico sia per il proprio cluster che per il cluster del Dispatcher malfunzionante.
Per un'illustrazione di una configurazione a disponibilità elevata reciproca con il "gruppo di cluster A" e il "gruppo di cluster B" condivisi, vedere Figura 14. Ciascun Dispatcher può attivamente instradare pacchetti per il proprio cluster principale. Se uno dei Dispatcher ha riscontrato un errore e non può più inviare attivamente pacchetti per il proprio cluster principale, l'altro Dispatcher può assumere il controllo e instradare pacchetti per il proprio cluster secondario.
Per informazioni sulla configurazione della disponibilità elevata semplice e reciproca, vedere Disponibilità elevata.