Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

144 ottobre
, anno 2009

WebSphere in cluster

III parte: Creazione di un Cluster di failover

Luigi Bennardis

Luigi Bennardis

Luigi Bennardis si è laureato in Scienze Statistiche ed Economiche all’Università di Roma. Si occupa di informatica da un po’ di tempo ed è attualmente impegnato su tematiche DevOps. Nel tempo libero ancora gioca a basket, nuota ed è appassionato di elettronica vintage.

MokaByte

WebSphere in cluster

III parte: Creazione di un Cluster di failover

Luigi Bennardis

Luigi Bennardis

  • Questo articolo parla di: Architetture dei sistemi, Frameworks & Tools, Programmazione & Linguaggi

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.

Figura 3 – Avvio del deployment manager da linea di comando.

Accediamo alla console amministrativa disponibile all’indirizzo

https://:9045/ibm/console
Figura 4 – Informazioni di runtime del deployment manager.

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

Figura 8 – Application server definiti nel nodo creato.

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.

Figura 9 – Topologia della cella.

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.

Figura 10 – File system di installazione dell’HTTP Server di IBM.

Il nome del server HTTP è quello definito dalla cartella

/opt/IBM/HTTPServer00/Plugins/logs/webserver1
Figura 11 – Home page di IBM HTTP Server.

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.

Figura 12 – Nodo unmanaged per IBM HTTP Server.

Aggiungiamo il web server alla cella di deploy. Dobbiamo specificare il nome del nodo unmanaged e il nome del web server in esecuzione.

Figura 13 – Creazione di un web server: puntamento all’HTTP Server.

Il wizard si conclude specificando le proprietà del web server.

Figura 14 – Creazione di un web server: proprietà dell’HTTP Server.

Terminata la procedura di associazione del web server alla cella, alla voce di menu “Web Server” troveremo quanto descritto in figura 15.

Figura 15 – Elenco degli HTTP Server disponibili nella cella.

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.

Figura 17 – Ambiti di deploy.

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.

Figura 18 – Mapping dei moduli J2EE.

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.

Figura 19 – Accesso all’applicazione web distribuita sul web server e sull’application 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

 

 

Facebook
Twitter
LinkedIn
Luigi Bennardis

Luigi Bennardis

Luigi Bennardis si è laureato in Scienze Statistiche ed Economiche all’Università di Roma. Si occupa di informatica da un po’ di tempo ed è attualmente impegnato su tematiche DevOps. Nel tempo libero ancora gioca a basket, nuota ed è appassionato di elettronica vintage.

Luigi Bennardis

Luigi Bennardis

Luigi Bennardis si è laureato in Scienze Statistiche ed Economiche all’Università di Roma. Si occupa di informatica da un po’ di tempo ed è attualmente impegnato su tematiche DevOps. Nel tempo libero ancora gioca a basket, nuota ed è appassionato di elettronica vintage.
Tutti gli articoli
Nello stesso numero
Loading...

ZK, un semplice e potente web framework basato su Ajax

II parte: Il pattern MVC in ZK con Spring

Il programmatore e le sue API

XVII parte: Il logging corretto

Interoperabilità tra applicazioni: un approccio orientato ai Web Service

II parte: Java e PHP. Framework di comunicazione

Semantic knowledge base: un help desk semantico per l‘open source

I parte: Metriche di valutazione e modelli di maturità

Semantic Web. Esplorazione/visualizzazione di ontologie

II parte: Tecnologie per il recupero di informazioni

Sviluppo rapido di applicazioni con Groovy & Grails

V parte: Le relazioni in GORM

Nella stessa serie
Loading...

WebSphere in cluster

IV parte: Completiamo il cluster di failover

WebSphere in cluster

II parte: Creazione di un server standalone

WebSphere in cluster

I parte: Sviluppo parallelo e ambienti di integrazione

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte