Funzioni avanzate di Dispatcher, CBR e Site Selector

Questo capitolo descrive come come configurare i parametri per il bilanciamento del carico e come impostare le funzioni avanzate di Load Balancer.

Nota:
se durante la lettura di questo capitolo, non si sta utilizzando il componente Dispatcher, sostituire "dscontrol" con quanto segue:
Tabella 11. Attività di configurazione avanzate di Load Balancer
Attività Descrizione Informazioni correlate
Posizionare Load Balancer su una macchina che esegue il bilanciamento del carico Impostare una macchina Load Balancer posizionata. Utilizzo dei server posizionati
Configurare la disponibilità elevata semplice e reciproca Impostare una seconda macchina Dispatcher che funzioni da backup. Disponibilità elevata
Configurare il bilanciamento del carico in base alle regole Definire le condizioni in base alle quali utilizzare un sottoinsieme di server. Configurazione del bilanciamento del carico in base alle regole
Utilizzare la funzione "ignora affinità di porta" per permettere a un server di ignorare la funzione di aderenza alla porta Consente a un server di ignorare l'impostazione stickytime su questa porta. ignora affinità di porta
Utilizzare la funzione di aderenza (affinità) per configurare la porta di un cluster e renderla aderente Consente di indirizzare le richieste dei client a uno stesso server. Funzionamento della funzione di affinità di Load Balancer
Utilizzare l'affinità multiporta per espandere la funzione di aderenza (affinità) tra le porte Fa in modo che le richieste dei client, ricevute da diverse porte, vengano indirizzate allo stesso server. Affinità multiporta
Utilizzare la funzione maschera indirizzo affinità per indicare un indirizzo di sottorete IP comune Permette che le richieste dei client, ricevute dalla stessa sottorete, vengano indirizzate sullo stesso server. Maschera indirizzo affinità (stickymask)
Utilizzare l'affinità cookie attiva per bilanciare il carico dei server di CBR L'opzione di una regola che consente a una sessione di mantenere l'affinità per un server particolare. Affinità cookie attivo
Utilizzare l'affinità cookie passivo per bilanciare il carico dei server per l'instradamento in base al contenuto di Dispatcher e per il componente CBR L'opzione di una regola che consente a una sessione di mantenere l'affinità per un server particolare in base al valore e al nome cookie. Affinità cookie passivo
Utilizzare l'affinità URI per bilanciare il carico tra i server Caching Proxy con contenuto univoco da memorizzare su ogni singolo server L''opzione di una regola che consente a una sessione di mantenere l'affinità per un server particolare in base all'URI. Affinità URI
Configurare il supporto di Dispatcher per una rete geografica Impostare un Dispatcher remoto per bilanciare il carico su una rete geografica (WAN, wide area network). Oppure, bilanciare il carico attraverso una rete geografica (WAN, Wide Area Network), senza un Dispatcher remoto, utilizzando una piattaforma server che supporta GRE. Configurazione del supporto di Dispatcher per una rete geografica
Utilizzare un collegamento esplicito Impedisce di ignorare Dispatcher nei collegamenti. Utilizzo di un collegamento esplicito
Utilizzare una rete privata Configurare Dispatcher in modo da bilanciare il carico dei server su una rete privata. Utilizzo di una configurazione di rete privata
Utilizzare cluster jolly per combinare le configurazioni di server comuni Gli indirizzi che non sono esplicitamente configurati utilizzeranno i cluster jolly per bilanciare il traffico. Utilizzo del cluster jolly per combinare le configurazioni di server
Utilizzare il cluster jolly per bilanciare il carico dei firewall Tutto il traffico verrà bilanciato sui firewall. Utilizzo di cluster jolly per bilanciare il carico dei firewall
Utilizzare il cluster jolly con Caching Proxy come proxy trasparente Consente di utilizzare Dispatcher per attivare un proxy trasparente. Utilizzo del cluster jolly con Caching Proxy per proxy trasparente
Utilizzare la porta jolly per indirizzare il traffico non configurato sulle porte Gestisce il traffico che non è configurato per nessuna porta in particolare. Utilizzo della porta jolly per indirizzare il traffico per una porta non configurata
Utilizzare il rilevamento attacchi di tipo "Denial of Service" per notificare agli amministratori (con un avviso) eventuali attacchi Dispatcher analizza le richieste in entrata per una grande quantità di connessioni TCP aperte a metà sui server. Rilevamento attacco di tipo Denial of service
Utilizzare i file binari di log per analizzare le statistiche dei server Permette la memorizzazione e il richiamo delle informazioni relative ai server dai file binari. Uso della registrazione binaria per analizzare le statistiche dei server
Utilizzare una configurazione client posizionato Consente al Load Balancer di trovarsi sulla stessa macchina del client Utilizzo di un client posizionato

Utilizzo dei server posizionati

Load Balancer può risiedere sulla stessa macchina di un server per il quale sta bilanciando il carico delle richieste. Questa operazione viene comunemente denominata come posizionamento di un server. È applicabile esclusivamente ai componenti Dispatcher e Site Selector. Il posizionamento è supportato anche per CBR, ma solo se si utilizzano dei server web Caching Proxy specifici del collegamento.

Nota:
un server posizionato si contende le risorse con Load Balancer nei momenti di traffico elevato. Tuttavia, anche quando non ci sono macchine sovraccariche, l'uso di un server posizionato riduce il numero totale delle macchine necessarie per configurare un sito con bilanciamento del carico.

Per il componente Dispatcher

Linux: per configurare contemporaneamente il posizionamento e l'alta disponibilità (HA, high availability), mentre il componente Dispatcher è in esecuzione con il metodo di inoltro mac, consultare Alternative per l'aggiunta dell'alias loopback Linux quando si utilizza il metodo di inoltro mac di Load Balancer.

Solaris: esiste un limite secondo il quale non è possibile configurare gli advisor WAN se Dispatcher del punto di ingresso è posizionato. Consultare Utilizzo di advisor remoti con il supporto rete geografica di Dispatcher.

Windows: il posizionamento non è più disponibile quando si utilizza il metodo di inoltro MAC del dispatcher.

Nelle release precedenti, era necessario specificare che l'indirizzo del server posizionato doveva essere uguale all'indirizzo NFA (nonforwarding address, indirizzo di non inoltro) nella configurazione. Tale restrizione è stata eliminata.

Per configurare un server da posizionare, il comando dscontrol server fornisce un'opzione chiamata collocated che può essere impostata su o no. Il valore predefinito è no. L'indirizzo del server deve essere un indirizzo IP valido di una scheda di interfaccia di rete sulla macchina. Il parametro collocated non dovrebbe essere impostato per i server posizionati mediante metodo di inoltro nat o cbr di Dispatcher.

È possibile configurare un server posizionato in uno dei seguenti modi:

Per il protocollo nat o per l'inoltro cbr di Dispatcher, è necessario configurare (alias) un indirizzo di adattatore non utilizzato su NFA. Il server dovrebbe essere configurato per essere in ascolto su questo indirizzo. Configurare il server utilizzando la seguente sintassi:

dscontrol server add cluster:port:new_alias address
new_alias router router_ip returnaddress
return_address

Una configurazione errata può causare errori di sistema, una mancata risposta del server, o entrambe le condizioni.

Configurazione del posizionamento del server mediante il metodo di inoltro nat di Dispatcher

Quando si configura un server posizionato mediante il metodo di inoltro nat del Dispatcher, il router specificato nel comando dscontrol server add deve essere un indirizzo reale del router e non un indirizzo IP del server.

Il supporto per il posizionamento, durante la configurazione del metodo di inoltro nat di Dispatcher, può essere applicato sui sistemi operativi riportati di seguito nel caso in cui le seguenti operazioni siano eseguite sulla macchina di Dispatcher:

Per il componente CBR

CBR supporta il posizionamento sulle piattaforme AIX, HP-UX, Linux e Solaris senza la necessità di alcuna configurazione aggiuntiva. Tuttavia, i server Web e il Caching Proxy utilizzati devono essere specifici del collegamento.

Per il componente Site Selector

Site Selector supporta il posizionamento sulle piattaforme AIX, HP-UX, Linux e Solaris senza la necessità di alcuna configurazione aggiuntiva.

Disponibilità elevata

La funzione Disponibilità elevata (configurabile tramite il comando dscontrol highavailability) è disponibile per il componente Dispatcher (ma non per i componenti CBR o Site Selector).

Per aumentare la disponibilità di Dispatcher, la funzione di Disponibilità elevata utilizza i seguenti meccanismi:

Nota:
per una descrizione di una configurazione di disponibilità elevata reciproca, dove due macchine Dispatcher che condividono due serie di cluster forniscono un backup reciproco, consultare Disponibilità elevata reciproca. La disponibilità elevata reciproca è simile alla disponibilità elevata ma si basa soprattutto su un indirizzo cluster anziché su una macchina Dispatcher completa. in entrambe le macchine, la configurazione dei gruppi di cluster condivisi deve essere identica.

Configurazione della disponibilità elevata

La sintassi completa per dscontrol highavailability è in dscontrol highavailability -- controlla la disponibilità elevata.

Per un quadro più completo delle attività riportate di seguito, vedere Configurazione della macchina Dispatcher.

  1. Creare dei file di script alias sulle due macchine Dispatcher. Consultare Utilizzo di script.
  2. Avviare il server su entrambe le macchine server Dispatcher.
  3. Avviare l'executor su entrambe le macchine.
  4. Verificare che l'NFA (nonforwarding address) di ciascuna macchina Dispatcher sia configurato e che sia un indirizzo IP valido per la sottorete di macchine Dispatcher.
  5. Aggiungere le informazioni heartbeat su entrambe le macchine:
    dscontrol highavailability heartbeat add sourceaddress destinationaddress
    Nota:
    sourceaddress e destinationaddress sono gli indirizzi IP (nomi DNS o indirizzi IP) delle macchine Dispatcher. I valori verranno riversati in ciascuna macchina. Ad esempio:
    Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8
    Backup  - highavailability heartbeat add 9.67.186.8 9.67.111.3
    Almeno una coppia di heartbeat deve avere gli NFA della coppia come indirizzo di origine e destinazione.

    Se possibile, è consigliabile che almeno una coppia di heartbeat venga inviata attraverso una sottorete separata rispetto al traffico regolare del cluster. Separando il traffico di heartbeat, è possibile evitare falsi takeover durante carichi di rete pesanti e migliorare i tempi di recupero dopo un failover.

    Impostare il numero di secondi che l'executor deve utilizzare come timeout per gli heartbeat di disponibilità elevata. Ad esempio:

    dscontrol executor set hatimeout 3

    Il valore predefinito è 2 secondi.

  6. Su entrambe le macchine, configurare un elenco di indirizzi IP che il Dispatcher deve poter raggiungere per offrire un servizio completo, utilizzando il comando reach add. Ad esempio:
    dscontrol highavailability reach add 9.67.125.18
    Le destinazioni finali sono consigliate ma non obbligatorie. Consultare Capacità di rilevamento di errori mediante heartbeat e la destinazione accessibile per ulteriori informazioni.
  7. Aggiungere le informazioni di backup su ciascuna macchina:
    Nota:
    selezionare una porta non utilizzata sulle macchine che abbia il valore di port. Il numero di porta immesso verrà utilizzato come chiave per garantire che l'host corretto riceva il package.
  8. Controllare lo stato di disponibilità elevata di ciascuna macchina:
    dscontrol highavailability status
    Ciascuna macchina deve avere il ruolo corretto (backup, principale o both), gli stati e gli stati secondari. La macchina principale deve essere attiva e sincronizzata; quella di backup dovrebbe essere in modalità standby e sincronizzata in breve tempo. Le strategie devono essere le stesse.
  9. Impostare le informazioni del cluster, della porta e del server su entrambe le macchine.
    Nota:
    Per una configurazione a disponibilità elevata reciproca (Figura 14), ad esempio, configurare il gruppo di cluster condivisi tra i due Dispatcher nel seguente modo:
    • Per Dispatcher 1, emettere:
      dscontrol cluster set clusterA primaryhost NFAdispatcher1
      dscontrol cluster set clusterB primaryhost NFAdispatcher2
    • Per Dispatcher 2, emettere:
      dscontrol cluster set clusterB primaryhost NFAdispatcher2
      dscontrol cluster set clusterA primaryhost NFAdispatcher1
  10. Avviare il gestore e gli advisor su entrambe le macchine.
