Questo capitolo include le seguenti sezioni:
Cisco CSS Controller 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 Cisco CSS Controller e Controller Nortel Alteon.
Per aumentare la tolleranza agli errori del controllor, la funzione di disponibilità elevata contiene le seguenti caratteristiche:
Per la sintassi completa relativa a xxxcontrol highavailability, vedere ccocontrol highavailability -- controlla la disponibilità elevata e nalcontrol highavailability -- controlla la disponibilità elevata.
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.Oltre alla mancanza di connettività tra il controller attivo e il controller in standby, che viene rilevata tramite i messaggi di heartbeat, l'accessibilità è un altro meccanismo di rilevamento errori.
Quando si configura la funzione di disponibilità elevata dei controller, è possibile fornire un elenco di host a cui i controller devono accedere per poter funzionare correttamente. Occorre almeno un host per ciascuna sottorete che verrà utilizzata dalla macchina controller. Questi host possono essere router, server IP o altri tipi di host.
L'accessibilità degli host è ottenuta grazie all'advisor reach che esegue il ping sull'host. Se i messaggi heartbeat non possono essere trasmessi o se i criteri di accessibilità vengono soddisfatti in maniera ottimale dal controller in standby anziché dal controller attivo, si verifica uno scambio di ruoli. Per prendere questa decisione in base a tutte le informazioni disponibili, il controller attivo invia regolarmente informazioni sulle proprie capacità di accessibilità al controller in standby e viceversa. Quindi, i controller confrontano le proprie informazioni sull'accessibilità con le informazioni del rispettivo partner e decidono chi deve attivarsi.
I ruoli delle due macchine controller sono configurati come principale e secondaria. All'avvio i controller si scambiano informazioni fino a sincronizzare le relative macchine. A questo punto, il controller principale passa allo stato attivo e inizia a calcolare i pesi e ad aggiornare lo switch, mentre la macchina secondaria passa allo stato di standby e 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 della strategia deve essere impostato allo stesso modo su entrambe le macchine.
Per gli esempi di configurazione della funzione di disponibilità elevata per Cisco CSS Controller, vedere Esempi.
Per gli esempi di configurazione della funzione di disponibilità elevata per 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 su 10 riceverà il doppio delle richieste del server impostato su 5.
Se un advisor rileva che un server è inattivo, il peso per tale server viene impostato a -1. Per Cisco CSS Controller e 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 rilevare velocemente il server in errore 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, consultare nalcontrol service -- configura un servizio.
L'advisor personalizzato è una piccola parte di codice Java che l'utente deve fornire come file di classe e viene richiamato dal codice di base. Il codice di base fornisce tutti i servizi amministrativi, quali:
Inoltre, notifica i risultati al consultant. Periodicamente, il codice di base esegue un ciclo di advisor, durante il quale valuta singolarmente lo stato di tutti i server della configurazione. Per prima cosa, apre una connessione a una macchina server. Se il socket viene aperto, il codice di base richiama il metodo (funzione) getLoad nell'advisor personalizzato. L'advisor personalizzato quindi esegue i passi necessari per valutare lo stato del server. In genere, invia al server un messaggio definito dall'utente e aspetta quindi una risposta. (L'accesso al socket aperto viene fornito all'advisor personalizzato.) Il codice di base chiude il socket con il server e notifica le informazioni sul carico al consultant.
Il codice di base e l'advisor personalizzato possono funzionare in modalità normale o in modalità di sostituzione. La scelta della modalità di funzionamento viene specificata nel file dell'advisor personalizzato come un parametro nel metodo del costruttore.
In modalità normale, l'advisor personalizzato scambia i dati con il server, il codice dell'advisor di base programma lo scambio e calcola il valore del carico. Il codice di base notifica quindi questo valore del carico al consultant. L'advisor personalizzato deve solo restituire uno zero (esito positivo) o meno uno (-1) (errore). Per specificare la modalità normale, l'indicatore di sostituzione nel costruttore è impostato su false.
In modalità di sostituzione, il codice di base non esegue nessuna misurazione temporizzata. Il codice dell'advisor personalizzato esegue qualsiasi operazione desiderata per i relativi requisiti univoci e restituisce un numero di carico effettivo. Il codice di base accetta il numero e lo notifica al consultant. Per ottenere risultati migliori, normalizzare i numeri del carico tra 10 e 1000; 10 indica un server veloce e 1000 indica un server lento. Per specificare la modalità di sostituzione, l'indicatore di sostituzione nel costruttore è impostato su true.
Questa funzione consente di scrivere i propri advisor in modo da fornire le informazioni precise sui server che sono necessarie. Un advisor personalizzato di esempio, ADV_ctlrsample.java, viene fornito per i controller. Dopo aver installato Load Balancer, è possibile trovare il codice di esempio in:
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
<root_installazione>ibm\edge\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 nella seguente directory:
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:
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.
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 seguente directory:
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 seguente directory:
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 la sezione relativa alla creazione di un alias di un indirizzo sullo stack Microsoft per un metric server.
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 registrazione binaria consente di memorizzare le informazioni sui server in file binari. È quindi possibile elaborare tali file per analizzare le informazioni sui server che sono state raccolte nel corso del tempo.
Nel log binario di ciascun server definito nella configurazione vengono memorizzate le seguenti informazioni.
Per poter registrare le informazioni sui log binari, il consultant deve essere in esecuzione.
Utilizzare il gruppo di comandi xxxcontrol consultant binarylog per configurare la registrazione binaria.
L'opzione start avvia la registrazione delle informazioni sui server sui log binari nella directory dei log. All'inizio di ogni nuova ora viene creato un log, il cui nome è composto dalla data e dall'ora.
L'opzione stop arresta la registrazione delle informazioni sui server sui log binari. Il servizio di registrazione viene arrestato per impostazione predefinita.
L'opzione set interval controlla la frequenza con cui le informazioni vengono scritte sui log. Il consultant invia le informazioni sui server al server dei log a ogni intervallo specificato. Le informazioni vengono scritte sui log solo se l'intervallo di registrazione specificato, espresso in secondi, è scaduto dall'ultima volta che un record è stato scritto sul log. Per impostazione predefinita, l'intervallo di registrazione è impostato a 60 secondi.
Le impostazioni dell'intervallo di invio delle informazioni da parte del consultant e dell'intervallo di registrazione interagiscono in una certa misura. Poiché la frequenza con cui il server dei log riceve le informazioni non è superiore all'intervallo di invio delle informazioni da parte del consultant, espresso in secondi, impostare l'intervallo di registrazione su un valore inferiore a quello dell'intervallo di invio delle informazioni da parte del consultant significa in pratica impostarlo sul suo stesso valore.
Questa tecnica di registrazione consente di acquisire le informazioni sui server a qualsiasi granularità. È possibile acquisire tutte le modifiche alle informazioni sui server di cui viene a conoscenza il consultant per calcolare i pesi dei server; tuttavia, probabilmente questa quantità di informazioni non è necessaria per analizzare l'utilizzo dei server e i relativi andamenti. La registrazione delle informazioni sui server ogni 60 secondi consente di ottenere istantanee di informazioni relative ai server nel corso del tempo. L'impostazione dell'intervallo di registrazione su un valore molto basso può generare quantitativi eccessivi di dati.
L'opzione set retention controlla per quanto tempo i file di log vengono mantenuti. I file di log, la cui ora di creazione precede il tempo specificato da questa opzione, vengono eliminati dal server dei log. Questa eliminazione viene eseguita solo se il server dei log viene richiamato dal consultant; quindi se si arresta il consultant, i file di log vecchi non vengono cancellati.
Un programma Java e un file dei comandi di esempio sono forniti nella seguente directory:
L'esempio illustra come richiamare tutte le informazioni dai file di log e stamparle sullo schermo. Può essere personalizzato al fine di eseguire qualsiasi tipo di analisi sui dati.
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 seguente directory:
Per eseguire i file, copiarli nella seguente directory e ridenominare 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: