Pianificazione di Content Based Routing

Questo capitolo descrive i fattori che il responsabile della pianificazione di rete deve considerare prima di installare e configurare il componente CBR con Caching Proxy.

Questo capitolo include le seguenti sezioni:

Considerazioni sulla pianificazione

Il componente CBR consente di bilanciare il carico del traffico HTTP e SSL utilizzando Caching Proxy per inoltrare le richieste via proxy. Il componente CBR consente di bilanciare il carico dei server configurati con un apposito file di configurazione CBR tramite i comandi cbrcontrol.

Nota:
Il contenuto CBR (Content Based Routing) non è disponibile sulle piattaforme che eseguono una JVM a 64 bit, ad eccezione di HP-UX ia64. Su HP-UX ia64, il componente CBR viene eseguito come applicazione 32 bit. È possibile utilizzare il metodo di inoltro CBR del componente Dispatcher di Load Balancer per fornire l'instradamento basato sul contenuto senza l'utilizzo di Caching Proxy. Per ulteriori informazioni, consultare Instradamento basato sul contenuto di Dispatcher (metodo di inoltro cbr).

CBR è molto simile a Dispatcher nella sua struttura. CBR è composto dalle seguenti funzioni:

Le tre funzioni chiave di CBR (executor, gestore e advisor) interagiscono per bilanciare e distribuire le richieste in entrata tra i server. Oltre a bilanciare il carico delle richieste, l'executor monitora il numero di nuove connessioni e il numero delle connessioni attive e fornisce tali informazioni al gestore.

Bilanciamento del carico di richieste per tipi diversi di contenuto

Il componente CBR consente di specificare un gruppo di server che gestirà una richiesta in base all'espressione regolare corrispondente al contenuto della richiesta client. CBR consente di suddividere il proprio sito in partizioni in modo che gruppi di server diversi possano provvedere a servizi di applicazioni o contenuti diversi. Questa partizione è trasparente per i client che accedono al proprio sito.

Suddivisione del contenuto del sito per ottimizzare i tempi di risposta

Una possibile soluzione di suddivisione del sito sarebbe assegnare a un gruppo di server la gestione delle richieste cgi e a un altro gruppo di server la gestione di tutte le altre richieste. Questo impedirebbe agli script cgi che svolgono calcoli complessi di rallentare i server in caso di normale traffico HTML con conseguente ottimizzazione complessiva dei tempi di risposta ai client. Questo schema consentirebbe anche di assegnare stazioni di lavoro più potenti alle richieste normali. Ciò migliorerebbe i tempi di risposta ai client senza dover affrontare le spese di un aggiornamento di tutti i server. Inoltre, questo consentirebbe di assegnare stazioni di lavoro più potenti alle richieste cgi.

Un'altra soluzione di suddivisione del sito potrebbe essere quella di indirizzare a un gruppo di server i client che accedono a pagine che prevedono la registrazione e a un altro gruppo di server tutte le altre richieste. Questo impedirebbe ai browser che accedono fortuitamente al sito di impegnare risorse che potrebbero essere altrimenti utilizzate dai client che intendono invece registrarsi. Inoltre, consentirebbe di dedicare stazioni di lavoro più potenti ai client che hanno completato la registrazione.

Naturalmente è possibile combinare i metodi sopra descritti per ottenere una flessibilità ancora maggiore e un servizio migliore.

Backup del contenuto del server Web

Poiché CBR consente di specificare più server per ciascun tipo di richiesta, il carico delle richieste può essere bilanciato per ottimizzare i tempi di risposta ai client. L'assegnazione di ciascun tipo di contenuto a più server protegge il sito in caso di malfunzionamento di una stazione di lavoro o di un server. CBR riconosce il malfunzionamento e continua a bilanciare il carico delle richieste client sugli altri server del gruppo.

Uso di più processi Caching Proxy per migliorare l'utilizzo della CPU

Caching Proxy comunica con un processo CBR tramite la relativa interfaccia del plug-in. Affinché ciò funzioni, CBR deve essere eseguito sulla macchina locale. Poiché questi due processi sono distinti, più istanze di Caching Proxy possono essere in esecuzione e funzionanti con un'unica istanza di CBR. Questa configurazione potrebbe consentire di isolare gli indirizzi o le funzionalità tra i Caching Proxy oppure di migliorare l'uso delle risorse della macchina grazie a più Caching Proxy che gestiscono il traffico dei client. Le istanze proxy possono restare in ascolto su porte diverse o essere associati a indirizzi IP univoci sulla stessa porta, a seconda di ciò che meglio soddisfa i requisiti di traffico.

Uso del bilanciamento del carico basato sulle regole con CBR

CBR con Caching Proxy esamina le richieste HTTP utilizzando tipi di regole specifiche. Quando in esecuzione, Caching Proxy accetta le richieste client e interroga il componente CBR per individuare il server più adatto. Sulla base di questa interrogazione, CBR confronta la richiesta a fronte di un gruppo di regole in base a un ordine di priorità. Quando individua la regola corrispondente, sceglie un server adatto da un gruppo precedentemente configurato. Infine, CBR notifica a Caching Proxy il server proxy attraverso il quale dovrà essere inviata la richiesta.

Una volta definito un cluster da sottoporre al bilanciamento del carico, è necessario accertarsi che tutte le richieste indirizzate a quel cluster abbiano una regola che consenta di scegliere un server. Se non viene trovata una regola che corrisponda a una determinata richiesta, il client riceve una pagina di errore da Caching Proxy. Il modo più facile per garantire che tutte le richieste corrispondano a una regola è creare una regola del tipo "sempre true" e assegnarle una priorità molto elevata. Verificare che i server utilizzati da questa regola possano gestire tutte le richieste che non sono gestite esplicitamente dalle regole con priorità inferiore. (Nota: le regole con priorità inferiore vengono valutate per prime.)

Per ulteriori informazioni, vedere Configurazione del bilanciamento del carico in base alle regole.

Bilanciamento del carico tra connessioni protette (SSL)

CBR con Caching Proxy può ricevere sia la trasmissione SSL dal client al proxy (lato client-proxy) sia supportare la trasmissione dal proxy a un server SSL (lato proxy-server). In una configurazione CBR, la definizione su un server di una porta SSL dedicata a ricevere le richieste SSL provenienti dal client, offre la possibilità di gestire un sito totalmente protetto e di utilizzare CBR per bilanciare il carico tra i server (SSL) protetti.

Oltre ad altre modifiche al file ibmproxy.conf per CBR, è necessario aggiungere un'altra istruzione di configurazione al file ibmproxy.conf affinché Caching Proxy abiliti la codifica SSL sul lato proxy-server. Il formato deve essere:

proxy modello_uri modello_url indirizzo

dove modello_uri è un modello a cui corrispondere (ad esempio: /secure/*), modello_url è un URL di sostituzione (ad esempio: https://clusterA/secure/*) e indirizzo è l'indirizzo cluster (ad esempio: clusterA).

Bilanciamento del carico client-proxy in SSL e proxy-server in HTTP

CBR con Caching Proxy può anche ricevere trasmissioni SSL dai client e decodificare le richieste SSL prima di inviarle a un server HTTP attraverso un proxy. Affinché CBR supporti la trasmissione client-proxy in SSL e proxy-server in HTTP, è prevista una parola chiave facoltativa mapport sul comando del server cbrcontrol. Utilizzare questa parola chiave quando si desidera indicare che la porta sul server è diversa dalla porta dove arrivano le richieste in entrata provenienti dal client. Di seguito viene riportato un esempio di aggiunta di una porta tramite la parola chiave mapport, dove la porta del client è 443 (SSL) e la porta del server è 80 (HTTP):

cbrcontrol server add cluster:443 mapport 80

Il numero di porta di mapport può essere un qualsiasi numero intero positivo. Il valore predefinito è il numero della porta dove arrivano le richieste in entrata provenienti dal client.

Poiché CBR deve essere in grado di fornire informazioni su una richiesta HTTP per un server configurato sulla porta 443 (SSL), viene fornito un advisor speciale ssl2http . Questo advisor viene avviato sulla porta 443 (la porta delle richieste in entrata provenienti dal client) e fornisce informazioni sui server configurati su tale porta. Se vi sono due cluster configurati e per ciascun cluster la porta è 443 e i server sono configurati con un valore mapport diverso, un'unica istanza dell'advisor può aprire di conseguenza la porta appropriata. Di seguito viene riportato un esempio di questa configurazione:

Executor
    Cluster1
       Port:443
           Server1 mapport 80
           Server2 mapport 8080
    Cluster2
       Port:443
           Server3 mapport 80
           Server4 mapport 8080
    Manager
      Advisor ssl2http 443