A proposito dell'autore

Senior Storage Engineer

– BS in Computer Science
– Debian supporter
– Storage Engineer
– Developer
– IT Evangelist

Introduzione

In questo articolo (ove sarò molto diretto a spicciolo) andremo ad illustrare una configurazione / monitoring di più di nodi tomcat, in dialogo con un jk connector verso un server apache che sfruttando questa connessione metterà in atto il Load balancing.
Baseremo tutta la pratica su dei server equipaggiati con la  distribuzione Linux CentOS 5.5, tutta questa pratica (giusto per la cronaca) è stata sviluppata e messa in deploy su un ambiente VMware ESXi.

Sommario

  • Descrizione contesto
  • Caratteristiche implementate
  • Configurazione nodo Apache Tomcat
  • Definizione workers.properties
  • Status Worker
  • Configurazione Apache Web Server

Descrizione contesto

Server Apache:

OS: CentOS 5.5
IP: 172.22.9.42
Apache web server: 2.2.3
mod_jk: 1.2.27

Server Tomcat1:

OS: CentOS 5.5
IP: 172.22.9.40
Apache Tomcat: 6.0.26

Server Tomcat 2:

OS: CentOS 5.5
IP: 172.22.9.41
Apache Tomcat: 6.0.26

Caratteristiche implementate

  • Balacing
  • Failover
  • Hot Standby (viene solo mostrata)
  • Socket timeout
  • Error state check
  • JK Status (monitoring)

Configurazione nodo Apache Tomcat

Definiamo una porta univoca ove il jk connector potrà connettersi verso questo nodo tomcat:

<Connector port="8008" protocol="AJP/1.3" redirectPort="8443" />

Bisognerà poi andare a definire una jvmRoute univoca che avrà il nome del worker definito nella nostra worker.list. essa servirà all’interno del gruppo di nodi designati per il  load balancing. Il nome viene legato alla generazione di una sessione in modo da far reindirizzare questa sessione sempre allo stesso nodo :

<Engine name="Catalina" defaultHost="localhost" jvmRoute="worker1">

Definizione file workers.properties

path: /etc/httpd/conf/workers.properties

nano workers.properties, e inseriamo il seguente codice:

ps=/

# The advanced router LB worker

worker.list=load_balancer, worker1,worker2

# Controlliamo ogni ora se un balancer è in stato di errore

worker.maintain=3600

# Definiamo un worker usando ajp13 per il nodo tomcat1

worker.worker1.port=8008
worker.worker1.host=172.22.9.40

# Il tipo ajp13 è utilizzato poichè il JK connector lo utilizza per la comunicazione tra il web server e il tomcat

worker.worker1.type=ajp13

# lbfactor setta quanto un worker debba lavorare rispetto ad un altro,
# ed è comparato con i valori degli altri workers attivi

worker.worker1.lbfactor=100

# Definiamo il nodo di failover preferito per il worker1

worker.worker1.redirect=worker2

# Definiamo un worker usando ajp13 per il nodo tomcat1
# porta definita sulla quale il tomcat è in ascolto per le richieste JK

worker.worker2.port=8009
worker.worker2.host=172.22.9.41
worker.worker2.type=ajp13

# lbfactor setta quanto un worker debba lavorare rispetto ad un altro,
# ed è comparato con i valori degli altri workers attivi
worker.worker2.lbfactor=100

# Questa opzione (chiamata HOT STANDBY) non la useremo, ma la inserisco commentata nel caso vi dovesse servire. Nello specifico server a: “Disabilita il worker per tutte le richieste, eccetto per il failvoer. Questo significa che esso riceve richieste nel caso in cui il worker che lo ha designato come failover node andasse in errore.

#worker.worker2.activation=disabled

# Definiamo il nodo di failover preferito per il worker2

worker.worker2.redirect=worker1

# timeout del socket (espresso in secondi) che viene utilizzato per la comunicazione tra il modulo Jk e l’host remoto. Se quest’ultimo non dovesse rispondere entro il lasso dei tempo di timeout impostato Il Jk produrrà un errore e proverà di nuovo. Lasciando il valore a zero il Jk aspetterà per un tempo infinito su tutte le operazioni del socket.

worker.worker2.socket_timeout=3600

Prima di andare a spiegare le prossime due righe volemo precisare questa cosa (dato che in questo articolo sto dando una conoscenza di base della tematica che si è affrontata): ”

Il load balancer è un worker virtuale ma si occupa dell’interazione/gestione dei worker che gli vengono associati e definiti come reali, questo significa che di fatto esso non “realmente” con essi. In ultimo un worker viene definito load balancer quando il type assume il valore “lb”

# definiamo alcuni parametri per il load balancer, come il tipo in questo caso tipo e l’errore da restituire in caso di fault.

worker.load_balancer.type=lb
worker.load_balancer.fail_on_status=404

# Tipologie di load balancing: #

Attraverso la direttiva “worker.load_balancer.method=value” andiamo a definire il metodo con il quale viene selezionato il miglior worker verso il quale dovrà essere inoltrata la nostra richiesta. Andiamo ad identificare i valori possibili e a darne una spiegazione:

