Versione 7.0
Numero documento GC31-6921-00
Nota |
---|
prima di utilizzare questo prodotto e le relative informazioni, leggere le informazioni generali contenute in Appendice E, Avvisi. |
Prima edizione (Giugno 2008)
Questa edizione si applica a:
e a tutte le modifiche e release successive, se non diversamente indicato nelle nuove edizioni.
Ordinare le pubblicazioni mediante il rappresentante IBM o gli uffici IBM del proprio paese.
(C) Copyright International Business Machines Corporation 2008. Tutti i diritti riservati.
Limitazioni previste per gli utenti del Governo degli Stati Uniti - L'uso, la duplicazione o la divulgazione sono limitati dal GSA ADP Schedule Contract con la IBM Corp.
Componente CBR (Content Based Routing)
Componente Cisco CSS Controller
Componente Nortel Alteon Controller
Funzioni e funzioni avanzate di Load Balancer
Gestione e risoluzione di problemi di Load Balancer
Questo manuale descrive come pianificare, installare, configurare, utilizzare e risolvere problemi relativi a IBM(R) WebSphere(R) Application Server Load Balancer per sistemi operativi AIX(R), HP-UX, Linux(TM), Solaris e Windows(R). Precedentemente, questo prodotto era chiamato Edge Server Network Dispatcher, SecureWay(R) Network Dispatcher, eNetwork Dispatcher e Interactive Network Dispatcher.
La guida alla gestione per Load Balancer è destinata ad amministratori di rete e di sistema esperti, con una buona conoscenza dei propri sistemi operativi e della fornitura di servizi Internet. Non è richiesta alcuna precedente esperienza di Load Balancer.
Questa guida non è destinata a supportare release precedenti di Load Balancer.
Il sito Web del centro informazioni Edge Components contiene un collegamento alla versione corrente di questa guida in formato HTML e PDF.
Per gli aggiornamenti più recenti di Load Balancer, visitare la pagina di assistenza del sito Web e collegarsi al sito Technote.
Per accedere a queste pagine Web e alle pagine correlate, utilizzare gli URL elencati in Documenti e siti Web correlati.
Le funzioni di accesso facilitato consentono a un utente con invalidità fisica, ad esempio con mobilità o vista limitata, di utilizzare agevolmente i prodotti software. Di seguito sono riportate le principali funzioni di accesso facilitato in Load Balancer:
I vostri commenti risultano di estrema importanza poiché consentono di fornire informazioni della massima accuratezza e qualità. Per fornire commenti su questa guida o su qualsiasi altra documentazione relativa a Edge Components:
Questa sezione presenta una panoramica di Load Balancer e dei sui componenti, una descrizione dettagliata delle funzioni di configurazione disponibili, un elenco dei requisiti hardware e software e istruzioni di installazione. Contiene i seguenti capitoli:
Questo capitolo fornisce una panoramica dei componenti di Load Balancer e comprende le seguenti sezioni:
Per un elenco dettagliato delle funzioni di configurazione fornite da ciascun componente di Load Balancer e decidere quali di esse devono essere utilizzate per la gestione della rete, vedere Gestione della rete: determinazione delle funzioni di Load Balancer da utilizzare.
Load Balancer è una soluzione software che consente di distribuire le richieste in entrata dei client tra diversi server. Quindi migliora le prestazioni dei server indirizzando le richieste delle sessioni TCP/IP a server diversi nell'ambito di un gruppo; in tal modo le richieste vengono bilanciate tra tutti i server. Questo bilanciamento del carico è trasparente agli utenti e alle altre applicazioni. Load Balancer è utile per applicazioni come i server di posta elettronica, i server World Wide Web, le query distribuite su database paralleli e altre applicazioni TCP/IP.
Quando viene utilizzato con i server Web, Load Balancer consente di ottimizzare le prestazioni di un sito dal momento che fornisce una soluzione potente, flessibile e scalabile per far fronte ai picchi di domanda. Se un sito Web non è in grado di gestire tutti i visitatori nei momenti di picco di domanda, utilizzare Load Balancer per individuare automaticamente il server migliore in grado di gestire le richieste in entrata, migliorando la soddisfazione dei clienti e i profitti dell'azienda.
Load Balancer è composto dai seguenti cinque componenti che possono essere usati separatamente o insieme per ottenere un bilanciamento del carico ottimale.
Per il protocollo HTTP, è possibile utilizzare la funzione di instradamento basato sul contenuto di Dispatcher per bilanciare il carico in base al contenuto delle richieste dei client. Il server verrà scelto associando l'URL a una regola specifica. L'instradamento basato sul contenuto di Dispatcher (metodo di inoltro cbr) non richiede Caching Proxy.
Per ulteriori informazioni sui componenti Dispatcher, CBR, Site Selector, Cisco CSS Controller e Nortel Alteon Controller, vedere Componenti di Load Balancer.
Il numero di utenti e di reti che utilizzano Internet sta crescendo in misura esponenziale. Questa crescita causa problemi di scalabilità che possono limitare l'accesso degli utenti ai siti più popolari.
Attualmente, gli amministratori dei siti utilizzano diversi metodi per ottimizzare gli accessi. Alcuni di questi metodi consentono agli utenti di scegliere un server diverso a caso, se la scelta precedente non ha consentito l'accesso o in caso di operazioni eccessivamente lente. Questo approccio è scomodo, noioso e inefficace. Un altro metodo è il round-robin standard, che prevedere che sia il server dei nomi di dominio (DNS) a scegliere di volta in volta i server che devono gestire le richieste. Questo approccio è migliore, ma ancora inefficace, poiché inoltra il traffico alla cieca, senza prendere in considerazione in alcun modo il carico di lavoro dei server. Inoltre, se un server subisce un guasto, il DNS continuerà a inviargli richieste.
La necessità di sviluppare una soluzione più potente ha prodotto Load Balancer. Questo prodotto offre numerosi benefici rispetto alle soluzioni precedenti e alla concorrenza.
Man mano che le richieste dei client aumentano, è possibile aggiungere dinamicamente altri server, consentendo quindi di supportare decine di milioni di richieste al giorno attraverso decine o centinaia di server.
Il bilanciamento del carico consente di ottimizzare l'uso dell'hardware di ciascun gruppo di server, riducendo al minimo le aree sensibili (hot-spot) che si vengono a creare frequentemente con il metodo round-robin standard.
Load Balancer utilizza i protocolli standard TCP/IP o UDP/IP. È possibile aggiungerlo alla rete esistente senza doverla modificare in alcun modo. È semplice da installare e configurare.
Utilizzando il metodo di inoltro del livello MAC, il componente Dispatcher controlla soltanto il traffico entrante dai client verso i server. Esso non gestisce il traffico uscente dai server verso i client. Ciò riduce significativamente il suo impatto sull'applicazione, confrontato con gli altri approcci, e migliora le prestazioni della rete.
I componenti Dispatcher, Cisco CSS Controller e Nortel Alteon Controller offrono una disponibilità elevata integrata grazie all'uso di una macchina di backup sempre pronta a entrare in funzione per gestire il bilanciamento del carico in caso di guasto al server principale. In caso di guasto a uno dei server, le richieste continueranno a essere soddisfatte dall'altro server. Ciò elimina la possibilità che qualsiasi server diventi un "single point of failure" e rende il sito altamente disponibile.
Per ulteriori informazioni, vedere Disponibilità elevata di Load Balancer
Insieme a Caching Proxy, il componente CBR può funzionare da proxy per le richieste HTTP e HTTPS (SSL) indirizzate a server specifici in base al contenuto richiesto. Ad esempio, se una richiesta contiene la stringa "/cgi-bin/" nella sezione directory dell'URL, e il nome del server indica un server locale, il componente CBR può indirizzare la richiesta al server migliore di un gruppo di server dedicati specificatamente alla gestione di richieste cgi.
Il componente Dispatcher fornisce inoltre un instradamento basato sul contenuto, ma non richiede che sia installato il Caching Proxy. Poiché l'instradamento basato sul contenuto fornito dal componente Dispatcher viene eseguito nel kernel man mano che i pacchetti vengono ricevuti, questa funzione risulta più veloce rispetto a quella fornita dal componente CBR. Il componente Dispatcher esegue l'instradamento basato sul contenuto per HTTP (utilizzando la regola di tipo "contenuto") e per HTTPS (utilizzando l'affinità ID di sessione SSL).
Il componente Dispatcher offre la funzione incorporata di disponibilità elevata, evitando di diventare un "single point of failure" della rete. Ciò viene realizzato grazie all'uso di una seconda macchina Dispatcher che controlla costantemente la macchina principale ed è sempre pronta a entrare in funzione in caso di guasto a quest'ultima. Dispatcher fornisce anche la disponibilità elevata reciproca che consente a due macchine di essere contemporaneamente principali e secondarie (backup) l'una rispetto all'altra. Vedere Configurazione della disponibilità elevata.
Utilizzando la configurazione a due livelli con una macchina Dispatcher che bilancia il carico del traffico tra più server equipaggiati con CBR, è possibile ottenere un livello di disponibilità elevata per questi componenti.
I controller sono caratterizzati da disponibilità elevata dal momento che è stata eliminata la possibilità di diventare un "single point of failure". Un controller su una macchina può essere configurato come principale e un altro, su una macchina diversa, può essere configurato come secondaria o di backup. Il controller di backup controlla costantemente il controller principale e si tiene sempre pronto a fornire agli switch i pesi dei server, in caso di guasto alla macchina principale. Per ulteriori informazioni, vedere Disponibilità elevata.
Questo capitolo fornisce una panoramica dei componenti di Load Balancer e comprende le seguenti sezioni:
Per un elenco dettagliato delle funzioni di configurazione fornite da ciascun componente di Load Balancer e decidere quali di esse devono essere utilizzate per la gestione della rete, vedere Gestione della rete: determinazione delle funzioni di Load Balancer da utilizzare.
I cinque componenti di Load Balancer sono: Dispatcher, Content Based Routing (CBR), Site Selector, Cisco CSS Controller e Nortel Alteon Controller. Load Balancer è un prodotto flessibile che consente di utilizzare i componenti separatamente o insieme, a seconda della configurazione del sito. Questa sezione descrive brevemente ciascuno di questi componenti.
Il componente Dispatcher bilancia il traffico tra i server tramite una combinazione univoca di bilanciamento del carico e software di gestione. Dispatcher è, inoltre, in grado di rilevare un server che non funziona e di deviare il traffico a lui indirizzato. Dispatcher supporta i protocolli HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, SIP e ogni altra applicazione basata sul protocollo TCP o UDP senza informazioni di stato.
Tutte le richieste client inviate alla macchina Dispatcher sono indirizzate al server considerato più adatto in base ai pesi che vengono impostati dinamicamente. È possibile utilizzare i valori predefiniti per questi pesi o attribuire loro dei valori diversi durante il processo di configurazione.
Dispatcher offre tre metodi di inoltro (specificati sulla porta):
Il componente Dispatcher è il fattore chiave che consente di gestire in modo stabile ed efficiente una rete ampia e scalabile di server. Con Dispatcher, è possibile collegare molti server singoli in modo da farli sembrare un solo server virtuale. Quindi il sito sembrerà avere un unico indirizzo IP. Dispatcher funziona indipendentemente da un DNS (Domain Name Server); tutte le richieste vengono inviate all'indirizzo IP della macchina Dispatcher.
Dispatcher offre considerevoli vantaggi nel bilanciamento del carico di traffico sui server organizzati in cluster consentendo di gestire i siti in modo stabile ed efficace.
La figura 1 mostra una rappresentazione fisica del sito che utilizza una configurazione di rete Ethernet. È possibile installare la macchina Dispatcher senza dover apportare modifiche fisiche alla rete. Dopo che la richiesta client è stata indirizzata al server più adatto da Dispatcher, se si utilizza il metodo di inoltro MAC, la risposta viene inviata direttamente dal server al client senza coinvolgere Dispatcher.
Figura 2. Esempio di un sito che utilizza Dispatcher e Metric Server per gestire server
La figura 2 illustra un sito in cui tutti i server risiedono in una rete locale. Il componente Dispatcher viene utilizzato per inoltrare le richieste; Metric Server viene utilizzato per fornire alla macchina Dispatcher le informazioni relative al carico del sistema.
In questo esempio, il daemon di Metric Server viene installato su ciascun server di backend. È possibile utilizzare Metric Server con il componente Dispatcher o con un altro componente di Load Balancer.
Figura 3. Esempio di un sito che utilizza Dispatcher per gestire server locali e remoti
Il supporto per rete geografica di Dispatcher consente di utilizzare sia i server locali che i server remoti (server situati su sottoreti diverse). La figura 3 mostra una configurazione dove un server locale (Dispatcher 1) funge da punto d'ingresso di tutte le richieste. Il Dispatcher locale distribuisce le richieste tra i server locali (ServerA, ServerB, ServerC) e sul Dispatcher remoto (Dispatcher 2), che a sua volta bilancerà il carico tra i server locali di sua competenza (ServerG, ServerH, ServerI).
Quando si usa il metodo di inoltro NAT di Dispatcher o il supporto GRE, è possibile realizzare il supporto per rete geografica anche senza utilizzare un Dispatcher sul sito remoto (dove si trovano ServerD, ServerE e ServerF). Per ulteriori informazioni, vedere NAT/NAPT Dispatcher (metodo di inoltro nat) e Supporto GRE (Generic Routing Encapsulation).
CBR funziona con Caching Proxy per inviare le richieste client ai server HTTP o HTTPS (SSL) specificati. Consente di gestire i dettagli di memorizzazione nella cache per recuperare più rapidamente i documenti Web con una larghezza di banda della rete inferiore. CBR con Caching Proxy esamina le richieste HTTP utilizzando tipi di regole specifici.
CBR consente di specificare un gruppo di server che gestisca una richiesta in base all'espressione regolare corrispondente al contenuto della richiesta. Poiché CBR consente di specificare più server per ciascun tipo di richiesta, il carico delle richieste può essere bilanciato per ottimizzare i tempi di risposta ai client. Inoltre, CBR rileva eventuali malfunzionamenti di un server del gruppo e interrompe l'instradamento delle richieste destinate a quel server. L'algoritmo di bilanciamento del carico utilizzato dal componente CBR è lo stesso dell'algoritmo utilizzato dal componente Dispatcher.
Quando Caching Proxy riceve una richiesta, questa viene confrontata con le regole che sono state definite nel componente CBR. Se viene rilevata una corrispondenza, uno dei server associati a quella regola viene scelto per gestire la richiesta. Quindi, esegue la propria abituale elaborazione per inviare la richiesta al server prescelto.
CBR dispone delle stesse funzioni di Dispatcher, eccetto la funzione di disponibilità elevata, l'agente secondario SNMP, il supporto per rete geografica e alcuni altri comandi di configurazione.
Caching Proxy deve essere in esecuzione prima che il componente CBR possa iniziare a bilanciare il carico delle richieste client.
Figura 4. Esempio di un sito che utilizza CBR per gestire server locali
La figura 4 mostra la rappresentazione logica di un sito in cui CBR viene utilizzato come proxy per gestire alcuni tipi di contenuti provenienti dai server locali. Il componente CBR utilizza Caching Proxy per inoltrare le richieste client (HTTP o HTTPS) ai server in base al contenuto dell'URL.
Site Selector agisce come un server dei nomi che funziona in associazione con altri server dei nomi in un DNS per eseguire il bilanciamento del carico tra un gruppo di server utilizzando le misure e i pesi raccolti. È possibile creare una configurazione del sito per consentire il bilanciamento del carico del traffico tra un gruppo di server basato sul nome dominio utilizzato per una richiesta del client.
Un client invia una richiesta di risoluzione di un nome dominio a un server dei nomi presente nella rete. Il server dei nomi inoltra la richiesta alla macchina Site Selector. Quindi, Site Selector risolve il nome dominio nell'indirizzo IP di uno dei server configurati per quel nome del sito. Site Selector restituisce l'indirizzo IP del server selezionato al server dei nomi. Il server dei nomi restituisce l'indirizzo IP al client.
Metric Server è un componente di monitoraggio del sistema di Load Balancer che deve essere installato su ciascun server della configurazione che si intende sottoporre a bilanciamento del carico. Insieme a Metric Server, Site Selector può monitorare il livello di attività su un server, rilevare un server che sta elaborando un carico inferiore rispetto agli altri e individuare un server in errore. Il carico misura il traffico sul server. La personalizzazione dei file di script delle metriche del sistema consente di controllare il tipo di misurazioni utilizzate per valutare il calcolo. È possibile configurare Site Selector in base all'ambiente, prendendo in considerazione fattori quali la frequenza degli accessi, il numero totale degli utenti e i tipi di accesso (ad esempio, query brevi e lunghe oppure carichi che richiedono molto spazio sulla CPU).
La figura 5 illustra un sito in cui il componente Site Selector viene utilizzato per rispondere alle richieste. Server1, Server2 e Server3 sono server locali. Server4, Server5 e Server6 sono server remoti.
Un client invia una richiesta di risoluzione di un nome dominio a un server dei nomi client. Il server dei nomi client inoltra la richiesta tramite DNS alla macchina Site Selector (percorso 1). Quindi, Site Selector risolve il nome dominio nell'indirizzo IP di uno dei server. Site Selector restituisce l'indirizzo IP del server selezionato al server dei nomi client. Il server dei nomi restituisce l'indirizzo IP al client.
Dopo che il client ha ricevuto l'indirizzo IP del server, instrada le richieste dell'applicazione direttamente al server selezionato (percorso 2).
Cisco CSS Controller forma una soluzione complementare insieme agli switch della serie CSS 11000 di Cisco. La soluzione combinata unisce le funzioni di instradamento basato sul contenuto e di inoltro del potente pacchetto CSS serie 11000 con i sofisticati algoritmi di raccolta delle informazioni di Load Balancer per determinare i dati sul carico e la disponibilità del servizio (database o applicazione del server di backend). La funzione Cisco CSS Controller utilizza l'algoritmo di calcolo dei pesi, gli advisor standard e personalizzati di Load Balancer e Metric Server per determinare le metriche, lo stato e il carico del servizio. Queste informazioni vengono utilizzate da Cisco CSS Controller per generare i pesi del servizio che vengono poi inviati a Cisco CSS Switch per la selezione del servizio più adatto, per l'ottimizzazione del carico e per la tolleranza agli errori.
Cisco CSS Controller utilizza molti criteri, tra cui:
Quando Cisco CSS Switch, senza Cisco CSS Controller, determina lo stato di un servizio che fornisce contenuti, utilizza i tempi di risposta per le richieste di contenuto o altre misurazioni della rete. Al contrario, con Cisco CSS Controller, queste attività vengono trasferite da Cisco CSS Switch su Cisco CSS Controller. Cisco CSS Controller influenza il peso del servizio o la capacità di trasferire contenuti e attiva o sospende un servizio quando il servizio diventa di nuovo disponibile o non è più disponibile.
Cisco CSS Controller:
Cisco CSS Controller, insieme a Cisco CSS Switch, offre la migliore soluzione possibile che combina la funzione di scambio dei contenuti in base alla velocità di connessione con un sistema di raccolta delle informazioni sulle applicazioni più sofisticato, tolleranza agli errori e ottimizzazione del carico del servizio. Cisco CSS Controller fa parte di una soluzione complementare globale tra Cisco CSS Switch e IBM WebSphere Application Server Load Balancer.
Nortel Alteon Controller insieme alla famiglia di switch Web di Nortel Alteon fornisce una soluzione complementare che combina le funzionalità e la velocità di inoltro del pacchetto degli switch con i sofisticati algoritmi per la raccolta delle informazioni di Load Balancer per determinare i pesi dei server.
Nortel Alteon Controller consente di sviluppare advisor personalizzati che siano in grado di eseguire valutazioni più intelligenti e consapevoli della disponibilità e del carico delle applicazioni utilizzate per distribuire i servizi.
Metric Server fornisce informazioni sul carico del sistema, quali le informazioni sull'utilizzo della CPU e della memoria e un framework per sviluppare le misurazioni di carico personalizzate del sistema.
Nortel Alteon Controller raccoglie molti tipi di informazioni metriche al fine di determinare i pesi per i server che verranno sottoposti al bilanciamento del carico da parte dei Nortel Alteon Web Switch, tra cui:
Nortel Alteon Controller utilizza SNMP per comunicare con lo switch. Le informazioni sulla configurazione, sullo stato e sulla connessione vengono richiamate dallo switch. Una volta che i pesi dei server sono stati calcolati dal controller, vengono impostati sullo switch. Lo switch utilizza i pesi impostati dal controller per selezionare il server più adatto a gestire le richieste client per un servizio.
Figura 7. Esempio di un sito che utilizza Nortel Alteon Controller per gestire server locali
È possibile gestire il controller tramite un'interfaccia browser, una GUI remota o una riga comandi remota.
Nortel Alteon Controller insieme alla famiglia di switch Web di Nortel Alteon offre la migliore soluzione possibile che combina la funzione di scambio dei contenuti in base alla velocità di connessione con informazioni più sofisticate sulle applicazioni e un'ottimizzazione del carico dei server. Nortel Alteon Controller fa parte di una soluzione complementare tra la famiglia di switch Web di Nortel Alteon e IBM WebSphere.
Questo capitolo elenca le funzioni di configurazione dei componenti di Load Balancer per facilitare la scelta delle opzioni da utilizzare per la gestione della rete:
Per ottimizzare il bilanciamento del carico tra i server e garantire che venga scelto il server più adatto, vedere:
Dispatcher supporta il bilanciamento del carico tra i server per HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, SIP e e ogni altra applicazione basata sul protocollo TCP o UDP senza informazioni sullo stato.
_ Per eseguire la configurazione di Load Balancer da una macchina diversa da quella dove risiede Load Balancer, vedere Gestione remota di Load Balancer.
_ Per eseguire Dispatcher sulla stessa macchina di un server Web per cui si sta effettuando il bilanciamento del carico, vedere Utilizzo di server posizionati.
_ Per utilizzare Dispatcher per eliminare la limitazione che un server diventi un "single point-of-failure", vedere Disponibilità elevata semplice e Disponibilità elevata reciproca.
Quando si esegue il bilanciamento del carico sul traffico SSL (HTTPS):
_ Per garantire che il client utilizzi lo stesso server SSL per connessioni multiple, vedere Funzione di affinità di Load Balancer.
_ Per garantire che il client utilizzi lo stesso server per il traffico HTTP e SSL, vedere Affinità multiporta.
_ Per garantire che il client utilizzi lo stesso server SSL per connessioni multiple, vedere Funzione di affinità di Load Balancer.
_ Per garantire che un gruppo di client utilizzi lo stesso server per connessioni multiple, vedere Maschera indirizzo affinità (stickymask).
_ Per eliminare un server dalla configurazione (ad esempio, a scopi di gestione) senza interrompere il traffico client, vedere Gestione della disattivazione delle connessioni server.
Per indirizzare i client a gruppi di server diversi configurati per lo stesso indirizzo Web, è possibile aggiungere delle regole alla configurazione di Dispatcher. Per ulteriori informazioni, vedere Configurazione del bilanciamento del carico in base alle regole.
_ Per indirizzare i client a gruppi di server diversi in base all'indirizzo IP origine del client, vedere Utilizzo delle regole basate sull'indirizzo IP del client.
_ Per indirizzare i client a gruppi di server diversi in base alla porta del client, vedere Utilizzo delle regole basate sulla porta client.
_ Per indirizzare i client a gruppi di server diversi in base all'ora del giorno, vedere Utilizzo delle regole basate sull'ora del giorno.
_ Per indirizzare i client ai server in base ai bit TOS (Type of Service) dei pacchetti di rete, vedere Utilizzo delle regole basate sul tipo di servizio (TOS).
_ Per indirizzare i client a gruppi di server diversi in base al traffico del sito:
_ Utilizzando le connessioni al secondo, vedere Utilizzo delle regole basate sulle connessioni al secondo.
_ Utilizzando un numero totale di connessioni attive, vedere Utilizzo delle regole basate sul numero totale di connessioni attive.
_ Riservando e condividendo la larghezza di banda per indirizzi Web diversi, vedere Utilizzo delle regole basate sulla larghezza di banda riservata e condivisa.
_ Garantendo che il traffico venga misurato correttamente per il proprio gruppo di server, vedere Opzione di valutazione dei server per le regole.
_ Per indirizzare il sovraccarico di traffico a un gruppo di server predefinito (ad esempio, i server che avvisano che il sito è occupato), vedere Utilizzo di regole il cui valore è sempre true.
_ Per escludere l'affinità dei client e garantire che un client non rimanga aderente a un server sovraccarico, vedere ignora affinità di porta.
Per garantire che i client SSL ritornino sullo stesso server SSL, in base all'ID SSL della richiesta client
_ Vedere la pagina ***.
Per indirizzare i client HTTP a gruppi di server diversi utilizzando le regole di corrispondenza dei contenuti URL della richiesta client, per ulteriori informazioni, vedere Instradamento basato sul contenuto di Dispatcher (metodo di inoltro cbr) e Utilizzo delle regole basate sul contenuto delle richieste.
_ Per distinguere tra URL specifici e rispettive applicazioni di servizi, vedere Suddivisione in partizioni dei server: server logici configurati su un server fisico (indirizzo IP).
_ Per garantire che i client ritornino allo stesso server quando le richieste contengono dei contenuti simili in più connessioni utilizzando i cookie creati dai propri server Web, vedere Affinità cookie passivo.
_ Per bilanciare il carico del traffico Web sui server Caching Proxy che consentono la memorizzazione nella cache di contenuti univoci su ciascun server (aumentando quindi le dimensioni della cache del sito ed eliminando la memorizzazione ridondante di contenuti su più macchine), vedere Affinità URI.
Il vantaggio del metodo di inoltro cbr di Dispatcher rispetto all'uso del componente CBR consiste nella rapidità di risposta alle richieste client. Inoltre, il metodo di inoltro cbr di Dispatcher non richiede l'installazione e l'uso di Caching Proxy.
Se la rete prevede traffico SSL totalmente protetto (client a server), il vantaggio di utilizzare il componente CBR (in combinazione con Caching Proxy) consiste nella possibilità di elaborare la codifica/decodifica richiesta al fine di eseguire l'instradamento basato sul contenuto. Per connessioni totalmente protette, il metodo di inoltro cbr di Dispatcher può essere configurato solo con l'affinità ID SSL in quanto non è in grado di elaborare la codifica/decodifica per eseguire l'instradamento basato sul contenuto sull'URL della richiesta client.
Il bilanciamento del carico per una rete geografica può essere ottenuto utilizzando metodi diversi.
_ Per bilanciare il carico sui server remoti utilizzando la funzione per la rete geografica di Dispatcher, vedere: Configurazione del supporto di Dispatcher per una rete geografica e Supporto GRE (Generic Routing Encapsulation).
_ Per bilanciare il carico sui server remoti utilizzando il metodo di inoltro nat di Dispatcher, vedere NAT/NAPT di Dispatcher (metodo di inoltro nat).
_ Per bilanciare il carico di un indirizzo Web su più server daemon sulla stessa macchina, dove ciascun daemon rimane in ascolto su una porta univoca, vedere NAT/NAPT di Dispatcher (metodo di inoltro nat).
_ Per indirizzare il traffico di Dispatcher su una rete diversa da quella su cui viene indirizzato il traffico dei client (per migliorare le prestazioni riducendo i conflitti sulla rete esterna), vedere Utilizzo di una configurazione di rete privata.
_ Per combinare indirizzi Web multipli in un'unica configurazione, vedere Utilizzo del cluster jolly per combinare le configurazioni di server.
_ Per bilanciare il carico dei firewall, vedere Utilizzo di cluster jolly per bilanciare il carico dei firewall.
_ Per indirizzare il traffico a tutte le porte di destinazione, vedere Utilizzo della porta jolly per indirizzare il traffico per una porta non configurata.
_ Per individuare possibili attacchi "denial of service", vedere Rilevamento attacco di tipo Denial of service.
_ Per analizzare il traffico del server, vedere Utilizzo della registrazione binaria per analizzare le statistiche dei server.
_ Per generare avvisi quando i server vengono contrassegnati come attivi o inattivi, vedere Uso degli script per generare un avviso o registrare un malfunzionamento dei server.
CBR integra il bilanciamento del carico con Caching Proxy di WebSphere Application Server per inviare le richieste dei client ai server HTTP o HTTPS (SSL) specificati. Per utilizzare CBR, Caching Proxy deve essere installato e configurato sulla stessa macchina. Per informazioni su come configurare Caching Proxy perché utilizzi CBR, vedere Fase 1. Configurazione di Caching Proxy per l'uso di CBR.
Il componente CBR (o il metodo di inoltro cbr di Dispatcher) consente di offrire i seguenti vantaggi ai client:
_ Bilanciare il carico delle richieste client per tipi diversi di contenuti su gruppi di server. (Vedere Bilanciamento del carico di richieste per tipi diversi di contenuto).
_ Migliorare il tempo di risposta dividendo in maniera ottimale i contenuti del sito tra i server Web. (Vedere Suddivisione del contenuto del sito per ottimizzare i tempi di risposta).
_ Garantire un traffico client ininterrotto in caso di malfunzionamento di un server assegnando ciascun tipo di contenuto a più server. (Vedere Backup del contenuto del server Web).
Se la rete richiede la gestione di traffico SSL totalmente protetto (client a server), il vantaggio di utilizzare il componente CBR (in combinazione con Caching Proxy) consiste nella possibilità di elaborare la codifica/decodifica SSL al fine di eseguire l'instradamento basato sul contenuto.
Per connessioni SSL totalmente protette, il metodo di inoltro cbr di Dispatcher può essere configurato solo con l'affinità ID SSL in quanto non è in grado di elaborare la codifica/decodifica per eseguire l'instradamento basato sul contenuto sull'URL della richiesta client.
Per il traffico HTTP, il vantaggio del metodo di inoltro cbr di Dispatcher rispetto all'uso del componente CBR consiste nella rapidità di risposta alle richieste client. Inoltre, il metodo di inoltro cbr di Dispatcher non richiede l'installazione e l'uso di Caching Proxy.
_ Per eseguire la configurazione di Load Balancer da una macchina diversa da quella dove risiede Load Balancer, vedere Gestione remota di Load Balancer.
_ È possibile eseguire il componente CBR sulla stessa macchina di un server per cui si sta effettuando il bilanciamento del carico. Per ulteriori informazioni, vedere Utilizzo di server posizionati.
_ Per migliorare l'utilizzo della CPU utilizzando più processi Caching Proxy, vedere Uso di più processi Caching Proxy per migliorare l'utilizzo della CPU.
Per consentire l'instradamento basato sul contenuto per il traffico SSL:
_ Utilizzando connessioni protette su entrambi i lati (client-proxy e proxy-server), vedere Bilanciamento del carico tra connessioni protette (SSL).
_ Utilizzando le connessioni protette solo sul lato client-proxy, vedere Bilanciamento del carico client-proxy in SSL e proxy-server in HTTP.
_ Per distinguere tra URL specifici e rispettive applicazioni di servizi, vedere Suddivisione in partizioni dei server: server logici configurati su un server fisico (indirizzo IP).
Per indirizzare i client a gruppi di server diversi configurati per lo stesso indirizzo Web, è possibile aggiungere delle regole alla configurazione di CBR. Per ulteriori informazioni, vedere Configurazione del bilanciamento del carico in base alle regole.
_ Per indirizzare i client a gruppi di server diversi in base al contenuto dell'URL richiesto, vedere Utilizzo delle regole basate sul contenuto delle richieste.
_ Per indirizzare i client a gruppi di server diversi in base all'indirizzo IP origine del client, vedere Utilizzo delle regole basate sull'indirizzo IP del client.
_ Per indirizzare i client a gruppi di server diversi in base all'ora del giorno, vedere Utilizzo delle regole basate sull'ora del giorno.
_ Per indirizzare i client a gruppi di server diversi in base al traffico del sito:
Utilizzando le connessioni al secondo, vedere Utilizzo delle regole basate sulle connessioni al secondo.
Utilizzando un numero totale di connessioni attive, vedere Utilizzo delle regole basate sul numero totale di connessioni attive.
_ Per indirizzare il sovraccarico di traffico a un gruppo di server predefinito (ad esempio, i server che avvisano che il sito è occupato), vedere Utilizzo di regole il cui valore è sempre true.
_ Per escludere l'affinità dei client e garantire che un client non rimanga aderente a un server sovraccarico, vedere ignora affinità di porta.
_ Per garantire che il client utilizzi lo stesso server per connessioni multiple, vedere Funzione di affinità di Load Balancer.
_ Per eliminare un server dalla configurazione (ad esempio, a scopi di gestione) senza interrompere il traffico client, vedere Gestione della disattivazione delle connessioni server.
_ Per garantire che i client ritornino allo stesso server quando le richieste contengono dei contenuti simili in più connessioni senza fare affidamento sui cookie creati dai propri server Web, vedere Affinità cookie attivo.
_ Per garantire che i client ritornino allo stesso server quando le richieste contengono dei contenuti simili in più connessioni utilizzando i cookie creati dai propri server Web, vedere Affinità cookie passivo.
_ Per bilanciare il carico del traffico Web sui server Caching Proxy che consentono la memorizzazione nella cache di contenuti univoci su ciascun server (aumentando quindi le dimensioni della cache del sito ed eliminando la memorizzazione ridondante di contenuti su più macchine), vedere Affinità URI.
_ Per eliminare le limitazioni "single point of failure" nella rete utilizzando Dispatcher in una configurazione a due livelli con CBR, vedere Disponibilità elevata di Load Balancer.
_ Per analizzare il traffico del server, vedere Utilizzo della registrazione binaria per analizzare le statistiche dei server.
_ Per generare avvisi quando i server vengono contrassegnati come attivi o inattivi, vedere Uso degli script per generare un avviso o registrare un malfunzionamento dei server.
Site Selector bilancia il carico di una richiesta di servizio dei nomi in un gruppo di server.
_ Per eseguire la configurazione di Load Balancer da una macchina diversa da quella dove risiede Load Balancer, vedere Gestione remota di Load Balancer.
È possibile eseguire il componente Site Selector sulla stessa macchina di un server per cui si sta effettuando il bilanciamento del carico, senza ulteriori fasi di configurazione.
_ La funzione di disponibilità elevata è disponibile tramite le metodologie DNS (Domain Name System) utilizzando più Site Selector ridondanti, a condizione che siano presenti la corretta configurazione del server dei nomi parent e i normali metodi di ripristino DNS. Esempi dei normali metodi di ripristino DNS sono: nuova trasmissione delle query e nuovi tentativi di trasferimento zone.
_ Per eliminare le limitazioni "single point of failure" nella rete utilizzando Dispatcher in una configurazione a due livelli con Site Selector, vedere Disponibilità elevata di Load Balancer.
_ Per garantire che il client utilizzi lo stesso server per più richieste del server dei nomi, vedere Funzione di affinità di Load Balancer.
_ Per garantire ai client l'affinità di un server utilizzando il metodo DNS di impostazione del valore TTL (Time To Live), vedere Considerazioni TTL.
Per indirizzare le richieste client a gruppi di server diversi per la risoluzione di un nome di dominio, è possibile aggiungere delle regole alla configurazione di Site Selector. Per ulteriori informazioni, vedere Configurazione del bilanciamento del carico in base alle regole.
_ Per indirizzare i client a gruppi di server diversi in base all'indirizzo IP origine del client, vedere Utilizzo delle regole basate sull'indirizzo IP del client.
_ Per indirizzare i client a gruppi di server diversi in base all'ora del giorno, vedere Utilizzo delle regole basate sull'ora del giorno.
_ Per indirizzare i client a gruppi di server diversi in base ai valori metrici del carico del gruppo di server, vedere:
_ Per indirizzare il sovraccarico di traffico a un gruppo di server predefinito (ad esempio, i server che avvisano che il sito è occupato), vedere Utilizzo di regole il cui valore è sempre true.
Site Selector può essere eseguito su una rete locale (LAN) o su una rete geografica (WAN).
In un ambiente WAN:
_ Per bilanciare il carico di richieste dei server dei nomi client utilizzando un metodo di selezione round-robin, non sono necessarie ulteriori fasi di configurazione.
_ Per prendere in considerazione la prossimità di rete del server dei nomi client ai server che forniscono l'applicazione richiesta (i server di destinazione), vedere Uso della funzione di prossimità della rete.
_ Per generare avvisi quando i server vengono contrassegnati come attivi o inattivi, vedere Uso degli script per generare un avviso o registrare un malfunzionamento dei server.
Cisco CSS Controller potenzia la funzione di bilanciamento del carico dei server eseguita dagli switch Cisco sulla base di informazioni più accurate sui sistemi e sulle applicazioni. Il controller utilizza metriche più sensibili alle applicazioni e al sistema per calcolare i pesi dei server dinamicamente. I pesi vengono forniti allo switch tramite SNMP. Lo switch utilizza i pesi durante l'elaborazione delle richieste client con conseguente ottimizzazione del carico dei server e una maggiore tolleranza agli errori.
Per ottimizzare il bilanciamento del carico tra i server e garantire che venga scelto il server più adatto, vedere:
_ Ottimizzazione del bilanciamento del carico fornito da Load Balancer
_ Advisor e Creazione di advisor personalizzati (personalizzabili)
_ Per eseguire la configurazione di Load Balancer da una macchina diversa da quella dove risiede Load Balancer, vedere Gestione remota di Load Balancer.
_ È possibile eseguire il componente Cisco CSS Controller sulla stessa macchina di un server per cui si sta effettuando il bilanciamento del carico, senza ulteriori fasi di configurazione.
_ Per eliminare limitazioni "single point of failure" nella rete, Cisco CSS Switch e Cisco CSS Controller dispongono della funzione di disponibilità elevata. Per lo switch, le funzioni di disponibilità elevata sono rese possibili dal protocollo di ridondanza CSS. Per Cisco CSS Controller, viene utilizzato un protocollo proprietario che consente la configurazione hot-standby di due controller.
Per ulteriori informazioni sulla configurazione della funzione di disponibilità elevata, vedere Disponibilità elevata.
_ Per analizzare il traffico del server, vedere Utilizzo della registrazione binaria per analizzare le statistiche dei server.
_ Per generare avvisi quando i server vengono contrassegnati come attivi o inattivi, vedere Uso degli script per generare un avviso o registrare un malfunzionamento dei server.
Nortel Alteon Controller potenzia la funzione di bilanciamento del carico dei server eseguita dagli switch Nortel Alteon sulla base di informazioni più accurate sui sistemi e sulle applicazioni. Il controller utilizza metriche più sensibili alle applicazioni e al sistema per calcolare i pesi dei server dinamicamente. I pesi vengono forniti allo switch tramite SNMP. Lo switch utilizza i pesi durante l'elaborazione delle richieste client con conseguente ottimizzazione del carico dei server e una maggiore tolleranza agli errori.
Per ottimizzare il bilanciamento del carico tra i server e garantire che venga scelto il server più adatto, vedere:
_ Ottimizzazione del bilanciamento del carico fornito da Load Balancer
_ Advisor e Creazione di advisor personalizzati (personalizzabili)
_ Per eseguire la configurazione di Load Balancer da una macchina diversa da quella dove risiede Load Balancer, vedere Gestione remota di Load Balancer.
_ È possibile eseguire il componente Nortel Alteon Controller sulla stessa macchina di un server per cui si sta effettuando il bilanciamento del carico, senza ulteriori fasi di configurazione.
_ Per eliminare limitazioni "single point of failure" nella rete, Nortel Alteon Web Switch e Nortel Alteon Controller dispongono della funzione di disponibilità elevata. Per utilizzare la funzione di disponibilità elevata con lo switch, è necessario utilizzare il protocollo di ridondanza per le connessioni ai server e per i servizi. Nortel Alteon Controller fornisce la funzione di disponibilità elevata utilizzando un protocollo proprietario che consente una configurazione hot-standby di due controller.
Per ulteriori informazioni sulla configurazione della funzione di disponibilità elevata, vedere Disponibilità elevata.
_ Per analizzare il traffico del server, vedere Utilizzo della registrazione binaria per analizzare le statistiche dei server.
_ Per generare avvisi quando i server vengono contrassegnati come attivi o inattivi, vedere Uso degli script per generare un avviso o registrare un malfunzionamento dei server.
Questo capitolo descrive come installare Load Balancer utilizzando gli strumenti di assemblaggio del sistema e i requisiti di tutti i sistemi operativi supportati.
Per le istruzioni di installazione con il programma di configurazione del prodotto, fare riferimento al documento Informazioni di base, pianificazione e installazione per Edge Components.
Java 2 SDK viene installato automaticamente con Load Balancer su tutte le piattaforme.
Se si sta eseguendo la migrazione da una precedente versione di Load Balancer, o se si sta reinstallando un sistema operativo, prima di procedere all'installazione, salvare tutti i file di configurazione o i file script precedenti di Load Balancer.
In base al tipo di installazione, non sono forniti tutti i package di Load Balancer elencati in questa sezione.
Per i requisiti hardware e software, compresi i browser supportati, fare riferimento alla seguente pagina Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
La tabella 1 riporta le immagini di installp per Load Balancer e l'ordine di installazione consigliato mediante lo strumento di installazione dei package del sistema.
Tabella 1. Immagini installp in AIX
Base | ibmlb.base.rte |
Amministrazione (con messaggi) |
|
Driver unità | ibmlb.lb.driver |
Licenza | ibmlb.lb.license |
Componenti di Load Balancer (con messaggi) |
|
Documentazione (con messaggi) |
|
Metric Server | ibmlb.ms.rte |
Dove componente può essere: disp (Dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) o nal (Nortel Alteon Controller). Selezionare facoltativamente i componenti che si desidera installare.
Dove lingua può essere:
Il package della documentazione contiene soltanto la lingua Inglese. Le versioni tradotte della documentazione di Load Balancer si trovano sul sito Web al seguente indirizzo: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Se è già stata installata una precedente versione, disinstallare la copia di prima di installare la versione aggiornata. In primo luogo, accertarsi che tutti gli executor e i server siano stati arrestati. Disinstallare, quindi, l'intero prodotto, immettere installp -u ibmlb (o il nome precedente, ad esempio, intnd). Per disinstallare determinati fileset, elencarli invece di indicare il nome del package.
Nel momento in cui si disinstalla il prodotto, è possibile scegliere di installare uno o tutti i componenti elencati di seguito:
Attenersi alla procedura elencata di seguito per installare Load Balancer in AIX:
Utilizzo di SMIT:
Una volta completato il comando, premere Done, quindi selezionare Exit Smit dal menu Exit oppure premere F12. Se si utilizza SMITTY, premere F10 per uscire dal programma.
Uso della riga comandi:
Se si esegue l'installazione da un CD, immettere il seguente comando per caricarlo:
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Fare riferimento alla tabella riportata
di seguito per determinare i comandi da immettere per installare i package Load Balancer desiderati per
AIX:
Tabella 2. Comandi install in AIX
Base | installp -acXgd dispositivo ibmlb.base.rte |
Amministrazione (con messaggi) | installp -acXgd dispositivo ibmlb.admin.rte ibmlb.msg.lingua.admin |
Driver unità | installp -acXgd dispositivo ibmlb.lb.driver |
Licenza | installp -acXgd dispositivo ibmlb.lb.license |
Componenti di Load Balancer (con messaggi). Include: Dispatcher, CBR, Site Selector, Cisco CSS Controller e Nortel Alteon Controller | installp -acXgd dispositivo ibmlb.componente.rte ibmlb.msg.lingua.lb |
Documenti (con messaggi) | installp -acXgd dispositivo ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd dispositivo ibmlb.ms.rte |
dove per dispositivo si intende:
Accertarsi che la colonna dei risultati del riepilogo contenga SUCCESS per ciascun componente di Load Balancer che si sta installando (APPLYing). Non proseguire finché tutti i componenti desiderati non verranno installati.
installp -ld dispositivo
dove per dispositivo si intende:
Per disinstallare il CD, immettere:
unmount /cdrom
lslpp -h | grep ibmlb
Se il prodotto è stato installato completamente, questo comando restituisce quanto segue:
ibmlb.base.rte ibmlb.admin.rte ibmlb.lb.driver ibmlb.lb.license ibmlb.<component>.rte ibmlb.doc.rte ibmlb.ms.rte ibmlb.msg.lingua.admin ibmlb.msg.en_US.doc ibmlb.msg.lingua.lb
I percorsi di installazione di Load Balancer sono:
Per la gestione remota di Load Balancer, mediante RMI (Remote Method Invocation), è necessario installare i package amministrazione, base, componenti e licenza sul client. Per informazioni sul metodo RMI, vedere RMI (Remote Method Invocation).
Per i requisiti hardware e software, compresi i browser supportati, fare riferimento alla seguente pagina Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
In questa sezione viene illustrato come installare Load Balancer su sistemi HP-UX mediante il CD del prodotto.
Prima di avviare la procedura di installazione, verificare di essere in possesso dell'autorizzazione root per installare il software.
Se è già stata installata una precedente versione, disinstallarne la copia prima di installare la versione aggiornata. Per prima cosa, accertarsi di avere arrestato sia l'executor che il server. Per disinstallare, quindi, Load Balancer, vedere Istruzioni per la disinstallazione dei package.
La tabella 3 visualizza un elenco di nomi di package di installazione
per Load Balancer e l'ordine necessario per installarli mediante lo strumento di
installazione package del sistema.
Tabella 3. Dettagli sull'installazione del package HP-UX per Load
Balancer
Descrizione package | Nome package HP-UX |
Base | ibmlb.base |
Amministrazione e messaggi | ibmlb.admin ibmlb.nlv-lang |
Licenza di Load Balancer | ibmlb.lic |
Componenti Load Balancer | ibmlb.componente |
Documentazione | ibmlb.doc |
Metric Server | ibmlb.ms |
Note:
|
La procedura riportata di seguito illustra le operazioni necessarie al completamento di questa attività.
su - root Password: password
swinstall -s /origine nome_package
in cui origine è il percorso directory assoluto di ubicazione del package e nome_package è il nome del package.
Il comando riportato di seguito installa il package di base di Load Balancer (ibmlb.base), se l'installazione avviene dalla root del CD:
swinstall -s /origine ibmlb.base
Per installare tutti i package per Load Balancer emettere il seguente comando, se l'installazione avviene dalla directory root del CD:
swinstall -s /origine ibmlb
Emettere il comando swlist per elencare tutti i package installati. Ad esempio,
swlist -l fileset ibmlb
Utilizzare il comando swremove per disinstallare i package. I package devono essere rimossi nell'ordine inverso rispetto all'installazione. Ad esempio, emettere i seguenti comandi:
swremove ibmlb
Per disinstallare un singolo package, ad esempio il componente Dispatcher:
swremove ibmlb.disp
Per i requisiti hardware e software, compresi i browser supportati, fare riferimento alla seguente pagina Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
In questa sezione viene illustrato come installare Load Balancer su sistemi Linux mediante il CD del prodotto.
Prima di avviare la procedura di installazione, verificare di essere in possesso dell'autorizzazione root per installare il software.
Se è già stata installata una precedente versione, disinstallarne la copia di prima di installare la versione aggiornata. In primo luogo, accertarsi che tutti gli executor e i server siano stati arrestati. Quindi per disinstallare completamente il prodotto, immettere rpm -e pkgname. Durante la disinstallazione, invertire l'ordine utilizzato per l'installazione, verificando che i package di amministrazione vengano disinstallati per ultimi.
Per installare Load Balancer:
L'immagine di installazione è un file nel formato eLBLX-versione:tar.z.
Di seguito è riportato un elenco dei package RPM installabili.
Dove --
Il package della documentazione contiene soltanto la lingua Inglese. Le versioni tradotte della documentazione di Load Balancer si trovano sul sito Web al seguente indirizzo: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Il comando di installazione dei package deve essere immesso dalla stessa directory in cui risiedono i file RPM. Per installare ciascun package, immettere il seguente comando: rpm -i package.rpm.
Sistemi Red Hat Linux: a causa di un problema noto con Red Hat Linux, sarà necessario eliminare i file RPM _db* o si verificherà un errore.
rpm -qa | grep ibmlb
L'installazione del prodotto completo genera un elenco analogo al seguente:
Per la gestione remota di Load Balancer, mediante RMI (Remote Method Invocation), è necessario installare i package amministrazione, base, componenti e licenza sul client. Per informazioni sul metodo RMI, vedere RMI (Remote Method Invocation).
Per informazioni sui requisiti hardware e software, compresi i browser supportati, fare riferimento alla seguente pagina Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
In questa sezione viene illustrato come installare Load Balancer su sistemi Solaris mediante il CD del prodotto.
Prima di avviare la procedura di installazione, verificare di essere in possesso dell'autorizzazione root per installare il software.
Se è già stata installata una precedente versione, disinstallarne la copia prima di installare la versione aggiornata. In primo luogo, verificare di aver arrestato tutti gli executor e i server. Per disinsstallare, quindi, Load Balancer, immettere pkgrm pkgname.
Per installare Load Balancer:
Sul prompt dei comandi, immettere pkgadd -d pathname , dove per pathname si intende il nome dell'unità CD-ROM o la directory sul disco rigido dove risiede il package, ad esempio: pkgadd -d /cdrom/cdrom0/.
Di seguito è riportato un elenco dei package visualizzati e l'ordine di installazione consigliato.
Il package della documentazione (ibmlbdoc) contiene soltanto la lingua Inglese. Le versioni tradotte della documentazione di Load Balancer si trovano sul sito Web al seguente indirizzo: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Se si desidera installare tutti i package, è sufficiente immettere "all" e premere Invio. Se si desidera installare solo alcuni componenti, immettere i nomi corrispondenti ai package da installare, separati da uno spazio o da una virgola, quindi premere Invio. Potrebbe essere richiesto di modificare le autorizzazioni sulle directory o file esistenti. Premere Invio o rispondere "yes". È necessario installare i package dei prerequisiti (l'installazione rispetta l'ordine alfabetico anziché l'ordine dei prerequisiti). Se si sceglie l'opzione "all", rispondere affermativamente ("yes") a tutti i prompt visualizzati per completare l'installazione correttamente.
Se si desidera installare soltanto il componente Dispatcher con la documentazione e Metric Server, è necessario installare i seguenti package: ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc e ibmlbms.
Per la gestione remota di Load Balancer, mediante RMI (Remote Method Invocation), è necessario installare i package amministrazione, base, componenti e licenza sul client. Per informazioni sul metodo RMI, vedere RMI (Remote Method Invocation).
I percorsi di installazione di Load Balancer sono:
Per informazioni sui requisiti hardware e software, ompresi i browser supportati, fare riferimento alla seguente pagina Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
In questa sezione viene illustrato come installare Load Balancer su sistemi Windows mediante il CD del prodotto.
Viene fornita una scelta di package da installare:
Per la gestione remota di Load Balancer, mediante RMI (Remote Method Invocation), è necessario installare i package amministrazione, base, componenti e licenza sul client. Per informazioni sul metodo RMI, vedere RMI (Remote Method Invocation).
Limitazioni: La versione Windows di Load Balancer non può essere installata sulla stessa macchina di IBM Firewall.
Prima di iniziare la procedura di installazione, verificare di aver effettuato il collegamento come amministratore o come utente con privilegi amministrativi.
Se è già stata installata una precedente versione, disinstallarne la copia di prima di installare la versione aggiornata. Per effettuare la disinstallazione utilizzando Installazione applicazioni, attenersi alla seguente procedura:
Per installare Load Balancer:
E:\setup
I percorsi di installazione di Load Balancer sono:
Come procurarsi un aggiornamento. Ci si può procurare un fix pack di Edge Components per sistemi AIX, HP-UX, Linux, Solaris o Microsoft Windows nei seguenti supporti:
Per informazioni su sistemi operativi supportati, fare riferimento al sito di supporto IBM per i i requisiti di sistema dettagliati di WebSphere Application Server.
È possibile trovare il link ai refresh pack o ai fix pack per Edge Components in Recommended downloads for WebSphere Application Server del sito IBM Support.
Prima di installare il refresh pack o il fix pack, arrestare e disinstallare le versioni esistenti di Load Balancer che sono precedenti alla versione cui si sta eseguendo l'aggiornamento.
dscontrol executor stop
Load Balancer Executor può essere ancora in esecuzione se dsserver viene arrestato. Se si riceve un messaggio che dsserver non è in esecuzione, avviare dsserver ed emettere di nuovo il comando.
dsserver stop
Tabella 4. Comandi specifici del sistema per disinstallare Load Balancer
Comandi specifici del sistema per disinstallare Load Balancer | |
---|---|
Piattaforma | Comandi |
AIX | Disinstallare tutti i package Load Balancer mediante i seguenti comandi:
installp -u ibmlb |
HP-UX | Disinstallare tutti i package Load Balancer mediante i seguenti comandi:
swremove ibmlb |
Linux |
|
Solaris |
|
Se Load Balancer non è installato, viene richiesto solo di installare il file di licenze per Load Balancer, che è lb70Full.LIC, prima di installare un refresh pack o un fix pack. È possibile procurarsi la licenza installando il package delle licenze per Load Balancer.
Per installare un fix pack o un refresh pack:
Tabella 5. Comandi specifici del sistema per installare un refresh o un fix pack
Comandi specifici del sistema per installare un refresh o un fix pack | |
---|---|
Sistema | Comandi |
AIX |
|
HP-UX |
swinstall -s /origine nome_package dove origine è la directory di ubicazione per il package e nome_package è il nome del package. Per installare, ad esempio, il package di base dalla directory corrente, emettere il seguente comando: swinstall -s /lb ibmlb.base |
Linux |
rpm -iv nome_package dove nome_package è il nome del package. Il seguente comando, ad esempio, installa tutti i package per Load Balancer quando i package risiedono nella directory corrente: rpm -iv ibmlb*.rpm
|
Solaris |
pkgadd -d pathname nome_package dove pathname è la directory di ubicazione per il package e nome_package è il nome del package. Per installare, ad esempio, il package di gestione dalla directory corrente, emettere il seguente comando: pkgadd -d . ibmlbadm |
Questa tabella elenca tutti i package consegnati con Edge Components e il rispettivo ordine di installazione. Installare i package inclusi nel refresh o fix pack conformemente all'ordine specificato nella seguente tabella.
Elenco di package | |
Componenti installati | Aggiornare i package (elencati genericamente) in questo ordine |
|
|
Documentazione su Edge Components | doc-lang |
Utilizzare il programma di installazione per Edge Components da aggiornare come segue
Per la maggior parte dei componenti, quando viene rimosso il refresh pack o il fix pack, i file di configurazione vengono salvati nella directory oldfiles/component. È possibile utilizzare i file di configurazione con la versione reinstallata del prodotto per mantenere la configurazione della patch nella versione antecedente alla patch. Per il componente Load Balancer, salvare manualmente i file di configutazione per mantenere la configurazione della patch.
Questa sezione fornisce informazioni per una rapida configurazione, considerazioni sulla pianificazione e descrive i metodi di configurazione del componente Dispatcher di Load Balancer. Contiene i seguenti capitoli:
Questo esempio di configurazione rapida mostra, appunto, come configurare tre stazioni di lavoro collegate localmente mediante il metodo di inoltro mac del componente Dispatcher, per bilanciare il traffico tra i due server Web. La configurazione è essenzialmente la stessa di quella utilizzata per bilanciare il traffico di altre applicazioni UDP stateless o TCP.
Figura 8. Una configurazione semplice di Dispatcher locale
Il metodo di inoltro mac è il metodo predefinito con cui Dispatcher bilancia il carico delle richieste in entrata sul server e il server restituisce la risposta direttamente al client. Per ulteriori informazioni sul metodo di inoltro MAC del componente Dispatcher, vedere Instradamento a livello MAC del Dispatcher (metodo di inoltro mac).
Per l'esempio di avvio rapido, è necessario disporre di tre stazioni di lavoro e di quattro indirizzi IP. Una stazione di lavoro è la macchina del Dispatcher mentre le altre due sono i server Web. Ciascun server Web richiede un indirizzo IP. La stazione di lavoro Dispatcher richiede due indirizzi: l'indirizzo di non inoltro (NFA) e l'indirizzo cluster (l'indirizzo su cui effettuare il bilanciamento del carico) che verranno forniti ai client per poter accedere al sito Web.
Stazione di lavoro | Nome | Indirizzo IP |
---|---|---|
1 | server1.Intersplashx.com | 9.47.47.101 |
2 | server2.Intersplashx.com | 9.47.47.102 |
3 | server3.Intersplashx.com | 9.47.47.103 |
Netmask = 255.255.255.0 |
Ciascuna stazione di lavoro contiene solo una scheda interfaccia di rete Ethernet standard.
Name= www.Intersplashx.com IP=9.47.47.104
Aggiungere un alias www.Intersplashx.com all'interfaccia loopback su server2.Intersplashx.com e server3.Intersplashx.com.
ifconfig lo0 alias www.Intersplashx.com netmask 255.255.255.255
ifconfig lo0:1 plumb www.Intersplashx.com netmask 255.255.255.0 up
A questo punto, tutte le fasi di configurazione necessarie sulle stazioni di lavoro del server Web sono state portate a termine.
Con il Dispatcher, è possibile creare una configurazione dalla riga comandi, con la configurazione guidata o mediante l'interfaccia utente grafica (GUI).
Se si utilizza la riga comandi:
dscontrol executor start
dscontrol cluster add www.Intersplashx.com
dscontrol port add www.Intersplashx.com:80
dscontrol server add www.Intersplashx.com:80:server2.Intersplashx.com
dscontrol server add www.Intersplashx.com:80:server3.Intersplashx.com
dscontrol executor configure www.Intersplashx.com
dscontrol manager start
Dispatcher ora eseguirà il bilanciamento del carico in base alle prestazioni del server.
dscontrol advisor start http 80
Il Dispatcher garantisce, a questo punto, che le richieste client non verranno inviate a un server Web in errore.
La configurazione di base, con i server collegati localmente, è ora completa.
Verificare se la configurazione è in esecuzione:
Per informazioni sull'uso della GUI di Dispatcher, vedere GUI e Appendice A, GUI: istruzioni generali.
Per informazioni sulla configurazione guidata, vedere Configurazione mediante la procedura guidata.
Esistono molti modi con cui configurare Load Balancer per supportare il sito. Se si dispone di un solo nome host per il sito a cui tutti i clienti vorranno connettersi, è possibile definire un unico cluster di server. Per ognuno di questi server configurare una porta attraverso la quale Load balancer comunica. Vedere la Figura 9.
Figura 9. Esempio Dispatcher configurato con un unico cluster e 2 porte
In questo esempio relativo al componente Dispatcher, un cluster viene definito all'indirizzo www.productworks.com. Questo cluster ha due porte: la porta 80 per HTTP e la porta 443 per SSL. Un client che effettua una richiesta all'indirizzo http://www.productworks.com (porta 80) viene indirizzato a un server diverso da quello di un client che effettua la richiesta all'indirizzo https://www.productworks.com (porta 443).
Se il sito da gestire è molto grande, con un gran numero di server dedicati a ciascun protocollo supportato, potrebbe essere indicato un altro tipo di configurazione di Load Balancer. In questo caso, è possibile definire un cluster per ciascun protocollo con un'unica porta ma con molti server, come mostrato nella Figura 10.
Figura 10. Esempio di Dispatcher configurato con due cluster, ognuno con una
porta
In questo esempio relativo al componente Dispatcher, vengono definiti due cluster: www.productworks.com per la porta 80 (HTTP) e www.testworks.com per la porta 443 (SSL).
È necessario ricorrere a un terzo tipo di configurazione di Load Balancer se il sito gestito deve ospitare i contenuti di più aziende o dipartimenti, a ciascuno dei quali i client accedono utilizzando URL diversi. In questo caso, è possibile definire un cluster per ogni società o dipartimento e, di conseguenza, decidere le porte su cui ricevere le connessioni a quell'URL, come illustrato nella Figura 11.
Figura 11. Esempio
di Dispatcher configurato con 2 cluster, ognuno con 2 porte
In questo esempio relativo al componente Dispatcher, vengono definiti due cluster con la porta 80 per HTTP e la porta 23 per Telnet per ogni sito all'indirizzo www.productworks.com e www.testworks.com.
Questo capitolo descrive i fattori che un responsabile della pianificazione di rete deve considerare prima di installare e configurare il componente Dispatcher.
Questo capitolo include le seguenti sezioni:
Dispatcher consiste delle seguenti funzioni:
L'uso del gestore è facoltativo. Tuttavia, se il gestore non viene utilizzato, il bilanciamento del carico verrà eseguito utilizzando la pianificazione con il metodo round-robin basata sui pesi dei server correnti, mentre gli advisor non saranno disponibili.
Dispatcher fornisce, inoltre, degli advisor che non scambiano informazioni specifiche sul protocollo, come l'advisor DB2(R) che riporta lo stato dei server DB2 e l'advisor ping che comunica se il server risponde o meno a un ping. Per un elenco completo degli advisor, vedere Elenco di advisor.
È possibile anche scrivere advisor personalizzati (vedere Creazione di advisor personalizzati (personalizzabili)).
L'uso degli advisor è facoltativo ma consigliato.
Le tre funzioni chiave del Dispatcher (executor, gestore e advisor) interagiscono per bilanciare e distribuire le richieste in entrata tra i server. Insieme al bilanciamento del carico delle richieste, l'executor controlla il numero delle nuove connessioni, delle connessioni attive e delle connessioni terminate. L'executor esegue inoltre la raccolta di dati inutili di connessioni completate o ripristinate e comunica tali informazioni al gestore.
Il gestore raccoglie le informazioni provenienti dall'executor, dagli advisor e da un programma di monitoraggio del sistema, quale Metric Server. In base alle informazioni ricevute, il gestore regola il peso delle macchine server su ciascuna porta e comunica all'executor i nuovi pesi da utilizzare nel bilanciamento delle nuove connessioni.
Gli advisor controllano ciascun server sulla porta assegnata, per determinare il tempo di risposta del server e la disponibilità, quindi, comunicano queste informazioni al gestore. Anche gli advisor controllano se un server è attivo o meno. Senza il gestore e gli advisor, l'executor esegue una pianificazione con il metodo round-robin basata sui pesi attuali dei server.
Con il Dispatcher, è possibile selezionare uno dei tre metodi di inoltro specificati a livello di porta: inoltro MAC, NAT/NAPT o CBR (content-based routing).
Utilizzando il metodo di inoltro MAC del Dispatcher (il metodo di inoltro predefinito), il Dispatcher bilancia il carico delle richieste in entrata al server selezionato e il server restituisce la risposta direttamente al client senza coinvolgere il Dispatcher. Con questo metodo di inoltro, il Dispatcher controlla soltanto il traffico entrante dai client verso i server Esso non gestisce il traffico uscente dai server verso i client. Ciò riduce significativamente il suo impatto sull'applicazione e migliora le prestazioni della rete.
Il metodo di inoltro può essere selezionato quando si aggiunge una porta con il comando dscontrol port add cluster:port method valore. Il valore del metodo di inoltro predefinito è mac. Il parametro method può essere specificato solo quando si aggiunge la porta. Dopo aver aggiunto la porta, non è possibile modificare l'impostazione del metodo di inoltro. Per ulteriori informazioni, vedere dscontrol port -- configura le porte.
Limitazione per Linux: Linux impiega un modello basato su host per comunicare gli indirizzi hardware agli indirizzi IP utilizzando ARP. Questo modello non è compatibile con i requisiti del server backend o del server con disponibilità elevata, per quel che riguarda il metodo di inoltro mac di Load Balancer. Vedere Alternative di creazione alias loopback Linux quando si utilizza l'inoltro mac di Load Balancer, che contiene un numero di soluzioni per modificare il funzionamento del sistema Linux in modo da renderlo compatibile con l'inoltro mac di Load Balancer.
Limitazione su Linux quando si utilizzano server zSeries o S/390 : esistono delle limitazioni quando si utilizzano server zSeries o S/390 che hanno schede OSA (Open System Adapter). Per soluzioni possibili, vedere Problema: su Linux, esistono delle limitazioni quando si utilizzano server zSeries o S/390 che hanno schede Open System Adapter (OSA).
Utilizzando la capacità NAT (Network Address Translation) o NAPT (Network Address Port Translation) del Dispatcher si elimina la limitazione che prevede di dover posizionare i server sottoposti a bilanciamento del carico su una rete collegata localmente. Se si desidera collegare server situati in ubicazioni remote, è possibile utilizzare la tecnica del metodo di inoltro NAT anziché la tecnica di incapsulamento GRE/WAN. È anche possibile utilizzare la funzione NAPT per accedere a più daemon server che risiedono su ciascuna macchina sottoposta a bilanciamento del carico, dove ogni daemon è in ascolto su una specifica porta.
È possibile configurare un server con più daemon in due modi differenti:
Questa applicazione funziona bene con protocolli di applicazioni di livello superiore come HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, ecc.
Limitazioni:
Saranno necessari tre indirizzi IP per la macchina Dispatcher - indirizzo nfa, cluster e mittente. Per implementare NAT/NAPT, effettuare quanto segue (vedere anche Operazioni di esempio per configurare i metodi di inoltro nat o cbr del Dispatcher):
dscontrol server add cluster:port:server mapport valore returnaddress rtrnaddress router rtraddress
Mappa il numero di porta (specifico per il Dispatcher) di destinazione della richiesta client sul numero di porta del server che il Dispatcher utilizza per bilanciare il carico delle richieste del client. Il parametro mapport consente a Load Balancer di ricevere una richiesta del client su una porta e di trasmetterla a una porta differente sulla macchina server. Con il parametro mapport è possibile bilanciare il carico delle richieste di un client su una macchina server che potrebbe disporre di più daemon server attivi. Il valore predefinito per mapport è il numero di porta di destinazione della richiesta client.
L'indirizzo mittente è un indirizzo univoco o un nome host configurato sulla macchina Dispatcher. Il Dispatcher utilizza l'indirizzo mittente come indirizzo di origine quando bilancia il carico delle richieste del client al server. In questo modo, il server restituisce il package alla macchina Dispatcher, anziché inviarlo direttamente al client. (Il Dispatcher inoltra quindi il package IP al client.) Quando si aggiunge il server, è necessario specificare il valore dell'indirizzo mittente. Non è possibile modificare l'indirizzo mittente, a meno il server non venga prima rimosso quindi riaggiunto. L'indirizzo mittente non può essere uguale all'indirizzo cluster, server o NFA.
Quando si utilizzano i metodi di inoltro nat o cbr, definire un indirizzo di ritorno per le comunicazioni tra Load Balancer e i server di back-end. Il numero di connessioni che Load Balancer può mantenere attive con il server di back-end è limitato dal numero di indirizzi di ritorno definiti. Load Balancer utilizza porte che si basano solo sull'indirizzo di ritorno, non sulla combinazione di indirizzo di ritorno e server. Quando tutte le porte disponibili sono in uso, connessioni aggiuntive non riescono. In un ambiente occupato, utilizzare indirizzi di ritorno per evitare una diminuzione di porte disponibili.
L'indirizzo del router al server remoto. Se questo è un server collegato in locale, immettere l'indirizzo del server, a meno che questo non si trovi sulla stessa macchina di Load Balancer. In tal caso, continuare a utilizzare l'indirizzo reale del router.
Il componente Dispatcher consente di eseguire l'instradamento basato sul contenuto per HTTP (utilizzando la regola di tipo "contenuto") e HTTPS (utilizzando l'affinità ID di sessione SSL) senza la necessità di utilizzare Caching Proxy. Per il traffico HTTP e HTTPS, il metodo di inoltro cbr del componente Dispatcher può offrire un instradamento più rapido rispetto a quello offerto dal componente CBR, che richiede Caching Proxy.
Per HTTP: la selezione del server per l'instradamento basato sul contenuto di Dispatcher è basata sui contenuti di un'intestazione URL o HTTP. La configurazione avviene utilizzando la regola di tipo "contenuto". Quando si configura la regola contenuto, specificare il "modello" della stringa di ricerca e un insieme di server per la regola. Durante l'elaborazione di una nuova richiesta in entrata, questa regola confronta la stringa specificata con l'URL del client o con l'intestazione HTTP specificata nella richiesta client.
Se il Dispatcher trova la stringa nella richiesta client, inoltra la richiesta a uno dei server nella regola. Il Dispatcher trasmette quindi i dati della risposta dal server al client (metodo di inoltro "cbr").
Se il Dispatcher non trova la stringa nella richiesta client, non seleziona alcun server dall'insieme dei server nella regola.
Per HTTPS (SSL): l'instradamento basato sul contenuto (cbr) del Dispatcher bilancia il carico in base al campo sessione ID SSL della richiesta client. Con SSL, una richiesta client contiene l'ID sessione SSL di una sessione precedente e i server mantengono una memoria cache delle connessioni SSL precedenti. L'affinità di sessione ID SSL del Dispatcher consente al client e al server di stabilire una nuova connessione utilizzando i parametri di sicurezza della precedente connessione al server. Eliminando la rinegoziazione dei parametri di sicurezza SSL, come le chiavi condivise e gli algoritmi di codifica, i server salvano i cicli della CPU e il client riceve una risposta più velocemente. Per abilitare l'affinità ID di sessione SSL: il tipo protocol specificato per la porta deve essere SSL e la porta stickytime deve essere impostata su un valore diverso da zero. Quando il valore di stickytime viene superato, il client potrebbe essere inviato a un server diverso dal precedente.
Saranno necessari tre indirizzi IP per la macchina Dispatcher - indirizzo nfa, cluster e mittente. Per implementare l'instradamento basato sul contenuto di Dispatcher, (vedere anche Operazioni di esempio per configurare i metodi di inoltro nat o cbr del Dispatcher):
dscontrol server add cluster:port:server mapport valore returnaddress rtrnaddress router rtraddress
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern modello
Dove modello specifica il modello da utilizzare per il tipo di regola content. Per ulteriori informazioni sul tipo di regola del contenuto, vedere Utilizzo delle regole basate sul contenuto delle richieste. Per ulteriori informazioni sulle espressioni valide per modello, vedere Appendice B, Sintassi della regola di contenuto (modello).
Figura 12. Esempio per l'utilizzo di metodi di inoltro nat o cbr di Dispatcher
Saranno necessari almeno tre indirizzi IP per la macchina Dispatcher. Per la Figura 12, le operazioni riportate di seguito sono indispensabili per configurare al minimo i metodi di inoltro nat o cbr del Dispatcher:
1.Avviare l'executor dscontrol executor start 2.Definire il gateway client dscontrol executor set clientgateway 1.2.3.5 NOTA: se la sottorete non dispone di un router locale, è necessario configurare una macchina per eseguire l'inoltro IP e utilizzarla come clientgateway. Consultare la documentazione del sistema operativo per determinare come attivare l'inoltro IP. 3.Definire l'indirizzo cluster dscontrol cluster add 1.2.3.44 4.Configurare l'indirizzo cluster dscontrol executor configure 1.2.3.44 5.Definire la porta con un metodo nat o cbr dscontrol port add 1.2.3.44:80 method nat o dscontrol port add 1.2.3.44:80 method cbr protocol http 6.Configurare un indirizzo di ritorno alias su Load Balancer (utilizzando la scheda ethernet 0) NOTA: sui sistemi Linux, non è necessario creare un alias per l'indirizzo di restituzione, se si utilizza l'inoltro nat su una macchina posizionata. dscontrol executor configure 10.10.10.99 o utilizzare il comando ifconfig (solo per Linux o UNIX): AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0 HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up 7.Definire i server backend dscontrol server add 1.2.3.4:80:192.10.10.10 router 10.10.10.6 returnaddress 10.10.10.99
Il gateway client (1.2.3.5) è l'indirizzo router 1 tra Load Balancer e il client. Il router (10.10.10.6) è l'indirizzo router 2 tra Load balancer e il server backend. In caso di dubbi sull'indirizzo clientgateway o router 2, è possibile utilizzare un programma denominato traceroute con l'indirizzo client (o server) per determinare l'indirizzo router. La sintassi esatta di questo programma differisce in base al sistema operativo utilizzato. È preferibile consultare la documentazione del sistema operativo per ulteriori informazioni circa questo programma.
Se il server si trova sulla stessa rete di Load Balancer (ossia, non vengono restituiti router mediante traceroute), specificare l'indirizzo server come indirizzo router. Se, tuttavia, il server si trova sulla stessa macchina di Load Balancer, nel campo del router va immesso l'indirizzo del router e non l'indirizzo del server. L'indirizzo router è l'indirizzo utilizzato nel comando "server add" sulla macchina Load Balancer al punto 7.
Con la suddivisione in partizioni del server, è possibile distinguere ulteriormente tra URL particolari e relative applicazioni specifiche. Ad esempio, un server Web può supportare pagine JSP, pagine HTML, file GIF, richieste database e così via. Load Balancer consente ora di suddividere in partizioni un server specifico di una porta o di un cluster in più server logici. In questo modo, l'utente può fornire informazioni su uno specifico servizio su una macchina per rilevare se un motore servlet o una richiesta database è in esecuzione più velocemente o non lo è affatto.
La suddivisione in partizioni del server consente a Load Balancer di individuare, ad esempio, se il servizio HTML sta servendo le pagine velocemente ma la connessione al database è interrotta. Ciò consente di distribuire il carico in base a un carico di lavoro differenziando i diversi servizi, piuttosto che calcolare solo i pesi dei vari server.
La suddivisione in partizioni del server può essere utile se utilizzata insieme agli advisor HTTP e HTTPS. Ad esempio, con un server HTML che gestisce pagine HTML, GIF e JSP, se si definisce una volta (mediante aggiunta) il server nella porta 80, si riceve solo un valore di carico per l'intero server HTTP. Ciò può essere fuorviante in quanto è possibile che il servizio GIF non sia operativo sul server. Il Dispatcher continua a inoltrare pagine GIF al server ma il client riscontra un timeout o un errore.
Se si definisce il server tre volte (ad esempio, ServerHTML, ServerGIF, ServerJSP) nella porta e si definisce il parametro advisorrequest del server con una stringa differente per ciascun server logico, è possibile eseguire una query relativa allo stato di uno specifico servizio sul server. ServerHTML, ServerGIF e ServerJSP rappresentano tre server logici che sono stati suddivisi in partizioni da un unico server fisico. Per ServerJSP, è possibile definire la stringa advisorrequest per eseguire una query relativa al servizio sulla macchina che gestisce le pagine JSP. Per ServerGIF, è possibile definire la stringa advisorrequest per eseguire la query relativa al servizio GIF. Infine, per ServerHTML, si definisce la stringa advisorrequest per eseguire una query relativa al servizio HTML. In questo modo, se il client non riceve risposta da advisorrequest alla query relativa al servizio GIF, il Dispatcher contrassegnerà il server logico (ServerGIF) come inattivo, mentre gli altri due potrebbero essere attivi. Il Dispatcher non inoltra altre pagine GIF al server fisico ma può ancora inviare richieste JSP e HTML al server.
Per ulteriori informazioni sul parametro advisorrequest, vedere Configurazione dell'advisor HTTP o HTTPS utilizzando l'opzione richiesta/risposta (URL).
All'interno della configurazione del Dispatcher, è possibile rappresentare un server fisico o un server logico utilizzando la gerarchia cluster:port:server. Il server può essere un indirizzo IP univoco della macchina (server fisico) espresso come nome simbolico o in formato indirizzo IP. Altrimenti, se si definisce il server per rappresentare un server suddiviso in partizioni, è necessario specificare un indirizzo server risolvibile per il server fisico sul parametro address del comando dscontrol server add. Per ulteriori informazioni, vedere dscontrol server -- configura i server.
Segue un esempio di suddivisione in partizioni di server fisici in server logici, per gestire differenti tipi di richieste.
Cluster: 1.1.1.1 Port: 80 Server: A (IP address 1.1.1.2) HTML server Server: B (IP address 1.1.1.2) GIF server Server: C (IP address 1.1.1.3) HTML server Server: D (IP address 1.1.1.3) JSP server Server: E (IP address 1.1.1.4) GIF server Server: F (IP address 1.1.1.4) JSP server Rule1: /*.htm Server: A Server: C Rule2: /*.jsp Server: D Server: F Rule3: /*.gif Server: B Server: E
In questo esempio, il server 1.1.1.2 è suddiviso in 2 server logici: "A" (che gestisce le richieste HTML) e "B" (che gestisce le richieste GIF). Il server 1.1.1.3 è suddiviso in 2 server logici: "C" (che gestisce le richieste HTML) e "D" (che gestisce le richieste JSP). Il server 1.1.1.4 è suddiviso in 2 server logici: "E" (che gestisce le richieste GIF) e "F" (che gestisce le richieste JSP).
Figura 13. Esempio di un Dispatcher che utilizza la disponibilità elevata semplice
La funzione di disponibilità elevata implica l'uso di una seconda macchina Dispatcher. La prima macchina Dispatcher esegue il bilanciamento del carico per tutto il traffico client, come in una configurazione a un solo Dispatcher. La seconda macchina Dispatcher controlla lo "stato" della prima e assume il controllo delle attività di bilanciamento del carico se rileva un malfunzionamento sulla prima macchina Dispatcher.
A ciascuna delle due macchine viene assegnato un ruolo specifico, ossia principale o di backup. La macchina principale invia continuamente i dati di connessione alla macchina secondaria. Mentre la macchina principale è attiva (ed esegue il bilanciamento del carico), la macchina di backup si trova in standby, aggiornata di continuo e pronta ad assumere il controllo, se necessario.
Le sessioni di comunicazione tra le due macchine vengono denominate heartbeat. Gli heartbeat consentono a ciascuna macchina di controllare lo stato dell'altra.
Se la macchina secondaria rileva un malfunzionamento della macchina attiva, assumerà il controllo e inizierà a eseguire il bilanciamento del carico. A quel punto, gli stati delle due macchine si invertono: la macchina secondaria diventa attiva mentre la macchina principale passa in standby.
Nella configurazione a disponibilità elevata, sia la macchina principale che quella di backup si trovano sulla stessa sottorete con configurazione identica.
Per ulteriori informazioni sulla configurazione della disponibilità elevata, vedere Disponibilità elevata.
Figura 14. Esempio di un Dispatcher che utilizza la disponibilità elevata reciproca
La funzione di disponibilità elevata reciproca implica l'uso di due macchine Dispatcher. Entrambe le macchine eseguono attivamente il bilanciamento del carico del traffico client e fungono da backup l'una per l'altra. In una configurazione a disponibilità elevata di tipo semplice, solo una macchina esegue il bilanciamento del carico. In una configurazione a disponibilità elevata reciproca, entrambe le macchine eseguono il bilanciamento del carico di una parte del traffico client.
Per la disponibilità elevata reciproca, il traffico client viene assegnato a ciascuna macchina Dispatcher in base all'indirizzo cluster. Ciascun cluster può essere configurato con l'NFA (nonforwarding address) del Dispatcher principale. La macchia Dispatcher principale normalmente esegue il bilanciamento del carico per quel cluster. Nel caso di un malfunzionamento, l'altra macchina eseguirà il bilanciamento del carico sia per il proprio cluster che per il cluster del Dispatcher malfunzionante.
Per un'illustrazione di una configurazione della disponibilità elevata reciproca con il "gruppo di cluster A" e il "gruppo di cluster B" condivisi, vedere Figura 14. Ciascun Dispatcher può attivamente instradare pacchetti per il proprio cluster principale. Se uno dei Dispatcher ha riscontrato un errore e non può più inviare attivamente pacchetti per il proprio cluster principale, l'altro Dispatcher può assumere il controllo e instradare pacchetti per il proprio cluster secondario.
Per informazioni sulla configurazione della disponibilità elevata semplice e reciproca, vedere Disponibilità elevata.
Prima di eseguire le operazioni riportate in questo capitolo, vedere Pianificazione di Dispatcher. Questo capitolo illustra come creare una configurazione di base per il componente Dispatcher di Load Balancer.
Prima di iniziare le procedure di
configurazione della tabella, verificare che la macchina Dispatcher e tutte
le macchine server siano collegate in rete, abbiano indirizzi IP
validi e siano in grado di eseguire il ping reciprocamente.
Tabella 7. Attività di configurazione per la funzione Dispatcher
Attività | Descrizione | Informazioni correlate |
---|---|---|
Configurazione della macchina Dispatcher. |
Configurazione del bilanciamento del
carico.
| Configurazione della macchina Dispatcher |
Configurazione delle macchine da sottoporre a bilanciamento del carico. | Creazione dell'alias dell'unità loopback, ricerca di instradamenti supplementari ed eventuale eliminazione di questi ultimi. | Configurazione delle macchine server per il bilanciamento del carico |
Per configurare il Dispatcher, sono disponibili quattro metodi di base:
Si tratta del metodo più diretto per configurare il Dispatcher. i valori dei parametri dei comandi devono essere immessi utilizzando l'alfabeto inglese. Le uniche eccezioni sono i nomi host (utilizzati in cluster, server e comandi highavailability) e i nomi file (utilizzati in comandi file).
Per avviare il Dispatcher dalla riga comandi:
È possibile utilizzare una versione ridotta dei parametri del comando dscontrol, immettendo le lettere che designano in modo univoco i parametri. Ad esempio, per visualizzare la guida del comando di salvataggio file, è possibile immettere dscontrol he f anziché dscontrol help file.
Per attivare l'interfaccia della riga comandi: emettere dscontrol per ricevere un prompt dei comandi dscontrol.
Per chiudere l'interfaccia della riga comandi: emettere exit o quit.
È possibile immettere i comandi per la configurazione di Dispatcher in un file script di configurazione per eseguirli tutti insieme. Vedere File di configurazione di Load Balancer di esempio.
dscontrol file appendload myscript
dscontrol file newload myscript
Per salvare la configurazione corrente nel file di script (ad esempio, savescript), eseguire il comando:
dscontrol file save savescript
Questo comando salva il file di script della configurazione nella directory ...ibm/edge/lb/servers/configurations/dispatcher.
Per istruzioni generali e un esempio della GUI, vedere Figura 41.
Per avviare la GUI, effettuare quanto segue:
dsserver
Per configurare il componente Dispatcher dalla GUI, è necessario anzitutto selezionare Dispatcher nella struttura ad albero. È possibile avviare l'executor e il gestore dopo essersi collegati a un host. Inoltre, è possibile creare cluster contenenti porte e server e avviare gli advisor per il gestore.
La GUI può essere utilizzata per eseguire le operazioni che verrebbero effettuate con il comando dscontrol. Ad esempio, per definire un cluster utilizzando la riga comandi, si deve immettere il comando dscontrol cluster add cluster. Per definire un cluster dalla GUI, fare clic con il tasto destro del mouse su Executor, quindi nel menu a comparsa fare clic con il tasto sinistro del mouse su Add Cluster. Immettere l'indirizzo del cluster nella finestra a comparsa, quindi fare clic su OK.
I file di configurazione Dispatcher esistenti possono essere caricati utilizzando l'opzione Load New Configuration (per sostituire completamente la configurazione corrente) e l'opzione Append to Current Configuration (per aggiornare la configurazione corrente), contenute nel menu a comparsa Host. Salvare periodicamente la configurazione Dispatcher su un file utilizzando l'opzione Save Configuration File As contenuta nel menu a comparsa Host. Il menu File situato sulla parte superiore della GUI consente di salvare le connessioni host correnti in un file o di ripristinare le connessioni nei file esistenti per tutti i componenti di Load Balancer.
I comandi di configurazione possono essere eseguiti anche da remoto. Per informazioni sul metodo RMI, vedere RMI (Remote Method Invocation).
Per eseguire un comando dalla GUI: evidenziare il nodo Host dalla struttura ad albero della GUI e selezionare Send command.... dal relativo menu a comparsa. Nel campo di immissione dei comandi, digitare il comando che si desidera eseguire, ad esempio: executor report. I risultati e la cronologia dei comandi in esecuzione nella sessione corrente vengono visualizzati nella finestra fornita.
È possibile accedere alla guida ? facendo clic sull'icona punto interrogativo nell'angolo in alto a destra della finestra di Load Balancer.
Per informazioni sull'uso della GUI, vedere Appendice A, GUI: istruzioni generali.
Se si utilizza la configurazione guidata, effettuare quanto segue:
dsserver
La procedura guidata illustra nei dettagli come creare una configurazione di base del componente Dispatcher. L'utente dovrà rispondere ad alcune domande circa la rete e riceverà tutte le informazioni necessarie per impostare un cluster del Dispatcher per bilanciare il traffico tra un gruppo di server.
Per poter configurare la macchina Dispatcher, è necessario disporre dei diritti utente root (per AIX, HP-UX, Linux o Solaris) o amministratore su Windows.
Su tutte le piattaforme supportate, Load Balancer può disporre di un server collocated. Ciò significa che Load Balancer può fisicamente risiedere su una macchina server su cui sta eseguendo il bilanciamento del carico.
Per la macchina Dispatcher, quando si utilizza il metodo di inoltro mac, saranno necessari almeno due indirizzi IP validi. Per il metodo di inoltro cbr o nat, saranno necessari almeno tre indirizzi IP validi:
Si tratta dell'indirizzo IP principale della macchina Dispatcher, noto come NFA (nonforwarding address, indirizzo di non inoltro). Per impostazione predefinita, questo indirizzo è identico a quello restituito dal comando hostname. Utilizzare questo indirizzo per collegarsi alla macchina per scopi di gestione, ad esempio, per eseguire una configurazione remota using Telnet o per accedere all'agente secondario SNMP. Se la macchina Dispatcher può già eseguire il ping su altre macchine sulla rete, non sono necessarie ulteriori operazioni per impostare l'indirizzo di non inoltro.
Un indirizzo cluster è un indirizzo associato a un nome host (ad esempio, www.yourcompany.com). Questo indirizzo IP viene utilizzato da un client per collegarsi ai server di un cluster. Si tratta dell'indirizzo sottoposto a bilanciamento del carico dal Dispatcher.
Il Dispatcher utilizza l'indirizzo mittente come indirizzo di origine quando bilancia il carico delle richieste del client al server. In questo modo, il server restituisce il package alla macchina Dispatcher, anziché inviarlo direttamente al client. (Il Dispatcher inoltra quindi il package IP al client.) Quando si aggiunge il server, è necessario specificare il valore dell'indirizzo mittente. Non è possibile modificare l'indirizzo mittente, a meno il server non venga prima rimosso quindi riaggiunto.
Il numero di connessioni che Load Balancer può mantenere attive con il server di back-end è limitato dal numero di indirizzi di ritorno definiti. Load Balancer utilizza porte che si basano solo sull'indirizzo di ritorno, non sulla combinazione di indirizzo di ritorno e server. Quando tutte le porte disponibili sono in uso, connessioni aggiuntive non riescono. In un ambiente occupato, utilizzare indirizzi di ritorno per evitare una diminuzione di porte disponibili.
Solo su sistemi Solaris:
Ad esempio, per modificare le impostazioni predefinite, modificare il file /opt/ibm/edge/lb/servers/ibmlb.conf come segue:
Per supportare più tipi di schede, replicare la riga nel file ibmlb.conf e modificare ciascuna riga in modo che corrisponda al tipo di dispositivo.
Se, ad esempio, si desidera utilizzare due schede Ethernet da 100Mbps, è necessario inserire un'unica riga nel file ibmlb.conf specificando il dispositivo eri.
Se invece si intende utilizzare una scheda Ethernet 10Mbps e una scheda Ethernet 100Mbps, il file ibmlb.conf conterrà due righe: una che specifica il dispositivo le e l'altro che specifica il dispositivo eri.
ifconfig -a
Se viene visualizzato il seguente output:
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 9.42.93.208 netmask fffffc00 broadcast 9.42.95.255 ether 0:3:ba:2d:24:45
allora è necessario modificare il file ibmlb.conf come riportato di seguito:
eri -1 0 ibmlb
Se, ad esempio, i cluster X e Y sono configurati per essere utilizzati dal componente CBR su una delle schede elencate in ibmlb.conf, la configurazione dei cluster X e Y viene annullata nel momento in cui vengono emessi i comandi dscontrol executor start o dscontrol executor stop. Questo potrebbe non essere il risultato desiderato. Quando i cluster X e Y vengono configurati nello script goAliases, i cluster vengono automaticamente riconfigurati dopo l'avvio o l'arresto dell'executor Dispatcher.
Verificare che l'inoltro IP non sia abilitato per il protocollo TCP/IP.
La figura 15 mostra un esempio di Dispatcher impostato con un cluster, due porte e tre server.
Figura 15. Esempio di indirizzi IP necessari per la macchina Dispatcher
Per informazioni sui comandi utilizzati in questa procedura, vedere Riferimento sui comandi per Dispatcher e CBR.
Per un file di configurazione di esempio, vedere File di configurazione di Load Balancer di esempio.
AIX, HP-UX, Linux o Solaris: per avviare la funzione server, immettere dsserver.
Su sistemi Windows: la funzione server viene avviata automaticamente come servizio.
Per avviare la funzione executor, immettere il comando dscontrol executor start. In questa fase, è possibile anche modificare le varie impostazioni dell'executor. Vedere Riferimento sui comandi per Dispatcher e CBR.
L'indirizzo di non inoltro viene adoperato per collegarsi alla macchina per scopi di gestione, ad esempio per utilizzare Telnet o SMTP. Per impostazione predefinita, questo indirizzo è il nome host.
Per definire l'indirizzo di non inoltro, immettere il comando dscontrol executor set nfa indirizzo_IP o modificare il file di configurazione di esempio. Per indirizzo_IP è possibile specificare il nome simbolico o l'indirizzo IP.
Il Dispatcher esegue il bilanciamento del carico delle richieste inviate all'indirizzo cluster per i server configurati sulle porte del cluster specificato.
Il cluster può essere il nome simbolico, l'indirizzo in formato decimale puntato o l'indirizzo speciale 0.0.0.0, che definisce un cluster jolly. Per definire un cluster, emettere il comando dscontrol cluster add. Per impostare le opzioni del cluster, emettere il comando dscontrol cluster set oppure utilizzare la GUI per emettere i comandi. I cluster jolly possono essere utilizzati per individuare più indirizzi IP per i pacchetti in entrata su cui eseguire il bilanciamento del carico. Vedere Utilizzo del cluster jolly per combinare le configurazioni di server, Utilizzo di cluster jolly per bilanciare il carico dei firewall e Utilizzo del cluster jolly con Caching Proxy per il proxy trasparente.
Quando il cluster è stato definito, configurare normalmente l'indirizzo cluster su una delle schede di rete della macchina Dispatcher. A tale scopo, emettere il comando dscontrol executor configure indirizzo_cluster. In questo modo, verrà ricercata una scheda con un indirizzo esistente che appartiene alla stessa sottorete dell'indirizzo cluster. Verrà quindi emesso il comando di configurazione della scheda del sistema operativo per l'indirizzo cluster, utilizzando la scheda individuata e la maschera di rete dell'indirizzo esistente di quella scheda. Ad esempio:
dscontrol executor configure 204.67.172.72
In alcuni casi, che prevedono cluster aggiunti a un server in standby in modalità a disponibilità elevata o cluster aggiunti a un dispatcher all'interno di una rete geografica che funge da server remoto, è preferibile non configurare l'indirizzo cluster. Inoltre, non è necessario eseguire il comando executor configure se, in modalità autonoma, si utilizza lo script di esempio goIdle. Per informazioni sullo script goIdle, vedere Utilizzo degli script.
In rari casi, l'indirizzo cluster a disposizione potrebbe non coincidere con nessuna delle sottoreti degli indirizzi esistenti. In questo caso, utilizzare il secondo formato del comando executor configure e specificare in modo esplicito il nome dell'interfaccia e la maschera di rete. Utilizzare dscontrol executor configure indirizzo_cluster interface_name netmask.
Di seguito sono riportati alcuni esempi:
dscontrol executor configure 204.67.172.72 en0 255.255.0.0 (sistemi AIX) dscontrol executor configure 204.67.172.72 eth0:1 255.255.0.0 (sistemi Linux) dscontrol executor configure 204.67.172.72 eri0 255.255.0.0 (sistemi Solaris) dscontrol executor configure 204.67.172.72 en1 255.255.0.0 (sistemi Windows)
Per utilizzare il secondo formato del comando executor configure su Windows, è necessario determinare il nome dell'interfaccia da utilizzare. Se si dispone solo di una scheda Ethernet nella macchina, il nome dell'interfaccia sarà en0. Se si dispone solo di una scheda Token Ring nella macchina, il nome dell'interfaccia sarà tr0. In presenza di più schede di entrambi i tipi, sarà necessario determinare la mappatura delle schede. Effettuare quanto segue:
L'output verrà visualizzato sullo schermo. Per determinare l'interfaccia da utilizzare per la configurazione di Load Balancer, ricercare l'indirizzo IP della macchina Load Balancer nelle righe che seguono Number of NIC records.
L'indirizzo IP della macchina Load Balancer verrà riportato come: ia->ia_addr. Il nome dell'interfaccia associata sarà riportato come ifp->if_name.
I nomi delle interfacce assegnate dal comando executor configure vengono associati ai nomi delle interfacce riportati in questo comando.
Dopo aver ottenuto le informazioni sulla mappatura, è possibile creare un alias sull'interfaccia di rete all'indirizzo cluster.
Su sistemi Linux o UNIX(R), il comando executor configure esegue i comandi ifconfig.
Quando si utilizzano applicazioni del server specifico del collegamento che si collegano a un elenco di indirizzi IP che non contengono l'IP del server, utilizzare il comando arp publish al posto di ifconfig per impostare dinamicamente un indirizzo IP sulla macchina Load Balancer. Ad esempio:
arp -s <cluster> <Load Balancer MAC address> pub
Per definire una porta, immettere il comando dscontrol port add cluster:porta, modificare il file di configurazione di esempio o utilizzare la GUI. Per cluster è possibile specificare il nome simbolico o l'indirizzo IP. Per porta specificare il numero della porta che si sta utilizzando per il protocollo. In questa fase, è possibile anche modificare varie impostazioni di porta. È necessario definire e configurare tutti i server di una porta. Vedere Riferimento sui comandi per Dispatcher e CBR.
Il numero di porta 0 (zero) viene utilizzato per specificare una porta jolly. Questa porta accetta il traffico di una porta non destinato ad alcuna porta definita sul cluster. La porta jolly verrà utilizzata per configurare regole e server per qualsiasi porta. Questa funzione può essere utilizzata anche in caso di una configurazione server/regola identica per più porte. Il traffico su una porta può quindi influire sulle decisioni inerenti il bilanciamento del carico del traffico su altre porte. Per ulteriori informazioni sui casi in cui è opportuno utilizzare una porta jolly, vedere Utilizzo della porta jolly per indirizzare il traffico per una porta non configurata.
Per definire una macchina server con bilanciamento del carico, immettere il comando dscontrol server add cluster:porta:server, modificare il file di configurazione di esempio o utilizzare la GUI. Per cluster e server, è possibile specificare il nome simbolico o l'indirizzo IP. Per porta specificare il numero della porta che si sta utilizzando per il protocollo. Per poter effettuare un bilanciamento del carico, è necessario definire più di un server per una porta su un cluster.
Server specifici del collegamento: Se il componente Dispatcher sta eseguendo il bilanciamento del carico su server specifici del collegamento, i server devono essere configurati collegarsi all'indirizzo cluster. Poiché il Dispatcher inoltra i pacchetti senza modificare l'indirizzo IP di destinazione, quando i pacchetti raggiungono il server, conterranno ancora l'indirizzo cluster come destinazione. Se un server è stato configurato per collegarsi a un indirizzo IP diverso dall'indirizzo cluster, il server non sarà in grado di accettare richieste destinati al cluster.
Per determinare se il server è bind specifico, emettere il comando netstat -an e ricercare server:port. Se il server non è bind specifico, il risultato di questo comando sarà 0.0.0.0:80. Se invece il server è bind specifico, verrà visualizzato un indirizzo del tipo 192.168.15.103:80.
Posizionamento di indirizzi multipli: In una configurazione posizionata, l'indirizzo della macchina server posizionata non deve essere identico all'indirizzo di non inoltro (NFA). Se la macchina è stata definita con più indirizzi IP, è possibile utilizzare un altro indirizzo. Per il componente Dispatcher, la macchina server posizionata deve essere definita come posizionata tramite il comando dscontrol server. Per ulteriori informazioni sui server posizionati, vedere Utilizzo di server posizionati.
Per ulteriori informazioni sulla sintassi del comando dscontrol server, vedere dscontrol server -- configura i server.
La funzione gestore migliora il bilanciamento del carico. Per avviare il gestore, immettere il comando dscontrol manager start, modificare il file di configurazione di esempio o utilizzare la GUI.
Gli advisor forniscono al gestore ulteriori informazioni sulla capacità delle macchine server con bilanciamento del carico di rispondere alle richieste. Un advisor è specifico di un protocollo. Ad esempio, per avviare l'advisor HTTP, immettere il seguente comando:
dscontrol advisor start http portaPer un elenco degli advisor e delle relative porte predefinite, vedere Riferimento sui comandi per Dispatcher e CBR. Per una descrizione di ogni advisor, vedere Elenco di advisor.
Se si avviano gli advisor, è possibile modificare le proporzioni di importanza attribuite alle informazioni raccolte dall'advisor che devono essere incluse nelle decisioni relative al bilanciamento del carico. Per impostare le proporzioni del cluster, immettere il comando dscontrol cluster set cluster proporzioni. Per ulteriori informazioni, vedere Proporzione di importanza attribuita alle informazioni sullo stato.
Effettuare le operazioni riportate di seguito se una delle condizioni è true:
Note:
Quando si utilizza il metodo di inoltro mac, il Dispatcher bilancerà il carico solo tra i server che consentono di configurare la scheda loopback con un indirizzo IP supplementare, per cui il server backend non risponderà mai alle richieste ARP (address resolution protocol). Attenersi alle operazioni descritte in questa sezione per configurare le macchine server sottoposte a bilanciamento del carico.
Per far funzionare macchine server sottoposte a bilanciamento del carico, è necessario impostare l'unità loopback (spesso denominata lo0) (o, preferibilmente, crearne l'alias) per l'indirizzo cluster. Quando si utilizza il metodo di inoltro mac, il componente Dispatcher non modifica l'indirizzo IP di destinazione nel pacchetto TCP/IP, prima di inoltrare il pacchetto a una macchina server TCP. Configurando l'unità loopback sull'indirizzo cluster, o aggiungendovi l'alias, le macchine server sottoposte a bilanciamento del carico accettano un package destinato all'indirizzo cluster.
Con un sistema operativo che supporta l'aggiunta dell'alias delle interfacce di rete (come AIX, HP-UX, Linux, Solaris o Windows), si dovrebbe creare l'alias dell'unità loopback per l'indirizzo cluster. Il vantaggio derivante dall'uso di un sistema operativo che supporta gli alias è la possibilità di configurare macchine server sottoposte a bilanciamento del carico destinate a servire più indirizzi cluster.
IMPORTANTE: Per i sistemi Linux, vedere Alternative di creazione alias loopback Linux quando si utilizza il metodo di inoltro mac di Load Balancer.
Se si dispone di un server con un sistema operativo che non supporta gli alias, è necessario impostare l'unità loopback per l'indirizzo cluster.
Utilizzare il comando per il sistema operativo a disposizione, come illustrato nella
Tabella 8, per impostare o creare l'alias dell'unità loopback.
Tabella 8. Comandi per creare l'alias dell'unità loopback (lo0) per Dispatcher
Su alcuni sistemi operativi, potrebbe essere stato creato un instradamento predefinito che deve essere rimosso.
route print
IMPORTANTE: qualsiasi instradamento aggiuntivo deve essere ignorato su Windows 2003. Se si verificano dei problemi con l'instradamento in seguito alla creazione dell'alias, rimuovere l'alias e aggiungerlo di nuovo utilizzando una netmask differente.
netstat -nr
Esempio Windows:
Instradamenti attivi: Indirizzo di rete Netmask Indirizzo gateway Interfaccia Metrica 0.0.0.0 0.0.0.0 9.67.128.1 9.67.133.67 1 9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1 9.67.128.0 255.255.248.0 9.67.133.67 9.67.133.67 1 9.67.133.67 255.255.255.255 127.0.0.1 127.0.0.1 1 9.67.133.158 255.255.255.255 127.0.0.1 127.0.0.1 1 9.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 224.0.0.0 9.67.133.158 9.67.133.158 1 224.0.0.0 224.0.0.0 9.67.133.67 9.67.133.67 1 255.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1
9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1
È necessario rimuovere l'instradamento supplementare. Utilizzare il comando del sistema operativo illustrato nella Tabella 9 per rimuovere l'instradamento supplementare.
Esempio: per eliminare un instradamento supplementare come illustrato nella tabella di esempio "Active Routes" della fase 2, immettere:
route delete 9.0.0.0 9.67.133.158
Tabella 9. Comandi per eliminare instradamenti supplementari per Dispatcher
Se si utilizza l'esempio illustrato nella Figura 15 e si configura una macchina server su cui è in esecuzione AIX, il comando dovrebbe essere:
route delete -net 204.0.0.0 204.67.172.72
Per verificare che un server backend sia correttamente configurato, effettuare le seguenti operazioni da una macchina differente sulla stessa sottorete, quando Load Balancer non è in esecuzione e il cluster non è configurato:
arp -d cluster
ping cluster
Non dovrebbe esserci risposta. Nel caso di risposta al ping, verificare di non aver eseguito il comando ifconfig per l'indirizzo cluster all'interfaccia. Accertarsi che non vi siano macchine che presentino una voce con arp publish nell'indirizzo cluster.
arp -a
Nell'output del comando, dovrebbe essere visualizzato l'indirizzo MAC del server. Emettere il comando:
arp -s cluster indirizzo_mac_server
arp -d cluster
Alcune versioni di Linux emettono delle risposte ARP per qualsiasi indirizzo IP configurato sulla macchina su ogni interfaccia presente sulla macchina stessa. Inoltre, è possibile selezionare un indirizzo IP di origine ARP per query ARP who-has basate su tutti gli indirizzi IP presenti sulla macchina, indipendentemente dalle interfacce su cui sono configurati quegli indirizzi. In questo modo, tutto il traffico cluster viene indirizzato a un unico server in maniera indeterminata.
Quando si utilizza il metodo di inoltro mac del Dispatcher, è necessario adoperare un meccanismo che assicuri che il traffico indirizzato al cluster venga accettato dagli stack dei server backend, compresa la macchina in standby con disponibilità elevata, se si utilizza sia la disponibilità elevata che il posizionamento.
Nella maggior parte dei casi, è necessario creare l'alias dell'indirizzo cluster sul loopback; perciò, per i server backend è obbligatorio creare l'alias del cluster sul loopback; inoltre, se si utilizza la disponibilità elevata e il posizionamento, per i server con bilanciamento del carico in standby, occorre creare l'alias del cluster sul loopback.
Per verificare che Linux non renda noti gli indirizzi sul loopback, è possibile utilizzare una delle seguenti soluzioni, per garantire la compatibilità tra Linux e il metodo di inoltro mac del Dispatcher.
# sysctl -w net.ipv4.conf.all.hidden=1 net.ipv4.conf.lo.hidden=1Quindi, è possibile creare normalmente l'alias dei cluster, ad esempio:
# ifconfig lo:1 $CLUSTER_ADDRESS netmask 255.255.255.255 up
# sysctl -w net.ipv4.conf.all.arp_ignore=3 net.ipv4.conf.all.arp_announce=2Quindi, è necessario creare l'alias dei cluster con il seguente comando:
# ip addr add $CLUSTER_ADDRESS/32 scope host dev loUn comando simile deve trovarsi negli script go* nelle configurazioni a disponibilità elevata.
# iptables -t nat -A PREROUTING -d $CLUSTER_ADDRESS -j REDIRECTIn questo modo, Linux esegue la conversione degli indirizzi di rete (NAT, Network Address Translation) su ciascun pacchetto, sostituendo l'indirizzo del cluster con l'indirizzo dell'interfaccia di rete. Questo metodo penalizza la velocità delle connessioni al secondo del 6,4%. Il metodo funziona su qualsiasi distribuzione comune supportata; non sono necessari moduli kernel o patch+build+install del kernel.
# modprobe noarp # noarpctl add $CLUSTER_ADDRESS indir-princ-nicdove indir-pric-nic è un indirizzo nella stessa sottorete dell'indirizzo cluster. Quindi, è possibile creare normalmente l'alias dei cluster, ad esempio:
# ifconfig lo:1 indirizzo cluster netmask 255.255.255.255 up
Questa sezione fornisce informazioni per una rapida configurazione, considerazioni sulla pianificazione e descrive i metodi di configurazione del componente CBR di Load Balancer. Contiene i seguenti capitoli:
Questo esempio di avvio rapido mostra come configurare tre stazioni di lavoro collegate localmente utilizzando il componente CBR con Caching Proxy, al fine di bilanciare il carico del traffico Web tra due server Web. (Per semplicità, questo esempio mostra i server sullo stesso segmento di LAN, tuttavia, CBR non pone limitazioni all'uso di server sulla stessa LAN.)
Figura 16. Una configurazione semplice di CBR locale
Per l'esempio di configurazione rapida, sono necessarie tre stazioni di lavoro e quattro indirizzi IP. Una stazione di lavoro verrà utilizzata per il CBR, le altre due per i server Web. Ciascun server Web richiede un indirizzo IP. La stazione di lavoro CBR richiede un indirizzo effettivo e un indirizzo per il bilanciamento del carico.
Per utilizzare CBR, Caching Proxy deve essere installato sullo stesso server. Per informazioni su come configurare Caching Proxy per CBR, vedere Fase 1. Configurazione di Caching Proxy per l'uso di CBR.
Stazione di lavoro | Nome | Indirizzo IP |
---|---|---|
1 | server1.mywebsite.com | 9.27.27.101 |
2 | server2.mywebsite.com | 9.27.27.102 |
3 | server3.mywebsite.com | 9.27.27.103 |
Netmask = 255.255.255.0 |
Ciascuna stazione di lavoro contiene solo una scheda interfaccia di rete Ethernet standard.
Name= www.mywebsite.com IP=9.27.27.104
CBR consente di creare una configurazione dalla riga comandi, con la configurazione guidata o mediante l'interfaccia utente grafica (GUI). In questo esempio di avvio rapido, le fasi di configurazione sono illustrate utilizzando la riga comandi.
Da un prompt dei comandi, effettuare le seguenti operazioni:
cbrcontrol executor start
ibmproxy
cbrcontrol cluster add www.mywebsite.com
cbrcontrol port add www.mywebsite.com:80
cbrcontrol server add www.mywebsite.com:80:server2.mywebsite.com
cbrcontrol server add www.mywebsite.com:80:server3.mywebsite.com
cbrcontrol rule add www.mywebsite.com:80:memberRule type content pattern uri=*/member/*
cbrcontrol rule add www.mywebsite.com:80:guestRule type content pattern uri=*/guest/*
In questo esempio, se si utilizza la regola di contenuto, le richieste client indirizzate a un sito Web www.mywebsite.com sono inviate a un server diverso in base a una directory contenuta nel relativo percorso di richiesta URI. Per ulteriori informazioni, vedere Appendice B, Sintassi della regola di contenuto (modello).
cbrcontrol rule useserver www.mywebsite:80:memberRule server2.mywebsite.com
cbrcontrol rule useserver www.mywebsite:80:guestRule server3.mywebsite.com
CBR eseguirà ora il bilanciamento del carico in base alla regola basata sul contenuto. Un client con una richiesta URL contenente /member/ sarà indirizzato al server2.mywebsite.com. Un client con una richiesta URL contenente /guest/ sarà indirizzato al server3.mywebsite.com.
cbrcontrol manager start
cbrcontrol advisor start http 80
A questo punto, CBR garantisce che le richieste client non verranno inviate a un server Web in errore.
La configurazione di base, con i server collegati localmente, è ora completa.
Verificare se la configurazione è in esecuzione:
cbrcontrol server report www.mywebsite.com:80:La somma totale della colonna connessioni dei due server deve essere "2."
Per informazioni sull'uso della GUI di CBR, vedere GUI e Appendice A, GUI: istruzioni generali.
Per informazioni sull'uso della procedura guidata CBR, vedere Procedura guidata di configurazione.
Sono disponibili diversi metodi per configurare CBR in modo che supporti il sito. Se si dispone di un solo nome host per il sito a cui tutti i clienti vorranno connettersi, è possibile definire un unico cluster di server. Per ciascuno di questi server, configurare una porta dedicata alla comunicazione con CBR. Vedere la Figura 9.
Figura 17. Esempio CBR configurato con un unico cluster e 2 porte
In questo esempio per il componente CBR, un cluster è definito all'indirizzo www.productworks.com. Questo cluster ha due porte: la porta 80 per HTTP e la porta 443 per SSL. Un client che invia una richiesta a http://www.productworks.com (porta 80) sarà indirizzato a un server diverso da quello destinato a un client che invia la sua richiesta a https://www.productworks.com (porta 443).
Se il sito è molto grande e contiene molti server dedicati a ciascun protocollo supportato, sarebbe opportuno configurare altrimenti il componente CBR. In questo caso, è possibile definire un cluster per ciascun protocollo con un'unica porta ma con molti server, come mostrato nella Figura 10.
Figura 18. Esempio di CBR configurato con due cluster, ognuno con una
porta
In questo esempio per il componente CBR, sono definiti due cluster: www.productworks.com per la porta 80 (HTTP) e www.testworks.com per la porta 443 (SSL).
Se il sito deve ospitare i contenuti di diverse aziende e reparti, ciascuno dei quali è indirizzato al sito con URL diversi, sarà opportuno adottare una terza configurazione. In questo caso, è possibile definire un cluster per ogni società o dipartimento e, di conseguenza, decidere le porte su cui ricevere le connessioni a quell'URL, come illustrato nella Figura 11.
Figura 19. Esempio di CBR configurato con 2 cluster, ognuno con 2 porte
In questo esempio per il componente CBR, sono definiti due cluster con la porta 80 (HTTP) e la porta 443 (SSL) per ciascun sito con indirizzo www.productworks.com e www.testworks.com.
Questo capitolo descrive i fattori che il responsabile della pianificazione di rete deve considerare prima di installare e configurare il componente CBR con Caching Proxy.
Questo capitolo include le seguenti sezioni:
Il componente CBR consente di bilanciare il carico del traffico HTTP e SSL utilizzando Caching Proxy per inoltrare le richieste via proxy. Il componente CBR consente di bilanciare il carico dei server configurati con un apposito file di configurazione CBR tramite i comandi cbrcontrol.
CBR è molto simile a Dispatcher nella sua struttura. CBR è composto dalle seguenti funzioni:
L'uso del gestore è facoltativo. Tuttavia, se il gestore non viene utilizzato, il bilanciamento del carico verrà eseguito utilizzando la pianificazione con il metodo round-robin basata sui pesi dei server correnti e gli advisor non saranno disponibili.
Le tre funzioni chiave di CBR (executor, gestore e advisor) interagiscono per bilanciare e distribuire le richieste in entrata tra i server. Oltre a bilanciare il carico delle richieste, l'executor monitora il numero di nuove connessioni e il numero delle connessioni attive e fornisce tali informazioni al gestore.
Il componente CBR consente di specificare un gruppo di server che gestirà una richiesta in base all'espressione regolare corrispondente al contenuto della richiesta client. CBR consente di suddividere il proprio sito in partizioni in modo che gruppi di server diversi possano provvedere a servizi di applicazioni o contenuti diversi. Questa partizione è trasparente per i client che accedono al proprio sito.
Una possibile soluzione di suddivisione del sito sarebbe assegnare a un gruppo di server la gestione delle richieste cgi e a un altro gruppo di server la gestione di tutte le altre richieste. Questo impedirebbe agli script cgi che svolgono calcoli complessi di rallentare i server in caso di normale traffico HTML con conseguente ottimizzazione complessiva dei tempi di risposta ai client. Questo schema consentirebbe anche di assegnare stazioni di lavoro più potenti alle richieste normali. Ciò migliorerebbe i tempi di risposta ai client senza dover affrontare le spese di un aggiornamento di tutti i server. Inoltre, questo consentirebbe di assegnare stazioni di lavoro più potenti alle richieste cgi.
Un'altra soluzione di suddivisione del sito potrebbe essere quella di indirizzare a un gruppo di server i client che accedono a pagine che prevedono la registrazione e a un altro gruppo di server tutte le altre richieste. Questo impedirebbe ai browser che accedono fortuitamente al sito di impegnare risorse che potrebbero essere altrimenti utilizzate dai client che intendono invece registrarsi. Inoltre, consentirebbe di dedicare stazioni di lavoro più potenti ai client che hanno completato la registrazione.
Naturalmente è possibile combinare i metodi sopra descritti per ottenere una flessibilità ancora maggiore e un servizio migliore.
Poiché CBR consente di specificare più server per ciascun tipo di richiesta, il carico delle richieste può essere bilanciato per ottimizzare i tempi di risposta ai client. L'assegnazione di ciascun tipo di contenuto a più server protegge il sito in caso di malfunzionamento di una stazione di lavoro o di un server. CBR riconosce il malfunzionamento e continua a bilanciare il carico delle richieste client sugli altri server del gruppo.
Caching Proxy comunica con un processo CBR tramite la relativa interfaccia del plugin. Affinché ciò funzioni, CBR deve essere eseguito sulla macchina locale. Poiché questi due processi sono distinti, più istanze di Caching Proxy possono essere in esecuzione e funzionanti con un'unica istanza di CBR. Questa configurazione potrebbe consentire di isolare gli indirizzi o le funzionalità tra i Caching Proxy oppure di migliorare l'uso delle risorse della macchina grazie a più Caching Proxy che gestiscono il traffico dei client. Le istanze proxy possono restare in ascolto su porte diverse o essere associati a indirizzi IP univoci sulla stessa porta, a seconda di ciò che meglio soddisfa i requisiti di traffico.
CBR con Caching Proxy esamina le richieste HTTP utilizzando tipi di regole specifici. Quando in esecuzione, Caching Proxy accetta le richieste client e interroga il componente CBR per individuare il server più adatto. Sulla base di questa interrogazione, CBR confronta la richiesta a fronte di un gruppo di regole in base a un ordine di priorità. Quando individua la regola corrispondente, sceglie un server adatto da un gruppo precedentemente configurato. Infine, CBR notifica a Caching Proxy il server proxy attraverso il quale dovrà essere inviata la richiesta.
Una volta definito un cluster da sottoporre al bilanciamento del carico, è necessario accertarsi che tutte le richieste indirizzate a quel cluster abbiano una regola che consenta di scegliere un server. Se non viene trovata una regola che corrisponda a una determinata richiesta, il client riceve una pagina di errore da Caching Proxy. Il modo più facile per garantire che tutte le richieste corrispondano a una regola è creare una regola del tipo "sempre true" e assegnarle una priorità molto elevata. Verificare che i server utilizzati da questa regola possano gestire tutte le richieste che non sono gestite esplicitamente dalle regole con priorità inferiore. (Nota: le regole con priorità inferiore vengono valutate per prime.)
Per ulteriori informazioni, vedere Configurazione del bilanciamento del carico in base alle regole.
CBR con Caching Proxy può ricevere sia la trasmissione SSL dal client al proxy (lato client-proxy) sia supportare la trasmissione dal proxy a un server SSL (lato proxy-server). In una configurazione CBR, la definizione su un server di una porta SSL dedicata a ricevere le richieste SSL provenienti dal client, offre la possibilità di gestire un sito totalmente protetto e di utilizzare CBR per bilanciare il carico tra i server (SSL) protetti.
Oltre ad altre modifiche al file ibmproxy.conf per CBR, è necessario aggiungere un'altra istruzione di configurazione al file ibmproxy.conf perché Caching Proxy abiliti la codifica SSL sul lato proxy-server. Il formato deve essere:
proxy modello_uri modello_url indirizzo
dove modello_uri è un modello a cui corrispondere (ad esempio: /secure/*), modello_url è un URL di sostituzione (ad esempio: https://clusterA/secure/*) e indirizzo è l'indirizzo cluster (ad esempio: clusterA).
CBR con Caching Proxy può anche ricevere trasmissioni SSL dai client e decodificare le richieste SSL prima di inviarle a un server HTTP attraverso un proxy. Affinché CBR supporti la trasmissione client-proxy in SSL e proxy-server in HTTP, è prevista una parola chiave facoltativa mapport nel comando cbrcontrol server. Utilizzare questa parola chiave quando si desidera indicare che la porta sul server è diversa dalla porta dove arrivano le richieste in entrata provenienti dal client. Di seguito viene riportato un esempio di aggiunta di una porta tramite la parola chiave mapport, dove la porta del client è 443 (SSL) e la porta del server è 80 (HTTP):
cbrcontrol server add cluster:443 mapport 80
Il numero di porta di mapport può essere un qualsiasi numero intero positivo. Il valore predefinito è il numero della porta dove arrivano le richieste in entrata provenienti dal client.
Poiché CBR deve essere in grado di fornire informazioni su una richiesta HTTP per un server configurato sulla porta 443 (SSL), viene fornito un advisor speciale ssl2http . Questo advisor viene avviato sulla porta 443 (la porta delle richieste in entrata provenienti dal client) e fornisce informazioni sui server configurati su tale porta. Se vi sono due cluster configurati e per ciascun cluster la porta è 443 e i server sono configurati con un valore mapport diverso, un'unica istanza dell'advisor può aprire di conseguenza la porta appropriata. Di seguito viene riportato un esempio di questa configurazione:
Executor Cluster1 Port:443 Server1 mapport 80 Server2 mapport 8080 Cluster2 Port:443 Server3 mapport 80 Server4 mapport 8080 Manager Advisor ssl2http 443
Prima di eseguire le operazioni riportate in questo capitolo, vedere Pianificazione di Content Based Routing. Questo capitolo illustra come creare una configurazione di base per il componente CBR di Load Balancer.
Prima di iniziare le procedure di configurazione della tabella, verificare che la macchina CBR e tutte le macchine server siano collegate in rete, abbiano indirizzi IP validi e siano in grado di eseguire il ping reciprocamente.
Tabella 10. Attività di configurazione per il componente CBR
Attività | Descrizione | Informazioni correlate |
---|---|---|
Configurazione della macchina CBR. | Individuazione dei requisiti. | Configurazione della macchina CBR |
Configurazione delle macchine da sottoporre a bilanciamento del carico. | Configurazione del bilanciamento del carico. | Fase 7. Definizione delle macchine server con bilanciamento del carico |
Per creare una configurazione base del componente CBR di Load Balancer, sono disponibili quattro metodi di base:
Per poter utilizzare il componente CBR, è necessario che Caching Proxy sia installato.
È il mezzo più diretto per la configurazione di CBR. i valori dei parametri dei comandi devono essere immessi utilizzando l'alfabeto inglese. Le uniche eccezioni riguardano i nomi host, utilizzati ad esempio nei comandi cluster e server, e i nomi di file.
Per avviare il componente CBR dalla riga comandi:
Per i sistemi Windows: fare clic su Start > Impostazioni (per Windows 2000) > Pannello di controllo > Strumenti di amministrazione > Servizi. Fare clic con il tasto destro del mouse su IBM Content Based Routing e selezionare Avvia. Per arrestare il servizio, effettuare le stesse operazioni e selezionare Arresta.
È possibile immettere una versione abbreviata dei parametri del comando cbrcontrol. È sufficiente inserire le lettere che designano in modo univoco i parametri. Ad esempio, per richiamare la guida sul comando di salvataggio file, è possibile digitare cbrcontrol he f anziché cbrcontrol help file.
Per avviare l'interfaccia della riga comandi: immettere cbrcontrol per ricevere il prompt dei comandi per cbrcontrol.
Per chiudere l'interfaccia della riga comandi: emettere exit o quit.
Note:
( ) parentesi di apertura e chiusura
& E commerciale
| barra verticale
! punto esclamativo
* asterisco
La shell del sistema operativo potrebbe interpretarli come caratteri speciali e trasformarli per alternare il testo prima che cbrcontrol li possa valutare.
I caratteri speciali dell'elenco sopra riportato sono caratteri opzionali del comando cbrcontrol rule add e vengono utilizzati per specificare un modello per una regola di contenuto. Ad esempio, il seguente comando potrebbe essere valido solo quando si utilizza il prompt cbrcontrol>>.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*
Affinché questo stesso comando funzioni sul prompt del sistema operativo, è necessario aggiungere le doppie virgolette (" ") prima e dopo il modello, come indicato di seguito:
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
Se non si utilizzano le virgolette, è possibile che il modello venga troncato quando la regola viene salvata nel componente CBR. Notare che le virgolette non sono supportate quando si utilizza il prompt dei comandi cbrcontrol>>.
È possibile immettere i comandi per la configurazione di CBR in un file script di configurazione per eseguirli tutti insieme.
cbrcontrol file appendload myscript
cbrcontrol file newload myscript
Per salvare la configurazione corrente nel file di script (ad esempio, savescript), eseguire il comando:
cbrcontrol file save savescript
Questo comando salva il file di script della configurazione nella directory ...ibm/edge/lb/servers/configurations/cbr.
Per istruzioni generali e un esempio della GUI, vedere Figura 41.
Per avviare la GUI, effettuare le seguenti operazioni.
Per configurare il componente CBR dalla GUI, è necessario anzitutto selezionare Content Based Routing nella struttura ad albero. È possibile avviare il gestore dopo essersi collegati a un host. Inoltre, è possibile creare cluster contenenti porte e server e avviare gli advisor per il gestore.
La GUI può essere utilizzata per eseguire le operazioni che verrebbero effettuate con il comando cbrcontrol. Ad esempio, per definire un cluster utilizzando la riga comandi, si deve immettere il comando cbrcontrol cluster add cluster. Per definire un cluster dalla GUI, fare clic con il tasto destro del mouse su Executor, quindi nel menu a comparsa fare clic su Aggiungi cluster. Immettere l'indirizzo del cluster nella finestra a comparsa, quindi fare clic su OK.
I file di configurazione CBR esistenti possono essere caricati utilizzando l'opzione Load New Configuration (per sostituire completamente la configurazione corrente) e l'opzione Append to Current Configuration (per aggiornare la configurazione corrente) contenuti nel menu a comparsa Host. Salvare periodicamente la configurazione di CBR su un file utilizzando l'opzione Save Configuration File As contenuta nel menu a comparsa Host. Il menu File situato sulla parte superiore della GUI consente di salvare le connessioni host correnti in un file o di ripristinare le connessioni nei file esistenti per tutti i componenti di Load Balancer.
È possibile accedere alla guida ? facendo clic sull'icona punto interrogativo nell'angolo in alto a destra della finestra di Load Balancer.
Per eseguire un comando dalla GUI: evidenziare il nodo Host dalla struttura ad albero della GUI e selezionare Send command... dal menu a comparsa Host. Nel campo di immissione dei comandi, digitare il comando che si desidera eseguire, ad esempio: executor report. I risultati e la cronologia dei comandi in esecuzione nella sessione corrente vengono visualizzati nella finestra fornita.
Per informazioni sull'uso della GUI, vedere Appendice A, GUI: istruzioni generali.
Se si utilizza la configurazione guidata, effettuare quanto segue:
Avviare la configurazione guidata dal prompt dei comandi immettendo cbrwizard. In alternativa, selezionare Configuration Wizard dal menu del componente CBR presente nella GUI.
Sui sistemi AIX, HP-UX, Linux o Solaris: per avviare Caching Proxy, immettere ibmproxy
Per i sistemi Windows: per avviare Caching Proxy, andare al pannello Servizi: Start >Impostazioni (per Windows 2000)> Pannello di controllo > Strumenti di amministrazione > Servizi
La configurazione guidata di CBR illustra nei dettagli come creare una configurazione di base per il componente CBR. Pone delle domande relative alla rete e fornisce le istruzioni su come configurare un cluster in modo che il componente CBR possa eseguire il bilanciamento del carico sul traffico esistente tra i server di un gruppo.
Per poter configurare la macchina CBR, è necessario disporre dei diritti di utente root (in AIX, HP-UX, Linux o Solaris) o di amministratore (in Windows).
Ciascun cluster di server configurato deve disporre di un indirizzo IP. Un indirizzo cluster è un indirizzo associato a un nome host (ad esempio, www.company.com). Questo indirizzo IP viene utilizzato da un client per collegarsi ai server di un cluster. In particolare, questo indirizzo si trova nella richiesta URL proveniente dal client. Tutte le richieste eseguite sullo stesso indirizzo cluster sono sottoposte a bilanciamento del carico da parte di CBR.
Solo per sistemi Solaris: prima di utilizzare il componente CBR, è necessario modificare i valori predefiniti del sistema per gli IPC (Inter-Process Communication). Le dimensioni massime di un segmento di memoria condivisa e il numero di identificatori di semaforo devono essere aumentati. Per ottimizzare il sistema in modo che supporti CBR, modificare il file /etc/system sul proprio sistema aggiungendo le seguenti istruzioni, quindi riavviare:
set shmsys:shminfo_shmmax=0x02000000 set semsys:seminfo_semmap=750 set semsys:seminfo_semmni=30 set semsys:seminfo_semmns=750 set semsys:seminfo_semmnu=30 set semsys:seminfo_semume=30
Se non si aumenta il segmento di memoria condiviso ai valori sopra riportati, il comando cbrcontrol executor start non verrà eseguito correttamente.
Per poter utilizzare il componente CBR, è necessario che Caching Proxy sia installato.
È necessario apportare le seguenti modifiche al file di configurazione di Caching Proxy (ibmproxy.conf):
Accertarsi che la direttiva URL in entrata CacheByIncomingUrl sia disattivata (impostazione predefinita).
Nella sezione relativa alla regola di mappatura del file di configurazione, per ciascun cluster, aggiungere una regola di mappatura analoga a:
Proxy /* http://cluster.domain.com/* cluster.domain.com
Per il plug-in di CBR devono essere modificate quattro voci:
Di seguito vengono riportate le aggiunte specifiche da inserire nel file di configurazione per ciascun sistema operativo.
Figura 20. File di configurazione di CBR sui sistemi AIX, Linux e Solaris
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerTerm
Figura 21. File di configurazione di CBR su sistemi HP-UX
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerTerm
Figura 22. File di configurazione di CBR su sistemi Windows
ServerInit C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerInit PostAuth C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostAuth PostExit C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostExit ServerTerm C:\Program Files\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerTerm
Per avviare la funzione server CBR, digitare cbrserver sulla riga comandi.
Un file di configurazione predefinito (default.cfg) viene caricato automaticamente quando si avvia cbrserver. Se si decide di salvare la configurazione CBR in default.cfg, tutto quello che è stato salvato in questo file verrà automaticamente caricato al successivo avvio di cbrserver.
Per avviare la funzione executor, immettere il comando cbrcontrol executor start. In questa fase, è possibile anche modificare le varie impostazioni dell'executor. Per ulteriori informazioni, vedere dscontrol executor -- controlla l'executor.
CBR esegue il bilanciamento delle richieste inviate per il cluster sui rispettivi server configurati sulle porte di quel determinato cluster.
Cluster è il nome simbolico situato nella porzione host dell'URL e deve corrispondere al nome utilizzato nell'istruzione Proxy del file ibmproxy.conf.
I cluster definiti in CBR devono essere definiti in modo da corrispondere alla richiesta in entrata. Per definire un cluster, utilizzare lo stesso nome host o lo stesso indirizzo IP che sarà presente nella richiesta in entrata. Ad esempio, se la richiesta arriverà come indirizzo IP, il cluster deve essere definito come indirizzo IP. Se esistono più nomi host che puntano a un unico indirizzo IP (e le richieste possono arrivare con uno qualsiasi di questi nomi host), sarà necessario definire come cluster tutti i nomi host.
Per definire un cluster, immettere il seguente comando:
cbrcontrol cluster add cluster
Per impostare le opzioni del cluster, immettere il seguente comando:
cbrcontrol cluster set valore opzione cluster
Per ulteriori informazioni, vedere Riferimento sui comandi per Dispatcher e CBR.
Se il Caching Proxy in esecuzione è configurato come proxy inverso, quando si esegue il bilanciamento del carico su più siti Web, è necessario aggiungere l'indirizzo cluster di ciascun sito Web su almeno una delle schede di interfaccia di rete della macchina Load Balancer. In caso contrario, è possibile ignorare questa fase.
Per sistemi AIX, HP-UX, Linux o Solaris: per aggiungere l'indirizzo cluster all'interfaccia di rete, utilizzare il comando ifconfig. Utilizzare il comando appropriato per il sistema operativo in uso, come indicato nella Tabella 11.
Tabella 11. Comandi per creare l'alias della NIC
AIX | ifconfig nome_interfaccia alias indirizzo_cluster netmask netmask |
HP-UX | ifconfig indirizzo_cluster_nome_interfaccia netmask netmask up |
Linux | ifconfig nome_interfaccia indirizzo_cluster netmask netmask up |
Solaris 8, Solaris 9 e Solaris 10 | ifconfig nome_interfaccia addif indirizzo_cluster netmask netmask up |
Per Windows 2000: per aggiungere l'indirizzo cluster all'interfaccia di rete, effettuare le seguenti operazioni:
Per Windows 2003: per aggiungere l'indirizzo cluster all'interfaccia di rete, effettuare le seguenti operazioni:
Il numero di porta indica la porta su cui le applicazioni del server rimangono in ascolto. Per CBR con Caching Proxy in esecuzione per il traffico HTTP, la porta è in genere 80.
Per definire una porta sul cluster definito nella fase precedente, immettere quanto segue:
cbrcontrol port add cluster:port
Per impostare le opzioni della porta, immettere quanto segue:
cbrcontrol port set valore opzione cluster:port
Per ulteriori informazioni, vedere Riferimento sui comandi per Dispatcher e CBR.
Le macchine server sono le macchine su cui vengono eseguite le applicazioni che si desidera sottoporre a bilanciamento del carico. Server è il nome simbolico o l'indirizzo decimale separato da punti della macchina server. Per definire un server sul cluster e sulla porta, immettere il seguente comando:
cbrcontrol server add cluster:port:server
Per poter effettuare un bilanciamento del carico, è necessario definire più di un server per porta su un cluster.
Questa è l'operazione chiave nella configurazione di CBR con Caching Proxy. Una regola definisce come distinguere una richiesta URL per poterla inviare al gruppo di server appropriato. Il tipo di regola particolare utilizzata da CBR viene denominata una regola di contenuto. Per definire una regola di contenuto, immettere il seguente comando:
cbrcontrol rule add cluster:port:rule modello contenuto tipo modello
Il valore modello è l'espressione regolare che verrà confrontata con l'URL in ciascuna richiesta client. Per ulteriori informazioni su come configurare il modello, vedere Appendice B, Sintassi della regola di contenuto (modello).
Alcuni altri tipi di regola definiti in Dispatcher possono essere utilizzati anche in CBR. Per ulteriori informazioni, vedere Configurazione del bilanciamento del carico in base alle regole.
Quando una richiesta client corrisponde a una regola, viene eseguita una query sul gruppo di server della regola per individuare il server migliore. Il gruppo di server della regola è un gruppo secondario di server definito sulla porta. Per aggiungere dei server al gruppo di server della regola, immettere il seguente comando:
cbrcontrol rule useserver cluster:port:rule server
La funzione gestore migliora il bilanciamento del carico. Per avviare il gestore, immettere il seguente comando:
cbrcontrol manager start
Gli advisor forniscono al gestore ulteriori informazioni sulla capacità delle macchine server con bilanciamento del carico di rispondere alle richieste. Un advisor è specifico di un protocollo. Ad esempio, per avviare l'advisor HTTP, immettere il seguente comando:
cbrcontrol advisor start http porta
Se si avviano gli advisor, è possibile modificare le proporzioni di importanza attribuite alle informazioni raccolte dall'advisor che devono essere incluse nelle decisioni relative al bilanciamento del carico. Per impostare le proporzioni del cluster, immettere il comando cbrcontrol cluster set cluster proporzioni. Per ulteriori informazioni, vedere Proporzione di importanza attribuita alle informazioni sullo stato.
/opt/ibm/edge/lb/servers/lib
/opt/ibm/edge/lb/servers/lib
C:\Program Files\IBM\edge\lb\servers\lib
Nel nuovo ambiente, avviare Caching Proxy: dal prompt dei comandi, immettere ibmproxy
Per configurare CBR, effettuare le seguenti operazioni:
Questa sezione fornisce informazioni per una rapida configurazione, considerazioni sulla pianificazione e descrive i metodi di configurazione del componente Site Selector di Load Balancer. Contiene i seguenti capitoli:
Questo esempio di avvio rapido illustra come creare una configurazione dei nomi del sito utilizzando Site Selector per bilanciare il traffico tra un gruppo di server basato sul nome dominio utilizzato su una richiesta del client.
Figura 23. Una configurazione Site Selector semplice
Per questo esempio di configurazione di avvio rapido, sono necessari i seguenti elementi:
In questo esempio di avvio rapido, il dominio del sito dell'azienda è mywebshop.com. Site Selector è responsabile di un dominio secondario all'interno di mywebshop.com. Quindi, è necessario definire un dominio secondario nell'ambito di mywebshop.com. Ad esempio: apps.mywebshop.com. Site Selector non è un DNS completamente implementato, come BIND, e svolge le funzioni di un nodo secondario in una gerarchia DNS. Site Selector è obbligatorio per il dominio secondario apps.mywebshop.com. Il dominio secondario apps.mywebshop.com include i nomi di sito seguenti: marketing.apps.mywebshop.com e developer.apps.mywebshop.com.
apps.mywebshop.com. IN NS siteselector.mywebshop.com
Site selector consente di creare una configurazione dalla riga comandi, con la configurazione guidata o mediante l'interfaccia utente grafica (GUI). In questo esempio di avvio rapido, le fasi di configurazione sono illustrate utilizzando la riga comandi.
Da un prompt dei comandi, effettuare le seguenti operazioni:
sscontrol nameserver start
sscontrol sitename add marketing.apps.mywebshop.com
sscontrol sitename add developer.apps.mywebshop.com
sscontrol server add marketing.apps.mywebshop.com:server1+server2
sscontrol server add developer.apps.mywebshop.com:server3+server4
sscontrol manager start
sscontrol advisor start http marketing.apps.mywebshop.com:80
sscontrol advisor start ftp developer.apps.mywebshop.com:21
Il Site Selector garantisce, a questo punto, che le richieste client non verranno inviate a un server in errore.
La configurazione Site Selector base è ora completa.
Verificare se la configurazione è in esecuzione:
sscontrol server status marketing.apps.mywebshop.com:
sscontrol server status developer.apps.mywebshop.com:
Il totale delle voci corrispondenti di ciascun server dovrebbe aggiungersi alla richiesta di ping e dell'applicazione
Per informazioni sull'uso della GUI di Site Selector, vedere GUI e Appendice A, GUI: istruzioni generali.
Per informazioni sull'uso della procedura guidata di Site Selector, vedere Procedura guidata di configurazione.
Questo capitolo descrive i fattori che un responsabile della pianificazione di rete deve considerare prima di installare e configurare il componente Site Selector.
Questo capitolo include le seguenti sezioni:
Site Selector interagisce con un DNS (Domain Name Server) per eseguire il bilanciamento del carico tra un gruppo di server utilizzando le misure e i pesi raccolti. È possibile creare una configurazione del sito per consentire il bilanciamento del carico del traffico tra un gruppo di server basato sul nome dominio utilizzato per una richiesta del client.
Limitazioni:: le interrogazioni DNS supportate da Site Selector sono solo le interrogazioni di Tipo A. Tutti gli altri tipi di interrogazione restituiranno un codice di errore NOTIMPL (non implementato). Se un intero dominio è delegato su Site Selector, verificare che il dominio riceva solo interrogazioni di Tipo A.
Figura 24. Esempio di un ambiente DNS
Durante la configurazione di un sottodominio di Site Selector nell'ambiente DNS, Site Selector deve disporre dell'autorità sul sottodominio. Ad esempio (vedere la Figura 24), all'azienda viene assegnata l'autorità sul dominio company.com. Nell'azienda, sono disponibili alcuni sottodomini. In questo caso, Site Selector avrebbe l'autorità per siteload.company.com, mentre i server DNS manterrebbero quella per atlanta.company.com e boston.company.com .
Affinché il server dei nomi dell'azienda riconosca l'autorità di Site Selector sul sottodominio siteload, è necessario aggiungere una voce server dei nomi al relativo file di dati denominato. Ad esempio, sui sistemi AIX, una voce server dei nomi potrebbe essere:
siteload.company.com. IN NS siteselector.company.com.
Dove siteselector.company.com è il nome host della macchina Site Selector. Voci equivalenti dovrebbero essere inserite in altri file database denominati per l'uso da parte dei server DNS.
Un client invia una richiesta di risoluzione di un nome dominio a un server dei nomi presente nella rete. Il server dei nomi inoltra la richiesta alla macchina Site Selector. Quindi, Site Selector risolve il nome dominio nell'indirizzo IP di uno dei server configurati per quel nome del sito. Site Selector restituisce l'indirizzo IP del server selezionato al server dei nomi. Il server dei nomi restituisce l'indirizzo IP al client. (Site Selector funziona come un server dei nomi non ricorsivo (nodo secondario) e restituisce un errore nel caso in cui non risolva la richiesta del nome dominio.)
Fare riferimento alla Figura 5 che illustra un sito in cui Site Selector viene utilizzato insieme a un sistema DNS per eseguire il bilanciamento del carico attraverso i server locali e remoti.
Site Selector è composto dalle seguenti funzioni:
L'uso del gestore è facoltativo. Tuttavia, se il gestore non viene utilizzato, il bilanciamento del carico verrà eseguito utilizzando la pianificazione con il metodo round-robin basata sui pesi dei server correnti e gli advisor non saranno disponibili.
Insieme a Metric Server, Site Selector può monitorare il livello di attività su un server, rilevare un server che sta elaborando un carico inferiore rispetto agli altri e individuare un server in errore. Il carico misura il traffico sul server. L'amministratore del sistema di Site Selector controlla il tipo di misurazione utilizzato per calcolare il carico. È possibile configurare Site Selector in base all'ambiente, prendendo in considerazione fattori quali la frequenza degli accessi, il numero totale degli utenti e i tipi di accesso (ad esempio, query brevi e lunghe oppure carichi che richiedono molto spazio sulla CPU).
Il bilanciamento del carico si basa sui pesi dei server. Per Site Selector, il gestore utilizza quattro proporzioni per stabilire i pesi:
I valori della CPU e della memoria sono tutti forniti da Metric Server. Di conseguenza, l'uso di Metric Server è consigliato con il componente Site Selector.
Per ulteriori informazioni, vedere Metric Server.
Le quattro funzioni chiave di Site Selector (server dei nomi, gestore, Metric Server e advisor) interagiscono per bilanciare e distribuire le richieste in entrata tra i server.
L'uso del bilanciamento del carico basato su DNS richiede che la memorizzazione nella cache delle risoluzioni dei nomi venga disabilitata. Il valore TTL (time to live) determina la funzionalità del bilanciamento del carico basato su DNS. TTL determina il tempo durante il quale un altro server dei nomi memorizzerà nella cache la risposta risolta. I valori TTL ridotti consentono la realizzazione più rapida di piccole modifiche al carico del server o della rete. Tuttavia, disabilitando la memorizzazione nella cache i client devono contattare il server dei nomi autorevole per tutte le richieste di risoluzione dei nomi, aumentando potenzialmente la latenza del client. Quando si sceglie un valore TTL, prestare particolare attenzione all'impatto che la disabilitazione della memorizzazione nella cache ha su un ambiente. Inoltre, tenere presente che il bilanciamento del carico basato su DNS è potenzialmente limitato dalla memorizzazione nella cache lato client delle risoluzioni dei nomi.
È possibile configurare TTL utilizzando il comando sscontrol sitename [add | set] . Per ulteriori informazioni, vedere sscontrol sitename -- configura un sitename.
La prossimità della rete è il calcolo della vicinanza di ciascun server al client richiedente. Per stabilire tale prossimità, l'agente Metric Server (che deve risiedere su ciascun server con bilanciamento del carico) invia un ping all'indirizzo IP client e restituisce il tempo di risposta a Site Selector. Site Selector utilizza la risposta di prossimità nella decisione di bilanciamento del carico. Site Selector combina il valore di risposta della prossimità della rete con il peso proveniente dal gestore per creare un peso finale combinato per il server.
L'uso della funzione di prossimità della rete con Site Selector è facoltativo.
Site Selector fornisce le seguenti opzioni di prossimità della rete che possono essere impostate per nome del sito:
Se impostata su sì (yes), Metric Server invia il ping al client per ottenere il tempo di risposta della prossimità. Il server dei nomi attende tutte le risposte di Metric Servers oppure attende che si verifichi un timeout. Quindi, per ciascun server, il server dei nomi combina il tempo di risposta della prossimità con il peso del gestore calcolato per creare un valore del "peso combinato" per ciascun server. Site Selector fornirà al client l'indirizzo IP del server con il miglior peso combinato. (Si prevede che la maggior parte dei server dei nomi client abbia un timeout di 5 secondi. Site Selector tenta di rispondere prima che venga superato questo timeout).
Se impostato su no, verrà fornita al client una risoluzione dei nomi basata sui pesi correnti del gestore. Quindi, Metric Server invia un ping al client per ottenere il tempo di risposta della prossimità. il server dei nomi memorizza nella cache il tempo di risposta ricevuto da Metric Server. Quando il client effettua una seconda richiesta, il server dei nomi combina il peso del gestore corrente con il valore della risposta ping memorizzato nella cache per ciascun server per ottenere il server con il miglior "peso combinato". Site Selector restituisce questo indirizzo IP del server al client per la seconda richiesta.
Le opzioni di prossimità della rete possono essere impostate sul comando sscontrol sitename [add | set] . Per ulteriori informazioni, vedere Riferimento sui comandi per Site Selector.
Prima di eseguire le operazioni riportate in questo capitolo, vedere Pianificazione di Site Selector. Questo capitolo illustra come creare una configurazione di base per il componente Site Selector di Load Balancer.
Tabella 12. Attività di configurazione per il componente Site Selector
Attività | Descrizione | Informazioni correlate |
---|---|---|
Configurazione della macchina Site Selector. | Individuazione dei requisiti. | Configurazione della macchina Site Selector |
Configurazione delle macchine da sottoporre a bilanciamento del carico. | Configurazione del bilanciamento del carico. | Fase 4. Definizione delle macchine server con bilanciamento del carico |
Per creare una configurazione di base del componente Site Selector di Load Balancer, sono disponibili quattro metodi di base di configurazione del componente Site Selector:
È il mezzo più diretto per la configurazione di Site Selector. i valori dei parametri dei comandi devono essere immessi utilizzando l'alfabeto inglese. Le uniche eccezioni riguardano i nomi host, (utilizzati ad esempio nei comandi site name e server) e i nomi di file.
Per avviare il componente Site Selector dalla riga comandi:
È possibile immettere una versione ridotta dei parametri del comando sscontrol. È sufficiente inserire le lettere che designano in modo univoco i parametri. Ad esempio, per richiamare la guida sul comando di salvataggio file, è possibile digitare sscontrol he f invece di sscontrol help file.
Per avviare l'interfaccia della riga comandi: immettere sscontrol per ricevere un prompt dei comandi per sscontrol.
Per chiudere l'interfaccia della riga comandi: emettere exit o quit.
I comandi per la configurazione di Site Selector possono essere inseriti in un file di script della configurazione ed essere eseguiti insieme.
sscontrol file appendload myscript
sscontrol file newload myscript
Per salvare la configurazione corrente nel file di script (ad esempio, savescript), eseguire il comando:
sscontrol file save savescript
Questo comando salva il file di script della configurazione nella directory ...ibm/edge/lb/servers/configurations/ss.
Per istruzioni generali e un esempio della GUI, vedere Figura 41.
Per avviare la GUI, effettuare le seguenti operazioni.
Per configurare il componente Site Selector dalla GUI, è necessario anzitutto selezionare Site Selector nella struttura ad albero. Se connessi a un host su cui è in esecuzione ssserver, è possibile creare i nomi dei siti contenenti i server, avviare il gestore e avviare gli advisor.
La GUI può essere utilizzata per eseguire le operazioni che verrebbero effettuate con il comando sscontrol. Per definire, ad esempio, un nome del sito utilizzando la riga comandi, si deve immettere il comando sscontrol sitename add sitename. Per definire un nome del sito dalla GUI, fare clic con il pulsante destro del mouse su Name Server, quindi nel menu a comparsa fare clic su Add Site Name. Immettere il nome del sito nella finestra a comparsa, quindi fare clic su OK.
I file di configurazione Site Selector esistenti possono essere caricati utilizzando l'opzione Load New Configuration (per sostituire completamente la configurazione corrente) e l'opzione Append to Current Configuration (per aggiornare la configurazione corrente), contenute nel menu a comparsa Host. Salvare periodicamente la configurazione di Site Selector in un file utilizzando l'opzione Save Configuration File As contenuta nel menu a comparsa Host. Il menu File situato sulla parte superiore della GUI consente di salvare le connessioni host correnti in un file o di ripristinare le connessioni nei file esistenti per tutti i componenti di Load Balancer.
Per eseguire un comando dalla GUI: evidenziare il nodo Host dalla struttura ad albero della GUI e selezionare Send command.... dal relativo menu a comparsa. Nel campo di immissione dei comandi, digitare il comando che si desidera eseguire, ad esempio: nameserver status. I risultati e la cronologia dei comandi in esecuzione nella sessione corrente vengono visualizzati nella finestra fornita.
È possibile accedere alla guida ? facendo clic sull'icona punto interrogativo nell'angolo in alto a destra della finestra di Load Balancer.
Per informazioni sull'uso della GUI, vedere Appendice A, GUI: istruzioni generali.
Se si utilizza la configurazione guidata, effettuare quanto segue:
ssserver
.È possibile avviare questa configurazione guidata dal prompt dei comandi immettendo sswizard. In alternativa, selezionare la procedura guidata di configurazione dal menu del componente Site Selector presente nella GUI.
La procedura guidata di configurazione di Site Selector illustra nei dettagli come creare una configurazione di base del componente Site Selector. Pone delle domande relative alla rete e fornisce le istruzioni su come configurare un nome del sito in modo che il componente Site Selector possa eseguire il bilanciamento del carico sul traffico esistente tra un gruppo di server.
Per poter configurare la macchina Site Selector, è necessario disporre dei diritti di utente root (su AIX, HP-UX, Linux o Solaris) o di amministratore (in Windows).
È necessario un nome host completo non risolvibile da utilizzare come nome del sito per un gruppo di server configurati. Il nome del sito è il nome che i client utilizzano per accedere al sito (ad esempio, www.yourcompany.com). Site Selector eseguirà il bilanciamento del carico del traffico per questo nome del sito tra il gruppo di server che utilizza DNS.
Per avviare la funzione server Site Selector, digitare ssserver sulla riga comandi.
Per avviare il Server dei nomi, immettere il comando sscontrol nameserver start.
Facoltativamente, avviare il Server dei nomi utilizzando la parola chiave bindaddress per collegarsi solo all'indirizzo specificato.
Site Selector esegue il bilanciamento delle richieste inviate per il nome sito sui rispettivi server configurati su di esso.
Il nome sito è un nome host non risolvibile che viene richiesto dal client. Il nome sito deve essere un nome dominio completo (ad esempio, www.dnsdownload.com). Quando un client richiede questo nome sito, verrà restituito uno degli indirizzi IP del server ad esso associati.
Per definire un nome sito, immettere il seguente comando:
sscontrol sitename add sitename
Per impostare le opzioni del nome sito, immettere il seguente comando:
sscontrol sitename set valore opzione sitename
Per ulteriori informazioni sui comandi, vedere Riferimento sui comandi per Site Selector.
Le macchine server sono le macchine su cui vengono eseguite le applicazioni che si desidera sottoporre a bilanciamento del carico. Server è il nome simbolico o l'indirizzo decimale separato da punti della macchina server. Per definire un server sul nome sito dalla fase 3, immettere il seguente comando:
sscontrol server add sitename:server
Per poter effettuare un bilanciamento del carico, è necessario definire più di un server per il nome del sito.
La funzione gestore migliora il bilanciamento del carico. Prima di avviare la funzione gestore, verificare che il server delle metriche sia installato in tutte le macchine con bilanciamento del carico.
Per avviare il gestore, immettere il seguente comando:
sscontrol manager start
Gli advisor forniscono al gestore ulteriori informazioni sulla capacità delle macchine server con bilanciamento del carico di rispondere alle richieste. Un advisor è specifico di un protocollo. Load Balancer fornisce molti advisor. Ad esempio, per avviare l'advisor HTTP per un nome del sito specifico, immettere il seguente comando:
sscontrol advisor start http sitename:port
Per informazioni sull'utilizzo delle metriche di sistema e su Metric Server, vedere Metric Server.
Se si avviano gli advisor, è possibile modificare le proporzioni di importanza attribuite alle informazioni dall'advisor (porta) che devono essere incluse nelle decisioni relative al bilanciamento del carico. Per impostare le proporzioni del nome sito, sscontrol sitename set sitename proporzioni. Per ulteriori informazioni, vedere Proporzione di importanza attribuita alle informazioni sullo stato.
Utilizzare Metric Server con il componente Site Selector. Per informazioni sulla configurazione di Metric Server su tutte le macchine server per cui Site Selector sta eseguendo il bilanciamento del carico, vedere Metric Server.
Questa sezione fornisce informazioni per una rapida configurazione, considerazioni sulla pianificazione e descrive i metodi di configurazione del componente Cisco CSS Controller di Load Balancer. Contiene i seguenti capitoli:
Questo esempio di avvio rapido illustra come creare una configurazione utilizzando il componente Cisco CSS Controller. Cisco CSS Controller fornisce informazioni sui pesi dei server che supportano Cisco CSS Switch nella determinazione e selezione del server più adatto per le decisioni sul bilanciamento del carico.
Figura 25. Una configurazione semplice di Cisco CSS Controller locale
Per questo esempio di configurazione di avvio rapido, sono necessari i seguenti elementi:
Prima di iniziare la configurazione per questo esempio, verificare che i passi seguenti siano stati completati:
Con Cisco CSS Controller, è possibile creare una configurazione dalla riga comandi o mediante l'interfaccia utente grafica (GUI). In questo esempio di avvio rapido, le fasi di configurazione sono illustrate utilizzando la riga comandi.
Da un prompt dei comandi, effettuare le seguenti operazioni:
ccocontrol consultant add SwConsultant-1 address 9.17.32.50 community public
Questo consente di controllare la connettività a Cisco CSS Switch e verificare che il nome comunità di SNMP in lettura/scrittura funzioni correttamente.
ccocontrol ownercontent add SwConsultant-1:OwnerContent-1 ownername OwnerName-1 contentrule ContentRule-1
Questi valori devono corrispondere agli attributi su Cisco CSS Switch.
Cisco CSS Controller può ora comunicare con lo switch sul protocollo SNMP e ottenere così le necessarie informazioni sulla configurazione provenienti dallo switch. Dopo questa fase, in Cisco CSS Switch è possibile esaminare le informazioni sui servizi che sono stati configurati su Cisco CSS Switch per ownercontent specificato.
ccocontrol ownercontent metrics SwConsultant-1:OwnerContent-1 activeconn 45 connrate 45 http 10
Questo comando configura le informazioni metriche e le proporzioni che si desidera ottenere dai servizi in modo da poterli utilizzare per il calcolo dei pesi. Il totale delle proporzioni di tutte le metriche deve essere 100.
ccocontrol consultant start SwConsultant-1
Questo comando consente di avviare tutti gli strumenti di raccolta delle metriche e iniziare i calcoli sui pesi dei servizi. Cisco CSS Controller comunica i risultati dei calcoli eseguiti sui pesi dei servizi a Cisco CSS Switch tramite SNMP.
La configurazione di Cisco CSS Controller di base è ora completa.
Verificare se la configurazione è in esecuzione:
Per informazioni sull'uso della GUI di Cisco CSS Controller, vedere GUI e Appendice A, GUI: istruzioni generali.
Questo capitolo descrive i fattori che il responsabile della pianificazione di rete deve considerare, prima di installare e configurare il componente Cisco CSS Controller.
Questo capitolo include:
Per i requisiti di sistema hardware e software, compresi i browser supportati, fare riferimento alla seguente pagina Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
Inoltre, sarà necessario
Cisco CSS Controller gestisce una serie di consultant dello switch. Ciascun consultant stabilisce i pesi per i servizi il cui bilanciamento dei carichi viene eseguito da uno switch singolo. Lo switch per cui il consultant fornisce i pesi viene configurato per il bilanciamento del carico dei contenuti. Il consultant utilizza il protocollo SNMP per inviare i pesi calcolati allo switch. Lo switch utilizza i pesi per selezionare un servizio per la regola di contenuto per cui sta eseguendo il bilanciamento del carico quando l'algoritmo del bilanciamento del carico è caricato con il metodo round-robin. Per determinare i pesi, il consultant utilizza una o più delle seguenti parti di informazioni:
Vedere Cisco Content Services Switch Getting Started Guide per una descrizione del bilanciamento del carico dei contenuti e per informazioni dettagliate sulla configurazione dello switch.
Affinché un consultant ottenga le informazioni per determinare i pesi dei servizi, deve disporre di:
Come indicato nella Figura 26, il consultant deve essere connesso alla rete dietro lo switch o gli switch per cui fornisce i pesi. Alcuni parametri devono essere configurati sullo switch e alcuni sul controller per abilitare la connettività tra il controller, lo switch e i servizi.
Nella Figura 26:
Per informazioni dettagliate sulla configurazione delle VLAN e dell'indirizzamento IP sullo switch, fare riferimento a Cisco Content Services Switch Getting Started Guide per informazioni dettagliate sulla configurazione delle VLAN e dell'indirizzamento IP sullo switch.
Figura 26. Esempio di un consultant connesso dietro gli switch
È possibile gestire Cisco CSS Controller utilizzando le seguenti interfacce:
Per la gestione remota, nella Figura 27 :
Per informazioni dettagliate, fare riferimento a Cisco Content Services Switch Getting Started Guide.
La disponibilità elevata del controller migliora le funzioni di tolleranza degli errori di Load Balancer. Progettata sulla base della disponibilità elevata dell'inoltro del package, la disponibilità elevata del controller riguarda i due controller in esecuzione contemporaneamente, uno nel ruolo principale e l'altro in quello secondario.
Ciascun controller è configurato con le stesse informazioni sullo switch ed è attivo solo un controller alla volta. Ciò significa che, come stabilito dalla logica della disponibilità elevata, solo il controller attivo calcola e aggiorna lo switch con nuovi pesi.
La disponibilità elevata del controller comunica con i partner tramite i pacchetti UDP (user datagram protocol) semplici su un indirizzo e una porta configurati dall'utente. Questi pacchetti vengono utilizzati per consentire lo scambio di informazioni tra i controller relative alla disponibilità elevata (informazioni sull'accessibilità) e per determinare la disponibilità dei controller partner (heartbeat). Se il controller in standby stabilisce che il controller attivo non funziona per qualche motivo, il controller in standby diventa quello attivo. Il controller di standby, quindi, diventa il controller attivo e inizia a calcolare e aggiornare lo switch con i nuovi pesi.
Oltre alla disponibilità dei partner, le destinazioni accessibili possono essere configurate per la disponibilità elevata. La disponibilità elevata del controller utilizza le informazioni sull'accessibilità per stabilire quale controller è attivo e quale in standby. Il controller attivo è quello che può eseguire il ping di più destinazioni e che è accessibile dai relativi partner.
Per ulteriori informazioni, vedere Disponibilità elevata.
Se il consultant stabilisce che un servizio non è disponibile, sospende quel servizio sullo switch per impedire che quest'ultimo consideri il server nelle richieste di bilanciamento del carico. Quando il servizio è nuovamente disponibile, il consultant attiva il servizio sullo switch in modo che venga considerato per le richieste di bilanciamento del carico.
Cisco CSS Controller invia le voci ai seguenti log:
Questi log sono disponibili nelle seguenti directory:
In ciascun log, è possibile impostare le dimensioni e il livello del log. Per ulteriori informazioni, vedere Utilizzo dei log di Balancer.
Prima di eseguire le operazioni riportate in questo capitolo, vedere Pianificazione di Cisco CSS Controller. Questo capitolo illustra come creare una configurazione di base per il componente Cisco CSS Controller di Load Balancer.
Prima di iniziare qualsiasi metodo di configurazione riportato in questo capitolo:
Tabella 13. Attività di configurazione per il componente Cisco CSS Controller
Attività | Descrizione | Informazioni correlate |
---|---|---|
Configurazione della macchina Cisco CSS Controller | Individuazione dei requisiti | Configurazione di Controller per la macchina Cisco CSS Switch |
Verifica della configurazione | Conferma che configurazione funziona correttamente | Verifica della configurazione |
Per creare una configurazione base del componente Cisco CSS Controller di Load Balancer, sono disponibili tre metodi:
Questo metodo è il mezzo più diretto di configurazione di Cisco CSS Controller. Le procedure descritte nel presente manuale presumono l'uso della riga comandi. i valori dei parametri del comando devono essere immessi utilizzando l'alfabeto inglese. Le uniche eccezioni riguardano i nomi host (utilizzati ad esempio nei comandi consultant add) e i nomi di file.
Per avviare Cisco CSS Controller dalla riga comandi:
Note:
È possibile immettere una versione abbreviata dei parametri del comando ccocontrol. È sufficiente inserire le lettere che designano in modo univoco i parametri. Ad esempio, per visualizzare le informazioni sul comando di salvataggio del file, è possibile digitare ccocontrol he f invece di ccocontrol help file.
Per avviare l'interfaccia della riga comandi: immettere ccocontrol per ricevere un prompt dei comandi per ccocontrol.
Per chiudere l'interfaccia della riga comandi: emettere exit o quit.
La configurazione attualmente definita può essere salvata su un file XML. In questo modo, la configurazione può essere caricata in un momento successivo quando si desidera creare rapidamente la configurazione.
Per eseguire il contenuto di un file XML (ad esempio, myscript.xml), utilizzare uno dei seguenti comandi:
ccocontrol file save XMLFilename
ccocontrol file load XMLFileName
Utilizzare il comando load solo se precedentemente è stato eseguito un comando file save.
I file XML vengono salvati nella directory ...ibm/edge/lb/servers/configurations/cco/.
Per istruzioni generali e un esempio della GUI, vedere Figura 41.
Per avviare la GUI, effettuare le seguenti operazioni.
ccoserver.
Per configurare il componente Cisco CSS Controller dalla GUI:
La GUI può essere utilizzata per eseguire le operazioni che verrebbero effettuate con il comando ccocontrol. Ad esempio:
Per eseguire un comando dalla GUI:
I risultati e la cronologia dei comandi eseguiti nella sessione corrente vengono visualizzati nella casella Result.
Per accedere alla guida ?, fare clic sull'icona punto interrogativo nell'angolo in alto a destra della finestra di Load Balancer.
Per informazioni sull'uso della GUI, vedere Appendice A, GUI: istruzioni generali.
Per poter configurare la macchina Cisco CSS Controller, è necessario disporre dei diritti di utente root (in AIX, HP-UX, Linux o Solaris) o di amministratore (in Windows).
Il consultant deve essere in grado di collegarsi a Cisco CSS Switch come amministratore di Cisco CSS Switch.
Durante la configurazione del consultant, è necessario configurare l'indirizzo e il nome comunità SNMP in modo che corrispondano agli attributi su Cisco CSS Switch.
Per informazioni sui comandi utilizzati in questa procedura, vedere Riferimento sui comandi per Cisco CSS Controller.
Se ccoserver non è già in esecuzione, digitare ccoserver come root per avviarlo.
Digitare ccocontrol per avviare l'interfaccia della riga comandi.
Configurare l'indirizzo switch e il nome comunità SNMP. Questi valori devono corrispondere agli attributi su Cisco CSS Switch.
Per aggiungere un consultant, digitare:
consultant add switchConsultantID address switchIPAddress community communityName
Un ownercontent è la rappresentazione di una regola di contenuto di un proprietario definita su Cisco CSS Switch. Il nome proprietario e il nome della regola di contenuto devono corrispondere con quelli definiti sullo switch.
Per definire un ownercontent, digitare:
ownercontent add switchConsultantID:ownercontentID ownername ownerName contentrule contentRuleName
Quando viene definito ownercontent, il consultant completa la configurazione richiamando i servizi configurati sullo switch. Confrontare la configurazione sullo switch con quella per il consultant per verificare che i servizi corrispondano.
Le metriche sono le misurazioni utilizzate per stabilire i pesi dei servizi e le proporzioni associate (l'importanza di una metrica rispetto ad un'altra) e possono essere costituite da qualsiasi combinazione di metriche dei dati di connessione, degli advisor delle applicazioni e dei server delle metriche. La somma delle proporzioni deve essere sempre pari a 100.
Quando viene configurato l'ownercontent, le metriche predefinite vengono indicate come activeconn e connrate. Se si desiderano metriche aggiuntive o metriche completamente diverse da quelle predefinite, digitare:
ownercontent metrics switchConsultantID:ownercontentID metric1 proportion1 metric2 proportion2...metricN proportionN
Per avviare il consultant, digitare:
consultant start switchConsultantID
In questo modo, vengono avviati gli strumenti di raccolta delle metriche e viene avviato il calcolo dei pesi.
Se le metriche del sistema vengono definite nella fase 5, il server delle metriche deve essere avviato sulle metriche del servizio. Per informazioni sull'utilizzo delle metriche di sistema e su Metric Server, vedere Metric Server.
Per configurare la disponibilità elevata, digitare:
highavailability add address IPaddress partneraddress IPaddress port 80 role primary
In un ambiente a disponibilità elevata, è possibile configurare più switch. Per garantire che le informazioni sui pesi siano sempre disponibili quando uno switch di backup diventa attivo prendendo il posto di un altro switch, Cisco CSS Controller deve essere configurato per fornire i pesi per tutti gli switch e i relativi backup.
Per informazioni dettagliate su come utilizzare e configurare la disponibilità elevata del controller, vedere Funzioni avanzate per Cisco CSS Controller e Nortel Alteon Controller.
Verificare se la configurazione è in esecuzione:
Questa sezione fornisce informazioni per una rapida configurazione, considerazioni sulla pianificazione e descrive i metodi di configurazione del componente Nortel Alteon Controller di Load Balancer. Contiene i seguenti capitoli:
Questo esempio di avvio rapido illustra come creare una configurazione utilizzando il componente Nortel Alteon Controller. Nortel Alteon Controller fornisce i pesi del server allo switch Web di Nortel Alteon. Questi pesi vengono utilizzati per selezionare i server per i servizi su cui lo switch sta eseguendo il bilanciamento del carico.
Figura 28. Una configurazione semplice di Nortel Alteon Controller
Per questo esempio di configurazione di avvio rapido, sono necessari i seguenti elementi:
Prima di iniziare la configurazione per questo esempio, verificare che i passi seguenti siano stati completati:
Con Nortel Alteon Controller, è possibile creare una configurazione dalla riga comandi o mediante l'interfaccia utente grafica (GUI). In questo esempio di avvio rapido, le fasi di configurazione sono illustrate utilizzando la riga comandi.
Da un prompt dei comandi, effettuare le seguenti operazioni:
nalcontrol consultant add Consultant-1 address 9.87.32.50
Questo consente di controllare la connettività a Nortel Alteon Web Switch e verificare che i nomi comunità di SNMP funzionino correttamente.
nalcontrol service add Consultant-1:Service-1 vsid 1 vport 80
Nortel Alteon Controller comunicherà ora con lo switch sul protocollo SNMP e otterrà così le necessarie informazioni sulla configurazione provenienti dallo switch. Dopo questa fase, in è possibile esaminare le informazioni sui server che sono stati configurati su Nortel Alteon Web Switch per il servizio.
nalcontrol service metrics Consultant-1:Service-1 http 40 activeconn 30 connrate 30
Questo comando configura le informazioni metriche che si desidera raccogliere dai server e l'importanza relativa di tali metriche durante il calcolo dei pesi.
nalcontrol consultant start Consultant-1
Questo comando consente di avviare tutti gli strumenti di raccolta delle metriche e iniziare i calcoli sui pesi dei server. Nortel Alteon Controller comunica i risultati dei calcoli eseguiti sui pesi dei server a Nortel Alteon Web Switch tramite SNMP.
La configurazione di Nortel Alteon Controller di base è ora completa.
Verificare se la configurazione è in esecuzione:
Per informazioni sull'uso della GUI di Nortel Alteon Controller, vedere GUI e Appendice A, GUI: istruzioni generali.
Questo capitolo descrive i fattori che il responsabile della pianificazione di rete deve considerare prima di installare e configurare il componente Nortel Alteon Controller.
Questo capitolo include:
Per i requisiti di sistema hardware e software, compresi i browser supportati, fare riferimento alla seguente pagina Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
Inoltre, sarà necessario
Nortel Alteon Controller gestisce una serie di consultant dello switch. Ciascun consultant stabilisce i pesi per i server il cui bilanciamento dei carichi viene eseguito da uno switch singolo. Lo switch per cui il consultant fornisce i pesi viene configurato per il bilanciamento del carico dei server. Il consultant utilizza il protocollo SNMP per inviare i pesi calcolati allo switch. Lo switch utilizza i pesi per selezionare un server per il servizio per cui sta eseguendo il bilanciamento del carico. Per determinare i pesi, il consultant utilizza una o più delle seguenti parti di informazioni:
Vedere Nortel Alteon Web OS Application Guide per una descrizione del bilanciamento del carico dei server e per informazioni dettagliate sulla configurazione dello switch.
Affinché un consultant ottenga le informazioni per determinare i pesi dei server, deve disporre di:
Il consultant può essere connesso alla rete davanti o dietro lo switch o gli switch per cui fornisce i pesi. Alcuni parametri devono essere configurati sullo switch e alcuni sul controller per abilitare la connettività tra il controller, lo switch e i server.
Nella Figura 29:
Fare riferimento a Nortel Alteon Web OS Application Guide o Command Reference per informazioni dettagliate sulla configurazione delle VLAN e dell'indirizzamento IP sullo switch.
Figura 29. Esempio di consultant connesso dietro lo switch
Nella Figura 30:
Figura 30. Esempio
di consultant connesso attraverso una rete intranet davanti allo switch
È possibile gestire Nortel Alteon Controller utilizzando le seguenti interfacce:
Nella Figura 31:
Figura 31. Esempio di consultant dietro lo switch e dell'interfaccia utente davanti allo switch
Quando un consultant calcola i pesi per i server che forniscono un servizio sottoposto a bilanciamento del carico da uno switch, il consultant disabilita il controllo dello stato normale del server sullo switch per ridurre il traffico inutile sui server. Il consultant riabilita il controllo dello stato quando interrompe l'invio dei pesi per il servizio. L'intervallo dei controlli dello stato del server corrisponde alla variabile MIB slbNewCgRealServerPingInterval.
Se il consultant stabilisce che un server non è disponibile, il consultant imposta il numero massimo di connessioni del server su zero per impedire che lo switch consideri il server nelle richieste di bilanciamento del carico. Quando il server è nuovamente disponibile, il numero massimo di connessioni viene riportato al valore originale. Il valore del numero massimo di connessioni al server corrisponde alla variabile MIB slbNewCfgRealServerMaxCons.
Quando viene calcolato il peso di un server effettivo, il peso viene impostato per il server. Il valore del peso del server corrisponde alla variabile MIB slbNewCfgRealServerWeight.
Lo switch consente la configurazione di alcuni server come backup di altri. Se lo switch stabilisce che un server con un backup non è disponibile, tale switch può iniziare ad inviare le richieste al backup. Quando il consultant calcola i pesi per un servizio con un backup, li calcola per entrambi i server di backup e principale e, successivamente, utilizza i pesi per la scelta del server di backup necessario.
Il peso per un server di backup potrebbe essere superiore a quello per un server principale. Questo perché nessuna richiesta viene inoltrata a quest'ultimo che, quindi, ha pesi ridotti fino a quando lo switch non decide di utilizzarli.
Per evitare risorse inutilizzate dei server, solitamente i server assegnati a un servizio vengono utilizzati come backup per i server assegnati a un servizio differente. Durante l'implementazione di una configurazione simile a questa, evitare di assegnare gli stessi server effettivi a più server attivi contemporaneamente. Se ciò si verifica, il peso per il server viene sovrascritto dal consultant per ciascun servizio di cui fa parte il server.
Ciascun server effettivo viene identificato da un numero intero e ha un peso e un attributo indirizzo IP. Due server effettivi potrebbero avere lo stesso indirizzo IP. In questo caso, i due server effettivi vengono associati alla stessa macchina server fisica. I server effettivi identificati come backup devono essere configurati esclusivamente come backup di un singolo servizio. Se le stesse macchine server fisiche rappresentano i server di backup assegnati a più servizi, devono essere configurate una volta per ciascun servizio e devono ricevere un'identificazione server univoca per ciascun servizio. Questo consente ai server di backup di avere un peso univoco per ciascun servizio di cui rappresentano il backup.
Figura 32. Esempio di consultant configurato con server di backup
I server su uno switch possono essere configurati come parte di più gruppi e i gruppi sullo switch possono essere configurati per più servizi.
Poiché è possibile configurare lo stesso server per più servizi, il peso verrà calcolato per ciascun servizio di cui fa parte il server. È possibile, quindi, che il peso non sia corretto poiché il servizio per cui è previsto quel peso non si conosce.
Inoltre, se il consultant stabilisce i pesi per un servizio e non per un altro, è possibile che il servizio per cui il consultant non ha calcolato i pesi abbia il controllo dello stato dei server disabilitato. In questo caso, lo switch potrebbe non eseguire correttamente il bilanciamento del carico di quel servizio.
Per questi motivi, verificare che un server effettivo non sia assegnato a più servizi per cui viene eseguito il bilanciamento del carico. Ciò non significa che la stessa macchina server non può eseguire le richieste di più servizi ma che è necessario configurare un server effettivo sullo switch con un identificatore univoco per ciascun servizio per cui la macchina server gestisce le richieste.
Nortel Alteon Controller e Nortel Alteon Web Switch dispongono delle funzioni di disponibilità elevata.
È possibile configurare due controller da eseguire su sistemi differenti in una configurazione hot-standby.
Due o più switch possono agire l'uno come backup dell'altro se configurati per funzionare come VIR (virtual IP interface router) o come VSR (virtual IP server router).
Un consultant (gestito dal controller) fornisce i pesi per un solo switch. Poiché uno switch di backup può diventare attivo in qualsiasi momento e quindi diventare lo switch principale, è necessario configurare il controller con un consultant per ciascuno switch che ha la possibilità di diventare principale. In questo modo, quando uno switch diventa principale, disporrà sicuramente dei pesi necessari.
Inoltre, quando i controller sono connessi a un VIR, la comunicazione con i server, con gli switch e con il controller di backup è garantita, anche se dovesse perdere la connettività con uno degli switch.
Fare riferimento a Nortel Alteon Web OS Application Guide per informazioni sulla disponibilità elevata sullo switch.
La disponibilità elevata del controller migliora le funzioni di tolleranza degli errori di Load Balancer. Progettata sulla base della disponibilità elevata dell'inoltro del package classica, la disponibilità elevata del controller riguarda i due controller in esecuzione contemporaneamente, uno nel ruolo principale e l'altro in quello secondario.
Ciascun controller è configurato con le stesse informazioni sullo switch. Analogamente alla disponibilità elevata classica, è attivo solo un controller alla volta. Ciò significa che, come stabilito dalla logica della disponibilità elevata, solo il controller attivo calcola e aggiorna lo switch con nuovi pesi.
La disponibilità elevata del controller comunica con i partner tramite i pacchetti UDP (user datagram protocol) semplici su un indirizzo e una porta configurati dall'utente. Questi pacchetti vengono utilizzati per consentire lo scambio di informazioni tra i controller relative alla disponibilità elevata (informazioni sull'accessibilità) e per determinare la disponibilità dei controller partner (heartbeat). Se il controller in standby stabilisce che il controller attivo non funziona per qualche motivo, il controller in standby diventa quello attivo. Il controller di standby, quindi, diventa il controller attivo e inizia a calcolare e aggiornare lo switch con i nuovi pesi.
Oltre alla disponibilità dei partner, le destinazioni accessibili possono essere configurate per la disponibilità elevata. Come con la disponibilità elevata classica, la disponibilità elevata del controller utilizza le informazioni sull'accessibilità per stabilire quale controller è attivo e quale in standby. Il controller attivo è quello che può eseguire il ping di più destinazioni e che è accessibile dai relativi partner.
Per ulteriori informazioni, vedere Disponibilità elevata.
Nella Figura 33:
Per evitare continue variazioni di pesi, è possibile configurare il consultant con una soglia di sensibilità. Tale soglia specifica l'entità della variazione tra i vecchi e i nuovi pesi necessaria affinché un peso possa essere modificato. Per ulteriori informazioni, vedere Soglia di sensibilità.
Se lo switch diventa troppo occupato durante l'aggiornamento dei pesi, è possibile aumentare i tempi di inattività del consultant per ridurre il traffico tra il controller e i server e lo switch. Tali tempi impostano l'intervallo di inattività in secondi tra i cicli di impostazione dei pesi.
Se i server gestiscono troppe richieste di controllo provenienti dal consultant, è possibile modificare i tempi di inattività degli strumenti di raccolta delle metriche. Per una descrizione dettagliata, vedere Tempi di inattività nel calcolo dei pesi.
Cisco CSS Controller invia le voci ai seguenti log:
Questi log sono disponibili nelle seguenti directory:
In ciascun log, è possibile impostare le dimensioni e il livello del log. Per ulteriori informazioni, vedere Utilizzo dei log di Load Balancer.
Prima di eseguire le operazioni riportate in questo capitolo, vedere Pianificazione di Nortel Alteon Controller. Questo capitolo illustra come creare una configurazione di base per il componente Nortel Alteon Controller di Load Balancer.
Prima di iniziare qualsiasi metodo di configurazione riportato in questo capitolo, verificare che Nortel Alteon Web Switch e tutte le macchine server siano configurati correttamente.
Tabella 14. Attività di configurazione per il componente Nortel Alteon Controller
Attività | Descrizione | Informazioni correlate |
---|---|---|
Configurazione di Nortel Alteon Web Switch e dei server | Configurazione dello switch. | Configurazione dello switch, a pagina (SETSWITCH) |
Configurazione della macchina Nortel Alteon Controller | Configurazione del controller. | Fase 1. Avvio della funzione server |
Verifica della configurazione | Conferma della procedura di configurazione in corso | Verifica della configurazione |
Per creare una configurazione base del componente Nortel Alteon Controller di Load Balancer, sono disponibili tre metodi:
Questo metodo è il mezzo più diretto di configurazione di Nortel Alteon Controller. Le procedure descritte nel presente manuale presumono l'uso della riga comandi.
Per avviare Nortel Alteon Controller dalla riga comandi:
Note:
È possibile utilizzare una versione abbreviata dei parametri del comando nalcontrol, immettendo le lettere che designano in modo univoco i parametri. Ad esempio, per visualizzare la guida del comando di salvataggio file, è possibile immettere nalcontrol he f anziché nalcontrol help file.
Per terminare l'interfaccia della riga comandi: digitare exit o quit.
Note:
La configurazione attualmente definita può essere salvata su un file XML. In questo modo, la configurazione può essere caricata in un momento successivo quando si desidera creare rapidamente la configurazione.
Per eseguire il contenuto di un file XML (ad esempio, myscript.xml), utilizzare i seguenti comandi:
nalcontrol file save XMLFilename
Utilizzare il comando load solo se precedentemente è stato eseguito un comando file save.
nalcontrol file load XMLFileName
Utilizzare il comando load solo se precedentemente è stato eseguito un comando file save.
I file XML vengono salvati nella directory ...ibm/edge/lb/servers/configurations/nal/.
Per un esempio della GUI, vedere la Figura 41.
Per avviare la GUI:
Per configurare il componente Nortel Alteon Controller dalla GUI:
La GUI può essere utilizzata per eseguire le operazioni che verrebbero effettuate con il comando nalcontrol. Ad esempio:
Per eseguire un comando dalla GUI:
I risultati e la cronologia dei comandi eseguiti nella sessione corrente vengono visualizzati nella casella Result.
Per accedere alla guida, fare clic sull'icona punto interrogativo nell'angolo in alto a destra della finestra di Load Balancer.
Per informazioni sull'uso della GUI, vedere Appendice A, GUI: istruzioni generali.
Per informazioni sui comandi utilizzati in questa procedura, vedere Riferimento sui comandi per Nortel Alteon Controller.
Prima di configurare la macchina Nortel Alteon Controller:
Se nalserver non è già in esecuzione, digitare nalserver come root per avviarlo.
Digitare nalcontrol per avviare l'interfaccia della riga comandi.
Per aggiungere un consultant dello switch, digitare:
consultant add switchconsultantID address switchIPAddress
Per aggiungere un servizio, digitare:
service add switchConsultantID:serviceID vsid virtualServerID vport virtualPortNumber
Un servizio viene identificato da un VSID (identificatore server virtuale) e da un numero VPORT (porta virtuale), entrambi associati a un server virtuale precedentemente configurato sullo switch.
Le metriche sono le informazioni utilizzate per determinare i pesi del server. Ciascuna metrica viene assegnata a una proporzione per indicare l'importanza relativa ad altre metriche. È possibile configurare tutte le combinazioni di metriche: metriche dei dati di connessione, degli advisor delle applicazioni e dei server delle metriche. La somma delle proporzioni deve essere sempre pari a 100.
Quando viene configurato un servizio, le metriche predefinite vengono indicate come activeconn e connrate. Se si desiderano metriche aggiuntive o metriche completamente diverse da quelle predefinite, digitare:
service metrics switchConsultantID:serviceID metricName 50 metricName2 50
Per avviare il consultant, digitare:
consultant start switchConsultantID
In questo modo, vengono avviati gli strumenti di raccolta delle metriche e viene avviato il calcolo dei pesi.
Per configurare la disponibilità elevata, digitare:
highavailability add address IPaddress partneraddress IPaddress port 80 role primary
Per informazioni dettagliate su come configurare la disponibilità elevata del controller, vedere Funzioni avanzate per Cisco CSS Controller e Nortel Alteon Controller.
Se le metriche del sistema vengono definite nella fase 5, il server delle metriche deve essere avviato sulle metriche del servizio. Per informazioni sull'utilizzo di Metric Server, vedere Metric Server.
Se viene modificata la configurazione su Nortel Alteon Web Switch, è possibile aggiornare la configurazione del controller. Digitare:
service refresh
Si consiglia di arrestare il consultant prima di eseguire un aggiornamento della configurazione. Dopo aver aggiornato la configurazione tramite il comando refresh, riavviare il consultant.
Verificare se la configurazione è in esecuzione:
Questa sezione fornisce informazioni sulle funzioni e sulle caratteristiche avanzate di configurazione disponibili per Load Balancer. Contiene i seguenti capitoli:
Questo capitolo illustra come configurare i parametri per il bilanciamento del carico e come impostare le funzioni gestore, advisor e Metric Server di Load Balancer.
Tabella 15. Attività di configurazione configurate per Load Balancer
Attività | Descrizione | Informazioni correlate |
---|---|---|
Facoltativamente, modificare le impostazioni di bilanciamento del carico |
È possibile modificare le seguenti impostazioni di bilanciamento del carico:
| Ottimizzazione del bilanciamento del carico fornito da Load Balancer |
Utilizzo degli script per generare un avviso o registrare un malfunzionamento dei server quando il gestore contrassegna i server come attivi/inattivi | Load Balancer fornisce uscite utente che attivano script personalizzabili quando il gestore contrassegna i server come attivi/inattivi. | Utilizzo degli script per generare un avviso o registrare un malfunzionamento dei server |
Utilizzo degli advisor | Descrive ed elenca gli advisor che notificano stati specifici dei server | Advisor |
Utilizzo dell'opzione di richiesta/risposta (URL) degli advisor HTTP o HTTPS | Definisce una stringa URL HTTP client univoca, specifica per un servizio che si desidera interrogare sulla macchina | Configurazione dell'advisor HTTP o HTTPS utilizzando l'opzione richiesta/risposta (URL) |
Utilizzo di advisor autonomo | Fornisce lo stato di carico sul server di backend in una configurazione WAN a due livelli di Load Balancer | Utilizzo dell'advisor autonomo in una configurazione WAN a due livelli |
Creazione di advisor personalizzati | Descrive come scrivere gli advisor personalizzati | Creazione di advisor personalizzati (personalizzabili) |
Utilizzo dell'agente Metric Server | Metric Server fornisce le informazioni sul carico del sistema a Load Balancer | Metric Server |
Utilizzo dell'advisor WLM (Workload Manager) | L'advisor WLM fornisce le informazioni sul carico del sistema a Load Balancer | Advisor Workload Manager |
La funzione gestore di Load Balancer esegue il bilanciamento del carico in base alle seguenti impostazioni:
Queste impostazioni possono essere modificate per ottimizzare il bilanciamento del carico nella rete in uso.
Nelle decisioni relative al calcolo dei pesi, il gestore può utilizzare completamente o in parte i seguenti fattori esterni
Oppure --
CPU: la percentuale di CPU in uso su ciascuna macchina server con bilanciamento del carico (input dell'agente Metric Server). Esclusivamente per Site Selector, questa proporzione viene visualizzata al posto della colonna delle proporzioni delle connessioni attive.
Oppure --
Memoria: la percentuale di memoria in uso (input dell'agente Metric Server) su ciascun server con bilanciamento del carico. Esclusivamente per Site Selector, questa proporzione viene visualizzata al posto della colonna delle proporzioni delle connessioni nuove.
Insieme al peso corrente di ciascun server e ad altre informazioni necessarie per i relativi calcoli, il gestore ottiene i primi due valori (connessioni nuove e attive) dall'executor. Questi valori si basano sulle informazioni generate e memorizzate internamente nell'executor.
È possibile modificare la proporzione relativa di importanza da attribuire ai quattro valori metrici per ciascun cluster (o nome del sito). È opportuno considerare la proporzione come percentuale; la somma delle proporzioni deve essere uguale al 100%. Il rapporto predefinito è 50/50/0/0, che ignora le informazioni dell'advisor e del sistema. Nell'ambiente in uso, può essere necessario tentare combinazioni diverse delle proporzioni per individuare la combinazione che offra le prestazioni migliori.
Quando si aggiunge un advisor WLM, se la proporzione delle metriche del sistema è uguale a zero, il gestore aumenta questo valore a 1. Poiché la somma delle proporzioni deve essere uguale a 100, il valore più alto viene ridotto di 1.
Il numero delle connessioni attive dipende dal numero di client e dal tempo necessario per l'utilizzo dei servizi forniti dalle macchine server con bilanciamento del carico. Se le connessioni client sono rapide (ad esempio, piccole pagine Web richiamate tramite HTTP GET), il numero delle connessioni attive sarà abbastanza basso. Se le connessioni client sono più lente (ad esempio, query del database), il numero delle connessioni attive sarà più alto.
È necessario evitare di impostare valori di proporzioni delle connessioni attive e nuove troppo bassi. Il bilanciamento del carico e l'arrotondamento verranno disabilitati a meno che ciascuno dei primi due valori non sia impostato almeno su 20.
Per impostare la proporzione dei valori di importanza, utilizzare il comando dscontrol cluster set cluster proporzioni. Per ulteriori informazioni, vedere dscontrol cluster -- configura i cluster.
I pesi vengono impostati dalla funzione gestore in base ai contatori interni all'executor, al feedback restituito dagli advisor e a quello restituito dal programma di monitoraggio del sistema, ad esempio Metric Server. Per impostare i pesi manualmente durante l'esecuzione del gestore, specificare l'opzione fixedweight sul comando dscontrol server. Per una descrizione dell'opzione fixedweight, vedere Pesi fissi del gestore.
I pesi vengono applicati a tutti i server su una porta. Per ogni particolare porta, le richieste vengono distribuite tra i servizi in base ai loro pesi rispettivi. Se, ad esempio, un server è impostato su un peso pari a 10 e l'altro su un peso pari a 5, il server impostato su 10 riceverà il doppio delle richieste del server impostato su 5.
Per specificare il limite massimo del peso che un server può avere, utilizzare il comando dscontrol port set porta weightbound peso. Questo comando influisce sulla differenza che può sussistere tra il numero delle richieste a ciascun server. Se il valore weightbound (limite di peso) massimo è impostato su 1, tutti i server possono avere un peso di 1, 0 se inattivo o -1 se contrassegnato come guasto. Aumentando questo numero, la differenza del calcolo dei pesi attribuibili ai server aumenta. A un valore weightbound (limite di peso) massimo di 2, un server può ricevere il doppio delle richieste di un altro server. A un valore weightbound (limite di peso) massimo di 10, un server può ricevere 10 volte le richieste di un altro server. Il valore weightbound massimo è 20.
Se un advisor rileva che un server è inattivo, notifica questa condizione al gestore che imposta il peso per tale server su zero. Di conseguenza, l'executor non invierà connessioni aggiuntive a tale server fin tanto che il valore del peso rimarrà zero. In caso di connessioni attive a quel server prima che venisse modificato il peso, queste verranno completate normalmente.
Se tutti i server sono inattivi, il gestore imposta i pesi sul metà del valore weightbound.
Senza il gestore, gli advisor non possono essere eseguiti e non possono rilevare se un server è inattivo. Se si sceglie di eseguire gli advisor, ma non si desidera che il gestore aggiorni il peso impostato per un determinato server, utilizzare l'opzione fixedweight sul comando dscontrol server. Ad esempio:
dscontrol server set cluster:port:server fixedweight yes
Dopo aver impostato fixedweight su sì (yes), utilizzare il comando dscontrol server set weight per impostare il peso sul valore desiderato. Il valore del peso del server rimane fisso mentre il gestore è in esecuzione finché non si immette un altro comando dscontrol server con fixedweight impostato su no. Per ulteriori informazioni, vedere dscontrol server -- configura i server
Se viene attivato il ripristino TCP, Dispatcher invierà un comando TCP reset al client connesso a un server con peso impostato su 0. Il peso del server può essere 0 se configurato su tale valore o se l'advisor lo contrassegna come inattivo. Un comando TCP reset chiude immediatamente la connessione. Questa opzione è utile per connessioni lunghe in cui viene accelerata la capacità del client di negoziare nuovamente una connessione non riuscita. Per attivare il ripristino TCP, utilizzare il comando dscontrol port add|set porta reset yes. Il valore predefinito per il comando reset è no.
Un'opzione utile da configurare, insieme al ripristino TCP, è nuovi tentativi degli advisor. Con questa funzione, un advisor può tentare nuovamente una connessione prima di contrassegnare come inattivo un server. In questo modo si evita che un server venga contrassegnato come inattivo prematuramente e, di conseguenza, si evitano problemi di ripristino della connessione. Ossia, solo perché il primo tentativo dell'advisor non è riuscito non significa che anche le connessioni esistenti non riescano. Per ulteriori informazioni, vedere Nuovi tentativi dell'advisor.
Per ottimizzare le prestazioni generali, il gestore viene limitato nella frequenza di interazione con l'executor. È possibile modificare questo intervallo immettendo i comandi dscontrol manager interval e dscontrol manager refresh.
L'intervallo del gestore imposta la frequenza con cui il gestore aggiornerà i pesi dei server che l'executor utilizza per instradare le connessioni. Se l'intervallo è impostato su un valore troppo basso, le prestazioni possono ridursi notevolmente come conseguenza delle continue interruzioni dell'executor da parte del gestore. Se l'intervallo del gestore è impostato su un valore troppo alto, l'instradamento delle richieste da parte dell'executor non si baserà su informazioni precise e aggiornate.
Ad esempio, per impostare l'intervallo del gestore su 1 secondo, immettere il seguente comando:
dscontrol manager interval 1
Il ciclo di aggiornamento del gestore specifica la frequenza con cui il gestore richiede all'executor le informazioni sullo stato. Il ciclo di aggiornamento si basa sul tempo dell'intervallo.
Ad esempio, per impostare il ciclo di aggiornamento del gestore su 3, immettere il seguente comando:
dscontrol manager refresh 3
In questo modo il gestore attende per 3 secondi prima di richiedere all'executor le informazioni sullo stato.
Per ottimizzare il bilanciamento del carico sui server, sono disponibili altri metodi. Per garantire la massima velocità, gli aggiornamenti dei pesi dei server vengono eseguiti solo se i pesi sono stati modificati significativamente. Un aggiornamento continuo dei pesi quando lo stato dei server non viene sottoposto a modifiche di entità considerevole creerebbe solo un sovraccarico superfluo. Quando la variazione percentuale del peso complessivo di tutti i server su una porta supera la soglia di sensibilità, i pesi utilizzati dall'executor per distribuire le connessioni vengono aggiornati dal gestore. Supporre, ad esempio, che il peso totale passi da 100 a 105. La variazione è del 5%. Se la soglia di sensibilità predefinita è 5, i pesi utilizzati dall'executor non vengono aggiornati dal gestore, in quanto la variazione in percentuale non supera la soglia. Tuttavia, se la variazione del peso totale passa da 100 a 106, il gestore aggiorna i pesi. Per impostare la soglia di sensibilità del gestore su un valore diverso da quello predefinito (ad esempio 6), immettere il seguente comando:
dscontrol manager sensitivity 6
Nella maggior parte dei casi, non è necessario modificare questo valore.
Il gestore calcola i pesi sul server in modo dinamico. Di conseguenza, un peso aggiornato può essere differente da quello precedente. Nella maggior parte dei casi, questo non rappresenta un problema. Tuttavia, in alcuni casi, potrebbe causare un'oscillazione nel modo in cui viene eseguito il bilanciamento del carico delle richieste. Ad esempio, un server può interrompere la ricezione della maggior parte delle richieste a causa di un peso elevato. Il gestore rileva che il server ha un numero di connessioni attive elevato e che risponde lentamente. Quindi, passerà il peso sui server liberi, sui quali si verificherà la stessa situazione, creando un uso inefficiente delle risorse.
Per risolvere questo problema, il gestore utilizza un indice di arrotondamento. Tale indice limita la quantità di peso che è possibile modificare su un server, arrotondando in modo effettivo la variazione nella distribuzione delle richieste. Un indice di arrotondamento più alto fa in modo che i pesi del server subiscano delle variazioni meno drastiche. Con un indice più basso, i pesi del server subiranno delle variazioni più drastiche. Il valore predefinito per l'indice di arrotondamento è 1.5. Con tale impostazione, i pesi del server possono essere piuttosto dinamici, mentre un indice di 4 o 5 renderà i pesi più stabili. Ad esempio, per impostare l'indice di arrotondamento su 4, immettere il seguente comando:
dscontrol manager smoothing 4
Nella maggior parte dei casi, non è necessario modificare questo valore.
Load Balancer fornisce uscite utente che attivano script personalizzabili. È possibile creare gli script per eseguire azioni automatizzate, quali avvisare un amministratore quando i server sono contrassegnati come inattivi dal gestore o semplicemente registrare l'evento del malfunzionamento. Gli script di esempio, personalizzabili, si trovano nella directory di installazione ...ibm/edge/lb/servers/samples. Per eseguire questi file, spostarli nella directory ...ibm/edge/lb/servers/bin ed eliminare l'estensione file "sample". Vengono forniti i seguenti script di esempio:
Se tutti i server in un cluster sono contrassegnati come inattivi (dall'utente o dagli advisor), viene eseguito managerAlert (se configurato) e Load Balancer tenta di instradare il traffico ai server con una tecnica round-robin. Lo script serverDown non viene eseguito quando l'ultimo server del cluster viene rilevato come non in linea.
Da schema, Load Balancer tenta di continuare a instradare il traffico nel caso in cui un server ritorni in linea e risponda alla richiesta. Se, al contrario, Load Balancer, elimina il traffico, il client non riceverebbe alcuna risposta.
Quando Load Balancer rileva che il primo server di un client è nuovamente in linea, viene eseguito lo script managerClear (se configurato) ma lo script serverUp (se configurato) non viene eseguito fino a quando un altro server non viene riportato in linea.
Considerazioni sull'uso degli script serverUp e serverDown:
Gli advisor sono agenti di Load Balancer il cui scopo è quello di valutare lo stato e il carico delle macchine server. Questa operazione viene eseguita con uno scambio proattivo del tipo client con i server. Gli advisor possono essere considerati come client leggeri dei server delle applicazioni.
Il prodotto fornisce alcuni advisor specifici per i protocolli più diffusi. Tuttavia, è inutile utilizzare tutti gli advisor forniti con ciascun componente di Load Balancer. (Ad esempio, con il componente CBR non si utilizzerebbe l'advisor Telnet). Load Balancer supporta, inoltre, il concetto di advisor personalizzato che consente agli utenti di scrivere i propri advisor.
Limitazione sull'utilizzo di applicazioni del server specifico del collegamento: Per poter utilizzare gli advisor sui server specifici di collegamento, avviare due istanze del server: una da collegare su cluster:port e l'altra da collegare su server:port. Per determinare se il server è bind specifico, emettere il comando netstat -an e ricercare server:port. Se il server non è bind specifico, il risultato di questo comando sarà 0.0.0.0:80. Se invece il server è bind specifico, verrà visualizzato un indirizzo del tipo 192.168.15.103:80.
Per i sistemi HP-UX e Solaris, limitazione sull'utilizzo di applicazioni del server specifico del collegamento: Se si utilizza il comando arp publish invece di ifconfig alias, Load Balancer supporterà l'uso degli advisor durante il bilanciamento del carico dei server con applicazioni server specifici del collegamento (inclusi altri componenti quali CBR o Site Selector), quando si collegano all'indirizzo IP cluster. Tuttavia, l'uso degli advisor sull'applicazione server specifico del collegamento non consente di posizionare Load Balancer sulla stessa macchina con l'applicazione server.
-DLB_ADV_SRC_ADDR=indirizzo_IP
Gli advisor aprono periodicamente una connessione TCP con ciascun server e inviano un messaggio di richiesta al server. Il contenuto del messaggio è specifico del protocollo in esecuzione sul server. Ad esempio, l'advisor HTTP invia una richiesta HTTP "HEAD" al server.
Quindi, gli advisor restano in ascolto di una risposta dal server. Dopo aver ricevuto la risposta, l'advisor esegue una valutazione del server. Per calcolare questo valore di carico, la maggior parte degli advisor misura il tempo impiegato dal server per rispondere, quindi utilizza questo valore, espresso in millisecondi, come valore del carico.
Gli advisor notificano il valore del carico alla funzione gestore, dove viene visualizzato nella colonna Porta del report del gestore. Il gestore calcola i valori dei pesi aggregati provenienti da tutte le fonti, in base alle relative proporzioni, e invia tali valori dei pesi alla funzione executor. L'Executor utilizza questi pesi per bilanciare il carico delle nuove connessioni client in entrata.
Se l'advisor stabilisce che un server è attivo e funzionante, notifica al gestore un numero di carico positivo, diverso da zero. Se l'advisor stabilisce che un server non è attivo, restituisce un valore di carico particolare pari a meno uno (-1). Il gestore e l'executor non inoltrano ulteriori connessioni a quel server finché il server non è di nuovo attivo.
È possibile avviare un advisor per una porta particolare attraverso tutti i cluster (advisor di gruppo). Oppure, scegliere di eseguire diversi advisor sulla stessa porta ma su cluster differenti (advisor specifici per cluster/sito). Se, ad esempio, Load Balancer è definito con tre cluster (clusterA, clusterB, clusterC), ciascuno con la porta 80, è possibile effettuare quanto segue:
dscontrol advisor start http clusterA:80Questo comando consente di avviare l'advisor HTTP sulla porta 80 per clusterA. L'advisor HTTP esaminerà tutti i server collegati alla porta 80 per il clusterA.
dscontrol advisor start ADV_custom 80Questo comando consente di avviare l'advisor ADV_custom sulla porta 80 per clusterB e clusterC. L'advisor personalizzato esaminerà tutti i server collegati alla porta 80 per clusterB e clusterC. (Per ulteriori informazioni sugli advisor personalizzati, vedere Creazione di advisor personalizzati (personalizzabili)).
Utilizzando l'esempio di configurazione per l'advisor del gruppo riportato sopra, è possibile scegliere di arrestare l'advisor personalizzato ADV_custom per la porta 80 su un solo cluster o su entrambi i cluster (clusterB e clusterC).
dscontrol advisor stop ADV_custom clusterB:80
dscontrol advisor stop ADV_custom 80
L'intervallo dell'advisor consente di impostare la frequenza con cui un advisor chiede lo stato dei server sulla porta su cui esegue il monitoraggio e notifica i risultati al gestore. Se l'intervallo dell'advisor è impostato su un valore troppo basso, le prestazioni possono ridursi notevolmente come conseguenza delle continue interruzioni dei server da parte dell'advisor. Se l'intervallo dell'advisor è impostato su un valore troppo alto, le decisioni del gestore sul calcolo dei pesi non si baseranno su informazioni precise e aggiornate.
Ad esempio, per impostare l'intervallo dell'advisor HTTP per la porta 80 su 3 secondi, immettere il seguente comando:
dscontrol advisor interval http 80 3
Non specificare un intervallo dell'advisor inferiore a quello del gestore. L'intervallo predefinito dell'advisor è di sette secondi.
Per garantire che il gestore non utilizzi informazioni non aggiornate nelle decisioni per il bilanciamento del carico, il gestore non utilizzerà le informazioni provenienti dall'advisor la cui data/ora è precedente all'ora impostata nel timeout report dell'advisor. Il timeout report dell'advisor deve essere essere maggiore dell'intervallo di polling dell'advisor. Se minore, il gestore ignora i report che dovrebbero essere utilizzati localmente. Per impostazione predefinita, i report dell'advisor non sono sottoposti a timeout - il valore predefinito è unlimited.
Ad esempio, per impostare il timeout report dell'advisor HTTP per la porta 80 su 3 secondi, immettere il seguente comando:
dscontrol advisor timeout http 80 30
Per ulteriori informazioni sull'impostazione del timeout report advisor, vedere dscontrol advisor -- controlla l'advisor.
In Load Balancer, è possibile impostare i valori di timeout dell'advisor ai quali rileva che una porta particolare sul server (un servizio) non funziona. I valori di timeout per i server che non hanno funzionato correttamente (connecttimeout e receivetimeout) stabiliscono per quanto tempo l'advisor deve rimanere in attesa prima di notificare che l'operazione di connessione o l'operazione di ricezione non ha avuto esito positivo.
Per rilevare rapidamente i server che non funzionano, impostare i timeout di connessione e di ricezione dell'advisor sul valore più piccolo (un secondo) e impostare l'intervallo del gestore e dell'advisor sul valore più piccolo (un secondo).
Ad esempio, per impostare connecttimeout e receivetimeout su 9 secondi per l'advisor HTTP sulla porta 80, immettere il seguente comando:
dscontrol advisor connecttimeout http 80 9 dscontrol advisor receivetimeout http 80 9
Il valore predefinito del timeout di connessione e di ricezione è 3 volte il valore specificato per l'intervallo dell'advisor.
Gli advisor possono tentare nuovamente una connessione prima di contrassegnare come inattivo un server. L'advisor non contrassegna un server come inattivo finché la query eseguita sul server non ha avuto esito negativo per il numero di tentativi più 1. Si consiglia di non impostare un valore di tentativi superiore a 3. Il seguente comando imposta un valore dei tentativi di 2 per l'advisor LDAP sulla porta 389:
dscontrol advisor retry ldap 389 2
L'opzione URL per l'advisor HTTP o HTTPS è disponibile per i componenti Dispatcher e CBR.
Dopo aver avviato un advisor HTTP o HTTPS, è possibile definire una stringa URL HTTP client univoca, specifica del servizio che si desidera interrogare sul server. In questo modo si consente all'advisor di valutare lo stato dei singoli servizi all'interno di un server. Ciò è possibile definendo i server logici con nomi server univoci con lo stesso indirizzo IP fisico. Per ulteriori informazioni, vedere Suddivisione in partizioni dei server: server logici configurati su un server fisico (indirizzo IP).
Per ciascun server logico definito nella porta HTTP, è possibile specificare una stringa URL HTTP client univoca, specifica per il servizio che si desidera interrogare sul server. L'advisor HTTP o HTTPS utilizza la stringa advisorrequest per verificare lo stato dei server. Il valore predefinito è HEAD / HTTP/1.0. La stringa advisorresponse è la risposta alla scansione da parte dell'advisor della risposta HTTP. L'advisor utilizza la stringa advisorresponse per confrontare la risposta effettiva ricevuta dal server. Il valore predefinito è null.
Importante: se la stringa URL HTTP contiene uno spazio:
server set cluster:port:server advisorrequest "head / http/1.0" server set cluster:port:server advisorresponse "HTTP 200 OK"
dscontrol server set cluster:port:server advisorrequest "\"head / http/1.0\"" dscontrol server set cluster:port:server advisorresponse "\"HTTP 200 OK\""
Durante la creazione della richiesta HTTP o HTTPS che l'advisor invia ai server di backend per vedere se funzionano, viene digitato l'inizio della richiesta HTTP e completa la fine della richiesta come segue:
\r\nAccept: */*\r\nUser-Agent:IBM_Network_Dispatcher_HTTP_Advisor\r\n\r\n
Per aggiungere un altro campo di intestazione HTTP prima che Load Balancer aggiunga questa stringa alla fine della richiesta, includere la propria stringa \r\n nella richiesta. Di seguito è riportato un esempio di cosa è possibile digitare per aggiungere un campo di intestazione host HTTP alla richiesta:
GET /pub/WWW/TheProject.html HTTP/1.0 \r\nHost: www.w3.org
Per ulteriori informazioni, vedere dscontrol server -- configura i server.
L'advisor autonomo è disponibile sul componente Dispatcher.
Per Load Balancer in una configurazione WAN (wide area network) a due livelli, Dispatcher fornisce un advisor autonomo che collega le informazioni sullo stato del carico sui server di backend.
Figura 34. Esempio di una configurazione WAN a due livelli
mediante l'advisor autonomo
In questo esempio, l'advisor autonomo risiede, insieme a Metric Server, sulle due macchine Dispatcher sottoposte a bilanciamento del carico da Load Balancer di livello superiore. L'advisor autonomo calcola specificatamente le connessioni al secondo sui server di backend del Dispatcher a livello dell'executor.
L'advisor autonomo scrive i risultati sul file dsloadstat. Load Balancer, inoltre, fornisce la metrica esterna denominata dsload. L'agente Metric Server su ciascuna macchina Dispatcher esegue la relativa configurazione che richiama la metrica esterna dsload. Lo script dsload consente l'estrazione di una stringa dal file dsloadstat e la restituisce all'agente Metric Server. Di conseguenza, ciascun agente Metric Server (da ciascun Dispatcher) restituisce il valore sullo stato del carico di Load Balancer di livello superiore per determinare il Dispatcher da utilizzare per inoltrare le richieste client.
L'eseguibile dsload risiede nella directory ...ibm/edge/lb/ms/script per Load Balancer.
Per ulteriori informazioni sull'uso di Dispatcher nelle configurazioni WAN, vedere Configurazione del supporto di Dispatcher per una rete geografica. Per ulteriori informazioni, vedere Metric Server.
L'advisor personalizzato (personalizzabile) è una piccola parte di codice Java che l'utente deve fornire come file di classe, richiamato dal codice di base. Il codice di base fornisce tutti i servizi amministrativi, come l'avvio e l'arresto di un'istanza dell'advisor personalizzato, l'indicazione di stato e report e la registrazione di informazioni cronologiche in un file di log. Inoltre, notifica i risultati al componente gestore. Periodicamente, il codice di base esegue un ciclo di advisor, durante il quale valuta singolarmente lo stato di tutti i server della configurazione. Per prima cosa, apre una connessione a una macchina server. Se il socket viene aperto, il codice di base richiama il metodo (funzione) getLoad nell'advisor personalizzato. L'advisor personalizzato quindi esegue le operazioni necessarie per valutare lo stato del server. In genere, invia al server un messaggio definito dall'utente e attende quindi una risposta. (L'accesso al socket aperto viene fornito all'advisor personalizzato.) Il codice di base, quindi, chiude il socket con il server e invia le informazioni sul carico al gestore.
Il codice di base e l'advisor personalizzato possono funzionare in modalità normale o in modalità di sostituzione. La scelta della modalità di funzionamento viene specificata nel file dell'advisor personalizzato come un parametro nel metodo del costruttore.
In modalità normale, l'advisor personalizzato scambia i dati con il server, il codice dell'advisor di base programma lo scambio e calcola il valore del carico. Il codice di base invia questo valore del carico al gestore. L'advisor personalizzato deve solo restituire uno zero (esito positivo) o meno uno (-1) (errore). Per specificare la modalità normale, l'indicatore di sostituzione nel costruttore è impostato su false.
In modalità di sostituzione, il codice di base non esegue nessuna misurazione temporizzata. Il codice dell'advisor personalizzato esegue qualsiasi operazione desiderata per i relativi requisiti univoci e restituisce un numero di carico effettivo. Il codice di base accetta il numero e lo notifica al gestore. Per ottenere risultati migliori, normalizzare i numeri del carico tra 10 e 1000; 10 indica un server veloce e 1000 indica un server lento. Per specificare la modalità di sostituzione, l'indicatore di sostituzione nel costruttore è impostato su true.
Questa funzione consente di scrivere i propri advisor in
modo da fornire le informazioni precise sui server che sono
necessarie. Un advisor personalizzato di esempio, ADV_sample.java, viene fornito con il prodotto Load Balancer.
Dopo aver installato Load Balancer, è possibile trovare il codice di
in
...<install
directory>/servers/samples/CustomAdvisors.
La directory install predefinita è:
Se l'advisor personalizzato fa riferimento a ulteriori classi Java, il percorso di classe nel file di script di avvio di Load Balancer (dsserver, cbrserver, ssserver) deve essere aggiornato per includere la posizione.
I file advisor personalizzati di esempio specifici per l'advisor WAS (WebSphere Application Server) sono forniti nella directory di installazione di Load Balancer.
I file di esempio dell'advisor WebSphere Application Server risiedono nella stessa directory degli esempi del file ADV_sample.java.
Il nome file dell'advisor personalizzato deve essere scritto nel formato "ADV_myadvisor.java." Il prefisso ADV_ all'inizio deve essere scritto in maiuscolo. I restanti caratteri devono essere tutti in minuscolo.
In base alle convenzioni Java, il nome della classe definita nel file deve corrispondere al nome del file. Se si copia il codice di esempio, accertarsi di modificare tutte le istanze di ADV_sample all'interno del file in base al nuovo nome di classe.
Gli advisor personalizzati vengono scritti in linguaggio Java. Utilizzare il compilatore Java installato con Load Balancer. Durante la compilazione si fa riferimento a questi file:
Durante la compilazione, il percorso classe deve indicare il file dell'advisor personalizzato e il file delle classi di base.
Per i sistemi Windows, un semplice comando di compilazione:
install_dir/java/bin/javac -classpath dir_install\lb\servers\lib\ibmlb.jar ADV_fred.java
dove:
L'output della compilazione è un file di classe, ad esempio
ADV_fred.class
Prima di avviare l'advisor, copiare il file di classe sulla directory di installazione ...ibm/edge/lb/servers/lib/CustomAdvisors.
Per i sistemi AIX, HP-UX, Linux e Solaris, la sintassi è simile.
Per eseguire l'advisor personalizzato, è necessario anzitutto copiare il file di classe sulla directory di installazione appropriata:
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_fred.class
Configurare il componente, avviare la funzione gestore ed immettere il comando per avviare l'advisor personalizzato:
dscontrol advisor start fred 123
dove:
Se l'advisor personalizzato fa riferimento a ulteriori classi Java, il percorso di classe nel file di script di avvio di Load Balancer (dsserver, cbrserver, ssserver) deve essere aggiornato per includere la posizione.
Come tutti gli advisor, un advisor personalizzato estende la funzione dell'advisor di base, definito ADV_Base. L'advisor di base esegue effettivamente la maggior parte delle funzioni dell'advisor, come ad esempio la notifica dei carichi al gestore affinché li utilizzi nell'algoritmo di valutazione. Inoltre, tale advisor effettua le operazioni di connessione e chiusura del socket e fornisce i metodi di invio e di ricezione per l'uso da parte dell'advisor. L'advisor in sé viene utilizzato unicamente per l'invio e la ricezione dei dati sulla porta specifica del server esaminato. I metodi TCP interni all'advisor di base sono programmati per calcolare il carico. Se desiderato, un'indicatore all'interno del costruttore dell'advisor di base sostituisce il carico esistente con il nuovo carico restituito dall'advisor.
I metodi di classe di base sono:
Load Balancer esamina innanzitutto l'elenco degli advisor nativi forniti, quindi nel caso in cui non trovi un determinato advisor, esamina l'elenco degli advisor personalizzati del cliente.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Program Files\IBM\edge\lb\servers\lib\CustomAdvisors
L'elenco del programma di un advisor di esempio di un controller è riportato in Advisor di esempio. Dopo l'installazione, è possibile trovare questo advisor di esempio nella directory ...ibm/edge/lb/servers/samples/CustomAdvisors .
Questa funzione è disponibile per tutti i componenti di Load Balancer.
Metric Server fornisce informazioni sul carico dei server a Load Balancer sotto forma di metriche specifiche del sistema notificando lo stato dei server. Il gestore di Load Balancer interroga l'agente che risiede su ciascun server, assegnando pesi al processo di bilanciamento del carico utilizzando le metriche raccolte dagli agenti. I risultati vengono inseriti nel report del gestore.
Per informazioni sul Metric Server operativo (avvio e arresto) e sull'utilizzo dei log di Metric Server, fare riferimento a Utilizzo del componente Metric Server.
Per un esempio di configurazione, vedere Figura 5.
Analogamente all'advisor WLM, Metric Server effettua la notifica ai sistemi server come insieme piuttosto che ai singoli daemon server specifici dei protocolli. Sia WLM che Metric Server inseriscono i relativi risultati nella colonna del sistema del report del gestore. Di conseguenza, l'esecuzione contemporanea dell'advisor WLM e di Metric Server non è supportata.
L'agente Metric Server deve essere installato e in esecuzione su tutti i server che sono sottoposti al bilanciamento del carico.
Di seguito vengono riportate le operazioni necessarie per configurare Metric Server per Dispatcher. Operazioni simili possono essere utilizzate per configurare Metric Server per altri componenti di Load Balancer.
porta è la porta RMI scelta per eseguire tutti gli agenti Metric Server. La porta RMI predefinita impostata nel file metricserver.cmd è 10004.
systemMetric è il nome dello script (che risiede sul server di backend) che deve essere eseguito su ciascun server nella configurazione del cluster specificato (o nome sito). Vengono forniti due script per il cliente - cpuload e memload. Altrimenti, è possibile creare script delle metriche del sistema personalizzati. Lo script contiene un comando che deve restituire un valore numerico compreso tra 0 e 100 oppure un valore di -1 se il server non è attivo. Questo valore numerico rappresenta una misura del carico e non un valore di disponibilità.
Limitazione: sulle piattaforme Windows, se il nome dello script System Metric ha un'estensione diversa da ".exe", è necessario specificare il nome completo del file (ad esempio, "mysystemscript.bat"). Questo è dovuto a una limitazione Java.
Facoltativamente, i clienti possono scrivere i file script delle metriche personalizzati che definiscono il comando che invierà alle macchine server. Accertarsi che gli script personalizzati siano eseguibili e posizionati nella directory ...ibm/edge/lb/ms/script. Gli script personalizzati devono restituire un valore di carico numerico compreso tra 0 e 100.
Per eseguire Metric Server su un indirizzo diverso dall'host locale, modificare il file metricserver sulla macchina server con bilanciamento del carico. Nel file metricserver, dopo "java", inserire quanto segue:
-Djava.rmi.server.hostname=OTHER_ADDRESS
Inoltre, prima delle istruzioni "if" nel file metricserver, aggiungere la seguente riga: hostname OTHER_ADDRESS .
Per la piattaforma Windows: è necessario creare l'alias di OTHER_ADDRESS sullo stack Microsoft della macchina Metric Server. Ad esempio:
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
Quando si raccolgono le metriche tra i diversi domini, è necessario impostare esplicitamente java.rmi.server.hostname nello script server (dsserver, cbrserver e così via) sul nome dominio completo FQDN (fully domain name) della macchina che sta richiedendo le metriche. Questa operazione è necessaria poiché, a seconda della configurazione e del sistema operativo, InetAddress.getLocalHost.getHostName() potrebbe non restituire l'FQDN.
WLM è il codice che viene eseguito sui mainframe MVS. È possibile eseguire delle query sul carico sulla macchina MVS.
Quando Workload Management MVS è stato configurato sul sistema OS/390, Dispatcher può accettare le informazioni sulla capacità provenienti da WLM e utilizzarle nel processo di bilanciamento del carico. Utilizzando l'advisor WLM, Dispatcher apre periodicamente le connessioni tramite la porta WLM su ciascun server nella tabella host del Dispatcher e accetta i numeri interi sulla capacità che vengono restituiti. Poiché tali numeri interi rappresentano la capacità ancora disponibile e i consultant si aspettano al contrario i valori dei carichi di ciascuna macchina, i numeri interi della capacità vengono invertiti dall'advisor e normalizzati in valori del carico (ad esempio, un numero intero grande che rappresenta la capacità e un numero piccolo che rappresenta il carico indicano entrambi un server in buono stato di funzionamento). I carichi risultanti vengono inseriti nella colonna del sistema del report del gestore.
Numerose importanti differenze distinguono l'advisor WLM dagli altri advisor del Dispatcher:
Analogamente all'agente Metric Server, l'agente WLM effettua la notifica ai sistemi server come insieme piuttosto che ai singoli daemon server specifici dei protocolli. Metric Server e WLM inseriscono i relativi risultati nella colonna del sistema del report del gestore. Di conseguenza, l'esecuzione contemporanea dell'advisor WLM e di Metric Server non è supportata.
Questo capitolo descrive come configurare i parametri per il bilanciamento del carico e come impostare le funzioni avanzate di Load Balancer.
Tabella 16. Attività di configurazione configurate per Load Balancer
Attività | Descrizione | Informazioni correlate |
---|---|---|
Posizionamento di Load Balancer su una macchina che esegue il bilanciamento del carico | Configurare una macchina Load Balancer posizionata. | Utilizzo dei server posizionati |
Configurazione della disponibilità elevata o 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. | Configurare il 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. | Configurare il 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. | Utilizzare il cluster jolly per bilanciare il carico dei firewall |
Utilizzare il cluster jolly con Caching Proxy per il proxy trasparente | Consente di utilizzare Dispatcher per attivare un proxy trasparente. | Utilizzare il cluster jolly con Caching Proxy per il 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. | Utilizzare la porta jolly per indirizzare il traffico non configurato sulle porte |
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. | Utilizzo 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 |
Load Balancer può risiedere sulla stessa macchina di un server per il quale sta bilanciando il carico delle richieste. Questa condizione viene definita posizionamento di un server. Il posizionamento si applica a Dispatcher e Site Selector. Il posizionamento è supportato anche per CBR, ma solo se si utilizzano dei server web Caching Proxy specifici del collegamento.
Sistemi 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, vedere Alternative di creazione alias Linux quando si utilizza l'inoltro mac di Load Balancer.
Sistemi Windows: 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 Configurazione di posizionamento ed elevata disponibilità (sistemi Windows).
Sistemi Solaris: esiste un limite secondo il quale non è possibile configurare gli advisor WAN se Dispatcher entry-point è posizionato. Vedere Utilizzo di advisor remoti con il supporto per rete geografica di 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 sì o su no. Il valore predefinito è no. L'indirizzo del server deve essere un indirizzo IP di una scheda di interfaccia di rete sulla macchina. Il parametro posizionato non deve essere impostato per i server che sono posizionati mediante i metodi 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 nuovo_alias router ip_router returnaddress indirizzo_ritorno
Una configurazione errata può causare errori di sistema, una mancata risposta del server, o entrambe le condizioni.
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 su tutti i sistemi operativi nel caso in cui le seguenti operazioni siano eseguite sulla macchina di Dispatcher:
arp -s hostname ether_addr pub
usando l'indirizzo MAC locale per ether_addr. In questo modo, l'applicazione locale è in grado di inviare il traffico all'indirizzo mittente nel kernel.
CBR supporta il posizionamento su tutte le piattaforme senza ulteriori configurazioni. Tuttavia, i server Web e il Caching Proxy utilizzati devono essere specifici del collegamento.
Site Selector supporta il posizionamento su tutte le piattaforme senza ulteriori configurazioni.
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:
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.
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.
dscontrol highavailability heartbeat add sourceaddress destinationaddress
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3Almeno 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.
dscontrol highavailability reach add 9.67.125.18Le destinazioni accessibili sono consigliate ma non obbligatorie. Per ulteriori informazioni, vedere Capacità di rilevamento di errori mediante heartbeat e la destinazione accessibile.
dscontrol highavailability backup add primary [auto | manual] porta
dscontrol highavailability backup add backup [auto | manual] porta
dscontrol highavailability backup add both [auto | manual] porta
dscontrol highavailability statusCiascuna 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.
dscontrol cluster set clusterA primaryhost NFAdispatcher1 dscontrol cluster set clusterB primaryhost NFAdispatcher2
dscontrol cluster set clusterB primaryhost NFAdispatcher2 dscontrol cluster set clusterA primaryhost NFAdispatcher1
Note:
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 accessibili che sono in grado di sottoporre a ping. Se la macchina in standby sottopone a ping un numero di destinazioni accessibili 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 a disponibilità elevata 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 è ottenuta grazie all'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.
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:
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 pacchetti 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 del 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.
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, vedere 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 directory ...ibm/edge/lb/servers/samples e devono essere spostati nella directory ...ibm/edge/lb/servers/bin per essere eseguiti. Gli script vengono eseguiti automaticamente solo se dsserver è in esecuzione.
Note:
È possibile utilizzare i seguenti script di esempio:
Sui sistemi Windows: in una 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 Linux per S/390(R): 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.
Sui server Windows, è possibile configurare sia l'elevata disponibilità che il posizionamento. Tuttavia, sono richieste delle operazioni aggiuntive per configurare queste funzioni di Load Balancer insieme sui sistemi Windows.
Su sistemi Windows, quando si utilizza il posizionamento con l'elevata disponibilità, sarà necessario un ulteriore indirizzo IP, una specie di indirizzo IP fittizio, che possa essere aggiunto all'adattatore loopback sul sistema Windows. L'adattatore loopback deve essere installato sia sulla macchina principale che su quella di backup. Per l'installazione del dispositivo loopback su sistemi Windows, effettuare le operazioni riportate in Configurazione della macchine server per il bilanciamento del carico.
Quando le operazioni indicano di aggiungere l'indirizzo IP del cluster al loopback, è necessario aggiungere un indirizzo IP fittizio e non l'indirizzo del cluster. Il motivo è che gli script go* di elevata disponibilità per i sistemi Windows devono eliminare e aggiungere l'indirizzo del cluster al dispositivo loopback, a seconda se la macchina di Load Balancer è attiva o in standby.
I sistemi Windows non consentono la rimozione dell'ultimo indirizzo IP configurato dal dispositivo loopback in quanto questo dispositivo non funziona in modalità DHCP. L'indirizzo fittizio consente a Load Balancer di rimuovere l'indirizzo del cluster in qualsiasi momento. L'indirizzo IP fittizio non verrà utilizzato per alcun tipo di traffico e potrà essere utilizzato sia sulla macchina attiva che sulla macchina standby.
Aggiornare e spostare gli script go* di Load Balancer sia sulla macchina attiva che su quella standby, quindi avviare il Dispatcher. L'indirizzo del cluster verrà aggiunto e rimosso dall'interfaccia di rete e dal dispositivo loopback tutte le volte necessarie.
È 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. Se tutti gli altri server non soddisfano la richiesta del client, la risposta potrebbe essere "Il sito non è attivo, riprovare in seguito".
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.
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, vedere 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). Verrà utilizzata la prima regola soddisfatta. Una volta soddisfatta una regola, non verranno valutate altre regole.
Per soddisfare una regola, sono necessarie due condizioni:
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.
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.
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.
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.
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
Questo tipo di regola è disponibile nei componenti Dispatcher e CBR.
È possibile utilizzare regole basate sulle connessioni al secondo per poter condividere i server con altre applicazioni. Ad esempio, si possono impostare due regole:
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. Per ulteriori informazioni, vedere Opzione di valutazione dei server per le regole.
Questo tipo di regola è disponibile nei componenti Dispatcher o CBR.
È possibile utilizzare le regole basate sul numero totale di connessioni attive su una porta se i server sono sovraccarichi e cominciano, quindi, ad eliminare i pacchetti. Alcuni server Web continuano ad accettare le connessioni anche se non dispongono di thread sufficienti per rispondere alle richieste. Ne consegue che le richieste dei client scadono e il cliente che visita il sito Web non viene assistito. Le regole basate sulle connessioni attive servono a bilanciare la capacità all'interno di un lotto di server.
Ad esempio, si sa, per esperienza, che i server smetteranno di soddisfare le richieste 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.
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.
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.
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 dimensioni dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth dimensioni
Il valore dimensioni 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 valore dscontrol rule set 9.20.34.11:80:shrule sharelevel valore
Il valore valore di sharelevel è executor o cluster. Sharelevel è un parametro obbligatorio sulla regola sharebandwidth.
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 una 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.
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.
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
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.
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
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 supponga di avere sei server. Due di loro devono gestire il traffico in ogni circostanza, a meno che non siano disattivati. Se i primi due server sono disattivati, si sceglie un secondo gruppo di server per gestire il traffico. Se tutti e quattro i server scelti sono disattivati, si utilizzano gli ultimi due disponibili. 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.
Si possono definire più regole "sempre true" e, quindi, impostare la regola da eseguire modificandone i livelli di priorità.
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, vedere Appendice B, Sintassi della regola di contenuto (modello).
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.
Per informazioni dettagliate sulla sintassi di comando relativa alla funzione ignora affinità di porta mediante il server aderente, vedere l'opzione dscontrol server -- configura i server .
È 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
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:
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 livello dscontrol rule set 9.22.21.3:80:rbweval evaluate livello
Il valore evaluate livello può essere impostato su porta, regola o upserversonrule. Il valore predefinito è port.
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 sotto la soglia dei server della prima regola, il nuovo traffico continua ad affluire su tali server.
Utilizzando le due regole descritte nell'esempio precedente, se si imposta l'opzione di valutazione su porta 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.
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). Per ulteriori informazioni, vedere Affinità multiporta .
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.
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.
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.
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. Per informazioni dettagliate sulla sintassi di comando sull'opzione crossport, vedere dscontrol port -- configura le porte.
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.
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 di stickytime delle porte condivise devono essere uguali (numero diverso da zero). Per ulteriori informazioni, vedere Affinità multiporta .
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.
Per informazioni dettagliate sulla sintassi di comando di stickymask (funzione maschera indirizzo affinità), vedere dscontrol port -- configura le porte.
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.
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:
Questo è il modo meno brusco di disattivare i server. Ad esempio, si può disattivare un server con molta delicatezza e aspettare il momento in cui il traffico è minore (probabilmente la mattina molto presto) per rimuoverlo del tutto dalla configurazione.
È possibile specificare i seguenti tipi di affinità sul comando dscontrol rule:
L'affinità cookie attivo si applica solamente al componente CBR.
Il cookie passivo si applica al componente CBR e al metodo di inoltro cbr del componente Dispatcher.
L'affinità URI si applica al componente CBR e al metodo di inoltro cbr del componente Dispatcher.
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.
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. Per informazioni dettagliate sulla sintassi del comando, vedere dscontrol rule -- configura le regole.
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:porta:regola+server-time! Le informazioni cluster:port:rule e server sono codificate, per impedire che la configurazione CBR venga rivelata.
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.
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.
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
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.
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.
Sui sistemi AIX, Solaris e Linux, il file cbrserver si trova nella directory /usr/bin.
Sui sistemi Windows, il file cbrserver si trova nella directory \winnt\system32.
L'affinità cookie passivo si applica al metodo di inoltro cbr (content-based routing) del componente Dispatcher e al componente CBR. Per ulteriori informazioni su come configurare il metodo di inoltro cbr di Dispatcher, vedere Instradamento a livello di contenuto di Dispatcher (metodo di inoltro cbr).
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.
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.
L'affinità URI si applica al metodo di inoltro cbr del Dispatcher e al componente CBR. Per ulteriori informazioni su come configurare il metodo di inoltro cbr di Dispatcher, vedere Instradamento a livello di contenuto di Dispatcher (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 ed eliminando la memorizzazione ridondante di contenuti 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.
Se, tuttavia, 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:
L'opzione affinità URI, del comando della regola, può essere impostata su URI se il valore stickytime della porta è zero (non abilitato). Una volta abilitata l'affinità URI su una regola, non è possibile abilitare il valore stickytime sulla porta.
Questa funzione è disponibile esclusivamente per il componente Dispatcher.
Se non si sta utilizzando il supporto per 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 35). Una richiesta client arriva nella macchina Dispatcher e viene inviata al server. Dal server, la risposta viene restituita direttamente al client.
Figura 35. Esempio di una
configurazione costituita da un unico segmento LAN
La funzione di rete geografica di Dispatcher fornisce un supporto ai server esterni, noti come server remoti (vedere Figura 36). 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 da server collegati localmente (ServerG, ServerH e ServerI). Un package client andrà da Internet alla macchina Dispatcher iniziale. Dal Dispatcher iniziale, il package 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 per area geografica.
Figura 36. Esempio di configurazione che utilizza 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 package può avere dei server locali collegati e può distribuire il carico tra i server locali e quelli remoti.
Per configurare il supporto per rete geografica:
dscontrol server add cluster:port:server router indirizzo
Per ulteriori informazioni sulla parola chiave router, vedere dscontrol server -- configura i server.
Sui Dispatcher entry-point:
I Dispatcher entry-point in esecuzione sulle piattaforme AIX, Linux (che utilizza GRE) o Solaris, visualizzeranno correttamente i carichi degli advisor. Le altre piattaforme devono basarsi sul bilanciamento del carico round-robin oppure utilizzare i metodi di inoltro nat/cbr di Dispatcher anziché la rete geografica (WAN, wide area networking).
Sistemi AIX
Sistemi HP-UX
Sistemi Linux
Sistemi Solaris
arp -s indirizzo_cluster_personale indirizzo_mac_personale pub
Sistemi Windows
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
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
Sistemi HP-UX, Linux, Solaris e Windows
Figura 37. Configurazione di esempio di rete geografica con Load Balancer remoti
Questo esempio si applica alla configurazione illustrata nella Figura 37.
Di seguito viene spiegato come configurare le macchine Dispatcher per supportare l'indirizzo cluster xebec sulla porta 80. LB1 viene definito come Load Balancer "entry-point". Viene utilizzata una connessione Ethernet. Si noti 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:
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
Sulla console del secondo Dispatcher (LB2):
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
Sulla console del terzo Dispatcher (LB3):
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
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 supportano 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 38. Configurazione di esempio di rete geografica con piattaforma server che supporta GRE
In questo esempio ((Figura 38), 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
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. Ciò consente a 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 back-end di Linux, emettere 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 indirizzo_cluster dev gre-nd
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.
È 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 i sistemi AIX, questa configurazione può trarre vantaggio dalle velocità elevate di High Performance Switch SP(TM), 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.
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 39, il comando dovrebbe essere codificato come:
dscontrol server add indirizzo_cluster:80:10.0.0.1
non
dscontrol server add indirizzo_cluster:80:9.67.131.18
Se si sta utilizzando Site Selector per fornire al Dispatcher informazioni sul carico, configurarlo per notificare i carichi sugli indirizzi privati.
Figura 39. Esempio di una rete privata
che utilizza Dispatcher
L'uso di una configurazione di rete privata si applica esclusivamente al componente Dispatcher.
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.
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.
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.
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
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ò significa 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 successive di controllo e 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.
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.
Load Balancer fornisce uscite utente che attivano script personalizzabili in grado di avvisare l'amministratore di un possibile attacco di tipo denial of service. Dispatcher fornisce i seguenti file di script di esempio nella directory ...ibm/edge/lb/servers/samples:
Per eseguire questi file, spostarli nella directory ...ibm/edge/lb/servers/bin ed eliminare 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à.
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.
La funzione di 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 sui server ogni 60 secondi consente di ottenere istantanee di informazioni relative ai 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 forniti nella directory ...ibm/edge/lb/servers/samples/BinaryLog. 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.)
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.
Questo capitolo include le seguenti sezioni:
Cisco CSS Controller o Nortel Alteon Controller possono risiedere sulla medesima macchina di un server per cui si sta effettuando il bilanciamento di carico delle richieste. Questa condizione viene definita posizionamento di un server. Non sono necessarie ulteriori procedure di configurazione.
La funzione di disponibilità elevata è ora disponibile per Cisco CSS Controller e Nortel Alteon Controller.
Per aumentare la tolleranza agli errori del controllor, la funzione di disponibilità elevata contiene le seguenti caratteristiche:
Vedere ccocontrol highavailability -- controlla la disponibilità elevata e nalcontrol highavailability -- controlla la disponibilità elevata per una sintassi completa per xxxcontrol highavailability.
Per configurare la disponibilità elevata del controller:
xxxcontrol highavailability add address 10.10.10.10 partneraddress 10.10.10.20 port 143 role primary
xxxcontrol highavailability add address 10.10.10.20 partneraddress 10.10.10.10 port 143 role secondary
I parametri address e partneraddress sono invertiti sulla macchina principale e su quella secondaria.
xxxcontrol highavailability set beatinterval 1000
xxxcontrol highavailability usereach 10.20.20.20
Configurare lo stesso numero di destinazioni finali sia sul controller locale che sul controller partner.
xxxcontrol highavailability start auto
xxxcontrol highavailability report
xxxcontrol highavailability takeover
Necessario solo a fini di gestione.
Note:
Oltre alla mancanza di connettività tra il controller attivo e il controller in standby, che viene rilevata tramite i messaggi di heartbeat, l'accessibilità è un altro meccanismo di rilevamento errori.
Quando si configura la funzione di disponibilità elevata dei controller, è possibile fornire un elenco di host a cui i controller devono accedere per poter funzionare correttamente. Occorre almeno un host per ciascuna sottorete che verrà utilizzata dalla macchina controller. Questi host possono essere router, server IP o altri tipi di host.
L'accessibilità degli host è ottenuta grazie all'advisor reach che esegue il ping sull'host. Se i messaggi heartbeat non possono essere trasmessi o se i criteri di accessibilità vengono soddisfatti in maniera ottimale dal controller in standby anziché dal controller attivo, si verifica uno scambio di ruoli. Per prendere questa decisione in base a tutte le informazioni disponibili, il controller attivo invia regolarmente informazioni sulle proprie capacità di accessibilità al controller in standby e viceversa. Quindi, i controller confrontano le proprie informazioni sull'accessibilità con le informazioni del rispettivo partner e decidono chi deve attivarsi.
I ruoli delle due macchine controller sono configurati come principale e secondaria. All'avvio i controller si scambiano informazioni fino a sincronizzare le relative macchine. A questo punto, il controller principale passa allo stato attivo e inizia a calcolare i pesi e ad aggiornare lo switch, mentre la macchina secondaria passa allo stato di standby e monitorizza la disponibilità della macchina principale.
In qualsiasi momento la macchina in standby rilevi un malfunzionamento della macchina attiva, la macchina in standby assume le funzioni di bilanciamento di carico della macchina attiva (guasta) e diventa essa stessa la macchina attiva. Quando la macchina principale diventa di nuovo operativa, le due macchine stabiliscono quale controller sarà quello attivo in base alla modalità di configurazione della strategia di ripristino.
Sono disponibili due tipi di strategia di ripristino:
Il controller principale passa allo stato attivo, calcolando e aggiornando i pesi, non appena torna ad essere nuovamente operativo. La macchina secondaria passa allo stato di standby dopo che la macchina principale è diventata quella attiva.
Il controller secondario attivo rimano nello stato attivo, anche dopo che il controller principale è diventato operativo.
Il controller principale passa allo stato di standby e richiede un intervento manuale per passare allo stato attivo.
Il parametro della strategia deve essere impostato allo stesso modo su entrambe le macchine.
Per gli esempi di configurazione della funzione di disponibilità elevata per Cisco CSS Controller, vedere Esempi.
Per gli esempi di configurazione della funzione di disponibilità elevata per Nortel Alteon Controller, vedere Esempi.
La funzione controller di Load Balancer esegue il bilanciamento del carico in base alle seguenti impostazioni:
Queste impostazioni possono essere modificate per ottimizzare il bilanciamento del carico nella rete in uso.
Nelle decisioni relative al calcolo dei pesi, il controller può utilizzare completamente o in parte gli strumenti di raccolta delle metriche elencati di seguito:
Le metriche predefinite sono activeconn e connrate.
È possibile modificare la proporzione di importanza da attribuire ai vari valori metrici. È opportuno considerare la proporzione come percentuale; la somma delle proporzioni deve essere uguale al 100%. Per impostazione predefinita, vengono utilizzate le metriche delle connessioni attive e le metriche delle nuove connessioni, in un rapporto pari a 50/50. Nell'ambiente in uso, può essere necessario tentare combinazioni diverse delle proporzioni attribuite alle varie metriche per individuare la combinazione che offra le prestazioni migliori.
Per impostare i valori delle proporzioni:
I pesi vengono impostati in base ai tempi di risposta e alla disponibilità dell'applicazione, al feedback restituito dagli advisor e a quello restituito dal programma di monitoraggio del sistema, ad esempio Metric Server. Per impostare i pesi manualmente, specificare l'opzione fixedweight per il server. Per una descrizione dell'opzione fixedweight, vedere Pesi fissi del controller.
I pesi vengono applicati a tutti i server che forniscono un servizio. Per ogni particolare porta, le richieste vengono distribuite tra i servizi in base ai loro pesi rispettivi. Ad esempio, se un server è impostato su un peso pari a 10 e l'altro su un peso pari a 5, il server impostato su 10 riceverà il doppio delle richieste del server impostato su 5.
Se un advisor rileva che un server è inattivo, il peso per tale server viene impostato a -1. Per Cisco CSS Controller e Nortel Alteon Controller lo switch viene informato che il server non è disponibile e arresta l'assegnazione di connessioni al server.
Senza il controller, gli advisor non possono essere eseguiti e non possono rilevare se un server è inattivo. Se si sceglie di eseguire gli advisor, ma non si desidera che il controller aggiorni il peso impostato per un determinato server, utilizzare l'opzione fixedweight sul comando ccocontrol service per Cisco CSS Controller o nalcontrol server per Nortel Alteon Controller.
Utilizzare il comando fixedweight per impostare il peso sul valore desiderato. Il valore del peso del server rimane fisso mentre il controller è in esecuzione finché non si immette un altro comando con fixedweight impostato su no.
Per ottimizzare le prestazioni complessive, è possibile limitare la frequenza di raccolta delle informazioni metriche.
Il tempo di inattività del consultant specifica la frequenza con cui il consultant aggiorna i pesi del server. Se il tempo di inattività del consultant è impostato su un valore troppo basso, le prestazioni possono ridursi notevolmente come conseguenza delle continue interruzioni dello switch da parte del consultant. Se il tempo di inattività del consultant è impostato su un valore troppo alto, il bilanciamento del carico dello switch non si basa su informazioni precise e aggiornate.
Ad esempio, per impostare il tempo di inattività del consultant su 1 secondo:
xxxcontrol consultant set consultantID sleeptime intervallo
Per ottimizzare il bilanciamento del carico sui server, sono disponibili altri metodi. Per garantire la massima velocità, gli aggiornamenti dei pesi dei server vengono eseguiti solo se i pesi sono stati modificati significativamente. Un aggiornamento continuo dei pesi quando lo stato dei server non viene sottoposto a modifiche di entità considerevole creerebbe solo un sovraccarico superfluo. Quando la variazione percentuale del peso complessivo di tutti i server che forniscono un servizio supera la soglia di sensibilità, i pesi utilizzati dal programma di bilanciamento del carico per distribuire le connessioni vengono aggiornati. Supporre, ad esempio, che il peso totale passi da 100 a 105. La variazione è del 5%. Se la soglia di sensibilità predefinita è 5, i pesi utilizzati dal programma di bilanciamento del carico non vengono aggiornati, in quanto la variazione in percentuale non supera la soglia. Tuttavia, se la variazione del peso totale passa da 100 a 106, i pesi vengono aggiornati. Per impostare la soglia di sensibilità del consultant su un valore diverso da quello predefinito, immettere il seguente comando:
xxxcontrol consultant set consultantID sensitivity percentageChange
Nella maggior parte dei casi, non è necessario modificare questo valore.
Gli advisor sono agenti di Load Balancer. Il loro scopo è valutare lo stato e il carico delle macchine server. Questa operazione viene eseguita con uno scambio proattivo del tipo client con i server. Considerare gli advisor come client leggeri dei server delle applicazioni.
Gli advisor aprono periodicamente una connessione TCP con ciascun server e inviano un messaggio di richiesta al server. Il contenuto del messaggio è specifico del protocollo in esecuzione sul server. Ad esempio, l'advisor HTTP invia una richiesta HTTP "HEAD" al server.
Quindi, gli advisor restano in ascolto di una risposta dal server. Dopo aver ricevuto la risposta, l'advisor esegue una valutazione del server. Per calcolare questo valore di carico, la maggior parte degli advisor misura il tempo impiegato dal server per rispondere, quindi utilizza questo valore, espresso in millisecondi, come valore del carico.
Gli advisor notificano il valore del carico alla funzione consultant, dove viene visualizzato nel report del consultant. Il consultant calcola i valori dei pesi aggregati provenienti da tutte le fonti, in base alle relative proporzioni, e invia tali valori dei pesi allo switch. Lo switch utilizza questi pesi per bilanciare il carico delle nuove connessioni client in arrivo.
Se l'advisor stabilisce che un server è attivo e funzionante, notifica al consultant un numero di carico positivo, diverso da zero. Se l'advisor stabilisce che un server non è attivo, restituisce un valore di carico particolare pari a meno uno (-1) per informare lo switch che il server è inattivo. Di conseguenza, lo switch non inoltra ulteriori connessioni a quel server finché il server non è tornato attivo.
Il tempo di inattività dell'advisor consente di impostare la frequenza con cui un advisor chiede lo stato dei server sulla porta su cui esegue il monitoraggio e notifica i risultati al consultant. Se il tempo di inattività dell'advisor è impostato su un valore troppo basso, le prestazioni possono ridursi notevolmente come conseguenza delle continue interruzioni dei server da parte dell'advisor. Se il tempo di inattività dell'advisor è impostato su un valore troppo alto, le decisioni relative ai pesi effettuate dal consultant non si basano su informazioni precise e aggiornate.
Ad esempio, per impostare l'intervallo dell'advisor HTTP a 3 secondi, immettere il seguente comando:
xxxcontrol metriccollector set consultantID:HTTP sleeptime 3
È possibile impostare il tempo a disposizione di un advisor per individuare il malfunzionamento di una porta sul server o su un servizio. I valori di timeout per i server che non hanno funzionato correttamente, connecttimeout e receivetimeout, stabiliscono per quanto tempo l'advisor deve rimanere in attesa prima di notificare che l'operazione di connessione o l'operazione di ricezione non ha avuto buon esito.
Per rilevare rapidamente i server che non funzionano, impostare i timeout di connessione e di ricezione dell'advisor sul valore più piccolo (un secondo) e impostare il tempo di inattività del consultant e dell'advisor sul valore più piccolo (un secondo).
Per impostare il valore di timeoutconnect dell'advisor HTTP a 9 secondi, immettere il seguente comando:
xxxcontrol metriccollector set consultantID:HTTP timeoutconnect 9
Il valore predefinito del timeout di connessione e di ricezione è 3 volte il valore specificato per il tempo di inattività dell'advisor.
Gli advisor possono tentare nuovamente una connessione prima di contrassegnare come inattivo un server. L'advisor non contrassegna un server come inattivo finché la query eseguita sul server non ha avuto esito negativo per il numero di tentativi più 1. Se non specificato altrimenti, il valore predefinito del numero di tentativi è 0.
Per Cisco CSS Controller, impostare il valore dei tentativi tramite il comando ccocontrol ownercontent set. Per ulteriori informazioni, vedere ccocontrol ownercontent -- controlla il nome proprietario e la regola di contenuto.
Per Nortel Alteon Controller, impostare il valore dei tentativi tramite il comando nalcontrol service set. Per ulteriori informazioni, vedere nalcontrol service -- configura un servizio
L'advisor personalizzato è una piccola parte di codice Java che l'utente deve fornire come file di classe e viene richiamato dal codice di base. Il codice di base fornisce tutti i servizi amministrativi, quali:
Inoltre, notifica i risultati al consultant. Periodicamente, il codice di base esegue un ciclo di advisor, durante il quale valuta singolarmente lo stato di tutti i server della configurazione. Per prima cosa, apre una connessione a una macchina server. Se il socket viene aperto, il codice di base richiama il metodo (funzione) getLoad nell'advisor personalizzato. L'advisor personalizzato quindi esegue i passi necessari per valutare lo stato del server. In genere, invia al server un messaggio definito dall'utente e aspetta quindi una risposta. (L'accesso al socket aperto viene fornito all'advisor personalizzato.) Il codice di base chiude il socket con il server e notifica le informazioni sul carico al consultant.
Il codice di base e l'advisor personalizzato possono funzionare in modalità normale o in modalità di sostituzione. La scelta della modalità di funzionamento viene specificata nel file dell'advisor personalizzato come un parametro nel metodo del costruttore.
In modalità normale, l'advisor personalizzato scambia i dati con il server, il codice dell'advisor di base programma lo scambio e calcola il valore del carico. Il codice di base notifica quindi questo valore del carico al consultant. L'advisor personalizzato deve solo restituire uno zero (esito positivo) o meno uno (-1) (errore). Per specificare la modalità normale, l'indicatore di sostituzione nel costruttore è impostato su false.
In modalità di sostituzione, il codice di base non esegue nessuna misurazione temporizzata. Il codice dell'advisor personalizzato esegue qualsiasi operazione desiderata per i relativi requisiti univoci e restituisce un numero di carico effettivo. Il codice di base accetta il numero e lo notifica al consultant. Per ottenere risultati migliori, normalizzare i numeri del carico tra 10 e 1000; 10 indica un server veloce e 1000 indica un server lento. Per specificare la modalità di sostituzione, l'indicatore di sostituzione nel costruttore è impostato su true.
Questa funzione consente di scrivere i propri advisor in modo da fornire le informazioni precise sui server che sono necessarie. Un advisor personalizzato di esempio, ADV_ctlrsample.java, viene fornito per i controller. Dopo aver installato Load Balancer, è possibile trovare il codice di esempio nella directory di installazione ...ibm/edge/lb/servers/samples/CustomAdvisors.
Le directory di installazione predefinite sono:
Il nome file dell'advisor personalizzato deve essere scritto nel formato ADV_ myadvisor.java. Il prefisso ADV_ posto all'inizio deve essere scritto in maiuscolo. I restanti caratteri devono essere tutti in minuscolo.
In base alle convenzioni Java, il nome della classe definita nel file deve corrispondere al nome del file. Se si copia il codice di esempio, accertarsi di modificare tutte le istanze di ADV_ctrlsample all'interno del file in base al nuovo nome di classe.
Gli advisor personalizzati vengono scritti in linguaggio Java. Utilizzare il compilatore Java installato con Load Balancer. Durante la compilazione si fa riferimento ai seguenti file:
Durante la compilazione, il percorso classe deve indicare il file dell'advisor personalizzato e il file delle classi di base.
Per la piattaforma Windows, un comando di compilazione appare come segue:
dir_install/java/bin/javac -classpath dir_install\lb\servers\lib\ibmlb.jar ADV_pam.java
dove:
L'output della compilazione è un file di classe, ad esempio:
ADV_pam.class
Prima di avviare l'advisor, copiare il file di classe sulla directory di installazione ...ibm/edge/lb/servers/lib/CustomAdvisors.
Per i sistemi AIX, HP-UX, Linux e Solaris, la sintassi è simile.
Per eseguire l'advisor personalizzato, è necessario anzitutto copiare il file di classe sulla directory di installazione appropriata:
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_pam.class
Avviare il consultant, quindi immettere questo comando per avviare l'advisor personalizzato:
dove:
Come tutti gli advisor, un advisor personalizzato estende la funzione dell'advisor di base, definito ADV_Base. L'advisor di base esegue la maggior parte delle funzioni dell'advisor, come ad esempio la notifica dei carichi al consultant affinché li utilizzi nell'algoritmo di valutazione. Inoltre, tale advisor effettua le operazioni di connessione e chiusura del socket e fornisce i metodi di invio e di ricezione per l'uso da parte dell'advisor. L'advisor in sé viene utilizzato unicamente per l'invio e la ricezione dei dati sulla porta specifica del server esaminato. I metodi TCP interni all'advisor di base sono programmati per calcolare il carico. Se desiderato, un'indicatore all'interno del costruttore dell'advisor di base sostituisce il carico esistente con il nuovo carico restituito dall'advisor.
I metodi di classe di base sono:
I controller consultano anzitutto l'elenco fornito di advisor nativi; se non vi trovano un determinato advisor, consultano l'elenco di advisor personalizzati.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Program Files\IBM\edge\lb\servers\lib\CustomAdvisors
L'elenco del programma di un advisor di esempio di un controller è riportato in Advisor di esempio. Dopo l'installazione, è possibile trovare questo advisor di esempio nella directory ...ibm/edge/lb/servers/samples/CustomAdvisors .
Metric Server fornisce informazioni sul carico dei server a Load Balancer sotto forma di metriche specifiche del sistema notificando lo stato dei server. Il consultant di Load Balancer interroga l'agente Metric Server che risiede su ciascun server, assegnando pesi al processo di bilanciamento del carico utilizzando le metriche raccolte dagli agenti. I risultati vengono quindi inseriti nel report servizio per Cisco CSS Controller o nel report server per Nortel Alteon Controller.
L'agente Metric Server deve essere installato e in esecuzione su tutti i server che sono sottoposti al bilanciamento del carico.
Di seguito vengono riportati i passi necessari per configurare Metric Server per i controller.
Per Nortel Alteon Controller, aggiungere uno switch del consultant, quindi aggiungere un servizio.
dove metricName è il nome dello script del server delle metriche.
Lo script delle metriche del sistema risiede sul server di backend e viene eseguito su ciascun server della configurazione nell'ownercontent o nel service specificati. È possibile utilizzare i due script forniti, cpuload e memload, oppure creare degli script personalizzati. Lo script contiene un comando che deve restituire un valore numerico. Questo valore numerico rappresenta una misura del carico e non un valore di disponibilità.
Limitazione: su sistemiWindows, se il nome dello script delle metriche del sistema ha un'estensione diversa da .exe, è necessario specificare il nome completo del file, ad esempio mySystemScript.bat. Si tratta di una limitazione del codice Java.
Facoltativamente, è possibile scrivere dei file script delle metriche personalizzati che definiscano il comando che Load Balancer invierà alle macchine server. Accertarsi che gli script personalizzati siano eseguibili e posizionati nella directory ...ibm/edge/lb/ms/script. Gli script personalizzati devono restituire un valore di carico numerico.
Per eseguire Metric Server su un indirizzo diverso dall'host locale, modificare il file metricserver sulla macchina server con bilanciamento del carico. Nel file metricserver, dopo java, inserire quanto segue:
-Djava.rmi.server.hostname=OTHER_ADDRESS
Inoltre, prima delle istruzioni "if" nel file metricserver, aggiungere: hostname OTHER_ADDRESS .
Per sistemi Windows: creare l'alias di OTHER_ADDRESS sullo stack di Microsoft. Per creare l'alias di un indirizzo sullo stack Microsoft, vedere pagina ***.
WLM è il codice che viene eseguito sui mainframe MVS. È possibile eseguire delle query sul carico sulla macchina MVS.
Quando Workload Management MVS è stato configurato sul sistema OS/390, i controller possono accettare le informazioni sulla capacità provenienti da WLM e utilizzarle nel processo di bilanciamento del carico. Utilizzando l'advisor WLM, i controller aprono periodicamente le connessioni tramite la porta WLM su ciascun server nella tabella host del consultant e accettano i numeri interi sulla capacità che vengono restituiti. Poiché tali numeri interi rappresentano la capacità ancora disponibile e i consultant si aspettano al contrario i valori dei carichi di ciascuna macchina, i numeri interi della capacità vengono invertiti dall'advisor e normalizzati in valori del carico (ad esempio, un numero intero grande che rappresenta la capacità e un numero piccolo che rappresenta il carico indicano entrambi un server in buono stato di funzionamento). Numerose importanti differenze distinguono l'advisor WLM dagli altri advisor dei controller:
La funzione di 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.
Per poter registrare le informazioni sui log binari, il consultant deve essere in esecuzione.
Utilizzare il gruppo di comandi xxxcontrol consultant binarylog 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 consultant invia le informazioni sui server al server dei 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 consultant 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 consultant, espresso in secondi, impostare l'intervallo di registrazione su un valore inferiore a quello dell'intervallo di invio delle informazioni da parte del consultant 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 consultant 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 sui server ogni 60 secondi consente di ottenere istantanee di informazioni relative ai 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. Questa eliminazione viene eseguita solo se il server dei log viene richiamato dal consultant; quindi se si arresta il consultant, i file di log vecchi non vengono cancellati.
Un programma Java e un file dei comandi di esempio sono forniti nella directory ...ibm/edge/lb/servers/samples/BinaryLog. 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.
Di seguito viene riportato un esempio che utilizza lo script e il programma forniti:
xxxlogreport 2002/05/01 8:00 2002/05/01 17:00
Ciò genera un report delle informazioni sui server da parte del controller dalle 8:00 della mattina alle 5:00 del pomeriggio, nel giorno del primo maggio 2002.
Load Balancer fornisce uscite utente che attivano script personalizzabili. È possibile creare gli script per eseguire azioni automatizzate, quali avvisare un amministratore quando i server sono contrassegnati come inattivi o semplicemente registrare l'evento del malfunzionamento. Gli script di esempio, personalizzabili, si trovano nella directory di installazione ...ibm/edge/lb/servers/samples. Per eseguire i file, copiarli sulla directory ...ibm/edge/lb/servers/bin , quindi ridenominare ciascun file in base alle istruzioni contenute nello script.
Vengono forniti i seguenti script di esempio, dove xxx è cco per Cisco CSS Controller e nal per Nortel Alteon Controller:
Questa sezione contiene informazioni sulla gestione e sulla risoluzione dei problemi di Load Balancer. Contiene i seguenti capitoli:
Questo capitolo illustra il funzionamento e la gestione di Load Balancer e comprende le seguenti sezioni:
Load Balancer fornisce due diverse modalità per eseguire i programmi di configurazione su una macchina separata da quella in cui risiede Load Balancer. La comunicazione tra i programmi di configurazione (dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol) e il server (dsserver, cbrserver e così via) può essere stabilita utilizzando uno dei seguenti metodi:
Il vantaggio dell'uso dell'amministrazione remota con RMI rispetto all'amministrazione basata sul Web è rappresentato dalle prestazioni più veloci.
I vantaggi dell'uso dell'amministrazione basata sul Web consistono nel fatto che forniscono un'amministrazione remota, protetta e autenticata, in grado di comunicare con la macchina, anche se è presente un firewall. Inoltre, questo metodo di amministrazione non richiede l'installazione e l'uso di chiavi di autenticazione (lbkeys) sulla macchina client remota in comunicazione con la macchina Load Balancer.
Per RMI, il comando per il collegamento a una macchina Load Balancer per l'amministrazione remota è dscontrol host:host_remoto.
Se la chiamata RMI proviene da una macchina diversa da quella locale, deve verificarsi una sequenza di autenticazione della chiave pubblica/chiave privata.
La comunicazione tra i programmi di controllo in esecuzione sulla stessa macchina dei server del componente non viene autenticata.
Utilizzare il seguente comando per generare chiavi pubbliche e private da utilizzare per l'autenticazione remota:
Questo comando viene eseguito solo sulla stessa macchina di Load Balancer.
L'uso dell'opzione create crea una chiave privata nella directory delle chiavi dei server (...ibm/edge/lb/servers/key/) e crea le chiavi pubbliche nella directory delle chiavi di amministrazione (...ibm/edge/lb/admin/keys/) per ciascun componente Load Balancer. Il nome file della chiave pubblica è: componente- ServerAddress-RMIport. Queste chiavi pubbliche devono quindi essere trasportate sui client remoti e inserite nella directory delle chiavi di amministrazione.
In una macchina Load Balancer con indirizzo nome host 10.0.0.25 che utilizza la porta RMI predefinita per ciascun componente, il comando lbkeys create genera i seguenti file:
Il fileset di amministrazione è stato installato su un'altra macchina. I file delle chiavi pubbliche devono essere inseriti nella directory ...ibm/edge/lb/admin/keys sulla macchina client remota.
Il client remoto sarà, quindi, autorizzato a configurare Load Balancer su 10.0.0.25.
Le stesse chiavi devono essere utilizzate su tutti i client remoti che si desidera autorizzare per configurare Load Balancer su 10.0.0.25.
Se si dovesse eseguire nuovamente il comando lbkeys create, verrebbe generato un nuovo gruppo di chiavi pubbliche/private. Ciò significherebbe che tutti i client remoti a cui si tentasse di connettersi utilizzando le chiavi precedenti non sarebbero autorizzati. La nuova chiave dovrebbe essere inserita nella directory corretta di quei client che si desidera autorizzare nuovamente.
Il comando lbkeys delete cancella le chiavi private e pubbliche sulla macchina server. Se queste chiavi vengono cancellate, non verrà autorizzato il collegamento dei client remoti ai server.
Per entrambi i comandi lbkeys create e lbkeys delete è disponibile un'opzione force. L'opzione force elimina i prompt dei comandi che richiedono se si desidera sovrascrivere o cancellare le chiavi esistenti.
Una volta stabilita la connessione RMI, è possibile comunicare tra i programmi di configurazione con i comandi dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol, dswizard, cbrwizard e sswizard da un prompt dei comandi. Inoltre, è possibile configurare Load Balancer dalla GUI, digitando lbadmin da un prompt dei comandi.
Per utilizzare l'amministrazione basata sul Web, la macchina client che esegue l'amministrazione remota deve disporre di quanto segue:
Quanto segue è necessario sulla macchina host a cui si accede per eseguire l'amministrazione remota basata sul Web:
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\PROGRA~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\PROGRA~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\PROGRA~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\PROGRA~1\IBM\edge\lb\admin\* Pass /documentation/lang/* C:\PROGRA~1\IBM\edge\lb\documentation\lang\*dove lang è la directory secondaria della lingua (ad esempio, en_US)
Per sistemi Linux e UNIX --
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/lang/* /opt/ibm/edge/lb/documentation/lang/*
ln -s /opt/perl/bin/perl /usr/bin/perl
Per eseguire l'amministrazione basata sul Web, è necessario avviarla sulla macchina host Load Balancer: immettere lbwebaccess dal prompt dei comandi della macchina host.
Sono necessari, inoltre, l'ID utente e la password della macchina host a cui si sta accendendo in modalità remota. L'ID utente e la password sono gli stessi dell'amministrazione Caching Proxy.
Per visualizzare l'amministrazione basata sul Web di Load Balancer, accedere al seguente URL sul browser Web dalla posizione remota:
http:// nome_host/lb-admin/lbadmin.html
Dove nome_host è il nome della macchina a cui si sta accedendo per comunicare con Load Balancer.
Dopo aver caricato la pagina Web, verrà visualizzata la GUI di Load Balancer nella finestra browser per eseguire l'amministrazione basata sul Web.
Dalla GUI di Load Balancer è possibile, inoltre, immettere i comandi di controllo della configurazione. Per immettere un comando dalla GUI:
Aggiornamento della configurazione in modalità remota
Con l'amministrazione remota basata sul Web, se sono presenti più amministratori che aggiornano la configurazione Load Balancer da altre posizioni, sarà necessario aggiornare la configurazione per visualizzare (ad esempio) il cluster, la porta o il server aggiunti (o eliminati) da un altro amministratore. La GUI dell'amministrazione remota basata sul Web fornisce le funzioni Refresh Configuration e Refresh all Configurations.
Dalla GUI basata sul Web, per aggiornare la configurazione
Load Balancer invia le voci a un log del server, a un log del gestore, a un log di monitoraggio delle metriche (registrazione delle comunicazioni con gli agenti Metric Server) e a un log di ciascun advisor utilizzato.
È possibile impostare il livello di registrazione per definire l'estensione dei messaggi scritti sul log. A livello 0, gli errori vengono registrati e Load Balancer registra anche le intestazioni e i record degli eventi che si sono verificati una volta sola (ad esempio, un messaggio relativo all'inizio della scrittura dell'advisor sul log del gestore). Il livello 1 include le informazioni in fase di sviluppo e così via fino al livello 5 che include tutti i messaggi prodotti per facilitare, se necessario, il debug di un problema. Il valore predefinito per i log del gestore, dell'advisor, del server o dell'agente secondario è 1.
È possibile, inoltre, impostare la dimensione massima di un log. Se si imposta la dimensione massima del file di log, il file ripartirà dall'inizio; quando il file raggiunge la dimensione specificata, le voci successive verranno scritte all'inizio del file, sovrascrivendo quindi le precedenti voci di log. Non è possibile impostare la dimensione del log su un valore inferiore a quello corrente. Le voci di log sono dotate di un indicatore di data e ora in modo da poter comunicare l'ordine in cui sono state scritte.
Tanto maggiore sarà il valore impostato per il livello di log, tanto più attentamente dovrà essere selezionata la dimensione del log. A livello 0, è probabilmente più sicuro lasciare la dimensione del log sul valore predefinito di 1MB; tuttavia, durante la registrazione a livello 3 e superiore, è necessario limitare la dimensione senza renderla troppo piccola per essere utile.
Per impostazione predefinita, i log generati da Load Balancer verranno memorizzati nella directory dei log dell'installazione di Load Balancer. Per modificare questo percorso, impostare la variabile lb_logdir nello script dsserver.
Sistemi AIX, HP-UX, Linux e Solaris: lo script dsserver si trova nella directory /usr/bin. In questo script, la variabile lb_logdir è impostata sulla directory predefinita. È possibile modificare questa variabile per specificare la directory di log. Esempio:
LB_LOGDIR=/path/to/my/logs/
Sistemi Windows: il file dsserver si trova nella directory di sistema Windows C:\WINNT\SYSTEM32, per Windows 2003. Nel file dsserver, la variabile lb_logdir è impostata sulla directory predefinita. È possibile modificare questa variabile per specificare la directory di log. Esempio:
set LB_LOGDIR=c:\path\to\my\logs\
In tutti i sistemi operativi, verificare che non ci siano spazi ai lati del segno uguale e che il percorso termini con una barra ("/" o "\" come appropriato).
La funzione di registrazione binaria di Load Balancer utilizza la stessa directory di log degli altri file di log. Vedere Utilizzo della registrazione binaria per analizzare le statistiche dei server.
È possibile impostare il livello di log per definire l'estensione dei messaggi scritti sul log. A livello 0, gli errori vengono registrati e Load Balancer registra anche le intestazioni e i record degli eventi che si sono verificati una volta sola (ad esempio, un messaggio relativo all'inizio della scrittura dell'advisor nel log del consultant). Il livello 1 include le informazioni in fase di sviluppo e così via fino al livello 5 che include tutti i messaggi prodotti per facilitare, se necessario, il debug di un problema. Il valore predefinito per il log è 1.
È possibile, inoltre, impostare la dimensione massima di un log. Se si imposta la dimensione massima del file di log, il file ripartirà dall'inizio; quando il file raggiunge la dimensione specificata, le voci successive verranno scritte all'inizio del file, sovrascrivendo quindi le precedenti voci di log. Non è possibile impostare la dimensione del log su un valore inferiore a quello corrente. Le voci di log sono dotate di un indicatore di data e ora in modo da poter comunicare l'ordine in cui sono state scritte.
Tanto maggiore sarà il valore impostato per il livello di log, tanto più attentamente dovrà essere selezionata la dimensione del log. A livello 0, è probabilmente più sicuro lasciare la dimensione del log sul valore predefinito di 1MB; tuttavia, durante la registrazione a livello 3 e superiore, è necessario limitare la dimensione senza renderla troppo piccola per essere utile.
Cisco CSS Controller e Nortel Alteon Controller hanno questi log:
Quanto segue è un esempio di configurazione del livello di registrazione e della dimensione massima per un log di monitoraggio delle metriche che registra le comunicazioni con gli agenti Metric Server:
xxxcontrol metriccollector set consultantID:serviceID:metricName loglevel x logsize y
Per impostazione predefinita, i log generati dai controller verranno memorizzati nella directory dei log dell'installazione del controller. Per modificare questo percorso, impostare la variabile xxx_logdir nello script xxxserver.
Sistemi AIX, HP-UX, Linux e Solaris: lo script xxxserver si trova nella directory /usr/bin. In questo script, la variabile xxx_logdir è impostata sulla directory predefinita. È possibile modificare questa variabile per specificare la directory di log. Esempio:
xxx_LOGDIR=/path/to/my/logs/
Sistemi Windows: il file xxxserver si trova nella directory di sistema Windows, di solito C:\WINNT\SYSTEM32. Nel file xxxserver, la variabile xxx_logdir è impostata sulla directory predefinita. È possibile modificare questa variabile per specificare la directory di log. Esempio:
set xxx_LOGDIR=c:\path\to\my\logs\
In tutti i sistemi operativi, verificare che non ci siano spazi ai lati del segno uguale e che il percorso termini con una barra ("/" o "\" come appropriato).
La funzione di registrazione binaria di Load Balancer utilizza la stessa directory di log degli altri file di log. Vedere Utilizzo della registrazione binaria per analizzare le statistiche dei server.
Questo capitolo illustra il funzionamento e la gestione del componente Dispatcher.
In Load Balancer, le connessioni sono considerate inattive quando non ci sono attività su tale connessione per il numero di secondi specificato nel timeout di inattività. Se il numero di secondi è stato superato senza attività, Load Balancer rimuoverà quel record di connessioni dalle tabelle e il traffico successivo non verrà eliminato.
A livello della porta, ad esempio, è possibile specificare il valore di timeout di inattività sul comando dscontrol port set staletimeout.
Il timeout di inattività può essere impostato sui livelli executor, cluster e porta. Ai livelli dell'executor e del cluster, il valore predefinito è 300 secondi ed eseguirà il filtro sulla porta. A livello della porta, il valore predefinito dipende dalla porta. Alcune porte correttamente definite hanno diversi valori di timeout inattività predefiniti. Ad esempio, la porta telnet 23 ha un valore predefinito di 259,200 secondi.
Alcuni servizi potrebbero avere propri valori di timeout inattività. Ad esempio, LDAP (Lightweight Directory Access Protocol) ha un parametro di configurazione denominato idletimeout. Quando i secondi idletimeout vengono superati, la connessione client inattiva verrà chiusa. Idletimeout potrebbe essere impostato su 0, che indica che la connessione non verrà mai chiusa.
I problemi di connettività possono verificarsi quando il valore di timeout di inattività di Load Balancer è inferiore al valore di timeout del servizio. Nel caso di LDAP, il valore predefinito di staletimeout di Load Balancer è 300 secondi. In assenza di attività sulla connessione per 300 secondi, Load Balancer rimuoverà il record di connessione dalle tabelle. Se il valore idletimeout è maggiore di 300 secondi (o impostato su 0), il client potrà ritenere di avere una connessione con il server. Quando il client invia pacchetti, questi vengono eliminati da Load Balancer. Questo causerà la sospensione dell'LDAP quando viene effettuata una richiesta al server. Per evitare il problema, impostare idletimeout di LDAP su un valore diverso da zero inferiore o pari al valore staletimeout di load Balancer.
Un client invia un package FIN dopo aver inviato tutti i pacchetti in modo che il server rilevi il termine della transazione. Quando Dispatcher riceve il package FIN, contrassegna la transazione dallo stato attivo alla stato FIN. Quando una transazione è contrassegnata FIN, la memoria riservata alla connessione può essere cancellata.
Per migliorare le prestazioni dell'assegnazione dei record di connessione e del riutilizzo, utilizzare il comando executor set fintimeout per controllare il periodo durante il quale Dispatcher deve mantenere le connessioni nello stato FIN attive nelle tabelle Dispatcher e accettare il traffico. Una volta che la connessione nello stato FIN supera fintimeout, verrà rimossa dalle tabelle Dispatcher e sarà pronta per il nuovo uso. È possibile modificare il timeout FIN utilizzando il comando dscontrol executor set fincount.
Utilizzare il comando dscontrol executor set staletimeout per controllare il periodo durante il quale Dispatcher deve mantenere le connessioni nello stato Established (stabilita) quando non è stato rilevato traffico attivo nelle tabelle Dispatcher e accettare il traffico. Per ulteriori informazioni, vedere Uso del valore timeout di inattività.
In base alle informazioni ricevute dall'executor e ritrasmesse al gestore, è possibile visualizzare diversi grafici. (L'opzione del menu Monitor della GUI richiede che la funzione gestore sia in esecuzione):
Un sistema di gestione della rete è un programma che viene eseguito in maniera continua ed è utilizzato per monitorare, riflettere lo stato e controllare una rete. Il protocollo SNMP (Simple Network Management Protocol), un protocollo comune utilizzato dai dispositivi di una rete per comunicare tra loro, è lo standard corrente per la gestione della rete. In genere, i dispositivi della rete dispongono di un agente SNMP e di uno o più agenti secondari. L'agente SNMP comunica con la stazione di gestione della rete o risponde alle richieste SNMP immesse sulla riga comandi. L'agente secondario SNMP richiama e aggiorna i dati, quindi li fornisce all'agente SNMP affinché possa rispondere al dispositivo che ha emesso la richiesta.
Dispatcher fornisce una base dati MIB (Management Information Base (ibmNetDispatcherMIB) SNMP e un agente secondario SNMP. Ciò consente di utilizzare un qualsiasi sistema di gestione della rete, quale Tivoli(R) NetView(R), Tivoli Distributed Monitoring, or HP OpenView per monitorare lo stato, la velocità di trasmissione e le attività di Dispatcher. I dati MIB descrivono il Dispatcher sottoposto a gestione e riflettono lo stato corrente del Dispatcher. I dati MIB vengono installati nella directory secondaria ..lb/admin/MIB.
Il sistema di gestione della rete utilizza i comandi SNMP GET per ricercare i valori MIB sulle altre macchine. Quindi, è in grado di notificare all'utente se i valori di soglia specificati sono stati superati. È quindi possibile influire sulle prestazioni di Dispatcher modificando i dati di configurazione di Dispatcher per ottimizzare in modo proattivo o risolvere i problemi di Dispatcher prima che diventino interruzioni di funzionamento di Dispatcher o dei server Web.
Generalmente, il sistema fornisce un agente SNMP per ciascuna stazione di gestione della rete. L'utente invia un comando GET all'agente SNMP. A sua volta, l'agente SNMP invia un comando GET per richiamare i valori variabili dei dati MIB specificati di un agente secondario responsabile per tali variabili MIB.
Dispatcher fornisce un agente secondario che aggiorna e richiama i dati MIB. L'agente secondario risponde con i dati MIB appropriati quando l'agente SNMP invia un comando GET. L'agente SNMP comunica i dati alla stazione di gestione della rete. La stazione di gestione della rete può notificare all'utente se i valori di soglia specificati sono stati superati.
Il supporto SNMP di Dispatcher include un agente secondario SNMP che utilizza la funzione DPI(R) (Distributed Program Interface). DPI è un'interfaccia tra l'agente SNMP e i relativi agenti secondari. Il sistema operativo Windows utilizza l'agente di estensione di Windows come interfaccia tra un agente SNMP e i relativi agenti secondari.
Figura 40. Comandi SNMP per sistemi Linux e UNIX
AIX fornisce un agente SNMP che utilizza il protocollo SNMP Multiplexer (SMUX) e fornisce DPID2, un ulteriore file eseguibile che funge da convertitore tra DPI e SMUX.
Per i sistemi HP-UX, è necessario ottenere un agente SNMP che sia abilitato a SMUX in quanto HP-UX non ne fornisce uno. Load Balancer fornisce DPID2 per sistemi HP-UX.
I sistemi Linux forniscono un agente SNMP che utilizza SMUX. La maggior parte delle versioni Linux (ad esempio, Red Hat) vengono fornite con un package UCD SNMP. Il package UCD SNMP versione 4.1 o successive dispone di agenti abilitati a SMUX. Load Balancer fornisce DPID2 per sistemi Linux.
Per i sistemi Solaris, è necessario ottenere un agente SNMP che sia abilitato al protocollo SMUX in quanto Solaris non ne fornisce uno. Load Balancer fornisce DPID2 per sistemi Solaris nella directory /opt/ibm/edge/lb/servers/samples/SNMP.
L'agente DPI deve essere eseguito come utente root. Prima di eseguire il daemon DPID2, aggiornare il file /etc/snmpd.peers e il file /etc/snmpd.conf nel modo indicato di seguito:
Per sistemi AIX e Solaris:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
Per sistemi Linux:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
Inoltre, è necessario trasformare in commento tutte le righe del file snmpd.conf che iniziano con le seguenti parole: com2sec, group, view o access.
Per installare il supporto SNMP di HP-UX:
Per utilizzare il protocollo SNMP di Load Balancer in SuSE Linux, effettuare le seguenti operazioni:
Aggiornare snmpd (se è già in esecuzione) in modo che legga nuovamente il file snmpd.conf:
refresh -s snmpd
Avviare il peer di DPID SMUX:
dpid2
I daemon devono essere avviati nel seguente ordine:
Per installare il supporto SNMP di Solaris:
da /etc/rc3.d/S76snmpdx a /etc/rc3.d/K76snmpdx
da /etc/rc3.d/S77dmi a /etc/rc3.d/K77dmi
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH: /usr/local/lib:/usr/local/ssl/lib:/usr/lib
export PATH=/usr/local/sbin:/usr/local/bin:$PATH
export SNMPCONFPATH =/etc/snmp
export MIBDIRS=/usr/local/share/snmp/mibs
cp /opt/ibm/edge/lb/servers/samples/SNMP/dpid2 /usr/local/sbin/dpid2
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
Note:
Sul sito Web di http://sunfreeware.com/, i nomi hanno un'estensione .gz, quindi non cercare di decomprimerli. Al contrario, utilizzare pkgadd packageName.
Per installare il supporto SNMP di Windows:
Con l'executor in esecuzione, utilizzare il comando dscontrol subagent start [communityname] per definire il nome comunità utilizzato tra l'agente di estensione del sistema operativo Windows e l'agente SNMP.
IMPORTANTE: in Windows 2003, per impostazione predefinita SNMP non risponde ai nomi comunità. In tal caso, l'agente secondario SNMP non risponderà ad alcuna richiesta SNMP. Per garantire che l'agente secondario SNMP risponda al nome comunità, impostare le proprietà del servizio SNMP sul nome comunità e sugli host di destinazione appropriati. Configurare le proprietà della sicurezza SNMP nel modo indicato di seguito:
SNMP comunica inviando e ricevendo delle trap, messaggi inviati dai dispositivi gestiti per riportare condizioni di eccezione o il verificarsi di eventi significativi, ad esempio una soglia che è stata raggiunta.
L'agente secondario utilizza le trap seguenti:
La trap indHighAvailStatus indica che il valore della variabile dello stato della funzione di disponibilità elevata (hasState) è cambiato. I valori possibili di hasState sono:
La trap indSrvrGoneDown indica che il peso per il server specificato dalla porzione csID (ID cluster), psNum (numero della porta) e ssID (ID server) di Object Identifier ha raggiungo il valore zero. L'ultimo numero noto di connessioni attive per il server viene inviato alla trap. Questa trap indica che, per quanto riguarda il Dispatcher, il server specificato è diventato inattivo.
La trap indDOSAttack indica che numhalfopen, il numero di connessioni aperte a metà costituite solo da pacchetti SYN, ha superato la soglia di maxhhalfopen per la porta specificata dalla porzione csID (ID cluster) e psNum (numero della porta) di Object Identifier. Il numero di server configurati sulla porta viene inviato alla trap. Questa trap indica che Load Balancer potrebbe aver ricevuto un attacco del tipo "Denial Of Service".
La trap indDOSAttackDone indica che numhalfopen, il numero di connessioni aperte a metà costituite solo da pacchetti SYN, ha raggiunto un valore inferiore alla soglia di maxhalfopen per la porta specificata dalla porzione csID e psNum di Object Identifier. Il numero di server configurati sulla porta viene inviato alla trap. Quando Load Balancer stabilisce che l'eventuale attacco "Denial of Service" è terminato, questa trap verrà inviata dopo l'invio di una trap indDOSAttack.
In Linux e UNIX, a causa delle limitazioni delle API SMUX, l'identificatore azienda riportato nelle trap dall'agente secondario ibmNetDispatcher potrebbe essere l'identificativo azienda di dpid2, anziché l'identificativo azienda di ibmNetDispatcher, 1.3.6.1.4.1.2.6.144. Tuttavia, i programmi di utilità di gestione del protocollo SNMP saranno in grado di determinare l'origine della trap in quanto i dati contengono un identificatore oggetto proveniente dai dati MIB di ibmNetDispatcher.
Il comando dscontrol subagent start attiva il supporto SNMP. Il comando dscontrol subagent stop disattiva il supporto SNMP.
Per ulteriori informazioni sul comando dscontrol, vedere dscontrol subagent -- configura l'agente secondario SNMP.
Il kernel Linux dispone di una funzione firewall incorporata denominata ipchains. Quando Load Balancer e ipchains vengono eseguiti contemporaneamente, Load Balancer rileva prima i pacchetti, seguiti da ipchains. Ciò consente l'uso di ipchains per rifiutare tutto il traffico sulla macchina Load Balancer Linux, che potrebbe essere, ad esempio, una macchina utilizzata per eseguire il bilanciamento del carico sui firewall.
Quando ipchains o iptables sono configurati come completamente ristretti (nessun traffico in entrata o in uscita consentito), la parte di inoltro del package di Load Balancer continua a funzionare normalmente.
Notare che ipchains e iptables non possono essere utilizzati per filtrare il traffico in entrata prima di aver eseguito il bilanciamento del carico.
Una parte di traffico aggiuntivo deve essere consentito affinché Load Balancer funzioni correttamente. Di seguito sono riportati alcuni esempi di questa comunicazione:
In generale, una strategia ipchains appropriata per le macchine Load balancer consiste nel non consentire tutto il traffico, ad eccezione di quello verso e dai server di backend, partner Load Balancer a disponibilità elevata, qualsiasi destinazione accessibile o qualsiasi host di configurazione.
Si consiglia di non attivare iptables con Load Balancer in esecuzione sul kernel Linux versione 2.4.10.x. L'attivazione su questa versione di kernel Linux, nel tempo, può determinare un peggioramento delle prestazioni.
Per disattivare iptables, elencare i moduli (lsmod) per visualizzare i moduli utilizzati da ip_tables e ip_conntrack, quindi rimuoverli immettendo rmmod ip_tables e rmmod ip_conntrack. Quando viene riavviata la macchina, questi moduli vengono nuovamente aggiunti in modo che sarà necessario ripetere queste operazioni ad ogni riavvio.
Per ulteriori informazioni, vedere Problema: su sistemi Linux, iptables può interferire con l'instradamento dei pacchetti.
Questo capitolo illustra il funzionamento e la gestione del componente CBR di Load Balancer.
CBR e Caching Proxy collaborano tramite l'API plugin Caching Proxy per gestire le richieste HTTP e HTTPS (SSL). Affinché CBR possa iniziare il bilanciamento del carico sui server, è necessario che Caching Proxy sia in esecuzione sulla stessa macchina. Configurare CBR e Caching Proxy come descritto nell'esempio di configurazione CBR.
Dopo aver avviato CBR, è possibile controllarlo utilizzando uno dei seguenti metodi:
I log utilizzati da CBR sono simili a quelli utilizzati in Dispatcher. Per ulteriori informazioni, vedere Utilizzo dei log di Load Balancer.
Dopo aver avviato Site Selector, è possibile controllarlo utilizzando uno dei seguenti metodi:
I log utilizzati da Site Selector sono simili a quelli utilizzati in Dispatcher. Per ulteriori informazioni, vedere Utilizzo dei log di Load Balancer.
Dopo aver avviato Cisco CSS Controller, è possibile controllarlo utilizzando uno dei seguenti metodi:
I log utilizzati da Cisco CSS Controller sono simili a quelli utilizzati in Dispatcher. Per ulteriori informazioni, vedere Utilizzo dei log di Load Balancer.
Dopo aver avviato Nortel Alteon Controller, è possibile controllarlo utilizzando uno dei seguenti metodi:
I log utilizzati da Nortel Alteon Controller sono simili a quelli utilizzati in Dispatcher. Per ulteriori informazioni, vedere Utilizzo dei log di Load Balancer.
Metric Server fornisce le informazioni sul carico del server a Load Balancer. Metric Server risiede su ciascun server sottoposto a bilanciamento del carico.
Sistemi Linux e UNIX:
Sistemi Windows:
Fare clic su Start > Impostazioni (in Windows 2000) > Pannello di controllo > Strumenti di amministrazione > Servizi. Fare clic con il tasto destro del mouse su IBM Metric Server e selezionare Avvia. Per arrestare il servizio, effettuare le stesse operazioni e selezionare Arresta.
Modificare il livello di log nello script di avvio di Metric Server. È possibile specificare un numero di livello dei log compreso tra 0 e 5, analogamente all'intervallo dei livelli nei log di Load Balancer. In questo modo viene generato un log degli agenti nella directory ...ms/logs.
Questo capitolo aiuta a rilevare e risolvere problemi associati a Load Balancer.
Utilizzare le informazioni fornite in questa sezione per raccogliere i dati richiesti dall'assistenza IBM. Le informazioni sono suddivise tra i seguenti argomenti.
Per il solo componente Dispatcher, è disponibile uno strumento per l'individuazione dei problemi che provvede automaticamente alla raccolta dei dati specifici del sistema operativo e dei file di configurazione del componente. Per eseguire questo strumento, digitare lbpd dalla directory adeguata:
Per sistemi Linux e UNIX: /opt/ibm/edge/lb/servers/bin/
Per sistemi Windows: C:\Program Files\IBM\edge\lb\servers\bin
Questo strumento di individuazione dei problemi crea un file archivio dei dati nel modo seguente:
Per sistemi Linux e UNIX: /opt/ibm/edge/lb/lbpmr.tar.Z
Per sistemi Windows: C:\Program Files\IBM\edge\lb\lbpmr.zip
Prima di contattare l'assistenza IBM, reperire le seguenti informazioni.
dscontrol file save primary.cfg
Questo comando colloca il file di configurazione nella directory .../ibm/edge/lb/servers/configuration/componente/.
java -fullversion
Sui sistemi AIX, HP-UX, Linux e Solaris: netstat -ni
Sui sistemi Windows: ipconfig /all
Questo dato deve essere ottenuto da tutti i server e Load Balancer.
Sui sistemi AIX, HP-UX, Linux e Solaris: netstat -nr
Sui sistemi Windows: route print
Questo dato deve essere ottenuto da tutti i server e Load Balancer.
Raccogliere le informazioni seguenti, richieste per i problemi in un ambiente HA.
Sui sistemi AIX, HP-UX, Linux e Solaris: /opt/ibm/edge/lb/servers/bin
Sistemi Windows: C:\Program Files\ibm\edge\lb\servers\bin
I nomi degli script sono:
goActive
goStandby
goIdle (se presente)
goInOp (se presente)
Includere anche i file di configurazione. Vedere Informazioni generali (sempre richieste).
Raccogliere le informazioni seguenti, richieste per i problemi di advisor; ad esempio, quando gli advisor contrassegnano erroneamente dei server come inattivi.
dscontrol advisor loglevel http 80 5
o
dscontrol advisor loglevel advisorName porta loglevel
o
dscontrol advisor loglevel advisorName cluster:port loglevel
o
nalcontrol metriccollector set consultantID:serviceID:metricName loglevel valore
Questo crea un log denominato ADV_nomeAdvisor.log; ad esempio, ADV_http.log. Questo log si trova nella posizione seguente:
Piattaforme AIX, HP-UX, Linux e Solaris: /opt/ibm/edge/lb/servers/logs/componente
Piattaforme Windows: C:\Program Files\ibm\edge\lb\servers\logs\componente
Dove componente è:
dispatcher = Dispatcher
cbr = Content Based Routing
cco = Cisco CSS Controller
nal = Nortel Alteon Controller
ss = Site Selector
La chiamata ADVLOG stampa istruzioni nel file di log degli advisor quando il livello è inferiore al livello di log associato agli advisor. Un livello di log 0 comporta che le istruzioni vengono scritte sempre. Non è possibile utilizzare ADVLOG dal costruttore. Il file di log non viene creato fino a subito dopo il completamento del costruttore dell'advisor, dal momento che il nome del file di log dipende da informazioni che vengono impostate nel costruttore.
C'è un altro modo per eseguire il debug di un advisor personalizzato aggirando questa limitazione. È possibile utilizzare istruzioni System.out.println(messaggio) per stampare i messaggi in una finestra. Modificare lo script dsserver e sostituire javaw con java per far sì che le istruzioni di stampa appaiano nella finestra. La finestra utilizzata per avviare dsserver deve essere mantenuta aperta per consentire la visualizzazione dei messaggi. Se si utilizza una piattaforma Windows, è necessario arrestare l'esecuzione di Dispatcher come servizio e avviarlo manualmente da una finestra per poter vedere i messaggi.
Vedere Guida alla programmazione per Edge Components per ulteriori informazioni su ADVLOG.
Raccogliere le informazioni seguenti, richieste per i problemi di CBR (Content Based Routing).
Sistemi Linux e UNIX: /etc/
Sistemi Windows: C:\Program Files\IBM\edge\cp\etc\en_US\
Sistemi Linux e UNIX: /opt/ibm/edge/lb/servers/configurations/cbr
Sistemi Windows: C:\Program Files\IBM\edge\lb\servers\configurations\cbr
Se non è possibile raggiungere il cluster, una o entrambe le macchine Load Balancer potrebbero non disporre di un alias per il cluster. Per determinare a quale macchina appartiene il cluster:
ping cluster arp -aSe si utilizzano i metodi di inoltro NAT o CBR di Dispatcher, eseguire un ping anche all'indirizzo mittente.
Sui sistemi AIX e HP-UX: netstat -ni
Sui sistemi Linux e Solaris: ifconfig -a
Sui sistemi Windows: ipconfig /all
Se non si ottiene una risposta dal ping, è possibile che nessuna delle due macchine abbia un alias per l'indirizzo IP del cluster sulla propria interfaccia, ad esempio en0, tr0 e così via.
Se non si è in grado di risolvere i problemi di instradamento e tutte le altre soluzioni non hanno avuto esito positivo, immettere il comando seguente per eseguire una traccia del traffico di rete:
iptrace -a -s IndirizzoIPClientConErrori -d IndirizzoIPCluster -b iptrace.trc
Eseguire la traccia, ricreare il problema e interrompere il processo.
tcpdump -i lan0 host cluster e host client
Potrebbe essere necessario scaricare tcpdump da uno dei siti di archivi software GNU per HP-UX.
tcpdump -i eth0 host cluster e host client
Eseguire la traccia, ricreare il problema e interrompere il processo.
snoop -v clientIPAddress destinationIPAddress > snooptrace.out
È inoltre possibile aumentare diversi livelli di log (quali log del gestore, log dell'advisor e così via) e analizzarne l'output.
Per identificare un problema già risolto in un fix pack di una release di servizio o in una patch, verificare la disponibilità di aggiornamenti. Per ottenere un elenco dei difetti di Edge Components risolti, vedere la pagina di assistenza del sito Web dedicato a WebSphere Application Server: http://www.ibm.com/software/webservers/appserv/was/support/. Dalla pagina di assistenza, seguire il link al sito per il download delle correzioni di servizio.
La versione corretta del codice Java viene installata insieme a Load Balancer.
Per link a pagine Web di assistenza e librerie, vedere Informazioni di riferimento. La pagina Web di assistenza contiene un link a informazioni di "autoassistenza" sotto forma di Technote.
Vedere quanto segue per:
Tabella 17. Tabella di risoluzione dei problemi di Dispatcher
Sintomo | Possibile causa | Andare a... |
---|---|---|
Dispatcher non viene eseguito correttamente | Numeri di porta in conflitto | Controllo dei numeri di porta di Dispatcher |
È stato configurato un server in co-locazione, che non risponde alle richieste di bilanciamento del carico | Indirizzo errato o in conflitto | Problema: Dispatcher e il server non rispondono |
Le connessioni dalle macchine client non ottengono risposta alle richieste o scadono |
| Problema: le richieste di non vengono sottoposte a bilanciamento |
Le richieste delle macchine cluster non vengono soddisfatte o scadono | Mancato funzionamento della disponibilità elevata | Problema: la funzionalità di disponibilità elevata di Dispatcher non funziona |
Impossibile aggiungere heartbeat (piattaforma Windows) | L'indirizzo di origine non è configurato su una scheda | Problema: impossibile aggiungere heartbeat (piattaforma Windows) |
Il server non soddisfa le richieste (piattaforma Windows) | È stato creato un instradamento in eccesso nella tabella di instradamento | Problema: instradamenti in eccesso (Windows 2000) |
Gli advisor non funzionano correttamente con Wide Area | Gli advisor non sono in esecuzione sulle macchine in remoto | Problema: gli advisor non funzionano correttamente |
Dispatcher, Microsoft IIS e SSL non funzionano o si interrompono | Impossibile inviare dati cifrati tra protocolli | Problema: Dispatcher, Microsoft IIS e SSL non funzionano (piattaforma Windows) |
Connessione alla macchina in remoto rifiutata | Una versione precedente delle chiavi è ancora in uso | Problema: connessione di Dispatcher a una macchina in remoto |
Il comando dscontrol o lbadmin provoca un messaggio di errore 'Il server non risponde' o Impossibile accedere al server RMI' |
| Problema: esecuzione errata dei comandi dscontrol o lbadmin |
Messaggio di errore "Impossibile trovare il file..." durante l'esecuzione di Netscape come browser predefinito per la visualizzazione della guida in linea (piattaforma Windows) | Impostazione errata per l'associazione dei file HTML | Problema: "Impossibile trovare il file... messaggio di errore quando si tenta di visualizzare la guida in linea |
Interfaccia utente grafica non avviata correttamente | Spazio di paginazione insufficiente | Problema: l'interfaccia utente grafica (GUI) non viene avviata correttamente |
Errore durante l'esecuzione di Dispatcher con Caching proxy installato | Dipendenza file Caching Proxy | Problema: errore nell'esecuzione di Dispatcher con Caching Proxy installato |
Interfaccia utente grafica non visualizzata correttamente. | Risoluzione errata. | Problema: l'interfaccia utente grafica (GUI) non viene visualizzata correttamente |
I pannelli di aiuto a volte scompaiono dietro altre finestre | Limitazione di Java | Problema: sulla piattaforma Windows, le finestre della guida a volte scompaiono dietro altre finestre aperte |
Load Balancer non può elaborare e inoltrare un frame | È necessario un indirizzo MAC univoco per ciascuna NIC | Problema: Load Balancer non può elaborare e inoltrare un frame |
Viene visualizzata una schermata blu | Scheda di rete non installata e configurata | Problema: viene visualizzata una schermata blu quando si avvia l'executor di Load Balancer |
Il percorso di Discovery impedisce il traffico di ritorno | Il cluster ha un alias sul loopback | Problema: il percorso di Discovery impedisce il traffico di ritorno con Load Balancer |
La disponibilità elevata nella modalità Wide Area di Load Balancer non funziona. | Il Dispatcher in remoto deve essere definito come un server in un cluster sul Dispatcher locale | Problema: la disponibilità elevata nella modalità Wide Area di Load Balancer non funziona |
La GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni. | Java non ha accesso a memoria sufficiente per gestire un cambiamento della GUI di tale portata | Problema: la GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni |
Gli indirizzi IP non vengono risolti correttamente sulla connessione remota | Quando si utilizza un client remoto su un'implementazione con socks sicuri, i nomi di dominio completi o i nomi host potrebbero non venire risolti sugli indirizzi IP corretti | Problema: gli indirizzi IP non vengono risolti correttamente sulla connessione remota |
L'interfaccia di Load Balancer in coreano visualizza font sovrapposti o indesiderati su AIX e Linux | Modificare i font predefiniti | Problema: l'interfaccia di in coreano visualizza font sovrapposti o indesiderati su AIX e Linux |
Su sistemi Windows, dopo aver assegnato un alias alla scheda MS Loopback, quando si emettono certi comandi, quale hostname, il sistema operativo risponde in modo non corretto con l'indirizzo alias | Nell'elenco delle connessioni di rete, l'alias appena inserito non deve precedere l'indirizzo locale | Problema: su Windows, l'indirizzo alias viene restituito al posto dell'indirizzo locale quando si immettono comandi quale hostname |
Comportamento imprevisto della GUI quando si utilizza la piattaforma Windows con una scheda video Matrox AGP | Il problema si verifica quando si utilizzano schede video Matrox AGP durante l'esecuzione della GUI di Load Balancer | Problema: sulla piattaforma Windows, si verifica un comportamento imprevisto della GUI quando si utilizzano schede video Matrox AGP |
Comportamento imprevisto, quale un blocco del sistema, durante l'esecuzione di "rmmod ibmlb" su Linux | Il problema si verifica durante la rimozione manuale del modulo del kernel per Load Balancer (ibmlb). | Problema: comportamento imprevisto quando si esegue rmmod ibmlb (Linux) |
Tempo di risposta eccessivo durante l'esecuzione di comandi sulla macchina Dispatcher | Il tempo di risposta eccessivo può essere dovuto a un sovraccarico della macchina provocato da un elevato volume di traffico client | Problema: tempo di risposta eccessivo durante l'esecuzione di comandi sulla macchina Dispatcher |
Per il metodo di inoltro MAC di Dispatcher, gli advisor SSL o HTTPS non registrano i carichi del server | Si verificano problemi perché l'applicazione server SSL non è configurata con l'indirizzo IP del cluster | Problema: per il metodo di inoltro MAC, gli advisor SSL o HTTPS non registrano i carichi del server |
Disconnessione dall'host quando si utilizza l'amministrazione Web in remoto con Netscape | La disconnessione dall'host si verifica quando viene ridimensionata la finestra del browser | Problema: si verifica una disconnessione dall'host quando si ridimensiona la finestra del browser Netscape durante l'uso della gestione Web |
Il lotto socket è abilitato e il server Web esegue il bind a 0.0.0.0 | Configurare il server Microsoft IIS con bind specifico | Problema: il lotto socket è abilitato e il server Web esegue il binding a 0.0.0.0 |
Sulla piattaforma Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti | Modificare le proprietà dei font della finestra del prompt dei comandi | Problema: su Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti |
Sulla piattaforma HP-UX, viene visualizzato il seguente messaggio: java.lang.OutOfMemoryError Impossibile creare un nuovo thread nativo | Alcune installazioni di HP-UX consentono, per impostazione predefinita, 64 thread per processo. Questo valore è insufficiente. | Problema: su HP-UX, si verifica un errore di esaurimento memoria / thread di Java |
Sulla piattaforma Windows, gli advisor e le destinazioni finali contrassegnano tutti i server come inattivi | Task Offload non è disabilitato o può richiedere l'abilitazione di ICMP. | Problema: su Windows, gli advisor e le destinazioni finali contrassegnano tutti i server come inattivi |
Sulla piattaforma Windows, si verificano problemi nella risoluzione di un indirizzo IP in un nome host quando su una scheda sono configurati più indirizzi | L'indirizzo IP desiderato come proprio nome host deve comparire per primo nel registro di configurazione. | Problema: su Windows, si verificano problemi nella risoluzione di un indirizzo IP in un nome host quando su una scheda sono configurati più indirizzi |
Sulla piattaforma Windows, gli advisor non funzionano in un'installazione a disponibilità elevata dopo un'interruzione della rete | Quando il sistema rileva un'interruzione della rete, cancella la propria cache ARP (Address Resolution Protocol) | Problema: su Windows, gli advisor non funzionano in un'installazione a disponibilità elevata dopo un'interruzione della rete |
Su sistemi Linux, il comando "IP address add" e gli alias loopback per cluster multipli non sono compatibili | Quando si definiscono alias per più di un indirizzo sul dispositivo loopback, utilizzare il comando ifconfig anziché ip address add | Problema: su Linux, non utilizzare il comando "IP address add" quando si crea un alias per cluster multipli sull'unità loopback |
Messaggio di errore: "Indirizzo router non specificato o non valido per il metodo della porta" quando si tenta di aggiungere un server | Elenco di controllo delle informazioni per individuare il problema che si è verificato durante l'aggiunta di un server | Problema: messaggio di errore "Indirizzo router non specificato o non valido per il metodo della porta" |
Su sistemi Solaris, i processi di Load Balancer si interrompono quando si chiude la sessione di terminale da cui sono stati avviati | Utilizzare il comando nohup per impedire che i processi avviati ricevano un segnale di interruzione all'uscita della sessione di terminale. | Problema: su Solaris, i processi di Load Balancer si interrompono quando si chiude la sessione di terminale da cui sono stati avviati |
Si verifica un rallentamento durante il caricamento di configurazioni Load Balancer | Il ritardo potrebbe essere dovuto a chiamate Domain Name System (DNS) eseguite per risolvere e verificare l'indirizzo del server. | Problema: si verifica un ritardo durante il caricamento della configurazione di Load Balancer |
Su sistemi Windows, viene visualizzato il seguente messaggio di errore: È presente un conflitto di indirizzi IP con un altro sistema sulla rete | Se la disponibilità elevata è configurata, gli indirizzi cluster potrebbero essere configurati su entrambe le macchine per un breve periodo, provocando la visualizzazione di questo messaggio di errore. | Problema: su Windows, viene visualizzato un messaggio di errore che segnala un conflitto di indirizzi IP |
In una configurazione a disponibilità elevata, sono attive entrambe le macchine, principali e di backup | Questo problema può verificarsi quando gli script "go" non vengono eseguiti sulla macchina principale o di backup. | Problema: in una configurazione a disponibilità elevata, sono attive entrambe le macchine, principale e di backup |
Le richieste dei client non riescono quando Dispatcher tenta di restituire risposte con pagine di grandi dimensioni | Le richieste client che producono come risposta pagine di grandi dimensioni scadono se l'MTU (Maximum Transmit Unit, unità di trasferimento massima) non è impostata adeguatamente sulla macchina Dispatcher quando si utilizza l'inoltro NAT o CBR. | Problema: le richieste client hanno esito negativo quando si tenta di restituire risposte con pagine di grandi dimensioni |
Sui sistemi Windows, si verifica un errore "Il server non risponde" quando si immette un comando dscontrol o lbadmin | Quando in un sistema Windows esiste più di un indirizzo IP e il file hosts** non specifica l'indirizzo da associare al nome host. | Problema: sui sistemi Windows, si verifica un errore "Il server non risponde" quando si emette un comando dscontrol o lbadmin |
Le macchine Dispatcher a disponibilità elevata potrebbero non sincronizzarsi su Linux per S/390 sui dispositivi qeth | Quando si utilizza la funzione di disponibilità elevata su Linux per S/390 con il driver di rete qeth, i Dispatcher attivo e in sospeso potrebbero non sincronizzarsi. | Problema: le macchine Dispatcher a disponibilità elevata potrebbero non sincronizzarsi su Linux per S/390 sui driver qeth |
Suggerimenti sulla configurazione della funzione di disponibilità elevata di Load Balancer | Questi suggerimenti consentono di risolvere i problemi legati all'alta disponibilità, quali:
| Problema: suggerimenti sulla configurazione dell'HA (high availability) |
Limitazioni della configurazione di inoltro MAC del Dispatcher con piattaforme zSeries e S/390 | Su Linux, esistono delle limitazioni quando si utilizzano server zSeries o S/390 che hanno schede Open System Adapter (OSA). Sono riportate delle possibili soluzioni alternative. | Problema: su Linux, esistono delle limitazioni quando si utilizzano server zSeries o S/390 che hanno schede Open System Adapter (OSA) |
Su alcune versioni di Red Hat Linux, si verifica una mancanza di memoria quando si esegue Load Balancer configurato con il gestore e gli advisor | Le versioni di IBM Java SDK della JVM e Native POSIX Thread Library (NPTL) rilasciato con alcune distribuzioni Linux, come Red Hat Enterprise Linux 3.0, possono causare questa mancanza di memoria. | Problema: su alcune versioni di Red Hat Linux, si verifica una mancanza di memoria quando si esegue Dispatcher Balancer configurato con il gestore e gli advisor |
Su SUSE Linux Enterprise Server 9, il report di Dispatcher indica che i pacchetti vengono inoltrati (aumenta il numero di pacchetti), tuttavia i pacchetti non raggiungono il server di backend | Il modulo NAT iptables viene caricato. Esiste un possibile errore (mai confermato) in questa versione di iptables che provoca un funzionamento anomalo quando si utilizza Dispatcher. | Problema: su SUSE Linux Enterprise Server 9, il report di Dispatcher indica che i pacchetti vengono inoltrati (aumenta il numero di pacchetti), tuttavia i pacchetti non raggiungono il server di backend |
Sui sistemi Windows, quando si utilizza la funzione di disponibilità elevata di Dispatcher, si verificano dei problemi durante il takeover | Se lo script goScript che configura l'indirizzo IP del cluster sulla macchina attiva viene eseguito prima dello script goScript per annullare la configurazione dell'indirizzo IP del cluster sulla macchina di backup, è possibile che si verifichino dei problemi. | Problema: su Windows, viene visualizzato un messaggio di errore che segnala un conflitto di indirizzi IP durante il takeover HA |
Sui sistemi Linux, iptables può interferire con l'instradamento dei pacchetti | Linux iptables può interferire con il bilanciamento del carico del traffico e deve essere disabilitato sulla macchina Load Balancer. | Problema: su sistemi Linux, iptables può interferire con l'instradamento dei pacchetti |
Un messaggio di avvertenza relativo a una serie di file Java viene visualizzato quando si installano le fix dei servizi o quando si utilizzano gli strumenti di assemblaggio del sistema | L'installazione del prodotto è costituita da diversi pacchetti che non devono essere installati sulla stessa macchina, pertanto ognuno di essi installa una serie di file Java. Quando installati sulla stessa macchina, viene visualizzato un messaggio di avvertenza che indica che la serie di file Java è di proprietà anche di un'altra serie di file. | messaggio di avvertenza Java che viene visualizzato quando si installano le fix di servizio |
Aggiornamento della serie di file Java fornita con le installazioni di Load Balancer | Se si verifica un problema con la serie di file Java, è necessario riportare il problema all'assistenza IBM in modo da poter ricevere un aggiornamento alla serie di file Java fornita con l'installazione di Load Balancer. | Aggiornamento della serie di file Java fornita con l'installazione di Load Balancer |
Le connessioni persistenti potrebbero essere rilasciate durante il takeover HA su una piattaforma Windows | Sui sistemi operativi Microsoft Windows, le connessioni persistenti potrebbero essere rilasciate durante un takeover HA. Questo problema esiste solo quando si dispone di un server posizionato che utilizza il metodo di inoltro MAC. | Problema: le connessioni persistenti potrebbero essere rilasciate durante il takeover HA |
Il programma di installazione non verrà eseguito su Linux a 32 bit per zSeries |
L'installazione di WebSphere Edge Server mediante ./install sul sistema operativo Linux a 32 bit per zSeries produce un messaggio "JVM non trovata".
| Problema: l'installazione di WebSphere Edge Server mediante ./install sul sistema operativo Linux a 32 bit per zSeries produce un messaggio "JVM non trovata" |
Il processo di disinstallazione non viene completato correttamente su sistemi Linux |
Il processo di disinstallazione per WebSphere Edge Server termina sui sistemi Linux
| Problema: il processo di disinstallazione per WebSphere Edge Server termina in Linux |
Tabella 18. Tabella di risoluzione dei problemi di CBR
Sintomo | Possibile causa | Andare a... |
CBR non viene eseguito correttamente | Numeri di porta in conflitto | Controllo dei numeri di porta di CBR |
Il comando cbrcontrol o lbadmin provoca un messaggio di errore 'Il server non risponde' o 'Impossibile accedere al server RMI' | Il comando non riesce a causa di uno stack abilitato ai socks. Oppure, i comandi non riescono a causa del mancato avvio di cbrserver | Problema: esecuzione errata dei comandi cbrcontrol o lbadmin |
Le richieste non vengono sottoposte a bilanciamento del carico | Caching Proxy è stato avviato prima dell'executor | Problema: le richieste non vengono sottoposte a bilanciamento del carico |
Su Solaris, il comando cbrcontrol executor start genera il messaggio di errore 'Errore: Executor non avviato'. | Il comando non riesce perché potrebbe essere necessario modificare i valori IPC predefiniti del sistema, o perché il collegamento alla libreria è errato. | Problema: su Solaris, il comando cbrcontrol executor start non riesce |
La regola URL non funziona | Errore di sintassi o di configurazione | Problema: errore di sintassi o di comunicazione |
Comportamento imprevisto della GUI quando si utilizza un sistema Windows con una scheda video Matrox AGP | Il problema si verifica quando si utilizzano schede video Matrox AGP durante l'esecuzione della GUI di Load Balancer | Problema: sulla piattaforma Windows, si verifica un comportamento imprevisto della GUI quando si utilizzano schede video Matrox AGP |
La GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni. | Java non ha accesso a memoria sufficiente per gestire un cambiamento della GUI di tale portata | Problema: la GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni |
Disconnessione dall'host quando si utilizza l'amministrazione Web in remoto con Netscape | La disconnessione dall'host si verifica quando viene ridimensionata la finestra del browser | Problema: si verifica una disconnessione dall'host quando si ridimensiona la finestra del browser Netscape durante l'uso della gestione Web |
Sulla piattaforma Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti | Modificare le proprietà dei font della finestra del prompt dei comandi | Problema: sulla piattaforma Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti |
Sulla piattaforma HP-UX, viene visualizzato il seguente messaggio: java.lang.OutOfMemoryError Impossibile creare un nuovo thread nativo | Alcune installazioni di HP-UX consentono, per impostazione predefinita, 64 thread per processo. Questo valore è insufficiente. | Problema: su HP-UX, si verifica un errore di esaurimento memoria / thread di Java |
Sulla piattaforma Windows, gli advisor e le destinazioni finali contrassegnano tutti i server come inattivi | Task Offload non è disabilitato o può richiedere l'abilitazione di ICMP. | Problema: su Windows, gli advisor e le destinazioni finali contrassegnano tutti i server come inattivi |
Sulla piattaforma Windows, si verificano problemi nella risoluzione di un indirizzo IP in un nome host quando su una scheda sono configurati più indirizzi | L'indirizzo IP desiderato come proprio nome host deve comparire per primo nel registro di configurazione. | Problema: su Windows, si verificano problemi nella risoluzione di un indirizzo IP in un nome host quando su una scheda sono configurati più indirizzi |
Sui sistemi Solaris, i processi di Load Balancer terminano quando si chiude la sessione di terminale da cui sono stati avviati | Utilizzare il comando nohup per impedire che i processi avviati ricevano un segnale di interruzione all'uscita della sessione di terminale. | Problema: su Solaris, i processi di Load Balancer si interrompono quando si chiude la sessione di terminale da cui sono stati avviati |
Tabella 19. Tabella di risoluzione dei problemi di Site Selector
Sintomo | Possibile causa | Andare a... |
---|---|---|
Site Selector non viene eseguito correttamente | Numero di porta in conflitto | Controllo dei numeri di porta di Site Selector |
Site Selector non esegue il round-robin delle richieste in entrata da client Solaris | I sistemi Solaris eseguono un "daemon cache del servizio nomi" | Problema: Site Selector non esegue il round-robin del traffico dai client Solaris |
Il comando sscontrol o lbadmin provoca un messaggio di errore 'Il server non risponde' o 'Impossibile accedere al server RMI' | Il comando non riesce a causa di uno stack abilitato ai socks. Oppure, i comandi non riescono a causa del mancato avvio di ssserver. | Problema: esecuzione errata dei comandi sscontrol o lbadmin |
ssserver on si avvia sulla piattaforma Windows | I sistemi Windows non richiedono che il nome host sia nel DNS. | Problema: ssserver non si avvia su piattaforma Windows |
Una macchina con instradamenti duplicati non esegue correttamente il bilanciamento del carico -- la risoluzione nome sembra non riuscire | Macchina Site Selector con più schede collegate alla stessa sottorete | Problema: Site Selector con instradamenti duplicati non esegue correttamente il bilanciamento del carico |
Comportamento imprevisto della GUI quando si utilizza la piattaforma Windows con una scheda video Matrox AGP | Il problema si verifica quando si utilizzano schede video Matrox AGP durante l'esecuzione della GUI di Load Balancer | Problema: sulla piattaforma Windows, si verifica un comportamento imprevisto della GUI quando si utilizzano schede video Matrox AGP |
La GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni. | Java non ha accesso a memoria sufficiente per gestire un cambiamento della GUI di tale portata | Problema: la GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni |
Disconnessione dall'host quando si utilizza l'amministrazione Web in remoto con Netscape | La disconnessione dall'host si verifica quando viene ridimensionata la finestra del browser | Problema: si verifica una disconnessione dall'host quando si ridimensiona la finestra del browser Netscape durante l'uso della gestione Web |
Sulla piattaforma Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti | Modificare le proprietà dei font della finestra del prompt dei comandi | Problema: sulla piattaforma Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti |
Sulla piattaforma HP-UX, viene visualizzato il seguente messaggio: java.lang.OutOfMemoryError Impossibile creare un nuovo thread nativo | Alcune installazioni di HP-UX consentono, per impostazione predefinita, 64 thread per processo. Questo valore è insufficiente. | Problema: su HP-UX, si verifica un errore di esaurimento memoria / thread di Java |
Sulla piattaforma Windows, gli advisor e le destinazioni finali contrassegnano tutti i server come inattivi | Task Offload non è disabilitato o può richiedere l'abilitazione di ICMP. | Problema: su Windows, gli advisor e le destinazioni finali contrassegnano tutti i server come inattivi |
Sui sistemi Solaris, i processi di Load Balancer terminano quando si chiude la sessione di terminale da cui sono stati avviati | Utilizzare il comando nohup per impedire che i processi avviati ricevano un segnale di interruzione all'uscita della sessione di terminale. | Problema: su Solaris, i processi di Load Balancer si interrompono quando si chiude la sessione di terminale da cui sono stati avviati |
Tabella 20. Tabella di risoluzione dei problemi degli switch Cisco CSS
Sintomo | Possibile causa | Andare a... |
---|---|---|
mancato avvio di ccoserver | Numeri di porta in conflitto | Controllo dei numeri di porta di Cisco CSS Controller |
Il comando ccocontrol o lbadmin provoca un messaggio di errore 'Il server non risponde' o 'Impossibile accedere al server RMI' | Il comando non riesce a causa di uno stack abilitato ai socks. Oppure, i comandi non riescono a causa del mancato avvio di ccoserver. | Problema: esecuzione errata dei comandi ccocontrol o lbadmin |
errore di ricezione: Impossibile creare il registro sulla porta 13099 | Licenza prodotto scaduta | Problema: impossibile creare il registro sulla porta 13099 |
Comportamento imprevisto della GUI quando si utilizza la piattaforma Windows con una scheda video Matrox AGP | Il problema si verifica quando si utilizzano schede video Matrox AGP durante l'esecuzione della GUI di Load Balancer | Problema: sulla piattaforma Windows, si verifica un comportamento imprevisto della GUI quando si utilizzano schede video Matrox AGP |
Viene ricevuto un errore di connessione durante l'aggiunta di un consultant | Le impostazioni di configurazione non sono corrette sullo switch o sul controller | Problema: viene ricevuto un errore di connessione durante l'aggiunta di un consultant |
I pesi non vengono aggiornati sullo switch | La comunicazione con il controller o lo switch non è disponibile o è interrotta | Problema: i pesi non vengono aggiornati sullo switch |
Il comando di aggiornamento non ha aggiornato la configurazione del consultant | La comunicazione tra il controller e lo switch non è disponibile o è interrotta | Problema: il comando di aggiornamento non ha aggiornato la configurazione del consultant |
La GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni. | Java non ha accesso a memoria sufficiente per gestire un cambiamento della GUI di tale portata | Problema: la GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni |
Disconnessione dall'host quando si utilizza l'amministrazione Web in remoto con Netscape | La disconnessione dall'host si verifica quando viene ridimensionata la finestra del browser | Problema: si verifica una disconnessione dall'host quando si ridimensiona la finestra del browser Netscape durante l'uso della gestione Web |
Sulla piattaforma Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti | Modificare le proprietà dei font della finestra del prompt dei comandi | Problema: sulla piattaforma Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti |
Sulla piattaforma HP-UX, viene visualizzato il seguente messaggio: java.lang.OutOfMemoryError Impossibile creare un nuovo thread nativo | Alcune installazioni di HP-UX consentono, per impostazione predefinita, 64 thread per processo. Questo valore è insufficiente. | Problema: su HP-UX, si verifica un errore di esaurimento memoria / thread di Java |
Sui sistemi Solaris, i processi di Load Balancer terminano quando si chiude la sessione di terminale da cui sono stati avviati | Utilizzare il comando nohup per impedire che i processi avviati ricevano un segnale di interruzione all'uscita della sessione di terminale. | Problema: su Solaris, i processi di Load Balancer si interrompono quando si chiude la sessione di terminale da cui sono stati avviati |
Tabella 21. Tabella di risoluzione dei problemi di Nortel Alteon Controller
Sintomo | Possibile causa | Andare a... |
---|---|---|
Mancato avvio di nalserver | Numeri di porta in conflitto | Controllo dei numeri di porta di Nortel Alteon Controller |
Il comando nalcontrol o lbadmin provoca un messaggio di errore 'Il server non risponde' o 'Impossibile accedere al server RMI' | Il comando non riesce a causa di uno stack abilitato ai socks. Oppure, i comandi non riescono a causa del mancato avvio di nalserver. | Problema: esecuzione errata dei comandi nalcontrol o lbadmin |
errore di ricezione: Impossibile creare il registro sulla porta 14099 | Licenza prodotto scaduta | Problema: impossibile creare il registro sulla porta 14099 |
Comportamento imprevisto della GUI quando si utilizza la piattaforma Windows con una scheda video Matrox AGP | Il problema si verifica quando si utilizzano schede video Matrox AGP durante l'esecuzione della GUI di Load Balancer | Problema: sulla piattaforma Windows, si verifica un comportamento imprevisto della GUI quando si utilizzano schede video Matrox AGP |
La GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni. | Java non ha accesso a memoria sufficiente per gestire un cambiamento della GUI di tale portata | Problema: la GUI si blocca (o presenta un altro comportamento imprevisto) quando si tenta di caricare un file di configurazione di grandi dimensioni |
Disconnessione dall'host quando si utilizza l'amministrazione Web in remoto con Netscape | La disconnessione dall'host si verifica quando viene ridimensionata la finestra del browser | Problema: si verifica una disconnessione dall'host quando si ridimensiona la finestra del browser Netscape durante l'uso della gestione Web |
Viene ricevuto un errore di connessione durante l'aggiunta di un consultant | Le impostazioni di configurazione non sono corrette sullo switch o sul controller | Problema: viene ricevuto un errore di connessione durante l'aggiunta di un consultant |
I pesi non vengono aggiornati sullo switch | La comunicazione con il controller o lo switch non è disponibile o è interrotta | Problema: i pesi non vengono aggiornati sullo switch |
Il comando di aggiornamento non ha aggiornato la configurazione del consultant | La comunicazione tra il controller e lo switch non è disponibile o è interrotta | Problema: il comando di aggiornamento non ha aggiornato la configurazione del consultant |
Sulla piattaforma Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti | Modificare le proprietà dei font della finestra del prompt dei comandi | Problema: su Windows, al prompt dei comandi vengono visualizzati caratteri nazionali Latin-1 corrotti |
Sulla piattaforma HP-UX, viene visualizzato il seguente messaggio: java.lang.OutOfMemoryError Impossibile creare un nuovo thread nativo | Alcune installazioni di HP-UX consentono, per impostazione predefinita, 64 thread per processo. Questo valore è insufficiente. | Problema: su HP-UX, si verifica un errore di esaurimento memoria / thread di Java |
Sui sistemi Solaris, i processi di Load Balancer terminano quando si chiude la sessione di terminale da cui sono stati avviati | Utilizzare il comando nohup per impedire che i processi avviati ricevano un segnale di interruzione all'uscita della sessione di terminale. | Problema: su Solaris, i processi di Load Balancer si interrompono quando si chiude la sessione di terminale da cui sono stati avviati |
Tabella 22. Tabella di risoluzione dei problemi di Metric Server
Sintomo | Possibile causa | Andare a... |
---|---|---|
IOException Metric Server su piattaforma Windows durante l'esecuzione di file di metrica utente .bat o .cmd | È richiesto il nome completo della metrica | Problema: IOException Metric Server su piattaforma Windows durante l'esecuzione di file di metrica utente .bat o .cmd |
Metric Server non riporta le informazioni sul carico alla macchina Load Balancer | Tra le cause possibili sono incluse:
| Problema: Metric Server non notifica i carichi alla macchina Load Balancer |
Nel log di Metric Server è riportato "La firma è necessaria per l'accesso all'agente" quando i file di chiavi vengono trasferiti sul server | I file di chiavi non vengono autorizzati perché corrotti. | Problema: nel log di Metric Server è riportato "La firma è necessaria per l'accesso all'agente" |
Sui sistemi AIX, quando si esegue Metric Server sotto carichi elevati in un sistema multiprocessore (AIX 4.3.3 o AIX 5.1), l'output del comando ps -vg potrebbe risultare corrotto | APAR IY33804 corregge questo problema noto di AIX | Problema: su AIX, durante l'esecuzione di Metric Server in condizioni di carico pesante l'output del comando ps vg può risultare corrotto |
Configurazione di Metric Server in una configurazione a due livelli, con bilanciamento del carico mediante Site Selector tra Dispatcher a disponibilità elevata | Metric Server (residente nel secondo livello) non è configurato per l'ascolto su un nuovo indirizzo IP. | Problema: impostazione di Metric Server in una configurazione a due livelli, con bilanciamento del carico mediante Site Selector tra Dispatcher a disponibilità elevata |
Gli script (metricserver, cpuload, memload) eseguiti su macchine Solaris multi-CPU producono messaggi console indesiderati | Questo comportamento è dovuto all'uso del comando di sistema VMSTAT per raccogliere le statistiche su CPU e memoria dal kernel. | Problema: gli script eseguiti su macchine Solaris multi-CPU producono messaggi console indesiderati |
Sui sistemi Solaris, i processi di Load Balancer terminano quando si chiude la sessione di terminale da cui sono stati avviati | Utilizzare il comando nohup per impedire che i processi avviati ricevano un segnale di interruzione all'uscita della sessione di terminale. | Problema: su Solaris, i processi di Load Balancer si interrompono quando si chiude la sessione di terminale da cui sono stati avviati |
Il valore della metrica restituisce -1 dopo aver avviato Metric Server | Questo problema può essere causato dai file delle chiavi che perdono integrità durante il trasferimento dei file al client. | Problema: dopo aver avviato Metric Server, il valore della metrica restituisce -1 |
Se si verificano problemi nell'esecuzione di Dispatcher, questo potrebbe essere dovuto al fatto che una delle applicazioni utilizza un numero di porta normalmente utilizzato da Load Balancer. Tenere presente che il server Dispatcher utilizza i seguenti numeri di porta:
Se un'altra applicazione utilizza uno dei numeri di porta di Dispatcher, è possibile modificare i numeri di porta di Dispatcher o il numero di porta dell'applicazione.
Per modificare i numeri di porta di Dispatcher, procedere come indicato di seguito:
Per modificare il numero della porta RMI dell'applicazione, procedere come indicato di seguito:
Se si verificano problemi nell'esecuzione di CBR, questo potrebbe essere dovuto al fatto che una delle applicazioni utilizza un numero di porta normalmente utilizzato da CBR. Tenere presente che CBR utilizza i seguenti numeri di porta:
Se un'altra applicazione utilizza uno dei numeri di porta di CBR, è possibile modificare i numeri di porta di CBR o il numero di porta dell'applicazione.
Per modificare i numeri di porta di CBR, procedere come indicato di seguito:
Per modificare il numero della porta RMI dell'applicazione, procedere come indicato di seguito:
Se si verificano problemi nell'esecuzione del componente Site Selector, questo potrebbe essere dovuto al fatto che una delle applicazioni utilizza un numero di porta normalmente utilizzato da Site Selector. Tenere presente che Site Selector utilizza i seguenti numeri di porta:
Se un'altra applicazione utilizza uno dei numeri di porta di Site Selector, è possibile modificare i numeri di porta di Site o il numero di porta dell'applicazione.
Per modificare i numeri di porta di Site Selector, procedere come indicato di seguito:
Per modificare il numero della porta RMI dell'applicazione, procedere come indicato di seguito:
Se si verificano problemi nell'esecuzione del componente Cisco CSS Controller, questo potrebbe essere dovuto al fatto che una delle applicazioni utilizza un numero di porta normalmente utilizzato da ccoserver di Cisco CSS Controller. Tenere presente che Cisco CSS Controller utilizza i seguenti numeri di porta:
13099 per ricevere comandi da ccocontrol
10004 per inviare query di metrica a Metric Server
13199 per la porta del server RMI
Se un'altra applicazione utilizza uno dei numeri di porta di Cisco, è possibile modificare i numeri di porta di Cisco CSS Controller o il numero di porta dell'applicazione.
Per modificare i numeri di porta di Cisco CSS Controller, procedere come indicato di seguito:
Per modificare il numero della porta RMI dell'applicazione, procedere come indicato di seguito:
Se si verificano problemi nell'esecuzione del componente Nortel Alteon Controller, questo potrebbe essere dovuto al fatto che una delle applicazioni utilizza un numero di porta normalmente utilizzato da ccoserver di Nortel Alteon Controller. Tenere presente che Nortel Alteon Controller utilizza i seguenti numeri di porta:
14099 per ricevere comandi da nalcontrol
10004 per inviare query di metrica a Metric Server
14199 per la porta del server RMI
Se un'altra applicazione utilizza uno dei numeri di porta di Nortel Alteon Controller, è possibile modificare i numeri di porta di o i numeri di porta dell'applicazione.
Per modificare i numeri di porta di Nortel Alteon Controller, procedere come indicato di seguito:
Per modificare il numero della porta RMI dell'applicazione, procedere come indicato di seguito:
Questo problema può verificarsi quando un'altra applicazione utilizza una delle porte utilizzate da Dispatcher. Per ulteriori informazioni, vedere Controllo dei numeri di porta di Dispatcher.
Questo problema si verifica quando viene utilizzato un indirizzo diverso da quello specificato. Quando si esegue la co-locazione di Dispatcher e server, accertarsi che l'indirizzo del server utilizzato nella configurazione sia l'indirizzo NFA o venga configurato come in co-locazione. Verificare, inoltre, che il file host contenga l'indirizzo corretto.
Questo problema comporta sintomi quali la mancata soddisfazione delle richieste client o la scadenza di connessioni. Per diagnosticare il problema, verificare quanto segue:
Per Windows e altre piattaforme, vedere anche Configurazione delle macchine server per il bilanciamento del carico.
Questo problema compare quando un ambiente a disponibilità elevata di Dispatcher è configurato e le richieste delle connessioni dalle macchine client non vengono soddisfatte o scadono. Per correggere o diagnosticare il problema, verificare quanto segue:
La procedura che segue rappresenta un metodo efficace per verificare il corretto funzionamento degli script di disponibilità elevata:
I due report saranno identici se gli script sono adeguatamente configurati.
Questo errore della piattaforma Windows si verifica quando l'indirizzo origine non è configurato su una scheda. Per correggere o diagnosticare il problema, verificare quanto segue.
dscontrol executor configure <indirizzo ip>
Dopo aver impostato le macchine server, ci si può accorgere di aver inavvertitamente creato uno o più instradamenti in eccesso. Se non eliminati, questi impediranno il funzionamento di Dispatcher. Per verificare e eliminare piattaforme, vedere anche Configurazione delle macchine server per il bilanciamento del carico.
Se si utilizza il supporto Wide Area e gli advisor sembrano non funzionare correttamente, accertarsi che siano avviati su Dispatcher locale e remoto.
Un ping ICMP viene inviato ai server prima della richiesta dell'advisor. Se è presente un firewall tra Load Balancer e i server, accertarsi che questo consenta il passaggio dei ping. Se questa impostazione rappresenta un rischio di sicurezza per la rete, modificare l'istruzione java in dsserver per disattivare tutti i ping ai server aggiungendo la proprietà java:
LB_ADV_NO_PING="true" java -DLB_ADV_NO_PING="true"
Vedere Utilizzo di advisor remoti con il supporto per rete geografica di Dispatcher.
Quando si utilizza Dispatcher, Microsoft IIS e SSL, il loro mancato funzionamento congiunto potrebbe essere dovuto a un problema di abilitazione della sicurezza SSL. Per ulteriori informazioni sulla generazione di una coppia di chiavi, l'acquisizione di un certificato, l'installazione di un certificato con una coppia di chiavi e la configurazione di una directory perché richieda SSL, vedere la documentazione di Microsoft Information and Peer Web Services.
Dispatcher utilizza chiavi per consentire la connessione a una macchina in remoto e la sua configurazione. Le chiavi specificano una porta RMI per la connessione. È possibile modificare la porta RMI, qualora questo sia richiesto per ragioni di sicurezza o a causa della presenza di conflitti. Quando si modificano le porte RMI, il nome file della chiave cambia. Se si dispone di più chiavi per la stessa macchina in remoto nella directory delle chiavi, e queste specificano diverse porte RMI, la riga comandi tenta di utilizzare solo la prima chiave trovata. Se questa non è corretta, la connessione verrà rifiutata. La connessione non avviene finché la chiave errata non viene eliminata.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Questo può causare problemi quando una delle console di gestione viene eseguita sulla stessa macchina di un firewall, oppure attraverso un firewall. Ad esempio, quando Load Balancer viene eseguito sulla stessa macchina di un firewall, e si emettono comandi di dscontrol, potrebbero comparire errori quale Errore: il server non risponde.
Per evitare questo problema, modificare il file script di dsserver per impostare la porta utilizzata da RMI per il firewall (o altra applicazione). Modificare la riga: LB_RMISERVERPORT=10199 in LB_RMISERVERPORT=propriaPorta. Dove propriaPorta è una porta diversa.
Al termine dell'operazione, riavviare dsserver e aprire il traffico per le porte 10099, 10004, 10199 e 10100, oppure per la porta prescelta per l'indirizzo host da cui verrà eseguita la console di gestione.
Ad esempio: java -Djava.rmi.server.hostname="10.1.1.1"
Per le piattaforme Windows, quando si utilizza Netscape come browser predefinito, potrebbe venire visualizzato il seguente messaggio di errore: "Impossibile trovare il file'<nomefile>.html' (o uno dei suoi componenti). Verificare che il percorso e il nome file siano corretti e che tutte le librerie necessarie siano disponibili."
Questo problema è dovuto a un'impostazione errata per l'associazione dei file HTML. La soluzione è la seguente:
L'interfaccia utente grafica (GUI), lbadmin, richiede un adeguato spazio di paginazione per funzionare correttamente. Se lo spazio di paginazione disponibile è insufficiente, potrebbe non avviarsi completamente. In tal caso, controllare ed, eventualmente, aumentare lo spazio di paginazione.
Se si disinstalla Load Balancer per reinstallare un'altra versione e si ottiene un errore quando si tenta di avviare il componente Dispatcher, verificare se è installato Caching Proxy. Caching Proxy ha una dipendenza da uno dei file di Dispatcher; questo file viene disinstallato solo all'atto di disinstallare Caching Proxy.
Per evitare questo problema:
Se si riscontra un problema nell'aspetto della GUI di Load Balancer, verificare l'impostazione della risoluzione del desktop del sistema operativo. La visualizzazione ottimale della GUI avviene a una risoluzione di 1024x768 pixel.
Sulla piattaforma Windows, quando si aprono per la prima volta le finestre della guida, a volte queste scompaiono dietro le finestre esistenti. In tal caso, fare clic sulla finestra per riportarla in primo piano.
Su Solaris ciascuna scheda di rete ha, per impostazione predefinita, lo stesso indirizzo MAC. Questo funziona correttamente quando ogni scheda si trova su una sottorete IP diversa; tuttavia, in un ambiente dotato di switch, quando più NIC con lo stesso MAC e lo stesso indirizzo di sottorete IP comunicano con lo stesso switch, quest'ultimo invia tutto il traffico associato al singolo MAC (e a entrambi gli IP) lungo lo stesso cavo. Solo la scheda che ha inserito per ultima un frame sul cavo vede i pacchetti IP associati per entrambe le schede. Solaris potrebbe scartare i pacchetti per un indirizzo IP valido ma giunti sull'interfaccia "sbagliata".
Se tutte le interfacce di rete non sono destinate a Load Balancer come configurato in ibmlb.conf, e se la NIC non definita in ibmlb.conf riceve un frame, Load Balancer non è in grado di elaborarlo, né di inoltrarlo.
Per evitare questo problema, sovrascrivere il valore predefinito e impostare un indirizzo MAC univoco per ciascuna interfaccia. Utilizzare questo comando:
ifconfig interfaccia ether macAddr
Ad esempio:
ifconfig eri0 ether 01:02:03:04:05:06
Sulla piattaforma Windows, è necessario disporre di una scheda di rete installata e configurata prima di avviare l'executor.
Il sistema operativo AIX contiene un parametro di rete denominato rilevazione percorso MTU. Durante una transazione con un client, se il sistema operativo determina che è necessario utilizzare un valore di MTU (Maximum Transmission Unit) minore per i pacchetti in uscita, questo parametro consente ad AIX di creare un instradamento per memorizzare quei dati. Il nuovo instradamento riguarda l'IP dello specifico client e registra il valore di MTU necessario per raggiungerlo.
Quando viene creato l'instradamento, potrebbe verificarsi un problema sui server, a causa dell'impostazione dell'alias del cluster sul loopback. Se l'indirizzo gateway dell'instradamento rientra nella sottorete/netmask del cluster, AIX crea l'instradamento sul loopback. Ciò avviene perché questa è l'ultima interfaccia per cui è stato creato un alias con tale sottorete.
Se, ad esempio, il cluster è 9.37.54.69 e viene utilizzata una netmask 255.255.255.0 e il gateway desiderato è 9.37.54.1, AIX utilizza il loopback per l'instradamento. Le risposte del server, in questo modo, non lasciano mai la macchina, e il client supera il timeout di attesa. Il client di norma vede una risposta dal cluster, dopodiché viene creato l'instradamento e non riceve nient'altro.
Sono disponibili due soluzioni a questo problema.
Note:
Quando si imposta un Load Balancer Wide Area, è necessario definire il Dispatcher remoto come server in un cluster sul Dispatcher locale. Normalmente, si utilizza l'indirizzo di non inoltro (NFA, Non-Forwarding Address) del Dispatcher remoto come indirizzo destinazione del server remoto. Se si esegue questa operazione e, successivamente, si imposta la disponibilità elevata sul Dispatcher remoto, non funzionerà. Questo avviene perché il Dispatcher locale punta sempre all'elemento primario sul lato remoto quando si utilizza il suo NFA per accedervi.
Per aggirare il problema:
Quando il Dispatcher remoto primario si attiva, crea un alias a questo indirizzo sulla propria scheda, consentendo di accettare il traffico. In caso di guasti, l'indirizzo passa alla macchina di backup, che continua ad accettare traffico per lo stesso indirizzo.
Quando si utilizza lbadmin o l'amministrazione Web (lbwebaccess) per caricare un file di configurazione di grandi dimensioni (circa 200 o più comandi add), la GUI potrebbe bloccarsi o mostrare un comportamento imprevisto, ad esempio rispondere alle modifiche delle schermate con estrema lentezza.
Ciò si verifica perché Java non ha accesso a una quantità di memoria sufficiente a gestire una configurazione di queste dimensioni.
L'ambiente di runtime prevede un'opzione, che può essere specificata per aumentare il lotto di allocazione della memoria disponibile per Java.
Si tratta dell'opzione -Xmxn dove n rappresenta la dimensione massima, in byte, del lotto di allocazione della memoria. n deve essere un multiplo di 1024 e avere un valore superiore a 2MB. Il valore n può essere seguito da k o K a indicare kilobyte, oppure m o M a indicare megabyte. Ad esempio, -Xmx128M e -Xmx81920k sono entrambi validi. Il valore predefinito è 64M. Solaris 8 prevede un valore massimo di 4000M.
Ad esempio, per aggiungere questa opzione, modificare il file script di lbadmin, sostituendo "javaw" con "javaw -Xmxn" come indicato di seguito. (Per i sistemi AIX, modificare "java" in "java -Xmxn"):
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH% %LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main
Non è previsto un valore consigliato per n, ma dovrebbe essere maggiore dell'opzione predefinita. Un buon punto di partenza è rappresentato dal doppio del valore predefinito.
Se la gestione di Load Balancer (lbadmin) si scollega dal server dopo l'aggiornamento della configurazione, verificare la versione di dsserver sul server che si sta tentando di configurare e accertarsi che coincida con quella di lbadmin o dscontrol.
Quando si utilizza un client remoto su un'implementazione con socks sicuri, i nomi di dominio completi o i nomi host potrebbero non venire risolti sugli indirizzi IP corretti nella notazione in formato indirizzo IP. L'implementazione socks potrebbe aggiungere dati specifici, relativi a socks, alla risoluzione DNS.
Se gli indirizzi IP non vengono risolti correttamente sulla connessione remota, si consiglia di specificare l'indirizzo IP nella notazione in formato indirizzo IP.
Per correggere i font sovrapposti o indesiderati nell'interfaccia di Load Balancer in coreano:
Su sistemi AIX
-Monotype-TimesNewRomanWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
Su sistemi Linux
-monotype- timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
-monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
Su Windows, dopo aver assegnato un alias alla scheda MS Loopback, quando si immettono certi comandi, quale hostname, il sistema operativo risponde in modo non corretto con l'indirizzo alias anziché l'indirizzo locale. Per correggere questo problema, nell'elenco delle connessioni di rete, l'alias appena inserito non deve essere elencato al di sotto dell'indirizzo locale. In questo modo, si garantisce che l'accesso avvenga prima all'indirizzo e poi all'alias loopback.
Per controllare l'elenco delle connessioni di rete:
Sulla piattaforma Windows, quando si utilizza una scheda Matrox AGP, potrebbero verificarsi comportamenti imprevisti della GUI di Load Balancer. Quando si fa clic con il mouse, un blocco leggermente più grande del puntatore può corrompersi, provocando un'evidenziazione inversa o lo spostamento delle immagini sullo schermo. Questo comportamento è stato riscontrato nelle schede Matrox meno recenti. Non è disponibile una correzione nota in caso di utilizzo di schede Matrox AGP.
Sui sistemi Linux, se dsserver è ancora in esecuzione durante la rimozione manuale del modulo del kernel per Load Balancer, può verificarsi un comportamento imprevisto, quale un blocco del sistema o javacore. Per la rimozione manuale del modulo del kernel per Load Balancer, è necessario arrestare prima dsserver.
Se "dsserver stop" non funziona, arrestare il processo java con SRV_KNDConfigServer. Arrestare il processo individuandone l'identificatore mediante il comando ps -ef | grep SRV_KNDConfigServer e quindi terminando il processo mediante il comando kill id_processo.
A questo punto, è possibile eseguire senza problemi il comando "rmmod ibmlb" per rimuovere il modulo di Load Balancer dal kernel.
Se si esegue il componente Dispatcher per il bilanciamento del carico, è possibile che il computer venga sovraccaricato di traffico client. Il modulo del kernel per Load Balancer ha la massima priorità e se questogestisce costantemente pacchetti client, il resto del sistema potrebbe smettere di rispondere. L'esecuzione di comandi nello spazio utente potrebbe richiedere molto tempo per il completamento, o non venire mai completata.
In tal caso, è opportuno ristrutturare l'impostazione generale per evitare di sovraccaricare di traffico la macchina Load Balancer. Le alternative comprendono la distribuzione del carico tra più macchine Load Balancer o la sostituzione della macchina con una più veloce e robusta.
Quando si determina se la risposta lenta sulla macchina è dovuta a un elevato traffico client, tenere in considerazione se questo si verifica durante i momenti di picco del traffico client. Anche sistemi non adeguatamente configurati che provocano loop di instradamento possono essere all'origine degli stessi sintomi. Prima di modificare l'impostazione di Load Balancer, stabilire se i sintomi sono dovuti a un elevato carico client.
Quando si utilizza il metodo di inoltro basato su MAC, Load Balancer invia pacchetti ai server utilizzando l'indirizzo cluster con alias sul loopback. Alcune applicazioni server, quale SSL, richiedono che le informazioni di configurazione, quali i certificati, siano basate sull'indirizzo IP. L'indirizzo IP deve essere l'indirizzo cluster configurato sul loopback per la corrispondenza con i contenuti dei pacchetti in entrata. Se l'indirizzo IP del cluster non viene utilizzato durante la configurazione dell'applicazione server, la richiesta del client non verrà inoltrata adeguatamente al server.
Se si sta utilizzando la gestione Web remota, per configurare Load Balancer, non ridimensionare la finestra del browser Netscape (riduzione, ingrandimento, ripristino in basso e così via) in cui viene visualizzata la GUI di Load Balancer. Poiché Netscape ricarica una pagina ogni volta che le finestre del browser vengono ridimensionate, questo provoca la disconnessione dall'host. Sarà necessario riconnettersi all'host ogni volta che si ridimensiona una finestra. Se si esegue l'amministrazione Web da remoto su una piattaforma Windows, utilizzare Internet Explorer.
Quando si esegue il server Microsoft IIS, versione 5.0 sui server backend Windows, è necessario configurare il server Microsoft IIS specifico del collegamento. Altrimenti, il lotto socket viene abilitato per impostazione predefinita e il server Web esegue il binding a 0.0.0.0 e rimane in ascolto di tutto il traffico, anziché eseguire il binding all'indirizzo IP virtuale configurato come identità multiple per il sito. Se un'applicazione sull'host locale si arresta mentre il lotto socket è abilitato, gli advisor dei server AIX o Windows lo rilevano; tuttavia, se un'applicazione su un host virtuale si arresta mentre l'host locale rimane attivo, gli advisor non rilevano il malfunzionamento e Microsoft IIS continua a rispondere a tutto il traffico, compreso quello destinato all'applicazione che non è più attiva.
Per determinare se il lotto socket è abilitato e il server Web esegue il binding a 0.0.0.0, immettere il seguente comando:
netstat -an
Le istruzioni per la configurazione del server Microsoft IIS specifico del collegamento (disattivazione del lotto socket) si trovano sul sito Web di assistenza per prodotti e servizi Microsoft. È inoltre possibile consultare uno dei seguenti URL per ottenere queste informazioni:
In una finestra del prompt dei comandi sul sistema operativo Windows, alcuni caratteri nazionali della famiglia Latin-1 potrebbero risultare corrotti. Ad esempio, la lettera "a" con la tilde potrebbe essere visualizzata come un simbolo di pi greco. Per risolvere questo problema, è necessario modificare le proprietà dei font della finestra del prompt dei comandi. Per modificare il font, procedere come indicato di seguito:
Alcune installazioni di HP-UX 11i sono preconfigurate per consentire solo 64 thread per processo. Tuttavia, alcune configurazioni di Load Balancer richiedono una quantità superiore. Per i sistemi HP-UX, impostare i thread per processo almeno su 256. Per aumentare il valore, servirsi dell'utilità "sam" per impostare il parametro del kernel max_thread_proc. Se si prevede un utilizzo intensivo, potrebbe essere necessario aumentare max_thread_proc oltre 256.
Per aumentare il valore di max_thread_proc, procedere come indicato di seguito:
Durante la configurazione della scheda su una macchina Load Balancer, è necessario accertarsi che le due impostazioni seguenti siano corrette, per consentire il funzionamento dell'advisor:
Sulla piattaforma Windows, quando si configura una scheda perché abbia più indirizzi IP, configurare l'indirizzo IP che si desidera associare al nome host come primo nel registro.
Poiché Load Balancer dipende da InetAddress.getLocalHost() in molti casi (ad esempio, per lbkeys create), più indirizzi IP con alias su una singola scheda possono causare problemi. Per evitare questo problema, collocare per primo nell'elenco del registro l'indirizzo IP sul quale si desidera venga risolto il nome host. Ad esempio:
Per impostazione predefinita, quando il sistema operativo Windows rileva un'interruzione della rete, cancella la propria cache ARP (Address Resolution Protocol), comprese tutte le voci statiche. Dopo il ripristino della rete, la cache ARP viene ripopolata mediante richieste ARP inviate sulla rete.
Con una configurazione a disponibilità elevata, entrambi i server intraprendono operazioni primarie quando sono interessati tutti e due da un problema di connettività di rete. Quando viene inviata la richiesta ARP per ripopolare la cache ARP, entrambi i server rispondono, cosicché la cache ARP contrassegna la voce come non valida. Di conseguenza, gli advisor non sono in grado di creare un socket ai server di backup.
Per risolvere questo problema, impedire al sistema operativo Windows di cancellare la cache ARP quando viene persa la connettività. Microsoft ha pubblicato un articolo che spiega come eseguire questa operazione. L'articolo si trova sul sito Web di Microsoft, nella Microsoft Knowledge Base, numero articolo 239924: http://support.microsoft.com/default.aspx?scid=kb;en-us;239924.
Di seguito viene fornito un riepilogo dei passi descritti nell'articolo di Microsoft per impedire al sistema di cancellare la cache ARP:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
È necessario fare alcune considerazioni quando si utilizzano server con kernel Linux 2.4.x e il metodo di inoltro MAC di Dispatcher. Se il server ha un indirizzo cluster configurato sul dispositivo loopback mediante il comando ip address add, è possibile creare un alias per un solo indirizzo cluster.
Quando si creano alias per cluster multipli sul dispositivo loopback, utilizzare il comando ifconfig, ad esempio:
ifconfig lo:num clusterAddress netmask 255.255.255.255 up
Inoltre, ci sono delle incompatibilità tra il metodo ifconfig e il metodo ip per la configurazione delle interfacce. Come pratica ottimale, è bene scegliere un metodo e utilizzare esclusivamente quello.
Quando si aggiungono server alla configurazione di Dispatcher, può venire generato il seguente messaggio di errore: "Errore: indirizzo router non specificato o non valido per il metodo della porta".
Utilizzare questo elenco di controllo per individuare il problema:
Il valore predefinito del parametro router è 0, che indica un server locale. Quando si imposta l'indirizzo del router del server su un valore diverso da 0, si indica che si tratta di un server remoto, su un'altra sottorete. Per ulteriori informazioni sul parametro router nel comando server add, vedere dscontrol server -- configura i server.
Se il server che si sta aggiungendo si trova su un'altra sottorete, il parametro router dovrà essere l'indirizzo del router da utilizzare sulla sottorete locale per comunicare con il server remoto.
Su Solaris, dopo l'avvio degli script di Load Balancer (quale dsserver o lbadmin) da una finestra di terminale, se si esce dalla finestra viene interrotto anche il processo di Load Balancer.
Per risolvere questo problema, avviare gli script di Load Balancer con il comando nohup. Ad esempio: nohup dsserver. Questo comando impedisce che i processi avviati da una sessione di terminale ricevano un segnale di interruzione dal terminale quando questo viene chiuso, consentendo loro di continuare anche dopo la fine della sessione di terminale. Utilizzare il comando nohup anteponendolo a qualsiasi script di Load Balancer che si desidera far proseguire oltre la fine di una sessione di terminale.
Il ritardo nel caricamento della configurazione di LOad Balancer potrebbe essere dovuto a chiamate Domain Name System (DNS) eseguite per risolvere e verificare l'indirizzo del server.
Se il DNS della macchina Load Balancer non è configurato adeguatamente o se le operazioni DNS in generale richiedono tempi lunghi, questo si aggiunge al ritardo, poiché Java invia richieste DNS sulla rete.
Una soluzione temporanea consiste nell'aggiunta degli indirizzi e dei nomi host dei serve al file /etc/hosts locale.
Se la disponibilità elevata è configurata, gli indirizzi cluster potrebbero essere configurati su entrambe le macchine per un breve periodo, provocando la visualizzazione del seguente messaggio di errore: È presente un conflitto di indirizzi IP con un altro sistema sulla rete. In questo caso, è possibile ignorare il messaggio. Un indirizzo cluster potrebbe essere configurato, per un breve tempo, su entrambe le macchine a disponibilità elevata contemporaneamente, in particolare all'avvio di una delle due macchine o quando viene iniziato un takeover.
Controllare gli script go* per verificare che configurino e deconfigurino correttamente gli indirizzi cluster. Se è stato richiamato un file di configurazione e sono installati gli script go*, accertarsi che il file di configurazione non contenga comandi "executor configure" per gli indirizzi cluster, dal momento che questo sarà in conflitto con i comandi configure e unconfigure negli script go*.
Per ulteriori informazioni sugli script go* nella configurazione della disponibilità elevata, vedere Utilizzo di script.
Questo problema può verificarsi quando gli script "go" non vengono eseguiti sulla macchina principale o di backup. Gli script "go" non possono essere eseguiti se dsserver non è avviato su entrambe le macchine. Verificare che dsserver sia in esecuzione su entrambe le macchine.
Le richieste client che producono come risposta pagine di grandi dimensioni scadono se l'MTU (Maximum Transmit Unit, unità di trasferimento massima) non è impostata adeguatamente sulla macchina Dispatcher. Per i metodi di inoltro CBR e NAT del componente Dispatcher, questo può verificarsi perché Dispatcher utilizza il valore MTU predefinito, anziché negoziarlo.
L'impostazione del valore di MTU avviene su ciascun sistema operativo in base al tipo di supporto di comunicazione, ad esempio Ethernet o Token-Ring. I router del segmento locale potrebbero avere un valore MTU inferiore se si collegano a un tipo di supporto di comunicazione diverso. Con il normale traffico TCP, si verifica una negoziazione MTU durante l'impostazione della connessione e viene utilizzato il valore minimo per l'invio di dati tra le macchine.
Dispatcher non supporta la negoziazione MTU per i metodi di inoltro CBR o NAT perché è attivamente coinvolto come endpoint per le connessioni TCP. Per l'inoltro CBR e NAT, Dispatcher utilizza il valore MTU predefinito di 1500. Questo rappresenta le dimensioni MTU tipiche per le reti Ethernet standard, per cui la maggior parte dei clienti non dovrà modificarlo.
Quando si utilizza il metodo di inoltro CBR o NAT di Dispatcher, se un router al segmento locale ha un valore MTU inferiore, è necessario impostare lo stesso valore sulla macchina Dispatcher.
Per risolvere questo problema, utilizzare il comando seguente per impostare il valore di MSS (Maximum Segment Size): dscontrol executor set mss nuovo_valore
Ad esempio:
dscontrol executor set mss 1400
Il valore predefinito di MSS è 1460.
L'impostazione di MSS non si applica per il metodo di inoltro MAC di Dispatcher o per eventuali componenti di Load Balancer diversi da Dispatcher.
Quando in un sistema Windows esiste più di un indirizzo IP e il file hosts non specifica l'indirizzo da associare al nome host, il sistema operativo sceglie l'indirizzo più breve da associare al nome host.
Per risolvere questo problema, aggiornare il file c:\Windows\system32\drivers\etc\hosts con il nome host della macchina e l'indirizzo IP che si desidera vi venga associato.
IMPORTANTE: l'indirizzo IP non può essere un indirizzo cluster.
Quando si utilizza la funzione di disponibilità elevata su Linux per S/390 con il driver di rete qeth, i Dispatcher attivo e in sospeso potrebbero non sincronizzarsi. Questo problema potrebbe essere limitato al kernel Linux 2.6.
Se si verifica questo problema, adottare la seguente soluzione temporanea:
Definire un dispositivo di rete CTC (channel-to-channel) tra le immagini Dispatcher attivo e in standby e aggiungere un heartbeat tra gli indirizzi IP dei due endpoint CTC.
Con la funzione di alta disponibilità (HA, high availability) per Load Balancer, una macchinapartner può eseguire il bilanciamento del carico se la macchina principale riporta un errore o viene terminata. Per mantenere le connessioni tra le varie macchine, i record delle connessioni vengono inviati tra le macchine. Quando la macchina di backup utilizza la funzione di bilanciamento del carico, l'indirizzo IP del cluster viene rimosso dalla macchina di backup e viene aggiunto alla nuova macchina principale. Esistono numerose considerazioni sulla sincronizzazione e sulla configurazione che possono influenzare questa operazione di takeover.
Per suggerimenti su come risolvere i problemi legati alla configurazione HA (high availability) come:
I seguenti suggerimenti sono utili per una corretta configurazione dell'alta disponibilità sulle macchine Load Balancer.
Tra gli esempi di comandi HA vi sono:
dscontrol highavailability heartbeat add ... dscontrol highavailability backup add ... dscontrol highavailability reach add ...
Nella maggior parte dei casi, è necessario posizionare le definizioni HA alla fine del file. Le istruzioni del cluster, della porta e del server devono essere inserite prima delle istruzioni HA. Ciò perché quando l'alta disponibilità viene sincronizzata, quando viene ricevuto un record di connessione vengono ricercate le definizioni del cluster, della porta e del server.
Se il cluster, la porta o il server non esiste, il record della connessione viene eliminato. Se si verifica un takeover e il record non è stato replicato sulla macchina, la connessione riporterà un errore.
L'eccezione a questa regola è l'utilizzo di server posizionati configurati con il metodo di inoltro MAC. In questo caso, le istruzioni HA devono essere inserite prima delle istruzioni del server posizionato. Se le istruzioni HA non si trovano prima delle istruzioni del server collocato, Load Balancer riceve una richiesta per il server che sembra essere uguale alla richiesta in entrata per il cluster, quindi viene bilanciata. Ciò può portare a un loop di pacchetti sulla rete e a un traffico eccessivo. Quando le istruzioni HA vengono inserite prima del server posizionato, Load Balancer riconosce che non va inoltrato il traffico in entrata fino a che lo stato è ACTIVE.
Per correggere questo problema, aggiungere un ritardo sleep nello script goActive. Il tempo del ritardo dipende dalla distribuzione. Si consiglia di impostare questo ritardo su 10.
Per impostazione predefinita, le macchine provano a comunicare tra loro ogni mezzo secondo e rileveranno un errore dopo quattro tentativi non riusciti. Se la macchina è occupata, è possibile che si verifichino dei failover mentre il sistema funziona correttamente. È possibile aumentare il numero di tentativi emettendo il comando:
dscontrol executor set hatimeout <value>
Perché ciò sia possibile, le vecchie connessioni non devono rimanere in memoria per troppo tempo. In particolare, si sono verificati dei problemi con le porte LDAP e periodi elevati di staletimeout (superiori a un giorno). L'impostazione di un valore elevato per staletimeout implica che le vecchie connessioni restano in memoria, il che causa l'invio di un numero maggiore di record di connessione durante la sincronizzazione e un maggiore utilizzo di memoria su entrambe le macchine.
Se la sincronizzazione non riesce con un staletimeout, è possibile aumentare il timeout di sincronizzazione emettendo:
e xm 33 5 new_timeoutQuesto comando non viene memorizzato nel file di configurazione quando viene salvato, cosicché è necessario aggiungerlo manualmente al file di configurazione, se si desidera che questa impostazione persista tra le chiusure.
Il valore di timeout viene memorizzato in un secondo e mezzo, di conseguenza, il valore predefinito per new_timeout è di 100 (50 secondi).
In generale, quando si utilizza il metodo di inoltro MAC, i server nella configurazione di Load Balancer devono essere tutti sullo stesso segmento di rete, senza tener conto della piattaforma. I dispositivi di rete attivi come router, bridge e firewall, interferiscono con Load Balancer. Ciò si verifica in quanto le funzioni di Load Balancer come un router specializzato, modificano solo le intestazioni a livello di collegamento sull'hop successivo e su quello finale. Qualsiasi topologia di rete in cui l'hop successivo non è l'hop finale non è valida per Load Balancer.
Esiste una limitazione per i server zSeries e S/390 che condividono la scheda OSA in quanto questo adattatore opera in maniera differente dalla maggior parte delle schede di rete. La scheda OSA ha la propria implementazione a livello di collegamento virtuale, che non ha niente a che vedere con Ethernet, presentato agli host Linux e z/OS. In effetti, ogni scheda OSA assomiglia a un host ethernet-to-ethernet (e non agli host OSA) e gli host che la utilizzano risponderanno come se fosse una scheda Ethernet.
La scheda OSA esegue inoltre determinate funzioni relative direttamente al livello IP. La risposta alle richieste ARP (address resolution protocol) è un esempio di funzione eseguita. un altro esempio è che la scheda OSA condivisa indirizza i pacchetti IP in base all'indirizzo IP di destinazione invece che in base a un indirizzo Ethernet come un commutatore di livello 2. In effetti, la scheda OSA è un segmento di rete con bridge su sé stessa.
Il Load Balancer che viene eseguito su un host S/390 Linux o zSeries Linux può inoltrare ad host sulla stessa scheda OSA o ad host sulla scheda Ethernet. Tutti gli host sulla stessa scheda OSA condivisa si trovano sullo stesso segmento.
Load Balancer può inoltrare inoltrare su una scheda OSA condivisa a causa della natura del bridge OSA. Il bridge riconosce la porta OSA che possiede l'IP del cluster. Il bridge riconosce anche l'indirizzo MAC degli host direttamente connessi al segmento Ethernet. Pertanto, Load Balancer può eseguire un inoltro MAC su un unico bridge OSA.
Tuttavia, Load Balancer non può eseguire un inoltro in una scheda OSA condivisa. Tra questi vi è il Load Balancer su S/390 Linux quando il server di backend si trova su una scheda OSA differente da quella di Load Balancer. La scheda OSA per il server di backend identifica l'indirizzo MAC OSA per l'IP del server, ma quando un package arriva all'indirizzo di destinazione Ethernet dell'OSA del server e all'indirizzo IP del cluster, la scheda OSA del server non riconosce l'host che deve ricevere il package. Gli stessi principi che consentono il funzionamento dell'inoltro MAC OSA-to-ethernet di una delle schede OSA condivise non valgono quando si prova a eseguire un inoltro su una scheda OSA condivisa.
Soluzione alternativa:
nelle configurazioni di Load Balancer che utilizzano server zSeries o S/390 che hanno delle schede OSA, esistono due approcci che consentono di risolvere il problema appena descritto.
Se i server nella configurazione di Load Balancer si trovano sullo stesso tipo di piattaforma zSeries o S/390, è possibile definire connessioni point-to-point (CTC o IUCV) tra Load Balancer e ogni server. Impostare gli endpoint con indirizzi IP privati. La connessione point-to-point viene utilizzata solo per il traffico tra Load Balancer e il server. Aggiungere quindi i server con l'indirizzo IP dell'endpoint del server del tunnel. con questa configurazione, il traffico del cluster passa attraverso la scheda OSA di Load Balancer e viene inoltrato sulla connessione point-to-point su cui il server risponde mediante l'instradamento predefinito. La risposta utilizza la scheda OSA del server da lasciare, che potrebbe essere o no la stessa scheda.
Se i server nella configurazione di Load Balancer non si trovano sullo stesso tipo di piattaforma zSeries o S/390 oppure se non è possibile definire una connessione point-to-point tra Load Balancer e ogni server, si consiglia di utilizzare la funzione GRE (Generic Routing Encapsulation) di Load Balancer, che è un protocollo che consente a Load Balancer di eseguire un inoltro attraverso i router.
Quando si utilizza la funzione GRE, il package IP client->cluster viene ricevuto da Load Balancer, viene integrato e quindi inviato al server. Sul server, il package IP client->cluster originale viene incapsulato e il server risponde direttamente al client. Il vantaggio dell'utilizzo della funzione GRE sta nel fatto che Load Balancer vede soltanto il traffico client-server e non quello server-client. Lo svantaggio sta nel fatto che riduce l dimensione massima del segmento (maximum segment size, MSS) della connessione TCP a causa del sovraccarico di integrazione.
Per configurare Load Balancer da inoltrare con l'incapsulamento GRE, aggiungere i server mediante il seguente comando:
dscontrol server add cluster_add:port:backend_server router backend_server
Dove router server_backend è valido se Load Balancer e il server di backend sono sulla stessa sottorete IP. In caso contrario, specificare l'indirizzo IP dell'hop successivo valido come router.
Per configurare i sistemi Linux in modo da eseguire l'integrazione GRE nativa, per ogni server di backend, emettere i seguenti comandi:
modprobe ip_gre ip tunnel add grelb0 mode gre ikey 3735928559 ip link set grelb0 up ip addr add cluster_addr dev grelb0
Quando si esegue Load Balancer configurato con le funzioni del gestore e dell'advisor, si può verificare una perdita di memoria su alcune versioni Red Hat Linux. La mancanza di memoria Java aumenta se si configura un'impostazione time-interval troppo piccola per l'advisor.
Le versioni di IBM Java SDK della JVM e Native POSIX Thread Library (NPTL) rilasciato con alcune distribuzioni Linux, come Red Hat Enterprise Linux 3.0, possono causare questa mancanza di memoria. La libreria di thread avanzati NPTL rilasciata con alcune distribuzioni di sistemi Linux come Red Hat Enterprise Linux 3.0 supporta NPTL.
Fare riferimento a http://www.ibm.com/developerworks/java/jdk/linux/tested.html per le informazioni più recenti sui sistemi Linux e su IBM Java SDK rilasciato con tali sistemi.
Come uno strumeno per la determinazione dei problemi, utilizzare il comando vmstat o ps per rilevare perdite di memoria.
Per correggere la perdita di memoria, inviare il seguente comando prima di eseguire la macchina Load Balancer per disabilitare la libreria NPTL:
export LD_ASSUME_KERNEL=2.4.10
Su SUSE Linux Enterprise Server 9, quando si utilizza il metodo di inoltro MAC, il report del Dispatcher indica che il pacchetto è stato inoltrato (il numero di pacchetti aumenta) ma il pacchetto non raggiunge il server di backend.
Immettere uno o tutti i comandi riportati di seguito:
ip_finish_output2: Nessuna cache intestazione e nessun router adiacente!
Destinazione ICMP non raggiungibile: Metodo di deframmentazione
Questo problema potrebbe verificarsi a causa del modulo NAT iptables caricato. Su SLES 9, esiste un possibile errore (mai confermato) in questa versione di iptables che provoca un funzionamento anomalo quando si utilizza Dispatcher.
Soluzione:
Caricare il modulo NAT iptables e il modulo di traccia delle connessioni.
Ad esempio:
# lsmod | grep ip iptable_filter 3072 0 iptable_nat 22060 0 ip_conntrack 32560 1 iptable_nat ip_tables 17280 2 iptable_filter,iptable_nat ipv6 236800 19 # rmmod iptable_nat # rmmod ip_conntrack
Rimuovere i moduli nel proprio ordine di utilizzo. In particolare, è possibile rimuovere un modulo solo se il numero di riferimenti (l'ultima colonna nell'output lsmod) è zero. Se sono state configurate delle regole in iptables, è necessario rimuoverle. Ad esempio: iptables -t nat -F.
Il modulo iptable_nat utilizza ip_conntrack, pertanto è necessario prima rimuovere il modulo iptable_nat module, quindi ip_conntrack module.
Sui sistemi Windows, se si esegue la funzione HA di Load Balancer, gli script goScripts vengono utilizzati per configurare l'indirizzo IP del cluster sul Load Balancer attivo e per annullare la configurazione dell'IP del cluster sul sistema di backup quando viene eseguito un takeover. Se lo script goScript che configura l'indirizzo IP del cluster sulla macchina attiva viene eseguito prima dello script goScript per annullare la configurazione dell'indirizzo IP del cluster sulla macchina di backup, è possibile che si verifichino dei problemi. Viene visualizzata una finestra a comparsa che indica che il sistema ha rilevato un conflitto di indirizzi IP. Se si esegue il comando ipconfig \all è possibile che sulla macchina venga visualizzato l'indirizzo IP 0.0.0.0.
Soluzione:
emettere il seguente comando per annullare manualmente la configurazione dell'indirizzo IP del cluster dalla macchina principale:
dscontrol executor unconfigure clusterIP
Tale comando rimuove l'indirizzo 0.0.0.0 dallo stack IP Windows.
Dopo che il partner HA rilascia l'indirizzo IP del cluster, emettere il seguente comando per aggiungere manualmente di nuovo l'IP del cluster:
dscontrol executor configure clusterIP
Dopo aver emesso questo comando, cercare l'indirizzo IP del cluster sullo stack di Windows IP di nuovo, emettendo il seguente comando:
ipconfig /all
Linux iptables può interferire con il bilanciamento del carico del traffico e deve essere disabilitato sulla macchina Dispatcher.
Emettere il seguente comando per stablire se iptable è caricato:
lsmod | grep ip_tables
L'output del comando precedente potrebbe essere simile al seguente:
ip_tables 22400 3 iptable_mangle,iptable_nat,iptable_filter
Emettere il seguente comando per ogni iptable elencato nell'output per visualizzare le regole per le tabelle:
iptables -t <short_name> -L
Ad esempio:
iptables -t mangle -L iptables -t nat -L iptables -t filter -L
Se iptable_nat è caricato, il caricamento deve essere annullato. Poiché iptable_nat ha una dipendenza su iptable_conntrack, è necessario anche rimuovere iptable_conntrack. Emettere il seguente comando per annullare il carico di questi due iptable:
rmmod iptable_nat iptable_conntrack
Load Balancer fornisce una serie di file Java insieme all'installazione del prodotto. L'installazione del prodotto è costituita da diversi pacchetti che non devono essere installati sulla stessa macchina. Tra questi pacchetti vi sono il package Metric Server, il package di gestione e il package di base. Tutti questi pacchetti di codice richiedono una serie di file Java funzionante ma ognuno di questi tre pacchetti può essere installato su una macchina separata. Pertanto, ognuno di questi pacchetti installa una serie di file Java. Se installata sulla stessa macchina, la serie di file Java sarà di proprietà di ognuna di queste serie di file. Quando si installa la seconda e la terza serie di file Java, verrà visualizzato un messaggio di avvertenza che indica che la serie di file Java è di proprietà di un'altra serie di file.
Quando si installa il codice mediante i metodi di installazione nativi (ad esempio, installp su AIX), è necessario ignorare i messaggi di avvertenza.
Durante il processo di installazione di Load Balancer, viene installata una serie di file Java. Load Balancer sarà l'unica applicazione che utilizza la versione Java che installa il prodotto. Non è necessario aggiornare questa versione della serie di file Java. Se si verifica un problema che richiede un aggiornamento della serie di file Java, è necessario riportare il problema all'assistenza IBM in modo da poter ricevere un aggiornamento alla serie di file Java fornita con l'installazione di Load Balancer.
Sui sistemi operativi Microsoft Windows, le connessioni persistenti potrebbero essere rilasciate durante un takeover HA. Questo problema esiste solo quando si dispone di un server posizionato che utilizza il metodo di inoltro MAC.
Quando l'indirizzo IP del cluster viene eliminato, dalla interfaccia ethernet o dall'interfaccia loopback, le connessioni su quell'indirizzo IP vengono rilasciate. Quando il sistema operativo riceve un pacchetto su una connessione rilasciata, invia una risposta RST al client e la connessione viene terminata.
Se non è possibile tollerare le connessioni rilasciate durante un takeover HA, non utilizzare un server posizionato su sistemi operativi Windows, quando si utilizza il metodo di inoltro MAC.
Questo problema è causato dalla limitazione di Edge Installer su sistemi Linux zSeries a 32 bit.
È possibile risolvere questo problema eseguendo una installazione manuale per i sistemi Linux zSeries a 32 bit. Per ulteriori informazioni, vedere Installazione per sistemi Linux.
Questo problema è il risultato di una limitazione in Edge Installer su sistemi Linux.
Per disinstallare WebSphere Edge Server su un sistema Linux, disinstallare manualmente il prodotto. Per disinstallare completamente il prodotto, immettere il comando rpm -e 'rpm -qa | grep ibmlb'.
Per disinstallare un singolo package, immettere il comando rpm -e <package name>. I nomi del package possono essere trovati nella sezione Installazione per sistemi Linux; si ricordi di disinstallare i pacchetti nell'ordine inverso in cui sono stati installati.
Questo problema può verificarsi quando un'altra applicazione utilizza una delle porte utilizzate da CBR. Per ulteriori informazioni, vedere Controllo dei numeri di porta di CBR.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Questo può causare problemi quando una delle console di gestione viene eseguita sulla stessa macchina di un firewall, oppure attraverso un firewall. Ad esempio, quando Load Balancer viene eseguito sulla stessa macchina di un firewall, e si emettono comandi di cbrcontrol, potrebbero comparire errori quale Errore: il server non risponde.
Per evitare questo problema, modificare il file script di cbrserver per impostare la porta utilizzata da RMI per il firewall (o altra applicazione). Modificare la riga: LB_RMISERVERPORT=11199 in LB_RMISERVERPORT=propriaPorta. Dove propriaPorta è una porta diversa.
Al termine dell'operazione, riavviare cbrserver e aprire il traffico per le porte 11099, 10004, 11199 e 11100, oppure per la porta prescelta per l'indirizzo host da cui verrà eseguita la console di gestione.
Caching Proxy e CBR sono stati avviati, ma le richieste non vengono sottoposte a bilanciamento del carico. Questo errore può verificarsi se si avvia Caching Proxy prima dell'executor. In tal caso, il log stderr di Caching Proxy conterrà il seguente messaggio di errore: "ndServerInit: impossibile stabilire collegamento all'executor." Per evitare questo problema, avviare l'executor prima di Caching Proxy.
Su Solaris, il comando cbrcontrol executor start restituisce: "Errore: executor non avviato." Questo errore si verifica se non si configura IPC (Inter-process Communication) per il sistema in modo che la dimensione massima di un segmento di memoria condivisa e gli ID semaforo sono più grandi del valore predefinito del sistema operativo. Per aumentare la dimensione del segmento di memoria condivisa e gli ID semaforo, è necessario modificare il file /etc/system. Per ulteriori informazioni su come configurare questo file, vedere la pagina ***.
Il mancato funzionamento della regola URL può dipendere da un errore di sintassi o di configurazione. Per risolvere il problema, controllare quanto segue:
Sulla piattaforma Windows, quando si utilizza una scheda Matrox AGP, potrebbero verificarsi comportamenti imprevisti della GUI di Load Balancer. Quando si fa clic con il mouse, un blocco leggermente più grande del puntatore può corrompersi, provocando un'evidenziazione inversa o lo spostamento delle immagini sullo schermo. Questo comportamento è stato riscontrato nelle schede Matrox meno recenti. Non è disponibile una correzione nota in caso di utilizzo di schede Matrox AGP.
Se si sta utilizzando la gestione Web remota, per configurare Load Balancer, non ridimensionare la finestra del browser Netscape (riduzione, ingrandimento, ripristino in basso e così via) in cui viene visualizzata la GUI di Load Balancer. Poiché Netscape ricarica una pagina ogni volta che le finestre del browser vengono ridimensionate, questo provoca la disconnessione dall'host. Sarà necessario riconnettersi all'host ogni volta che si ridimensiona una finestra. Se si esegue l'amministrazione Web da remoto su una piattaforma Windows, utilizzare Internet Explorer.
In una finestra del prompt dei comandi sul sistema operativo Windows, alcuni caratteri nazionali della famiglia Latin-1 potrebbero risultare corrotti. Ad esempio, la lettera "a" con la tilde potrebbe essere visualizzata come un simbolo di pi greco. Per risolvere questo problema, è necessario modificare le proprietà dei font della finestra del prompt dei comandi. Per modificare il font, procedere come indicato di seguito:
Alcune installazioni di HP-UX 11i sono preconfigurate per consentire solo 64 thread per processo. Tuttavia, alcune configurazioni di Load Balancer richiedono una quantità superiore. Per i sistemi HP-UX, impostare i thread per processo almeno su 256. Per aumentare il valore, servirsi dell'utilità "sam" per impostare il parametro del kernel max_thread_proc. Se si prevede un utilizzo intensivo, potrebbe essere necessario aumentare max_thread_proc oltre 256.
Per aumentare il valore di max_thread_proc, procedere come indicato in ***.
Durante la configurazione della scheda su una macchina Load Balancer, è necessario accertarsi che le due impostazioni seguenti siano corrette, per consentire il funzionamento dell'advisor:
Per istruzioni sulla configurazione di questa impostazione, fare riferimento a ***.
Sulla piattaforma Windows, quando si configura una scheda perché abbia più indirizzi IP, configurare l'indirizzo IP che si desidera associare al nome host come primo nel registro.
Poiché Load Balancer dipende da InetAddress.getLocalHost() in molti casi (ad esempio, per lbkeys create), più indirizzi IP con alias su una singola scheda possono causare problemi. Per evitare questo problema, collocare per primo nell'elenco del registro l'indirizzo IP sul quale si desidera venga risolto il nome host.
Per le fasi di configurazione del nome host come primo nel registro, fare riferimento a pagina ***.
Questo problema può verificarsi quando un'altra applicazione utilizza una delle porte utilizzate da Site Selector. Per ulteriori informazioni, vedere Controllo dei numeri di porta di Site Selector.
Sintomo: Site Selector non esegue il round-robin delle richieste in entrata da client Solaris.
Causa possibile: i sistemi Solaris eseguono un daemon cache del servizio nomi. Se questo daemon è in esecuzione, alla richiesta seguente di resolver verrà fornita risposta da questa cache anziché da un'interrogazione di Site Selector.
Soluzione: disattivare il daemon cache del servizio nomi sulla macchina Solaris.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Questo può causare problemi quando una delle console di gestione viene eseguita sulla stessa macchina di un firewall, oppure attraverso un firewall. Ad esempio, quando Load Balancer viene eseguito sulla stessa macchina di un firewall, e si emettono comandi di sscontrol, potrebbero comparire errori quale Errore: il server non risponde.
Per evitare questo problema, modificare il file script di ssserver per impostare la porta utilizzata da RMI per il firewall (o altra applicazione). Modificare la riga: LB_RMISERVERPORT=10199 in LB_RMISERVERPORT=propriaPorta. Dove propriaPorta è una porta diversa.
Al termine dell'operazione, riavviare ssserver e aprire il traffico per le porte 12099, 10004, 12199 e 12100, oppure per la porta prescelta per l'indirizzo host da cui verrà eseguita la console di gestione.
Site Selector deve poter partecipare a un DNS. Tutte le macchine coinvolte nella configurazione dovrebbero partecipare anch'esse al sistema. I sistemi Windows non richiedono che il nome host sia nel DNS. Per avviarsi correttamente, Site Selector richiede che il proprio nome host sia definito nel DNS.
Verificare che questo host sia definito nel DNS. Modificare il file ssserver.cmd ed eliminare "w" da "javaw". Questo dovrebbe fornire ulteriori informazioni sugli errori.
Il server dei nomi di Site Selector non si associa ad alcun indirizzo sulla macchina. Risponderà alle richieste destinate a qualsiasi IP valido sulla macchina. Site Selector si affida al sistema operativo per inoltrare le risposte al client. Se la macchina Site Selector dispone di più schede e qualsiasi numero di queste è collegato alla stessa sottorete, il sistema operativo potrebbe inviare la risposta al client da un indirizzo diverso rispetto a quello sui è stata ricevuta la richiesta. Alcune applicazioni client non accettano una risposta da un indirizzo diverso da quello a cui è stata inviata la richiesta. Di conseguenza, la risoluzione nome sembra non riuscire.
Sulla piattaforma Windows, quando si utilizza una scheda Matrox AGP, potrebbero verificarsi comportamenti imprevisti della GUI di Load Balancer. Quando si fa clic con il mouse, un blocco leggermente più grande del puntatore può corrompersi, provocando un'evidenziazione inversa o lo spostamento delle immagini sullo schermo. Questo comportamento è stato riscontrato nelle schede Matrox meno recenti. Non è disponibile una correzione nota in caso di utilizzo di schede Matrox AGP.
Se si sta utilizzando la gestione Web remota, per configurare Load Balancer, non ridimensionare la finestra del browser Netscape (riduzione, ingrandimento, ripristino in basso e così via) in cui viene visualizzata la GUI di Load Balancer. Poiché Netscape ricarica una pagina ogni volta che le finestre del browser vengono ridimensionate, questo provoca la disconnessione dall'host. Sarà necessario riconnettersi all'host ogni volta che si ridimensiona una finestra. Se si esegue l'amministrazione Web da remoto su una piattaforma Windows, utilizzare Internet Explorer.
In una finestra del prompt dei comandi sul sistema operativo Windows, alcuni caratteri nazionali della famiglia Latin-1 potrebbero risultare corrotti. Ad esempio, la lettera "a" con la tilde potrebbe essere visualizzata come un simbolo di pi greco. Per risolvere questo problema, è necessario modificare le proprietà dei font della finestra del prompt dei comandi. Per modificare il font, procedere come indicato di seguito:
Alcune installazioni di HP-UX 11i sono preconfigurate per consentire solo 64 thread per processo. Tuttavia, alcune configurazioni di Load Balancer richiedono una quantità superiore. Per i sistemi HP-UX, impostare i thread per processo almeno su 256. Per aumentare il valore, servirsi dell'utilità "sam" per impostare il parametro del kernel max_thread_proc. Se si prevede un utilizzo intensivo, potrebbe essere necessario aumentare max_thread_proc oltre 256.
Per aumentare il valore di max_thread_proc, procedere come indicato in ***.
Durante la configurazione della scheda su una macchina Load Balancer, è necessario accertarsi che le due impostazioni seguenti siano corrette, per consentire il funzionamento dell'advisor:
Per istruzioni sulla configurazione di questa impostazione, fare riferimento a ***.
Questo problema può verificarsi quando un'altra applicazione utilizza una delle porte utilizzate da ccoserver di Cisco CSS Controller. Per ulteriori informazioni, vedere Controllo dei numeri di porta di Cisco CSS Controller.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Questo può causare problemi quando una delle console di gestione viene eseguita sulla stessa macchina di un firewall, oppure attraverso un firewall. Ad esempio, quando Load Balancer viene eseguito sulla stessa macchina di un firewall, e si emettono comandi di ccocontrol, potrebbero comparire errori quale Errore: il server non risponde.
Per evitare questo problema, modificare il file script di ccoserver per impostare la porta utilizzata da RMI per il firewall (o altra applicazione). Modificare la riga: CCO_RMISERVERPORT=14199 in CCO_RMISERVERPORT=propriaPorta. Dove propriaPorta è una porta diversa.
Al termine dell'operazione, riavviare ccoserver e aprire il traffico per le porte 13099, 10004, 13199 e 13100, oppure per la porta prescelta per l'indirizzo host da cui verrà eseguita la console di gestione.
Questo problema può verificarsi quando manca una licenza del prodotto valida. Quando si tenta di avviare ccoserver, si riceve il seguente messaggio:
La licenza è scaduta. Contattare il rappresentante o il distributore autorizzato IBM locale.
Per correggere questo problema:
Sulla piattaforma Windows, quando si utilizza una scheda Matrox AGP, potrebbero verificarsi comportamenti imprevisti della GUI di Load Balancer. Quando si fa clic con il mouse, un blocco leggermente più grande del puntatore può corrompersi, provocando un'evidenziazione inversa o lo spostamento delle immagini sullo schermo. Questo comportamento è stato riscontrato nelle schede Matrox meno recenti. Non è disponibile una correzione nota in caso di utilizzo di schede Matrox AGP.
Durante l'aggiunta di un consultant, potrebbe verificarsi un errore di connessione, dovuto a una configurazione errata. Per correggere questo problema:
Per correggere questo problema
Aumentare il livello di log di consultant e riprovare il comando. Se fallisce nuovamente, ricercare SNMP timeout o altri errori di comunicazione SNMP nel log.
Se si sta utilizzando la gestione Web remota, per configurare Load Balancer, non ridimensionare la finestra del browser Netscape (riduzione, ingrandimento, ripristino in basso e così via) in cui viene visualizzata la GUI di Load Balancer. Poiché Netscape ricarica una pagina ogni volta che le finestre del browser vengono ridimensionate, questo provoca la disconnessione dall'host. Sarà necessario riconnettersi all'host ogni volta che si ridimensiona una finestra. Se si esegue l'amministrazione Web da remoto su una piattaforma Windows, utilizzare Internet Explorer.
In una finestra del prompt dei comandi sul sistema operativo Windows, alcuni caratteri nazionali della famiglia Latin-1 potrebbero risultare corrotti. Ad esempio, la lettera "a" con la tilde potrebbe essere visualizzata come un simbolo di pi greco. Per risolvere questo problema, è necessario modificare le proprietà dei font della finestra del prompt dei comandi. Per modificare il font, procedere come indicato di seguito:
Alcune installazioni di HP-UX 11i sono preconfigurate per consentire solo 64 thread per processo. Tuttavia, alcune configurazioni di Load Balancer richiedono una quantità superiore. Per i sistemi HP-UX, impostare i thread per processo almeno su 256. Per aumentare il valore, servirsi dell'utilità "sam" per impostare il parametro del kernel max_thread_proc. Se si prevede un utilizzo intensivo, potrebbe essere necessario aumentare max_thread_proc oltre 256.
Per aumentare il valore di max_thread_proc, procedere come indicato in ***.
Questo problema può verificarsi quando un'altra applicazione utilizza una delle porte utilizzate da ccoserver di Nortel Alteon Controller. Per ulteriori informazioni, vedere Controllo dei numeri di porta di Nortel Alteon Controller.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Questo può causare problemi quando una delle console di gestione viene eseguita sulla stessa macchina di un firewall, oppure attraverso un firewall. Ad esempio, quando Load Balancer viene eseguito sulla stessa macchina di un firewall, e si emettono comandi di nalcontrol, potrebbero comparire errori quale Errore: il server non risponde.
Per evitare questo problema, modificare il file script di nalserver per impostare la porta utilizzata da RMI per il firewall (o altra applicazione). Modificare la riga: NAL_RMISERVERPORT=14199 in NAL_RMISERVERPORT=propriaPorta. Dove propriaPorta è una porta diversa.
Al termine dell'operazione, riavviare nalserver e aprire il traffico per le porte 14099, 10004, 14199 e 14100, oppure per la porta prescelta per l'indirizzo host da cui verrà eseguita la console di gestione.
Questo problema può verificarsi quando manca una licenza del prodotto valida. Quando si tenta di avviare nalserver, si riceve il seguente messaggio:
La licenza è scaduta. Contattare il rappresentante o il distributore autorizzato IBM locale.
Per correggere questo problema:
Sulla piattaforma Windows, quando si utilizza una scheda Matrox AGP, potrebbero verificarsi comportamenti imprevisti della GUI di Load Balancer. Quando si fa clic con il mouse, un blocco leggermente più grande del puntatore può corrompersi, provocando un'evidenziazione inversa o lo spostamento delle immagini sullo schermo. Questo comportamento è stato riscontrato nelle schede Matrox meno recenti. Non è disponibile una correzione nota in caso di utilizzo di schede Matrox AGP.
Se si sta utilizzando la gestione Web remota, per configurare Load Balancer, non ridimensionare la finestra del browser Netscape (riduzione, ingrandimento, ripristino in basso e così via) in cui viene visualizzata la GUI di Load Balancer. Poiché Netscape ricarica una pagina ogni volta che le finestre del browser vengono ridimensionate, questo provoca la disconnessione dall'host. Sarà necessario riconnettersi all'host ogni volta che si ridimensiona una finestra. Se si esegue l'amministrazione Web da remoto su una piattaforma Windows, utilizzare Internet Explorer.
Durante l'aggiunta di un consultant, potrebbe verificarsi un errore di connessione, dovuto a una configurazione errata. Per correggere questo problema:
Per correggere questo problema
Aumentare il livello di log di consultant e riprovare il comando. Se fallisce nuovamente, ricercare SNMP timeout o altri errori di comunicazione SNMP nel log.
In una finestra del prompt dei comandi sul sistema operativo Windows, alcuni caratteri nazionali della famiglia Latin-1 potrebbero risultare corrotti. Ad esempio, la lettera "a" con la tilde potrebbe essere visualizzata come un simbolo di pi greco. Per risolvere questo problema, è necessario modificare le proprietà dei font della finestra del prompt dei comandi. Per modificare il font, procedere come indicato di seguito:
Alcune installazioni di HP-UX 11i sono preconfigurate per consentire solo 64 thread per processo. Tuttavia, alcune configurazioni di Load Balancer richiedono una quantità superiore. Per i sistemi HP-UX, impostare i thread per processo almeno su 256. Per aumentare il valore, servirsi dell'utilità "sam" per impostare il parametro del kernel max_thread_proc. Se si prevede un utilizzo intensivo, potrebbe essere necessario aumentare max_thread_proc oltre 256.
Per aumentare il valore di max_thread_proc, procedere come indicato in ***.
È necessario utilizzare il nome metrica completo per le metriche scritte dall'utente su Metric Server in esecuzione sulla piattaforma Windows. Ad esempio, è necessario specificare usermetric.bat anziché usermetric. Il nome usermetric è valido sulla riga comandi, ma non funziona quando viene eseguito nell'ambiente di runtime. Se non si utilizza il nome metrica completo, verrà generata una IOException di Metric Server. Impostare la variabile LOG_LEVEL a un valore 3 nel file dei comandi metricserver, quindi controllare l'output del log. In questo esempio, l'eccezione appare come:
... java.io.IOException: CreateProcess: usermetric error=2
Le ragioni per cui Metric Server non notifica le informazioni sui carichi a Load Balancer possono essere diverse. Per individuare la causa, eseguire questi controlli:
È inoltre possibile risolvere questo problema specificando il nome host nella proprietà Java java.rmi.server.hostname nello script metricserver.
Questo messaggio di errore compare nel log di Metric Server dopo che i file di chiavi sono stati trasferiti al server.
Questo errore viene registrato quando il file di chiavi non supera l'autorizzazione con la coppia di chiavi a causa di una corruzione nella coppia. Per correggere questo problema, provare quanto segue:
Quando si esegue Metric Server sotto carichi elevati in un sistema multiprocessore con piattaforma AIX (4.3.3, 5.1 a 32 bit o 5.1 a 64 bit), l'output del comando ps -vg potrebbe risultare corrotto. Ad esempio:
55742 - A 88:19 42 18014398509449680 6396 32768 22 36 2.8 1.0 java -Xms
I campi SIZE e/o RSS del comando ps potrebbero indicare un uso eccessivo della memoria.
Si tratta di un problema noto del kernel AIX. L'APAR IY33804 correggerà questo problema. Ottenere la correzione dall'assistenza AIX all'indirizzo http://techsupport.services.ibm.com/server/fixes, oppure contattare il rappresentante dell'assistenza AIX locale.
In una configurazione Load Balancer a due livelli, se Site Selector (primo livello) esegue il bilanciamento del carico tra una coppia di partner Dispatcher a disponibilità elevata (secondo livello), è necessario completare alcuni passaggi per configurare il componente Metric Server. Metric Server deve essere configurato per rimanere in ascolto su un nuovo indirizzo IP, ad esso specificamente destinato. Sulle due macchine Dispatcher a disponibilità elevata, Metric Server è attivo solo sul Dispatcher attivo.
Per configurare correttamente questa impostazione, completare le seguenti operazioni:
Ad esempio:
ifconfig en0 delete 9.27.23.61 ifconfig lo0 alias 9.27.23.61 netmask 255.255.255.0 route add 9.27.23.61 127.0.0.1 metricserver stop # inattività massima di 60 secondi o fino all'arresto di metricserver let loopcount=0 while [[ "$loopcount" -lt "60" && 'ps -ef | grep AgentStop| grep -c -v gr ep' -eq "1"]] do sleep 1 let loopcount=$loopcount+1 done route delete 9.27.23.61
Ad esempio:
call netsh interface ip delete address "Connessione alla rete locale" addr=9.27.23.61 call netsh interface ip add address "Connessione alla rete locale 2" addr=9.27.2.3.61 mask = 255.255.255.0 sleep 3 metricserver stop
Quando vengono eseguiti su macchine Solaris multi-CPU, gli script metricserver, cpuload e memload possono produrre messaggi console indesiderati. Questo comportamento è dovuto all'uso del comando di sistema VMSTAT per raccogliere le statistiche su CPU e memoria dal kernel. Alcuni messaggi restituiti da VMSTAT indicano che lo stato del kernel è cambiato. Gli script non sono in grado di gestire questi messaggi, per cui vengono visualizzati messaggi console non necessari dalla shell.
Esempi di questi messaggi console sono:
/opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=: syntax error /opt/ibm/edge/lb/ms/script/memload[31]: LOAD=4*100/0: divide by zero /opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=659664+: more tokens expected
Questi messaggi possono essere ignorati.
Questo problema può essere il risultato della perdita di integrità dei file delle chiavi durante il trasferimento al client.
Se si utilizza FTP per trasferire i file delle chiavi dalla macchina di Load Balancer al server di backend verificare di utilizzare la modalità binaria per eseguire il put o il get dei file delle chiavi sul server FTP.
Questa sezione fornisce informazioni di riferimento sui comandi di tutti i componenti di Load Balancer. Contiene i seguenti capitoli:
Il diagramma delle sintassi mostra come specificare un comando in modo che il sistema interpreti correttamente ciò che è stato digitato. Leggere il diagramma delle sintassi da sinistra verso destra e dall'alto verso il basso, seguendo la riga orizzontale (il percorso principale).
Nei diagrammi della sintassi vengono utilizzati i seguenti simboli:
Inserire tutta la punteggiatura, ad esempio, due punti, virgolette e segni di sottrazione, come mostrato nel diagramma della sintassi.
Nei diagrammi della sintassi vengono utilizzati i seguenti parametri
I parametri sono classificati come parole chiave o variabili. Le parole chiave sono visualizzate in minuscolo e quindi possono essere inserite in minuscolo. Ad esempio, un nome di un comando è una parola chiave. Le variabili sono in corsivo e rappresentano i nomi o i valori forniti.
Nell'esempio riportato di seguito, il comando user è una parola chiave. La variabile obbligatoria è id_utente e la variabile facoltativa è password. Sostituire le variabili con i propri valori.
>>-user--id_utente--+----------+--------------------------------->< '-password-'
Parole chiave obbligatorie: le parole chiave e le variabili obbligatorie vengono visualizzate nella riga del percorso principale.
>>-required_keyword--------------------------------------------><
È necessario codificare le parole chiave e i valori obbligatori.
Scegliere una delle voci obbligatorie da uno stack: se è disponibile più di una parola chiave o variabile obbligatoria la cui presenza esclude la presenza di un'altra, queste vengono raggruppate in verticale nell'ordine alfanumerico.
>>-+-required_parameter_1-+------------------------------------>< '-required_parameter_2-'
Valori facoltativi: le parole chiave e le variabili facoltative vengono visualizzate sotto la riga del percorso principale.
>>-+---------+------------------------------------------------->< '-keyword-'
È possibile scegliere di non codificare le parole chiave e le variabili facoltative.
Scegliere una parola chiave facoltativa da uno stack: se è disponibile più di una parola chiave o variabile facoltativa la cui presenza esclude la presenza di un'altra, queste vengono raggruppate in verticale in ordine alfanumerico sotto la riga del percorso principale.
>>-+-------------+--------------------------------------------->< +-parameter_1-+ '-parameter_2-'
Variabili: una parola interamente in corsivo è una variabile . Quando è presente una variabile nella sintassi, sostituirla con uno dei nomi o dei valori possibili, come indicato nel testo.
>>-variable----------------------------------------------------><
Caratteri non alfanumerici: se un diagramma mostra un carattere non alfanumerico (punti, virgolette o segni di sottrazione) è necessario codificare il carattere come parte della sintassi. In questo esempio, codificare cluster:port.
>>-cluster:porta------------------------------------------------><
Questo capitolo descrive come utilizzare i comandi dscontrol di Dispatcher. oltre a essere un riferimento ai comandi di CBR.
Per le versioni precedenti, quando il prodotto era noto come Network Dispatcher, il nome del comando per il controllo del Dispatcher era ndcontrol. Il nome del comando per il controllo del Dispatcher è ora dscontrol. Accertarsi di aver aggiornato tutti i file script precedenti in modo da utilizzare dscontrol (e non ndcontrol) per configurare il Dispatcher.
CBR utilizza una serie secondaria dei comandi Dispatcher, elencata in questo riferimento sui comandi. Quando si utilizzano questi diagrammi della sintassi per CBR, specificare cbrcontrol al posto di dscontrol. Per informazioni, vedere Differenze di configurazione tra CBR e Dispatcher.
L'elenco riportato di seguito contiene i comandi descritti in questo capitolo:
È possibile immettere una versione ridotta dei parametri del comando dscontrol. È sufficiente inserire le lettere che designano in modo univoco i parametri. Ad esempio, per visualizzare la guida del comando di salvataggio file, è possibile immettere dscontrol he f anziché dscontrol help file.
Per attivare l'interfaccia della riga comandi: emettere dscontrol per ricevere un prompt dei comandi dscontrol.
Per chiudere l'interfaccia della riga comandi: emettere exit o quit.
i valori dei parametri dei comandi devono essere immessi utilizzando l'alfabeto inglese. Le uniche eccezioni sono i nomi host (utilizzati in cluster, server e comandi highavailability) e i nomi file (utilizzati in comandi file).
L'interfaccia della riga comandi CBR è una serie secondaria dell'interfaccia della riga comandi del Dispatcher. Per CBR, specificare il comando cbrcontrol al posto del comando dscontrol per configurare il componente.
Alcuni comandi omessi in CBR sono elencati di seguito.
>>-dscontrol--advisor--+-connecttimeout--nome--+-port---------+--timeoutseconds-+->< | '-cluster:port-' | +-interval--nome--+-port---------+--seconds--------------+ | '-cluster:port-' | +-list---------------------------------------------------+ +-loglevel--nome--+-port---------+--level----------------+ | '-cluster:port-' | +-logsize--nome--+-port---------+--+-unlimited---------+-+ | '-cluster:port-' '-numbero di record-' | +-receivetimeout--nome--+-porta---------+--timeoutseconds-+ | '-cluster:port-' | +-report--nome--+-porta---------+-------------------------+ | '-cluster:port-' | +-retries--nome--+-porta---------+--numretries------------+ | '-cluster:port-' | +-start--nome--+-porta---------+--+----------+------------+ | '-cluster:port-' '-file log-' | +-status--nome--+-porta---------+-------------------------+ | '-cluster:port-' | +-stop--nome--+-porta---------+---------------------------+ | '-cluster:porta-' | +-timeout--nome--+-porta---------+--+-unlimited-+---------+ | '-cluster:port-' '-secondi---' | '-version--nome--+-porta---------+------------------------' '-cluster:port-'
Per ulteriori informazioni sugli advisor forniti da Load Balancer, vedere Elenco di advisor.
I nomi degli advisor personalizzati sono nel formato xxxx, dove per ADV_xxxx si intende il nome della classe che implementa l'advisor personalizzato. Per ulteriori informazioni, vedere Creazione di advisor personalizzati (personalizzabili).
Il cluster è il nome simbolico o l'indirizzo sotto forma di indirizzo IP. La porta è il numero della porta monitorata dall'advisor.
Nome advisor | Protocollo | Port |
---|---|---|
cachingproxy | HTTP (via Caching Proxy) | 80 |
connessione | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
self | private | 12345 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
ssl2http | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10,007 |
Il file predefinito è porta_nomeadvisor .log, ad esempio, http_80.log. Per modificare la directory su cui vengono memorizzati i file di log, vedere Modifica dei percorsi file di log. I file di log predefiniti per advisor specifici del cluster (o del sito) vengono creati con l'indirizzo cluster, ad esempio, http_127.40.50.1_80.log.
Esempi
dscontrol advisor start http 127.40.50.1:80
dscontrol advisor start http 88
dscontrol advisor stop http 127.40.50.1:80
dscontrol advisor connecttimeout http 80 30
dscontrol advisor connecttimeout http 127.40.50.1:80 20
dscontrol advisor interval ftp 21 6
dscontrol advisor listQuesto comando produce un output simile a:
--------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | --------------------------------------- | http |127.40.50.1:80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
dscontrol advisor loglevel http 80 0
dscontrol advisor logsize ftp 21 5000
dscontrol advisor receivetimeout http 80 60
dscontrol advisor report ftp 21Questo comando produce un output simile a:
Advisor Report: --------------- Advisor name ............. Ftp Port number .............. 21 Cluster address .......... 9.67.131.18 Server address ........... 9.67.129.230 Load ..................... 8 Cluster address .......... 9.67.131.18 Server address ........... 9.67.131.215 Load ..................... -1
dscontrol advisor status http 80Questo comando produce un output simile al seguente:
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited Number of retries ............. 0
dscontrol advisor timeout ftp 21 5
dscontrol advisor version ssl 443Questo comando produce un output simile al seguente:
Version: 04.00.00.00 - 07/12/2001-10:09:56-EDT
>>-dscontrol--binlog--+-start----------------------+----------->< +-stop-----------------------+ +-set--+-retention--time--+-+ | '-interval--seconds-' | '-status---------------------'
>>-dscontrol--cluster--+-add--cluster+c2+...--+----------------------------------------+-+->< | +-address--address-----------------------+ | | +-proportions--active--new--port--system-+ | | +-maxports--size-------------------------+ | | +-maxservers--size-----------------------+ | | +-stickytime--time-----------------------+ | | +-weightbound--weight--------------------+ | | +-porttype--type-------------------------+ | | +-primaryhost--address-------------------+ | | +-staletimeout--staletimeout-------------+ | | '-sharedbandwidth--size------------------' | +-set--cluster+c2+...--+-proportions--active--new--port--system-+-+ | +-maxports--size-------------------------+ | | +-maxservers--size-----------------------+ | | +-stickytime--time-----------------------+ | | +-weightbound--weight--------------------+ | | +-porttype--type-------------------------+ | | +-primaryhost--address-------------------+ | | +-staletimeout--staletimeout-------------+ | | '-sharedbandwidth--size------------------' | +-remove--cluster-------------------------------------------------+ +-report--cluster-------------------------------------------------+ '-status--cluster-------------------------------------------------'
Ad eccezione del comando dscontrol cluster add, è possibile utilizzare un carattere due punti (:) in modo che funzioni da carattere jolly. Ad esempio, il seguente comando, dscontrol cluster set : weightbound 80, consente di impostare un limite di peso di 80 su tutti i cluster.
Se si modifica il valore primaryhost di un cluster dopo aver avviato la macchina principale e le macchine di backup, in esecuzione con disponibilità elevata reciproca, è necessario anche forzare il nuovo host principale ad assumere il comando. Inoltre, è necessario aggiornare gli script, quindi deconfigurare e configurare manualmente il cluster in modo corretto. Per ulteriori informazioni, vedere Disponibilità elevata reciproca.
Esempi
dscontrol cluster add 130.40.52.153
dscontrol cluster remove 130.40.52.153
dscontrol cluster set 9.6.54.12 proportions 60 35 5 0
dscontrol cluster add 0.0.0.0
dscontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
dscontrol cluster status 9.67.131.167Questo comando produce un output simile a:
Cluster Status: ---------------- Cluster ................................. 9.67.131.167 Address ................................. 9.67.131.167 Number of target ports .................. 3 Default sticky time ..................... 0 Default stale timeout ................... 30 Default port weight bound ............... 20 Maximum number of ports ................. 8 Default port protocol ................... tcp/udp Default maximum number of servers ....... 32 Proportion given to active connections... 0.5 Proportion given to new connections...... 0.5 Proportion given specific to the port.... 0 Proportion given to system metrics....... 0 Shared bandwidth (KBytes) ............... 0 Primary Host Address .................... 9.67.131.167
>>-dscontrol--executor--+-report-----------------------------------------------------------+->< +-set--+-nfa--IP address------------+------------------------------+ | +-maxclusters--size----------+ | | +-maxports--size-------------+ | | +-fintimeout--fintimeout-----+ | | +-hatimeout--size------------+ | | +-hasynctimeout--time--------+ | | +-maxservers--size-----------+ | | +-mss--size------------------+ | | +-staletimeout--staletimeout-+ | | +-stickytime--time-----------+ | | +-clientgateway--address-----+ | | +-weightbound--weight--------+ | | +-porttype--type-------------+ | | +-wideportnumber--port-------+ | | '-sharedbandwidth--size------' | +-configure--interface_address+i2+...--+-------------------------+-+ | '-interface_name--netmask-' | +-unconfigure--interface_name-----------------------------------+ +-start------------------------------------------------------------+ +-status-----------------------------------------------------------+ '-stop-------------------------------------------------------------'
Il timer viene utilizzato per garantire che la macchina principale e quella di backup siano sincronizzate. Tuttavia, se è presente un numero troppo elevato di connessioni e la macchina attiva continua a gestire un carico di traffico in entrata significativo, allora la sincronizzazione potrebbe non essere completate nel periodo definito dal timer. Come risultato, Load Balancer proverà a eseguire continuamente la risincronizzazione e le due macchine non saranno mai sincronizzate. In questo caso, impostare hasynctimeout su un valore maggiore di quello predefinito in modo da fornire alle due macchine un tempo sufficiente per scambiare le informazioni sulle connessioni esistenti. Per impostare questo timer, il comando hasynctimeout deve essere emesso dopo il comando dscontrol executor start ma prima di emettere i comandi ad alta disponibilità (dscontrol highavailability ).
Esempi
dscontrol executor status Executor Status: ---------------- Nonforwarding address ............... 9.67.131.151 Client gateway address .............. 0.0.0.0 Fin timeout ......................... 60 Wide area network port number ....... 0 Shared bandwidth (Kbytes) ........... 0 Default maximum ports per cluster ... 8 Maximum number of clusters .......... 100 Default maximum servers per port .... 32 Default stale timeout ............... 300 Default sticky time ................. 0 Default weight bound ................ 20 Default port type ................... tcp/udp
dscontrol executor set nfa 130.40.52.167
dscontrol executor set maxclusters 4096
dscontrol executor start
dscontrol executor stop
>>-dscontrol--file--+-delete--file[.ext]----------+------------>< +-appendload--file[.ext]------+ +-report----------------------+ +-save--file[.ext]--+-------+-+ | '-force-' | '-newload--file[.ext]---------'
L'estensione del file (.ext) è a scelta e può essere omessa.
Esempi
dscontrol file delete file3 Il file (file3) è stato eliminato.
dscontrol file newload file1.sv Il file (file1.sv) è stato caricato nel Dispatcher.
dscontrol file appendload file2.sv Il file (file2.sv) è stato accodato alla configurazione corrente e caricato.
dscontrol file report FILE REPORT: file1.save file2.sv file3
dscontrol file save file3 La configurazione è stata salvata nel file (file3).
>>-dscontrol--help--+-advisor----------+----------------------->< +-binlog-----------+ +-cluster----------+ +-executor---------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-host-------------+ +-logstatus--------+ +-manager----------+ +-metric-----------+ +-port-------------+ +-rule-------------+ +-server-----------+ +-set--------------+ +-status-----------+ '-subagent---------'
Esempi
dscontrol helpQuesto comando produce un output simile a:
HELP COMMAND ARGUMENTS: --------------------------------- Utilizzo: help <help option> Esempio: help cluster help - stampa il testo completo della guida advisor - guida per il comando advisor cluster - guida per il comando cluster executor - guida per il comando executor file - guida per il comando file host - guida per il comando host binlog - guida per il comando binary log manager - guida per il comando manager metric - guida per il comando metric port - guida per il comando port rule - guida per il comando rule server - guida per il comando server set - guida per il comando set status - guida per il comando status logstatus - guida per lo stato del log server subagent - guida per il comando subagent highavailability - guida per il comando high availabilityNotare che i parametri nelle tag <> sono variabili.
fintimeout <cluster address>|all <time> -Change FIN timeout (Use 'all' to change all clusters)
>>-dscontrol--highavailability--+-status--------------------------------------+->< +-backup--+-add--+-primary-+--+-auto---+--p-+-+ | | +-backup--+ '-manual-' | | | | '-both----' | | | '-delete--------------------------' | +-reach--+-add----+--address--mask------------+ | '-delete-' | +-heartbeat--+-add--srcaddress--dstaddress-+--+ | '-delete--address-------------' | '-takeover--+---------+-----------------------' '-address-'
Inoltre, la parola chiave status restituisce informazioni su vari stati secondari:
Configurazione di disponibilità elevata reciproca (il ruolo di ciascuna macchina Dispatcher è both):
Note:
Esempi
dscontrol highavailability status
Output:
High Availability Status: ------------------------- Role ........................primary Recovery Strategy ........... manual State ....................... Active Sub-state.............. Synchronized Primary host........... 9.67.131.151 Port .........................12345 Preferred Target....... 9.67.134.223 Heartbeat Status: ----------------- Count ......................... 1 Source/destination ............ 9.67.131.151/9.67.134.223 Reachability Status: -------------------- Count ................ 1 Address .............. 9.67.131.1 reachable
dscontrol highavailability backup add primary auto 80
dscontrol highavailability reach add 9.67.125.18
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3
dscontrol highavailability takeover
>>-dscontrol--host:--remote_host-------------------------------><
dscontrol host:host_remoto
Dopo aver emesso questo comando sul prompt dei comandi, immettere un comando dscontrol valido da inviare alla macchina Load Balancer remota.
>>-dscontrol--logstatus----------------------------------------><
Esempi
Per visualizzare logstatus:
dscontrol logstatus
Questo comando produce un output simile a:
Dispatcher Log Status: ------------------------------ Log filename ............... C:\PROGRA~1\IBM\edge\lb\servers\logs\dispatcher \server.log Log level .................. 1 Maximum log size (bytes) ... 1048576
>>-dscontrol--manager--+-interval--seconds----------------------+->< +-loglevel--level------------------------+ +-logsize--+-unlimited-+-----------------+ | '-bytes-----' | +-metric set--+-loglevel--level--------+-+ | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-quiesce--server--+-----+---------------+ | '-now-' | +-reach set--+-interval--seconds------+--+ | +-loglevel--level--------+ | | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-refresh--refresh cycle-----------------+ +-report--+----------------+-------------+ | '-cluster+c2+...-' | +-restart--message-----------------------+ +-sensitivity--weight--------------------+ +-smoothing--smoothing index-------------+ +-start--+-----------------------+-------+ | '-log file--metric_port-' | +-status---------------------------------+ +-stop-----------------------------------+ +-unquiesce--server----------------------+ '-version--------------------------------'
Altrimenti, se è stata adoperata la suddivisione in partizioni del server, utilizzare il nome univoco del server logico. Per ulteriori informazioni, vedere Suddivisione in partizioni dei server: server logici configurati su un server fisico (indirizzo IP).
Il file predefinito viene installato nella directory logs. Vedere Appendice C, File di configurazione di esempio. Per modificare la directory su cui vengono memorizzati i file di log, vedere Modifica dei percorsi file di log.
Esempi
dscontrol manager interval 5
dscontrol manager loglevel 0
dscontrol manager logsize 1000000
dscontrol manager quiesce 130.40.52.153
dscontrol manager refresh 3
dscontrol manager reportQuesto comando produce un output simile a:
-------------------------------------------------------------------- | SERVER | IP ADDRESS | STATUS | -------------------------------------------------------------------- | mach14.dmz.com | 10.6.21.14 | ACTIVE | | mach15.dmz.com | 10.6.21.15 | ACTIVE | -------------------------------------------------------------------- ----------------------------- | MANAGER REPORT LEGEND | ----------------------------- | ACTV | Active Connections | | NEWC | New Connections | | SYS | System Metric | | NOW | Current Weight | | NEW | New Weight | | WT | Weight | | CONN | Connections | ----------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | WEIGHT | ACTV | NEWC | PORT | SYS | | PORT: 21 |NOW NEW| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | -1 | 0 | | mach15.dmz.com | 10 10 | 0 | 0 | -1 | 0 | ------------------------------------------------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | WEIGHT | ACTV | NEWC | PORT | SYS | | PORT: 80 |NOW NEW| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | 23 | 0 | | mach15.dmz.com | 9 9 | 0 | 0 | 30 | 0 | ------------------------------------------------------------------- --------------------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | --------------------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------------------
dscontrol manager restart Restarting the manager to update codeQuesto comando produce un output simile a:
320-14:04:54 Riavvio del gestore per aggiornare il codice
dscontrol manager sensitivity 10
dscontrol manager smoothing 2.0
dscontrol manager start ndmgr.log
dscontrol manager statusQuesto comando produce un output simile al seguente esempio.
Manager status: =============== Metric port................................... 10004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 0.05 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7 Metric monitor log file name.................. MetricMonitor.log Metric monitor log level...................... 1 Maximum metric monitor log size............... 1048576
dscontrol manager stop
dscontrol manager quiesce 130.40.52.153 now
dscontrol manager quiesce 130.40.52.153
dscontrol manager unquiesce 130.40.52.153
dscontrol manager version
>>-dscontrol--metric--+-add--cluster+c2+...+cN:metric+metric1+...+metricN--------------+->< +-remove--cluster+c2+...+cN:metric+metric1+...+metricN-----------+ +-proportions--cluster+c2+...+cN proportion1 prop2 prop3...propN-+ '-status--cluster+c2+...+cN:metric+metric1+...+metricN-----------'
Esempi
dscontrol metric add site1:metric1
dscontrol metric proportions site1 0 100
dscontrol metric status site1:metric1Questo comando produce un output simile al seguente:
Metric Status: ------------ Cluster ....................... 10.10.10.20 Metric name ................... metric1 Metric proportion ............. 50 Server .................... plm3 Metric data ............... -1
>>-dscontrol--port--+-add--cluster:port--+----------------------+-+->< | +-crossport--otherport-+ | | +-maxservers--size-----+ | | +-stickymask--value----+ | | +-stickytime--time-----+ | | +-method--type---------+ | | +-staletimeout--value--+ | | +-weightbound--weight--+ | | +-porttype--type-------+ | | +-protocol--type-------+ | | '-reset--value---------' | +-set--cluster:port--+-crossport--otherport-+-+ | +-maxservers--size-----+ | | +-stickymask--value----+ | | +-stickytime--time-----+ | | +-staletimeout--value--+ | | +-weightbound--weight--+ | | +-porttype--type-------+ | | +-maxhalfopen--value---+ | | '-reset--value---------' | +-remove--cluster:port------------------------+ +-report--cluster:port------------------------+ +-status--cluster:port------------------------+ '-halfopenaddressreport--cluster:port---------'
Per eliminare la funzione crossport, impostare nuovamente il valore crossport sul numero di porta originale. Per ulteriori informazioni sulla funzione di affinità multiporta, consultare Affinità multiporta.
Per il componente Dispatcher:
Per il componente CBR: se si imposta port stickytime su un valore diverso da zero, il tipo di affinità sulla regola deve essere none (valore predefinito). L'affinità basata su regole (cookie passivo, URI, cookie attivo) non può coesistere quando stickytime è impostato sulla porta.
Note:
Un valore positivo indica che verrà effettuato un controllo per determinare se le attuali connessioni aperte a metà superano la soglia. In questo caso, viene effettuata una chiamata a uno script di avvertimento. Per ulteriori informazioni, vedere Rilevamento attacco di tipo Denial of service.
Esempi
dscontrol port add 130.40.52.153:80+23
dscontrol port set 130.40.52.153:0
dscontrol port set 130.40.52.153:80 weightbound 10
dscontrol port set 130.40.52.153:80+23 stickytime 60
dscontrol port set 130.40.52.153:80 crossport 23
dscontrol port remove 130.40.52.153:23
dscontrol port status 9.67.131.153:80Questo comando produce un output simile a:
Port Status: ------------ Port number .................... 80 Cluster ........................ 9.67.131.153 Stale timeout .................. 300 Weight bound ................... 20 Maximum number of servers ...... 32 Sticky time .................... 0 Port type ...................... tcp/udp Cross Port Affinity ............ 80 Sticky mask bits ............... 32 Max Half Open Connections ...... 0 Send TCP Resets ................ no
dscontrol port report 9.62.130.157:80Questo comando produce un output simile a:
Port Report: ------------ Cluster address ................ 9.62.130.157 Port number .................... 80 Number of servers .............. 5 Maximum server weight .......... 10 Total active connections ....... 55 Connections per second ......... 12 KBytes per second .............. 298 Number half open ............... 0 TCP Resets sent ................ 0 Forwarding method .............. MAC Based Forwarding
dscontrol port halfopenaddressreport 9.67.127.121:80Questo comando produce un output simile a:
Half open connection report successfully created: ------------ Half Open Address Report for cluster:port = 9.67.127.121:80 Total addresses with half open connections reported ... 0 Total number of half open connections reported ........ 0 Largest number of half open connections reported ...... 0 Average number of half open connections reported ...... 0 Average half open connection time (seconds) reported .. 0 Total half open connections received .................. 0
>>-dscontrol--rule--+-add--cluster:port:rule--type--type--| opts |-+->< +-dropserver--cluster:port:rule--server--------+ +-remove--cluster:port:rule--------------------+ +-report--cluster:port:rule--------------------+ +-set--cluster:port:rule--| opts |-------------+ +-status--cluster:port:rule--------------------+ '-useserver--cluster:port:rule--server+s2+...--' opts: |--+---------------------------------+--------------------------| +-beginrange--low--endrange--high-+ +-priority--level-----------------+ +-pattern--pattern----------------+ +-tos--value----------------------+ +-stickytime--time----------------+ +-affinity--affinity_type---------+ +-cookiename--value---------------+ +-evaluate--level-----------------+ '-sharelevel--level---------------'
Per ulteriori informazioni, vedere Affinità cookie attivo.
Un tipo di affinità "activecookie" consente di bilanciare il carico del traffico Web con caratteristiche di affinità con lo stesso server tramite la creazione di cookie da parte di Load Balancer.
Un tipo di affinità "passivecookie" 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. È necessario utilizzare il parametro cookiename insieme all'affinità cookie passivo.
Un tipo di affinità "URI" consente di bilanciare il carico del traffico Web per i server Caching Proxy in una maniera che consente di aumentare efficacemente la dimensione della cache.
Per ulteriori informazioni, vedere Affinità cookie attivo, Affinità cookie passivo e Affinità URI.
Per ulteriori informazioni, vedere Affinità cookie passivo.
Per la regola di tipo connessione, è possibile specificare anche un'opzione evaluate -- upserversonrule. Specificando upserversonrule, i server che rimangono all'interno della regola non verranno sovraccaricati, se alcuni dei server del gruppo non sono attivi.
Altrimenti, se è stata adoperata la suddivisione in partizioni del server, utilizzare il nome univoco del server logico. Per ulteriori informazioni, vedere Suddivisione in partizioni dei server: server logici configurati su un server fisico (indirizzo IP).
Esempi
dscontrol rule add 9.37.67.100:80:trule type true priority 100
dscontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
dscontrol rule add cluster1:80:timerule type time beginrange 11 endrange 14 dscontrol rule useserver cluster1:80:timerule server05
dscontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
dscontrol rule add 9.67.131.153:80:rbwrule type reservedbandwidth beginrange 0 endrange 100 evaluate rule
dscontrol cluster set 9.67.131.153 sharedbandwidth 200 dscontrol rule add 9.67.131.153:80:shbwrule type sharedbandwidth sharelevel cluster
>>-dscontrol--server--+-add--cluster:port:server--+-------------------------+-+->< | +-address--address--------+ | | +-collocated--value-------+ | | +-sticky--value-----------+ | | +-weight--value-----------+ | | +-fixedweight--value------+ | | +-cookievalue--value------+ | | +-mapport--portvalue------+ | | +-protocol--value---------+ | | +-router--addr------------+ | | +-returnaddress--addr-----+ | | +-advisorrequest--string--+ | | '-advisorresponse--string-' | +-set--cluster:port:server--+-collocated--value-------+-+ | +-sticky--value-----------+ | | +-weight--value-----------+ | | +-fixedweight--value------+ | | +-cookievalue--value------+ | | +-protocol--value---------+ | | +-router--addr------------+ | | +-advisorrequest--string--+ | | '-advisorresponse--string-' | +-down--cluster:port:server-----------------------------+ +-remove--cluster:port:server---------------------------+ +-report--cluster:port:server---------------------------+ +-up--cluster:port:server-------------------------------+ '-status--cluster:port:server---------------------------'
Altrimenti, se si utilizza un nome univoco che non si risolve in un indirizzo IP, è necessario specificare il parametro address del server sul comando dscontrol server add. Per ulteriori informazioni, vedere Suddivisione in partizioni dei server: server logici configurati su un server fisico (indirizzo IP).
Quando il comando del server inattivo (dscontrol server down) viene utilizzato per porre un server offline, se il valore dell'intervallo è diverso da zero per tale server, i client esistenti continuano a funzionare sul server fino a che viene raggiunto l'intervallo. Il server non sarà reso inattivo fino a che non viene raggiunto il valore dell'intervallo.
Esempi
dscontrol server add 130.40.52.153:80:27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 sticky no
dscontrol server down 130.40.52.153:80:27.65.89.42
dscontrol server remove ::27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
dscontrol server set 130.40.52.153:80:27.65.89.42 weight 10
dscontrol server up 130.40.52.153:80:27.65.89.42
dscontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
dscontrol server set 130.40.52.153:80:27.65.89.42 advisorrequest "\"HEAD / HTTP/1.0\""
dscontrol server status 9.67.131.167:80:9.67.143.154Questo comando produce un output simile a:
Server Status: -------------- Server ......................... 9.67.143.154 Port number .................... 80 Cluster ........................ 9.67.131.167 Cluster address ................ 9.67.131.167 Quiesced ....................... N Server up ...................... Y Weight ......................... 10 Fixed weight ................... N Sticky for rule ................ Y Remote server .................. N Network Router address ......... 0.0.0.0 Collocated ..................... N Advisor request................. HEAD / HTTP/1.0 Advisor response................ Cookie value ................... n/a Clone ID ....................... n/a
>>-dscontrol--set--+-loglevel--level--------+------------------>< '-logsize--+-unlimited-+-' '-size------'
>>-dscontrol--status-------------------------------------------><
Esempi
dscontrol statusQuesto comando produce un output simile a:
Executor has been started. Manager has been started. ---------------------------------------- | ADVISOR | CLUSTER:PORT | TIMEOUT | ---------------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | ----------------------------------------
>>-dscontrol--subagent--+-loglevel--level--------------------+->< +-logsize--+-bytes-----+-------------+ | '-unlimited-' | +-report-----------------------------+ +-start--+-------------------------+-+ | '-community_name--logfile-' | +-status-----------------------------+ +-stop-------------------------------+ '-version----------------------------'
Per la piattaforma Windows: viene utilizzato il nome comunità del sistema operativo.
Esempi
dscontrol subagent start bigguy bigguy.log
Questo capitolo descrive come utilizzare i seguenti comandi sscontrol di Site Selector:
È possibile immettere una versione ridotta dei parametri del comando sscontrol. È sufficiente inserire le lettere che designano in modo univoco i parametri. Ad esempio, per richiamare la guida sul comando di salvataggio file, è possibile digitare sscontrol he f invece di sscontrol help file.
>>-sscontrol--advisor--+-connecttimeout--name--+-port----------+--seconds-------+->< | '-sitename:port-' | +-interval--name--+-port----------+--seconds-------------+ | '-sitename:port-' | +-list---------------------------------------------------+ +-loglevel--name--+-port----------+--level---------------+ | '-sitename:port-' | +-logsize--name--+-port----------+--+-size | unlimited-+-+ | '-sitename:port-' '-bytes------------' | +-receivetimeout--name--+-port----------+--seconds-------+ | '-sitename:port-' | +-report--name--+-port----------+------------------------+ | '-sitename:port-' | +-retries--name--+-port----------+--numretries-----------+ | '-sitename:port-' | +-start--name--+-port----------+--+----------+-----------+ | '-sitename:port-' '-log file-' | +-status--name--+-port----------+------------------------+ | '-sitename:port-' | +-stop--name--+-port----------+--------------------------+ | '-sitename:port-' | +-timeout--name--+-port----------+-----------------------+ | '-sitename:port-' | '-version--name--+-port----------+--seconds--------------' '-sitename:port-'
.
Nome advisor | Protocollo | Port |
---|---|---|
Connect | n/d | definito dall'utente |
db2 | private | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
PING | PING | N/A |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
Il file predefinito è porta_nomeadvisor .log, ad esempio, http_80.log. Per modificare la directory su cui vengono memorizzati i file di log, vedere Modifica dei percorsi file di log.
È possibile avviare un solo advisor per ogni sitename.
Esempi
sscontrol advisor connecttimeout http 80 30
sscontrol advisor interval ftp 21 6
sscontrol advisor listQuesto comando produce un output simile a:
--------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | --------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
sscontrol advisor loglevel http mysite:80 0
sscontrol advisor logsize ftp mysite:21 5000
sscontrol advisor receivetimeout http 80 60
sscontrol advisor report ftp 21Questo comando produce un output simile a:
Advisor Report: --------------- Advisor name ............. http Port number .............. 80 sitename ................. mySite Server address ........... 9.67.129.230 Load ..................... 8
sscontrol advisor start ftp 21 ftpadv.log
sscontrol advisor status http 80Questo comando produce un output simile al seguente:
Advisor Status: --------------- Interval (seconds) ............ 7 Timeout (seconds) ............. Unlimited Connect timeout (seconds).......21 Receive timeout (seconds).......21 Advisor log filename .......... Http_80.log Log level ..................... 1 Maximum log size (bytes) ...... Unlimited Number of retries ............. 0
sscontrol advisor stop http 80
sscontrol advisor timeout ftp 21 5
sscontrol advisor version ssl 443
>>-sscontrol--file--+-delete--filename.ext----------+---------->< +-appendload--filename.ext------+ +-report------------------------+ +-save--filename.ext--+-------+-+ | '-force-' | '-newload--filename.ext---------'
L'estensione del file (.ext) è a scelta e facoltativa.
Esempi
sscontrol file delete file3 File (file3) was deleted.
sscontrol file newload file1.sv File (file1.sv) was loaded into the Dispatcher.
sscontrol file appendload file2.sv File (file2.sv) was appended to the current configuration and loaded.
sscontrol file report FILE REPORT: file1.save file2.sv file3
sscontrol file save file3 The configuration was saved into file (file3).
>>-sscontrol--help--+-advisor----+----------------------------->< +-file-------+ +-help-------+ +-host-------+ +-logstatus--+ +-manager----+ +-metric-----+ +-nameserver-+ +-rule-------+ +-server-----+ +-set--------+ +-sitename---+ '-status-----'
Esempi
sscontrol helpQuesto comando produce un output simile a:
HELP COMMAND ARGUMENTS: --------------------------------- Utilizzo: help <opzione guida> Esempio: nome guida help - stampa il testo completo della guida advisor - guida per il comando advisor file - guida per il comando file host - guida per il comando host manager - guida per il comando manager metric - guida per il comando metric sitename - guida per il comando sitename nameserver - guida per il comando nameserver rule - guida per il comando rule server - guida per il comando server set - guida per il comando set status - guida per il comando status logstatus - guida per il comando logstatusI parametri nelle tag < > sono variabili.
logsize <number of bytes | unlimited> -Set the maximum number of bytes to be logged in the log file
>>-sscontrol--logstatus----------------------------------------><
>>-sscontrol--manager--+-interval--seconds----------------------+->< +-loglevel--level------------------------+ +-logsize--+-unlimited-+-----------------+ | '-bytes-----' | +-metric set--+-loglevel--level--------+-+ | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-reach set--+-interval--seconds------+--+ | +-loglevel--level--------+ | | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-report--sitename+sn2+...+snN-----------+ +-restart--message-----------------------+ +-sensitivity--weight--------------------+ +-smoothing--smoothing index-------------+ +-start--+----------------------+--------+ | '-logfile--metric_port-' | +-status---------------------------------+ +-stop-----------------------------------+ '-version--------------------------------'
Il file predefinito viene installato nella directory logs. Vedere Appendice C, File di configurazione di esempio. Per modificare la directory su cui vengono memorizzati i file di log, vedere Modifica dei percorsi file di log.
Esempi
sscontrol manager interval 5
sscontrol manager loglevel 0
sscontrol manager logsize 1000000
sscontrol manager reportQuesto comando produce un output simile a:
---------------------------------- | SERVER | STATUS | ---------------------------------- | 9.67.129.221| ACTIVE| | 9.67.129.213| ACTIVE| | 9.67.134.223| ACTIVE| ---------------------------------- -------------------------- | MANAGER REPORT LEGEND | -------------------------- | CPU | CPU Load | | MEM | Memory Load | | SYS | System Metric | | NOW | Current Weight | | NEW | New Weight | | WT | Weight | -------------------------- ------------------------------------------------------------------------ | mySite | WEIGHT | CPU 49% | MEM 50% | PORT 1% | SYS 0% | ------------------------------------------------------------------------ | |NOW NEW | WT LOAD | WT LOAD | WT LOAD | WT LOAD | ------------------------------------------------------------------------ | 9.37.56.180 | 10 10 |-99 -1|-99 -1|-99 -1| 0 0| ------------------------------------------------------------------------ | TOTALS:| 10 10 | -1| -1| -1| 0| ------------------------------------------------------------------------ ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ----------------------------------------- | http | 80 | unlimited | -----------------------------------------
sscontrol manager restart Restarting the manager to update codeQuesto comando produce un output simile a:
320-14:04:54 Restarting the manager to update code
sscontrol manager sensitivity 10
sscontrol manager smoothing 2.0
sscontrol manager start ndmgr.log
sscontrol manager statusQuesto comando produce un output simile al seguente esempio.
Manager status: ============= Metric port................................... 10004 Manager log filename.......................... manager.log Manager log level............................. 1 Maximum manager log size (bytes).............. unlimited Sensitivity level............................. 5 Smoothing index............................... 1.5 Update interval (seconds)..................... 2 Weights refresh cycle......................... 2 Reach log level............................... 1 Maximum reach log size (bytes)................ unlimited Reach update interval (seconds)............... 7
sscontrol manager stop
sscontrol manager version
>>-sscontrol--metric--+-add--sitename+sn2+...+snN:metric+metric1+...+metricN--------------+->< +-remove--sitename+sn2+...+snN:metric+metric1+...+metricN-----------+ +-proportions--sitename+sn2+...+snN:proportion1 prop2 prop3...propN-+ '-status--sitename+sn2+...+snN metric+metric1+...+metricN-----------'
Esempi
sscontrol metric add site1:metric1
sscontrol metric proportions site1 0 100
sscontrol metric status site1:metric1Questo comando produce un output simile al seguente:
Metric Status: ------------ sitename ..................... site1 Metric name ................... metric1 Metric proportion ............. 50 Server ......... 9.37.56.100 Metric data .... -1
>>-sscontrol--nameserver--+-start--+----------------------+-+-->< | '-bindaddress--address-' | +-stop----------------------------+ '-status--------------------------'
>>-sscontrol--rule--+-add--sitename+sn2+...+snN:rule+r2+...+rN--type--value--| value |--| opts |-+->< +-dropserver--sitename+sn2+...+snN:rule+r2+...+rN--server+s2+...+snN---------+ +-remove--sitename+sn2+...+snN:rule+r2+...+rN--------------------------------+ +-set--sitename+sn2+...+snN:rule+r2+...+rN--| value |--| opts |--------------+ +-status--sitename+sn2+...+snN:rule+r2+...+rN--------------------------------+ '-useserver--sitename+sn2+...+snN:rule+r2+...+rN--server+s2+...+snN----------' opts: |--+---------------------------------+--------------------------| +-beginrange--low--endrange--high-+ +-priority--value-----------------+ '-metricname--value---------------'
Esempi
sscontrol rule add sitename:rulename type true priority 100
sscontrol rule add sitename:rulename type ip b 9.0.0.0 e 9.255.255.255
sscontrol rule add sitename:rulename type time beginrange 11 endrange 14 sscontrol rule useserver sitename:rulename server05
>>-sscontrol--server--+-add--sitename+sn2+...+snN:server+s2+...+sN--+------------------------+-+->< | +-metricaddress--address-+ | | '-weight--value----------' | +-down--sitename+sn2+...+snN:server+s2+...+sN----------------------------+ +-remove--sitename+sn2+...+snN:server+s2+...+sN--------------------------+ +-set--sitename+sn2+...+snN:server+s2+...+sN--+------------------------+-+ | +-metricaddress--address-+ | | '-weight--value----------' | +-status--sitename+sn2+...+snN:server+s2+...+sN--------------------------+ '-up--sitename+sn2+...+snN:server+s2+...+sN------------------------------'
Esempi
sscontrol server add site1:27.65.89.42
sscontrol server down site1:27.65.89.42
sscontrol server remove :27.65.89.42
sscontrol server up site1:27.65.89.42
>>-sscontrol--set--+-loglevel--level--------+------------------>< '-logsize--+-unlimited-+-' '-size------'
>>-sscontrol--sitename--+-add--sitename+sn2+...+snN--+----------------------------------------+-+->< | +-cachelife--value-----------------------+ | | +-networkproximity--yes | no-------------+ | | +-proportions--cpu--memory--port--metric-+ | | +-proximitypercentage--value-------------+ | | +-stickytime--time-----------------------+ | | +-ttl--time------------------------------+ | | +-waitforallresponses--yes | no----------+ | | '-weightbound--weight--------------------' | +-remove--sitename+sn2+...+snN------------------------------------------+ +-set--sitename+sn2+...+snN--+----------------------------------------+-+ | +-cachelife--value-----------------------+ | | +-networkproximity--yes | no-------------+ | | +-proportions--cpu--memory--port--metric-+ | | +-proximitypercentage--value-------------+ | | +-stickytime--time-----------------------+ | | +-ttl--time------------------------------+ | | +-waitforallresponses--yes | no----------+ | | '-weightbound--weight--------------------' | '-status--sitename+sn2+...+snN------------------------------------------'
Esempi
sscontrol sitename add 130.40.52.153
sscontrol sitename set mySite networkproximity yes
sscontrol sitename set mySite cachelife 1900000
sscontrol sitename set mySite proximitypercentage 45
sscontrol sitename set mySite waitforallresponses no
sscontrol sitename set mySite ttl 7
sscontrol sitename set mySite proportions 50 48 1 1
sscontrol sitename remove 130.40.52.153
sscontrol sitename status mySiteQuesto comando produce un output simile a:
SiteName Status: --------------- SiteName ........................... mySite WeightBound ........................ 20 TTL ................................ 5 StickyTime ......................... 0 Number of Servers .................. 1 Proportion given to CpuLoad ........ 49 Proportion given to MemLoad ........ 50 Proportion given to Port ........... 1 Proportion given to System metric .. 0 Advisor running on port ............ 80 Using Proximity .................... N
>>-sscontrol--status-------------------------------------------><
Esempi
sscontrol statusQuesto comando produce un output simile a:
NameServer has been started. Manager has been started. ----------------------------------------- | ADVISOR | SITENAME:PORT | TIMEOUT | ---------------------------------------- | http | 80 | unlimited | -----------------------------------------
Questo capitolo descrive come utilizzare i seguenti comandi ccocontrol di Cisco CSS Contoller:
È possibile utilizzare una versione abbreviata dei parametri del comando ccocontrol digitando le lettere che designano in modo univoco i parametri. Ad esempio, per visualizzare le informazioni sul comando di salvataggio del file, è possibile digitare ccocontrol he f invece di ccocontrol help file.
Per richiamare il prompt dei comandi ccocontrol: digitare ccocontrol .
Per chiudere l'interfaccia della riga comandi: emettere exit o quit.
>>-ccocontrol--consultant--+-add--scID--address--swIPAddr--community--commName-+->< +-binarylog--scID+scID2...--+-report-------------+--+ | +-set--+-interval--+-+ | | | '-retention-' | | | +-start--------------+ | | '-stop---------------' | +-remove--scID+scID2...-----------------------------+ +-report--scID+scID2...-----------------------------+ +-set--+-loglevel--level----------------+-----------+ | +-logsize--+-size------+---------+ | | | '-unlimited-' | | | +-sensitivity--weight percentage-+ | | '-sleeptime--sec-----------------' | +-start--scID+scID2...------------------------------+ '-stop--scID+scID2...-------------------------------'
0 = Nessuno
1 = Minimo
2 = Base
3 = Moderato
4 = Avanzato
5 = Verbose
Esempi
ccocontrol consultant add sc1 address 9.37.50.17 community comm2
ccocontrol consultant binarylog sc1 start
ccocontrol consultant report sc1
Questo comando produce un output simile a:
Consultant sc1 connected to switch at 9.37.50.1:cn1 Consultant has been started Sleep time = 7 Sensitivity = 5 Log level = 5 Log size = 1,048,576 ownerContent(s): ownerContent oc1
ccocontrol consultant set sc1 sleeptime 10
ccocontrol consultant start sc1
>>-ccocontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--level--------+ '-logsize--+-size------+-' '-unlimited-'
0 = Nessuno
1 = Minimo
2 = Base
3 = Moderato
4 = Avanzato
5 = Verbose
Esempi
ccocontrol controller report
Questo comando produce un output simile a:
Controller Report: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Logging level . . . . . . 1 Log size. . . . . . . . . 1048576 Configuration File. . . . config1.xml Consultants: Consultant consult1 -Started
ccocontrol set loglevel 0
ccocontrol controller set logsize 1000000
>>-ccocontrol--file--+-delete--filename----------+------------->< +-load--filename------------+ +-report--------------------+ '-save--filename--+-------+-' '-force-'
directory di installazione (predefinita) C:\Program Files\ibm\edge\lb\servers\configurations\cco
Esempi
ccocontrol file delete file1
ccocontrol file load config2
ccocontrol file report
Questo comando produce un output simile a:
FILE REPORT: ------------ file1.xml file2.xml file3.xml
ccocontrol file save config2
>>-ccocontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metriccollector--+ +-ownercontent-----+ '-service----------'
Esempi
ccocontrol help
Questo comando produce un output simile a:
Sono disponibili i seguenti comandi: controller - funziona sul controller consultant - funziona sui consultant dello switch file - funziona sui file di configurazione help - funziona sulla guida highavailability - funziona sulla disponibilità elevata metriccollector - funziona sugli strumenti di raccolta delle metriche ownerContent - funziona su ownerContents service - funziona sui servizi
>>-ccocontrol--highavailability--+-add--+-address--address---------------+-+->< | +-partneraddress--partneraddress-+ | | +-port--port---------------------+ | | '-role--+-primary---+------------' | | '-secondary-' | +-dropreach--address----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--time-----+---------+ | +-takeoverinterval--time-+ | | +-loglevel--level--------+ | | '-logsize--+-size------+-' | | '-unlimited-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--address-----------------------'
0 = Nessuno
1 = Minimo
2 = Base
3 = Moderato
4 = Avanzato
5 = Verbose
ccocontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
ccocontrol highavailability usereach 9.37.50.9
ccocontrol highavailability dropreach 9.37.50.9
ccocontrol highavailability start manual
ccocontrol highavailability report
Questo comando produce un output simile a:
High Availability Status: ------------------------- Node . . . . . . . . . . . primary Node Address . . . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Partner Address. . . . . . 9.37.50.14 Recovery Strategy. . . . . manual Heartbeat Interval . . . . 500 Takeover Interval. . . . . 2000 State. . . . . . . . . . . idle Sub-state. . . . . . . . . unsynchronized Reachability Status : Node/Partner --------------------------------------- No reach targets configured
>>-ccocontrol--metriccollector--+-report--scID+scID2+...:mN+mN2...--------------------------+->< '-set--scID+scID2+...:mN+mN2...--+-timeoutconnect--sec----+-' +-loglevel--level--------+ +-logsize--+-size------+-+ | '-unlimited-' | +-timeoutreceive--sec----+ '-sleeptime--sec---------'
0 = Nessuno
1 = Minimo
2 = Base
3 = Moderato
4 = Avanzato
5 = Verbose
Esempi
ccocontrol metriccollector report sc1:http
Questo comando produce un output simile a:
MetricCollector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
ccocontrol metriccollector set sc1:http timeoutconnect 15 logsize unlimited
>>-ccocontrol--ownerContent--+-add--scID:ocN--ownername--oN--contentrule--cN------------------------------+->< +-metrics--scID+scID2...:ocN+ocN2...--mN--importance--mN2--i2----------------+ +-refresh--scID+scID2...:ocN+ocN2...-----------------------------------------+ +-remove--scID+scID2...:ocN+ocN2...------------------------------------------+ +-report--scID+scID2...:ocN+ocN2...------------------------------------------+ '-set--scID+scID2...:ocN+ocN2...----metric--mN--+------------------------+---' +-requeststring--string--+ +-responsestring--string-+ '-retry--numretries------'
Segue un elenco di nomi di metriche validi e delle
porte associate.
Nome advisor | Protocollo | Port |
---|---|---|
connessione | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (via Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10,007 |
activeconn | n/d | n/d |
connrate | n/d | n/d |
cpuload | n/d | n/d |
memload | n/d | n/d |
Esempi
ccocontrol ownerContent add sc1:oc1 ownername owner1 contentrule content1
ccocontrol ownerContent metrics sc1:oc1 activeconn 50 http 50
ccocontrol ownerContent report sc1:oc1
Questo comando produce un output simile a:
ownerContent sc1:oc1 Weightbound = 10 Metric activeconn has proportion 25 ResponseString... n/a RequestString.... n/a Metric http has proportion 50 ResponseString... n/a RequestString.... n/a Metric connrate has proportion 25 ResponseString... n/a RequestString.... n/a Contains Service t3 Contains Service t2 Contains Service t1
ccocontrol ownerContent set sc1:oc1 metric http requeststring getCookie
>>-ccocontrol--service--+-report--scID+scID2...:ocN+ocN2...:svc+svc2...---------------------------------+->< '---set--scID+scID2...:ocN+ocN2...:svc+svc2...--+---------------------------+---' +-fixedweight--+-integer-+--+ | '-off-----' | +-requestsourceip--IPAd-----+ +-metricserveraddress--IPAd-+ '-metricserverport--portN---'
Esempi
ccocontrol service report sc1:oc1:t1
Questo comando produce un output simile a:
Service sc1:oc1:ta has weight 10 Fixed weight is off Request Source Ip..... 9.27.24.156 Application port...... 80 MetricServer address.. 1.0.0.1 MetricServer port..... 10004 Metric activeconn has value -99 Metric http has value -99 Metric connrate has value -99
ccocontrol service set sc1:oc1:t2 metricserveraddress 9.37.50.17
Questo capitolo descrive come utilizzare i seguenti comandi nalcontrol di Nortel Alteon Contoller:
È possibile utilizzare una versione abbreviata dei parametri del comando nalcontrol, immettendo le lettere che designano in modo univoco i parametri. Ad esempio, per visualizzare la guida del comando di salvataggio file, è possibile immettere nalcontrol he f anziché nalcontrol help file.
Per richiamare il prompt dei comandi nalcontrol: immettere nalcontrol .
Per chiudere l'interfaccia della riga comandi: emettere exit o quit.
>>-nalcontrol--consultant--+-add--scID--address--swIPAddr--+---------------------------+-+->< | +-rcommunity--readCommName--+ | | '-wcommunity--writeCommName-' | +-binarylog--scID+scID2...--+-report------------------------+-+ | +-set--+-interval--interval---+-+ | | | '-retention--retention-' | | | +-start-------------------------+ | | '-stop--------------------------' | +-remove--scID+scID2...---------------------------------------+ +-report--scID+scID2...---------------------------------------+ +-set--+--------------------------------+---------------------+ | +-loglevel--level----------------+ | | +-logsize--+-size------+---------+ | | | '-unlimited-' | | | +-sensitivity--weight percentage-+ | | '-sleeptime--sec-----------------' | +-start--scID+scID2...----------------------------------------+ '-stop--scID+scID2...-----------------------------------------'
0 = Nessuno
1 = Minimo
2 = Base
3 = Moderato
4 = Avanzato
5 = Verbose
Esempi
nalcontrol consultant add sc1 address 9.37.50.17
nalcontrol consultant binarylog sc1 start
nalcontrol consultant report sc1
Questo comando produce un output simile a:
Consultant ID: sc1 Switch IP addr: 9.37.50.1 Read Community: public Write Community: private Consultant has been started Sleep time = 7 Sensitivity = 5 Log level = 5 log size = 1,048,576 Service(s): Service svc1
nalcontrol consultant set sc1 sleeptime 10
nalcontrol consultant start sc1
>>-nalcontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--level--------+ '-logsize--+-size------+-' '-unlimited-'
0 = Nessuno
1 = Minimo
2 = Base
3 = Moderato
4 = Avanzato
5 = Verbose
Esempi
nalcontrol controller report
Questo comando produce un output simile a:
Controller Report: ------------------------ Version . . . . . . . . . Version: 05.00.00.00 - 03/21/2002-09:49:57-EST Logging level . . . . . . 1 Log size. . . . . . . . . 1048576 Configuration File. . . . config1.xml Consultants: Consultant consult1 -Started
nalcontrol set loglevel 0
nalcontrol controller set logsize 1000000
>>-nalcontrol--file--+-delete--filename-+---------------------->< +-load--filename---+ +-report-----------+ '-save--filename---'
Percorso directory di installazione comune C:\Program Files\ibm\edge\lb\servers\configurations\nal
Percorso directory di installazione nativo C:\Program Files\ibm\lb\servers\configurations\nal
Esempi
nalcontrol file delete file1
nalcontrol file load config2
nalcontrol file report
Questo comando produce un output simile a:
FILE R EPORT: ------------ file1.xml file2.xml file3.xml
nalcontrol file save config2
>>-nalcontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metrinalllector--+ +-ownercontent-----+ '-service----------'
Esempi
nalcontrol help
Questo comando produce un output simile a:
Sono disponibili i seguenti comandi: controller - funziona sul controller consultant - funziona sui consultant dello switch file - funziona sui file di configurazione help - funziona sulla guida highavailability - funziona sulla disponibilità elevata metriccollector - funziona sugli strumenti di raccolta delle metriche server - funziona sui server service - funziona sui servizi
>>-nalcontrol--highavailability--+-add--+-address--address---------------+-+->< | +-partneraddress--partneraddress-+ | | +-port--port---------------------+ | | '-role--+-primary---+------------' | | '-secondary-' | +-dropreach--address----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--time-----+---------+ | +-takeoverinterval--time-+ | | +-loglevel--level--------+ | | '-logsize--+-size------+-' | | '-unlimited-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--address-----------------------'
0 = Nessuno
1 = Minimo
2 = Base
3 = Moderato
4 = Avanzato
5 = Verbose
nalcontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
nalcontrol highavailability usereach 9.37.50.9
nalcontrol highavailability dropreach 9.37.50.9
nalcontrol highavailability start manual
nalcontrol highavailability report
Questo comando produce un output simile a:
High Availability Status: ------------------------- Node . . . . . . . . . . . primary Node Address . . . . . . . 9.37.50.17 Port . . . . . . . . . . . 12345 Partner Address. . . . . . 9.37.50.14 Recovery Strategy. . . . . manual Heartbeat Interval . . . . 500 Takeover Interval. . . . . 2000 Started. . . . . . . . . . N State. . . . . . . . . . . idle Sub-state. . . . . . . . . unsynchronized Reachability Status : Node/Partner ---------------------------------------
>>-nalcontrol--metricollector--+-report--scID+scID2+...:mN+mN2...--------------------------+->< '-set--scID+scID2+...:mN+mN2...--+-connecttimeout--sec----+-' +-loglevel--level--------+ +-logsize--+-size------+-+ | '-unlimited-' | +-receivetimeout--sec----+ '-sleeptime--sec---------'
0 = Nessuno
1 = Minimo
2 = Base
3 = Moderato
4 = Avanzato
5 = Verbose
Esempi
nalcontrol metrinalllector report sc1:http
Questo comando produce un output simile a:
Metrinalllector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
nalcontrol metrinalllector set sc1:http connecttimeout 15 logsize unlimited
>>-nalcontrol--serer--+-report--scID+scID2...:svcID+svcID2...:serverID+svrID2...-----------------------------------+->< '---set--scID+scID2...:svcID+svcID2...:serverID+svrID2--+--------------------------------+---' +-fixedweight--+-integer-+-------+ | '-off-----' | +-requestsourceip--IPAddress-----+ +-metricserveraddress--IPAddress-+ '-metricserverport--portNumber---'
Esempi
nalcontrol server report sc1:svc1:1
Questo comando produce un output simile a:
Server sc1:svc1:1 has weight -99 Fixed weight is off Request Source Ip...... 9.27.24.156 Application port....... 99 MetricServer address... 9.99.99.98 MetricServer port...... 10004 Metric activeconn has value -99 Metric connrate has value -99
nalcontrol server set sc1:svc1:2 metricserveraddress 9.37.50.17
>>-nalcontrol--service--+-add--scID+scID2...:serviceID+svcID2...--vsid--virSvrID--vport--virPortNum------+->< +-metrics--scID+scID2...:svcID+svcID2...--mN--importance--mCN2--i2---------------+ +-refresh--scID+scID2...:svcID+svcID2...-----------------------------------------+ +-remove--scID+scID2...:svcID+svcID2...------------------------------------------+ +-report--scID+scID2...:svcID+svcID2...------------------------------------------+ '-set--scID+scID2...:svcID+svcID2...----metric--mN----+-requeststring--string--+-' +-responsestring--string-+ '-retry--numretries------'
Segue un elenco di nomi di metriche validi e delle
porte associate.
Nome advisor | Protocollo | Port |
---|---|---|
connessione | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (via Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10,007 |
activeconn | n/d | n/d |
connrate | n/d | n/d |
cpuload | n/d | n/d |
memload | n/d | n/d |
Esempi
nalcontrol service add sc1:svc1 vsid 1 vport 80
nalcontrol service metrics sc1:svc1 activeconn 50 http 50
nalcontrol service report sc1:svc1
Questo comando produce un output simile a:
Service sc1:svc1 Weightbound = 48 Metric activeconn has proportion 50 Metric connrate has rpoportion 50 Contains Server 4 Contains Server 3 Contains Server 2 Contains Server 1
nalcontrol service set sc1:svc1 metric http requeststring getLastErrorCode
L'interfaccia utente grafica (GUI) di Load Balancer visualizza sul lato sinistro del pannello la struttura ad albero con Load Balancer nel livello superiore e Dispatcher, CBR (Content Based Routing), Site Selector, Cisco CSS Controller e Nortel Alteon Controller elencati come componenti.
Tutti i componenti possono essere configurati dalla GUI. È possibile selezionare gli elementi della struttura ad albero con il primo pulsante del mouse (in genere, il pulsante sinistro) e visualizzare i menu a comparsa con l'altro pulsante (in genere, il pulsante destro). I menu a comparsa degli elementi della struttura ad albero sono accessibili anche dalla barra dei menu situata in alto sul pannello.
Fare clic sul segno più (+) o meno (-) per espandere o comprimere gli elementi della struttura ad albero.
Per eseguire un comando dalla GUI: evidenziare il nodo Host dalla struttura ad albero della GUI e selezionare Send command.... dal relativo menu a comparsa. Nel campo di immissione dei comandi, digitare il comando che si desidera eseguire, ad esempio: executor report. I risultati e la cronologia dei comandi in esecuzione nella sessione corrente vengono visualizzati nella finestra fornita.
Sul lato destro del pannello vengono visualizzate le schede degli indicatori di stato per l'elemento correntemente selezionato.
Per accedere all'Help, fare clic sul punto interrogativo (?) nell'angolo superiore destro della finestra di Load Balancer.
Questa appendice descrive come utilizzare la sintassi della regola di contenuto (modello) per il componente CBR e per il metodo di inoltro cbr del componente Dispatcher e contiene scenari ed esempi di uso.
Applicabile solo se È stato selezionato "content" per il tipo di regola.
Immettere la sintassi modello che si desidera utilizzare, con le seguenti restrizioni:
Le parole chiave riservate sono sempre seguite da un segno uguale "=".
Un browser che punta a http://www.company.com/path/webpage.htm potrebbe avere valori analoghi a quelli seguenti:
Method=GET URI=/path/webpage.htm Version=HTTP/1.1 Host=www.company.com Connection=Keep-Alive Referer=http://www.company.com/path/parentwebpage.htm
Ad esempio, il seguente comando è valido solo quando si utilizza il prompt cbrcontrol>> o da un file di configurazione.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
Quando si utilizzano i caratteri speciali, affinché questo stesso comando funzioni sul prompt del sistema operativo, è necessario aggiungere le doppie virgolette (" ") intorno all'intero comando:
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*"
Se non si utilizzano le virgolette, è possibile che il modello venga troncato quando la regola viene salvata nel componente CBR.
Di seguito viene riportata una raccolta di scenari possibili e di esempi di uso delle sintassi modello.
Scenario 1
La configurazione per un nome cluster prevede un gruppo di server Web per il contenuto HTML standard, un secondo gruppo di server Web che comprenda WebSphere Application Server per le richieste servlet, un terzo gruppo di server Lotus(R) Notes(R) per i file NSF e così via. È necessario accedere ai dati client per distinguere queste pagine richieste. È anche necessario inviarli ai server appropriati. Le regole di corrispondenza dei contenuti forniscono la separazione necessaria per completare queste attività. Viene inoltre configurata una serie di regole in modo che la necessaria separazione delle richieste venga eseguita automaticamente. Ad esempio, i seguenti comandi consentono di effettuare le tre suddivisioni menzionate:
>>rule add cluster1:80:servlets type content pattern "uri=*/servlet/*" priority 1 >>rule uses cluster1:80:servlets server1+server2
>>rule add cluster1:80:notes type content pattern "uri=*.nsf*" priority 2 >>rule uses cluster1:80:notes server3+server4
>>rule add cluster1:80:regular type true priority 3 >>rule uses cluster1:80:regular server5+server6
Se a Load Balancer arriva una richiesta per un file NSF, viene controllata per prima la regola dei servlet, che non offre alcuna corrispondenza. La richiesta è quindi controllata dalla regola di Notes che restituisce una corrispondenza. Il carico del client viene bilanciato tra il server3 e il server4.
Scenario 2
Un altro scenario comune È un sito Web principale che controlla numerosi gruppi interni distinti. Ad esempio, www.company.com/software comporta un gruppo di server diversi e il contenuto della sezione www.company.com/hardware . Poiché le richieste si basano tutte sul cluster root www.company.com , le regole di contenuto sono necessarie per trovare le differenze di URI e completare il bilanciamento del carico. La regola dello scenario È simile a quanto segue:
>>rule add cluster1:80:div1 type content pattern "uri=/software/*" priority 1 >>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2 >>rule uses cluster1:80:div2 server3+server4
Scenario 3
Alcune combinazioni sono sensibili all'ordine in cui le regole vengono ricercate. Ad esempio, nello scenario 2, i client erano suddivisi in base a una directory del percorso delle rispettive richieste; tuttavia, la directory di destinazione potrebbe comparire a più livelli del percorso e comportare conseguenze diverse nel posizionamento. Ad esempio, www.company.com/pcs/fixes/software È una destinazione diversa da www.company.com/mainframe/fixes/software . Le regole devono essere definite sull'account per questa possibilità e non prevedere troppi scenari contemporaneamente. Ad esempio, il test uri=*/software/* in questo caso contiene troppi caratteri jolly e comporterebbe una ricerca troppo vasta. Delle regole alternative potrebbero essere strutturate nel seguente modo:
Una ricerca combinata può restringere il campo di ricerca:
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)" >>rule uses cluster 1:80:pcs server1
In caso non sia possibile utilizzare le combinazioni disponibili, diventa importante l'ordine:
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*" >>rule uses cluster1:80:pc1 server2
La seconda regola interviene quando "pcs" compare nelle posizioni successive di directory anziché nella prima.
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*" >>rule uses cluster1:80:pc2 server3
In quasi tutti i casi, è possibile completare le regole con una regola sempre true predefinita da applicare in tutti i casi in cui non possono essere applicate le altre regole. Questa potrebbe essere anche un server del tipo "Spiacenti, impossibile al momento collegarsi al sito, provare di nuovo" per scenari in cui tutti gli altri server non riescono a soddisfare la richiesta di questo client.
>>rule add cluster1:80:sorry type true priority 100 >>rule uses cluster1:80:sorry server5
Questo appendice contiene i file di configurazione di esempio per il componente Dispatcher di Load Balancer.
I file di esempio sono posizionati nella directory ...ibm/edge/lb/servers/samples/.
#!/bin/bash
#
# configuration.sample - File di configurazione di esempio per il
Componente Dispatcher
#
#
# Accertarsi che l'utente root sia l'utente che esegue lo script.
#
# iam=`whoami`
# if [ "$iam" != "root" ]if [ "$iam" != "root" ]
# then
# echo "You must login as root to run this script"
# exit 2
# fi
#
# In primo luogo, avviare il server
#
# dsserver start
# sleep 5
#
# Quindi, avviare l'executor
#
# dscontrol executor start
#
# Il Dispatcher può essere eliminato in qualsiasi momento utilizzando
# "i comandi "dscontrol executor stop" e "dsserver stop" per
# arrestare rispettivamente l'executor e il server prima di rimuovere
# il software di Dispatcher.
#
# Il passo successivo nella configurazione di Dispatcher è impostare
# l'indirizzo NFA (indirizzo di non inoltro) e gli indirizzi cluster.
#
# L'NFA viene utilizzato per accedere in remoto alla macchina Dispatcher
# a scopi di amministrazione o configurazione. Questo
# indirizzo è necessario in quanto il Dispatcher inoltrerà i pacchetti
# agli indirizzi cluster.
#
# L'indirizzo CLUSTER è il nome host (o l'indirizzo IP) a cui
# si collegano i client remoti.
#
# In qualunque punto di questo file, si i nomi host e gli
# indirizzi IP sono intercambiabili.
#
# NFA=hostname.domain.name
# CLUSTER=www.yourcompany.com
# echo "Loading the non-forwarding address"
# dscontrol executor set nfa $NFA
#
# Il passo successivo nella configurazione di Dispatcher è creare
# un cluster. Il Dispatcher instrada le richieste inviate
# all'indirizzo cluster alle macchine server corrispondenti
# definite per quel cluster. È possibile configurare e utilizzare
# più indirizzi cluster tramite Dispatcher.
# Utilizzare una configurazione simile per CLUSTER2, CLUSTER3 ecc.
#
# echo "Loading first CLUSTER address "
# dscontrol cluster add $CLUSTER
#
# Ora occorre definire le porte che saranno utilizzate da questo cluster.
# Qualsiasi richiesta ricevuta da Dispatcher su una porta definita verrà
# inoltrata alla porta corrispondente di una delle macchine
# server.
#
# echo "Creating ports for CLUSTER: $CLUSTER"
# dscontrol port add $CLUSTER:20+21+80
#
# L'ultimo passo consiste nell'aggiungere ciascuna macchina server
# alle porte di questo cluster.
# L'ultimo passo consiste nell'aggiungere ciascuna macchina server
# l'indirizzo IP delle macchine server.
#
# SERVER1=server1name.domain.name
# SERVER2=server2name.domain.name
# SERVER3=server3name.domain.name
# echo "Adding server machines"
# dscontrol server add $CLUSTER:20+21+80:
# $SERVER1+$SERVER2+$SERVER3
#
# Si avviano ora i componenti di bilanciamento del carico di
# Dispatcher. Il componente principale viene definito
# gestore e i componenti secondari advisor.
# Se il gestore e gli advisor non sono in esecuzione,
# Dispatcher invia le richieste in formato round-robin. Dopo aver
# avviato il gestore, vengono prese le decisioni sul calcolo dei pesi,
# in base al numero di connessioni nuove e di connessioni attive, e le richieste
# in entrata sono inviate al server considerato più adatto. Gli advisor
# forniscono al gestore ulteriori informazioni sulla capacità di un
# server di ricevere le richieste e rilevano se un server è attivo.
# Se un advisor rileva un server inattivo, lo contrassegna
# come tale (a condizione che le proporzioni del gestore siano state impostate
# in modo da includere l'input dell'advisor) e nessuna ulteriore richiesta
# sarà instradata verso quel server.
# L'ultimo passo nella configurazione dei componenti di bilanciamento
# del carico consiste nell'impostare le proporzioni del gestore. Il gestore
# aggiorna il peso di ciascun server in base a quattro politiche:
# 1. Il numero delle connessioni attive su ciascun server.
# 2. Il numero delle nuove connessioni a ciascun server.
# 3. L'input proveniente dagli advisor.
# 4. L'input proveniente dagli advisor del sistema.
# La somma di tali proporzioni deve essere 100. Ad esempio,
# se si impostano le proporzioni del gestore su
# dscontrol manager proportions 48 48 0 0
# le connessioni attive e nuove rappresenteranno il 48% nella
# decisione sul calcolo dei pesi, gli advisor contribuiranno nella
# misura del 4% e l'input del sistema non verrà preso in considerazione.
#
# NOTA: per impostazione predefinita, le proporzioni del gestore sono impostate a 50 50 0 0
#
# echo "Starting the manager..."
# dscontrol manager start
# echo "Starting the FTP advisor on port 21 ..."
# dscontrol advisor start ftp 21
# echo "Starting the HTTP advisor on port 80 ..."
# dscontrol advisor start http 80
# echo "Starting the Telnet advisor on port 23 ..."
# dscontrol advisor start telnet 23
# echo "Starting the SMTP advisor on port 25 ..."
# dscontrol advisor start smtp 25
# echo "Starting the POP3 advisor on port 110 ..."
# dscontrol advisor start pop3 110
# echo "Starting the NNTP advisor on port 119 ..."
# dscontrol advisor start nntp 119
# echo "Starting the SSL advisor on port 443 ..."
# dscontrol advisor start ssl 443
#
# echo "Setting the manager proportions..."
# dscontrol manager proportions 58 40 2 0
#
# Il passo finale nella configurazione della macchina Dispatcher è creare
# l'alias della scheda di interfaccia di rete(NIC).
#
# NOTA: NON utilizzare questo comando in un ambiente con la funzione
# di disponibilità elevata abilitata. Gli script go* configureranno
# la NIC e il loopback come necessario.
# dscontrol executor configure $CLUSTER
# Se l'indirizzo cluster si trova su una NIC o sottorete diversa
da quella di NFA utilizzare il seguente formato per il cluster
di configurazione del cluster.
# dscontrol executor configure $CLUSTER tr0 0xfffff800
# dove tr0 è la NIC (tr1 per la seconda scheda token ring,
# en0 per la prima scheda ethernet) e 0xfffff800 è una
# subnet mask valida per questo sito.
#
#
# I seguenti comandi sono impostati sui valori predefiniti.
# Utilizzare questi comandi come guida per modificare i valori predefiniti.
# dscontrol manager loglevel 1
# dscontrol manager logsize 1048576
# dscontrol manager sensitivity 5
# dscontrol manager interval 2
# dscontrol manager refresh 2
#
# dscontrol advisor interval ftp 21 5
# dscontrol advisor loglevel ftp 21 1
# dscontrol advisor logsize ftp 21 1048576
# dscontrol advisor timeout ftp 21 unlimited
# dscontrol advisor interval telnet 23 5
# dscontrol advisor loglevel telnet 23 1
# dscontrol advisor logsize telnet 23 1048576
# dscontrol advisor timeout telnet 23 unlimited
# dscontrol advisor interval smtp 25 5
# dscontrol advisor loglevel smtp 25 1
# dscontrol advisor logsize smtp 25 1048576
# dscontrol advisor timeout smtp 25 unlimited
# dscontrol advisor interval http 80 5
# dscontrol advisor loglevel http 80 1
# dscontrol advisor logsize http 80 1048576
# dscontrol advisor timeout http 80 unlimited
# dscontrol advisor interval pop3 110 5
# dscontrol advisor loglevel pop3 110 1
# dscontrol advisor logsize pop3 110 1048576
# dscontrol advisor timeout pop3 110 unlimited
# dscontrol advisor interval nntp 119 5
# dscontrol advisor loglevel nntp 119 1
# dscontrol advisor logsize nntp 119 1048576
# dscontrol advisor timeout nntp 119 unlimited
# dscontrol advisor interval ssl 443 5
# dscontrol advisor loglevel ssl 443 1
# dscontrol advisor logsize ssl 443 1048576
# dscontrol advisor timeout ssl 443 unlimited
#
Di seguito viene riportato un file di configurazione di esempio di Load Balancer denominato configuration.cmd.sample da utilizzare in Windows.
@echo off rem configuration.cmd.sample - File di configurazione di esempio per il rem componente Dispatcher. rem rem dsserver deve essere avviato dal pannello Servizi rem rem rem Quindi, avviare l'executor rem rem call dscontrol executor start rem rem Il passo successivo nella configurazione di Dispatcher è impostare rem l'indirizzo NFA (indirizzo di non inoltro) e impostare gli rem indirizzi cluster. rem rem L'NFA viene utilizzato per accedere in remoto alla macchina Dispatcher rem a scopi di amministrazione o configurazione. Questo rem indirizzo è necessario in quanto il Dispatcher inoltrerà i pacchetti rem i pacchetti agli indirizzi cluster. rem rem L'indirizzo CLUSTER è il nome host (o l'indirizzo IP) a cui rem si collegano i client remoti. rem rem In qualunque punto di questo file, i nomi host e gli rem indirizzi IP sono intercambiabili. rem NFA=[Non-forwarding address] rem CLUSTER=[your clustername] rem rem set NFA=hostname.domain.name rem set CLUSTER=www.yourcompany.com rem echo "Loading the non-forwarding address" rem call dscontrol executor set nfa %NFA% rem rem I seguenti comandi sono impostati sui valori predefiniti. rem Utilizzare questi comandi per modificare i valori predefiniti. rem call dscontrol executor set fintimeout 30 rem rem Il passo successivo nella configurazione di Dispatcher è creare rem un cluster. Il Dispatcher instrada le richieste inviate rem all'indirizzo cluster alle macchine server corrispondenti rem definite per quel cluster. È possibile configurare e utilizzare rem più indirizzi cluster tramite Dispatcher. rem Utilizzare una configurazione simile per CLUSTER2, CLUSTER3 ecc. rem rem echo "Loading first CLUSTER address " rem call dscontrol cluster add %CLUSTER% rem rem Ora occorre definire le porte che saranno utilizzate da questo cluster. rem Qualsiasi richiesta ricevuta da Dispatcher su una porta definita verrà rem inoltrata alla porta corrispondente rem di una delle macchine server. rem rem echo "Creating ports for CLUSTER: %CLUSTER%" rem call dscontrol port add %CLUSTER%:20+21+80 rem rem L'ultimo passo consiste nell'aggiungere ciascuna macchina server rem alle porte di questo cluster. Anche in questo caso, è possibile utilizzare rem il nome host o l'indirizzo IP delle macchine server. rem rem set SERVER1=server1name.domain.name rem set SERVER2=server2name.domain.name rem set SERVER3=server3name.domain.name rem echo "Adding server machines" rem call dscontrol server add %CLUSTER%:20+21+80: rem %SERVER1%+%SERVER2%+%SERVER3% rem rem Si avviano ora i componenti di bilanciamento del carico di rem Dispatcher. Il componente principale viene definito rem gestore e i componenti secondari advisor. rem Se il gestore e gli advisor non sono in esecuzione, rem Dispatcher invia le richieste in formato round-robin. Dopo aver rem avviato il gestore, vengono prese le decisioni sul calcolo dei pesi, rem in base al numero di connessioni nuove e di connessioni attive, e le richieste rem in entrata sono inviate al server considerato più adatto. Gli advisor rem forniscono al gestore ulteriori informazioni rem sulla capacità di un server di ricevere le richieste e rem rilevano se un server è attivo. rem Se un advisor rileva un server inattivo, lo contrassegna come tale rem (a condizione che le proporzioni del gestore siano state impostate rem in modo da includere l'input dell'advisor) e nessuna ulteriore richiesta sarà rem instradata verso quel server. rem L'ultimo passo nella configurazione dei componenti di bilanciamento rem del carico consiste nell'impostare le proporzioni del gestore. Il rem gestore aggiorna il peso di ciascun server in base rem a quattro politiche: rem 1. Il numero delle connessioni attive su ciascun server. rem 2. Il numero delle nuove connessioni a ciascun server. rem 3. L'input proveniente dagli advisor. rem 4. L'input proveniente dagli advisor del sistema. rem rem La somma di tali proporzioni deve essere 100. Ad esempio, rem impostando le proporzioni del cluster mediante rem dscontrol cluster set <cluster> proportions 48 48 4 0 rem le connessioni attive e nuove rappresenteranno il 48% nella rem decisione sul calcolo dei pesi, l'advisor contribuirà nella rem misura del 4% e l'input del sistema non verrà preso in considerazione. rem rem NOTA: per impostazione predefinita, le proporzioni del gestore sono impostate su rem 50 50 0 0 rem echo "Starting the manager..." rem call dscontrol manager start rem echo "Starting the FTP advisor on port 21 ..." rem call dscontrol advisor start ftp 21 rem echo "Starting the HTTP advisor on port 80 ..." rem call dscontrol advisor start http 80 rem echo "Starting the Telnet advisor on port 23 ..." rem call dscontrol advisor start telnet 23 rem echo "Starting the SMTP advisor on port 25 ..." rem call dscontrol advisor start smtp 25 rem echo "Starting the POP3 advisor on port 110 ..." rem call dscontrol advisor start pop3 110 rem echo "Starting the NNTP advisor on port 119 ..." rem call dscontrol advisor start nntp 119 rem echo "Starting the SSL advisor on port 443 ..." rem call dscontrol advisor start ssl 443 rem rem echo "Setting the cluster proportions..." rem call dscontrol cluster set %CLUSTER% proportions 58 40 2 0 rem rem Il passo finale nella configurazione della macchina Dispatcher è creare rem l'alias della scheda di interfaccia di rete (NIC). rem rem NOTA: NON utilizzare questo comando in un ambiente con la funzione rem di disponibilità elevata abilitata. Gli script go* configureranno rem la NIC e il loopback come necessario. rem rem dscontrol executor configure %CLUSTER% rem Se l'indirizzo cluster si trova su una NIC o sottorete diversa rem da quella di NFA utilizzare il seguente formato per il cluster rem di configurazione del cluster. rem dscontrol executor configure %CLUSTER% tr0 0xfffff800 rem dove tr0 è la NIC (tr1 per la seconda scheda token ring, rem en0 per la prima scheda ethernet) e 0xfffff800 è una rem subnet mask valida per questo sito. rem rem rem I seguenti comandi sono impostati sui valori predefiniti. rem Utilizzare questi comandi come guida per modificare i valori predefiniti. rem call dscontrol manager loglevel 1 rem call dscontrol manager logsize 1048576 rem call dscontrol manager sensitivity 5 rem call dscontrol manager interval 2 rem call dscontrol manager refresh 2 rem rem call dscontrol advisor interval ftp 21 5 rem call dscontrol advisor loglevel ftp 21 1 rem call dscontrol advisor logsize ftp 21 1048576 rem call dscontrol advisor timeout ftp 21 unlimited rem call dscontrol advisor interval telnet 23 5 rem call dscontrol advisor loglevel telnet 23 1 rem call dscontrol advisor logsize telnet 23 1048576 rem call dscontrol advisor timeout telnet 23 unlimited rem call dscontrol advisor interval smtp 25 5 rem call dscontrol advisor loglevel smtp 25 1 rem call dscontrol advisor logsize smtp 25 1048576 rem call dscontrol advisor timeout smtp 25 unlimited rem call dscontrol advisor interval http 80 5 rem call dscontrol advisor loglevel http 80 1 rem call dscontrol advisor logsize http 80 1048576 rem call dscontrol advisor timeout http 80 unlimited rem call dscontrol advisor interval pop3 110 5 rem call dscontrol advisor loglevel pop3 110 1 rem call dscontrol advisor logsize pop3 110 1048576 rem call dscontrol advisor timeout pop3 110 unlimited rem call dscontrol advisor interval nntp 119 5 rem call dscontrol advisor loglevel nntp 119 1 rem call dscontrol advisor logsize nntp 119 1048576 rem call dscontrol advisor timeout nntp 119 unlimited rem call dscontrol advisor interval ssl 443 5 rem call dscontrol advisor loglevel ssl 443 1 rem call dscontrol advisor logsize ssl 443 1048576 rem call dscontrol advisor timeout ssl 443 unlimited rem
Di seguito è riportato un file advisor di esempio denominato ADV_sample.
/**
* ADV_sample: L'advisor HTTP di Load Balancer
*
*
* Questa classe definisce un advisor personalizzato di esempio per .
* Analogamente a
tutti gli advisor, questo advisor personalizzato estende la funzione
* dell'advisor di base,
denominato ADV_Base. L'advisor di base esegue effettivamente
* la maggior parte delle
* funzioni dell'advisor, come ad esempio l'invio dei carichi
* da utilizzare nell'algoritmo di valutazione di Load Balancer. L'advisor di base
* effettua le operazioni di connessione e chiusura del socket e fornisce i metodi di invio e di ricezione
all'advisor. L'advisor stesso viene utilizzato
* esclusivamente per l'invio e la ricezione dei dati a e dalla porta sul server
* esaminato. I metodi TCP forniti con l'advisor di base sono programmati per calcolare
* il carico. Se necessario, un'indicatore all'interno del costruttore dell'advisor
* di base sostituisce il carico esistente con il nuovo carico restituito dall'advisor.
*
* Nota: in base al valore impostato nel costruttore, l'advisor di base fornisce
* il carico all'algoritmo di valutazione a intervalli specifici. Se
* l'advisor effettivo non è stato completato in modo che restituisca un carico valido,
* l'advisor di base utilizza il carico precedente.
*
* NAMING
*
* La convenzione di denominazione è la seguente:
*
* - Il file deve trovarsi nella seguente directory Load Balancer:
*
* lb/servers/lib/CustomAdvisors/ (lb\servers\lib\CustomAdvisors su Windows)
*
* - Il nome Advisor deve essere preceduto da "ADV_". Tuttavia, è possibile
* avviare l'advisor solo con il nome; ad esempio, l'advisor "ADV_sample"
* può essere avviato con "sample".
*
* - Il nome dell'advisor deve avere caratteri minuscoli.
*
* Quindi, tenendo presente quanto riportato sopra, questo esempio viene definito:
*
* <base directory>/lib/CustomAdvisors/ADV_sample.class
*
*
* Gli advisors, come tutti i componenti restanti di Load Balancer, devono essere
* compilati con la versione prereq di Java. Per garantire l'accesso alle classi Load Balancer,
* verificare che il file ibmlb.jar (situato nella sottodirectory lib della directory
* di base) sia incluso nel CLASSPATH del sistema.
*
* Metodi forniti da ADV_Base:
*
* - ADV_Base (Costruttore):
*
* - Parametri
* - String sName = Nome dell'advisor
* - String sVersion = Versione dell'advisor
* - int iDefaultPort = Numero porta predefinita su cui effettuare l'esame
* - int iInterval = Intervallo durante il quale eseguire l'esame dei server
* - String sDefaultName = Non utilizzato. Deve essere inviato come "".
* - boolean replace = True - sostituisce il valore del carico calcolato
* dall'advisor di base
* False - aggiunge il valore del carico calcolato
* dall'advisor di base
* - Valori di ritorno
* - I costruttori non hanno valori di ritorno.
*
* Poiché l'advisor di base è basato sul thread, sono disponibili
* altri metodi a cui è possibile fare riferimento utilizzando
* il parametro CALLER inviato in getLoad().
*
* Questi metodi sono:
*
* - send - Invia un package di informazioni sulla connessione socket stabilita
* al server sulla porta specificata.
* - Parametri
* - String sDataString - I dati da inviare sotto forma di una stringa
* - Valori di ritorno
* - int RC - Invio dei dati riuscito o meno: zero indica che
* i dati sono stati inviati; un valore intero negativo indica un errore.
*
* - receive - Riceve le informazioni dalla connessione socket connection.
* - Parametri
* - StringBuffer sbDataBuffer - I dati ricevuti durante la chiamata di ricezione
* - Valori di ritorno
* - int RC - Ricezione dei dati riuscita o meno; zero
* indica che i dati sono stati inviati; un valore intero negativo indica
* un errore.
*
* Se la funzione fornita dall'advisor di base non è sufficiente,
* è possibile creare la funzione adeguata nell'advisor e
* i metodi forniti dall'advisor di base verranno ignorati.
*
* Una domanda importante sul carico restituito è se applicare
* tale carico a quello generato nell'advisor di base
* oppure se sostituirlo; sono presenti istanze valide di entrambe le situazioni.
*
* Questo esempio corrisponde essenzialmente all'advisor HTTP di Load Balancer. Il funzionamento
* è molto semplice: viene emessa una richiesta di invio--una richiesta head http. Quando viene
* ricevuta la risposta, il metodo getLoad termina, indicando all'advisor
* di base di arrestare la sincronizzazione della richiesta. Il metodo è quindi completo. Le
* informazioni restituite non vengono analizzate; il carico si basa sul tempo
* necessario per eseguire le operazioni di invio e ricezione.
*/
package CustomAdvisors;
import com.ibm.internet.nd.advisors.*;
public class ADV_sample extends ADV_Base implements ADV_MethodInterface {
String COPYRIGHT =
"(C) Copyright IBM Corporation 1997, All Rights Reserved.\n";
static final String ADV_NAME ="Sample";
static final int ADV_DEF_ADV_ON_PORT = 80;
static final int ADV_DEF_INTERVAL = 7;
// Nota: la maggior parte dei protocolli del server richiede un ritorno a capo ("\r")
// e un avanzamento riga ("\n") alla fine dei messaggi. In questo caso, includerli
// nella stringa.
static final String ADV_SEND_REQUEST =
"HEAD / HTTP/1.0\r\nAccept: */*\r\nUser-Agent: " +
"IBM_Load_Balancer_HTTP_Advisor\r\n\r\n";
/**
* Costruttore.
*
* Parametri: Nessuno ma il costruttore per ADV_Base ha diversi parametri
* che devono essere inviati.
*
*/
public ADV_sample() {
super( ADV_NAME,
"2.0.0.0-03.27.98",
ADV_DEF_ADV_ON_PORT,
ADV_DEF_INTERVAL,
"", // non utilizzato
false);
super.setAdvisor( this );
}
/**
* ADV_AdvisorInitialize
*
* Qualsiasi inizializzazione specifica dell'advisor che deve essere effettuata
* in seguito all'avvio dell'advisor di base. Questo metodo viene richiamato solo
* una volta e, generalmente, non viene utilizzato.
*/
public void ADV_AdvisorInitialize()
{
return;
}
/**
* getLoad()
*
* Questo metodo viene chiamato dall'advisor di base per completare il funzionamento
* dell'advisor, in base ai dettagli specifici del protocollo. In questo advisor
* di esempio, è necessaria solo una singola operazione di invio e di ricezione; in
* caso di logiche più complesse, è possibile emettere più operazioni di invio e
* ricezione. Adesempio, una risposta potrebbe essere ricevuta e analizzata. In base alle
* informazioni apprese, potrebbe essere emessa un'altra operazione di invio e di ricezione.
*
* Parametri:
*
* - iConnectTime - Il carico corrente poiché fa riferimento al tempo impiegato
* per completare la connessione al server attraverso
* la porta specificata.
*
* - caller - Un riferimento alla classe dell'advisor di base in cui i metodi forniti da Load
* Balancer devono eseguire richieste TCP semplici,
* principalmente l'invio e la ricezione.
*
* Risultati:
*
* - Carico - Un valore, espresso in millisecondi, che può essere aggiunto
* o sostituito al carico esistente, come specificato
* dall'indicatore "replace" del costruttore.
*
* Più è grande il carico e maggiore sarà il tempo necessario al server per rispondere;
* quindi, il peso all'interno di Load Balancer verrà ridotto.
*
* Se il valore è negativo, potrebbe essersi verificato un errore. Un errore proveniente
* da un advisor indica che il server che sta tentando di raggiungere non
* è accessibile ed è stato individuato come disattivo. Load Balancer
* non tenterà di eseguire il bilanciamento del carico su un server disattivo.
* riprenderà tale operazione quando riceverà un valore positivo da tale server.
*
*/
public int getLoad(int iConnectTime, ADV_Thread caller) {
int iRc;
int iLoad = ADV_HOST_INACCESSIBLE; // -1
// Per inviare la richiesta tcp
iRc = caller.send(ADV_SEND_REQUEST);
if (iRc >= 0)
{
// Per eseguire una ricezione
StringBuffer sbReceiveData = new StringBuffer("");
iRc = caller.receive(sbReceiveData);
/**
* In modalità advisor normale (l'indicatore "replace" è false), il carico
* restituito è 0 o 1 a seconda se il server è attivo o meno.
* Se la ricezione è avvenuta con esito positivo, viene restituito un carico con valore
* zero che indica che è necessario utilizzare il carico creato nell'advisor di base.
*
* Altrimenti (l'indicatore "replace" è true), viene restituito il valore di carico
* desiderato.
*/
if (iRc >= 0)
{
iLoad = 0;
}
}
return iLoad;
}
} // Fine - ADV_sample
Questa appendice descrive come impostare una configurazione di disponibilità elevata a due livelli combinando le funzioni di due componenti di Load Balancer (il componente Dispatcher e il componente CBR) con Caching Proxy.
La configurazione della macchina server per la Figura 46 è la seguente:
La Figura 46 mostra una rappresentazione grafica di più server (EdgeServer1, EdgeServer2, EdgeServer3) che eseguono il bilanciamento del carico tra più server Web di backend. Il componente CBR utilizza Caching Proxy per inoltrare le richieste in base al contenuto dell'URL ai server Web di backend. Il componente Dispatcher viene utilizzato per bilanciare il carico dei componenti CBR tra gli EdgeServer. La funzione di disponibilità elevata del componente Dispatcher viene utilizzata per garantire che le richieste del server di backend continuino ad essere elaborate anche se la macchina principale con disponibilità elevata (EdgeServer1) dovesse subire un malfunzionamento.
Linee guida per la configurazione di base:
Caching ON CacheMemory 128000 K ReversePass /* http://websrvA.company.com/* http://www.company.com/*
File di configurazione di esempio:
I seguenti file di configurazione di esempio sono analoghi ai file creati quando si imposta la configurazione di Edge Components come mostrato nella Figura 46. I file di configurazione di esempio rappresentano i file per i componenti Dispatcher e CBR di Load Balancer. Nella configurazione di esempio, viene utilizzato un unico adattatore Ethernet per ciascuna macchina EdgeServer e tutti gli indirizzi sono rappresentati da una sottorete privata. I file di configurazione di esempio utilizzano i seguenti indirizzi IP per le macchine specificate:
File di configurazione di esempio per il componente Dispatcher sull'EdgeServer principale con disponibilità elevata:
dscontrol executor start dscontrol cluster add 192.168.1.11 primaryhost 192.168.1.10 dscontrol port add 192.168.1.11:80 dscontrol server add 192.168.1.11:80:edgeserver1 address 192.168.1.10 dscontrol server add 192.168.1.11:80:edgeserver2 address 192.168.1.20 dscontrol server add 192.168.1.11:80:edgeserver3 address 192.168.1.30 dscontrol manager start manager.log 10004 dscontrol highavailability heartbeat add 192.168.1.10 192.168.1.20 dscontrol highavailability backup add primary auto 4567
File di configurazione di esempio per il componente CBR sugli EdgeServer:
cbrcontrol set loglevel 1 cbrcontrol executor start cbrcontrol cluster add 192.168.1.11 cbrcontrol port add 192.168.1.11:80 cbrcontrol server add 192.168.1.11:80:webserverA address 192.168.1.71 cbrcontrol server add 192.168.1.11:80:webserverB address 192.168.1.72 cbrcontrol server add 192.168.1.11:80:webserverC address 192.168.1.73 cbrcontrol rule add 192.168.1.11:80:webA_rule type content pattern (URI=*WSA*)|(URI=*wsA*) priority 21 cbrcontrol rule useserver 192.168.1.11:80:webA_rule webserverA cbrcontrol rule add 192.168.1.11:80:webB_rule type content pattern (URI=/WS_B*) priority 22 cbrcontrol rule useserver 192.168.1.11:80:webB_rule webserverB cbrcontrol rule add 192.168.1.11:80:webC_rule type content pattern URI=*webC* priority 23 cbrcontrol rule useserver 192.168.1.21:80:webC_rule webserverC
Queste informazioni sono state sviluppate per prodotti e servizi offerti negli Stati Uniti d'America.
IBM può non offrire i prodotti, i servizi o le funzioni presentati in questo documento in altri paesi. Consultare il proprio rappresentante locale IBM per informazioni sui prodotti ed i servizi attualmente disponibili nella propria zona. Qualsiasi riferimento ad un prodotto, programma o servizio IBM non implica o intende dichiarare che solo quel prodotto, programma o servizio IBM può essere utilizzato. Qualsiasi prodotto funzionalmente equivalente al prodotto, programma o servizio che non violi alcun diritto di proprietà intellettuale IBM può essere utilizzato. È tuttavia responsabilità dell'utente valutare e verificare la funzionalità di tali prodotti, programmi o servizi non IBM.
IBM può avere applicazioni di brevetti o brevetti in corso relativi all'argomento descritto in questo documento. La fornitura di questa pubblicazione non implica la
concessione di alcuna licenza su di essi. Chi desiderasse ricevere informazioni relative a licenze
può rivolgersi per iscritto a:
IBM Director of Licensing
IBM Corporation
500 Columbus Avenue
Thornwood, NY 10594
U.S.A.
Per richieste di licenze relative ad informazioni double-byte (DBCS), contattare
il Dipartimento di Proprietà Intellettuale IBM nel proprio paese o inviare richieste per
iscritto a:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
Il seguente paragrafo non è valido per il Regno Unito o per tutti i paesi le cui leggi nazionali siano in contrasto con le disposizioni in esso contenute:
INTERNATIONAL BUSINESS MACHINES CORPORATION FORNISCE QUESTA PUBBLICAZIONE NELLO STATO IN CUI SI TROVA SENZA ALCUNA GARANZIA, ESPLICITA O IMPLICITA, IVI INCLUSE EVENTUALI GARANZIE DI COMMERCIABILITÀ ED IDONEITÀ AD UNO SCOPO PARTICOLARE. Alcuni stati non consentono la rinuncia a garanzie esplicite o implicite in determinate transazioni, quindi, la presente dichiarazione potrebbe non essere a voi applicabile.
Questa pubblicazione potrebbe contenere imprecisioni tecniche o errori tipografici. Le informazioni incluse in questo documento vengono modificate su base periodica; tali modifiche verranno incorporate nelle nuove edizioni o nella nuova documentazione. IBM si riserva il diritto di apportare miglioramenti e/o modifiche ai prodotti e/o ai programmi descritti nel manuale in qualsiasi momento e senza preavviso.
Tutti i riferimenti a siti Web non IBM contenuti in questo documento sono forniti solo per consultazione. I materiali presenti in tali siti Web non sono parte dei materiali per questo prodotto IBM e l'utilizzo di tali siti Web è a proprio rischio.
IBM può utilizzare o distribuire qualsiasi informazione fornita in qualsiasi modo ritenga appropriato senza incorrere in alcun obbligo verso l'utente.
Coloro che detengono la licenza su questo programma e desiderano avere informazioni su
di esso allo scopo di consentire: (i) uno scambio di informazioni tra programmi
indipendenti ed altri (compreso questo) e (ii) l'uso reciproco di tali informazioni,
dovrebbero rivolgersi a:
IBM Corporation
Attn.: G7IA./503.
P.O. Box 12195
3039 Cornwallis Rd.
Research Triangle Park, N.C. 27709-2195
U.S.A.
Tali informazioni possono essere disponibili, in base ad appropriate clausole e condizioni, includendo in alcuni casi, il pagamento di una tassa.
Il programma su licenza descritto in queste informazioni e tutto il materiale su licenza ad esso relativo sono forniti da IBM nel rispetto delle condizioni previste dall'accordo IBM International Program License Agreement o da accordi equivalenti.
Tutti i dati relativi alle prestazioni contenuti in questa pubblicazione sono stati determinati in ambiente controllato. Pertanto, i risultati ottenuti in altri ambienti operativi possono notevolmente variare. Alcune misure potrebbero essere state calcolate su sistemi di livelli di sviluppo per cui non si garantisce che queste saranno uguali su tutti i sistemi disponibili. Inoltre, alcune misure potrebbero essere state ricavate mediante estrapolazione. I risultati possono quindi variare. Gli utenti del presente documento dovranno verificare i dati applicabili per i propri ambienti specifici.
Le informazioni relative a prodotti non IBM sono state ottenute dai fornitori di tali prodotti. IBM non ha testato quei prodotti e non può confermarne l'accuratezza della prestazione, la compatibilità o qualsiasi altro reclamo relativo ai prodotti non IBM. Eventuali commenti relativi alle prestazioni dei prodotti non IBM devono essere indirizzati ai fornitori di tali prodotti.
Tutte le dichiarazioni riguardanti la futura direzione o le intenzioni di IBM sono soggette a sostituzione o al ritiro senza preavviso e rappresentano unicamente scopi e obiettivi di IBM.
Queste informazioni contengono esempi di dati e report utilizzati quotidianamente nelle operazioni aziendali. Per meglio illustrarli, tali esempi contengono nomi di persone, società, marchi e prodotti. Tutti questi nomi sono fittizi e qualsiasi somiglianza con nomi ed indirizzi utilizzati da gruppi aziendali realmente esistenti è puramente casuale.
Se si stanno visualizzando queste informazioni in formato elettronico, le illustrazioni a colori e le foto potrebbero non essere visualizzate.
I seguenti termini sono marchi o marchi registrati di IBM Corporation negli Stati Uniti, in altri paesi o in entrambi.
AFS
AIX
DFS
IBM
iSeries(TM)
NetView
OS/2
Redbooks(TM)
RS/6000(R)
SecureWay
ViaVoice
WebSphere
zSeries(R)
Java e tutti i marchi basati su Java sono di Sun Microsystems, Inc. negli Stati Uniti, in altri paesi o in entrambi.
Microsoft, Windows, Windows NT, e il logo Windows sono marchi di Microsoft Corporation negli Stati Uniti e/o in altri paesi.
Intel(TM), Intel Inside (logos), MMX(TM) e Pentium(R) sono marchi di Intel Corporation negli Stati, in altri paesi o in entrambi.
UNIX è un marchio di The Open Group negli Stati Uniti e in altri paesi.
Linux è un marchio di Linus Torvalds, negli Stati Uniti, in altri paesi o in entrambi.
Altri nomi di società, prodotti o servizi possono essere marchi o marchi di servizi di altre società.