Per cluster di application servers si intende una serie di istanze del server su cui girano le stesse risorse (le stesse Java web applications). Generalmente istanze diverse girano su Java Virtual Machine differenti e su macchine fisiche separate (sebbene appattenenti alla stessa sottorete) e questo introduce tutta una serie di problematiche peculiari al clustering. Il motivo per cui si ricorre a questa architettura è che in applicazioni di un certo peso la disponibilità del servizio (e le sue prestazioni) devono essere per quanto possibile garantite. In maniera molto semplice (e anche non del tutto precisa), un cluster di tre istanze è sempre in grado di svolgere il suo lavoro (garantire la disponibilità del sito all’utente finale) anche se una o due istanze dovessero incepparsi o crashare. Non solo, se mi accorgo che il sito e molto trafficato, posso sempre aggiungere un’istanza al cluster per ripartire il lavoro (scalabilità). Tutto questo inoltre avviene in maniera trasparente per l’utente finale che, anche se loggato ad un sito, non perderà la sessione, né si accorgerà di nessun cambiamento qualora alcune istanze del cluster dovessero avere dei problemi perché quelle rimaneni si faranno carico del lavoro.
Proseguendo il precedente post, vediamo come installare un architettura cluster su più server Linux fisicamente distinti. Suppongo si siano eseguite le istruzioni per installare Glassfish su un singolo server con supporto cluster abilitato come spiegato nel precedente articolo.
Se avete seguito le istruzioni, l’installazione di Glassfish che ne risulterà, sarà il nostro DAS (Domain Administration Server) vale a dire il nodo centrale di amministrazione delle varie istanze che comporranno il cluster.
È possibile installare una o più istanze all’interno di uno stesso cluster e residenti sulla stessa macchina fisica semplicemente leggendo la documentazione ufficiale e con qualche semplice e intuitiva operazione dalla interfaccia web di amministrazione. Caso più interessante è invece l’installazione di istanze su macchine fisiche separate. Partiamo col dire che le macchine devono appartenere alla stessa sottorete e nessun firewall deve impedire la comunicazione tra le varie istanze del cluster ospitate. Detto questo pensiamo di avere due macchine diciamo:
test1.acme.com
e
test2.acme.com
e supponiamo anche di aver già installato Glassfish con supporto cluster su test1.acme.com così come descritto nel precedente post. Logghiamoci a test1.acme.com con l’utente glassfish e avviamo il server:
asadmin start-domain domain1
Avviato il server, la console di amministrazione sarà disponibile all’indirizzo:
ora dobbiamo creare un node agent per test1.acme.com
asadmin create-node-agent --host localhost --port 4848 <node-name>>
dove “nodename” è il nome da noi scelto per il nodo (per esempio test1-node). Senza scendere nei dettagli, dobbiamo avere un agent node su ogni singola macchian fisica che entrerà a far parte del cluster. Dalla console di amministrazione possiamo proseguire creando un nuovo cluster e una nuova istanza che assegneremo al cluster (e che avrà come node agent il nodo appena creato e per ora l’unico disponibile). Ora avviamo il node-agent appena creato:
asadmin start-node-agent --syncinstances=true <node-name>
Ora ci dobbiamo loggare sulla seconda macchina che ospiterà una o più istanze del nostro cluster: test2.acme.com. Su questo server dobbiamo installare Glassfish per cui rimando al post precedente alle sezioni “installare il JDK” e “installare ANT”. In questo caso però non abbiamo bisogno di un’installazione completa che creerebbe un secondo DAS ridondante, per cui invece di eseguire il comando
lib/ant/bin/ant -f setup-cluster.xml
useremo questo di seguito:
lib/ant/bin/ant -f setup-cluster.xml create-node-agent --nodeagent <node-agent-name> -Ddas.host="test1.acme.com"
Dove “host” è l’host su cui è installato il DAS (nel nostro caso test1.acme.com) e <node-agent-name> è il nome del nuovo nodo che stiamo per creare (per esempio test2-node). Ci deve essere un node agent per ogni macchina fisica distinta destinata ad ospitare istanze del cluster e ovviamente il nome del nodo deve essere unico entro un cluster.
Avviamo il nuovo node agent creato su test2:
asadmin start-node-agent --syncinstances=true <node-agent-name>
Logghiamoci alla admin console (o facciamo un refresh se siamo già loggati) e nella sezione dedicata ai nodi dovremmo poter essere in grado di vedere il nuovo nodo appena creato su test2.acme.com. Sempre attraverso l’interfaccia web di amministrazione possiamo creare nuove istanze appartenenti al cluster e assegnarle il nodo su test2. Questo vuol dire che l’istanza verrà creata e girerà su test2.acme.com.
Le istanze del cluster girano su porte particolari. Se, per esempio, creiamo due istanze su test2.acme.com e una su test1.acme.com avremo le varie istanze del server in ascolto su queste porte:
- http://test1.acme.com:38080 (prima ed unica istanza su test1)
- http://test2.acme.com:38080 (prima istanza su test2)
- http://test2.acme.com:38081 (seconda istanza su test2)
A questo punto di solito si prosegue creando un load balancer e integrando Glassfish con un web server tipo Apache. Avremo quindi un unico URL con cui invocare la nostra applicazione java e dietro le quinte il load balancer deciderà concretamente (e in maniera trasparente per l’utente) a quale istanza del cluster indirizzare la richiesta.
Un ultima nota dedicata più agli sviluppatori Java. Le librerie (file .jar) che dovrebbero essere condivise tra le farie applicazioni java deployate su uno stesso cluster (per esempio un driver jdbc per un database) dovrebbero essere piazzate qui:
<glassfish-home>/domains/domain1/config/<cluster-name>-config/lib
La documentazione completa sul clustering su Glassfish (e argomenti correlati) è disponibile qui:
http://glassfish.dev.java.net/nonav/javaee5/docs/SJSASEEHAAG.pdf
Il Pinguino Furioso 