Versione 6.1
Document Number GC13-3365-02
Nota |
---|
Prima di usare questo prodotto e le relative informazioni, leggere le informazioni contenute nella sezione Appendice E, Avvertenze. |
Prima edizione (Maggio 2006)
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 IBM Corporation, 2006. Tutti i diritti riservati. Materiale su licenza - Proprietà dell'IBM
Componente Content Based Routing (CBR)
Componente Controller Cisco CSS
Componente Controller Nortel Alteon
Funzioni e caratteristiche avanzate di Load Balancer
Gestione e risoluzione dei problemi di Load Balancer
Questa guida illustra come pianificare, installare, configurare, utilizzare e risolvere i problemi di IBM WebSphere Application Server Load Balancer nei sistemi operativi AIX, HP-UX, Linux, Solaris e Windows. Precedentemente, questo prodotto era chiamato Edge Server Network Dispatcher, SecureWay Network Dispatcher, eNetwork Dispatcher, and Interactive Network Dispatcher.
La presente 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 con 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 sisto Web e collegarsi al sito Technote.
Per accedere a queste pagine Web e alle pagine correlate, utilizzare gli URL elencati in Documenti correlati e siti Web.
Le funzioni di accessibilità 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 accessibilità 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 ai componenti Edge:
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 di Load Balancer e comprende le seguenti sezioni:
Per un elenco dettagliato delle opzioni 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 entranti 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 entranti, migliorando la soddisfazione dei clienti e i profitti dell'azienda.
IMPORTANTE: se si sta utilizzando Load Balancer per IPv4 e IPv6, solo il componente Dispatcher è disponibile. Per ulteriori informazioni, consultare Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6.
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 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, Controller Cisco CSS, e Controller Nortel Alteon, 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 scala 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, Controller Cisco CSS e Controller Nortel Alteon offrono una disponibilità elevata 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 al Caching Proxy, il componente CBR può funzionare da proxy per le richieste HTTP e HTTPS (SSL) indirizzati 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 opzioni incorporate 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. La disponibilità offerta dal componente Dispatcher è ancora più elevata se si considera che le due macchine possono fungere contemporaneamente da principale e da secondaria (backup). 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 secondario 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, consultare Disponibilità elevata.
Load Balancer per IBM WebSphere Application Server Versione 6.1 contiene un certo numero di nuove opzioni. Le nuove opzioni più importanti sono elencate qui di seguito.
Il supporto è stato aggiunto alle installazioni Load Balancer per IPv4 e IPv6 per eseguire i processi di bilanciamento del carico nello spazio utente piuttosto che nello spazio kernel. Per sistemi Linux, non esiste alcuna dipendenza dal modulo kernel.
Per le informazioni più aggiornate sulle piattaforme che supportano il bilanciamento del carico nello spazio utente (senza kernel), fare riferimento al seguente sitoWeb: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Per ulteriori informazioni, vedere Piattaforme supportate per Load Balancer per IPv4 e IPv6.
Per informazioni sui 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
Il supporto per i sistemi Linux su zSeries a 64-bit è fornito solo per le installazioni Load Balancer per IPv4 e IPv6.
Per ulteriori informazioni su Load Balancer per IPv4 e IPv6 e sulle considerazioni speciali per l'esecuzione di sistemi Linux su zSeries a 64-bit, fare riferimento a Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6.
Per informazioni sui 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
Il supporto per un advisor Session Initiation Pprotocol (SIP) è stato aggiunto. L'advisor SIP supportato viene eseguito solo sul protocollo TCP.
Per ulteriori informazioni, fare riferimento a (SIPADV).
Questa funzione si applica a tutti i componenti di Load Balancer.
I client che si trovano sulla stessa macchina di Load Balancer sono supprtati solo su sistemi Linux.
Per ulteriori informazioni, vedere Utilizzo di un client posizionato.
Per informazioni sulle versioni supportate di Firefox e su tutti i browser supportati, fare riferimento al seguente sito Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Questo capitolo fornisce una panoramica dei componenti di Load Balancer e comprende le seguenti sezioni:
Per un elenco dettagliato delle opzioni 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, Controller Cisco CSS e Controller Nortel Alteon. 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.
IMPORTANTE: se si utilizza Load Balancer per IPv4 e IPv6, solo il componente Dispatcher è disponibile. Per ulteriori informazioni, vedere Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6.
Il componente Dispatcher bilancia il traffico tra i server tramite un'efficace combinazione di bilanciamento del carico e software di gestione. Inoltre, Dispatcher è 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. Dispatcher consente di 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 Dispatcher ha indirizzato la richiesta client al server più adatto, 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 dove i server sono gestiti da Dispatcher e Metric 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 dove i server locali e remoti sono gestiti da Dispatcher
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 Dispatcher 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 del Dispatcher (metodo di inoltro nat) e Supporto GRE (Generic Routing Encapsulation).
CBR funziona con Caching Proxy per inviare le richieste ai server HTTP o HTTPS (SSL) specificati tramite proxy. 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, Caching Proxy esegue la propria abituale elaborazione per inviare la richiesta al server prescelto tramite proxy.
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 dove i server locali sono gestiti da CBR
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).
Controller Cisco CSS 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 Controller Cisco CSS 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 Controller Cisco CSS per generare i pesi del servizio che vengono poi inviati a Switch Cisco CSS per la selezione del servizio più adatto, per l'ottimizzazione del carico e per la tolleranza agli errori.
Controller Cisco CSS utilizza molti criteri, tra cui:
Quando Switch Cisco CSS, senza Controller Cisco CSS, 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 Controller Cisco CSS, queste attività vengono trasferite da Switch Cisco CSS su Controller Cisco CSS. Controller Cisco CSS 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.
Controller Cisco CSS:
Controller Cisco CSS, insieme a Switch Cisco CSS, 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. Controller Cisco CSS fa parte di una soluzione complementare globale tra Switch Cisco CSS e IBM WebSphere Application Server Load Balancer.
Controller Nortel Alteon 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.
Controller Nortel Alteon 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.
Controller Nortel Alteon 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 Switch Nortel Alteon Web, tra cui:
Controller Nortel Alteon 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 dove i server locali sono gestiti da Controller Nortel Alteon
È possibile gestire il controller tramite un'interfaccia browser, una GUI remota o una riga comandi remota.
Controller Nortel Alteon, 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. Controller Nortel Alteon 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:
IMPORTANTE: se si utilizza Load Balancer per IPv4 e IPv6, solo il componente Dispatcher è disponibile. Per ulteriori informazioni, consultare Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6.
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 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 Amministrazione remota di Load Balancer.
(Se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, questa funzione non è disponibile.)
_ Per eseguire Dispatcher sulla stessa macchina di un server Web per cui si sta effettuando il bilanciamento del carico, vedere Utilizzo dei server posizionati.
_ Per utilizzare Dispatcher per eliminare la limitazione che un server diventi un "single point-of-failure", vedere Disponibilità elevata di tipo semplice e Disponibilità elevata reciproca.
(Se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, è disponibile solo la funzione semplice di disponibilità elevata e non la 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 Funzionamento della funzione di affinità di Load Balancer.
_ Per garantire che il client utilizzi lo stesso server per il traffico HTTP e SSL, vedere Affinità multiporta.
(Se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, la funzione di affinità multiporta non è disponibile.)
_ Per garantire che il client utilizzi lo stesso server per connessioni multiple, vedere Funzionamento della 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).
(Se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, la funzione stickmask non è disponibile.)
_ 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, 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, type of service).
_ 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 il totale delle 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à di client e garantire che un client non rimanga aderente a un server sovraccarico, vedere ignora affinità di porta.
Se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, il bilanciamento del carico basato sulle regole non è disponibile.
Per garantire che i client SSL ritornino sullo stesso server SSL, in base all'ID SSL della richiesta client
_ Vedere a pagina ***.
Per indirizzare i client HTTP a gruppi di server diversi utilizzando le regole di corrispondenza dei contenuti URL della richiesta client, vedere Instradamento basato sul contenuto di Dispatcher (metodo di inoltro cbr) e Utilizzo delle regole basate sul contenuto delle richieste per ulteriori informazioni.
_ Per distinguere tra i singoli URL e le relative applicazioni dei 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.
(Se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, il metodo di inoltro cbr di Dispatcher non è disponibile.)
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 del Dispatcher (metodo di inoltro nat).
(Se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, la funzione di bilanciamento del carico per una rete geografica non è disponibile.)
_ 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 del Dispatcher (metodo di inoltro nat).
(Se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, questa funzione non è disponibile.)
_ 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 dei server, vedere Uso 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 attraverso un server proxy. 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 Amministrazione 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 dei 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 i singoli URL e le relative applicazioni dei 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, 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 il totale delle 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 ritorni allo stesso server in caso di connessioni multiple, vedere Funzionamento della 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 dei server, vedere Uso 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 Amministrazione 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 richieste di server dei nomi multiple, vedere Funzionamento della funzione di affinità di Load Balancer.
_ Per garantire l'affinità dei client a un server utilizzando il metodo di impostazione DNS standard per il valore TTL (Time To Live), vedere Considerazioni su 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, 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.
Controller Cisco CSS 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 in Load Balancer
_ Advisor e Creazione di advisor personalizzati
_ Per eseguire la configurazione di Load Balancer da una macchina diversa da quella dove risiede Load Balancer, vedere Amministrazione remota di Load Balancer.
_ È possibile eseguire il componente Controller Cisco CSS 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, Switch Cisco CSS 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 dei server, vedere Uso 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.
Controller Nortel Alteon 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 in Load Balancer
_ Advisor e Creazione di advisor personalizzati
_ Per eseguire la configurazione di Load Balancer da una macchina diversa da quella dove risiede Load Balancer, vedere Amministrazione remota di Load Balancer.
_ È possibile eseguire il componente Controller Nortel Alteon 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 dei server, vedere Uso 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 pacchetti 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
Tabella 1 riporta le immagini di installp
per Load Balancer e l'ordine di installazione consigliato mediante lo
strumento di installazione dei pacchetti del sistema.
Tabella 1. immagini installp in AIX
Base | ibmlb.base.rte |
Amministrazione (con i messaggi) |
|
Driver unità | ibmlb.lb.driver |
Licenza | ibmlb.lb.license |
Componenti Load Balancer (con messaggi) |
|
Documentazione (con messaggi) |
|
Metric Server | ibmlb.ms.rte |
Dove component 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 language può essere:
Il pacchetto 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, disinstallarne la copia prima di installare la versione aggiornata. In primo luogo, accertarsi che tutti gli executor e i server siano stati arrestati. Quindi, disinstallare 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 pacchetto.
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:
Uso 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 pacchetti Load Balancer desiderati per
AIX:
Tabella 2. Comandi di installazione AIX
Base | installp -acXgd device ibmlb.base.rte |
Amministrazione (con messaggi) | installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin |
Driver unità | installp -acXgd device ibmlb.lb.driver |
Licenza | installp -acXgd device ibmlb.lb.license |
Componenti di Load Balancer (con msg). Tra i componenti sono inclusi: Dispatcher, CBR, Site Selector, Controller Cisco CSS e Controller Nortel Alteon | installp -acXgd device ibmlb.component.rte ibmlb.msg.language.lb |
Documenti (con messaggi) | installp -acXgd unità ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd device ibmlb.ms.rte |
dove per device 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 device
dove per device 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.language.admin ibmlb.msg.en_US.doc ibmlb.msg.language.lb
I percorsi di installazione di Load Balancer includono quanto segue:
Per l'amministrazione remota di Load Balancer, utilizzando il metodo RMI (Remote Method Invocation), è necessario installare i pacchetti 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 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. Quindi, per disinstallare Load Balancer, consultare Istruzioni per la disinstallazione dei pacchetti.
La Tabella 3 visualizza un elenco di nomi di pacchetti di installazione
per Load Balancer e l'ordine necessario per installarli mediante lo
strumento di installazione pacchetto del sistema.
Tabella 3. Dettagli sull'installazione del pacchetto HP-UX per Load Balancer
Descrizione pacchetto | Nome pacchetto HP-UX |
Base | ibmlb.base |
Amministrazione e messaggi | ibmlb.admin ibmlb.nlv-lang |
Licenza di Load Balancer | ibmlb.lic |
Componenti Load Balancer | ibmlb.component |
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_pacchetto
in cui origine è il percorso directory assoluto di ubicazione del pacchetto e nome_pacchetto è il nome del pacchetto.
Il comando riportato di seguito installa il pacchetto di base di Load Balancer (ibmlb.base), se l'installazione avviene dalla root del CD:
swinstall -s /origine ibmlb.base
Per installare tutti i pacchetti 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 pacchetti installati. Ad esempio,
swlist -l fileset ibmlb
Utilizzare il comando swremove per disinstallare i pacchetti. I pacchetti devono essere rimossi nell'ordine inverso rispetto all'installazione. Ad esempio, emettere i seguenti comandi:
swremove ibmlb
Per disinstallare un singolo pacchetto, 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
Questa sezione illustra come installare Load Balancer in Linux mediante un 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, 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 pacchetti di amministrazione vengano disinstallati per ultimi.
Per installare Load Balancer:
L'immagine di installazione è un file nel formato eLBLX-version:tar.z.
Di seguito è riportato un elenco dei pacchetti RPM installabili.
Dove --
Il pacchetto 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 pacchetti deve essere immesso dalla stessa directory in cui risiedono i file RPM. Per installare ciascun pacchetto, 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 l'amministrazione remota di Load Balancer, utilizzando il metodo RMI (Remote Method Invocation), È necessario installare i pacchetti 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
Questa sezione illustra 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. Quindi, per disinstallare 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 pacchetto, ad esempio: pkgadd -d /cdrom/cdrom0/.
Di seguito è riportato un elenco dei pacchetti visualizzati e l'ordine di installazione consigliato.
Il pacchetto 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 pacchetti, è sufficiente immettere "all" e premere Invio. Se si desidera installare solo alcuni componenti, immettere i nomi corrispondenti ai pacchetti 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 pacchetti 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 pacchetti: ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc e ibmlbms.
Per l'amministrazione remota di Load Balancer, utilizzando il metodo RMI (Remote Method Invocation), è necessario installare i pacchetti 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 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
Questa sezione illustra come installare Load Balancer su sistemi Windows mediante un CD del prodotto.
Viene fornita una scelta di pacchetti da installare:
Per l'amministrazione remota di Load Balancer, utilizzando il metodo RMI (Remote Method Invocation), è necessario installare i pacchetti 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 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 includono quanto segue:
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.
IMPORTANTE: se si sta utilizzando Load Balancer per IPv4 e IPv6, vedere anche Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6.
Figura 8. Una semplice configurazione 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, consultare 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.0
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 a questo punto esegue il bilanciamento del carico in base alla 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 Figura 9.
Figura 9. Esempio di 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 tal caso, è possibile definire un cluster per ogni protocollo, con una singola porta ma con molti server, come illustrato in 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 in 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:
IMPORTANTE: se si sta utilizzando Load Balancer per IPv4 e IPv6, vedere anche Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6.
Dispatcher è 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, mentre gli advisor non saranno disponibili.
Il Dispatcher fornisce inoltre degli advisor che non scambiano informazioni specifiche sul protocollo, come l'advisor DB2 che riporta lo stato dei server DB2 e l'advisor ping che comunica se il server risponde o meno a un ping. Per un elenco completo degli advisor, vedere Elenco di advisor.
È possibile anche scrivere advisor personalizzati (vedere Creazione di advisor personalizzati).
L'uso degli advisor è facoltativo ma consigliato.
Le tre funzioni chiave del Dispatcher (executor, gestore e advisor interagiscono per bilanciare e distribuire le richieste in entrata tra i server. Insieme al bilanciamento del carico delle richieste, l'executor controlla il numero delle nuove connessioni, delle connessioni attive e delle connessioni terminate. L'executor esegue inoltre la raccolta di dati inutili di connessioni completate o ripristinate e comunica tali informazioni al gestore.
Il gestore raccoglie le informazioni provenienti dall'executor, dagli advisor e da un programma di monitoraggio del sistema, quale Metric Server. In base alle informazioni ricevute, il gestore regola il peso delle macchine server su ciascuna porta e comunica all'executor i nuovi pesi da utilizzare nel bilanciamento delle nuove connessioni.
Gli advisor controllano ciascun server sulla porta assegnata, per determinare il tempo di risposta del server e la disponibilità, quindi, comunicano queste informazioni al gestore. Anche gli advisor controllano se un server è attivo o meno. Senza il gestore e gli advisor, l'executor esegue una pianificazione con il metodo round-robin basata sui pesi attuali dei server.
Con il Dispatcher, è possibile selezionare uno dei tre metodi di inoltro specificati a livello di porta: inoltro MAC, NAT/NAPT o CBR (content-based routing).
Utilizzando il metodo di inoltro MAC del Dispatcher (il metodo di inoltro predefinito), il Dispatcher bilancia il carico delle richieste in entrata al server selezionato e il server restituisce la risposta direttamente al client senza coinvolgere il Dispatcher. Con questo metodo di inoltro, il Dispatcher controlla soltanto il traffico entrante dai client verso i server e non gestisce il traffico uscente dai server verso i client. Ciò riduce significativamente il suo impatto sull'applicazione e migliora le prestazioni della rete.
Il metodo di inoltro può essere selezionato quando si aggiunge una porta con il comando dscontrol port add cluster:port method value. Il valore del metodo di inoltro predefinito è mac. Il parametro method può essere specificato solo quando si aggiunge la porta. Dopo aver aggiunto la porta, non è possibile modificare l'impostazione del metodo di inoltro. Per ulteriori informazioni, consultare 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 per l'aggiunta dell'alias loopback Linux quando si utilizza il metodo di inoltro mac di Load Balancer, che contiene un numero di soluzioni per modificare il funzionamento del sistema Linux in modo da renderlo compatibile con l'inoltro mac di Load Balancer.
Su Linux, esistono delle limitazioni quando si utilizzano server zSeries o S/390 che hanno schede Open System Adapter (OSA). Fare riferimento a Problema: su Linux, esistono delle limitazioni alla configurazione del Dispatcher quando si utilizzano server zSeries o S/390 che utilizzano schede Open System Adapter (OSA) per le eventuali soluzioni alternative.
Utilizzando la capacità NAT (Network Address Translation) o NAPT (Network Address Port Translation) del Dispatcher si elimina la limitazione che prevede di dover posizionare i server sottoposti a bilanciamento del carico su una rete collegata localmente. Se si desidera collegare server situati in ubicazioni remote, è possibile utilizzare la tecnica del metodo di inoltro NAT anziché la tecnica di incapsulamento GRE/WAN. È anche possibile utilizzare la funzione NAPT per accedere a più daemon server che risiedono su ciascuna macchina sottoposta a bilanciamento del carico, dove ogni daemon è in ascolto su una specifica porta.
È possibile configurare un server con più daemon in due modi differenti:
Questa applicazione funziona bene con protocolli di applicazioni di livello superiore come HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, ecc.
Limitazioni:
Saranno necessari tre indirizzi IP per la macchina Dispatcher - indirizzo nfa, cluster e mittente. Per implementare NAT/NAPT, effettuare quanto segue (vedere anche Operazioni di esempio per configurare i metodi di inoltro nat o cbr del Dispatcher):
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
Mappa il numero di porta (specifico per il Dispatcher) di destinazione della richiesta client sul numero di porta del server che il Dispatcher utilizza per bilanciare il carico delle richieste del client. Il parametro mapport consente a Load Balancer di ricevere una richiesta del client su una porta e di trasmetterla a una porta differente sulla macchina server. Con il parametro mapport è possibile bilanciare il carico delle richieste di un client su una macchina server che potrebbe disporre di più daemon server attivi. Il valore predefinito per mapport è il numero di porta di destinazione della richiesta client.
L'indirizzo mittente è un indirizzo univoco o un nome host configurato sulla macchina Dispatcher. Il Dispatcher utilizza l'indirizzo mittente come indirizzo di origine quando bilancia il carico delle richieste del client al server. In questo modo, il server restituisce il pacchetto alla macchina Dispatcher, anziché inviarlo direttamente al client. (Il Dispatcher inoltra quindi il pacchetto IP al client.) Quando si aggiunge il server, è necessario specificare il valore dell'indirizzo mittente. Non è possibile modificare l'indirizzo mittente, a meno il server non venga prima rimosso quindi riaggiunto. L'indirizzo mittente non può essere uguale all'indirizzo cluster, server o NFA.
L'indirizzo del router al server remoto. Se questo è un server collegato in locale, immettere l'indirizzo del server, a meno che questo non si trovi sulla stessa macchina di Load Balancer. In tal caso, continuare a utilizzare l'indirizzo reale del router.
Il componente Dispatcher consente di eseguire l'instradamento basato sul contenuto per HTTP (utilizzando la regola di tipo "contenuto") e HTTPS (utilizzando l'affinità ID di sessione SSL) senza la necessità di utilizzare Caching Proxy. Per il traffico HTTP e HTTPS, il metodo di inoltro cbr del componente Dispatcher può offrire un instradamento basato sul contenuto più rapido rispetto a quello offerto dal componente CBR, che richiede Caching Proxy.
Per HTTP: la selezione del server per l'Instradamento basato sul contenuto di Dispatcher è basata sui contenuti di un'intestazione URL o HTTP. La configurazione avviene utilizzando la regola di tipo "contenuto". Quando si configura la regola contenuto, specificare il "modello" della stringa di ricerca e un insieme di server per la regola. Durante l'elaborazione di una nuova richiesta in entrata, questa regola confronta la stringa specificata con l'URL del client o con l'intestazione HTTP specificata nella richiesta client.
Se il Dispatcher trova la stringa nella richiesta client, inoltra la richiesta a uno dei server nella regola. Il Dispatcher trasmette quindi i dati della risposta dal server al client (metodo di inoltro "cbr").
Se il Dispatcher non trova la stringa nella richiesta client, non seleziona alcun server dall'insieme dei server nella regola.
Per HTTPS (SSL): l'instradamento basato sul contenuto (cbr) del Dispatcher bilancia il carico in base al campo sessione ID SSL della richiesta client. Con SSL, una richiesta client contiene l'ID sessione SSL di una sessione precedente e i server mantengono una memoria cache delle connessioni SSL precedenti. L'affinità di sessione ID SSL del Dispatcher consente al client e al server di stabilire una nuova connessione utilizzando i parametri di sicurezza della precedente connessione al server. Eliminando la rinegoziazione dei parametri di sicurezza SSL, come le chiavi condivise e gli algoritmi di codifica, i server salvano i cicli della CPU e il client riceve una risposta più velocemente. Per abilitare l'affinità ID di sessione SSL: il tipo protocol specificato per la porta deve essere SSL e la porta stickytime deve essere impostata su un valore diverso da zero. Quando il valore di stickytime viene superato, il client potrebbe essere inviato a un server diverso dal precedente.
Saranno necessari tre indirizzi IP per la macchina Dispatcher - indirizzo nfa, cluster e mittente. Per implementare 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 value returnaddress rtrnaddress router rtraddress
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern pattern
Dove pattern specifica il modello da utilizzare per il tipo di regola content. Per ulteriori informazioni sul tipo di regola content, vedere Utilizzo delle regole basate sul contenuto delle richieste. Per ulteriori informazioni sulle espressioni valide per pattern, vedere Appendice B, Sintassi della regola di contenuto (modello).
Figura 12. Esempio d'uso dei metodi di inoltro nat o cbr del Dispatcher
Saranno necessari almeno tre indirizzi IP per la macchina Dispatcher. Per la Figura 12, le operazioni riportate di seguito sono indispensabili per configurare al minimo i metodi di inoltro nat o cbr del Dispatcher:
1.Avviare l'executor dscontrol executor start 2.Definire il gateway client dscontrol executor set clientgateway 1.2.3.5 NOTA: se la sottorete non dispone di un router locale, è necessario configurare una macchina per eseguire l'inoltro IP e utilizzarla come clientgateway. Consultare la documentazione del sistema operativo per determinare come attivare l'inoltro IP. 3.Definire l'indirizzo cluster dscontrol cluster add 1.2.3.44 4.Configurare l'indirizzo cluster dscontrol executor configure 1.2.3.44 5.Definire la porta con un metodo nat o cbr dscontrol port add 1.2.3.44:80 method nat o dscontrol port add 1.2.3.44:80 method cbr protocol http 6.Configurare un indirizzo mittente alias su Load Balancer (utilizzando la scheda ethernet 0) NOTA: su sistemi Linux, non è necessario creare un alias per l'indirizzo di restituzione se si utilizza l'inoltro nat su una macchina posizionata. dscontrol executor configure 10.10.10.99 o utilizzare il comando ifconfig (solo per Linux o UNIX): AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0 HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up 7.Definire i server backend dscontrol server add 1.2.3.4:80:192.10.10.10 router 10.10.10.6 returnaddress 10.10.10.99
Il gateway client (1.2.3.5) è l'indirizzo router 1 tra Load Balancer e il client. Il router (10.10.10.6) è l'indirizzo router 2 tra Load Balancer e il server backend. In caso di dubbi sull'indirizzo clientgateway o router 2, è possibile utilizzare un programma denominato traceroute con l'indirizzo client (o server) per determinare l'indirizzo router. La sintassi esatta di questo programma differisce in base al sistema operativo utilizzato. È preferibile consultare la documentazione del sistema operativo per ulteriori informazioni circa questo programma.
Se il server si trova sulla stessa rete di Load Balancer (ossia, non vengono restituiti router mediante traceroute), specificare l'indirizzo server come indirizzo router. Tuttavia, se il server si trova sulla stessa macchina di Load Balancer, nel campo del router va immesso l'indirizzo del router e non l'indirizzo del server. L'indirizzo router è l'indirizzo utilizzato nel comando "server add" sulla macchina Load Balancer al punto 7.
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, consultare 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 di tipo semplice
La funzione di disponibilità elevata implica l'uso di una seconda macchina Dispatcher. La prima macchina Dispatcher esegue il bilanciamento del carico per tutto il traffico client, come in una configurazione a un solo Dispatcher. La seconda macchina Dispatcher controlla lo "stato" della prima e assume il controllo delle attività di bilanciamento del carico se rileva un malfunzionamento sulla prima macchina Dispatcher.
A ciascuna delle due macchine viene assegnato un ruolo specifico, ossia primary (principale) o backup (secondario). La macchina principale invia continuamente i dati di connessione alla macchina secondaria. Mentre la macchina principale è attiva (ed esegue il bilanciamento del carico), la macchina secondaria si trova in standby, aggiornata di continuo e pronta ad assumere il controllo, se necessario.
Le sessioni di comunicazione tra le due macchine vengono denominate heartbeat. Gli heartbeat consentono a ciascuna macchina di controllare lo stato dell'altra.
Se la macchina secondaria rileva un malfunzionamento della macchina attiva, assumerà il controllo e inizierà a eseguire il bilanciamento del carico. A quel punto, gli stati delle due macchine si invertono: la macchina secondaria diventa attiva mentre la macchina principale passa in standby.
Nella configurazione a disponibilità elevata, sia la macchina principale che quella secondaria si trovano sulla stessa sottorete con configurazione identica.
Per informazioni sulla configurazione della disponibilità elevata, vedere Disponibilità elevata.
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 a disponibilità elevata reciproca con il "gruppo di cluster A" e il "gruppo di cluster B" condivisi, vedere Figura 14. Ciascun Dispatcher può attivamente instradare pacchetti per il proprio cluster principale. Se uno dei Dispatcher ha riscontrato un errore e non può più inviare attivamente pacchetti per il proprio cluster principale, l'altro Dispatcher può assumere il controllo e instradare pacchetti per il proprio cluster secondario.
Per informazioni sulla configurazione della disponibilità elevata semplice e reciproca, vedere Disponibilità elevata.
Prima di eseguire le operazioni riportate in questo capitolo, vedere Pianificazione del Dispatcher. Questo capitolo illustra come creare una configurazione di base per il componente Dispatcher di Load Balancer.
IMPORTANTE: se si sta utilizzando Load Balancer per IPv4 e IPv6, vedere Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6.
Prima di iniziare le procedure di configurazione contenute nella 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 4. 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 ulteriori informazioni, 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 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.
È possibile accedere alla guida (Help) facendo clic sull'icona punto interrogativo nell'angolo in alto a destra della finestra di Load Balancer.
Per ulteriori 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 posizionato . 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 non inoltrabile). 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 pacchetto alla macchina Dispatcher, anziché inviarlo direttamente al client. (Il Dispatcher inoltra quindi il pacchetto IP al client.) Quando si aggiunge il server, è necessario specificare il valore dell'indirizzo mittente. Non è possibile modificare l'indirizzo mittente, a meno il server non venga prima rimosso quindi riaggiunto.
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 unità.
Ad esempio, se si desidera utilizzare due schede Ethernet da 100Mbps, è necessario inserire un'unica riga nel file ibmlb.conf specificando la scheda 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 l'unità le e l'altra che specifica l'unità 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
Ad esempio, se i cluster X e Y sono configurati per essere utilizzati dal componente CBR su una delle schede elencate in ibmlb.conf, i cluster X e Y vengono deconfigurati 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 degli indirizzi IP necessari per la macchina Dispatcher
Per la guida dei comandi utilizzati in questa procedura, vedere Riferimenti sui comandi per Dispatcher e CBR.
Per un file di configurazione di esempio, vedere File di configurazione di Load Balancer di esempio.
Su sistemi 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 Riferimenti sui comandi per Dispatcher e CBR.
L'indirizzo non inoltrabile 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 non inoltrabile, immettere il comando dscontrol executor set nfa IP_address o modificare il file di configurazione di esempio. Per IP_address è 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. Consultare 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 proxy trasparente, per ulteriori informazioni.
Normalmente, dopo aver definito il cluster, è necessario configurare l'indirizzo cluster su una delle schede di interfaccia di rete della macchina Dispatcher. A tale scopo, emettere il comando dscontrol executor configure cluster_address. 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 di 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 cluster_address 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, il comando executor configure esegue i comandi ifconfig.
Quando si utilizzano applicazioni server specifiche 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:port, modificare il file di configurazione di esempio o utilizzare la GUI. Per cluster è possibile specificare il nome simbolico o l'indirizzo IP. Per port 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 Riferimenti 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. Vedere Utilizzo della porta jolly per indirizzare il traffico per una porta non configurata, per ulteriori informazioni sui casi in cui è opportuno utilizzare una porta jolly.
Per definire una macchina server con bilanciamento del carico, immettere il comando dscontrol server add cluster:port: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 port 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 per 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 pacchetti/richieste destinati al cluster.
Per determinare se il server è bind specifico, emettere il comando netstat -an e ricercare server:porta. 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 con più indirizzi: 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 dei 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 portPer un elenco degli advisor e delle relative porte predefinite, vedere Riferimenti sui comandi per Dispatcher e CBR. Per una descrizione di ciascun 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 proportions. Per ulteriori informazioni, vedere Proporzione di importanza attribuita alle informazioni sullo stato.
Effettuare le operazioni riportate di seguito in presenza di una delle seguenti condizioni:
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 pacchetto 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, consultare Alternative per l'aggiunta dell'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 del sistema operativo a disposizione, come illustrato
nella Tabella 5, per impostare o creare l'alias dell'unità
loopback.
Tabella 5. 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:
Active Routes: Network Address Netmask Gateway Address Interface Metric 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 6 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 6. Comandi per eliminare instradamenti supplementari per il Dispatcher
Se si utilizza l'esempio illustrato nella Figura 15 e si configura una macchina server su cui è in esecuzione AIX, il comando sarà:
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 server_mac_address
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 nic-primary-addrdove per nic-primary-addr si intende un indirizzo nella stessa sottorete dell'indirizzo cluster. Quindi, è possibile creare normalmente l'alias dei cluster, ad esempio:
# ifconfig lo:1 cluster address netmask 255.255.255.255 up
Il supporto per lo schema di indirizzamento IP esteso di IPv6 È disponibile con Load Balancer per IPv4 e IPv6. Load Balancer per IPv4 e IPv6 è un'immagine di installazione separata costituita esclusivamente dal componente Dispatcher. Questo tipo di installazione fornisce il bilanciamento del carico per il traffico IPv4 e IPv6 ai server configurati nella rete che utilizzano l'inoltro del pacchetto basato su MAC di Dispatcher.
Questo capitolo descrive le differenze di configurazione e le limitazioni di Dispatcher nell'installazione di Load Balancer per IPv4 e IPv6 di questo prodotto e comprende le seguenti sezioni:
Per informazioni generali sul componente Dispatcher, fare riferimento ai seguenti capitoli:
È importante sottolineare che con l'installazione di Load Balancer per IPv4 e IPv6, la sintassi del comando Dispatcher (dscontrol) rimane la stessa, con un'unica eccezione. Il delimitatore dei comandi dscontrol è un simbolo at (@), anziché i due punti (:), quando si utilizza Load Balancer per IPv4 e IPv6. Quando negli altri capitoli del presente documento si fa riferimento ai comandi, ricordarsi di sostituire i due punti (:) con il simbolo @ come delimitatore nei comandi dscontrol.
L'installazione di Load Balancer per IPv4 e IPv6 È disponibile su tutte le piattaforme supportate ad eccezione di Windows 2000.
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
Su alcune piattaforme supportate, come ad esempio tutte le architetture Linux, le installazioni Load Balancer per IPv4 e IPv6 eseguono i processi di bilanciamento del carico nello spazio utente anziché nello spazio del kernel. Per tali sistemi, non esiste alcuna dipendenza dal modulo kernel.
Per le informazioni più aggiornate sulle piattaforme che supportano il bilanciamento del carico nello spazio utente (senza kernel), fare riferimento al seguente sitoWeb: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
I sistemi supportati che eseguono i processi di bilanciamento del carico nello spazio utente hanno delle procedure di configurazione differenti da quei sistemi che eseguono gli stessi processi in uno spazio del kernel. Tali differenze verranno trattate nella sezione relativa a Load Balancer per IPv4 e IPv6.
Sistemi Linux su zSeries
Supporto del tunneling Linux
Su sistemi Linux, le installazioni Load Balancer per IPv4 e IPv6 possono essere inoltrate mediante tunnel quali IPIP e IPGRE. Quando si utilizza Linux su zSeries con un'interfaccia qeth/OSA, un tunnel Linux può essere definito per attraversare l'interfaccia qeth/OSA. I sistemi Linux possono essere inoltrati su macchine ubicate sulle stesse unità qeth/OSA o su unità diverse o su qualsiasi altra unità di rete.
Sistemi Solaris: non esiste alcun supporto per il bilanciamento del carico del traffico IPv6 sui server Solaris 5.8 di backend. Su Solaris 5.8, esiste una incompatibilità con il pacchetto IPv6 MAC e lo stack IPv6 Solaris. Quando il cluster è configurato su un server di backend Solaris 5.8 mediante il comando ifconfig lo0 (loopback), il pacchetto arriva sul nodo Solaris 5.8 ma non viene accettato. Tuttavia, è possibile utilizzare le installazioni Load Balancer per IPv4 e IPv6 per bilanciare il carico del traffico IPv4 sui server Solaris 5.8 di backend.
Sistemi z/OS: non esiste alcun supporto per il bilanciamento del carico del traffico IPv6 sui server z/OS di backend. Tuttavia, è possibile utilizzare le installazioni Load Balancer per IPv4 e IPv6 per bilanciare il carico del traffico IPv4 sui server z/OS di backend.
In Load Balancer per IPv4 e IPv6, le fasi di installazione e i nomi dei pacchetti sono gli stessi di quelli utilizzati per il prodotto Load Balancer che supporta solo gli indirizzi server IPv4. Tuttavia, i pacchetti componente sono di numero inferiore, in quanto È disponibile solo il componente Dispatcher.
Quando si utilizzano gli strumenti di assemblaggio del sistema, l'ordine consigliato per l'installazione dei pacchetti è leggermente differente per le installazioni di Load Balancer per IPv4 e IPv6. È importante notare che il pacchetto del componente di gestione deve essere installato in seguito al pacchetto del componente dispatcher. L'ordine consigliato per l'installazione dei pacchetti per Load Balancer per IPv4 e IPv6 mediante gli strumenti di sistema è: base, licenza, componente dispatcher, gestione, documentazione e Metric Server.
Ad esempio, su sistemi AIX, l'ordine di installazione dei pacchetti Load Balancer per IPv4 e IPv6 è il seguente:
È importante disinstallare la precedente versione di Load Balancer prima di installare Load Balancer per IPv4 e IPv6. Due versioni di Load Balancer non possono essere presenti sulla stessa macchina.
Per le istruzioni sull'installazione del prodotto, vedere Installazione di Load Balancer.
Il componente Dispatcher offre molte, anche se non tutte, delle funzioni offerte dallo stesso componente nelle installazioni di Load Balancer che supportano solo gli schemi di indirizzamento server IPv4. I seguenti argomenti descrivono le particolari differenze di configurazione e le limitazioni funzionali di Dispatcher in Load Balancer per IPv4 e IPv6.
Con l'indirizzamento IPv6, ogni macchina nella configurazione di Load Balancer deve avere un indirizzo locale di collegamento a IPv6.
Questo indirizzo è l'indirizzo utilizzato per il rilevamento del traffico per IPv6. Senza questo indirizzo sulla macchina Load Balancer e sui server di back-end, il rilevamento non viene eseguito e le macchine non sono visibili le une alle altre. Load Balancer per IPv6 non può inoltrare traffico senza un indirizzo IPv6 locale di collegamento configurato su un'interfaccia di ciascuna macchina nella configurazione di Load Balancer.
Quando si configura Load Balancer per IPv4 e IPv6, tutti i server devono essere omogenei nel cluster. Ad esempio, se Cluster1 è stato definito con un indirizzo IPv4, tutti i server raggruppati nel Cluster1 devono essere IPv4. Se Cluster2 è stato definito con un indirizzo IPv6, tutti i server definiti in Cluster2 devono essere IPv6. Inoltre, il protocollo utilizzato dal client per inviare i pacchetti IP deve corrispondere al formato IP del cluster.
Il supporto di un ambiente client misto IPv4 e IPv6 richiede che, per ciascuna definizione cluster logica, vengano definite due definizioni cluster effettive - un cluster IPv4 e un cluster IPv6. I client che inviano pacchetti IPv4 sono instradati da Load Balancer al cluster logico che utilizza gli indirizzi IPv4 configurati per il cluster. I client che inviano pacchetti IPv6 sono instradati da Load Balancer al cluster logico che utilizza gli indirizzi IPv6 configurati per il cluster.
Molte delle funzioni di Dispatcher descritte in Pianificazione del Dispatcher e in Funzioni avanzate di Dispatcher, CBR e Site Selector sono disponibili in Load Balancer per IPv4 e IPv6.
Di seguito viene riportato un elenco riepilogativo delle funzioni di Dispatcher che non sono supportate in Load Balancer per IPv4 e IPv6:
Vedere Funzioni del componente Dispatcher per una descrizione dettagliata delle funzioni di Dispatcher disponibili per la gestione della rete.
Se si utilizza il protocollo IPv6 e si desidera utilizzare gli advisor, è necessario modificare il file del protocollo.
ipv6-icmp 58 IPv6-ICMP
Su sistemi Linux e UNIX, il file del protocollo si trova nella directory /etc/protocols. Su sistemi Windows, il file del protocollo si trova nella directory C:\windows\system32\drivers\etc.
Limitazione relativa all'utilizzo di advisor: seLoad Balancer è in esecuzione su un computer con più schede adattatore di rete e se si desidera che il traffico degli advisor venga distribuito a un particolare adattatore, è possibile forzare l'indirizzo IP di origine dei pacchetti a un indirizzo particolare. La proprietà -DLB_ADV_SRC_ADDR non è disponibile per le installazioni Load Balancer per IPv4 e IPv6.
Per ulteriori informazioni sugli advisor, vedere Advisor.
Se si utilizza il protocollo IPv6 e si desidera utilizzare l'elevata disponibilità, è necessario verificare se protocollo 58 è definito come ICMPv6 nel file del protocollo. Per informazioni sulla modifica del file di protocollo, fare riferimento a Configurazione degli advisor.
Nelle installazioni di Load Balancer per IPv4 e IPv6, la configurazione di una macchina Dispatcher con disponibilità elevata è supportata con le seguenti limitazioni o considerazioni speciali:
Per ulteriori informazioni sulla funzione di disponibilità elevata, vedere Disponibilità elevata.
Il posizionamento è una configurazione in cui Load Balancer può risiedere sulla stessa macchina di un server per il quale sta bilanciando il carico delle richieste.
Quando si utilizzano installazioni di Load Balancer per IPv4 e IPv6, la funzione di posizionamento è disponibile su tutti i sistemi operativi supportati eccetto i sistemi Windows e i sistemi che vengono eseguiti nello spazio utente, come i sistemi Linux.
Per ulteriori informazioni sul posizionamento dei server, vedere Utilizzo dei server posizionati.
La funzione di affinità di Load Balancer per i sistemi che vengono eseguiti nello spazio utente, come i sistemi Linux, opera in maniera differente dalla funzione di affinità per altri sistemi operativi che vengono eseguiti nello spazio del kernel.
Per i sistemi che vengono eseguiti nello spazio utente, Load Balancer associa l'indirizzo IP del client a un server di backend. L'affinità viene stabilita una volta che l'indirizzo IP di destinazione di un pacchetto viene associato al cluster, la porta di destinazione corrisponde alla porta di Load Balancer e l'indirizzo IP di origine corrisponde.
Quando viene stabilità l'affinità, i pacchetti successivi vengono inviati allo stesso server di backend. Se l'affinità viene interrotta, a causa dell'inattività del server o alla rimozione di un server, tutte le connessioni a tale server verranno interrotte.
Inoltre, non saranno presenti informazioni sulla "connessione" riportate sui client della riga comandi o della GUI. verrà utilizzato soltanto il numero di record di affinità attivi.
Questo approccio ha il vantaggio di fornire una elevata affinità ed è più efficiente per il Load Balancer.
Lo svantaggio dei sistemi che utilizzano il bilanciamento del carico nel kernel sta nel fatto che l'utilizzo dell'affinità IP aggiunge carico di CPU e memoria al meccanismo di inoltro della connessione. Su sistemi che eseguono il bilanciamento del carico nello spazio utente, il metodo di affinità utilizzato diminuisce l'utilizzo della CPU e della memoria rispetto all'inoltro della connessione.
Inoltre, a causa di questo modello a singolo record su sistemi in esecuzione in uno spazio utente, i valori di stickytime e staletimeout associati all'affinità sono stati uniti in un unico valore, staletimeout. Poiché la rimozione di un record di affinità interrompe le connessioni, quando si esegue la migrazione da un sistema che viene eseguito nello spazio kernel a un sistema che viene eseguito nello spazio utente, il valore massimo di staletimeout e stickytime deve essere utilizzato come nuovo valore di staletimeout per il Load Balancer in esecuzione sul sistema dello spazio utente.
Per informazioni generali sulla funzione di affinità per i sistemi in esecuzione nello spazio kernel rispetto allo spazio utente, fare riferimento a Funzionamento della funzione di affinità di Load Balancer.
Se si utilizza il protocollo IPv6 e si desidera utilizzare l'elevata disponibilità, è necessario verificare se protocollo 58 è definito come ICMPv6 nel file del protocollo. Per informazioni sulla modifica del file di protocollo, fare riferimento a Configurazione degli advisor.
In una configurazione di Load Balancer che supporta sia i cluster IPv4 che i cluster IPv6, i server che eseguono la funzione Metric Server possono essere configurati solo come server IPv4 o come server IPv6, ma non entrambi. Per far sì che il metric server utilizzi un determinato protocollo, IPv4 o IPv6, specificare la proprietà Java java.rmi.server.hostname nello scriptmetricserver.
IMPORTANTE: il nome host specificato nella proprietà Java deve essere l'indirizzo IP fisico di Metric Server.
Su sistemi UNIX o Linux: perché Metric Server comunichi sull'indirizzo IPV6 2002:92a:8f7a:162:9:42:92:67, specificare la proprietà Java dopo $LB_CLASSPATH nello script di avvio metricserver (nella directory /usr/bin) come riportato di seguito:
/opt/ibm/edge/lb/java/jre/bin/java ..... $LB_CLASSPATH -Djava.rmi.server.hostname=2002:92a:8f7a:162:9:42:92:67 com.ibm.internet.nd.sma.SMA_Agent $LB_RMIPORT $LOG_LEVEL $LOG_SIZE $LOG_DIRECTORY $KEYS_DIRECTORY $SCRIPT_DIRECTORY &
Su sistemi Windows: perché Metric Server comunichi sull'indirizzo IPv6 2002:92a:8f7a:162:9:42:92:67, è necessario modificare il file metricserver.cmd (nella directory C:\winnt\system32) come riportato di seguito:
start /min /wait %IBMLBPATH%\java\jre\bin\java -Djava.rmi.server.hostname=2002:92a:8f7a:162:9:42:92:67 -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Stack=true -Xrs -cp %LB_CLASSPATH% com.ibm.internet.nd.sma.SMA_Agent %RMI_PORT% %LOG_LEVEL% %LOG_SIZE% %LOG_DIRECTORY% %KEYS_DIRECTORY% %SCRIPT_DIRECTORY% goto done :stop %IBMLBPATH%\java\jre\bin\java -Djava.rmi.server.hostname=2002:92a:8f7a:162:9:42:92:67 -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Stack=true -cp %LB_CLASSPATH% com.ibm.internet.nd.sma.SMA_AgentStop %RMI_PORT% :done
Per ulteriori informazioni, vedere Metric Server.
Nei sistemi AIX, Linux e Windows: prima di avviare l'executor (dscontrol executor start), immettere quanto segue dalla riga comandi come root,
Per abilitare l'elaborazione interrotta dei pacchetti IPv6 (anche dopo un riavvio del sistem), modificare il file /etc/rc.tcpip e rimuovere il commento dalla seguente riga, aggiungendo l'indicatore -A: start /usr/sbin/autoconf6 " " -A
Questi comandi abilitano l'elaborazione dei pacchetti IPv6 nei rispettivi sistemi operativi. Immettere questo comando una sola volta. Quindi, è possibile avviare e arrestare l'executor tutte le volte che lo si reputa necessario.
Senza il comando per abilitare l'elaborazione dei pacchetti IPv6 su questi sistemi, l'executor non viene avviato.
Nei sistemi HP-UX e Solaris: utilizzando il comando ifconfig, valutare gli indirizzi IPv6 e configurare un'interfaccia in modo che Dispatcher possa controllare i pacchetti IPv6. Prima di avviare l'executor (dscontrol executor start), immettere quanto segue dalla riga comandi come root,
ifconfig device inet6 up
ifconfig device inet6 plumb ifconfig device inet6 address/prefix up
Senza questi comandi, l'executor verrà avviato ma non sarà possibile visualizzare alcun pacchetto IPv6.
Per configurare l'indirizzo cluster su una scheda di interfaccia di rete (NIC) della macchina Dispatcher, è possibile immettere il comando dscontrol executor configure cluster_address. Il comando dscontrol executor configure esegue i comandi di configurazione dell'adattatore del sistema operativo(ad esempio, i comandi ifconfig, dsconfig (solo IPv6) o ip). In alternativa, per creare l'alias della NIC della macchina Dispatcher, è possibile scegliere di immettere direttamente i comandi di configurazione dell'adattatore del sistema operativo anziché utilizzare il comando executor configure.
Tuttavia, ciò non si applica a sistemi Linux su zSeries che utilizzano un'interfaccia qeth/OSA. Per questa piattaforma, è necessario configurare l'indirizzo del cluster. Fare riferimento a Operazioni di configurazione del cluster per Linux suzSeries per maggiori dettagli.
Per creare l'alias del dispositivo loopback (lo0) sui server sottoposti al bilanciamento del carico, è necessario utilizzare i comandi di configurazione dell'adattatore del sistema operativo.
Nelle installazioni di Load Balancer per IPv4 e IPv6, è possibile utilizzare i seguenti comandi per creare l'alias dell'interfaccia di rete e del dispositivo loopback (interface_name ).
Nei sistemi AIX (5.x),
ifconfig interface_name inet6 cluster_address/prefix_length alias
Ad esempio, per creare l'alias del dispositivo loopback sui server sottoposti al bilanciamento del carico:
ifconfig lo0 inet6 2002:4a::541:56/128 alias
Nei sistemi HP-UX:
ifconfig interface_name:alias inet6 cluster_address up prefix prefix_length
Ad esempio, per creare l'alias del dispositivo loopback sui server sottoposti al bilanciamento del carico:
ifconfig lo0:1 inet6 3ffe:34::24:45 up prefix 128
Nei sistemi Linux:
ip -versione addr add indirizzo_cluster/lunghezza_prefisso dev lo
Ad esempio, per creare l'alias del dispositivo loopback sui server sottoposti al bilanciamento del carico:
ip -6 addr add 3ffe:34::24:45/128 dev lo ip -4 addr add 12.42.38.125/32 dev lo
Una volta emesso uno dei comandi di configurazione sulla macchina, utilizzare sempre lo stesso comando (ip or ifconfig) altrimenti si verificheranno degli errori.
Sui sistemi Solaris 8, 9 e 10:
ifconfig interface_name inet6 addif cluster_address/prefix_length up
Ad esempio, per creare l'alias del dispositivo loopback sui server sottoposti al bilanciamento del carico:
ifconfig lo0 inet6 addif 3ffe:34::24:45/128 up
Nei sistemi Windows 2003 (Windows 2000 e Windows NT non supportano IPv6):
Configurazione IP Windows Host Name . . . . . . . . . . . . : ndserv10 Primary Dns Suffix . . . . . . . : rtp.raleigh.ibm.com Node Type . . . . . . . . . . . . : Unknown IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : rtp.raleigh.ibm.com Ethernet adapter Local Area Connection 2: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft Loopback Adapter Physical Address. . . . . . . . . : 02-00-4C-4F-4F-50 DHCP Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 9.42.92.158 Subnet Mask . . . . . . . . . . . : 255.255.252.0 IP Address. . . . . . . . . . . . : 9.42.92.159 Subnet Mask . . . . . . . . . . . : 255.255.252.0 IP Address. . . . . . . . . . . . : 2002:92a:8f7a:162:9:42:92:160 IP Address. . . . . . . . . . . . : 2002:92a:8f7a:162:9:42:92:159 IP Address. . . . . . . . . . . . : fe80::4cff:fe4f:4f50%4 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 127.0.0.1 fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1
netsh interface ipv6 add address "Local Area Connection 2" 2002:92a:8f7a:162:9:42:92:161
Ethernet adapter Local Area Connection 2: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft Loopback Adapter Physical Address. . . . . . . . . : 02-00-4C-4F-4F-50 DHCP Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 9.42.92.158 Subnet Mask . . . . . . . . . . . : 255.255.252.0 IP Address. . . . . . . . . . . . : 9.42.92.159 Subnet Mask . . . . . . . . . . . : 255.255.252.0 IP Address. . . . . . . . . . . . : 2002:92a:8f7a:162:9:42:92:161 IP Address. . . . . . . . . . . . : 2002:92a:8f7a:162:9:42:92:160 IP Address. . . . . . . . . . . . : 2002:92a:8f7a:162:9:42:92:159 IP Address. . . . . . . . . . . . : fe80::4cff:fe4f:4f50%4 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 127.0.0.1 fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1
netsh interface ipv6>show interface Querying active state... Idx Met MTU State Name --- ---- ----- ------------ ----- 6 2 1280 Disconnected Teredo Tunneling Pseudo-Interface 5 0 1500 Connected Local Area Connection 4 0 1500 Connected Local Area Connection 2 3 1 1280 Connected 6to4 Pseudo-Interface 2 1 1280 Connected Automatic Tunneling Pseudo-Interface 1 0 1500 Connected Loopback Pseudo-Interface netsh interface ipv6>set interface "Local Area Connection" forwarding=enabled Ok. netsh interface ipv6>set interface "Local Area Connection 2" forwarding=enabled Ok.
Nei sistemi OS/2:
Per Linux su zSeries, per impostare il Load Balancer sono richieste le seguenti operazioni di configurazione aggiuntive:
Per gli indirizzi IPv6 o IPv4:
ip -versione addr add indirizzo_cluster/lunghezza_prefisso dev dispositivo
Ad esempio:
ip -4 addr add 12.42.38.125/24 dev eth0 ip -6 addr add 3ffe:34::24:45/64 dev eth0
Per gli indirizzi IPv4:
iptables -t filter -A INPUT -d indirizzo_cluster -j DROP
Per gli indirizzi IPv6:
ip6tables -t filter -A INPUT -d indirizzo_cluster -j DROP
Ad esempio:
iptables -t filter -A INPUT -d 12.42.38.125 -j DROP ip6tables -t filter -A INPUT -d 3ffe:34::24:45 -j DROP
Per annullare la configurazione precedente, utilizzare i seguenti comandi:
ip -versione addr del indirizzo_cluster/lunghezza_prefisso dev dispositivo iptables -t filter -D INPUT -d indirizzo_cluster -j DROP ip6tables -t filter -D INPUT -d indirizzo_cluster -j DROP
Poiché Load Balancer per IPv4 e IPv6 non supporta tutte le funzioni del componente, i comandi dscontrol validi per questa installazione sono un gruppo secondario dei comandi dscontrol per le installazioni Load Balancer che supportano solo IPv4. Questa sezione descrive le differenze di sintassi dei comandi ed elenca tutti i comandi dscontrol supportati per il componente Dispatcher in Load Balancer per IPv4 e IPv6.
Nell'installazione di Load Balancer per IPv4 e IPv6, la sintassi del comando Dispatcher (dscontrol) rimane la stessa, con un'unica importante eccezione. Il delimitatore dei comandi dscontrol è un simbolo chiocciola (@), anziché i due punti (:), quando si utilizza Load Balancer per IPv4 e IPv6.
È stato necessario definire un delimitatore diverso dai due punti (:) perché nel formato IPv6 tale simbolo si utilizza nello schema di indirizzamento.
Quanto riportato di seguito illustra il comando dscontrol utilizzando un delimitatore chiocciola (@)
dscontrol server add 30::100@80@30::200
dscontrol server add 192.4.40.30@80@192.4.20.35
IMPORTANTE: quando nel presente documento si fa riferimento ai comandi, ricordarsi di sostituire i due punti (:) con il simbolo @ come delimitatore nei comandi dscontrol.
Per informazioni dettagliate ed esempi della sintassi di tutti i comandi dscontrol, vedere Riferimenti sui comandi per Dispatcher e CBR.
Di seguito viene riportato un riepilogo di tutti i comandi supportati di Dispatcher nell'installazione di Load Balancer per IPv4 e IPv6:
Per i sistemi che vengono eseguiti nello spazio utente, come i sistemi Linux:
Per IPv6, la lunghezza del prefisso rappresenta il numero di bit nella porzione di rete degli indirizzi IPv6. La lunghezza del prefisso definisce l'indirizzo di rete dall'indirizzo host.
Per IPv4, determinare la lunghezza del prefisso come riportato di seguito: se la subnet mask è 255.255.252.0, l'equivalente esadecimale è FF.FF.FC.0. In valori binari, il valore è11111111 11111111 11111100 00000000. Un numero pari a 1 nella subnet mask determina la lunghezza del prefisso. Se sono presenti 22 numeri uno nella subnet mask, allora il prefisso sarà 22.
La sintassi per executor configure è:
dscontrol executor configure indirizzo_inerfaccia nome_interfaccia lunghezza_prefisso
Esempio con indirizzo IPv6:
dscontrol executor configure 2002:092a:8f7a:4226:9:37:240:99 en0 112
Esempio con indirizzo IPv4, se la subnet mask è 255.255.252.0:
dscontrol e config 191.60.20.20 en1 22
È importante tenere presente che il comando executor configure non viene utilizzato per i sistemi che vengono eseguiti nello spazio utente, come ad esempio i sistemi Linux su installazioni Load Balancer per IPv4 e IPv6.
I seguenti valori sono gli unici valori validi delle chiavi per gli argomenti add e set sul comando dscontrol port:
Per sistemi che vengono eseguiti nello spazio utente, come i sistemi Linux: i seguenti valori delle chiavi sono validi per gli argomenti add e set sul comando dscontrol port:
Le opzioni per selectionalgorithm (algoritmo di selezione server) sono:
Ad esempio:
dscontrol port add cluster@port selectionalgorithm affinity
I seguenti valori delle chiavi sono validi per l'argomento add sul comando dscontrol server:
La parola chiave collocated è disponibile su tutti i sistemi operativi supportati tranne che su Windows e su sistemi che vengono eseguiti nello spazio utente, come i sistemi Linux.
I seguenti valori delle chiavi sono validi per l'argomento set sul comando dscontrol server:
La parola chiave collocated è disponibile su tutti i sistemi operativi supportati tranne che su Windows e su sistemi che vengono eseguiti nello spazio utente, come i sistemi Linux.
I seguenti comandi non sono disponibili per Dispatcher nell'installazione di Load Balancer per IPv4 e IPv6:
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 avvio rapido, è necessario disporre di tre stazioni di lavoro e di 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 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 di 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 colonna delle connessioni totali dei due server dovrebbe visualizzare "2".
Per informazioni sull'uso della GUI in CBR, vedere GUI and see Appendice A, GUI: istruzioni generali.
Per informazioni sull'uso della configurazione guidata di CBR, vedere Configurazione guidata.
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 si collegheranno tutti gli utenti, è possibile definire un unico cluster di server. Per ciascuno di questi server, configurare una porta dedicata alla comunicazione con CBR. Vedere Figura 9.
Figura 17. Esempio di 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 dispone di due porte: la porta 80 per il traffico HTTP e la porta 443 per il traffico 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, una porta ciascuno
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 ciascuna azienda o reparto, quindi definire le porte su cui si desidera ricevere le connessioni a quell'URL, come mostrato nella Figura 11.
Figura 19. Esempio di CBR configurato con 2 cluster, 2 porte ciascuno
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 plug-in. Affinché ciò funzioni, CBR deve essere eseguito sulla macchina locale. Poiché questi due processi sono distinti, più istanze di Caching Proxy possono essere in esecuzione e funzionanti con un'unica istanza di CBR. Questa configurazione potrebbe consentire di isolare gli indirizzi o le funzionalità tra i Caching Proxy oppure di migliorare l'uso delle risorse della macchina grazie a più Caching Proxy che gestiscono il traffico dei client. Le istanze proxy possono restare in ascolto su porte diverse o essere associati a indirizzi IP univoci sulla stessa porta, a seconda di ciò che meglio soddisfa i requisiti di traffico.
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 affinché Caching Proxy abiliti la codifica SSL sul lato proxy-server. Il formato deve essere:
proxy modello_uri modello_url indirizzo
dove modello_uri è un modello a cui corrispondere (ad esempio: /secure/*), modello_url è un URL di sostituzione (ad esempio: https://clusterA/secure/*) e indirizzo è l'indirizzo cluster (ad esempio: clusterA).
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 per il 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 7. 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:
Su 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. A tal fine, è sufficiente immettere 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: immettere 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 Add 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 su un file o di ripristinare le connessioni nei file esistenti per tutti i componenti di Load Balancer.
È possibile accedere alla guida (Help) 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 ulteriori informazioni sull'uso della GUI, vedere Appendice A, GUI: istruzioni generali.
Se si utilizza la configurazione guidata, effettuare le seguenti operazioni:
Avviare la configurazione guidata dal prompt dei comandi immettendo cbrwizard. In alternativa, selezionare Configuration Wizard dal menu del componente CBR presente nella GUI.
Su sistemi AIX, HP-UX, Linux o Solaris: per avviare Caching Proxy, immettere ibmproxy
Su sistemi Windows: per avviare Caching Proxy, fare clic su 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 su 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 per 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 automaticamente caricato all'avvio di 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. È inoltre possibile modificare le varie impostazioni dell'executor in questa fase. 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 cluster option value
Per ulteriori informazioni, vedere Riferimenti 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.
Su 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 8.
Tabella 8. Comandi per creare l'alias della NIC
AIX | ifconfig interface_name alias cluster_address netmask netmask |
HP-UX | ifconfig interface_name cluster_address netmask netmask up |
Linux | ifconfig interface_name cluster_address netmask netmask up |
Solaris 8, Solaris 9 e Solaris 10 | ifconfig nome_interfaccia addif indirizzo_cluster netmask netmask up |
In Windows 2000: per aggiungere l'indirizzo cluster all'interfaccia di rete, effettuare le seguenti operazioni:
In 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:porta
Per impostare le opzioni della porta, immettere quanto segue:
cbrcontrol port set cluster:porta option value
Per ulteriori informazioni, vedere Riferimenti 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 type content pattern 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 port
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 proportions. 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 and 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 in Site Selector, vedere GUI e Appendice A, GUI: istruzioni generali.
Per informazioni sull'uso della configurazione guidata di Site Selector, vedere Configurazione guidata.
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 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, su 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 Site Selector del sistema 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, consultare 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, consultare 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 time-out. 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 time-out di 5 secondi. Site Selector tenta di rispondere prima che venga superato questo time-out.)
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, consultare Riferimenti 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 9. Configurazione delle attività 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 Site Selector dalla riga comandi:
È possibile immettere una versione ridotta dei parametri del comando sscontrol. A tal fine, è sufficiente immettere 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: immettere 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. Ad esempio, per definire 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 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 su 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 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 (Help) facendo clic sull'icona punto interrogativo nell'angolo in alto a destra della finestra di Load Balancer.
Per ulteriori 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 Configuration Wizard dal menu del componente Site Selector presente nella GUI.
La procedura guidata 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 del sito sui rispettivi server configurati su di esso.
Il nome del sito è un nome host non risolvibile che il client richiederà. Il nome del sito deve essere un nome dominio completo (ad esempio, www.dnsdownload.com). Quando un client richiede questo nome del sito, verrà restituito uno degli indirizzi IP del server associati al nome del sito.
Per definire un nome del sito, immettere il seguente comando:
sscontrol sitename add sitename
Per impostare le opzioni del nome del sito, immettere il seguente comando:
sscontrol sitename set sitename option value
Per ulteriori informazioni, vedere Riferimenti 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 del 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
Vedere Metric Server per informazioni sull'uso delle metriche del sistema e di 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 del sito, immettere il comando sscontrol sitename set sitename proportions. Per ulteriori informazioni, vedere Proporzione di importanza attribuita alle informazioni sullo stato.
Utilizzare Metric Server con il componente Site Selector. Fare riferimento a Metric Server per informazioni sulla configurazione di Metric Server su tutte le macchine server per cui Site Selector sta eseguendo il bilanciamento del carico.
Questa sezione fornisce informazioni per una rapida configurazione, considerazioni sulla pianificazione e descrive i metodi di configurazione del componente Controller Cisco CSS 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 Switch Cisco CSS nella determinazione e selezione del server più adatto per le decisioni sul bilanciamento del carico.
Figura 25. Una configurazione Cisco CSS Controller semplice
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:
Cisco CSS Controller consente di 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 Switch Cisco CSS 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 Switch Cisco CSS.
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 Controller è possibile esaminare le informazioni sui servizi che sono stati configurati su Switch Cisco CSS 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 Switch Cisco CSS tramite SNMP.
La configurazione Cisco CSS Controller base è ora completa.
Verificare se la configurazione è in esecuzione:
Per informazioni sull'uso della GUI in 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 Controller Cisco CSS.
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 in 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:
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:
Fare riferimento a Cisco Content Services Switch Getting Started Guide per le informazioni dettagliate.
La disponibilità elevata del controller migliora le funzioni di tolleranza degli errori di Load Balancer. Progettata sulla base della disponibilità elevata dell'inoltro del pacchetto, 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, consultare 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, consultare Uso dei log di Load Balancer.
Prima di eseguire le operazioni riportate in questo capitolo, vedere Pianificazione di Controller Cisco CSS. Questo capitolo illustra come creare una configurazione di base per il componente Controller Cisco CSS di Load Balancer.
Prima di iniziare qualsiasi metodo di configurazione riportato in questo capitolo:
Tabella 10. Configurazione delle attività per il componente Controller Cisco CSS
Attività | Descrizione | Informazioni correlate |
---|---|---|
Configurazione della macchina Controller Cisco CSS | Individuazione dei requisiti | Configurazione della macchina Controller per switch Cisco CSS |
Verifica della configurazione | Conferma che configurazione funziona correttamente | Verifica della configurazione |
Per creare una configurazione di base per il componente Controller Cisco CSS di Load Balancer, sono disponibili tre metodi:
Questo metodo è il mezzo più diretto di configurazione di Controller Cisco CSS. Le procedure descritte nel presente manuale presumono l'uso della riga comandi. 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 consultant add) e i nomi di file.
Per avviare Controller Cisco CSS dalla riga comandi:
Note:
È possibile immettere una versione abbreviata dei parametri del comando ccocontrol. A tal fine, è sufficiente immettere 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: immettere 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 di Controller Cisco CSS 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 all'Help, fare clic sull'icona punto interrogativo nell'angolo superiore destro della finestra di Load Balancer.
Per ulteriori informazioni sull'uso della GUI, vedere Appendice A, GUI: istruzioni generali.
Per poter configurare la macchina Controller Cisco CSS, è 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 Switch Cisco CSS come amministratore di Switch Cisco CSS.
Durante la configurazione del consultant, è necessario configurare l'indirizzo e il nome comunità SNMP in modo che corrispondano agli attributi su Switch Cisco CSS.
Per maggiori informazioni sui comandi utilizzati in questa procedura, vedere Riferimenti 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 Switch Cisco CSS.
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 Switch Cisco CSS. 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'uso del server delle metriche, 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, Controller Cisco CSS 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 di Controller Cisco CSS e Controller Nortel Alteon.
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 Controller Nortel Alteon di Load Balancer. Contiene i seguenti capitoli:
Questo esempio di avvio rapido illustra come creare una configurazione utilizzando il componente Controller Nortel Alteon. Controller Nortel Alteon fornisce le informazioni sui pesi dei server a Switch Nortel Alteon Web. 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 Controller Nortel Alteon semplice
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:
Controller Nortel Alteon consente di 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 Switch Nortel Alteon Web e verificare che i nomi comunità SNMP funzionino correttamente.
nalcontrol service add Consultant-1:Service-1 vsid 1 vport 80
Controller Nortel Alteon comunicherà ora con lo switch sul protocollo SNMP e otterrà così le necessarie informazioni sulla configurazione provenienti dallo switch. Dopo questa fase, in Controller Nortel Alteon è possibile esaminare le informazioni sui server che sono stati configurati su Switch Nortel Alteon Web 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. Controller Nortel Alteon comunica i risultati dei calcoli eseguiti sui pesi dei servizi a Switch Nortel Alteon Web tramite SNMP.
La configurazione Controller Nortel Alteon base è ora completa.
Verificare se la configurazione è in esecuzione:
Per informazioni sull'uso della GUI in Controller Nortel Alteon, vedere GUI and 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 Controller Nortel Alteon.
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
Controller Nortel Alteon 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 Controller Nortel Alteon 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 delle connessioni massime 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.
Sia Controller Nortel Alteon che Switch Nortel Alteon Web hanno 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 pacchetto 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, consultare 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, consultare 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, consultare Uso dei log di Load Balancer.
Prima di eseguire le operazioni riportate in questo capitolo, vedere Pianificazione di Controller Nortel Alteon. Questo capitolo illustra come creare una configurazione di base per il componente Controller Nortel Alteon di Load Balancer.
Prima di iniziare qualsiasi metodo di configurazione riportato in questo capitolo, verificare che Switch Nortel Alteon Web e tutte le macchine server siano configurate correttamente.
Tabella 11. Configurazione delle attività per il componente Controller Nortel Alteon
Attività | Descrizione | Informazioni correlate |
---|---|---|
Configurazione di Switch Nortel Alteon Web e dei server | Configurazione dello switch. | Come configurare lo switch, a pagina (SETSWITCH) |
Configurazione della macchina Controller Nortel Alteon | Configurazione del controller. | Fase 1. Avvio della funzione del server |
Verifica della configurazione | Conferma della procedura di configurazione in corso | Verifica della configurazione |
Per creare una configurazione di base per il componente Controller Nortel Alteon di Load Balancer, sono disponibili tre metodi:
È il mezzo più diretto per la configurazione di Controller Nortel Alteon. Le procedure riportate in questo manuale presuppongono l'uso della riga comandi.
Per avviare Controller Nortel Alteon dalla riga comandi:
Note:
È possibile utilizzare una versione abbreviata dei parametri del comando nalcontrol digitando le lettere che designano in modo univoco i parametri. Ad esempio, per visualizzare le informazioni sul comando di salvataggio dei file, è possibile digitare nalcontrol he f invece di 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 dell'interfaccia utente grafica (GUI), vedere Figura 41.
Per avviare la GUI:
Per configurare il componente Controller Nortel Alteon 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 all'Help, fare clic sull'icona punto interrogativo nell'angolo superiore destro della finestra di Load Balancer.
Per ulteriori informazioni sull'uso della GUI, vedere Appendice A, GUI: istruzioni generali.
Per maggiori informazioni sui comandi utilizzati in questa procedura, vedere Riferimenti sui comandi per Controller Nortel Alteon.
Prima di configurare la macchina Controller Nortel Alteon:
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 virtualer) 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 utilizzare e configurare la disponibilità elevata del controller, vedere Funzioni avanzate di Controller Cisco CSS e Controller Nortel Alteon.
Se le metriche del sistema vengono definite nella fase 5, il server delle metriche deve essere avviato sulle metriche del servizio. Per informazioni sull'uso del server delle metriche, vedere Metric Server.
Se viene modificata la configurazione su Switch Nortel Alteon Web, è 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.
IMPORTANTE: se si sta utilizzando l'installazione di Load
Balancer per IPv4 e IPv6, vedere Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6 per evidenziare le limitazioni e le differenze di
configurazione prima di esaminare i contenuti di questa sezione.
Tabella 12. Attività di configurazione avanzate di 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 in 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. | Uso 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 |
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 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 proportions. Per ulteriori informazioni, consultare dscontrol cluster -- configura i cluster.
I pesi vengono impostati dalla funzione gestore in base ai contatori interni all'executor, alle informazioni restituite dagli advisor e alle informazioni restituite 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. 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.
Per specificare il limite massimo del peso che un server può avere, utilizzare il comando dscontrol port set port weightbound weight. 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 predefinito 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 su 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 port 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, consultare 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 delle applicazioni server specifiche del collegamento: Per poter utilizzare gli advisor sui server specifici di collegamento, avviare due istanze del server: una da collegare su cluster:porta e l'altra da collegare su server:porta. Per determinare se il server è bind specifico, emettere il comando netstat -an e ricercare server:porta. 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.
Su sistemi HP-UX e Solaris, limitazione all'uso delle applicazioni server specifiche 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 specifiche del collegamento (inclusi altri componenti Load Balancer quali CBR o Site Selector) quando si collegano all'indirizzo IP cluster. Tuttavia, l'uso degli advisor sull'applicazione server specifica 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 "Port" 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). Ad esempio, se 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).
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 è illimitato.
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 ottenere il rilevamento più rapido dei server che non hanno funzionato correttamente, 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, consultare 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 Load Balancer 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, consultare 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 utilizzando 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 di 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 su Metric Server, 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 esempio nella directory di
installazione
...<directory
install>/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 avere il 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 è:
dir_install/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 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
Il listato del programma di un advisor di esempio è 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 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 Metric Server 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 Uso 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.
port è 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 deve rappresentare una misura di carico non un valore della 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 Metric Server 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 di 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 come configurare i parametri per il bilanciamento del carico e come impostare le funzioni avanzate di Load Balancer.
IMPORTANTE: se si sta utilizzando l'installazione di Load
Balancer per IPv4 e IPv6, consultare Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6 per evidenziare le limitazioni e le differenze di
configurazione prima di esaminare i contenuti di questo capitolo.
Tabella 13. Attività di configurazione avanzate di Load Balancer
Attività | Descrizione | Informazioni correlate |
---|---|---|
Posizionare Load Balancer su una macchina che esegue il bilanciamento del carico | Impostare una macchina Load Balancer posizionata. | Utilizzo dei server posizionati |
Configurare la disponibilità elevata semplice e reciproca | Impostare una seconda macchina Dispatcher che funzioni da backup. | Disponibilità elevata |
Configurare il bilanciamento del carico in base alle regole | Definire le condizioni in base alle quali utilizzare un sottoinsieme di server. | Configurazione del bilanciamento del carico in base alle regole |
Utilizzare la funzione "ignora affinità di porta" per permettere a un server di ignorare la funzione di aderenza alla porta | Permette a un server di ignorare l'impostazione del tempo di aderenza sulla sua porta. | ignora affinità di porta |
Utilizzare la funzione di aderenza (affinità) per configurare la porta di un cluster e renderla aderente | Consente di indirizzare le richieste dei client a uno stesso server. | Funzionamento della funzione di affinità di Load Balancer |
Utilizzare l'affinità multiporta per espandere la funzione di aderenza (affinità) tra le porte | Fa in modo che le richieste dei client, ricevute da diverse porte, vengano indirizzate allo stesso server. | Affinità multiporta |
Utilizzare la funzione maschera indirizzo affinità per indicare un indirizzo di sottorete IP comune | Permette che le richieste dei client, ricevute dalla stessa sottorete, vengano indirizzate sullo stesso server. | Maschera indirizzo affinità (stickymask) |
Utilizzare l'affinità cookie attiva per bilanciare il carico dei server di CBR | L'opzione di una regola che consente a una sessione di mantenere l'affinità per un server particolare. | Affinità cookie attivo |
Utilizzare l'affinità cookie passivo per bilanciare il carico dei server per l'instradamento in base al contenuto di Dispatcher e per il componente CBR | L'opzione di una regola che consente a una sessione di mantenere l'affinità per un server particolare in base al valore e al nome cookie. | Affinità cookie passivo |
Utilizzare l'affinità URI per bilanciare il carico tra i server Caching Proxy con contenuto univoco da memorizzare su ogni singolo server | L''opzione di una regola che consente a una sessione di mantenere l'affinità per un server particolare in base all'URI. | Affinità URI |
Configurare il supporto di Dispatcher per una rete geografica | Impostare un Dispatcher remoto per bilanciare il carico su una rete geografica (WAN, wide area network). Oppure, bilanciare il carico attraverso una rete geografica (WAN, Wide Area Network), senza un Dispatcher remoto, utilizzando una piattaforma server che supporta GRE. | Configurazione del supporto di Dispatcher per una rete geografica |
Utilizzare un collegamento esplicito | Impedisce di ignorare Dispatcher nei collegamenti. | Utilizzo di un collegamento esplicito |
Utilizzare una rete privata | Configurare Dispatcher in modo da bilanciare il carico dei server su una rete privata. | Utilizzo di una configurazione di rete privata |
Utilizzare cluster jolly per combinare le configurazioni di server comuni | Gli indirizzi che non sono esplicitamente configurati utilizzeranno i cluster jolly per bilanciare il traffico. | Utilizzo del cluster jolly per combinare le configurazioni di server |
Utilizzare il cluster jolly per bilanciare il carico dei firewall | Tutto il traffico verrà bilanciato sui firewall. | Utilizzo di cluster jolly per bilanciare il carico dei firewall |
Utilizzare il cluster jolly con Caching Proxy come proxy trasparente | Consente di utilizzare Dispatcher per attivare un proxy trasparente. | Utilizzo del cluster jolly con Caching Proxy per proxy trasparente |
Utilizzare la porta jolly per indirizzare il traffico non configurato sulle porte | Gestisce il traffico che non è configurato per nessuna porta in particolare. | Utilizzo della porta jolly per indirizzare il traffico per una porta non configurata |
Utilizzare il rilevamento attacchi di tipo "Denial of Service" per notificare agli amministratori (con un avviso) eventuali attacchi | Dispatcher analizza le richieste in entrata per una grande quantità di connessioni TCP aperte a metà sui server. | Rilevamento attacco di tipo Denial of service |
Utilizzare i file binari di log per analizzare le statistiche dei server | Permette la memorizzazione e il richiamo delle informazioni relative ai server dai file binari. | Uso della registrazione binaria per analizzare le statistiche dei server |
Utilizzare una configurazione client posizionato | Consente al Load Balancer di trovarsi sulla stessa macchina del client | Utilizzo di un client posizionato |
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. È applicabile esclusivamente ai componenti Dispatcher e Site Selector. Il posizionamento è supportato anche per CBR, ma solo se si utilizzano dei server web Caching Proxy specifici del collegamento.
Su 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, consultare Alternative per l'aggiunta dell'alias loopback Linux quando si utilizza il metodo di inoltro mac di Load Balancer.
Su 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 e 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 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 no. Il valore predefinito è no. L'indirizzo del server deve essere un indirizzo IP valido di una scheda di interfaccia di rete della macchina. Il parametro collocated non dovrebbe essere impostato per i server posizionati mediante metodo di inoltro nat o cbr di Dispatcher.
È possibile configurare un server posizionato in uno dei seguenti modi:
Per il protocollo nat o per l'inoltro cbr di Dispatcher, è necessario configurare (alias) un indirizzo di adattatore non utilizzato su NFA. Il server dovrebbe essere configurato per essere in ascolto su questo indirizzo. Configurare il server utilizzando la seguente sintassi:
dscontrol server add cluster:port:new_alias address new_alias router router_ip returnaddress return_address
Una configurazione errata può causare errori di sistema, una mancata risposta del server, o entrambe le condizioni.
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 finali sono consigliate ma non obbligatorie. Per ulteriori informazioni, consultare Capacità di rilevamento di errori mediante heartbeat e la destinazione accessibile.
dscontrol highavailability backup add primary [auto | manual] port
dscontrol highavailability backup add backup [auto | manual] port
dscontrol highavailability backup add both [auto | manual] port
dscontrol highavailability statusCiascuna macchina deve avere il ruolo corretto (backup, principale o entrambi), 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 finali che sono communicate grado di sottoporre a ping. Se la macchina in standby sottopone a ping un numero di destinazioni finali superiore a quelli attivi, si verifica un failover.
Gli heartbeat vengono inviati dal Dispatcher attivo ed è previsto che vengano ricevuti dal Dispatcher in standby ogni mezzo secondo. Se il Dispatcher in standby non riceve alcun heartbeat entro 2 secondi, inizia un failover. Per consentire il takeover da un Dispatcher in standby, tutti gli heartbeat devono essere interrotti. In altre parole, se sono configurate due coppie di heartbeat, entrambi gli heartbeat devono essere interrotti. Per stabilizzare un ambiente 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 si ottiene tramite l'advisor reach, che esegue il ping sull'host. Il failover si verifica se si interrompe la trasmissione degli heartbeat oppure se i criteri di accessibilità vengono soddisfatti in misura maggiore dal Dispatcher in standby rispetto al Dispatcher principale. Per prendere una decisione in base alle informazioni disponibili, il Dispatcher attivo invia regolarmente al Dispatcher in standby informazioni sulle sue capacità di accessibilità. Il Dispatcher in standby, quindi, confronta tali capacità con le proprie e decide se deve avvenire la commutazione.
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 di cluster. Se si verifica un problema con una macchina, che riguarda anche un solo cluster, l'altra macchina prenderà il controllo di entrambi i cluster.
Affinché il Dispatcher indirizzi i pacchetti, è necessario creare un alias per ciascun indirizzo cluster sull'unità di interfaccia di rete.
Per informazioni sull'alias della scheda di rete, fare riferimento a Fase 5. Creazione dell'alias della scheda di interfaccia di rete (NIC).
Poiché le macchine Dispatcher cambiano di stato quando viene rilevato un errore, i comandi indicati in precedenza devono essere emessi automaticamente. Per far ciò, Dispatcher eseguirà gli script creati dall'utente. Gli script di esempio si trovano nella directory ...ibm/edge/lb/servers/samples e devono essere spostati sulla directory ...ibm/edge/lb/servers/bin per poter essere eseguiti. Gli script vengono eseguiti automaticamente solo se dsserver è in esecuzione.
Note:
È possibile utilizzare i seguenti script di esempio:
Sui sistemi Windows: durante la configurazione, se Site Selector bilancia il carico di due macchine Dispatcher, operative in un ambiente a disponibilità elevata, sarà necessario aggiungere un alias sullo stack Microsoft per i Metric Server. Questo alias va aggiunto allo script goActive. Ad esempio:
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
Negli script goStandby e goInOp, l'alias dovrà essere rimosso. Ad esempio:
call netsh interface ip delete address "Local Area Connection" addr=9.37.51.28
Se la macchina dispone di più NIC, controllare prima quale interfaccia utilizzare emettendo il seguente comando sul prompt dei comandi: netsh interface ip show address. Questo comando restituirà un elenco delle interfacce attualmente configurate numerando ciascuna "Connessione alla rete locale (LAN)" (ad esempio, "Connessione alla rete locale (LAN) 2"); in questo modo, è possibile stabilire quale utilizzare.
Su sistemi Linux per S/390: Dispatcher emette un ARP gratuito per spostare gli indirizzi IP da un Dispatcher all'altro. Questo meccanismo è, quindi, legato al tipo di rete sottostante. Quando si esegue Linux per S/390, Dispatcher può eseguire, in modalità nativa, takeover in disponibilità elevata (compresi gli spostamenti dell'indirizzo IP) solo su quelle interfacce che possono emettere un ARP gratuito e configurare l'indirizzo sull'interfaccia locale. Questo meccanismo non funzionerà correttamente sulle interfacce point-to-point, come ad esempio IUCV e CTC, e non funzionerà correttamente in alcune configurazioni di qeth/QDIO.
Per quelle interfacce e configurazioni in cui la funzione di takeover IP nativa del Dispatcher non funziona correttamente, il cliente può inserire dei comandi adatti negli script go per spostare manualmente gli indirizzi. In questo modo, quelle topologie di rete possono trarre beneficio dalla disponibilità elevata.
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 primaria che su quella di backup. Per l'installazione del dispositivo loopback su sistemi Windows, effettuare le operazioni riportate in Configurazione delle 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, consultare Appendice B, Sintassi della regola di contenuto (modello)).
Le regole vengono valutate in ordine di priorità. In altre parole, una regola con priorità 1 (numero più basso) verrà valutata prima di una regola con priorità 2 (numero più alto). 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, consultare 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 size dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth size
Il valore size di sharedbandwidth è un numero intero (kilobyte al secondo). Il valore predefinito è zero. Se il valore è zero, la larghezza di banda non può essere condivisa.
La condivisione della larghezza di banda al livello di cluster permette a quest'ultimo di utilizzare una larghezza di banda massima specificata. Fino a quando la larghezza di banda utilizzata dal cluster è inferiore alla quantità specificata, questa regola verrà considerata valida, true. Se la larghezza di banda totale è superiore alla quantità specificata, questa regola sarà considerata non valida, false.
La condivisione della larghezza di banda al livello di executor permette all'intera configurazione di Dispatcher di condividere una quantità massima di larghezza di banda. Fino a quando la larghezza di banda utilizzata al livello di executor è inferiore alla quantità specificata, questa regola verrà considerata valida, true. Se la larghezza di banda totale è superiore a quella definita, questa regola sarà considerata non valida, false.
Di seguito vengono riportati esempi di aggiunta o impostazione di una regola sharedbandwidth:
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel value dscontrol rule set 9.20.34.11:80:shrule sharelevel value
Il valore value di sharelevel è executor o cluster. Sharelevel è un parametro obbligatorio sulla regola sharebandwidth.
Dispatcher consente di assegnare una larghezza di banda specifica a gruppi di server all'interno della configurazione mediante la regola larghezza di banda riservata. Indicando un intervallo di inizio e uno di fine, è possibile controllare il numero di kilobyte distribuiti da un gruppo di server ai client. Se la regola non è più valida (l'intervallo di fine è stato superato), verrà valutata la regola successiva con priorità inferiore. Se quest'ultima è una regola "sempre true", viene selezionato un server che risponda al client con una risposta "sito occupato".
Ad esempio: si supponga che sulla porta 2222 vi sia un gruppo di tre server. Se la larghezza di banda riservata è impostata su 300, il numero massimo di kbyte al secondo sarà 300 in un intervallo di tempo di 60 secondi. Quando questa velocità viene superata, la regola non viene più considerata valida. Se questa fosse la sola regola, Dispatcher selezionerebbe uno dei tre server per gestire la richiesta. Se ci fosse una regola "sempre true" con priorità minore, la richiesta potrebbe essere indirizzata a un altro server e ricevere una risposta "sito occupato".
La regola di larghezza di banda condivisa fornisce ai client maggiore accessibilità ai server. Nello specifico, se utilizzato come regola di priorità inferiore seguito da una regola di larghezza di banda riservata, un client può ancora accedere a un server anche se la larghezza di banda riservata è stata superata.
Ad esempio: utilizzando una regola di larghezza di banda condivisa seguita da una regola di larghezza di banda riservata, è possibile permettere ai client di accedere ai tre server in modo controllato. Fino a quando sarà possibile utilizzare una larghezza di banda, la regola verrà valutata come true e l'accesso verrà garantito. Se non è disponibile alcuna larghezza di banda condivisa, la regola non sarà true e verrà valutata la regola successiva. Se segue una regola "sempre true", la richiesta può essere indirizzata secondo necessità.
Utilizzando una larghezza di banda riservata e condivisa, come descritto nell'esempio precedente, è possibile esercitare maggiore controllo e flessibilità nel permettere (o nel negare) l'accesso ai server. I server di una porta specifica possono essere limitati nell'uso della larghezza di banda, mentre altri possono utilizzare una larghezza di banda aggiuntiva per tutto il tempo in cui questa è disponibile.
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, consultare 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.
Consultare dscontrol server -- configura i server, per informazioni dettagliate sulla sintassi di comando relativa alla funzione ignora affinità di porta mediante il server aderente .
È 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 level dscontrol rule set 9.22.21.3:80:rbweval evaluate level
Il valore evaluate level può essere impostato su porta, regola o upserversonrule. Il valore predefinito è porta.
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 port per la prima regola (valutare la condizione della regola su tutti i server della porta), nel momento in cui il traffico supera la soglia di quella regola, viene indirizzato al server "sito occupato" associato alla seconda regola.
La prima regola misura il traffico di tutti il server (compreso il server "sito occupato") sulla porta per determinare se il traffico supera la soglia. Con il diminuire della congestione dei server associati alla prima regola, potrebbe verificarsi un risultato imprevisto nel punto in cui il traffico continua sul server "sito occupato", poiché il traffico sulla porta supera ancora la soglia della prima regola.
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, consultare 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 si disabilita 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. 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.
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 poter utilizzare questa funzione, le porte devono:
È possibile collegare più porte alla stessa affinità multiporta. Quando le connessioni provengono dallo stesso client sulla stessa porta o su una porta condivisa, accedono allo stesso server. Di seguito viene riportato un esempio di configurazione di più porte con affinità multiporta sulla porta 10:
dscontrol port set cluster:20 crossport 10 dscontrol port set cluster:30 crossport 10 dscontrol port set cluster:40 crossport 10
Una volta stabilita l'affinità multiporta, è possibile modificare il valore stickytime della porta. Tuttavia, è consigliabile impostare i valori stickytime di tutte le porte condivise sullo stesso valore per evitare che si verifichino risultati imprevisti.
Per rimuovere l'affinità multiporta, impostare nuovamente il valore crossport sul numero di porta originale. Consultare dscontrol port -- configura le porte, per informazioni dettagliate sulla sintassi di comando relativa all'opzione crossport.
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 stickymask delle porte condivise, devono essere gli stessi. Per ulteriori informazioni, consultare 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.
Consultare dscontrol port -- configura le porte, per informazioni dettagliate sulla sintassi di stickymask (funzione maschera indirizzo affinità).
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. Consultare dscontrol rule -- configura le regole, per informazioni dettagliate sulla sintassi del comando.
Una volta abilitata la regola affinità cookie attivo, le nuove richieste client verranno bilanciate grazie a degli algoritmi CBR standard, mentre le richieste successive provenienti dallo stesso client verranno inviate al server scelto inizialmente. Quest'ultimo viene memorizzato come cookie nella risposta per il client. Fino a quando le future richieste del client conterranno il cookie, e ogni richiesta arriva nell'intervallo stickytime stabilito, il client conserverà l'affinità con il server iniziale.
L'affinità cookie attivo viene utilizzata per garantire che un client continui ad essere bilanciato con lo stesso server per un determinato periodo di tempo. Ciò è possibile inviando un cookie che verrà memorizzato dal browser dei client. Il cookie contiene la regola cluster:port:rule utilizzata per prendere la decisione, il server in base al quale è stato bilanciato il carico e la data e l'ora di scadenza che indicano la fine della validità dell'affinità. Il cookie è nel seguente formato: IBMCBR=cluster:port:rule+server-time! Le informazioni cluster:port:rule e server sono codificate per impedire che la configurazione CBR venga rivelata.
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.
Su sistemi AIX, Solaris e Linux, il file cbrserver si trova nella directory /usr/bin.
Su sistemi Windows, il file cbrserver si trova nella directory \winnt\system32.
L'affinità cookie passivo si applica al metodo di inoltro cbr (content-based routing) del componente Dispatcher e al componente CBR. Consultare Instradamento basato sul contenuto di Dispatcher (metodo di inoltro cbr) per informazioni su come configurare il metodo di inoltro cbr di Dispatcher.
L'affinità cookie passivo permette di rendere aderenti i client di un particolare server. Abilitando l'affinità di una regola su "passivecookie", l'affinità cookie passivo consente di bilanciare il carico del traffico Web con caratteristiche di affinità con lo stesso server tramite la creazione di cookie auto-identificativi da parte dei server. È possibile configurare l'affinità cookie passivo al livello della regola.
Quando viene generata la regola, se l'affinità cookie passivo è abilitata, Load Balancer sceglierà il server in base al nome cookie nell'intestazione HTTP della richiesta client. Load Balancer confronta il nome del cookie dell'intestazione HTTP del client con il valore del cookie configurato per ciascun server.
La prima volta in cui Load Balancer rileva un server il cui valore cookie contiene il nome cookie del client, Load Balancer sceglie quel server per la richiesta.
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. Consultare Instradamento basato sul contenuto di Dispatcher (metodo di inoltro cbr) per informazioni su come configurare il metodo di inoltro cbr.
L'affinità URI permette di bilanciare il carico del traffico Web sui server Caching Proxy che consentono di memorizzare nella cache il contenuto unico di ciascun server. In questo modo, si aumenta effettivamente la capacità della cache del sito evitando che i contenuti vengano memorizzati su più macchine. Configurare l'affinità URI al livello della regola. Una volta creata la regola, se l'affinità URI è abilitata e lo stesso gruppo di server è attivo e risponde, Load Balancer inoltra le richieste in arrivo dei client con lo stesso URI sullo stesso server.
Normalmente, Load Balancer può distribuire le richieste su più server che supportano lo stesso contenuto. Se si utilizza Load Balancer con un gruppo di caching server, i contenuti più esaminati vengono memorizzati nella cache di tutti i server. Questo consente di supportare un carico di client molto elevato riproducendo i contenuti identici memorizzati nella cache su più macchine. Questo espediente risulta molto utile quando si gestiscono siti Web con un volume elevato di traffico.
Tuttavia, se il sito Web supporta un volume ridotto di traffico client di diverso contenuto, e si preferisce avere maggiore disponibilità di cache sui vari server, il sito funzionerebbe meglio se ogni caching server avesse un contenuto unico e Load Balancer distribuisse la richiesta esclusivamente al caching server con quel contenuto.
Con l'affinità URI, Load Balancer permette di distribuire il contenuto memorizzato nella cache sui singoli server, evitando una memorizzazione ridondante su più macchine. Con questo potenziamento, si migliorano anche le prestazioni dei siti server di diverso contenuto che utilizzano i server Caching Proxy. Le stesse richieste vengono inviate allo stesso server, per cui il contenuto viene memorizzato nella cache dei singoli server. Quindi, la dimensione effettiva della cache aumenta ogni volta che si aggiunge una nuova macchina server al lotto.
Per configurare l'Affinità URI:
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 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 (consultare 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 dai relativi server collegati localmente (ServerG, ServerH e ServerI). Un pacchetto client andrà da Internet alla macchina Dispatcher iniziale. Dal Dispatcher iniziale, il pacchetto raggiunge la macchina Dispatcher che si trova in una posizione geograficamente remota e uno dei server collegati localmente.
Tutte le macchine Dispatcher (locale e remota) devono eseguire lo stesso tipo di sistema operativo e piattaforma per poter creare delle configurazioni WAN.
Figura 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 pacchetto può avere dei server locali collegati e può distribuire il carico tra i server locali e quelli remoti.
Per configurare il supporto rete geografica:
dscontrol server add cluster:port:server router address
Per maggiori informazioni sulla parola chiave router, consultare 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 my_cluster_address my_mac_address 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, Sistemi 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 è il Load Balancer "entry-point". Viene utilizzata una connessione Ethernet. Notare che LB1 ha cinque server definiti: tre locali (ServerA, ServerB, ServerC) e due remoti (LB2 e LB3). I server remoti LB2 e LB3 hanno, ognuno, altri tre server locali definiti.
Sulla console del primo Dispatcher (LB1), eseguire queste operazioni:
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. Questo permette al Load Balancer entry-point di bilanciare il carico direttamente sui server WAN di Linux, senza passare per un Load Balancer in una posizione remota. Ciò consente agli advisor di Load Balancer entry-point di funzionare direttamente con ogni server remoto.
Su Load Balancer entry point, eseguire una configurazione come quella descritta per WAN.
Per configurare ogni server di 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 cluster address 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 AIX, questa configurazione può trarre vantaggio dalle velocità elevate di High Performance Switch SP se le macchine del Dispatcher e del server TCP sono in esecuzione sui nodi in un Frame SP.
Per creare una rete privata, ogni macchina deve avere almeno due schede LAN, una delle quali collegata alla rete privata. È necessario, inoltre, configurare la seconda scheda LAN su una rete secondaria diversa. La macchina del Dispatcher invierà le richieste client alle macchine del server TCP attraverso la rete privata.
Su sistemi Windows: configurare l'indirizzo di non inoltro mediante il comando executor configure.
I server aggiunti con il comando dscontrol server add devono essere aggiunti mediante gli indirizzi di rete privati; ad esempio, facendo riferimento all'esempio del server Apple nella Figura 39, il comando dovrebbe essere codificato come:
dscontrol server add cluster_address:80:10.0.0.1
non
dscontrol server add cluster_address:80:9.67.131.18
Se si sta utilizzando Site Selector per fornire al Dispatcher informazioni sul carico, configurare Site Selector per notificare i carichi sugli indirizzi privati.
Figura 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ò vuol dire che un client, con una connessione esistente che passa per un cluster di bilanciamento del carico e arriva a una porta di controllo FTP, avrà connessioni di controllo e le connessioni con numero di porta elevato (porta >1023), destinate allo stesso cluster, automaticamente indirizzate da Load Balancer verso lo stesso server della connessione di controllo FTP.
Se la porta jolly e la porta FTP sullo stesso cluster non hanno lo stesso gruppo di server, le applicazioni con numero di porta elevato (porta >1023) potrebbero non funzionare correttamente se un client utilizza una connessione di controllo FTP esistente. Quindi, non è consigliabile configurare diversi gruppi di server per le porte jolly e FTP sullo stesso cluster. Se si vuole questo tipo di scenario, impostare l'intervallo di porte passive del daemon FTP nella configurazione Load Balancer.
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 poter eseguire i file, è necessario spostarli sulla directory ...ibm/edge/lb/servers/bin e rimuovere l'estensione ".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:
Controller Cisco CSS o Controller Nortel Alteon possono risiedere sulla medesima macchina di un server per cui si sta effettuando il bilanciamento di carico delle richieste. Questa operazione viene comunemente denominata come posizionamento di un server. Non sono necessarie ulteriori procedure di configurazione.
La funzione di disponibilità elevata è ora disponibile per Controller Cisco CSS e Controller Nortel Alteon.
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 la sintassi completa di 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 primaria 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 secondario. 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 monitora 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 relativo alla strategia deve essere impostato sullo stesso valore su entrambe le macchine.
Per gli esempi di configurazione della funzione di disponibilità elevata per Controller Cisco CSS, vedere Esempi.
Per gli esempi di configurazione della funzione di disponibilità elevata per Controller Nortel Alteon, 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, alle informazioni restituite dagli advisor e alle informazioni restituite 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 dei 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 a 10 riceverà il doppio delle richieste del server impostato a 5.
Se un advisor rileva che un server è inattivo, il peso per tale server viene impostato a -1. Per Cisco CSS Controller e Controller Nortel Alteon, 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 sul comando nalcontrol server per Controller Nortel Alteon.
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 interval
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 ottenere il rilevamento più rapido dei server che non hanno funzionato correttamente, impostare i timeout di connessione e di ricezione dell'advisor sul valore più piccolo (un secondo) e impostare il tempo di inattività dell'advisor e del consultant 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 alcuna 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 di 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.
Sulla piattaforma Windows, un comando di compilazione potrebbe essere:
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.
Su 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, l'advisor di base effettua le operazioni di connessione e chiusura del socket e fornisce i metodi di invio e di ricezione che saranno utilizzati dall'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
Il listato del programma di un advisor di esempio di un controller è riportato in Advisor di esempio. Dopo l'installazione, questo advisor di esempio può essere trovato 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 Controller Nortel Alteon.
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 Controller Nortel Alteon, aggiungere uno switch del consultant, quindi aggiungere un service.
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 Java.
Facoltativamente, è possibile scrivere dei file script delle metriche personalizzati che definiscano il comando che Metric Server 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 del 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.
Su sistemi Windows: creare l'alias di OTHER_ADDRESS sullo stack Microsoft. Per creare l'alias di un indirizzo sullo stack Microsoft, vedere a 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 delle istantanee delle informazioni 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 desiderato 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 rinominare ciascun file in base alle istruzioni contenute nello script.
Vengono forniti i seguenti script di esempio, dove xxx sta per cco per Cisco CSS Controller e nal per Controller Nortel Alteon:
Questa sezione contiene informazioni sulla gestione e sulla risoluzione dei problemi di Load Balancer. Contiene i seguenti capitoli:
IMPORTANTE: se si sta utilizzando l'installazione di Load Balancer per IPv4 e IPv6, consultare Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6 per evidenziare le limitazioni e le differenze di configurazione prima di esaminare i contenuti di questo capitolo.
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 Load Balancer 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:remote_host .
Se la chiamata RMI proviene da una macchina diversa da quella locale, deve verificarsi una sequenza di autenticazione della chiave pubblica/chiave privata la sequenza di autenticazione deve verificarsi prima di accettare il comando di configurazione.
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 è: component-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)
Sui 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://host_name/lb-admin/lbadmin.html
Dove host_name è 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 Load Balancer. Per modificare questo percorso, impostare la variabile lb_logdir nello script dsserver.
Su 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/
Su sistemi Windows: il file dsserver si trova nella directory di sistema Windows C:\WINNT\SYSTEM32, in 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 Uso della registrazione binaria per analizzare le statistiche dei server.
È 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 dei log 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 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.
Controller Cisco CSS e Controller Nortel Alteon hanno i seguenti 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.
Su 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/
Su sistemi Windows: il file xxxserver si trova nella directory del sistema Windows, generalmente 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 Uso 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 pacchetto FIN dopo aver inviato tutti i pacchetti in modo che il server rilevi il termine della transazione. Quando Dispatcher riceve il pacchetto 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, consultare 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) SNMP (ibmNetDispatcherMIB) e un agente secondario SNMP. Ciò consente di utilizzare un qualsiasi sistema di gestione della rete, quale -- Tivoli NetView, Tivoli Distributed Monitoring o 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 (Distributed Program Interface). DPI è un'interfaccia che consente la comunicazione 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 in 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 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 pacchetto UCD SNMP. Il pacchetto 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 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 Sistemi Linux e UNIX, a causa delle limitazioni delle API SMUX, l'identificatore azienda riportato nelle trap dall'agente secondario ibmNetDispatcher potrebbe essere l'identificatore azienda di dpid2, anziché l'identificatore 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 Linux Load Balancer, che potrebbe essere, ad esempio, una macchina Load Balancer 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 pacchetto 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: 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 in Esempio di configurazione di 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 Uso 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 una descrizione più dettagliata, vedere Uso dei log di Load Balancer.
Dopo aver avviato Controller Cisco CSS, è possibile controllarlo utilizzando uno dei seguenti metodi:
I log utilizzati da Controller Cisco CSS sono simili a quelli utilizzati in Dispatcher. Per una descrizione più dettagliata, vedere Uso dei log di Load Balancer.
Dopo aver avviato Controller Nortel Alteon, è possibile controllarlo utilizzando uno dei seguenti metodi:
I log utilizzati da Controller Nortel Alteon sono simili a quelli utilizzati in Dispatcher. Per una descrizione più dettagliata, vedere Uso 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 (per 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
Su sistemi AIX, HP-UX, Linux e Solaris: netstat -ni
Su sistemi Windows: ipconfig /all
Questo dato deve essere ottenuto da tutti i server e Load Balancer.
Su sistemi AIX, HP-UX, Linux e Solaris: netstat -nr
Su 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.
Su sistemi AIX, HP-UX, Linux e Solaris: /opt/ibm/edge/lb/servers/bin
Su 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 nomeAdvisor porta livello di log
o
dscontrol advisor loglevel nomeAdvisor cluster:porta livello di log
o
nalcontrol metriccollector set IDconsultant:IDservizio:nomeMetrica 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
Su piattaforme Windows: C:\Program Files\ibm\edge\lb\servers\logs\componente
Dove componente è:
dispatcher = Dispatcher
cbr = Content Based Routing
cco = Cisco CSS Controller
nal = Controller Nortel Alteon
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
Su 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.
Su sistemi AIX e HP-UX: netstat -ni
Su sistemi Linux e Solaris: ifconfig -a
Su 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 and host client
Potrebbe essere necessario scaricare tcpdump da uno dei siti di archivi software GNU per HP-UX.
tcpdump -i eth0 host cluster and host client
Eseguire la traccia, ricreare il problema e interrompere il processo.
snoop -v indirizzoIPclient indirizzoIPdestinazione > 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.
Vedere Informazioni di riferimento per link a pagine Web di assistenza e librerie. La pagina Web di assistenza contiene un link a informazioni di "autoassistenza" sotto forma di Technote.
Vedere quanto segue per:
Tabella 14. 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 Dispatcher 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: messaggio di errore "Impossibile trovare il file... quando si tenta di visualizzare la guida in linea (piattaforma Windows) |
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 di file di 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 Load Balancer in coreano visualizza font sovrapposti o indesiderati su AIX e Linux |
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 | 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 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 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 di grandi dimensioni | 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 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, primaria e di riserva | Questo problema può verificarsi quando gli script "go" non vengono eseguiti sulla macchina primaria o di riserva. | Problema: in una configurazione a disponibilità elevata, sono attive entrambe le macchine, primaria e di riserva |
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 immette 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 ad alta disponibilità 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 alla configurazione del Dispatcher quando si utilizzano server zSeries o S/390 che utilizzano 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 Linux, si verifica una mancanza di memoria quando viene eseguito il Dispatcher con il gestore e gli advisor |
Su SUSE Linux Enterprise Server 9, il prospetto 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, Dispatcher inoltra i pacchetti, ma i pacchetti non raggiungono il server di backend |
Su sistemi Windows, quando si utilizza la funzione ad alta disponibilità del 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, un messaggio di conflitto di indirizzi IP viene visualizzato durante un takeover HA |
Su 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: Linux iptables può interferire con l'instradamento dei pacchetti |
Su sistemi Solaris, quando si prova a configurare un server IPv6 sulla macchina del Dispatcher, viene visualizzato il messaggio "impossibile aggiungere il server" | Tale messaggio può essere causato dal modo in cui il sistema operativo Solaris gestisce la richiesta di ping per un indirizzo IPv6. | Problema: impossibile aggiungere un server IPv6 alla configurazione di Load Balancer su sistemi Solaris |
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 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 |
Tabella 15. 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 su 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 su un nome host quando su una scheda sono configurati più indirizzi |
Su 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 |
Tabella 16. 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 non 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 |
Su 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 |
Tabella 17. tabella di risoluzione dei problemi di Controller per 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 |
Su 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 |
Tabella 18. tabella di risoluzione dei problemi di Controller Nortel Alteon
Sintomo | Possibile causa | Andare a... |
---|---|---|
Mancato avvio di nalserver | Numeri di porta in conflitto | Controllo dei numeri di porta di Controller Nortel Alteon |
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 |
Su 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 |
Tabella 19. Tabella di risoluzione dei problemi di Metric Server
Sintomo | Possibile causa | Andare a... |
---|---|---|
Metric Server IOException su piattaforma Windows durante l'esecuzione di file di metrica utente .bat o .cmd | È richiesto il nome completo della metrica | Problema: Metric Server IOException 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 |
Su 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 |
Impostazione 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 |
Su 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 |
Su sistemi Linux, quando si esegue Load Balancer per IPv6, non è possibile richiamare i valori da Metric Server | Esiste una incompatibilità di selezione degli indirizzi IPv6 quando si utilizzano piattaforme Linux. Come risultato, Metric Monitor prova a comunicare con Metric Server sull'indirizzo IP di origine non corretto. | Problema: su Load Balancer per IPv6, non è possibile richiamare i valori da Metric Server su sistemi Linux |
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: dop oaver 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 Dispatcher. 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 Selector 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 CSS Controller, è 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 Controller Nortel Alteon, questo potrebbe essere dovuto al fatto che una delle applicazioni utilizza un numero di porta normalmente utilizzato da nalserver di Controller Nortel Alteon. Tenere presente che Controller Nortel Alteon 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 Controller Nortel Alteon, è possibile modificare i numeri di porta di Controller Nortel Alteon o i numeri di porta dell'applicazione.
Per modificare i numeri di porta di Controller Nortel Alteon, 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. Inoltre, verificare che il file hosts 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 la loro presenza ed eliminarli, vedere 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 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 immettono 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 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 indirizzoMAC
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 questo dato. 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.
Ad esempio, se 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 riserva, 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 dev'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 AIX, sostituire "java" con "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.
Su 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 la gestione 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 con un bind specifico. 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 ND 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 per un bind specifico (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 riserva.
Per risolvere questo problema, impedire al sistema operativo Windows di cancellare la cache ARP quando viene persa 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 indirizzoCluster 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 a un valore diverso da 0, si indica che si tratta di un server remoto, su un'altra sottorete. Per ulteriori informazioni sul parametro router del 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 primaria o di riserva. 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 primaria 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 primaria. 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 <valore>
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 entro un periodo staletimeout ragionevole, è possibile aumentare il valore di timeout della sincronizzazione emettendo il comando:
e xm 33 5 new_timeoutQuesto comando non viene memorizzato nel file di configurazione quando viene salvato, pertanto è necessario aggiungerlo manualmente al file di configurazione se si desidera che questa impostazione venga conservata in seguito a un riavvio.
Il valore di timeout è memorizzato su un secondo e mezzo; per questo motivo, il valore predefinito per new_timeout è 100 (50 secondi).
In generale, quando si utilizza il metodo di inoltro MAC, i server nella configurazione di Load Balancer devono trovarsi tutti sullo stesso segmento di rete, indipendentemente dalla 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 a host sulla stessa scheda OSA o a host sulla scheda Ethernet. Tutti gli host sulla stessa scheda OSA condivisa si trovano sullo stesso segmento.
Load Balancer può 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 pacchetto 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 pacchetto. 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 pacchetto IP client->cluster viene ricevuto da Load Balancer, viene integrato e quindi inviato al server. Sul server, il pacchetto 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 in modo che utilizzi la funzione GRE, aggiungere i server mediante il seguente comando:
dscontrol server add cluster_add:port:server_backend router server_backend
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 indirizzo_cluster dev grelb0
Quando si esegue Load Balancer configurato con le funzioni del gestore e degli advisor, si verifica una mancanza di memoria su alcune versioni di 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 strumento di determinazione dei problemi, utilizzare il comando vmstat o ps per rilevare la mancanza di memoria.
Per risolvere questo problema, emettere il seguente comando prima di eseguire 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 prospettodel Dispatcher indica che il pacchetto è stato inoltrato (il numero di pacchetti aumenta) ma il pacchetto non raggiunge il server di backend.
È possibile che si verifichi quanto riportato di seguito:
ip_finish_output2: Nessuna cache di intestazione e nessun elemento vicino.
Destinazione ICMP non raggiungibile: è necessaria una frammentazione
Questo problema si verifica a causa del modulo NAT iptables che viene 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 nello stesso 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, e quindi ip_conntrack module.
Su 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 primaria:
dscontrol executor unconfigure clusterIP
Tale comando rimuove l'indirizzo 0.0.0.0 dallo stack IP Windows.
Quando il partner HA rilascia l'indirizzo IP del cluster, emettere il seguente comando per aggiungere manualmente di nuovo l'indirizzo IP del cluster:
dscontrol executor configure clusterIP
Dopo aver emesso questo comando, ricercare l'indirizzo IP del cluster sullo stack IP di Windows 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 determinare se iptables sono state caricate:
lsmod | grep ip_tables
L'output del comando precedente può essere simile al seguente:
ip_tables 22400 3 iptable_mangle,iptable_nat,iptable_filter
Emettere il seguente comando per ogni iptable riportata nell'output per visualizzare le regole per le tabelle:
iptables -t <short_name> -L
For example:
iptables -t mangle -L iptables -t nat -L iptables -t filter -L
Se iptable_nat viene caricata, allora questa deve essere scaricata. Poiché iptable_nat ha una dipendenza su iptable_conntrack, è necessario anche rimuovere iptable_conntrack. Emettere il seguente comando per scaricare queste due iptables:
rmmod iptable_nat iptable_conntrack
Su sistemi Solaris, quando si prova a configurare un server IPv6 su una installazione Load Balancer per IPv4 e IPv6, viene visualizzato il messaggio impossibile aggiungere il server. Tale messaggio può essere causato dal modo in cui il sistema operativo Solaris gestisce la richiesta di ping per un indirizzo IPv6.
Su sistemi Solaris, quando si aggiunge un server alla configurazione, Load Balancer prova a eseguire il ping al server per ottenere l'indirizzo MAC del server. La macchina Solaris può scegliere l'indirizzo del cluster configurato come indirizzo di origine della richiesta ping invece che utilizzare l'indirizzo NFA della macchina. Se l'indirizzo del cluster è configurato sul loopback del server, la risposta al ping non viene ricevuta sulla macchina Load Balancer e pertanto il server non viene aggiunto alla configurazione.
La soluzione sta nel configurare un altro indirizzo IPv6 sulla macchina Load Balancer prima o dopo la configurazione dell'indirizzo del cluster IPv6. Questo indirizzo deve essere un indirizzo senza alias sul loopback del server di backend che si sta provando ad aggiungere alla configurazione di Load Balancer. Quindi aggiungere il server alla configurazione di Load Balancer.
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 pacchetto Metric Server, il pacchetto di gestione e il pacchetto 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.
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 immettono 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 la gestione 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:
Fare riferimento a *** per istruzioni sulla configurazione di questa impostazione.
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.
Fare riferimento a pagina *** per le fasi di configurazione del nome host come primo nel registro.
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 immettono 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 la gestione 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:
Fare riferimento a *** per istruzioni sulla configurazione di questa impostazione.
Questo problema può verificarsi quando un'altra applicazione utilizza una delle porte utilizzate da Cisco CSS Controller ccoserver. 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 immettono 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 la gestione 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 Controller Nortel Alteon nalserver. Per ulteriori informazioni, vedere Controllo dei numeri di porta di Controller Nortel Alteon.
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 immettono 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 la gestione 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, o 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.
Esiste una incompatibilità di selezione degli indirizzi IPv6 quando si utilizzano piattaforme Linux. Come risultato, Metric Monitor prova a comunicare con Metric Server sull'indirizzo IP di origine non corretto.
Su sistemi Linux, la selezione dell'indirizzo di origine IPv6 per un determinato instradamento fa riferimento all'ultimo indirizzo configurato che corrisponde alla parte di rete dell'instradamento.
Se l'ultima interfaccia configurata è un cluster IPv6 e tale interfaccia corrisponde alla porzione di rete di un'instradamento nella tabella di routing, allora l'interfaccia viene utilizzata come indirizzo IP di origine predefinito per l'instradamento. Se tale instradamento viene utilizzato tra Load Balancer e Metric Server, la comunicazione tra i due nodi non verrà stabilita.
La comunicazione non viene stabilita poiché il nodo di Load Balancer prova a comunicare con Metric Server mediante l'indirizzo del cluster come indirizzo IP di origine. Quando il cluster viene configurato sul loopback del nodo di Metric Server, la risposta da Metric Server va al loopback e la comunicazione non viene stabilita.
Soluzione:
Per determinare l'indirizzo utilizzato dal nodo Linux per il determinato instradamento e l'interfaccia utilizzata per le comunicazioni RMI tra Metric Monitor e Metric Server, emettere il seguente comando:
ip -6 route get your_ipv6_route
Ad esempio, quando si emette il comando:
ip -6 route get fec0::/64
viene restituito:
fec0:: via fec0:: dev eth0 src fec0::4 metric 0 cache mtu 1500 advmss 1383
Se fec0::4 è un indirizzo del cluster, è necessario aggiungere un'altra interfaccia al dispositivo in modo da evitare che il cluster venga utilizzato come origine predefinita altrimenti una precedente interfaccia non cluster non potrà essere rimossa e quindi aggiunta di nuovo.
Ad esempio:
ip -6 addr add fec0::5/64 dev eth0
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 è user_id e la variabile facoltativa è password. Sostituire le variabili con i propri valori.
>>-user--user_id--+----------+--------------------------------->< '-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:port------------------------------------------------><
Questo capitolo descrive come utilizzare i comandi dscontrol del 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 ulteriori informazioni, vedere Differenze di configurazione tra CBR e Dispatcher.
IMPORTANTE: se si sta utilizzando l'installazione Load Balancer per IPv4 e IPv6 di questo prodotto, è disponibile solo il componente Dispatcher. Il Dispatcher di questo tipo di installazione utilizza una serie secondaria di comandi dscontrol elencata in questo riferimento sui comandi. Quando si utilizzano questi diagrammi di sintassi, utilizzare il carattere at (@) al posto del carattere due punti (:) come delimitatore nel comando dscontrol. Per ulteriori informazioni fare riferimento a Differenze di sintassi dei comandi e a Comandi dscontrol supportati per l'installazione Load Balancer per IPv4 e IPv6.
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 del comando 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--name--+-port---------+--timeoutseconds-+->< | '-cluster:port-' | +-interval--name--+-port---------+--seconds--------------+ | '-cluster:port-' | +-list---------------------------------------------------+ +-loglevel--name--+-port---------+--level----------------+ | '-cluster:port-' | +-logsize--name--+-port---------+--+-unlimited---------+-+ | '-cluster:port-' '-number of records-' | +-receivetimeout--name--+-port---------+--timeoutseconds-+ | '-cluster:port-' | +-report--name--+-port---------+-------------------------+ | '-cluster:port-' | +-retries--name--+-port---------+--numretries------------+ | '-cluster:port-' | +-start--name--+-port---------+--+----------+------------+ | '-cluster:port-' '-log file-' | +-status--name--+-port---------+-------------------------+ | '-cluster:port-' | +-arrestare--name--+-port---------+----------------------+ | '-cluster:port-' | +-timeout--name--+-port---------+--+-unlimited-+---------+ | '-cluster:port-' '-seconds---' | '-versione--name--+-port---------+-----------------------' '-cluster:port-'
Consultare Elenco di advisor per ulteriori informazioni sugli advisor forniti da Load Balancer.
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, consultare Creazione di advisor personalizzati.
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 è advisorname_port.log, ad esempio, http_80.log. Per modificare la directory su cui vengono memorizzati i file di log, consultare 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----------------------+----------->< +-arrestare------------------+ +-set--+-retention--hours--+-+ | '-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, consultare 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--time------------+ | | +-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_address-----------------------------------+ +-start------------------------------------------------------------+ +-status-----------------------------------------------------------+ '-stop-------------------------------------------------------------'
Il timer viene utilizzato per garantire che la macchina primaria 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 comandohasynctimeout 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 File (file3) was deleted.
dscontrol file newload file1.sv File (file1.sv) was loaded into the Dispatcher.
dscontrol file appendload file2.sv File (file2.sv) was appended to the current configuration and loaded.
dscontrol file report FILE REPORT: file1.save file2.sv file3
dscontrol file save file3 The configuration was saved into file (file3).
>>-dscontrol--help--+-advisor----------+----------------------->< +-binlog-----------+ +-cluster----------+ +-executor---------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-host-------------+ +-logstatus--------+ +-manager----------+ +-metric-----------+ +-port-------------+ +-rule-------------+ +-server-----------+ +-set--------------+ +-status-----------+ '-subagent---------'
Esempi
guida dscontrolQuesto comando produce un output simile a:
HELP COMMAND ARGUMENTS: --------------------------------- Usage: help <help option> Example: help cluster help - print complete help text advisor - help on advisor command cluster - help on cluster command executor - help on executor command file - help on file command host - help on host command binlog - help on binary log command manager - help on manager command metric - help on metric command port - help on port command rule - help on rule command server - help on server command set - help on set command status - help on status command logstatus - help on server log status subagent - help on subagent command highavailability - help on high availability commandNotare 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:remote_host
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-+-----------------+ | '-byte------' | +-metric set--+-loglevel--level--------+-+ | '-logsize--+-unlimited-+-' | | '-byte------' | +-quiesce--server--+-----+---------------+ | '-now-' | +-reach set--+-interval--seconds------+--+ | +-loglevel--level--------+ | | '-logsize--+-unlimited-+-' | | '-byte------' | +-refresh--refresh cycle-----------------+ +-report--+----------------+-------------+ | '-cluster+c2+...-' | +-restart--message-----------------------+ +-sensitivity--weight--------------------+ +-smoothing--smoothing index-------------+ +-start--+-----------------------+-------+ | '-log file--metric_port-' | +-status---------------------------------+ +-arrestare------------------------------+ +-unquiesce--server----------------------+ '-versione-------------------------------'
Altrimenti, se è stata adoperata la suddivisione in partizioni del server, utilizzare il nome univoco del server logico. Per ulteriori informazioni, consultare 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, consultare 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 Restarting the manager to update code
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-----+ | | +-Metodo--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, consultare 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, consultare 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.
Consultare Affinità cookie attivo, Affinità cookie passivo e Affinità URI per ulteriori informazioni.
Per ulteriori informazioni, consultare Affinità cookie passivo.
Per la regola di tipo connection, è 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, consultare 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, consultare 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--+-byte------+-------------+ | '-unlimited-' | +-report-----------------------------+ +-start--+-------------------------+-+ | '-community_name--logfile-' | +-status-----------------------------+ +-arrestare--------------------------+ '-versione---------------------------'
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. A tal fine, è sufficiente immettere 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-' '-byte-------------' | +-receivetimeout--name--+-port----------+--seconds-------+ | '-sitename:port-' | +-report--name--+-Porta---------+------------------------+ | '-sitename:port-' | +-retries--name--+-port----------+--numretries-----------+ | '-sitename:port-' | +-avviare--name--+-port----------+--+----------+---------+ | '-sitename:port-' '-log file-' | +-status--name--+-port----------+------------------------+ | '-sitename:port-' | +-arrestare--name--+-port----------+---------------------+ | '-sitename:port-' | +-timeout--name--+-port----------+-----------------------+ | '-sitename:port-' | '-versione--name--+-port----------+--seconds-------------' '-sitename:port-'
.
Nome advisor | Protocollo | Porta |
---|---|---|
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 è advisorname_port .log, ad esempio, http_80.log. Per modificare la directory su cui vengono memorizzati i file di log, consultare 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: --------------------------------- Usage: help <help option> Example: help name help - print complete help text advisor - help on advisor command file - help on file command host - help on host command manager - help on manager command metric - help on metric command sitename - help on sitename command nameserver - help on nameserver command rule - help on rule command server - help on server command set - help on set command status - help on status command logstatus - help on logstatus commandI 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-+-----------------+ | '-byte------' | +-metric set--+-loglevel--level--------+-+ | '-logsize--+-unlimited-+-' | | '-byte------' | +-reach set--+-interval--seconds------+--+ | +-loglevel--level--------+ | | '-logsize--+-unlimited-+-' | | '-byte------' | +-report--sitename+sn2+...+snN-----------+ +-restart--message-----------------------+ +-sensitivity--weight--------------------+ +-smoothing--smoothing index-------------+ +-avviare--+----------------------+------+ | '-logfile--metric_port-' | +-status---------------------------------+ +-arrestare------------------------------+ '-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, consultare 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--+-avviare--+----------------------+-+->< | '-bindaddress--address-' | +-arrestare-------------------------+ '-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 Controller:
È 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 terminare l'interfaccia della riga comandi: digitare 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 - operate on the controller consultant - operate on switch consultants file - operate on configuration files help - operate on help highavailability - operate on high availability metriccollector - operate on metric collectors ownerContent - operate on ownerContents service - operate on services
>>-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 | Porta |
---|---|---|
connect | 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 comandi nalcontrol riportati di seguito per Controller Nortel Alteon:
È 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: immettere exit o quit.
>>-nalcontrol--consultant--+-add--scID--address--swIPAddr--+---------------------------+-+->< | +-rcommunity--readCommName--+ | | '-wcommunity--writeCommName-' | +-binarylog--scID+scID2...--+-report------------------------+-+ | +-set--+-interval--interval---+-+ | | | '-retention--retention-' | | | +-avviare-----------------------+ | | '-arrestare---------------------' | +-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 native -- 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:
The following commands are available: controller - operate on the controller consultant - operate on switch consultants file - operate on configuration files help - operate on help highavailability - operate on high availability metriccollector - operate on metric collectors server - operate on servers service - operate on services
>>-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-' | +-arrestare-------------------------------+ +-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--server--+-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------+->< +-metriche--scID+scID2...:svcID+svcID2...--mN--importanza--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 metrica validi e delle porte associate.
Nome advisor | Protocollo | Porta |
---|---|---|
connect | 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, Content Based Routing (CBR), Site Selector, Controller Cisco CSS e Controller Nortel Alteon elencati come componenti.
Se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, solo il componente Dispatcher è disponibile. Per ulteriori informazioni, vedere Distribuzione di Dispatcher su Load Balancer per IPv4 e IPv6.
Per esempi grafici della GUI di Load Balancer che evidenziano ciascuno dei diversi componenti, fare riferimento a quanto indicato di seguito:
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 di 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>>.
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 (" ") 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>>.
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 Notes 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.
IMPORTANTE: se si utilizza l'installazione di Load Balancer per IPv4 e IPv6, ricordarsi di sostituire i due punti (:) con il simbolo at (@) come delimitatore nei comandi dscontrol in questi file di configurazione di esempio.
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, 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.
# Anche in questo caso, è possibile utilizzare il nome host o
# 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 comando
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à 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 ulteriori informazioni sulla capacità di un rem server di ricevere le richieste e 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 a 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 comando 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 Load Balancer.
* 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
* a Load Balancer da utilizzare nell'algoritmo di valutazione di Load Balancer. Inoltre,
* tale advisor 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.
*
* DENOMINAZIONE
*
* 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 pacchetto 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. Load Balancer
* 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 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 non può offrire in altri paesi i prodotti, i servizi o le funzioni descritti in questo documento. Per le informazioni sui prodotti ed i servizi disponibili al momento nella propria area, rivolgersi al rivenditore IBM locale. Qualunque riferimento relativo a prodotti, programmi o servizi IBM non implica che solo quei prodotti, programmi o servizi IBM possano essere utilizzati. In sostituzione a quelli forniti da IBM, possono essere usati prodotti, programmi o servizi funzionalmente equivalenti che non comportino violazione dei diritti di proprietà intellettuale o di altri diritti dell'IBM. È tuttavia responsabilità dell'utente valutare e verificare la funzionalità di tali prodotti, programmi o servizi non IBM.
IBM può avere brevetti o domande di brevetto in corso relativi a quanto
trattato nel presente 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 domande sulle licenze relative a informazioni DBCS, contattare IBM
Intellectual Property Department nel proprio paese oppure scrivere 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 contenuti in tali siti Web non fanno parte della documentazione per questo prodotto IBM e il loro utilizzo è a discrezione dell'utente.
IBM può utilizzare o distribuire qualsiasi informazione fornita dall'utente nel modo più appropriato senza incorrere in alcuna obbligazione.
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.
Queste informazioni possono essere rese disponibili secondo condizioni contrattuali appropriate, compreso, in alcuni casi, l'addebito di un canone.
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 ambienti operativi diversi possono variare in modo considerevole. 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 di questa pubblicazione devono verificare che i dati siano applicabili al loro specifico ambiente.
Le informazioni relative a prodotti non IBM sono state ottenute dai fornitori di tali prodotti. IBM non ha verificato tali prodotti e, pertanto, non può garantirne l'accuratezza delle prestazioni o la compatibilità. 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 i nomi contenuti nella guida sono fittizi e ogni riferimento a nomi ed indirizzi reali è 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
NetView
OS/2
Redbook
RS/6000
SecureWay
ViaVoice
WebSphere
zSeries
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, in altri paesi o in entrambi.
Intel, Intel Inside (loghi), MMX and Pentium sono marchi di Intel Corporation negli Stati Uniti, in altri paesi o in entrambi.
UNIX è un marchio registrato 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à.