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:
lbkeys [create|delete]
Questo comando viene eseguito solo sulla stessa macchina di Load Balancer.
L'utilizzo dell'opzione create consente di creare una chiave privata nella directory delle chiavi del server:
Il file script crea inoltre le chiavi pubbliche nella directory delle chiavi di amministrazione 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 seguente directory 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:
Per sistemi Windows —
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\PROGRA~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\PROGRA~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\PROGRA~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\PROGRA~1\IBM\edge\lb\admin\* Pass /documentation/lang/* C:\PROGRA~1\IBM\edge\lb\documentation\lang\*dove lang è la directory secondaria della lingua (ad esempio, en_US)
Per sistemi operativi AIX, HP-UX, Linux e Solaris —
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 log per definire l'estensione dei messaggi scritti sul log. A livello 0, gli errori vengono registrati e Load Balancer registra anche le intestazioni e i record degli eventi che si sono verificati una volta sola (ad esempio, un messaggio relativo all'inizio della scrittura dell'advisor 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/
Sistemi Windows: il file dsserver si trova nella directory <root_installazione>ibm\edge\lb\bin. 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. Consultare 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.
Cisco CSS Controller 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/
Sistemi Windows: il file xxxserver si trova nella directory <root_installazione>ibm\edge\lb\bin. 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. Consultare 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. Consultare Uso del valore timeout di inattività per ulteriori informazioni.
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.
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 sistemi Solaris nella directory /opt/ibm/edge/lb/servers/samples/SNMP.
L'agente DPI deve essere eseguito come utente root. Prima di eseguire il daemon DPID2, aggiornare il file /etc/snmpd.peers e il file /etc/snmpd.conf nel modo indicato di seguito:
Per sistemi AIX e Solaris:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
Per sistemi Linux:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_passwordInoltre, è 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:
"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
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 operativi AIX, HP-UX, Linux e Solaris, a causa delle limitazioni delle API SMUX, l'identificativo azienda riportato nelle trap dall'agente secondario ibmNetDispatcher potrebbe essere l'identificativo azienda di dpid2, anziché l'identificativo azienda di ibmNetDispatcher, 1.3.6.1.4.1.2.6.144. Tuttavia, i programmi di utilità di gestione del protocollo SNMP saranno in grado di determinare l'origine della trap in quanto i dati contengono un identificatore oggetto proveniente dai dati MIB di ibmNetDispatcher.
Il comando dscontrol subagent start attiva il supporto SNMP. Il comando dscontrol subagent stop disattiva il supporto SNMP.
Per ulteriori informazioni sul comando dscontrol, vedere dscontrol subagent — configura l'agente secondario SNMP.
Il kernel Linux dispone di una funzione firewall incorporata denominata ipchains. Quando Load Balancer e ipchains vengono eseguiti contemporaneamente, Load Balancer rileva prima i pacchetti, seguiti da ipchains. Ciò consente l'uso di ipchains per rifiutare tutto il traffico sulla macchina 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, consultare Problema: su sistemi Linux, iptables può interferire con l'instradamento dei pacchetti.
Questo capitolo illustra il funzionamento e la gestione del componente CBR di Load Balancer.
CBR e Caching Proxy collaborano tramite l'API plugin Caching Proxy per gestire le richieste HTTP e HTTPS (SSL). Affinché CBR possa iniziare il bilanciamento del carico sui server, è necessario che Caching Proxy sia in esecuzione sulla stessa macchina. Configurare CBR e Caching Proxy come descritto 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 Utilizzo dei log di Load Balancer.
Nelle release precedenti, per CBR era possibile modificare il percorso della directory dei log nel file di configurazione Caching Proxy. Ora, è possibile modificare il percorso della directory in cui viene memorizzato il log nel file cbrserver. Consultare Modifica dei percorsi file di log.
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 Utilizzo dei log di Load Balancer.
Dopo aver avviato Cisco CSS Controller, è possibile controllarlo utilizzando uno dei seguenti metodi:
I log utilizzati da Cisco CSS Controller sono simili a quelli utilizzati in Dispatcher. Per una descrizione più dettagliata, vedere Utilizzo 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 Utilizzo dei log di Load Balancer.
Metric Server fornisce le informazioni sul carico del server a Load Balancer. Metric Server risiede su ciascun server sottoposto a bilanciamento del carico.
Sistemi Linux e UNIX:
Sistemi Windows:
Fare clic su Start > 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.