Proseguiamo il nostro tutorial su WebSphere affrontando la creazione di un cluster di failover. Avremo in tal modo a disposizione, nella nostra architettura a cluster, uno strumento che consenta la prosecuzione del servizio, che prevenga la perdita dei dati, e che, in definitiva, consenta un migliore assolvimento dei compiti per cui il sistema è stato progettato.
Introduzione
Andremo adesso a creare un cluster di application server, per poi conlcudere sul prossimo numero il nostro tutorial su WebSphere. Prima di passare all’opera, però, intendiamo fornire un brevissimo riassunto su alcuni aspetti fondamentali nell’architettura che ci riguarda: si tratta dei concetti di alta disponibilità bilanciamento, fault tolerance e scalabilità (orizzontale e verticale).
Alta disponibilità (HA, High Avalaibility)
Con il concetto di “alta disponibilità” si intende la capacità di un sistema di garantire la continuità nell’erogazione dei servizi. Nell’ambito di un cluster, nel caso in cui un nodo si blocchi, il carico delle richieste che il nodo inattivo non può più processare vengono reindirizzate verso gli altri nodi del sistema. Tutto ciò in un contesto di completa trasparenza per i consumatori ai quali i servizi sono esposti da un unico endpoint. La ridondanza dei nodi definiti in un cluster ha come obiettivo l’eliminazione dei punti deboli del sistema (i così detti “single point of failure”) attraverso procedure automatiche che mantengono i nodi sincronizzati tra loro.
Bilanciamento (Load Balancing)
Quando parliamo di “bilanciamento” ci riferiamo alla capacità di un sistema composto da più calcolatori di ottimizzare le proprie risorse indirizzando le richieste verso i nodi del sistema più scarichi. L’obiettivo di un cluster di load-balancing è l’ottimizzazione delle prestazioni complessive di un sistema, attraverso il bilanciamento e la distribuzione del carico delle richieste utente verso i nodi che lo costituiscono.
Scalabilità
Con il termine di “scalabilità” si indica quella positiva caratteristica di un sistema che permette di mantenere costanti le capacità computazionali all’aumentare delle richieste di un servizio. La scalabilità verticale si ottiene incrementando le risorse hardware di un calcolatore (essenzialmente RAM, CPU e/o dischi). In questo contesto l’aumento della capacità computazionale non cresce linearmente all’aumentare delle risorse, ma è comunque limitato dall’hardware e dai programmi in esecuzione. La scalabilità orizzontale si realizza con un cluster di calcolatori. L’aumento delle esigenze computazionali, derivante dall’incremento delle richieste dei servizi, viene soddisfatto aggiungendo nuovi nodi al cluster.
Fault Tolerance
Un sistema distribuito è per definizione un’aggregazione multipla di elementi. In un tale contesto la tolleranza ai guasti è un aspetto che assume una importanza rilevante. Maggiore è il numero degli elementi di un sistema, maggiore è la probabilità che ciascuno di essi possa andare in fault, determinando un’interruzione del servizio. Ciò rende la tolleranza ai guasti un requisito fondamentale al crescere dei sistemi distribuiti. Le tecniche sottostanti alla creazione di un cluster (alta disponibilità, bilanciamento e scalabilità) permettono a un sistema distribuito di garantire elevati livelli di fault tolerance.
Definizione di una cella amministrata dal deployment manager
Dopo aver messo a disposizione dei singoli gruppi un ambiente dove poter realizzare l’integrazione del software, ci accingiamo a creare un ambiente server più robusto dove realizzare l’integrazione di tutto il software proveniente dai vari gruppi. Un ambiente di integrazione con queste caratteristiche di robustezza può essere realizzato attraverso un cluster di WebSphere.
Per prima cosa andiamo a definire una cella amministrata da un deployment manager: un particolare server che gestisce la propagazione della configurazione degli application server WebSphere federati in questa cella.
Nella cella amministrativa andremo a federare anche un server HTTP che si occuperà di bilanciare il carico delle richieste verso gli HTTP server embedded negli application server federati. Definiremo quindi un primo nodo di questa cella.
Sullo stesso calcolatore definiremo un altro nodo sempre federato nella cella amministrativa creata e creeremo quindi il nostro cluster di failover. L’ipotesi è che il calcolatore di cui disponiamo abbia risorse sufficienti a tenere in esecuzione questi application server.
Andiamo con ordine e procediamo alla creazione di un profilo di deployment manager che definisce anche la cella amministrativa sottostante. Come già descritto avviamo il Profile Management Tool di WebSphere che è disponibile nella cartella di distribuzione dei binari di WebSphere
/bin/ProfileManagement/pmt.sh
Sceglieremo l’installazione di un profilo “Deployment manager” con l’opzione di creazione di un profilo avanzato e di deploy della console amministrativa. Definiremo quindi il nome della nodo di appartenenza del Deploy Manager e della cella. Il wizard comprende la definizione della sicurezza in termini di firma di accesso alla console e di lancio dei comandi amministrativi da linea di comando e l’assegnazione delle porte che utilizzerà il Deployment Manager. Al termine, la creazione del profilo, verrà riportata sotto forma di sommario. Per agilità non documentiamo questi passi in quanto analoghi a quelli riportati per il server standalone visto nelle parti precedenti.
Figura 1 – Nome del profilo e percorso di installazione sul file system.
Figura 2 – Collocazione del profilo sul file system.
Avviamo da linea di comando il Deployment manager attraverso il comando startManager.sh che si trova nella directory bin del profilo.
Accediamo alla console amministrativa disponibile all’indirizzo
https://:9045/ibm/console
Notiamo subito che, rispetto alla console amministrativa del server stand alone, il menu di sinistra si arricchisce della voce “System administration”, che raggruppa le funzioni di amministrazione della cella amministrata del deployment manager.
Proseguiamo con la realizzazione del nostro cluster, creando un nodo con un application server WebSphere, federandolo alla cella appena definita. Sempre attraverso il Profile Management Tool di WebSphere creiamo in modalità avanzata un profilo di tipo “Application server”. Durante il wizard verrà richiesto il deploy dell’applicazioni di default, mentre non sarà necessario il deploy della console visto che questo nodo sarà federato nella cella definita in precedenza. Come già visto, anche per questo profilo definiamo il percorso di creazione, il nome della cella, e la firma di amministrazione.
Ultimata la creazione di questo profilo, federiamo questo application server nella cella amministrativa. La figura 5 riporta l’aggiunta di un nodo attraverso il link “Nodes” del menu System administration.
Figura 5 – Aggiunta di un nodo.
Aggiungiamo un nodo “managed”, un nodo cioè che contiene un application server che è in esecuzione all’interno della cella amministrata dal deployment manager. A questo tipo di nodo è sempre associato a un “node agent” a cui sono demandate le funzioni di propagazione della configurazione del deployment manager.
Figura 6 – Informazioni relative al nodo.
Dovremmo indicare l’host dove è in esecuzione l’application server che vogliamo federare, la sua firma amministrativa e quella del deployment manager . Di seguito riportiamo la topologia della cella dopo la federazione di questo nodo.
Figura 7 – Topologia della cella dopo la federazione del nuovo nodo.
Nella lista degli application server disponibili avremmo a disposizione il server1 sul nodo Node01
A questo punto il nodo entra a far parte della cella amministrativa. Le configurazioni della cella verranno da questo momento propagate verso questo server attraverso il node agent. La topologia della cella assume la configurazione descritta dalla figura 9.
Completiamo questa fase definendo in questa cella un server HTTP il cui compito è quello di gestire le richieste HTTP. Si tratta di un componente, all’interno di un cluster, che ha il compito di distribire il carico delle richieste verso tutti gli application server e di gestire possibili fault dei sistemi reindirizzando le richieste verso quelli ancora attivi. All’interno di una cella di WebSphere possiamo federare molti tipi di server HTTP: nel nostro caso utilizziamo IBM HTTP Server.
Installazione dell’HTTP server di IBM
Una volta installato e avviato l’HTTP server di IBM questo sarà in ascolto sul protocollo HTTP sulla porta 80 mentre sulla porta 8008 (HTTP administration port) sarà in ascolto il listener di amministrazione.
Il nome del server HTTP è quello definito dalla cartella
/opt/IBM/HTTPServer00/Plugins/logs/webserver1
Sarà possibile aggiungere l’HTTP server nella cella di deploy attraverso la creazione di un nodo “unmanaged” vuoto. In WebSphere si definisce “unmanaged” un nodo che non ospita un processo server e un node agent. In un nodo si questo tipo il web server viene controllato attraverso il servizio “IBM HTTP server Admin Service” contrariamente a quanto accade per i nodi “managed” dove la propagazione delle configurazioni è garantita dal node agent.
La creazione di un nodo “unmanaged” modifica la struttura della cella che assume la topologia indicata dalla figura 12 dove il nodo ihsnode è al momento vuoto.
Aggiungiamo il web server alla cella di deploy. Dobbiamo specificare il nome del nodo unmanaged e il nome del web server in esecuzione.
Il wizard si conclude specificando le proprietà del web server.
Terminata la procedura di associazione del web server alla cella, alla voce di menu “Web Server” troveremo quanto descritto in figura 15.
La cella a questo punto assumerà la seguente topologia:
Figura 16 – Topologia attuale della cella.
A questo punto la cella di deploy è costituita da un server HTTP e un application server WebSphere. La distribuzione di un’applicazione Java EE avverrà indicando al deployment manager la mappatura dei moduli sui server disponibili nella cella.
Se prendiamo in esame una ipotetica applicazione Java EE (EAR) costituita da un modulo EJB e un modulo web (WAR), il deploy avviene mappando quest’ultimo sia sul server WebSphere che sull’HTTP Server mentre il modulo EJB va mappato solo sul server WebSphere.
Questo mapping determina la disponibilità della web application sia alla URL dell’embedded web server dell’application di WebSphere (porta 8080) che sulla porta 80 dove è in ascolto l’HTTP Server.
I rispettivi log sui due server saranno disponibili nella cartelle logs del profilo corrispondente.
Conclusioni
Mancano ancora molti passi importanti per concludere la creazione di un cluster di server WebSphere, ma per questa volta ci fermiamo qui e li vedremo nella quarta e ultima parte di questa serie su WebSphere, che intende focalizzare l’attenzione sulle modalità con cui possiamo realizzare la scalabilità orizzontale di un sistema di questo tipo.
Riferimenti
[1] WebSphere Application Server, Versione 6.1
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
[2] Steve Robinson, WebSphere Tools
http://www.webspheretools.com