Note:
  1. Per configurare una singola macchina Dispatcher per l'instradamento dei pacchetti senza un backup, non immettere alcun comando di alta disponibilità all'avvio.
  2. Per convertire due macchine Dispatcher configurate per l'alta disponibilità in una macchina in esecuzione autonoma, arrestare l'executor su una delle macchine, quindi eliminare le funzioni di alta disponibilità (heartbeat, accessibilità e backup) sull'altra.
  3. In entrambi i casi, è necessario creare un alias per la scheda interfaccia di rete con indirizzi cluster, come richiesto.
  4. Quando due macchine Dispatcher sono in esecuzione in una configurazione di disponibilità elevata e sono sincronizzate, si consiglia di inserire tutti i comandi dscontrol (per aggiornare la configurazione) prima sulla macchina in standby, poi su quella attiva.
  5. Se due macchine Dispatcher sono in esecuzione in una configurazione di disponibilità elevata, potrebbero verificarsi dei risultati imprevisti nel caso in cui si imposta uno dei parametri dell'executor, del cluster, della porta o del server (ad esempio, port stickytime) su valori diversi per le due macchine.
  6. Per la disponibilità elevata reciproca, considerare il caso in cui uno dei Dispatcher deve instradare attivamente i pacchetti per il cluster principale e controllare l'instradamento dei pacchetti per il cluster di backup. Verificare che questo non superi la velocità di trasmissione di questa macchina.
  7. Su sistemi Linux, quando si configura contemporaneamente la disponibilità elevata e il posizionamento utilizzando il metodo di inoltro della porta MAC del componente Dispatcher, consultare Alternative per l'aggiunta dell'alias loopback Linux quando si utilizza il metodo di inoltro mac di Load Balancer.
  8. Per suggerimenti su come risolvere i problemi legati alla configurazione HA (high availability) come:
    • Connessioni interrotte in seguito al takeover
    • Macchine partner che non vengono sincronizzate
    • Richieste dirette erroneamente alla macchina del partner di backup
    Consultare Problema: suggerimenti sulla configurazione dell'HA (high availability).

Capacità di rilevamento di errori mediante heartbeat e la destinazione accessibile

Oltre ai criteri fondamentali del rilevamento di errori (la perdita di connettività tra Dispatcher attivi e in standby rilevata tramite i messaggi heartbeat), esiste un altro meccanismo di rilevamento degli errori denominato criteri di accessibilità. Quando si configura il Dispatcher, è possibile fornire un elenco degli host che ciascun Dispatcher deve raggiungere per poter funzionare correttamente. I due partner della configurazione a disponibilità elevata sono continuamente in contatto tramite gli heartbeat e aggiornano reciprocamente il numero di destinazioni finali che sono communicate grado di sottoporre a ping. Se la macchina in standby sottopone a ping un numero di destinazioni finali superiore a quelli attivi, si verifica un failover.

Gli heartbeat vengono inviati dal Dispatcher attivo ed è previsto che vengano ricevuti dal Dispatcher in standby ogni mezzo secondo. Se il Dispatcher in standby non riceve alcun heartbeat entro 2 secondi, inizia un failover. Per consentire il takeover da un Dispatcher in standby, tutti gli heartbeat devono essere interrotti. In altre parole, se sono configurate due coppie di heartbeat, entrambi gli heartbeat devono essere interrotti. Per stabilizzare un ambiente ad alta disponibilità e per evitare il failover, è consigliabile aggiungere più di una coppia di heartbeat.

Per le destinazioni finali, scegliere almeno un host per ogni sottorete utilizzata dalla macchina Dispatcher. Gli host possono essere router, server IP e altri tipi di host. L'accessibilità degli host si ottiene tramite l'advisor reach, che esegue il ping sull'host. Il failover si verifica se si interrompe la trasmissione degli heartbeat oppure se i criteri di accessibilità vengono soddisfatti in misura maggiore dal Dispatcher in standby rispetto al Dispatcher principale. Per prendere una decisione in base alle informazioni disponibili, il Dispatcher attivo invia regolarmente al Dispatcher in standby informazioni sulle sue capacità di accessibilità. Il Dispatcher in standby, quindi, confronta tali capacità con le proprie e decide se deve avvenire la commutazione.

Nota:
quando si configura la destinazione accessibile, è necessario avviare anche l'advisor reach. L'advisor reach viene avviato automaticamente all'avvio della funzione gestore. Per ulteriori informazioni sull'advisor reach, vedere pagina ***.

Strategia di ripristino

Sono configurate due macchine Dispatcher: la macchina principale e una seconda macchina, chiamata di backup. All'avvio, la macchina principale invia tutti i dati di connessione alla macchina di backup fino a quando quella macchina non è sincronizzata. La macchina principale diventa attiva, ovvero, inizia il bilanciamento del carico. La macchina di backup, nel frattempo, controlla lo stato della macchina principale e si trova in stato di standby.

Se la macchina di backup rileva qualche errore nella macchina principale, esegue un takeover delle funzioni di bilanciamento del carico della macchina principale e diventa la macchina attiva. Dopo che la macchina principale è diventata di nuovo operativa, le macchine rispondono in base al modo in cui la strategia di ripristino è stata configurata dall'utente. Esistono due tipi di strategie:

Automatica
La macchina principale riprende a instradare i pacchetti nel momento in cui diventa di nuovo operativa.
Manuale
La macchina di backup continua a instradare i pacchetti anche dopo che la macchina principale è diventata operativa. È necessario un intervento manuale per riportare la macchina principale allo stato attivo e ripristinare la macchina di backup sullo stato di standby.

Il parametro della strategia deve essere impostato allo stesso modo su entrambe le macchine.

La strategia di ripristino manuale consente di forzare l'instradamento dei package su una macchina particolare usando il comando takeover. Il ripristino manuale è utile per eseguire la manutenzione sull'altra macchina. La strategia di ripristino automatico è utile in una configurazione senza operatore.

Per una configurazione di disponibilità elevata reciproca, non esiste errore di cluster. Se si verifica un problema con una macchina, che riguarda anche un solo cluster, l'altra macchina prenderà il controllo di entrambi i cluster.

Nota:
durante le situazioni di takeover, alcuni aggiornamenti delle connessioni potrebbero andare persi. Ciò potrebbe determinare l'interruzione di connessioni di lunga durata esistenti (come ad esempio, telnet) in caso di accesso alla fine del takeover.

Utilizzo di script

Affinché il Dispatcher indirizzi i pacchetti, è necessario creare un alias per ciascun indirizzo cluster sull'unità di interfaccia di rete.

Per informazioni sull'alias della scheda di rete, fare riferimento a Fase 5. Creazione dell'alias della scheda di interfaccia di rete (NIC).

Poiché le macchine Dispatcher cambiano di stato quando viene rilevato un errore, i comandi indicati in precedenza devono essere emessi automaticamente. Per far ciò, Dispatcher eseguirà gli script creati dall'utente. Gli script di esempio si trovano nella seguente directory:

Tali script devono essere spostati nella seguente directory per poter essere eseguiti:

Gli script vengono eseguiti automaticamente solo se dsserver è in esecuzione.

Note:
  1. Per una configurazione di disponibilità elevata reciproca, ogni script "go" verrà richiamato dal Dispatcher con un parametro che identifica l'indirizzo del Dispatcher principale. Lo script deve interrogare questo parametro ed eseguire i comandi executor configure per quegli indirizzi cluster associati al Dispatcher principale.
  2. per poter configurare la disponibilità elevata per il metodo di inoltro nat del Dispatcher, è necessario aggiungere gli indirizzi di ritorno ai file di script.

È possibile utilizzare i seguenti script di esempio:

goActive
Lo script goActive viene eseguito quando un Dispatcher è in stato attivo e inizia l'instradamento dei pacchetti.
goStandby
Lo script goStandby viene eseguito quando un Dispatcher va in stato di standby durante il controllo della condizione della macchina attiva, ma non durante l'instradamento di pacchetti.
goInOp
Lo script goInOp viene eseguito quando un executor di Dispatcher viene arrestato.
goIdle
Lo script goIdle viene eseguito quando un Dispatcher è in stato inattivo e inizia l'instradamento dei pacchetti. Ciò avviene quando le funzioni di disponibilità elevata non sono state aggiunte, come ad esempio in una configurazione autonoma. Avviene anche in una configurazione di disponibilità elevata prima che le funzioni di disponibilità elevata vengano aggiunte o dopo che sono state rimosse.
highavailChange
Lo script highavailChange viene eseguito ogni volta che lo stato di disponibilità elevata viene modificato nel Dispatcher, come quando viene richiamato uno degli script "go". L'unico parametro inviato a questo script è il nome dello script "go" eseguito da Dispatcher. È possibile creare questo script per utilizzare le informazioni sui cambiamenti di stato, ad esempio, per avvisare un amministratore o semplicemente per registrare un evento.

Sui sistemi Windows: durante la configurazione, se Site Selector bilancia il carico di due macchine Dispatcher, operative in un ambiente a disponibilità elevata, sarà necessario aggiungere un alias sullo stack Microsoft per i Metric Server. Questo alias va aggiunto allo script goActive. Ad esempio:

call netsh interface ip add address
"Local Area Connection"
  addr=9.37.51.28 mask=255.255.240.0

Negli script goStandby e goInOp, l'alias dovrà essere rimosso. Ad esempio:

call netsh interface ip delete address
"Local Area Connection"
  addr=9.37.51.28

Se la macchina dispone di più NIC, controllare prima quale interfaccia utilizzare emettendo il seguente comando sul prompt dei comandi: netsh interface ip show address. Questo comando restituirà un elenco delle interfacce attualmente configurate numerando ciascuna "Connessione alla rete locale (LAN)" (ad esempio, "Connessione alla rete locale (LAN) 2"); in questo modo, è possibile stabilire quale utilizzare.

Su sistemi Linux per S/390: Dispatcher emette un ARP gratuito per spostare gli indirizzi IP da un Dispatcher all'altro. Questo meccanismo è, quindi, legato al tipo di rete sottostante. Quando si esegue Linux per S/390, Dispatcher può eseguire, in modalità nativa, takeover in disponibilità elevata (compresi gli spostamenti dell'indirizzo IP) solo su quelle interfacce che possono emettere un ARP gratuito e configurare l'indirizzo sull'interfaccia locale. Questo meccanismo non funzionerà correttamente sulle interfacce point-to-point, come ad esempio IUCV e CTC, e non funzionerà correttamente in alcune configurazioni di qeth/QDIO.

Per quelle interfacce e configurazioni in cui la funzione di takeover IP nativa del Dispatcher non funziona correttamente, il cliente può inserire dei comandi adatti negli script go per spostare manualmente gli indirizzi. In questo modo, quelle topologie di rete possono trarre beneficio dalla disponibilità elevata.

Configurazione del bilanciamento del carico in base alle regole

È possibile utilizzare il bilanciamento del carico in base alle regole per ottimizzare i tempi e le condizioni in cui i pacchetti devono essere inviati a determinati server. Load Balancer rivede le regole aggiunte dall'utente a partire dalla prima priorità fino all'ultima, fermandosi sulla prima regola che ritiene valida; quindi bilancia il carico dei contenuti tra i vari server associati a quella regola. Bilancia inoltre il carico in base alla destinazione e alla porta, ma tramite le regole aumenta la capacità di distribuire le connessioni.

Nella maggior parte dei casi, quando si configurano le regole è consigliabile configurare una regola predefinita come sempre true, per poter rilevare qualsiasi richiesta che viene inclusa tra altre regole di priorità più elevata. Questo è un po' come restituire la risposta "Il sito è al momento inattivo, provare in un secondo momento" quando tutti gli altri server riportano un errore per la richiesta client.

Si consiglia di utilizzare il bilanciamento del carico in base alle regole con Dispatcher e Site Selector quando, per qualche motivo, si desidera utilizzare un sottoinsieme di server. È necessario utilizzare sempre le regole del componente CBR.

La scelta è tra i seguenti tipi di regole:

È consigliabile pianificare la logica che le regole devono seguire prima di iniziare ad aggiungere regole alla configurazione.

Modalità di valutazione delle regole

Tutte le regole hanno un nome, un tipo e una priorità e possono disporre di un intervallo di inizio e di fine, insieme a un gruppo di server. Inoltre, la regola del tipo di contenuto del componente CBR ha un modello di espressione regolare corrispondente associato ad essa. (Per gli esempi e gli scenari relativi alle modalità di utilizzo delle regole di contenuto e della sintassi dei modelli valida per tali regole, consultare Appendice B. Sintassi della regola di contenuto (modello)).

Le regole vengono valutate in ordine di priorità. In altre parole, una regola con priorità 1 (numero più basso) verrà valutata prima di una regola con priorità 2 (numero più alto). Viene poi utilizzata la prima regola che viene soddisfatta. Una volta soddisfatta una regola, non verranno valutate altre regole.

Per soddisfare una regola, sono necessarie due condizioni:

  1. Il predicato della regola deve essere true. Vale a dire che, il valore che si sta valutando deve essere compreso tra l'intervallo iniziale e finale oppure il contenuto deve corrispondere all'espressione regolare specificata nel modello della regola di contenuto. Per le regole di tipo "true," il predicato viene sempre soddisfatto, a prescindere dagli intervalli di inizio e fine.
  2. Se vi sono server associati alla regola, almeno uno di loro deve avere un peso maggiore di 0 a cui inoltrare i pacchetti.

Se una regola non ha server associati, è necessaria solo la condizione uno affinché la regola venga soddisfatta. In questo caso Dispatcher interrompe la richiesta di collegamento, Site Selector restituisce il nome della richiesta del server con un errore e CBR fa in modo che Caching Proxy restituisca una pagina di errore.

Se non viene soddisfatta alcuna regola, Dispatcher seleziona un server dalla serie completa di server disponibili sulla porta, Site Selector seleziona un server dalla serie completa di server disponibili sul nome sito e CBR fa in modo che Caching Proxy restituisca una pagina di errore.

Utilizzo delle regole basate sull'indirizzo IP del client

Questo tipo di regola è disponibile nel componente Dispatcher, CBR o Site Selector.

È possibile utilizzare le regole basate sull'indirizzo IP client se si desidera visualizzare i clienti e allocare le risorse in base alla provenienza.

Ad esempio, è stato notificato che la rete sta ricevendo molto traffico non pagato, e per questo indesiderato, dai client appartenenti a un gruppo specifico di indirizzi IP. Si crea una regola mediante il comando dscontrol rule , ad esempio:

dscontrol rule add 9.67.131.153:80:ni type ip 
  beginrange 9.0.0.0 endrange 9.255.255.255

Questa regola "ni" visualizza le connessioni dai client non desiderati. A questo punto è possibile aggiungere alla regola i server che si desidera rendere accessibili ai dipendenti IBM oppure, se non si aggiunge alcun server, le richieste provenienti dagli indirizzi 9.x.x.x non verranno soddisfatte da nessun server.

Utilizzo delle regole basate sulla porta client

Questo tipo di regola è disponibile solo nel componente Dispatcher.

È possibile utilizzare regole basate sulla porta client se i client utilizzano alcuni tipi di software che richiedono una porta specifica da TCP/IP per generare le richieste.

Ad esempio, si può creare una regola che attesta che qualsiasi richiesta con una porta client 10002 utilizzerà una serie di server speciali veloci, in quanto la richiesta client con tale porta proviene da un gruppo di clienti di elite.

Utilizzo delle regole basate sull'ora del giorno

Questo tipo di regola è disponibile nel componente Dispatcher, CBR o Site Selector.

È possibile utilizzare le regole basate sull'ora del giorno per poter pianificare le capacità. Ad esempio, se il traffico sul sito Web è più elevato sempre nelle stesse ore del giorno, è possibile dedicare cinque server durante il periodo di maggior traffico.

Un altro motivo per cui si può utilizzare una regola basata sull'ora del giorno è quando si decide di disattivare, per la manutenzione, alcuni server ogni notte a mezzanotte; per questo è possibile impostare una regola che escluda quei server durante il periodo di manutenzione necessario.

Utilizzo delle regole basate sul tipo di servizio (TOS, type of service)

Questo tipo di regola è disponibile solo nel componente Dispatcher.

È possibile utilizzare le regole basate sul contenuto del campo "tipo di servizio" (TOS) nell'intestazione IP. Ad esempio, se una richiesta del client arriva con un valore TOS che indica un servizio normale, è possibile instradarla verso un gruppo di server. Se una richiesta client diversa arriva con un valore TOS diverso che indica una priorità di servizio più elevata, è possibile instradarla verso un gruppo diverso di server.

La regola TOS consente di configurare completamente ogni bit del byte TOS usando il comando dscontrol rule . Se si desidera che alcuni bit importanti corrispondano all'interno del byte TOS, utilizzare 0 o 1. Altrimenti, il valore usato è x. Di seguito viene riportato un esempio di aggiunta di una regola TOS:

dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x

Utilizzo delle regole basate sulle connessioni al secondo

Questo tipo di regola è disponibile nei componenti Dispatcher e CBR.

Nota:
è necessario che il gestore sia in esecuzione affinché le seguenti azioni funzionino correttamente.

È possibile utilizzare regole basate sulle connessioni al secondo per poter condividere i server con altre applicazioni. Ad esempio, si possono impostare due regole:

  1. Se il numero di connessioni al secondo sulla porta 80 è compreso tra 0 e 2000, utilizzare questi 2 server
  2. Se il numero di connessioni al secondo sulla porta 80 è superiore a 2000, utilizzare questi 10 server

Oppure, è possibile utilizzare Telnet e riservare due dei cinque server per Telnet, tranne quando il numero di connessioni al secondo supera un certo livello. In questo modo, Dispatcher bilancia il carico tra tutti e cinque i server nei momenti di traffico elevato.

Impostazione dell'opzione di valutazione delle regole "upserversonrule" insieme alla regola di tipo "connessione": quando si utilizza il tipo di regola delle connessioni e si imposta l'opzione upserversonrule, se alcuni server del gruppo sono disattivati, sicuramente i server rimanenti non verranno sovraccaricati. Consultare Opzione di valutazione dei server per le regole per ulteriori informazioni.

Utilizzo delle regole basate sul numero totale di connessioni attive

Questo tipo di regola è disponibile nei componenti Dispatcher o CBR.

Nota:
è necessario che il gestore sia in esecuzione affinché le seguenti azioni funzionino correttamente.

È possibile utilizzare le regole basate sul numero totale di connessioni attive su una porta se i server risultano sovraccarichi e iniziano a rifiutare i package. Determinati server Web continueranno ad accettare le connessioni anche se non hanno thread sufficienti per rispondere alla richiesta. Come risultato, le richieste del client scadono e l'utente che desidera visualizzare il sito Web non sarà soddisfatto. Le regole basate sulle connessioni attive servono a bilanciare la capacità all'interno di un lotto di server.

Ad esempio, nel caso in cui si sa che i propri server smetteranno di completare le operazioni dopo aver accettato 250 connessioni. Si crea una regola mediante il comando dscontrol rule o il comando cbrcontrol rule, ad esempio:

dscontrol rule add 130.40.52.153:80:pool2 type active 
  beginrange 250 endrange 500

o

cbrcontrol rule add 130.40.52.153:80:pool2 type active
  beginrange 250 endrange 500

Si aggiunge quindi la regola ai server correnti e ad altri server aggiunti che verrebbero, altrimenti, utilizzati per altri processi.

Utilizzo delle regole basate sulla larghezza di banda riservata e condivisa

Le regole della larghezza di banda riservata e della larghezza di banda condivisa sono disponibili solo nel componente Dispatcher.

Per le regole della larghezza di banda, Dispatcher calcola la larghezza di banda come la velocità con cui i dati vengono distribuiti ai client attraverso un gruppo specifico di server. Dispatcher traccia la capacità ai livelli server, regola, porta, cluster ed executor. Per ciascuno di questi livelli è disponibile un campo per il numero di byte: kilobyte trasferiti al secondo. Dispatcher calcola queste velocità in un intervallo di 60 secondi. I valori della velocità sono visibili dalla GUI o dal risultato visualizzato dalla riga comandi.

Regola della larghezza di banda riservata

La regola della larghezza di banda riservata permette di controllare il numero di kilobyte al secondo distribuiti da un gruppo di server. Impostando una soglia (assegnando cioè un'intervallo specifico per la larghezza di banda) per ogni gruppo di server della configurazione, è possibile controllare e garantire una parte determinata della larghezza di banda utilizzata da ciascuna combinazione porta-cluster.

Di seguito viene riportato un esempio di aggiunta di una regola reservedbandwidth:

dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth 
  beginrange 0 endrange 300

Gli intervalli di inizio e di fine vengono specificati in kilobyte al secondo.

Regola della larghezza di banda condivisa

Prima di configurare la regola della larghezza di banda condivisa, è necessario specificare la quantità massima di larghezza di banda (kilobyte al secondo) che può essere condivisa a livello executor o cluster tramite il comando dscontrol executor o dscontrol cluster con l'opzione sharedbandwidth. Il valore sharebandwidth non deve superare la larghezza di banda totale (capacità di rete totale) disponibile. Utilizzando il comando dscontrol per impostare la larghezza di banda condivisa, si fornisce solo un limite superiore per la regola.

Di seguito sono riportati esempi di sintassi del comando:

dscontrol executor set sharedbandwidth size
dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth size

Il valore size di sharedbandwidth è un numero intero (kilobyte al secondo). Il valore predefinito è zero. Se il valore è zero, la larghezza di banda non può essere condivisa.

La condivisione della larghezza di banda al livello di cluster permette a quest'ultimo di utilizzare una larghezza di banda massima specificata. Fino a quando la larghezza di banda utilizzata dal cluster è inferiore alla quantità specificata, questa regola verrà considerata valida, true. Se la larghezza di banda totale è superiore alla quantità specificata, questa regola sarà considerata non valida, false.

La condivisione della larghezza di banda al livello di executor permette all'intera configurazione di Dispatcher di condividere una quantità massima di larghezza di banda. Fino a quando la larghezza di banda utilizzata al livello di executor è inferiore alla quantità specificata, questa regola verrà considerata valida, true. Se la larghezza di banda totale è superiore a quella definita, questa regola sarà considerata non valida, false.

Di seguito vengono riportati esempi di aggiunta o impostazione di una regola sharedbandwidth:

dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel value
dscontrol rule set 9.20.34.11:80:shrule sharelevel value

Il valore value di sharelevel è executor o cluster. Sharelevel è un parametro obbligatorio sulla regola sharebandwidth.

Utilizzo delle regole di larghezza di banda riservata e condivisa

Dispatcher consente di assegnare una larghezza di banda specifica a gruppi di server all'interno della configurazione mediante la regola larghezza di banda riservata. Indicando un intervallo di inizio e uno di fine, è possibile controllare il numero di kilobyte distribuiti da un gruppo di server ai client. Se la regola non è più valida (l'intervallo di fine è stato superato), verrà valutata la regola successiva con priorità inferiore. Se quest'ultima è una regola "sempre true", viene selezionato un server che risponda al client con una risposta "sito occupato".

Ad esempio: si supponga che sulla porta 2222 vi sia un gruppo di tre server. Se la larghezza di banda riservata è impostata su 300, il numero massimo di kbyte al secondo sarà 300 in un intervallo di tempo di 60 secondi. Quando questa velocità viene superata, la regola non viene più considerata valida. Se questa fosse la sola regola, Dispatcher selezionerebbe uno dei tre server per gestire la richiesta. Se ci fosse una regola "sempre true" con priorità minore, la richiesta potrebbe essere indirizzata a un altro server e ricevere una risposta "sito occupato".

La regola di larghezza di banda condivisa fornisce ai client maggiore accessibilità ai server. Nello specifico, se utilizzato come regola di priorità inferiore seguito da una regola di larghezza di banda riservata, un client può ancora accedere a un server anche se la larghezza di banda riservata è stata superata.

Ad esempio: utilizzando una regola di larghezza di banda condivisa seguita da una regola di larghezza di banda riservata, è possibile permettere ai client di accedere ai tre server in modo controllato. Fino a quando sarà possibile utilizzare una larghezza di banda, la regola verrà valutata come true e l'accesso verrà garantito. Se non è disponibile alcuna larghezza di banda condivisa, la regola non sarà true e verrà valutata la regola successiva. Se segue una regola "sempre true", la richiesta può essere indirizzata secondo necessità.

Utilizzando una larghezza di banda riservata e condivisa, come descritto nell'esempio precedente, è possibile esercitare maggiore controllo e flessibilità nel permettere (o nel negare) l'accesso ai server. I server di una porta specifica possono essere limitati nell'uso della larghezza di banda, mentre altri possono utilizzare una larghezza di banda aggiuntiva per tutto il tempo in cui questa è disponibile.

Nota:
Dispatcher traccia la larghezza di banda misurando il traffico dei client, come ad esempio gli "acks" dei dati, che affluiscono su un server. Se, per alcune ragioni, questo traffico non viene "visto" da Dispatcher, i risultati che derivano dall'uso delle regole della larghezza di banda sono imprevedibili.

Regola Metric all

Questo tipo di regola è disponibile solo nel componente Site Selector.

