Funzionamento e gestione di Load Balancer

Nota:
se, durante la lettura di questo capitolo, nelle sezioni generali non specifiche di un particolare componente, non si sta utilizzando il componente Dispatcher, sostituire "dscontrol" e "dsserver" con quanto segue:

Questo capitolo illustra il funzionamento e la gestione di Load Balancer e comprende le seguenti sezioni:

Amministrazione remota di Load Balancer

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.

RMI (Remote Method Invocation)

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.

Nota:
a causa delle modifiche apportate ai pacchetti di protezione nella versione Java, le chiavi Load Balancer generate per le release precedenti a v5.1.1 potrebbero non essere compatibili con le chiavi della release corrente, quindi è necessario generare nuovamente le chiavi al momento dell'installazione della nuova release.

Amministrazione basata sul Web

Requisiti

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:

Configurazione di Caching Proxy

Esecuzione e accesso all'amministrazione basata sul Web

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:

  1. evidenziare il nodo Host dalla struttura ad albero della GUI
  2. selezionare Send command... dal menu a comparsa Host
  3. 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.

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

Utilizzo dei log di Load Balancer

Per Dispatcher, CBR e Site Selector

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.

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

È 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 personalizzare le seguenti funzioni di registrazione:

Configurare la registrazione con i seguenti comandi:

Modifica dei percorsi file di log

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).

Registrazione binaria

Nota:
la registrazione binaria non si applica al componente Site Selector.

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.

Per Cisco CSS Controller e Controller Nortel Alteon

È 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 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.

Log controller

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

Modifica dei percorsi file di log

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).

Registrazione binaria

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.

Uso del componente Dispatcher

Questo capitolo illustra il funzionamento e la gestione del componente Dispatcher.

Avvio e arresto di Dispatcher

Uso del valore timeout di inattività

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.

Uso di fintimeout e staletimeout per controllare la pulitura dei record di connessioni

Un client invia un pacchetto FIN dopo aver inviato tutti i propri pacchetti, in modo che il server riconosca 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.

Notifica GUI -- Opzione del menu Monitor

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):

Uso del protocollo SNMP (Simple Network Management Protocol) con il componente Dispatcher

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.

Nota:
i dati MIB, ibmNetDispatcherMIB.02, non vengono caricati quando si utilizza il programma Tivoli NetView xnmloadmib2. Per correggere questo problema, trasformare la sezione NOTIFICATION-GROUP del MIB in un commento, vale a dire, inserire "- -" all'inizio della riga "indMibNotifications Group NOTIFICATION-GROUP" e delle 6 righe successive.

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.

Comandi SNMP e protocollo

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.

Abilitazione di SNMP su sistemi AIX, HP-UX, Linux e Solaris

Figura 37. Comandi SNMP per sistemi operativi AIX, HP-UX, Linux e Solaris
Comandi SNMP e sistema server per AIX, HP-UX, Linux e Solaris

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.

Nota:
Per i sistemi SuSE Linux, è necessario ottenere un agente SNMP che sia abilitato a SMUX poiché SuSE non ne fornisce uno.

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:

Per sistemi Linux:

Abilitazione di SNMP su sistemi HP-UX

Per installare il supporto SNMP di HP-UX:

  1. Se non si ha una versione di GNU SED installata, scaricarla dal sito Web HP, http://www.hp.com.
  2. Prelevare il file ucd-snmp-4.2.4.tar.gz dalla seguente pagina Web, http://sourceforge.net/project/showfiles.php?group_id=12694.
  3. Verificare che "gcc" e "gmake or make" siano installati sulla macchina. In caso contrario, installarli.
  4. Decomprimere il file ucd-snmp-4.2.4.tar.gz, quindi decomprimere tutti i file di origine della directory.
  5. Individuare la directory contenente i file di origine ed effettuare le seguenti operazioni:
    1. run ./configure --with-mib-modules=smux
    2. make
    3. Eseguire i successivi due comandi come root:
      1. umask 022
      2. make install
    4. export SNMPCONFPATH=/etc/snmp
    5. start /usr/local/sbin/snmpd -s (Questo avvia l'agente SNMP)
    6. start dpid2 (Questo avvia il convertitore DPI)
    7. dscontrol subagent start (Questo avvia l'agente secondario di Dispatcher)

Abilitazione di SNMP su sistemi SuSE Linux

Per utilizzare il protocollo SNMP di Load Balancer in SuSE Linux, effettuare le seguenti operazioni:

  1. Rimuovere ucd-snmp rpm installato dalla macchina SuSE.
  2. Richiamare ucd-snmp-4.2.4.tar.gz da http://sourceforge.net/project/showfiles.php?group_id=12694.
  3. Verificare che "gcc" e "gmake or make" siano installati nella macchina SuSE (se non sono presenti, installarli).
  4. Decomprimere il file ucd-snmp-4.2.4.tar.gz, quindi decomprimere tutti i file di origine della directory.
  5. Individuare la directory contenente i file di origine ed effettuare le seguenti operazioni:
    1. run ./configure --with-mib-modules=smux
    2. make
    3. Eseguire i successivi due comandi come root:
      1. umask 022 #
      2. make install
    4. export SNMPCONFPATH=/etc/snmp
    5. start /usr/local/sbin/snmpd -s
    6. start dpid2

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:

  1. Agente SNMP
  2. Convertitore DPI
  3. agente secondario di Dispatcher

Abilitazione di SNMP su sistemi Solaris

Per installare il supporto SNMP di Solaris:

  1. Arrestare il daemon SNMP di Solaris in esecuzione (snmpdx e snmpXdmid).
  2. Rinominare i file nel modo seguente:
  3. Scaricare i seguenti pacchetti dall'indirizzo http://www.sunfreeware.com/:
  4. Installare i pacchetti scaricati utilizzando pkgadd.
  5. Scaricare il file ucd-snmp-4.2.3-solaris8.tar.gz da http://sourceforge.net/project/showfiles.php?group_id=12694
  6. Decomprimere il file ucd-snmp-4.2.3-solaris8.tar.gz sulla directory root (/)
  7. Immettere i seguenti comandi:
  8. Se non esiste, creare il file /etc/snmpd.peers. Inserire quanto segue nel file snmpd.peers:
    "dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2     "dpid_password"
  9. Se non esiste, creare il file /etc/snmp/snmpd.conf. Inserire quanto segue nel file snmpd.conf:
    smuxpeer        1.3.6.1.4.1.2.3.1.2.2.1.1.2     dpid_password
  10. Avviare /usr/local/sbin/snmpd.
  11. Avviare /usr/local/sbin/dpid2.
Note:
  1. Quanto indicato di seguito è in formato pacchetto.
    • libgcc-3.0.3-sol8-sparc-local (SMClibgcc)
    • openssl-0.9.6c-sol8-sparc-local (SMCosslc)
    • popt-1.6.3-sol8-sparc-local (SMCpopt)

    Sul sito Web di http://sunfreeware.com/, i nomi hanno un'estensione .gz, quindi non cercare di decomprimerli. Al contrario, utilizzare pkgadd packageName.

  2. Quando si aggiunge la voce smuxpeer nel file /etc/snmp/snmpd.conf, verificare che non vengano aggiunti spazi nella stringa dpid_password.
  3. La funzione SNMP di Load Balancer è stata testata con ucd-snmp versione 4.2.3 abilitato a SMUX. Le release successive di ucd-snmp con smux dovrebbero funzionare con analoga impostazione.

Abilitazione di SNMP nel sistema operativo di Windows

Per installare il supporto SNMP di Windows:

  1. Fare clic su Start > Pannello di controllo > Aggiungi/Rimuovi programmi.
  2. Fare clic su Installazione componenti di Windows.
  3. In Aggiunta guidata componenti di Windows, fare clic su Strumenti di gestione e controllo (senza selezionare o deselezionare la relativa casella di controllo), quindi fare clic su Dettagli
  4. Selezionare la casella di controllo SNMP (Simple Network Management Protocol), quindi fare clic su OK.
  5. Fare clic su Avanti.

Definizione di un nome comunità per SNMP

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:

  1. Aprire Gestione computer.
  2. Nella struttura ad albero, fare clic su Servizi
  3. Nel riquadro dei dettagli, fare clic su Servizio SNMP
  4. Dal menu delle azioni, fare clic su Proprietà
  5. Sulla scheda Sicurezza, in Nomi comunità accettati, fare clic su Aggiungi
  6. In Diritti comunità, selezionare un livello di autorizzazione per questo host per elaborare le richieste SNMP provenienti dalla comunità selezionata (almeno autorizzazione di Sola lettura)
  7. In Nome comunità, immettere un nome comunità sensibile al maiuscolo/minuscolo, lo stesso fornito all'agente secondario di Load Balancer (nome comunità predefinito: public), quindi fare clic su Aggiungi
  8. Specificare se accettare o meno i pacchetti SNMP provenienti da un host. Scegliere una delle seguenti opzioni:
  9. Riavviare il servizio SNMP per applicare le modifiche apportate

Trap

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:

-idle
Questa macchina sta eseguendo il bilanciamento del carico e non cerca di stabilire un contatto con il Dispatcher partner.
-listen
La funzione di disponibilità elevata è stata appena avviata e Dispatcher è in ascolto di eventuali comunicazioni dal partner.
-active
Questa macchina sta eseguendo il bilanciamento del carico.
-standby
Questa macchina sta controllando la macchina attiva.
-preempt
Questa macchina è in uno stato transitorio durante il passaggio dalla stato principale allo stato di backup.
-elect
Dispatcher sta negoziando con il partner per stabilire chi assumerà il ruolo principale e chi il ruolo di backup.
-no_exec
L'executor non è in esecuzione.

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.

Attivazione e disattivazione del supporto SNMP dal comando dscontrol

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.

Utilizzo di ipchains o iptables per rifiutare tutto il traffico sulla macchina Load Balancer (sistemi Linux)

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: le iptable di Linux possono interferire con l'instradamento dei pacchetti.

Uso del componente CBR (Content Based Routing)

Questo capitolo illustra il funzionamento e la gestione del componente CBR di Load Balancer.

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

Avvio e arresto di CBR

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.

Controllo di CBR

Dopo aver avviato CBR, è possibile controllarlo utilizzando uno dei seguenti metodi:

Uso dei log di CBR

I log utilizzati da CBR sono simili a quelli utilizzati in Dispatcher. Per ulteriori informazioni, vedere Utilizzo dei log di Load Balancer.

Nota:

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.

Utilizzo del componente Site Selector

Avvio e arresto di Site Selector

Controllo di Site Selector

Dopo aver avviato Site Selector, è possibile controllarlo utilizzando uno dei seguenti metodi:

Uso dei log di Site Selector

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.

Uso del componente Cisco CSS Controller

Avvio e arresto di Cisco CSS Controller

  1. Digitare ccoserver su una riga comandi per avviare Cisco CSS Controller.
  2. Digitare ccoserver stop su una riga comandi per arrestare Cisco CSS Controller.

Controllo di Cisco CSS Controller

Dopo aver avviato Cisco CSS Controller, è possibile controllarlo utilizzando uno dei seguenti metodi:

Utilizzo dei log Cisco CSS Controller

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.

Uso del componente Controller Nortel Alteon

Avvio e arresto di Controller Nortel Alteon

  1. Digitare nalserver su una riga comandi per avviare Controller Nortel Alteon.
  2. Digitare nalserver stop su una riga comandi per arrestare Controller Nortel Alteon.

Controllo di Controller Nortel Alteon

Dopo aver avviato Controller Nortel Alteon, è possibile controllarlo utilizzando uno dei seguenti metodi:

Utilizzo dei log Controller Nortel Alteon

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.

Uso del componente Metric Server

Avvio e arresto di Metric Server

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.

Uso dei log di Metric Server

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.