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.
Vedremo come WebSphere realizza un ambiente di questo tipo.
Per prima cosa andiamo a definire una cella amministrata da un deployment manager: un particolare server che gestisce la configurazione degli application server WebSphere federati in questa cella.
E' lui che si occupa della propagazione delle configurazioni verso tutti gli AS federati.[ ]{.Apple-converted-space}
Nella cella amministrativa andremo a federare anche un http Server che si occuperà di bilanciare il carico delle richieste verso gli http server embedded nei was federati. Definiremo quindi un primo nodo di questa cella. Sullo stesso calcolatore definiremo un altro nodo sempre federato nella cella amministrativa creata e creeremo il nostro cluster di fail over. L'ipotesi è che il calcolatore di cui disponiamo abbia sufficienti risorse per mettere in esecuzione tutti questi as.
Andiamo con ordine e procediamo alla creazione di un profilo di deployment manager che definisce anche la cella amministrativa sottostante (cfr. figura\....). Come già descritto avviamo il Profile Management Tool di WebSphere che è disponibile nella all'interno della distribuzione dei binari di WebSphere: \<was_root\>/bin/ProfileManagement/pmt.sh. Sceglieremo l'installazione di un profilo "Deployment manager" scegliendo la creazione di un profilo avanzato e il deploy della console amministrativa. Definiremo quindi il nome della nodo di appartenenza del DMng e della cella. Il wizard si conclude con la definizione della sicurezza (accesso alla console e avvio dei moandi amministrativi) e l'assegnazione delle porte che utilizzerà il DMng e il sommario relativo alla creazione del profilo.Per agilità non documentiamo questi passi vista che sono del tutto omologhi a quelli riportati per il server stand alone.[ ]{.Apple-converted-space}
Riportiamo il nome del profilo scelto e la sua locazione sul file system.[ ]{.Apple-converted-space}
Fig.27-- Locazione sul file system del profilo.
Fig.28-- Locazione sul file system del profilo.
Avviamo il Deployment manager attraverso il comando start Manager.sh nella directory bin del profilo.
Fig.29-- Avvio del deployment manager da linea di comando.
Avviamo la console amministrativa disponibile all'indirizzo[ ]{.Apple-converted-space}
Fig.30-- Informazioni di runtime del Deployment manager.
Notiamo subito rispetto alla console amministrativa del server stand alone il menu di sinistra dove è presente la voce System administration, dove è possibile visualizzare le scelte in merito al nome del nodo che ospita il deployment manager e il nome della cella che questo amministra.
Proseguiamo con la creazione del nostro Cluster. Creiamo e federiamo un nodo con un application server. Sempre attraverso il Profile Management Tool di WebSphere definiamo un profilo di tipi "Application server" selezionando la modalità avanzata di creazione del profilo. Richiediamo il deploy della applicazioni di default ma non serve il deploy della console visto che questo nodo sarà federato nella cella prima creata. Come già visto per la creazione del server stand alone definiamo il path del profilo, il nome della cella, i grant amministrativi.[ ]{.Apple-converted-space}
Federiamo questo server nella cella definita.
Sempre nel manu System administrtion[ ]{.Apple-converted-space}
Fig.31-- Aggiunta di un nodo.
Aggiungiamo un nodo "managed", un nodo contenente un application server che è in esecuzione all'interno della cella amministrata dal DMNg. Questo tipo di nodo è associato ad un node agent che propaga la configurazione del Dmng.[ ]{.Apple-converted-space}
Fig.31-- Informazioni relativi al nodo.
Dovremmo indicare l'host dove è in esecuzione l'application server che vogliamo federare, le grant di questo e quelle del deployment manager .
\<inserire log was in display\>
Una volta federato questo nodo avremmo.
Fig.32-- Nodo aggiunto.
Nella lista degli application server disponibili avremmo a disposizione il server1 sul nodo \<SERVER00\>Node01
Fig.33-- Application server del nodo creato.
A questo punto il nodo entra a far parte della cella amministrativa propagando le configurazioni verso questo server attraverso il node agent.
Di seguito l'attuale topologia della cella.
Fig.34-- Topologia della cella.
Andiamo a definire all'interno di questa cella l'http Server a cui sarà demendata la gestione del carico delle richieste http.[ ]{.Apple-converted-space}
Al'interno di una cella di WebSphere possiamo federare molti tipi di http server, nel nostro caso utilizziamo IBM HTTP Server. [ ]{.Apple-converted-space}
Non ci resta che definire un http Server che ci permetta di distribuire il carico delle richieste http verso tutti gli application server definiti nella cella di deploy e di gestire possibili fault di uno dei partecipanti reindirizzando le richieste verso quelli ancora attivi.[ ]{.Apple-converted-space}
Installazione dell'http server di IBM.
Una volta installato l'http Server di IBM questo sarà in ascolto sulla porta 80 mentre l'HTTP administration port sarà in ascolto sulla porta 8008. Nel nostro caso l'installazione è :
Fig.34-- File system di IBM HTTP Server.
Il nome del server http è riscontrabile nella cartella /opt/IBM/HTTPServer00/Plugins/logs/webserver1 è il nome del web server definito.
Fig.35-- Home page di IBM HTTP Server.
Andiamo a gestire questo http server nella cella di deploy :
attraverso la creazione di un nodo unmanaged vuoto e aggiungendo a questo nodo il web server appena creato. Un nodo di questo tipo non ospita un processo server e un node agent. Ricordiamo che I nodi unmanaged usano IBM http Server Admin Service invece del node agent per controllare il web server .
Fig.36-- Nodo per IBM HTTP Server.
Aggiungiamo il web server definito nella cella creata. Dobbiamo specificare il nome del nodo e il nome del web server.
Fig.37-- Creazione di un web server: puntamento all'HTTP Server.
Specifichiamo il puntamento al web server[ ]{.Apple-converted-space}
Fig.38-- Creazione di un web server: proprietà dell'HTTP Server.
Alla voce di menu Web Server troveremo:
Fig.39-- lista degli HTTP Server disponibili nella cella.
La topologia della cella sarà:
Fig.40-- Topologia attuale della cella.
A questo punto la cella di deploy è costituita da un server HTTP e un application server WebSphere. Se proviamo a distribuire un'applicazione J2EE dovremo indicare al deployment manager come mappare i moduli sui server disponibili nella cella.
Fig.41-- Ambiti di deploy.
Se proviamo a distribuire un'applicazione J2EE costituita da un modulo EJB e un modulo web (WAR) mappando quest'ultimo sia sul server WebSphere che sull'HTTP Server mentre il modulo EJB solo sul server WebSphere.
Fig.42-- Mapping dei moduli J2EE.
Questo mapping dei moduli sui server definiti determina la disponibilità di questa applicazione sia alla url dell'embedded web server dell'application di WebSphere (porta 8080) che sulla porta 80 dove è in ascolto l'HTTP Server.[ ]{.Apple-converted-space}
Fig.42-- Accesso alle risorse web dell'applicazione distribuita sul web server e sull'application server.
I rispettivi log sui due server saranno disponibili nella cartelle logs del profilo.
Aggiunta di un nuovo nodo[ ]{.Apple-converted-space}
Aggiungiamo a questa cella un nuovo application server.[ ]{.Apple-converted-space}
Creiamo dapprima un nuovo nodo sempre attraverso il Profile Managemant Tool. Il profilo che creeremo sarà di tipo "Custom profile". Analogamente a quanto già descritto durante il wizard definiamo il nome del Nodo. A questo punto ci viene richiesto la possibilità di federare questo nodo ad una cella già definita. federarlo al dmng definito in precedenza. Indicheremo server e su quale porta questo è in ascolto, oltre alle credenziali di autenticazione.
Fig.43-- Federazione del nodo.
Ma è anche possibile federare questo nodo successivamente.
Fig.44-- Federazione del nodo.
E' possibile federare ogni nodo attraverso il comando addNode nel caso in cui il deployment manager non sia in esecuzione o è disabilitato il connettore SOAP. Al termine sarà necessario avviare il nodo attraverso il comando \<profile_root\>/bin/startNode.sh[ ]{.Apple-converted-space}
La creazione di un Custom Profile di fatto crea solo un nodo con un node agent. Come infatti rappresentato dalla topologia corrente:
Fig.45-- Topologia attualizzata della cella.
I node agent presenti su questa cella saranno:
Fig.46-- Lista dei node agent definiti nella cella.
Fig.47-- Lista dei nodi definiti nella cella.
Creazione del Cluster
A partire dalla topologia corrente dove nella cella ammnistrata dal dmgf sono federati un application server sul nodo Node01 e un nodo dove c'è solo un node agent.
Fig.48-- Topologia attualizzata nella cella.
Creiamo il nostro cluster.
Fig.49-- Definizione del nome del Cluster.
Fig.49-- Creazione dell'application server a partire dal'istanza esistente sul Node01 del primo host.
Fig.50-- Definizione del nome del server e del nodo su cui crearlo.
Aggiungiamo la porta di ascolto http al virtual host
Fig.51-- Aggiornamento del virtual host.
In verde la definizione della porta di ascolto HTTP dell'application server server1 sul primo nodo e in blu quella dell'application server2 sul secondo nodo.[ ]{.Apple-converted-space}
Di seguito la topologia del nodo e quella del cluster
Fig.51-- Topologia attualizzata della cella.
Fig.52-- Topologia del cluster.
Federazione di un nodo presente su un altro server e ampliamento del cluster
A partire dal server1 del primo profilo creiamo un cluster propagando la sua configurazione verso il server2 sul nuovo profilo che viene creato in questa fase. La configurazione del server 1 viene propagata assieme alle applicazioni correntemente deployate.[ ]{.Apple-converted-space}
Preequisito della federazione (nell'esempio ho usato due vm linux)
Fig.53-- File /etc/hosts.
Creazione e federazione di un nodo custom su un altro server[ ]{.Apple-converted-space}
A questo punto accediamo al secondo calcolatore e definiamo un nuovo Nodo. Durante la creazione di questo ci[ ]{.Apple-converted-space}
Fig.53-- Federazione del Nodo nella cella.[ ]{.Apple-converted-space}
Con le porte di ascolto :
Fig.54-- Porte di ascolto del nodo.[ ]{.Apple-converted-space}
\<non va bene c'è il server1\>
Oppure da linea di comando col comando addNode sul profilo del server02 appena creato
\[root@was61host02 bin\]# ./addNode.sh was61host00 8881\ ADMU0116I: Tool information is being logged in file\
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/addNode.log\ ADMU0128I: Starting tool with the AppSrv01 profile\ CWPKI0309I: All signers from remote keystore already exist in local keystore.\ ADMU0001I: Begin federation of node was61host02Node01 with Deployment Manager\ at was61host00:8881.\ ADMU0001I: Begin federation of node was61host02Node01 with Deployment Manager\ at was61host00:8881.\ ADMU0009I: Successfully connected to Deployment Manager Server:\ was61host00:8881\ ADMU0505I: Servers found in configuration:\ ADMU0506I: Server name: server1\ ADMU2010I: Stopping all server processes for node was61host02Node01\ ADMU0512I: Server server1 cannot be reached. It appears to be stopped.\ ADMU0024I: Deleting the old backup directory.\ ADMU0015I: Backing up the original cell repository.\ ADMU0012I: Creating Node Agent configuration for node: was61host02Node01\ ADMU0014I: Adding node was61host02Node01 configuration to cell:\ was61host00Cell01\ ADMU0016I: Synchronizing configuration between node and cell.\ ADMU0018I: Launching Node Agent process for node: was61host02Node01\ ADMU0020I: Reading configuration for Node Agent process: nodeagent\ ADMU0022I: Node Agent launched. Waiting for initialization status.\ ADMU0030I: Node Agent initialization completed successfully. Process id is:\ 11432\ ADMU9990I:\ ADMU0300I: The node was61host02Node01 was successfully added to the\ was61host00Cell01 cell.\ ADMU9990I:\ ADMU0306I: Note:\ ADMU0302I: Any cell-level documents from the standalone was61host00Cell01\ configuration have not been migrated to the new cell.\ ADMU0307I: You might want to:\ ADMU0303I: Update the configuration on the was61host00Cell01 Deployment Manager\ with values from the old cell-level documents.\ ADMU9990I:\ ADMU0306I: Note:\ ADMU0304I: Because -includeapps was not specified, applications installed on\ the standalone node were not installed on the new cell.\ ADMU0307I: You might want to:\ ADMU0305I: Install applications onto the was61host00Cell01 cell using wsadmin\ \$AdminApp or the Administrative Console.\ ADMU9990I:\ ADMU0003I: Node was61host02Node01 has been successfully federated.\ \[root@was61host02 bin\]#\
Sul deploy manager avremo la seguente topologia risultante
Fig.55-- Topologia attualizzata della cella.[ ]{.Apple-converted-space}
Aggiungiamo questo nodo al cluster prima definito[ ]{.Apple-converted-space}
Fig.56--Membri del cluster.
Fig.57-- Aggiunta del nuovo server sul cluster.[ ]{.Apple-converted-space}
In questa fase viene creato un nuovo server sul nodo[ ]{.Apple-converted-space}
DOPO IL ADD MEMBER (SERVER3 NOME UNIVOCO NEL CLUSTER) di fatto punteremo al server compreso nel nodo (server1) che avevamo creato
Fig.58-- Lista dei server federati nel cluster.[ ]{.Apple-converted-space}
Fig.59-- Definizione del server.[ ]{.Apple-converted-space}
Al termine viene fatta la sincronizzazione
Fig.60-- Sincronizzazione della configurazione.
Lista dei server che partecipano a questo cluster[ ]{.Apple-converted-space}
Fig.61-- Elenco dei server federati.
Di seguito la topologia del cluster
Fig.62-- Topologia del Cluster.
Aggiornare il default_host per reindirizzare le chiamate http verso il nuovo nodo[ ]{.Apple-converted-space}
Fig.63-- Aggiornamento del default host.
In Verde le porte HTTP assegnate ai due server presenti sulla prima macchina e in rosso quella assegnata all'app server sulla seconda macchina
L'applicazione J2EE avrà i moduli mappati secondo i contesti come possiamo notare dopo aver federato i server nel cluster non è più disponibile il contesto su ciascuno di loro. Non è più possibile fare una distribuzione su singola su di essi.
Fig.64-- Mapping dei moduli J2EE sui contesti di distribuzione.
In termini di accesso http[ ]{.Apple-converted-space}
È possibile accedere all'applicazione web
Attraverso
l'HTTP server alla url http://\<SERVER00\>/ivt/ivtDate.jsp che sfrutta il bilanciamento e quindi il virtual_host
Il server 1 [ ]{.Apple-converted-space}http://\<SERVER00\>:9080/ivt/ivtDate.jsp[ ]{.Apple-converted-space}
Il server 2 [ ]{.Apple-converted-space}http://\<SERVER00\>:9081/ivt/ivtDate.jsp[ ]{.Apple-converted-space}
Il server 3 [ ]{.Apple-converted-space}http://\<SERVER02\>:9081/ivt/ivtDate.jsp[ ]{.Apple-converted-space}
\<INSERIRE ENDO POINT DEGLI EJB\>
Creazione profilo server federato: differenza : esistenza del server node agent che interagendo con il dmng riceve la configurazione. Fare immagine.[ ]{.Apple-converted-space}
Comandi di deploy nel cluster definito
Facendo riferimento alla definizione di un cluster stand alone per rioslvere le esigenze di integrazione di progetto, il comando di deploy varia come segue
installApp.jacl:
\$AdminApp install /opt/IBM/WebSphere/AppServer/installableApps/ivtApp.ear {-appname IVTApplication -MapWebModToVH {{\"IVT Application\" ivtapp.war,WEB-INF/web.xml defaulthost}} -MapModulesToServers {{\"IVT EJB Module\" ivtEJB.jar,META-INF/ejb-jar.xml[ ]{.Apple-converted-space}
WebSphere:cell=\<SERVER\>Cell01,cluster=TestCluster}
{\"IVT Application\" ivt_app.war,WEB-INF/web.xml[ ]{.Apple-converted-space}
WebSphere:cell=\<SERVER\>Cell01,cluster=TestCluster+ WebSphere:cell=\<SERVER\>Cell01,node=ihsnode,server=webserver1 }}}
\$AdminConfig save
-MapWebModToVH
Mappa il modulo web al default host in ascolto sulla porte HTTP (9080, 9081 per il \<SERVER00\>, e 9081 per il \<SERVER02\>)
-MapModulesToServers
1) META-INF/ejb-jar.xml
Mappa il modulo EJB sul cluster e quindi su gli application server che lo definiscono
2) WEB-INF/web.xml
Mappa il modulo WAR sul cluster e quindi sugli embedded web server degli application server che partecipano al cluster.[ ]{.Apple-converted-space}
Memo: riavvio dei nodeagent
Dopo un riavvio del sistema operativo sarà necessario riavviare i node agent poi i server (o il cluster se ne è stato definito uno) (il deployment manager)[ ]{.Apple-converted-space}
Avvio del nodo sul profilo AppSrv01
Fig.66-- Avvio del nodo.
Avvio del server server1 sul profilo AppSrv01
Fig.67-- Avvio del server.
Conclusioni
Abbiamo dato una panoramica sul provisioning degli ambienti server da quello più semplice stand alone alla creazione di un ambiente clusterizzato con was. Scalabilità: aggiungiamo un nuovo server per esigenze computazionali.[ ]{.Apple-converted-space}
Bibliografia
[ ]{.Apple-converted-space}HYPERLINK \"http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp\" [http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp]
[http:// HYPERLINK \"http://www.webspheretools.com\" www.webspheretools.com]
Appendice:
Sequenza di avvio
Profilo 1 :[ ]{.Apple-converted-space}
startNode.sh --username wasadmin --password wasadmin
startServer.sh server1 --username wasadmin --password wasadmin
Profilo 2 :[ ]{.Apple-converted-space}
startNode.sh --username wasadmin --password wasadmin
startServer.sh server1 --username wasadmin --password wasadmin
Deployment manager
startManager.sh --username wasadmin --password wasadmin
Appendice: argomenti da trattare
alta disponibilità
bilanciamento
Fault tolerance
Scalabilità orizzontale e verticale.[ ]{.Apple-converted-space}
Bilanciatori hardware.[ ]{.Apple-converted-space}
Bilanciamento degli ejb sull'rmi (esempio di deploy di un EJB)
Creazione di una cella, server
Jvm di ciascuna istanza (vedere appunti)
Installazione dell HTTP server di apache
Configurazione round robin
Mostrare come le richieste vanno sui due server
Fermo di un ambiente: business continuity
Plug in: che vuol dire[ ]{.Apple-converted-space}
Analisi delle cartelle.
Analisi dei Logs.
Pagina[ ]{.Apple-converted-space}PAGE 1 di[ ]{.Apple-converted-space}NUMPAGES 31