Pianificazione di Dispatcher

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:

Nota:
Per le versioni precedenti, quando il prodotto era noto come Network Dispatcher, il nome del comando per il controllo del Dispatcher era ndcontrol. Il nome del comando per il controllo del Dispatcher è ora dscontrol.

Considerazioni sulla pianificazione

Dispatcher consiste delle seguenti funzioni:

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.

Metodi di inoltro

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).

Instradamento a livello MAC del Dispatcher (metodo di inoltro mac)

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.

NAT/NAPT del Dispatcher (metodo di inoltro nat)

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):

Instradamento basato sul contenuto di Dispatcher (metodo di inoltro cbr)

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.

Nota:
la regola contenuto viene configurata nella stessa maniera, sia per il componente Dispatcher che per il componente CBR. Il Dispatcher può utilizzare la regola contenuto per il traffico HTTP. Tuttavia, il componente CBR può utilizzare la regola contenuto sia per il traffico HTTP che HTTPS (SSL).

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):

Nota:
la funzione di disponibilità elevata per la replica del record delle connessioni (che garantisce che una connessione del client non venga interrotta quando una macchina Dispatcher secondaria assume il controllo al posto della macchina principale) non è supportata con l'instradamento basato sul contenuto (cbr) del Dispatcher.

Operazioni di esempio per configurare i metodi di inoltro nat o cbr del Dispatcher

Figura 12. Esempio d'uso dei metodi di inoltro nat o cbr del Dispatcher
Configurazione per l'utilizzo dell'inoltro nat o cbr di Dispatcher

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.

Suddivisione in partizioni dei server: server logici configurati su un server fisico (indirizzo IP)

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.

Suddivisione in partizioni del server mediante advisor HTTP o HTTPS

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).

Esempio di configurazione di un server fisico in server logici

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).

Disponibilità elevata

Disponibilità elevata di tipo semplice

Figura 13. Esempio di un Dispatcher che utilizza la disponibilità elevata di tipo semplice
Dispatcher che utilizza una configurazione a disponibilità elevata di tipo semplice

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 a disponibilità elevata, sia la macchina principale che quella secondaria si trovano sulla stessa sottorete con configurazione identica.

Per informazioni sulla configurazione della disponibilità elevata, vedere Disponibilità elevata.

Disponibilità elevata reciproca

Figura 14. Esempio di un Dispatcher che utilizza la disponibilità elevata reciproca
Dispatcher che utilizza una configurazione a disponibilità elevata reciproca

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.

Nota:
in entrambe le macchine, la configurazione dei gruppi di cluster condivisi deve essere identica. Ossia, le porte utilizzate e i server in ciascuna porta devono essere identici nelle due configurazioni.

Per informazioni sulla configurazione della disponibilità elevata semplice e reciproca, vedere Disponibilità elevata.