|
Lo scopo del lavoro è quello di guadagnarsi il tempo libero
|
|
|
|
|
Un cluster di server Web basati su Apache – Geronimo
By
Samuele Pretini
23 gennaio 2007
|
 |
|
Nell’ Agosto 2003 la Apache Software Foundation annunciò il suo intento di far partire un progetto open source per lo sviluppo di un nuovo server J2EE compliant.
Come tale esso avrebbe dovuto abbracciare una vasta gamma di tecnologie, ma quello che i progettisti avevano in mente era di realizzare un prodotto che fosse anche tecnologicamente avanzato, pensato e progettato secondo linee di pensiero che a tutt’oggi sono ancora innovative e di tutto rispetto.
Lo scopo di questo articolo è quello di introdurre il lettore alla conoscenza di questo nuovo strumento di lavoro, proponendo un esempio di utilizzo che abbraccia vari aspetti e che permetterà di vedere all’opera già da subito una piccola applicazione Web, ospitata su un cluster di server.
Sfruttando questa occasione, potrò illustrare (brevemente ma spero esaurientemente), le caratteristiche principali e più interessanti di Geronimo, che senza dubbio per le potenzialità che offre si propone come piattaforma ideale per applicazioni enterprise distribuite multilivello.
In questo contesto verrà utilizzata la release 1.1.1 di Geronimo che attualmente è la più avanzata.
|
|
|
Cenni sull’Architettura del server
|
top
|
|
Come anticipato nella prefazione il server è stato concepito con in mente alcuni concetti estremamente interessanti.
La loro applicazione raggiunge due risultati: rende possibile la produzione di uno strumento flessibile, innovativo e robusto; dimostra praticamente, che le idee su cui si basa sono sicuramente valide e se ben applicate possono portare a risultati che non hanno nulla da invidiare a quelli raggiunti con le tradizionali tecniche di sviluppo.
Come ogni server J2EE compliant Geronimo è utilizzabile per ospitare applicazioni che si avvalgono di tutta una serie di tecnologie quali: JavaServerPage, servlet,filters,EnterpriseJavaBean, fornisce le facility per la creazione di oggetti DataSource registrabile su un albero JNDI, l’utilizzo di code JMS, etc.
Internamente il server è implementato come container generico di servizi, ognuno dei quali totalmente indipendente dall’altro.
Per esempio OpenEJB può operare come servizio ed essere utilizzato per ospitare e gestire gli EJB installati e contemporaneamente Tomcat o Jetty possono essere utilizzati anch’essi come servizi per ospitare e gestire applicazioni Web dinamiche.
Immaginiamo quindi uno spazio composto da macro oggetti utilizzati per offrire servizi agli utilizzatori ognuno dei quali vive all’interno dell’infrastruttura del server che ne gestisce e coordina l’operatività.
Tale modello offre quindi la possibilità di ospitare nel server qualsiasi tipo di servizio ad esso compatibile, inclusi servizi non di tipo J2EE, quale ad esempio può essere il framework Spring.
Geronimo è quindi un container di container, concetto questo che è stato voluto e inseguito dagli sviluppatori della fondazione Apache. L’intento finale era quello di produrre un oggetto che fosse: scalabile, maneggevole e facilmente configurabile.
|
|
Gli oggetti GBean
|
top
|
Senza dubbio gli elementi caratterizzanti questo tipo di architettura sono i ‘GBean’.
Tali oggetti sono i costituenti principale del server e possono essere visti come entità che gravitano all’interno di esso e vengono gestiti dal kernel di Geronimo che sovrintende al loro ciclo di vita.
Immaginiamo quindi un core interno ed una nuvola di bean, più o meno complessi, posizionato tutt’intorno ad esso ognuno dei quali è responsabile da solo o in collaborazione con altri Gbean di un servizio offerto dal server.
Si tenga conto però, che la parola servizio viene qui usata nell’accezione più larga possibile, in quanto un GBean potrebbe rappresentare ad esempio un Container per Applicazioni Web dinamiche, un container EJB, un connettore, un’ applicazione installata, etc…
In questa architettura il kernel ha una funzione ben precisa verso i GBean, nel senso che offre loro dei servizi di tipo gestionale quali:
1 Permette ai singoli GBean si ritenere o meno in modo persistente il loro stato
2 Gestire le interrelazioni tra i GBean
3 Dà la possibilità ai GBean di contenere una logica che può essere utilizzata al verificarsi di un determinato evento nel server. Il kernel quindi dovrà, ove necessario, trasmettere gli opportuni eventi ai GBean deputati alla loro gestione.
In fig.1 viene rappresentata la situazione esposta:
Fig.1 – Architettura interna e modalità di interazione tra GBean
Come spiegato in precedenza all’interno di Geronimo tutto è un GBean, compresi i container e le applicazioni che in essi devono essere installate. Ciò significa quindi che ci sono dei componenti che sono indipendenti ed altri che invece hanno bisogno del supporto dei primi per poter esplicare le loro funzioni.
Ebbene chi risolve queste dipendenze è il kernel utilizzando i concetti dell’Inversion of Control, che è uno dei pilastri su cui si basa Geronimo, insieme all' Aspect Oriented Programming.
Il kernel infatti servendosi di un file che rappresenta il piano di installazione, risolve le dipendenze tra gli oggetti iniettando quelli indipendenti in quelli dipendenti. Per fare un esempio i GBean che rappresentano le applicazioni verranno iniettati nei GBean che rappresentano i container.
Altre dipendenze invece vengono risolte in modo automatico dal kernel, ad esempio quando una applicazione dichiara di voler utilizzare un connettore verso un altro server o un metodo di accesso alla persistenza (un DataSource ad esempio), i GBean che rappresentano tali funzionalità e che magari già esistono all’interno del server verranno iniettati nell’applicazione o nel bean che rappresenta il container per garantire il corretto funzionamento delle tecnologie richieste.
Dai concetti spiegati fin’ora risulta evidente che l’elemento centrale di tutta questa architettura risulta essere il file che contiene il piano di installazione, il quale: contiene la dichiarazione degli oggetti GBean che verranno utilizzati e che "vivranno" all’interno dello spazio virtuale gestito dal kernel di Geronimo; esprime in modo dichiarativo direttamente o indirettamente le dipendenze tra i di essi.
|
|
Ciclo di vita dei GBean
|
top
|
|
Un GBean può trovarsi in tre stati possibili: stored, loaded, running.
1 Stored: questo è lo stato in qui si trova un GBean quando non è stato mai instanziato e la sua presenza è rappresentata solo al livello di configurazione nel DeployementPlan.
2 Loaded: Quando il kernel rileva che un determinato GBean debba essere instanziato, lo crea utilizzando il DeployementPlan ed assegnando ad esso un nome univoco ma transiente, cioè il nome attribuito ad uno stesso GBean sarà diverso ogni volta che esso verrà instanziato. Tale meccanismo ricorda quello attuanto dalla JVM per attribuire dei riferimenti simbolici agli oggetti che vengono caricati dal classloader per essere instanziati.
3 Running: il GBean stà assolvendo al suo compito.
Vediamo ora un esempio di DeployementPlan che servirà per mostrare come possono essere definite le dipendenze in modo dichiarativo, demandando al kernel la loro risoluzione:
Fig.2 Esempio di DeployementPlan
Come si può osservare il GBean HumanResource ha una dipendenza verso il GBean Customer , tale dipendenza viene espressa in modo dichiarativo e server per informare il kernel che prima di creare il bean HumanResource dovrà creare il bean Customer ed iniettare il riferimento di quest’ultimo nel primo.
Lascio al lettore le considerazioni relative ai vantaggi che può portare un simile tipo di architettura, sia in termini di scalabilità del server che in termini di riuso delle componenti interne. Ne tantomeno intendo approfondire ulteriormente tali argomenti, che pure richiederebbero di essere trattati in modo approfondito e accurato, in quanto questo esula dalla scopo di questo breve articolo che vuole invece fornire una prima dimostrazione del funzionamento di Geronimo in un contesto di studio.
|
|
Applicazione web dinamica
|
top
|
|
In questo articolo viene mostrato il processo di installazione di una WebApplication minimale di tipo J2EE, sviluppata con l’ausilio del Framework Struts, in un cluster di server Geronimo utilizzati come container di applicazioni dinamiche, il cui carico di lavoro viene bilanciato da un server Web che invocato direttamente dai client.
Verranno illustrati ora tutti i componenti utilizzati per realizzare la dimostrazione in questione
L’applicazione utilizzata dà la possibilità all’utente di inserire dei dati utilizzando un form di tipo html, e mostra successivamente tali dati in una pagina di riepilogo. Come si può osservare tale funzionalità banale è ben calata nel contesto di tale articolo che ha come scopo tra gli altri la verifica del funzionamento del container per applicazioni Web incluso in Geronimo.
Il file di configurazione di Struts, mostrato di seguito, descrive e configura le componenti operative dell’ applicazione:
File di configurazione di Struts
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.2//EN"
"http://struts.apache.org/dtds/struts-config_1_2.dtd">
<struts-config>
<form-beans>
<form-bean type="org.geronimo.samples.actionforms.AnagraficaActionForm"
name="anagraficaFormBean">
<form-property type="String" name="name"/>
<form-property type="String" name="surname"/>
<form-property type="String" name="method"/>
</form-bean>
</form-beans>
<action-mappings>
<action path="/insertAnagrafica" parameter="method"
type="org.geronimo.samples.actions.InsertDataAction"
name="anagraficaFormBean" scope="request" validate="false">
<forward path="/jsp/InsertingAnagraficData.jsp" name="toInsertPage"/>
<forward path="/jsp/InsertResult.jsp" name="toInsertingResult"/>
</action>
</action-mappings>
<controller processorClass="org.apache.struts.tiles.TilesRequestProcessor"/>
<message-resources parameter="MessageResources"/>
<plug-in className="org.apache.struts.tiles.TilesPlugin">
<set-property property="definitions-config" value="/WEB-INF/tiles-defs.xml"/>
</plug-in>
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames"
value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>
</plug-in>
</struts-config>
E’ stato predisposto un ActionForm di nome anagraficaFormBean che conterrà i dati inseriti attraverso il form html, tali dati sarano: name, surname, method.
Come noto il campo method viene usato per richiamare il metodo voluto, in una classe che estende DispatchAction.
La action appunto ha come nome simbolico: insertAnagrafica e definisce due forward verso altrettanti file jsp. Il primo di essi rappresenta la pagina di inserimento dei dati, il secondo la pagina che mostra il riepilogo dei dati inseriti.
Le altre impostazioni che si possono osservare sono relative a degli strumenti, come ad esempio i Tiles o il framework per la validazione dei dati in input, che per questa applicazione non vengono utilizzati in quanto appesantirebbero l’esempio senza nulla aggiungere allo scopo per cui esso esiste.
Passiamo ora all’ analisi delle componenti salienti dell’applicazione Web in esame:
• AnagraficaActionForm: è un classico POJO che conterrà tre campi descritti sopra
• InsertDataAction: Rappresenta la classe che contiene la logica di controllo minimale per questo esempio, il listato è mostrato di seguito:
InsertDataAction public class InsertDataAction extends DispatchAction {
public ActionForward insertAnagrafica(ActionMapping actionMapping,
ActionForm actionForm,
HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse) throws Exception {
System.out.println("Inserimento effettuato.");
return actionMapping.findForward("toInsertingResult");
}
public ActionForward goToInsertAnagrafica(ActionMapping actionMapping,
ActionForm actionForm,
HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse)
throws Exception {
System.out.println("goToInsertAnagrafica.....");
return actionMapping.findForward("toInsertPage");
}
Come si può osservare i due metodi non fanno altro che eseguire un forward verso delle pagine jsp, che in dettaglio sono:
• Pagina di inserimento dati: rappresenta il file jsp che contiene il form per l’inserimento dei dati. Il codice è rappresentato di seguito
Pagina inserimentoDati
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%>
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html"%>
<html>
<head>
<title>Inserimento dati anagrafici</title>
</head>
<body>
<html:form action="/insertAnagrafica" method="post">
<html:hidden property="method" value="insertAnagrafica"/>
<table>
<tr>
<td>
Name: <html:text property="name"/>
</td>
<td>
Surname: <html:text property="surname"/>
</td>
</tr>
<tr>
<td>
<html:submit value="Go"/>
</td>
</tr>
</table>
</html:form>
</body>
</html>
|
|
Caso di test
|
top
|
Introduzione e visualizzazione dati anagrafici:
• L’applicazione viene invocata digitando l’indirizzo :
http://localhost:8080/GeronimoSamplesWeb/insertAnagrafica.do?method= goToInsertAnagrafica
Nella Fig.3 viene mostrata la pagina html che permette l’inserimento dei dati di prova: Bob, Tyler.
 Fig.3: Pagina inserimento Dati
Cliccando sul tasto submit(Go) tali dati verranno inviati al server.
L’applicazione infine mostrerà i dati inseriti nella pagina di resume, come mostrato in Fig 7:  Fig.4: Pagina di resume
Come si desume da questo esempio, l’applicazione in sé non ha un grande complessità, ma è di aiuto nell’intento di focalizzare l’attenzione sulla fase di installazione nel server e configurazione di quest’ultimo per operare come nodo componente di un cluster di server.
|
|
Preparazione dei server
|
top
|
Per poter utilizzare un server Geronimo come membro di un cluster è necessario modificare il file config.xml nella cartella /var/config del server stesso, aggiungendo le righe seguenti: Configurazione del server <gbean name="TomcatEngine">
<attribute name="initParams">name=Geronimo
jvmRoute=node001</attribute>
</gbean>
Ove il parametro “jvmRoute” dovrà essere univoco all’interno del cluster.
Tale parametro verrà utilizzato dal bilanciatore del carico per indirizzare le varie richieste http sui vari server del cluster.
|
|
Configurazione dell’applicazione
|
top
|
Come detto in precedenza, per poter installare questa applicazione Web nel server Geronimo, è necessario utilizzare un file xml che descrive il piano di installazione e configurazione. Nel mostrare tale documento procederò in due fasi successive: prima mostrerò la parte del file relativa all’applicazione web, poi mostrerò la parte relativa alla configurazione dell’applicazione come entità da installare e far funzionare in modalità clusterizzata.
File di configurazione applicazione Web<sys:environment
xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1">
<sys:moduleId>
<sys:groupId>geronimo</sys:groupId>
<sys:artifactId>GeronimoSamplesWebApp-Cluster</sys:artifactId>
<sys:version>1.1</sys:version>
<sys:type>war</sys:type>
</sys:moduleId>
</sys:environment>
<context-root>/GeronimoSamplesWeb</context-root>
In questo stralcio del file di configurazione possiamo identificare la proprietà artifactId utilizzata per identificare con un nome mnemonico l’applicazione; version usata per versionare la release; type usata per comunicare al server che il formato usato per installare l’applicazione sarà quello di archivio compresso (war); context-root proprietà che imposta il nome dell’applicazione, usato per invocarla attraverso una chiamata http.
Quest’ultimo parametro verrà utilizzato per identificare l’applicazione tra le altre presenti installate nel server e presenti nella lista che viene presentata dalla console di amministrazione.
|
|
Impostazioni per il cluster
|
top
|
Passiamo ora ad analizzare la restante parte del file di installazione e configurazione di Geronimo, quella che riguarda le impostazione che configurano una applicazione installata come parte di un cluster di applicazioni installate su altrettanti server. Il cluster si baserà sul concetto si replicazione della sessione di tipo all-to-all.
Ovviamente questa scelta è da farsi solo in un contesto che prevede un cluster formato da un numero limitato di elementi e una infrastruttura di rete adatta alla trasmissione di una mole anche considerevole di informazioni. Altro requisito fondamentale è che tutti gli elementi costituenti la rete di cluster supportino la trasmissione di dati di tipo multicast.
Analizzerò ora gli elementi più importanti che descrivono il comportamento di ogni singolo nodo del cluster. I più esperti in materia certamente noteranno che le impostazioni fatte nel file di deployement di Geronimo per quanto concerne la configurazione del cluster sono molto simili a quelle necessarie per il server Apache-Tomcat.
In effetti ciò è vero in quanto Geronimo, come più volte asserito, utilizza proprio il server Tomcat configurato come GBean per implementare il servizio di container per applicazioni Web dinamiche in tecnologia Java.
Si osservi ora la successiva sezione del file (prima parte della configurazione del funzionamento come cluster):
<cluster>TomcatCluster</cluster>
<gbeanType:gbean
class="org.apache.geronimo.tomcat.cluster.CatalinaClusterGBean" name="TomcatCluster">
<gbeanType:attribute name="className">
org.apache.catalina.cluster.tcp.SimpleTcpCluster
</gbeanType:attribute>
<gbeanType:attribute name="initParams">
managerClassName=org.apache.catalina.cluster.session.DeltaManager
expireSessionsOnShutdown=false
useDirtyFlag=false
notifyListenersOnReplication=true
</gbeanType:attribute>
<gbeanType:reference name="Membership">
<gbeanType:name>TomcatMembership</gbeanType:name>
</gbeanType:reference>
<gbeanType:reference name="Receiver">
<gbeanType:name>TomcatReceiver</gbeanType:name>
</gbeanType:reference>
<gbeanType:reference name="Sender">
<gbeanType:name>TomcatSender</gbeanType:name>
</gbeanType:reference>
<gbeanType:reference name="TomcatValveChain">
<gbeanType:name>ReplicationValve</gbeanType:name>
</gbeanType:reference>
</gbeanType:gbean>
In essa possiamo identificare queste componenti:
• Cluster: identifica il nome simbolico del cluster
• gBeanType: questo è un Tag utilizzato per definire un nuovo GBean, le cui proprietà saranno definite nei Tag seguenti
• class: identifica la classe che rappresenta il nuovo GBean
I parametri di configurazione più importanti di questo GBean sono:
- className: rappresenta la classe che costituisce il gestore del cluster, in questo caso verrà utilizzato un cluster basato sulla replicazione della sessione tra i membri utilizzando il protocollo TCP per il trasferimento di tali informazioni, e una rete multicast per il discovery dello stato dei componenti del cluster stesso. La sessione verrà replicata tra tutti quei server in cui sono state installate una versione dell’applicazione con nel file web.xml il tag distributable specificato.
Il gestore del cluster a sua volta deve essere inizializzato con alcuni parametro tra cui:
- managerClassName: rappresenta la classe che ha la responsabilità della gestione replicazione dei contesti tra i membri del cluster, in modo che vengano replicate solo le differenze tra i membri.
• Membership: è un riferimento ad un GBean che verrà descritto in seguito è che rappresenta le impostazioni di appartenenza di un nodo al cluster
• Receiver: è un riferimento ad un GBean che verrà descritto in seguito. Il receiver è necessario per realizzare la replicazione del contesto. Ogni membro del cluster infatti, utilizzando una politica ben definita, al verificarsi di un evento invia il suo contesto applicativo agli altri nodi. Tali nodi, che stanno in ascolto utilizzando una socket, ricevono tale informazione e la memorizzano utilizzando un meccanismo predefinito. Nel nostro esempio il meccanismo è la memoria di sistema. Altre varianti sono: l’utilizzo di un livello di persistenza rappresentato da files o da DataBases.
• Sender: è un riferimento ad un GBean che verrà descritto in seguito. Attraverso il sender, un server invia i delta che rappresentano le variazioni del contesto applicativo.
• ReplicationValve: Tale GBean è necessario per filtrare le richieste http che potenzialmente possono provocare un cambiamento dello stato della sessione del server da quelle invarianti da tale punto di vista. Quindi le richieste http che fanno riferimento a risorse statiche non sono sottoposte a replicazione, in quanto esse certamente non comportano una variazione dello stato applicativo interno di un server.
Analizziamo ora più dettagliatamente i GBean menzionati sopra, per chiarire meglio il funzionamento del cluster preso in esame.
A tale scopo faremo riferimento alla seconda ed ultima parte del file di installazione di Geronimo, utilizzato per la configurazione del cluster:
<!-- Membership -->
<gbeanType:gbean name="TomcatMembership"
class="org.apache.geronimo.tomcat.cluster.MembershipServiceGBean">
<gbeanType:attribute name="className">
org.apache.catalina.cluster.mcast.McastService</gbeanType:attribute>
<gbeanType:attribute name="initParams">
mcastAddr=228.0.0.4
mcastBindAddress=127.0.0.1
mcastPort=45564
mcastFrequency=500
mcastDropTime=3000
</gbeanType:attribute>
</gbeanType:gbean>
<!-- Receiver -->
<gbeanType:gbean name="TomcatReceiver" class="org.apache.geronimo.tomcat.cluster.ReceiverGBean">
<gbeanType:attribute name="className">
org.apache.catalina.cluster.tcp.ReplicationListener</gbeanType:attribute>
<gbeanType:attribute name="initParams">
tcpListenAddress=127.0.0.1
tcpListenPort=4001
tcpSelectorTimeout=100
tcpThreadCount=6
</gbeanType:attribute>
</gbeanType:gbean>
<!-- Sender -->
<gbeanType:gbean name="TomcatSender" class="org.apache.geronimo.tomcat.cluster.SenderGBean">
<gbeanType:attribute name="className">
org.apache.catalina.cluster.tcp.ReplicationTransmitter</gbeanType:attribute>
<gbeanType:attribute name="initParams">
replicationMode=pooled
ackTimeout=15000
</gbeanType:attribute>
</gbeanType:gbean>
<!-- Valves -->
<gbeanType:gbean name="ReplicationValve" class="org.apache.geronimo.tomcat.ValveGBean">
<gbeanType:attribute name="className">org.apache.catalina.cluster.tcp.ReplicationValve</gbeanType:attribute>
<gbeanType:attribute name="initParams">
filter=.*\.gif;.*\.js;.*\.css;.*\.png;.*\.jpeg;.*\.jpg;.*\.htm;.*\.html;.*\.txt;
</gbeanType:attribute>
<gbeanType:reference name="NextValve">
<gbeanType:name>JvmRouteBinderValve</gbeanType:name>
</gbeanType:reference>
</gbeanType:gbean>
<gbeanType:gbean name="JvmRouteBinderValve" class="org.apache.geronimo.tomcat.ValveGBean">
<gbeanType:attribute name="className">
org.apache.catalina.cluster.session.JvmRouteBinderValve</gbeanType:attribute>
<gbeanType:attribute name="initParams">
enabled=true
</gbeanType:attribute>
</gbeanType:gbean>
|
|
Specifica Parametri Configurazione Cluster
|
top
|
• Membership: come detto sopra, ogni membro del cluster deve essere componente di una rete multicast e condividere quindi con gli altri membri del cluster lo stesso indirizzo multicast e porto. Attraverso tale indirizzo, ogni membro del cluster comunica agli altri che è attivo e funzionante e ascolta quali altri server sono attivi nel cluster.
Tale funzionalità viene espletata grazie al fatto che ogni membro del cluster deve trasmettere ad intervalli regolari un cosiddetto “heartbeat”.
Se un server non trasmette tale segnale nell’intervallo temporale predefinito, viene considerato “death” dagli altri e quindi non fa più parte del cluster. Nel caso in esame, i parametri di membership specificati sono quelli indicati nel GBean relativo. In particolare si noti il parametro mcastFrequency, che rappresenta ogni quanto tempo viene inviato l’ heartbeat e il parametro mCastDropTime che rappresenta l’intervallo di tempo dopo il quale un server è considerato death se da esso non arriva il segnale di esistenza.
• Receiver: rappresenta il GBean deputato alla ricezione delle variazioni dello stato degli asltri server attraverso l’utilizzo di una socket. I parametri di configurazione più importanti sono: l’indirizzo IP, il porto di ascolto e gli intervalli di ascolto
• Sender: Rappresenta il GBean deputato all’invio delle variazioni dello stato della sessione applicativa agli altri server. Esistono tre tipologie di invio delle informazioni: Asynchronous, synchronous,pooled. Nel caso in esame si è scelta la modalità pooled, che è una estensione della modalità sincrona con l’utilizzo di code di invio diversificate per i diversi sottogruppi di server appartenenti al cluster.
Una volta specificate tutte le proprietà che caratterizzano il cluster, verrà generato l’archivio compresso relativo all’applicazione ed essa dovrà essere installata su ogni nodo del cluster. Per fare ciò è sufficiente avviare la console di amministrazione di Geronimo e cliccando (Fig.5) sulla voce Deploy New verrà visualizzato un form che permetterà di specificare la locazione del file con estensione “war” relativo all’applicazione.
Fig. 5: Consolle di installazione
Se l’installazione avrà esito positivo, cliccando sulla voce Web App WARs sarà possibile visualizzare tra le altre applicazioni anche quella dell’esempio corrente.
Ovviamente tale processo andrà ripetuto su tutti i nodi che costituiscono il cluster.
Al termine di tale procedura avremo a disposizione un certo numero di server che opereranno in regime di replicazione della sessione applicativa.
|
|
Bilanciamento del carico
|
top
|
Per fare in modo che il carico di lavoro tra i due server in cluster sia sottoposto ad un bilanciamento, è necessario utilizzare un livello in più nell’architettura costruita fin ora, livello che si interporrà tra i client e il cluster.
Tale livello può ad esempio essere costituito da un server tipo Apache Web Server che esporrà un indirizzo a cui punteranno tutti i client.
Tale server quindi, nella ipotesi in cui il cluster sia formato da due soli nodi (serverA e serverB), utilizzando le regole di bilanciamento del carico re-indirizzerà le richieste http al nodo più scarico. Vorrei anche porre l’attenzione sul fatto che la distribuzione oculata del lavoro garantisce anche il failover cioè la presenza del servizio nel caso in cui uno o più server non sia più disponibile.
La configurazione del server Apache prevede di utilizzare uno strumento di bilanciamento tipo : mod_jk. Per installare tale strumento è necessario eseguire queste operazioni:
• Copiare il file mod_jk.so (o ddl a seconda del S.O.) nella directory modules
• Nel file httpd.conf aggiungere le righe seguenti:
FIle di Configurazione Apache Web Server
# Loads the Jakarta Tomcat Connector module
LoadModule jk_module C:\Programmi\Apache Group\Apache2\modules\mod_jk_1.2.6_2.0.50.dll
JkWorkersFile C:\Programmi\Apache Group\Apache2\conf\workers.properties
# Tells the module the location of the workers.properties file
JkLogFile C:\Programmi\Apache Group\Apache2\logs\mod_jk.log
# Specifies the location for this module's specific log file
JkLogLevel error
# Sets the module's log level to info
#JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
# Sets the module's log time stamp format
JkMount /console/* ajp13
Sarà poi necessario creare un file di nome workers.properties nella cartella dove si trova il file httpd.conf, tale file serve per configurare il bilanciatore del traffico e mappare i nodi che costituiscono il cluster riportando il nome di ognuno di essi, in modo che le richieste http possano essere indirizzate nel modo desiderato.
Le impostazioni fondamentali di tale file sono mostrate nella casella di testo seguente:
Impostazione bilanciatore di traffico
worker.list=loadbalancer,status
worker.node1.port=8009
worker.node1.host=your.first.cluster.member.host.name
worker.node1.type=ajp13
worker.node1.lbfactor=1
worker.node2.port=8009
worker.node2.host=your.second.cluster.member.host.name
worker.node2.type=ajp13
worker.node2.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2
worker.loadbalancer.sticky_session=1
worker.status.type=status
/symbolic-name-of-application=loadbalancer
/ symbolic-name-of-application /*=loadbalancer
Si noti che i nomi degli host dovranno essere gli stessi di quelli usati per configurare il parametro “jvmRoute” all’interno del file config.xml di ogni server del cluster.
|
|
Conclusioni
|
top
|
A questo punto non rimane che avviare i server Geronimo e successivamente avviare il server Web.
Da questo momento in poi tutte le richieste http indirizzate al server Web verranno redirette secondo la politica imposta dal bilanciamento del traffico garantendo anche il failover che assicurerà il servizio anche in caso di crash di uno o più server.
|
|
|
| |
| JavaPortal è ideato da: |
 |
Eccetto dove diversamente specificato, i contenuti di questo sito sono rilasciati sotto licenza Creative Commons
|
|
|
Documentazione
>
