Concludiamo con questa parte il nostro tutorial su WebSphere. In questo articolo vedremo come aggiungere nuovi nodi alla nostra configurazione del cluster di failover, nell‘ottica di Alta disponibilità, Bilanciamento, Scalabilità e Fault Tolerance affrontata nell‘articolo precedente.
Aggiunta di un nuovo nodo
Aggiungiamo alla cella creata un nuovo application server. La procedura è quella già descritta con la variante relativa al profilo che in questo caso sarà di tipo “Custom”. Per questo tipo di profilo il Profile Managemant Tool ci propone la possibilità di federare questo nodo a una cella già definita. Indicheremo quindi, del deployment manager responsabile della nostra cella, il server, la porta su cui è in ascolto, e le credenziali di autenticazione.
Figura 1 – Federazione di un nuovo nodo.
Sarà anche possibile federare questo nodo successivamente alla sua creazione.
Figura 2 – Federazione del nodo successiva alla sua creazione.
È possibile federare ogni nodo attraverso il comando addNode nel caso in cui durante la creazione di questo profilo il deployment manager non sia in esecuzione o sia disabilitato il connettore SOAP. Al termine sarà necessario avviare il nodo attraverso il comando /bin/startNode.sh
La creazione di un Custom Profile di fatto crea solo un nodo con un node agent. Ciò è infatti rappresentato dalla topologia corrente:
Figura 3 – Topologia attuale della cella.
I node agent presenti su questa cella saranno:
Figura 4 – Elenco dei node agent definiti nella cella.
Figura 5 – Elenco dei nodi definiti nella cella.
Creazione del Cluster
La creazione del cluster avviene a partire dalla topologia corrente, dove nella cella amministrata dal deployment manager sono federati un application server sul nodo Node01 mentre nel nodo c’è solo un node agent.
Figura 6 – Topologia corrente della cella.
Avviamo la procedura di creazione del cluster; al primo passo indichiamo il nome e selezioniamo le opzioni relative alla localizzazione degli EJB e alla configurazione della replica “memory to memory” della sessione HTTP. La prima rappresenta un meccanismo di ottimizzazione per cui le richieste RMI vengono ruotate verso il nodo dove è distribuito il client. L’altra rappresenta la modalità con cui un cluster di WebSphere mantiene sincronizzata la sessione HTTP tra server federati.
Figura 7 – Definizioni per il cluster che si vuole creare.
Passiamo al secondo passo creando il primo membro del cluster per conversione dell’application server (server1) definito nel nodo Node01.
Figura 8 – Creazione dell’application server a partire dal’istanza esistente sul nodo Node01.
Aggiungiamo quindi un nuovo application server al cluster. Questo risiederà sul nodo “Custom profile” NodeC02 presente nella topologia della cella (cfr. Figura 3).
Figura 9 – Definizione del nuovo application server e del nodo di pertinenza.
Aggiorniamo le porte di ascolto HTTP definite per il virtual host.
Figura 10 – 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.
Di seguito la topologia risultante del nodo e quella del cluster.
Figura 11 – Topologia attualizzata della cella.
Figura 12 – Topologia attualizzata del cluster.
Federazione di un nodo WebSphere presente su un altro server e ampliamento del cluster
Proseguiamo l’attività di creazione del cluster di WebSphere federando un nuovo nodo, definito su un altro calcolatore, nella cella di deployment precedentemente creata. Vedremo come la configurazione e applicazioni attualmente distribuite sul cluster verranno propagate verso il nuovo application server.
La creazione di questo cluster è stata fatta utilizzando due sistemi operativi virtuali Red Hat Enterprise Linux AS release 4. Prerequisito alle operazioni di federazione del nodo sulla cella di deployment e ampliamento del cluster è l’aggiornamento nel file hosts con le entry relative ai due server.
Figura 13 – File /etc/hosts.
Creazione di un profilo custom su un altro server e federazione di questo nella cella di deploy
A questo punto accediamo al secondo calcolatore e creiamo un nuovo profilo di tipo custom. Durante il wizard di ci viene proposta la federazione ad un deployment manager esistente. Come indicato dalla figura di seguito indichiamo il deployment manager in ascolto sulla porta 8881 della macchina .
Il wizard propone, per questo profilo, le seguenti porte di ascolto.
Figura 15 – Porte di ascolto del nodo.
La stessa operazioni di federazione del nodo al deployment manager può essere fatta da linea di comando. Sarà necessario lanciare il comando addNode sul profilo 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 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]#
La cella di deployment assumerà così la seguente topologia.
Figura 16 – Topologia attualizzata della cella.
Aggiungiamo questo nodo al cluster definito in precedenza.
Figura 17 – Membri del cluster.
L’ampliamento del cluster al nuovo server avviene attraverso la creazione di questo nel nodo appena federato. Il nome di questo server dovrà essere univoco nel l’ambito del cluster, mentre bisognerà selezionare il nodo di appartenenza tra quelli già federati alla cella di deployment. In questo caso il nodo appena creato sulla macchina .
Figura 18 – Creazione del nuovo membro del cluster.
Figura 19 – Elenco dei server attualmente federati nel cluster.
Figura 20 – Definizione del server.
Al termine del wizard viene lanciata la sincronizzazione della configurazione tra i membri del cluster.
Figura 21 – Sincronizzazione della configurazione.
Di seguito l’elenco degli application server WebSphere che partecipano al cluster.
Figura 22 – Elenco dei server del cluster.
La topologia del cluster assume pertanto la seguente configurazione.
Figura 23 – Topologia del Cluster.
A questo punto sarà necessario aggiornare il virtual host con la porta di ascolto HTTP del nuovo server. Solo così sarà possibile reindirizzare le chiamate http verso il nuovo nodo.
Figura 24 – Aggiornamento del virtual host.
In verde le porte HTTP assegnate ai due server presenti sul primo host, mentre in rosso quella assegnata all’application server in esecuzione sul secondo.
Dal punto di vista della distribuzione una volta creato il cluster potremo mappare i moduli di un’applicazione J2EE sul cluster o sul web server. Non sarà quindi più possibile la distribuzione sui singoli elementi del cluster, che di fatto non sono più visibili durante il deploy.
Figura 25 – Mapping dei moduli J2EE sui contesti di distribuzione.
Sul protocollo HTTP sarà possibile accedere all’applicazione web alle seguenti URL:
http:///ivt/ivtDate.jsp
che risolvendo il virtual host sfrutta il failover e il bilanciamento delle richieste;
http://:9080/ivt/ivtDate.jsp
accede alla web application bypassando l’http server e puntando direttamente l’embedded web server dell’application server server1;
http://:9081/ivt/ivtDate.jsp
analogo per il server2;
http://:9081/ivt/ivtDate.jsp
analogo per il server3;
Sul protocollo IIOP (iiop://:) possiamo ottenere l’interfaccia remota di un ejb, attraverso una look up JNDI diretta sui node agent del cluster o sul node agent del deployment manager. Solo in quest’ultimo caso si sfruttano i meccanismi di clusterizzazione del sistema.
Figura 26 – Tabella dei risultati della look-up JNDI diretta sui node agent.
Comandi di deploy nel cluster definito
In riferimento a quanto riportato nella definizione di un cluster standalone, per risolvere 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" ivt_app.war,WEB-INF/web.xml default_host}} -MapModulesToServers {{ "IVT EJB Module" ivtEJB.jar,META-INF/ejb-jar.xml WebSphere_cell=Cell01,cluster=TestCluster} {"IVT Application" ivt_app.war,WEB-INF/web.xml WebSphere_cell=Cell01,cluster=TestCluster+ WebSphere_cell=Cell01,node=ihsnode,server=webserver1 }}} $AdminConfig save
MapWebModToVH
Mappa il modulo web al default host in ascolto sulla porte HTTP (9080, 9081 per il , e 9081 per il )
MapModulesToServers
META-INF/ejb-jar.xml: Mappa il modulo EJB sul cluster e quindi su gli application server che lo definiscono
WEB-INF/web.xml: Mappa il modulo WAR sul cluster e quindi sugli embedded web server degli application server che partecipano al cluster.
Memo: avvio dei nodi e del deployment manager
Dopo aver riavviato il sistema operativo perche’ il cluster sia di nuovo disponibile, sarà necessario avviare ciascun node agent, ciascun server e il deployment manager. In figura 27 c’è l’avvio del nodo sul profilo AppSrv01.
Figura 27 – Avvio del nodo.
In figura 28, c’è l’avvio del server server1 sul profilo AppSrv01
Figura 28 – Avvio del server.
Figura 29 – Avvio del deployment manager.
Ultimate queste operazioni la console amministrativa sarà disponibile all’URL
https://was61host00:9045/ibm/console
Conclusioni
In questo tutorial di 4 puntate abbiamo illustrato la creazione di un cluster di server WebSphere, cercando di focalizzare la nostra 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