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.
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
In alternativa —
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.
In alternativa —
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. Consultare dscontrol cluster — configura i cluster per ulteriori informazioni.
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, consultare 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. Consultare Nuovi tentativi dell'advisor per ulteriori informazioni.
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 seguente directory:
Per poter eseguire i file, è necessario spostarli nella seguente directory e rimuovere 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 loro 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.
Limitazioni nell'uso di applicazioni dei server specifici 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 è specifico del collegamento, il risultato di questo comando sarà 0.0.0.0:80. Se invece il server è specifico del collegamento, 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 rilevare velocemente il server in errore 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
Se l'advisor SSL contrassegna i server come inattivi, si sa che il server è ancora attivo e vengono visualizzati messaggi di avviso relativi all'assenza di cifrature, utilizzare l'advisor TLS.
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. Consultare Suddivisione in partizioni dei server: server logici configurati su un server fisico (indirizzo IP) per ulteriori informazioni.
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 che l'advisor HTTP o HTTPS 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_Load_Balanacer_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
Consultare dscontrol server — configura i server per ulteriori informazioni.
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.
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 si trova nella seguente directory:
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 in:
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 di 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 nella seguente directory:
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:
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, 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:
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/
<root_installazione>ibm\edge\lb\servers\lib\CustomAdvisors
Il listato del programma di un advisor di esempio è riportato in Advisor di esempio. Dopo l'installazione, questo advisor di esempio può essere trovato nella seguente directory:
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 seguente directory:
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.