Tomcat è un Application Server: un contenitore di applicazioni sviluppate attraverso il linguaggio di programmazione Java. Tomcat viene impiegato generalmente per l’esposizione di web service e questa sua attitudine, in caso di applicazioni critiche per importanza, deve essere obbligatoriamente associata all’alta affidabilità. Esso nativamente supporta un modello di cluster, che consente a diverse istanze di condividere le sessioni, in modo da garantire la sopravvivenza del servizio: se quindi un’istanza smette di funzionare, il suo ruolo viene assunto dall’istanza sopravvissuta.
Ma chi si occupa del controllo delle istanze stesse?
Questo articolo descrive un caso di studio relativo ad un cluster nativo Tomcat le cui istanze vengono gestite da Heartbeat attraverso il Cluster Resource Manager Pacemaker.
Installazione di Java
Java è essenziale per il funzionamento di Tomcat ed è anche il primo software da configurare per ottenere il risultato prefissato in questo articolo. Per prima cosa quindi sarà necessario scaricare il pacchetto di installazione dal sito ufficiale di SUN presso il link http://www.java.com/it/download/linux_manual.jsp?locale=it&host=www.java.com.
Ottenuto il file jre-6u23-linux-i586.bin, il cui nome potrà variare a seconda della versione, questo va eseguito:
# chmod +x jre-6u23-linux-i586.bin
# ./jre-6u23-linux-i586.bin
L’esecuzione del file creerà una cartella nominata jre1.6.0_23 che sarà possibile spostare in un path consono, ad esempio /usr/local, per il quale potrà essere creato un link simbolico:
# mv jre1.6.0_23 /usr/local
# ln -s /usr/local/jre1.6.0_23 /usr/local/java
In questo modo sarà possibile far riferimento al path /usr/local/java per il raggiungimento degli eseguibili java ed inoltre, in caso di installazioni di versioni diverse di Java, basterà cambiare il puntamento del link simbolico.
Installazione di Tomcat
L’installazione di Tomcat viene descritta in maniera generalista, indipendente quindi dalla distribuzione utilizzata.
Per prima cosa quindi è necessario scaricare l’ultima versione dell’application server Tomcat, andando sul sito ufficiale di Tomcat (http://tomcat.apache.org/download-70.cgi) oppure scaricando il pacchetto da uno dei mirror:
# wget http://it.apache.contactlab.it/tomcat/tomcat-7/v7.0.6/bin/apache-tomcat-7.0.6.tar.gz -o /tmp/apache-tomcat-7.0.6.tar.gz
una volta terminato lo scaricamento, è possibile decomprimere il pacchetto in un path di sistema, ad esempio (e per convenzione) /usr/local:
# cd /usr/local
# tar -xzvf /tmp/apache-tomcat-7.0.6.tar.gz
# ln -s apache-tomcat-7.0.6 tomcat
L’ultimo comando lanciato crea un link simbolico, in modo che in futuro per accedere alla directory di Tomcat sarà sufficiente utilizzare il percorso /usr/local/tomcat.
Installazione di Heartbeat e Pacemaker
L’installazione dell’apparato cluster offerto dal progetto Linux-ha non verrà descritta in questo articolo, in quanto ampiamente trattata nei precedenti articoli della serie, in particolare nella puntata confronto pratico tra Heartbeat classico ed Heartbeat con Pacemaker.
Configurazione di Tomcat
La configurazione prevede due fasi: la prima relativa alle credenziali di accesso, la seconda relativa alle impostazioni per il clustering.
All’interno del file /usr/local/tomcat/conf/tomcat-users.xml sono definite le utenze di accesso alle diverse componenti dell’application server, in particolare, per permettere all’utente tomcat di gestire l’installazione di nuove applicazioni attraverso l’interfaccia web disponibile, il contenuto del file dovrà essere il seguente:
Inutile dire come il campo password debba essere modificato in base alla password scelta.
L’abilitazione del cluster Tomcat, data la natura introduttiva dell’articolo, verrà fatta nella modalità più semplice, così come illustrato dalla documentazione ufficiale di Tomcat (http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html), abilitando cioè la seguente riga all’interno del file /usr/local/tomcat/conf/server.xml:
La configurazione preliminare dell’application server è così completa.
Configurazione di Heartbeat e Pacemaker
Appena avviato il demone Heartbeat:
# /etc/init.d/heartbeat start
è possibile definire le configurazioni preliminari del cluster:
# crm configure property stonith-enabled="false"
# crm configure property no-quorum-policy="ignore"
# crm configure primitive ping ocf:pacemaker:ping params host_list="192.168.0.254" name="ping" op monitor interval="10s" timeout="60s" op start timeout="60s" op stop timeout="60s"
# crm configure clone ping_clone ping meta globally-unique="false"
Come spiegato nei precedenti articoli queste configurazioni preliminari indicano di non utilizzare stonith, ignorare l’assenza di quorum e creare una risorsa ping che controlli la connettività in entrambi i nodi attraverso il clone della risorsa stessa.
Maggiori informazioni e spiegazioni approfondite si trovano nella seconda parte del secondo articolo della serie.
In particolare l’ultima definizione, ossia la risorsa clonata per il controllo della connettività, favorisce lo spunto per la configurazione della risorsa Tomcat per la quale esiste un resource agent apposito: http://www.linux-ha.org/doc/re-ra-tomcat.html. Essendo obiettivo del progetto la gestione per mezzo di Pacemaker delle istanze di Tomcat, ed essendo le istanze di Tomcat in tutto e per tutto simili su entrambi nodi, queste potranno essere assimilate ad un’unica risorsa clonata.
Nel dettaglio, la configurazione sarà la seguente:
crm configure primitive cluster_tomcat ocf:heartbeat:tomcat params java_home="/usr/local/java/" catalina_home="/usr/local/tomcat/" op monitor interval="60s" timeout="30s" op start interval="0" timeout="60s" op stop interval="0" timeout="120s"
crm configure clone cluster_tomcat_clone cluster_tomcat meta globally-unique="false" target-role="Started"
crm configure location cluster_tomcat_on_connected_node cluster_tomcat_clone -inf: not_defined ping or ping lte 0
Nel dettaglio:
- Viene definita la risorsa cluster_tomcat i cui parametri sono il path in cui è installato Java (java_home) ed il path di tomcat stesso (catalina_home);
- La risorsa cluster_tomcat viene clonata dalla nuova risorsa cluster_tomcat_clone. Così come per la risorsa ping_clone che risiederà su ciascun nodo definito, anche questa avrà lo stesso comportamento;
- Viene definita una location, ossia un vincolo che obbliga la risorsa clonata a funzionare unicamente sui nodi la cui connettività è comprovata (nodi su cui cioè la risorsa ping esiste e restituisce un risultato positivo);
A questo punto, la situazione del cluster dovrebbe essere la seguente:
============
Last updated: Mon Jan 24 10:17:05 2011
Stack: Heartbeat
Current DC: tomcatcluster-nodo2 (b091eddc-aa64-4d7d-8407-65a7dddafbdf) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, unknown expected votes
2 Resources configured.
============
Online: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]
Clone Set: ping_clone
Started: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]
Clone Set: cluster_tomcat_clone
Started: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]
Ed entrambe le istanze di Tomcat dovrebbero essersi avviate su ciascun nodo. E’ possibile verificarlo provando ad accedere all’interfaccia web di amministrazione presente su ciascun nodo:
http://tomcatcluster-nodo1:8080/manager/html
http://tomcatcluster-nodo2:8080/manager/html
Entrambi link dovrebbero essere funzionanti e richiedere uno username con password per accedervi. Una volta inserite le credenziali definite in fase di configurazione di Tomcat, sarà visibile l’interfaccia di amministrazione delle applicazioni.
Analisi dei log
L’avvio dei servizi Tomcat da parte del cluster può essere seguito dai file di log dell’application server stesso, all’interno dei quali è possibile verificare se il cluster nativo di Tomcat viene attivato correttamente.
# cat /usr/local/tomcat/logs/catalina.out
...
INFO: Cluster is about to start
...
INFO: Setting cluster mcast soTimeout to 500
...
INFO: Server startup in 3153 ms
...
21-gen-2011 17.05.47 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{192, 168, 0, 1}:4000,{192, 168, 0, 2},4000, alive=1259, securePort=-1, UDP Port=-1, id={101 64 89 59 2 -44 67 123 -73 23 4 -50 -57 105 8 58 }, payload={}, command={}, domain={}, ]
...
Il server è avviato e certamente ha considerato la configurazione, includendo l’host (memberAdded) 192.168.0.52 nel cluster.
Configurazione applicazione di Test
La configurazione può dirsi completa. E’ possibile quindi installare una semplice applicazione di test per verificare nell’effettivo il funzionamento delle sessioni condivise. Per fare ciò è sufficiente creare un’applicazione configurata con il parametro “
L’applicazione TestSession, scaricabile dal portale è stata configurata proprio a questo scopo:
Una volta scaricato il file TestSession.war, attraverso la console Tomcat e su ciascun nodo, sarà possibile installare l’applicazione nella sezione “WAR file to deploy”, selezionando il fie “war” scaricato e premendo il tasto “deploy”. Se l’esito sarà “OK”, entrambe le applicazioni saranno disponibili attraverso l’indirizzo:
http://tomcatcluster-nodo1:8080/TestSession
http://tomcatcluster-nodo2:8080/TestSession
E’ possibile dunque avviare i test.
Test di funzionamento
Il principio di funzionamento del cluster è quello di rispondere alle richieste. Generalmente in questo tipo di architettura, gli Application Server risiedono dietro a bilanciatori, cioè apparati hardware o software che distribuiscono il carico attraverso batterie di macchine che offrono servizi.
L’architettura di test predisposta non prevede l’utilizzo di un bilanciatore, a per simulare il bilanciamento del carico tra i due host sarà sufficiente inserire nel file /etc/hosts della propria macchina queste due righe:
192.168.0.1 tomcatcluster
#192.168.0.2 tomcatcluster
Come scritto in precedenza quindi, l’applicazione potrà essere chiamata come segue, senza far riferimento all’IP:
http://tomcatcluster:8080/TestSession/
Il test funzionerà in modo che chiamato l’url relativo al quale si passa un parametro, ad esempio:
http://tomcatcluster:8080/TestSession/session.jsp?aaa=111
la pagina visualizzi quanto segue:
Server info
* Name: tomcatcluster-nodo1
* Address: 192.168.0.1
Session Attributes
* aaa = 111
Ovviamente le chiamate successive con parametri differenti aggiungeranno nuovi attributi.
Nella fattispecie, chiamare:
http://tomcatcluster:8080/TestSession/session.jsp?bbb=222
produrrà:
Server info
* Name: tomcatcluster-nodo1
* Address: 192.168.0.1
Session Attributes
* aaa = 111
* bbb = 222
Il test a questo punto è semplicissimo, modificando il file /etc/hosts in modo che appaia come segue:
#192.168.0.1 tomcatcluster
192.168.0.2 tomcatcluster
Di fatto il secondo nodo ora sarà quello attivo. Richiamando nuovamente lo script:
http://tomcatcluster:8080/TestSession/session.jsp?ccc=333
Si otterrà il seguente output:
Server info
* Name: tomcatcluster-nodo2
* Address: 192.168.0.2
Session Attributes
* aaa = 111
* bbb = 222
* ccc = 333
Da notare come nel Server info ora il nodo sia tomcatcluster-nodo2, mentre i dati di sessione sono stati mantenuti.
Il corretto funzionamento è verificabile anche accedendo singolarmente a ciascun tomcat ai link presenti nella pagina manager nella colonna “Sessions”, dove vengono elencate le sessioni, che ovviamente hanno lo stesso codice su entrambi gli Application server.
Conclusioni
Terminata questa carrellata di concetti e test una cosa è chiara: come sempre questo è solo l’inizio. Sono moltissimi gli ambiti in cui soluzioni come (o simili) a quella presentata possono essere messe in produzione per ottenere infrastrutture stabili, sicure e funzionali. Sempre e comunque altamente affidabili.
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Lascia un commento