Per quanto riguarda la regola metric all, scegliendo una metrica di sistema (cpuload, memload, oppure lo script della metrica di sistema personalizzato), Site Selector confronta il valore della metrica di sistema (restituito dall'agente Metric Server presente su ogni server con bilanciamento del carico) con l'intervallo di inizio e di fine specificato nella regola. Il valore attuale della metrica di sistema, per tutti i server all'interno del gruppo, deve essere incluso nell'intervallo della regola da eseguire.

Nota:
Lo script della regola di sistema scelto deve risiedere su ogni server su cui viene eseguito il bilanciamento del carico.

Di seguito viene riportato un esempio di aggiunta di una regola metric all alla configurazione:

sscontrol rule add dnsload.com:allrule1 type metricall 
  metricname cpuload beginrange 0 endrange 100

Regola media metrica

Questo tipo di regola è disponibile solo nel componente Site Selector.

Per quanto riguarda la regola Media metrica, si sceglie una metrica di sistema (cpuload, memload, oppure lo script della metrica di sistema personalizzato) e Site Selector confronta il valore della metrica di sistema (restituito dall'agente Metric Server presente su ogni server con bilanciamento del carico) con l'intervallo di inizio e di fine specificato nella regola. La media dei valori della metrica di sistema attuale, per tutti i server all'interno del gruppo, deve essere inclusa nell'intervallo della regola da generare.

Nota:
Lo script della regola di sistema scelto deve risiedere su ogni server su cui viene eseguito il bilanciamento del carico.

Di seguito viene riportato un esempio di aggiunta di una regola media metrica alla configurazione:

sscontrol rule add dnsload.com:avgrule1 type metricavg 
  metricname cpuload beginrange 0 endrange 100

Utilizzo di regole il cui valore è sempre true

Questo tipo di regola è disponibile nel componente Dispatcher, CBR o Site Selector.

È possibile creare una regola che sia "sempre true." Tale regola verrà sempre selezionata, a meno che tutti i server ad essa associati non siano disattivati. Per questo motivo, questa regola dovrebbe avere sempre una priorità inferiore rispetto alle altre.

È possibile disporre di più regole che siano "sempre true", ognuna con un gruppo di server associati. Viene scelta la prima regola true disponibile. Ad esempio, si assuma di avere sei server. Due di essi devono gestire il traffico in ogni circostanza, a meno che non siano entrambi inattivi. Se i primi due server sono inattivi, è possibile impostare una seconda serie di server per la gestione del traffico. Se tutti e quattro i server sono inattivi, allora è necessario utilizzare i due server finali per gestire il traffico. Si possono impostare tre regole sulla condizione "sempre true". Verrà scelto sempre il primo gruppo di server fino a quando almeno uno dei server è attivo. Se entrambi sono disattivati, si sceglie un server del secondo gruppo, e così via.

Un altro esempio prevede una regola "sempre true" in grado di assicurare che se i client in entrata non corrispondono a nessuna delle regole impostate, le loro richieste non verranno soddisfatte. Si crea una regola mediante il comando dscontrol rule, come ad esempio:

dscontrol rule add 130.40.52.153:80:jamais type true priority 100

A questo punto, nessun altro server viene aggiunto alla regola poiché i pacchetti client verrebbero eliminati senza risposta.

Nota:
Non è necessario impostare un intervallo di fine o di inizio quando si crea una regola sempre true.

Si possono definire più regole "sempre true" e, quindi, impostare la regola da eseguire modificandone i livelli di priorità.

Utilizzo delle regole basate sul contenuto delle richieste

Questo tipo di regola è disponibile nei componenti CBR o Dispatcher (quando si usa il metodo di inoltro cbr di Dispatcher).

Le regole del tipo di contenuto vengono utilizzate per inviare le richieste a gruppi di server impostati per gestire alcuni sottogruppi di traffico del sito. Ad esempio, un gruppo di server può gestire le richieste cgi-bin, un altro gruppo gestisce le richieste dei flussi audio e un terzo gruppo gestisce tutte le altre richieste. È possibile aggiungere una regola con un modello che corrisponde al percorso della directory cgi-bin, un'altra che corrisponde al tipo di file dei file di flussi audio e una terza regola sempre true per gestire il resto del traffico. Si aggiungono, poi, i server appropriati per ciascuna regola.

Importante: per gli esempi e gli scenari relativi alle modalità di utilizzo delle regole di contenuto e della sintassi dei modelli valida per tali regole, consultare Appendice B. Sintassi della regola di contenuto (modello).

ignora affinità di porta

Con la funzione ignora affinità di porta, si ignora l'aderenza di una porta per un server specifico. Ad esempio, si sta utilizzando una regola per limitare la quantità di connessioni a ciascun server delle applicazioni e su uno dei server si è verificato un overflow, mentre la regola sempre true informa l'utente di "riprovare in seguito" per poter utilizzare l'applicazione richiesta. La porta ha un valore di tempo di aderenza di 25 minuti e non è consigliabile che il client rimanga aderente a quel server. La funzione ignora affinità di porta permette di cambiare il server in overflow per ignorare l'affinità che normalmente è associata a quella porta. Quando il client effettuerà una nuova richiesta al cluster, il carico viene bilanciato verso il miglior server delle applicazioni disponibile e non sul server in overflow.

Consultare dscontrol server -- configura i server, per informazioni dettagliate sulla sintassi di comando relativa alla funzione ignora affinità di porta mediante il server aderente .

Aggiunta di regole alla configurazione

È possibile aggiungere delle regole utilizzando il comando dscontrol rule add , modificando il file di configurazione di esempio oppure usando una GUI (graphical user interface). Si possono aggiungere più regole su ciascuna porta definita.

Si tratta di un processo a due fasi: si aggiunge la regola e si definiscono i server da supportare se la regola è true. Ad esempio, l'amministratore di sistema desidera quantificare l'uso dei server proxy da parte di ciascuna divisione del sito. Gli indirizzi IP sono assegnati a ogni divisione. Creare il primo gruppo di regole in base all'indirizzo IP del client per separare il carico di ogni divisione:

dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255
dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255
dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255

Quindi, aggiungere un server diverso ad ogni regola e misura il carico su ogni server per fatturare correttamente la divisione in base ai servizi utilizzati. Ad esempio:

dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45
dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63
dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47

Opzione di valutazione dei server per le regole

L'opzione di valutazione dei server è disponibile solo nel componente Dispatcher.

Sul comando dscontrol rule è presente un'opzione di valutazione dei server per le regole. Utilizzare l'opzione evaluate per valutare la condizione delle regole su tutti i server sulla porta oppure per valutare la condizione delle regole solo sui server inclusi nella regola. (Nelle versioni precedenti di Load Balancer, è possibile misurare ogni condizione di regola su tutti i server sulla porta).

Note:
  1. L'opzione di valutazione del server è valida solo per le regole che si basano sulle caratteristiche dei server: la regola Numero totale di connessioni (al secondo), la regola Connessioni attive e la regola Larghezza di banda riservata.
  2. La regola di tipo "connessione" ha un'opzione di valutazione in più da scegliere -- upserversonrule. Consultare Utilizzo delle regole basate sulle connessioni al secondo per ulteriori informazioni.

Di seguito vengono riportati esempi di aggiunta o impostazione dell'opzione di valutazione su una regola di larghezza di banda riservata:

dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate level 
dscontrol rule set 9.22.21.3:80:rbweval evaluate level

Il valore evaluate level può essere impostato su porta, regola o upserversonrule. Il valore predefinito è porta.

Valutazione dei server in una regola

L’opzione per la misurazione della condizione della regola sui server inclusi in una regola, permette di configurare due regole con le seguenti caratteristiche:

Il risultato è che quando il traffico supera la soglia dei server inclusi nella prima regola, il traffico verrà inviato al server del "sito occupato" incluso nella seconda regola. Quando il traffico scende al di sotto della soglia dei server all'interno della prima regola, il nuovo traffico continua ancora una volta sui server nella prima regola.

Valutazione dei server sulla porta

Utilizzando le due regole descritte nell'esempio precedente, se si imposta l'opzione di valutazione su port per la prima regola (valutare la condizione della regola su tutti i server della porta), nel momento in cui il traffico supera la soglia di quella regola, viene indirizzato al server "sito occupato" associato alla seconda regola.

La prima regola misura il traffico di tutti il server (compreso il server "sito occupato") sulla porta per determinare se il traffico supera la soglia. Con il diminuire della congestione dei server associati alla prima regola, potrebbe verificarsi un risultato imprevisto nel punto in cui il traffico continua sul server "sito occupato", poiché il traffico sulla porta supera ancora la soglia della prima regola.

Funzionamento della funzione di affinità di Load Balancer

Per i componenti Dispatcher e CBR: si abilita la funzione di affinità quando la porta del cluster viene configurata come aderente. La configurazione di una porta del cluster sulla condizione di aderenza permette alle successive richieste client di essere indirizzate allo stesso server. Ciò è possibile impostando su un certo numero di secondi il valore di stickytime a livello di executor, del cluster o della porta. La funzione viene disabilitata impostando stickytime su zero.

se si abilita l'affinità multiporta, i valori di stickytime delle porte condivise devono essere uguali (numero diverso da zero). Consultare Affinità multiporta per ulteriori informazioni.

Per il componente Site Selector: si abilita la funzione di affinità quando si configura un nome sito come aderente. In questo modo, il client può utilizzare lo stesso server per più richieste di servizio nome. Ciò è possibile impostando il valore stickytime del nome sito su un certo numero di secondi. La funzione viene disabilitata impostando stickytime su zero.

L'intervallo compreso tra la chiusura di una connessione e l'apertura di una nuova connessione durante il quale un client verrà rinviato allo stesso server utilizzato durante la prima connessione. Dopo questo intervallo, il client potrebbe essere inviato a un server diverso dal primo. Il valore dell'intervallo per un server viene configurato utilizzando i comandi dscontrol executor, port o cluster.

Funzionamento con affinità disabilitata

Con la funzione di affinità disabilitata, ogni volta che si riceve una nuova connessione TCP da un client, Load Balancer seleziona il server adatto in quel momento e gli inoltra i pacchetti. Se un'altra connessione viene dallo stesso client, Load Balancer la considera come una nuova connessione non correlata e seleziona di nuovo il server più adatto in quel momento.

Funzionamento con affinità abilitata

Con la funzione di affinità abilitata, se una richiesta viene dallo stesso client, sarà poi indirizzata allo stesso server.

Nel corso del tempo, il client termina di inviare le transazioni e il record di affinità non sarà più necessario. Da qui, il significato di "tempo di aderenza". Ogni record di affinità ha una durata che equivale al valore "stickytime" espresso in secondi. Quando si ricevono altre connessioni durante il tempo di aderenza, il record di affinità è ancora valido e la richiesta viene indirizzata allo stesso server. Se si riceve un'altra connessione al di fuori del tempo di aderenza, il record viene eliminato; una connessione ricevuta oltre quell'intervallo di tempo, verrà supportata da un altro server.

Il comando del server inattivo (dscontrol server down) viene utilizzato per porre un server offline. Il server sarà attivo fino a che viene raggiunto il valore dell'intervallo di aderenza.

Affinità multiporta

L'affinità multiporta si applica esclusivamente ai metodi di inoltro MAC e NAT/NATP del componente Dispatcher.

L'affinità multiporta è una funzione di aderenza che è stata estesa per coprire più porte. Ad esempio, se una richiesta client viene ricevuta su una porta e la richiesta successiva su un'altra porta, l'affinità multiporta permette a Dispatcher di inviare la richiesta di quel client allo stesso server. Per utilizzare questa funzione, è importante che le porte:

È possibile collegare più porte alla stessa affinità multiporta. Quando le connessioni provengono dallo stesso client sulla stessa porta o su una porta condivisa, accedono allo stesso server. Di seguito viene riportato un esempio di configurazione di più porte con affinità multiporta sulla porta 10:

dscontrol port set cluster:20 crossport 10
dscontrol port set cluster:30 crossport 10
dscontrol port set cluster:40 crossport 10

Una volta stabilita l'affinità multiporta, è possibile modificare il valore stickytime della porta. Tuttavia, è consigliabile impostare i valori stickytime di tutte le porte condivise sullo stesso valore per evitare che si verifichino risultati imprevisti.

Per rimuovere l'affinità multiporta, impostare nuovamente il valore crossport sul numero di porta originale. Consultare dscontrol port -- configura le porte, per informazioni dettagliate sulla sintassi di comando relativa all'opzione crossport.

Maschera indirizzo affinità (stickymask)

La funzione maschera indirizzo affinità si applica esclusivamente al componente Dispatcher.

La funzione maschera indirizzo affinità è un potenziamento della funzione di aderenza che serve a raggruppare i client in base agli indirizzi di sottorete comuni. Specificando stickymask nel comando dscontrol port, è possibile applicare una maschera ai bit più significativi dell'indirizzo IP a 32 bit. Se questa funzione è configurata, quando una richiesta client stabilisce la prima connessione alla porta, tutte le successive richieste dai client con lo stesso indirizzo di sottorete (rappresentato da quella parte dell'indirizzo IP con maschera) verranno indirizzate allo stesso server.

Nota:
per abilitare stickymask, il valore di porta stickytime deve essere diverso da zero.

Ad esempio, se si desidera che tutte le richieste client in entrata, con lo stesso indirizzo Classe A di rete, vengano indirizzate allo stesso server, è sufficiente impostare il valore stickymask su 8 (bit) per la porta. Per raggruppare le richieste client con lo stesso indirizzo Classe B di rete, impostare il valore stickymask su 16 (bit). Per raggruppare le richieste client con lo stesso indirizzo Classe C di rete, impostare il valore stickymask su 24 (bit).

Per ottenere dei risultati più soddisfacenti, impostare il valore stickymask al primo avvio di Load Balancer. Modificando in modo dinamico il valore stickymask, i risultati potrebbero essere imprevedibili.

Interazione con l'affinità multiporta: se si abilita l'affinità multiporta, i valori stickymask delle porte condivise, devono essere gli stessi. Consultare Affinità multiporta per ulteriori informazioni.

Per abilitare la maschera indirizzo affinità, emettere un comando dscontrol port simile al seguente:

dscontrol port set cluster:port stickytime 10 stickymask 8

I valori possibili di stickymask sono 8, 16, 24 e 32. Un valore 8 indica che verrà applicata una maschera ai primi 8 bit più significativi dell'indirizzo IP (indirizzo Classe A di rete). Un valore 16 indica che verrà applicata una maschera ai primi 16 bit più significativi dell'indirizzo IP (indirizzo Classe B di rete). Un valore 24 indica che verrà applicata una maschera ai primi 24 bit più significativi dell'indirizzo IP (indirizzo Classe C di rete). Il valore 32 indica che si sta applicando una maschera all'intero indirizzo IP che, in effetti, disabilita la funzione di maschera indirizzo affinità. Il valore predefinito di stickymask è 32.

Consultare dscontrol port -- configura le porte, per informazioni dettagliate sulla sintassi di stickymask (funzione maschera indirizzo affinità).

Gestione della disattivazione delle connessioni server

La gestione della disattivazione si applica ai componenti Dispatcher e CBR.

Per rimuovere un server dalla configurazione di Load Balancer per qualsiasi motivo (aggiornamenti, manutenzione, e così via), utilizzare il comando dscontrol manager quiesce . Il comando secondario di disattivazione fa in modo che le connessioni esistenti vengano completate (senza essere interrotte) e inoltra solo le successive nuove connessioni dal client al server disattivato, se la connessione è designata come aderente e il tempo di aderenza non è scaduto. Tale comando impedisce qualsiasi altra connessione al server.

Gestione della disattivazione per le connessioni aderenti

Utilizzare l'opzione di disattivazione "now" se è stato impostato un tempo di aderenza e si intende inviare le nuove connessioni a un altro server (diverso dal server disattivato) prima della scadenza di tale tempo. Di seguito viene riportato un esempio sull'uso dell'opzione now che permette di disattivare il server 9.40.25.67:

dscontrol manager quiesce 9.40.25.67 now

L'opzione now determina il modo in cui verranno gestite le connessioni aderenti:

Opzione di affinità della regola basata sul contenuto della richiesta client

È possibile specificare i seguenti tipi di affinità sul comando dscontrol rule:

Il valore predefinito per l'opzione di affinità è "none." L'opzione stickytime del comando della porta deve essere impostata su zero (non abilitata) per poter configurare l'opzione affinità sul comando della regola del cookie attivo, cookie passivo e URI. Se l'affinità è impostata sulla regola, non è possibile abilitare stickytime sulla porta.

Affinità cookie attivo

L'affinità cookie attivo si applica solamente al componente CBR.

Permette di rendere i client "aderenti" a un particolare server. Questa funzione viene abilitata regolando il valore stickytime di una regola su un numero positivo e configurando l'affinità su "activecookie". Ciò è possibile quando si aggiunge una regola o si utilizza il comando di impostazione di una regola. Consultare dscontrol rule -- configura le regole, per informazioni dettagliate sulla sintassi del comando.

Una volta abilitata la regola affinità cookie attivo, le nuove richieste client verranno bilanciate grazie a degli algoritmi CBR standard, mentre le richieste successive provenienti dallo stesso client verranno inviate al server scelto inizialmente. Quest'ultimo viene memorizzato come cookie nella risposta per il client. Fino a quando le future richieste del client conterranno il cookie, e ogni richiesta arriva nell'intervallo stickytime stabilito, il client conserverà l'affinità con il server iniziale.

L'affinità cookie attivo viene utilizzata per garantire che un client continui ad essere bilanciato con lo stesso server per un determinato periodo di tempo. Ciò è possibile inviando un cookie che verrà memorizzato dal browser dei client. Il cookie contiene la regola cluster:port:rule utilizzata per prendere la decisione, il server in base al quale è stato bilanciato il carico e la data e l'ora di scadenza che indicano la fine della validità dell'affinità. Il cookie è nel seguente formato: IBMCBR=cluster:port:rule+server-time! Le informazioni cluster:port:rule e server sono codificate per impedire che la configurazione CBR venga rivelata.

Funzionamento dell'affinità cookie attivo

Ogni volta che viene generata una regola con affinità cookie attivo abilitata, il cookie inviato dal client viene esaminato.

Questo nuovo cookie viene inserito nelle intestazioni che verranno restituite al client e se il browser di quest'ultimo è configurato per accettare i cookie, restituirà le richieste successive.

Ogni istanza di affinità del cookie sarà di 65 byte di lunghezza e terminerà con un punto esclamativo. Ne deriva che un cookie di 4096 byte può contenere circa 60 regole di cookie attivi per dominio. Una volta saturo, tutte le istanze di affinità scadute verranno eliminate. Se tutte le istanze sono ancora valide, si elimina la più obsoleta per fare spazio e aggiungere le nuove istanze della regola corrente.

Nota:
CBR sostituisce le occorrenze dei cookie IBMCBR di formato vecchio non appena compaiono nel proxy.

L'opzione affinità cookie attivo, del comando della regola, può essere impostata solo su activecookie se il valore stickytime della porta è zero (non abilitato). Una volta abilitata l'affinità cookie attivo su una regola, non è possibile abilitare stickytime sulla porta.

Come abilitare l'affinità cookie attivo

Per abilitare l'affinità cookie attivo di una regola particolare, utilizzare il comando del gruppo di regole:

rule set cluster:port:rule stickytime 60
rule set cluster:port:rule affinity activecookie

Perché utilizzare l'affinità cookie attivo

Una regola di aderenza viene utilizzata normalmente per CGI o i servlet che memorizzano lo stato dei client sul server. Lo stato viene identificato da un ID cookie (questi sono i cookie dei server). Lo stato del client è presente solo sul server selezionato, quindi il client ha bisogno del cookie di quel server per conservare lo stato tra le richieste.

Scadenza dell'affinità cookie attivo ignorata

L'affinità cookie attivo ha una scadenza predefinita relativa alla data del server corrente, più l'intervallo stickytime, più ventiquattro ore. Se i sistemi dei client (quelli che inviano le richieste alla macchina CBR) hanno una data errata (ad esempio, sono avanti di un giorno rispetto alla data del server), ignorano i cookie che provengono da CBR in quanto il sistema presuppone che tali cookie siano già scaduti. Per impostare una data di scadenza più lunga, modificare lo script cbrserver. Nel file di script, modificare la riga javaw aggiungendo il seguente parametro dopo LB_SERVER_KEYS: -DCOOKIEEXPIREINTERVAL=X dove X è il numero di giorni da aggiungere alla data di scadenza.

Su sistemi AIX, Solaris e Linux, il file cbrserver si trova nella directory /usr/bin.

Su sistemi Windows, il file cbrserver si trova nella directory \winnt\system32.

Affinità cookie passivo

L'affinità cookie passivo si applica al metodo di inoltro cbr (content-based routing) del componente Dispatcher e al componente CBR. Consultare Instradamento basato sul contenuto di Dispatcher (metodo di inoltro cbr) per informazioni su come configurare il metodo di inoltro cbr di Dispatcher.

L'affinità cookie passivo permette di rendere aderenti i client di un particolare server. Abilitando l'affinità di una regola su "passivecookie", l'affinità cookie passivo consente di bilanciare il carico del traffico Web con caratteristiche di affinità con lo stesso server tramite la creazione di cookie auto-identificativi da parte dei server. È possibile configurare l'affinità cookie passivo al livello della regola.

Quando viene generata la regola, se l'affinità cookie passivo è abilitata, Load Balancer sceglierà il server in base al nome cookie nell'intestazione HTTP della richiesta client. Load Balancer confronta il nome del cookie dell'intestazione HTTP del client con il valore del cookie configurato per ciascun server.

La prima volta in cui Load Balancer rileva un server il cui valore cookie contiene il nome cookie del client, Load Balancer sceglie quel server per la richiesta.

Nota:
Load Balancer permette tale flessibilità per gestire i casi in cui il server può generare un valore cookie che abbia una parte statica aggiunta e una parte variabile. Ad esempio, il valore del cookie del server potrebbe essere il nome del server (un valore statico) aggiunto e un valore data/ora (un valore variabile).

Se il nome del cookie nella richiesta client non si trova o non corrisponde al contenuto dei valori del cookie del server, quest'ultimo verrà scelto tra una selezione di server esistente o tramite la tecnica dei pesi del metodo round-robin.

Per configurare l'affinità cookie passivo:

L'opzione affinità cookie passivo, del comando della regola, può essere impostata solo su passivecookie se il valore stickytime della porta è zero (non abilitato). Una volta abilitata l'affinità cookie passivo su una regola, non è possibile abilitare stickytime sulla porta.

Affinità URI

L'affinità URI si applica al metodo di inoltro cbr del Dispatcher e al componente CBR. Consultare Instradamento basato sul contenuto di Dispatcher (metodo di inoltro cbr) per informazioni su come configurare il metodo di inoltro cbr.

L'affinità URI permette di bilanciare il carico del traffico Web sui server Caching Proxy che consentono di memorizzare nella cache il contenuto unico di ciascun server. In questo modo, si aumenta effettivamente la capacità della cache del sito evitando che i contenuti vengano memorizzati su più macchine. Configurare l'affinità URI al livello della regola. Una volta creata la regola, se l'affinità URI è abilitata e lo stesso gruppo di server è attivo e risponde, Load Balancer inoltra le richieste in arrivo dei client con lo stesso URI sullo stesso server.

Normalmente, Load Balancer può distribuire le richieste su più server che supportano lo stesso contenuto. Se si utilizza Load Balancer con un gruppo di caching server, i contenuti più esaminati vengono memorizzati nella cache di tutti i server. Questo consente di supportare un carico di client molto elevato riproducendo i contenuti identici memorizzati nella cache su più macchine. Questo espediente risulta molto utile quando si gestiscono siti Web con un volume elevato di traffico.

Tuttavia, se il sito Web supporta un volume ridotto di traffico client di diverso contenuto, e si preferisce avere maggiore disponibilità di cache sui vari server, il sito funzionerebbe meglio se ogni caching server avesse un contenuto unico e Load Balancer distribuisse la richiesta esclusivamente al caching server con quel contenuto.

Con l'affinità URI, Load Balancer permette di distribuire il contenuto memorizzato nella cache sui singoli server, evitando una memorizzazione ridondante su più macchine. Con questo potenziamento, si migliorano anche le prestazioni dei siti server di diverso contenuto che utilizzano i server Caching Proxy. Le stesse richieste vengono inviate allo stesso server, per cui il contenuto viene memorizzato nella cache dei singoli server. Quindi, la dimensione effettiva della cache aumenta ogni volta che si aggiunge una nuova macchina server al lotto.

Per configurare l'Affinità URI:

Configurazione del supporto di Dispatcher per una rete geografica

Questa funzione è disponibile esclusivamente per il componente Dispatcher.

Se non si sta utilizzando il supporto rete geografica di Dispatcher, né il metodo di inoltro nat di Dispatcher, una configurazione Dispatcher richiede che la macchina Dispatcher e i server relativi siano collegati allo stesso segmento LAN (vedere Figura 32). Una richiesta client arriva nella macchina Dispatcher e viene inviata al server. Dal server, la risposta viene restituita direttamente al client.

Figura 32. Esempio di una configurazione costituita da un unico segmento LAN
Unico segmento LAN

La funzione di rete geografica di Dispatcher fornisce un supporto ai server esterni, noti come server remoti (consultare Figura 33). Se GRE non è supportato sul sito remoto e se il metodo di inoltro nat di Dispatcher non viene utilizzato, il sito remoto deve essere costituito da una macchina Dispatcher remota (Dispatcher 2) e dai relativi server collegati localmente (ServerG, ServerH e ServerI). Un pacchetto client andrà da Internet alla macchina Dispatcher iniziale. Dal Dispatcher iniziale, il pacchetto raggiunge la macchina Dispatcher che si trova in una posizione geograficamente remota e uno dei server collegati localmente.

Tutte le macchine Dispatcher (locale e remota) devono eseguire lo stesso tipo di sistema operativo e piattaforma per poter creare delle configurazioni WAN.

Figura 33. Esempio di configurazione che utilizza server locali e remoti
Server locali e remoti

Questa configurazione a un indirizzo cluster di supportare tutte le richieste di client in tutto il mondo e di distribuire il carico su server altrettanto remoti.

La macchina Dispatcher che riceve inizialmente il pacchetto può avere dei server locali collegati e può distribuire il carico tra i server locali e quelli remoti.

Sintassi dei comandi

Per configurare il supporto rete geografica:

  1. Aggiungere i server. Quando si aggiunge un server a un Dispatcher, definire se il server è locale o remoto (vedere paragrafo precedente). Per aggiungere un server e definirlo come locale, emettere il comando dscontrol server add senza specificare un router. Questo è il valore di default. Per definire il server come remoto, specificare il router attraverso il quale Dispatcher deve inviare il pacchetto per poter raggiungere il server remoto. Il server deve essere un altro Dispatcher e l'indirizzo server deve essere l'indirizzo di non inoltro del Dispatcher. Ad esempio, in Figura 34, se si aggiunge LB 2 come server remoto sotto LB 1, indicare router 1 come l'indirizzo router. Sintassi generale:
    dscontrol server add cluster:port:server router address

    Per maggiori informazioni sulla parola chiave router, consultare dscontrol server -- configura i server.

  2. Configurare gli alias. Sulla prima macchina Dispatcher (dove le richieste client arrivano da Internet), è necessario creare un alias per l'indirizzo cluster utilizzando il comando executor configure. (Per i sistemi Linux o UNIX, è possibile utilizzare il comando executor configure o ifconfig). Sulle macchine Dispatcher remote, tuttavia, non viene creato un alias per l'indirizzo cluster su una scheda di interfaccia di rete.

Utilizzo di advisor remoti con il supporto rete geografica di Dispatcher

Sui Dispatcher entry-point:

Un dispatcher del punto di ingresso gestirà il Dispatcher di secondo livello come server e ne controllerà lo stato di integrità come tale, associando i risultati all'IP effettivo del dispatcher.

Sui Dispatcher remoti: effettuare le seguenti procedure di configurazione per ogni indirizzo cluster remoto. Per una configurazione di disponibilità elevata sul Dispatcher remoto, eseguire queste operazioni su entrambe le macchine.

Sistemi AIX

Sistemi HP-UX, Sistemi Linux, Solaris e Windows

Esempio di configurazione

Figura 34. Configurazione di esempio di rete geografica con Load Balancer remoti
Configurazione di rete geografica con Load Balancer remoti

Questo esempio si applica alla configurazione illustrata nella Figura 34.

Di seguito viene spiegato come configurare le macchine Dispatcher per supportare l'indirizzo cluster xebec sulla porta 80. LB1 è il Load Balancer "entry-point". Viene utilizzata una connessione Ethernet. Notare che LB1 ha cinque server definiti: tre locali (ServerA, ServerB, ServerC) e due remoti (LB2 e LB3). I server remoti LB2 e LB3 hanno, ognuno, altri tre server locali definiti.

Sulla console del primo Dispatcher (LB1), eseguire queste operazioni:

  1. Avvia l'executor.

    dscontrol executor start

  2. Impostare l'indirizzo di non inoltro della macchina Dispatcher.

    dscontrol executor set nfa LB1

  3. Definire il cluster.

    dscontrol cluster add xebec

  4. Definire la porta.

    dscontrol port add xebec:80

  5. Definire i server.
    1. dscontrol server add xebec:80:ServerA
    2. dscontrol server add xebec:80:ServerB
    3. dscontrol server add xebec:80:ServerC
    4. dscontrol server add xebec:80:LB2 router Router1
    5. dscontrol server add xebec:80:LB3 router Router1
  6. Configurare l'indirizzo cluster.

    dscontrol executor configure xebec

Sulla console del secondo Dispatcher (LB2):

  1. Avvia l'executor.

    dscontrol executor start

  2. Impostare l'indirizzo di non inoltro della macchina Dispatcher.

    dscontrol executor set nfa LB2

  3. Definire il cluster.

    dscontrol cluster add xebec

  4. Definire la porta.

    dscontrol port add xebec:80

  5. Definire i server.
    1. dscontrol server add xebec:80:ServerD
    2. dscontrol server add xebec:80:ServerE
    3. dscontrol server add xebec:80:ServerF

Sulla console del terzo Dispatcher (LB3):

  1. Avvia l'executor.

    dscontrol executor start

  2. Impostare l'indirizzo di non inoltro della macchina Dispatcher.

    dscontrol executor set nfa LB3

  3. Definire il cluster.

    dscontrol cluster add xebec

  4. Definire la porta.

    dscontrol port add xebec:80

  5. Definire i server.
    1. dscontrol server add xebec:80:ServerG
    2. dscontrol server add xebec:80:ServerH
    3. dscontrol server add xebec:80:ServerI

Note

  1. Su tutti i server (A-I), creare l'alias dell'indirizzo cluster sul loopback.
  2. I cluster e le porte vengono aggiunti con dscontrol su tutte le macchine Dispatcher collegate: il Dispatcher entry-point e le macchine remote.
  3. Vedere Utilizzo di advisor remoti con il supporto rete geografica di Dispatcher per informazioni su come utilizzare gli advisor remoti con un supporto di rete geografica.
  4. Il supporto di rete geografica impedisce i loop di instradamento infiniti. (Se una macchina Dispatcher riceve un pacchetto da un altro Dispatcher, non lo inoltra a un terzo Dispatcher.) La rete geografica supporta solo un livello di macchine remote.
  5. La rete geografica supporta UDP e TCP.
  6. La disponibilità elevata è disponibile anche sulle reti geografiche: ogni Dispatcher può disporre di una macchina di backup adiacente in standby (all'interno della stessa LAN).
  7. Il gestore e gli advisor possono funzionare su una rete geografica e, se utilizzati, devono essere avviati su tutte le macchine Dispatcher collegate.
  8. Load Balancer supporta le reti geografiche (WAN) esclusivamente con sistemi operativi simili.

Supporto GRE (Generic Routing Encapsulation)

GRE (Generic Routing Encapsulation) è un protocollo Internet specificato in RFC 1701 e RFC 1702. Con GRE, Load Balancer è in grado di racchiudere i pacchetti IP client all'interno dei pacchetti IP/GRE e inviarli alle piattaforme server, come ad esempio OS/390 che supporta GRE. Il supporto GRE permette al componente Dispatcher di bilanciare il carico dei pacchetti su più indirizzi server associati a un indirizzo MAC.

Load Balancer implementa GRE come parte della funzione WAN. Ciò permette a Load Balancer di bilanciare il carico della rete geografica direttamente su ciascun sistema server in grado di aprire i pacchetti GRE. Non è necessario che Load Balancer sia installato sul sito remoto se i server remoti supportano i pacchetti GRE racchiusi. Load Balancer racchiude i pacchetti WAN con il campo chiave GRE impostato sul valore decimale 3735928559.

Figura 35. Configurazione di esempio di rete geografica con piattaforma server che supporta GRE
Configurazione rete geografica con piattaforma server che supporta GRE

In questo esempio (Figura 35), per aggiungere il server ServerD remoto, che supporta GRE, definirlo nella configurazione di Load Balancer come se si stesse definendo un server WAN nella gerarchia cluster:port:server:

dscontrol server add cluster:port:ServerD router Router1

Su sistemi Linux, configurazione dell'incapsulamento GRE perWAN

Linux ha la capacità nativa di racchiudere GRE che consente a Load Balancer di bilanciare il carico delle immagini del server Linux/390, dove molte immagini server condividono un indirizzo MAC. Questo permette al Load Balancer entry-point di bilanciare il carico direttamente sui server WAN di Linux, senza passare per un Load Balancer in una posizione remota. Ciò consente agli advisor di Load Balancer entry-point di funzionare direttamente con ogni server remoto.

Su Load Balancer entry point, eseguire una configurazione come quella descritta per WAN.

Per configurare ogni server di backend di Linux, immettere i seguenti comandi come root. (Questi comandi possono essere aggiunti alla funzionalità di avvio del sistema in modo che le modifiche vengano conservate anche con i successivi riavvii).

# modprobe ip_gre
# ip tunnel add gre-nd mode gre ikey 3735928559 
# ip link set gre-nd up
# ip addr add cluster address dev gre-nd
Nota:
il server Linux, configurato con queste istruzioni, non deve essere sullo stesso segmento fisico di Load Balancer entry-point. Questo perché il server Linux risponde alle richieste "ARP who-has" dell'indirizzo cluster determinando una condizione di competizione che potrebbe causare un "corto circuito" in cui tutto il traffico diretto all'indirizzo cluster viene indirizzato solo al vincitore della competizione ARP.

Normalmente, le funzioni di bilanciamento del carico del Dispatcher funzionano indipendentemente dal contenuto dei siti su cui viene utilizzato il prodotto. Tuttavia, esiste un'area in cui i contenuti del sito assumono una grande importanza e dove le decisioni relative ai contenuti possono avere un impatto significativo sull'efficienza del Dispatcher. Ciò avviene nell'area di indirizzamento del collegamento.

Se le pagine specificano dei collegamenti che portano ai singoli server del sito, in effetti si sta forzando un client ad andare su una macchina in particolare ignorando, così, la funzione di bilanciamento del carico che potrebbe, altrimenti, essere attiva. Per questo motivo, si consiglia di utilizzare sempre l'indirizzo del Dispatcher in tutti i collegamenti presenti nelle pagine. Notare che il tipo di indirizzamento utilizzato potrebbe non sempre essere evidente se il sito utilizza la programmazione automatizzata che crea le HTML in modo dinamico. Per ottimizzare il bilanciamento del carico, bisognerebbe conoscere qualsiasi indirizzamento esplicito ed evitarlo laddove è possibile.

Utilizzo di una configurazione di rete privata

È possibile impostare le macchine del Dispatcher e del server TCP utilizzando una rete privata. Questa configurazione può ridurre il conflitto sulla rete pubblica o esterna e può avere conseguenze sulle prestazioni.

Per AIX, questa configurazione può trarre vantaggio dalle velocità elevate di High Performance Switch SP se le macchine del Dispatcher e del server TCP sono in esecuzione sui nodi in un Frame SP.

Per creare una rete privata, ogni macchina deve avere almeno due schede LAN, una delle quali collegata alla rete privata. È necessario, inoltre, configurare la seconda scheda LAN su una rete secondaria diversa. La macchina del Dispatcher invierà le richieste client alle macchine del server TCP attraverso la rete privata.

Su sistemi Windows: configurare l'indirizzo di non inoltro mediante il comando executor configure.

I server aggiunti con il comando dscontrol server add devono essere aggiunti mediante gli indirizzi di rete privati; ad esempio, facendo riferimento all'esempio del server Apple nella Figura 36, il comando dovrebbe essere codificato come:

dscontrol server add cluster_address:80:10.0.0.1

non

dscontrol server add cluster_address:80:9.67.131.18

Se si sta utilizzando Site Selector per fornire al Dispatcher informazioni sul carico, configurare Site Selector per notificare i carichi sugli indirizzi privati.

Figura 36. Esempio di una rete privata che utilizza Dispatcher
Rete privata

L'uso di una configurazione di rete privata si applica esclusivamente al componente Dispatcher.

Utilizzo del cluster jolly per combinare le configurazioni di server

L'uso di un cluster jolly per combinare le configurazioni dei server si applica esclusivamente al componente Dispatcher.

Il "carattere jolly" fa riferimento alla capacità del cluster di corrispondere a diversi indirizzi IP (vale a dire, agisce da jolly). L'indirizzo cluster 0.0.0.0 viene utilizzato per specificare un cluster jolly.

Se si dispone di molti indirizzi cluster da bilanciare e le configurazioni porta/server sono identiche per tutti i cluster, si possono combinare tutti i cluster in un'unica configurazione di cluster jolly.

È necessario configurare esplicitamente ogni indirizzo cluster su uno degli adattatori di rete della stazione di lavoro del Dispatcher. Non aggiungere nessun indirizzo cluster alla configurazione Dispatcher mediante il comando di aggiunta cluster dscontrol.

Aggiungere solo il cluster jolly (indirizzo 0.0.0.0) e configurare le porte e i server per il bilanciamento del carico. Il traffico indirizzato a qualsiasi indirizzo configurato degli adattatori verrà bilanciato mediante la configurazione del cluster jolly.

Un vantaggio di questo approccio è dato dal fatto che il traffico, diretto a tutti gli indirizzi cluster, viene preso in considerazione quando si sceglie il miglior server da raggiungere. Se un cluster sta ricevendo molto traffico e ha creato molte connessioni attive su uno dei server, il traffico diretto ad altri indirizzi cluster verrà bilanciato mediante queste informazioni.

Si possono combinare i cluster jolly con i cluster effettivi se vi sono alcuni indirizzi cluster con configurazioni porta/server univoche e altri con configurazioni comuni. Le configurazioni univoche devono essere assegnate ognuna a un indirizzo cluster effettivo. Tutte le configurazioni comuni possono essere assegnate a un cluster jolly.

Utilizzo di cluster jolly per bilanciare il carico dei firewall

L'uso di un cluster jolly per bilanciare il carico dei firewall si applica esclusivamente al componente Dispatcher. L'indirizzo cluster 0.0.0.0 viene utilizzato per specificare un cluster jolly.

Il cluster jolly si può utilizzare per bilanciare il traffico verso gli indirizzi che non sono configurati esplicitamente su nessun adattatore di rete della stazione di lavoro del Dispatcher. Affinché funzioni, il Dispatcher deve essere in grado di vedere tutto il traffico di cui deve bilanciare il carico. La stazione di lavoro del dispatcher non vedrà il traffico diretto agli indirizzi che non sono stati configurati esplicitamente su uno degli adattatori di rete, a meno che non sia impostato come instradamento predefinito per una parte del traffico.

Dopo aver configurato il Dispatcher come instradamento predefinito, il traffico TCP o UDP, in transito sulla macchina Dispatcher, verrà bilanciato mediante la configurazione del cluster jolly.

Un'applicazione ha lo scopo di bilanciare il carico dei firewall. Poiché i firewall possono elaborare pacchetti provenienti da diversi indirizzi e porte di destinazione, è necessario poter bilanciare il carico del traffico indipendentemente dalla porta e dall'indirizzo di destinazione.

I firewall vengono utilizzati per gestire il traffico proveniente da client non protetti e diretto a server protetti e le risposte provenienti da tali server, così come il traffico di client del lato protetto verso i server del lato non protetto e le relative risposte.

È necessario impostare due macchine Dispatcher, una per bilanciare il carico del traffico non protetto su indirizzi firewall non protetti ed un'altra per bilanciare il carico del traffico protetto su indirizzi firewall protetti. Poiché entrambi i Dispatcher devono utilizzare il cluster e la porta jolly con diversi gruppi di indirizzi server, i due Dispatcher devono trovarsi su due stazioni di lavoro separate.

Utilizzo del cluster jolly con Caching Proxy per proxy trasparente

L'uso del cluster jolly con Caching Proxy per proxy trasparente si applica esclusivamente al componente Dispatcher. L'indirizzo cluster 0.0.0.0 viene utilizzato per specificare un cluster jolly.

La funzione cluster jolly consente di utilizzare Dispatcher per abilitare la funzione proxy trasparente per un server Caching Proxy che si trova sulla stessa macchina del Dispatcher. Questa è una funzione esclusiva di AIX, in quanto ci deve essere comunicazione dal componente dispatcher al componente TCP del sistema operativo.

Per abilitare questa funzione, è necessario avviare l'ascolto di Caching Proxy delle richieste client sulla porta 80. Configurare, quindi, un cluster jolly (0.0.0.0). Nel cluster jolly, configurare la porta 80. Sulla porta 80, configurare NFA della macchina Dispatcher come server unico. A questo punto, il traffico client verso qualsiasi indirizzo della porta 80 verrà distribuito sul server Caching Proxy in esecuzione sulla stazione di lavoro Dispatcher. La richiesta client verrà inviata tramite proxy, come di norma, e la risposta verrà restituita al client da Caching Proxy. In questo modo, il componente Dispatcher non esegue nessun bilanciamento del carico.

Utilizzo della porta jolly per indirizzare il traffico per una porta non configurata

La porta jolly può essere utilizzata per gestire il traffico che non è destinato ad una porta configurata esplicitamente. Uno di questi usi è per il bilanciamento del carico dei firewall. Un secondo uso è quello di garantire che il traffico, diretto su una porta non configurata, venga gestito in modo appropriato. Definendo una porta jolly senza server, si garantisce che qualsiasi richiesta a una porta, che non è stata configurata, verrà scartata anziché rimandata indietro al sistema operativo. Il numero di porta 0 (zero) indica una porta jolly, ad esempio:

dscontrol port add cluster:0

Porta jolly per la gestione del traffico FTP

Quando si configura un cluster per gestire l'FTP passivo e la porta jolly, l'FTP passivo utilizza per impostazione predefinita l'intero intervallo di porte TCP non privilegiato per la connessione dei dati. Ciò vuol dire che un client, con una connessione esistente che passa per un cluster di bilanciamento del carico e arriva a una porta di controllo FTP, avrà connessioni di controllo e le connessioni con numero di porta elevato (porta >1023), destinate allo stesso cluster, automaticamente indirizzate da Load Balancer verso lo stesso server della connessione di controllo FTP.

Se la porta jolly e la porta FTP sullo stesso cluster non hanno lo stesso gruppo di server, le applicazioni con numero di porta elevato (porta >1023) potrebbero non funzionare correttamente se un client utilizza una connessione di controllo FTP esistente. Quindi, non è consigliabile configurare diversi gruppi di server per le porte jolly e FTP sullo stesso cluster. Se si vuole questo tipo di scenario, impostare l'intervallo di porte passive del daemon FTP nella configurazione Load Balancer.

Rilevamento attacco di tipo Denial of service

Questa funzione è disponibile esclusivamente per il componente Dispatcher.

Dispatcher consente di rilevare potenziali attacchi di tipo "denial of service" e di avvisare gli amministratori tramite un avviso. Dispatcher fa questo analizzando le richieste in entrata per una grande quantità di connessioni TCP solo parzialmente aperte sui server, caratteristica comune agli attacchi di tipo denial of service. In un attacco di tipo denial of service, un sito riceve una grande quantità di pacchetti SYN provenienti da un gran numero di indirizzi IP di origine e numeri di porta di origine, ma il sito non riceve altri pacchetti per le connessioni TCP. Ciò determina un gran numero di connessioni TCP aperte a metà sui server e, nel tempo, i server possono diventare molto lenti e rifiutare nuove connessioni in arrivo.

Nota:
deve esserci traffico in entrata attraverso la porta e il cluster, che sono sotto attacco, affinché Dispatcher stabilisca la fine di un attacco di tipo denial of service. Questo perché Dispatcher non stabilisce la fine di un attacco fino a quando il traffico non inizia a fluire di nuovo.

Load Balancer fornisce uscite utente che attivano script personalizzabili in grado di avvisare l'amministratore di un possibile attacco di tipo denial of service. Il Dispatcher fornisce i file script di esempio nella seguente directory:

Sono disponibili i seguenti script:

Per poter eseguire i file, è necessario spostarli nella seguente directory e rimuovere l'estensione file ".sample":

Per implementare il rilevamento di attacchi DoS, impostare il parametro maxhalfopen sul comando dscontrol port, come riportato di seguito:

dscontrol port set 127.40.56.1:80 maxhalfopen 1000

Nell'esempio precedente, Dispatcher confronta il numero totale corrente di connessioni aperte a metà (per tutti i server che si trovano sul cluster 127.40.56.1 sulla porta 80) con il valore soglia uguale a 1000 (specificato dal parametro maxhalfopen). Se le connessioni correnti aperte a metà superano la soglia, viene effettuata una chiamata a uno script di avviso (halfOpenAlert). Quando il numero di connessioni aperte a metà scende sotto la soglia, si effettuata un chiamata a un altro script di avviso (halfOpenAlertDone) per indicare che l'attacco è finito.

Per stabilire come impostare il valore maxhalfopen: eseguire periodicamente (forse ogni 10 minuti) un report di connessioni aperte a metà (dscontrol port halfopenaddressreport cluster:port ) se il sito sta sostenendo un traffico che da normale tende ad essere intenso. Il report di connessioni aperte a metà restituisce il numero "totale di connessioni ricevute aperte a metà". È consigliabile impostare maxhalfopen su un valore che sia tra il 50 e il 200% superiore al numero massimo di connessioni aperte a metà sostenute dal sito.

Oltre ai dati statistici riportati, halfopenaddressreport genera anche delle voci nel log (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) per tutti gli indirizzi client (fino a 8000 coppie indirizzi circa) che hanno accesso a server con connessioni aperte a metà.

Nota:
è presente una trap di SNMP corrispondente agli script halfOpenAlert e halfOpenAlertDone. Se l'agente SNMP è configurato e in esecuzione, le trap corrispondenti verranno inviate nelle stesse condizioni che attivano gli script. Per maggiori informazioni sull'agente secondario SNMP, vedere Uso del protocollo SNMP (Simple Network Management Protocol) con il componente Dispatcher.

Per una maggiore protezione dagli attacchi di tipo denial of service per i server di backend, è possibile configurare porte e cluster jolly. In particolare, in ogni cluster configurato, aggiungere una porta jolly senza server. Aggiungere anche un cluster jolly con una porta jolly senza server. In questo modo, verranno scartati tutti i pacchetti che non sono indirizzati a una porta e a un cluster non jolly. Per informazioni sulle porte e sui cluster jolly, vedere Utilizzo del cluster jolly per combinare le configurazioni di server e Utilizzo della porta jolly per indirizzare il traffico per una porta non configurata.

Uso della registrazione binaria per analizzare le statistiche dei server

Nota:
la funzione registrazione binaria si applica esclusivamente ai componenti Dispatcher e CBR.

La registrazione binaria consente di memorizzare le informazioni sui server in file binari. È quindi possibile elaborare tali file per analizzare le informazioni sui server che sono state raccolte nel corso del tempo.

Nel log binario di ciascun server definito nella configurazione vengono memorizzate le seguenti informazioni.

Parte di queste informazioni viene richiamata dall'executor come parte del ciclo del gestore. Per questo, il gestore deve essere in esecuzione affinché le informazioni vengano registrate sui file di log binari.

Utilizzare il gruppo di comandi dscontrol binlog per configurare la registrazione binaria.

L'opzione start avvia la registrazione delle informazioni sui server sui log binari nella directory dei log. All'inizio di ogni nuova ora viene creato un log, il cui nome è composto dalla data e dall'ora.

L'opzione stop arresta la registrazione delle informazioni sui server sui log binari. Il servizio di registrazione viene arrestato per impostazione predefinita.

L'opzione set interval controlla la frequenza con cui le informazioni vengono scritte sui log. Il gestore invia le informazioni sui server al server di log a ogni intervallo specificato. Le informazioni vengono scritte sui log solo se l'intervallo di registrazione specificato, espresso in secondi, è scaduto dall'ultima volta che un record è stato scritto sul log. Per impostazione predefinita, l'intervallo di registrazione è impostato a 60 secondi. Le impostazioni dell'intervallo di invio delle informazioni da parte del gestore e dell'intervallo di registrazione interagiscono in una certa misura. Poiché la frequenza con cui il server dei log riceve le informazioni non è superiore all'intervallo di invio delle informazioni da parte del gestore, espresso in secondi, impostare l'intervallo di registrazione su un valore inferiore a quello dell'intervallo di invio delle informazioni da parte del gestore significa in pratica impostarlo sul suo stesso valore. Questa tecnica di registrazione consente di acquisire le informazioni sui server a qualsiasi granularità. È possibile acquisire tutte le modifiche alle informazioni sui server di cui viene a conoscenza il gestore per calcolare i pesi dei server. Tuttavia, probabilmente questa quantità di informazioni non è necessaria per analizzare l'utilizzo dei server e i relativi andamenti. La registrazione delle informazioni relative al server eseguita ogni 60 secondi fornisce delle istantanee di informazioni sul server nel corso del tempo. L'impostazione dell'intervallo di registrazione su un valore molto basso può generare quantitativi eccessivi di dati.

L'opzione set retention controlla per quanto tempo i file di log vengono mantenuti. I file di log, la cui ora di creazione precede il tempo specificato da questa opzione, vengono eliminati dal server dei log. Ciò avviene se il server di log viene richiamato dal gestore; quindi, arrestando il gestore, i vecchi file di log non verranno eliminati.

L'opzione status restituisce le impostazioni correnti del servizio di log. Tali impostazioni indicano se il servizio è stato avviato, definiscono l'intervallo e le ore di archiviazione.

Un programma Java e un file dei comandi di esempio sono stati forniti nella seguente directory:

L'esempio illustra come richiamare tutte le informazioni dai file di log e stamparle sullo schermo. Può essere personalizzato al fine di eseguire qualsiasi tipo di analisi sui dati. Un esempio che utilizza lo script e il programma forniti per dispatcher sarebbe:

dslogreport 2001/05/01 8:00 2001/05/01 17:00

per ottenere un report delle informazioni sui server del componente Dispatcher dalle 8:00 di mattina alle 5:00 del pomeriggio, nel giorno del primo maggio 2001. (Per CBR, utilizzare cbrlogreport.)

Utilizzo di un client posizionato

Solo i sistemi Linux supportano le configurazioni in cui un client si trova sulla stessa macchina di Load Balancer.

Le configurazioni client posizionate potrebbero non funzionare correttamente su altre piattaforme in quanto Load Balancer utilizza tecniche differenti per esaminare i pacchetti in entrata sui diversi sistemi operativi supportati. Nella maggior parte dei casi, su sistemi diversi da Linux, Load Balancer non riceve i pacchetti dalla macchina locale. Esso riceve i pacchetti in entrata solo dalla rete. Per questo motivo, le richieste effettuate all'indirizzo del cluster dalla macchina locale non sono ricevute da Load Balancer e non possono essere soddisfatte.