R[quest]: il balancer userà il numero delle richieste accodate su ogni worker per determinare il migliore da servire. Gli accessi vengono distrbuiiti secondo l’ lbfactor secondo il criterio del “windows sliding time”. Questo valore è quello di default.

S[ession]: il balancer userebbe il numero di sessioni per cercare il miglior worker….gli accessi sarebbero comunque distribuiti secondo il “window sliding time” poichè il balancer non mantiene nessuna informazioni sullo stato (stateless) e attualmente non ha visione/conoscenza del numero di sessioni. Invece viene effettuato un conteggio su ogni richiesta senza “cookie sessio” o “URL encoding” che viene quindi calcolata essere una nuova sessione. Viene consigliato di utilizzare questo valore quando le sessioni
sono la risorsa limitante.

T[raffic]: il balancer utilizzerà il traffico di rete tra il server JK e il server tomcat per definire il miglio worker. Gli accessi saranno distribuiti in accordo con l’ lbfactor in una “window sliding time” Questo metodo dovrebbe essere utilizzato se la rete da/verso i backends costituiscono la risorsa limitante.

B[usyness]: il balancer selezionerà il worker con il carico di lavoro corrente più basso, questa tecnica è basata su quante richieste il worker sta servendo correntemente. Il numero viene diviso per l’ lbfactor di tutti gli altri worker e il valore più basso (che praticamente corrisponde a quello meno occupato) viene scelto come worker a cui inoltrare la richiesta.
Questo metodo risulta interessante nel momento in cui la richesta richiede un tempo lungo per essere processato, per esempio un corposo download.

# Definiamo che tipologia di load balancing decidiamo di utilizzare

# default vaule = R quindi non lo setto
#worker.load_balancer.method=R

# Definiamo i workers da utilizzare

worker.load_balancer.balance_workers=worker1, worker2

Trattiamo adesso la parte del worker che ci server per effettuare il monitoring dello stato dei nostri JK connectors:

Status Worker Reference

Esiste un particolare tipo di worker chiamato “status worker”, esso non ha il compito di girare le richieste alel istance dei nodi tomcat ma di reperire le informazioni di gestione, stato, configurazione in runtime e cambiare nel caso delel configurazioni in modo dinamico; tutto attraverso una interfaccia web integrata (molto semplice e snella).

Nellìesempio sottostante ho configurato due tipo di worker status, uno che consente le modifiche e azioni di gestione da parte di un prsunto sysadmin, e il secondo una semplice versione dello stesso in modalità read-only per un eventuale monitoring da parte – la butto li – di una persona addetta alla segnalazione di errori.
Andrmeo poi a vedere come nella configurazione si apache renderemo queste “location” disponibili ad un solo pre-determinato indirizzo ip e negando l’accesso a tutti gli altri.

# Aggiungiamo questo particolare worker alla lista (questo sarà quello per l’admin)

worker.list=jkstatus

# definiamo il jkstatus
worker.jkstatus.type=status

# definiamo il punto di mount
worker.jkstatus.mount=/private/jkmanager

# un altro worker ti questa tipologia ma solo read-only
worker.list=jkview
worker.jkview.type=status
worker.jkview.read_only=True
worker.jkview.mount=/private/jkview

Configurazione Apache web Server

Andiamo un secondo a vedere come rendere accessibili questi worker i lavori tramite apache, andiamo a modificare il file httpd.conf, e inseriamo le seguenti righe alla fine del file:

# Worker properties file
JkWorkersFile /etc/httpd/conf/workers.properties

# Logging
JkLogFile /var/log/httpd/mod_jk.log

# Set the jk log level [debug/error/info]
JkLogLevel debug

# Log Format
JkLogStampFormat " [%a %b %d %H:%M:&S %Y] "

# Send servlet for context / AGO_EXT to worker named worker1

JkMount /WEAPP1 load_balancer
JkMount /WEBAPP1/* load_balancer

JkMount /WEBAPP2 load_balancer
JkMount /WEBAPP2/* load_balancer
<Location /private/jkmanager> JkMount jkstatus Order Deny,Allow Deny from all Allow from 172.22.80.12 </Location>
 <Location /private/jkmonitor> JkMount jkview Order Deny, Allow Deny from all Allow from 172.22.50.36 </Location> 

Per la parte relativa al semplice tomcat con mod_jk potete anche dare un occhio a questo articolo

Infine vi propongo una schermata di come è il jkmanager e per gli approfondimenti vi rimando alla documentazione ufficiale del sito tomcat.apache.org perchè come sempre questo è solo un assaggio per stuzzicare la mente :)



Un saluto,

Giovanni Uccio

  • lmx insider

    you can do some load balance only with the dns servers…one time it give to requesting user a ip of a tomcat server, in another it give the ip of other ip tomcat server, but of course you have to be running a http server on the two servers…
    You are doing the load balance in the 172.22.9.42 right ?

    regards

  • Giovanni Uccio

    yes the 172.22.9.42 is the Apache Web Server used for the load balancing….

Close
Entra in contatto con altri professionisti ICT, seguici su Facebook e Twitter: