Tema 4: Creación de un cluster

Este tema contiene las instrucciones básicas para obtener las características más potentes de un servidor de aplicaciones: la escalabilidad y la recuperación ante fallos. Para ello aprenderemos a configurar un cluster y determinadas características adicionales como un servidor proxy y la replicación de memoria.

Un cluster es una asociación de servidores WebLogic que actúan como si fueran uno solo. Una aplicación desplegada en un cluster es respondida por cada servidor dentro del cluster. Si nuestro sistema observa un aumento en el número de peticiones, podemos incorporar nuevos servidores para soportar dicho aumento. Otra característica, la recuperación ante fallos, es muy importante en sistemas de alta disponibilidad. WebLogic nos va a permitir replicar las sesiones HTTP e incluso los servicios (por ejemplo, JDBC) para que se permita realizar copias de las sesiones en otros servidores. De esta forma, si el servidor que está sirviendo actualmente tiene algún problema o no responde, el servidor que contiene la copia de la sesión puede seguir respondiendo sin necesidad de comenzar una nueva sesión.

4.1. Configuración básica de un cluster

Para configurar un cluster pinchamos en el icono de cluster y nos aparecerá una figura como la siguiente. Pinchamos en Configure a new Cluster.

En la siguiente figura debemos empezar a configurar el cluster. Comentamos las distintas opciones:

En la siguiente solapa debemos chequear la dirección de multicast. El multicast permite la comunicación entre los servidores del cluster. Esta dirección se configura desde el sistema operativo. Por defecto es la mostrada en la figura (el puerto por defecto es también el 7777). Si queremos chequear si funciona la dirección podemos hacer uso de una utilidad de WebLogic. Desde dos sesiones distintas del sistema operativo tecleamos el siguiente comando:

java -cp $BEA_HOME/weblogic700/server/lib/weblogic.jar utils.MulticastTest 
-n mensaje -a dirección

donde mensaje es el mensaje que se enviará a la dirección de multicast y dirección es la dirección multicast a utilizar. Ponemos mensajes distintos en cada sesión y debemos recibir los dos mensajes.

Pasamos a la solapa Servers donde debemos indicar los servidores que participarán en el cluster. Los servidores deben estar parados para poder asignarlos al cluster.

En la solapa Monitoring podemos saber el número de servidores configurados para el cluster y los activos en este momento. Si pinchamos en Monitor server participation... nos aparece la figura mostrada más abajo donde se nos muestra información de los distintos servidores.

Para desplegar una aplicación al cluster (y así que todos los servidores del cluster respondan a la aplicación) debemos asignar la aplicación al cluster. Para ello, en la solapa Targets seleccionamos Clusters en vez de Servers. Es muy importante no desplegar la misma aplicación a un cluster y además a un servidor que forme parte del cluster.

También podemos arrancar todos los servidores que formen parte de un cluster a la vez, si tenemos configurado el NodeManager. Pinchamos con el botón derecho en el icono del cluster y seleccionamos Start this cluster...

 

4.2. Configuración de un servidor proxy

Una vez creado el cluster como se indicaba en el apartado anterior ya lo tenemos disponible para su utilización. Sin embargo, cada servidor tiene su propia dirección IP, por lo que si tenemos una aplicación desplegada en el cluster, ¿a qué dirección IP debe direccionar el cliente su petición?. Podemos pedir a un servidor (que pertenezca al cluster) en concreto y éste responderá, pero perderemos el balanceo de carga. Para solucionar este problema se suele insertar un servidor proxy HTTP entre el cluster y el cliente. Este servidor proxy será un servidor de aplicaciones que tendrá asociada una aplicación que se encargará de realizar el balanceo de carga. También se puede utilizar otro servidor proxy (como Apache) o incluso un proxy hardware. En esta sección vamos a ver cómo podemos configurar un servidor proxy haciendo uso de una utilidad que incorpora Weblogic. Esta utilidad no es más que una clase que implementa un servlet para realizar el balanceo de carga.

Lo primero a realizar es la creación de un servidor de aplicaciones, al que llamaremos proxy. Vamos a asociar una aplicación a este servidor de aplicaciones. Para ello vamos a crear una aplicación vacía, que contendrá sólo el fichero de descripción de aplicación (web.xml) el cual utilizará un servlet de Weblogic. Creamos un fichero web.xml que contendrá la siguiente información:

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc. //DTD Web Application 
    2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> 
<web-app>

    <servlet> 
    	<servlet-name>HttpClusterServlet</servlet-name> 
    	<servlet-class>
	    weblogic.servlet.proxy.HttpClusterServlet 
    	</servlet-class> 
    
    	<init-param> 
	    <param-name>WebLogicCluster</param-name> 
	    <param-value> 
    	    	miguel.dccia.ua.es:7736:7737|miguel.dccia.ua.es:7736:7737
	    </param-value> 
    	</init-param>
<init-param> <param-name>DebugConfigInfo</param-name> <param-value>ON</param-value> </init-param>
</servlet>
<servlet-mapping> <servlet-name>HttpClusterServlet</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>
<servlet-mapping> <servlet-name>HttpClusterServlet</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping>
<servlet-mapping> <servlet-name>HttpClusterServlet</servlet-name> <url-pattern>*.htm</url-pattern> </servlet-mapping>
<servlet-mapping> <servlet-name>HttpClusterServlet</servlet-name> <url-pattern>*.html</url-pattern> </servlet-mapping>
</web-app>

Este fichero de descripción consta de las siguientes partes:

Una vez creado este fichero creamos un directorio WEB-INF y movemos el fichero web.xml dentro de este directorio. Para crear la aplicación web utilizamos el siguiente comando:

jar cf proxyApp.war WEB-INF/*

donde proxyApp.war es el nombre que le hemos dado a la aplicación. Debemos desplegar la aplicación dentro de nuestro dominio y asociarla al servidor proxy. El último paso es hacer que esta aplicación sea la aplicación por defecto del servidor proxy. Para ello pinchamos en el servidor proxy y nos posicionamos en la solapa Connections HTTP. Debemos seleccionar proxyApp en la opción Default Web Application. A partir de este momento ya podemos disponer de balanceo de carga en el cluster creado. Ahora podemos atacar cualquier aplicación desplegada en el cluster solicitando la dirección del proxy.

4.3. Configuración de la replicación de memoria

La última característica por configurar es la recuperación ante fallos. Cuando un cliente realiza una petición a un servidor, se crea una instancia de la sesión. Si un servidor se viene abajo (ya sea por problemas técnicos o por desconexión por mantenimiento de la máquina) y está dando servicio a un determinado cliente, la sesión HTTP, los servicios EJB y toda la memoria asociada a ese cliente se pierde. Para solucionar este problema, WebLogic nos permite configurar la replicación de memoria. La replicación de memoria nos permite especificar dónde van a ser almacenadas las copias de las sesiones. Vamos a trabajar con grupos de replicación, que son una agrupación lógica de servidores relacionados en un cluster. Lo recomendable es que los servidores en la misma máquina estén en el mismo grupo de replicación. Cuando se crea una sesión, WebLogic crea una réplica de la sesión y la envía a otro servidor siguiendo este orden de preferencia:

  1. Primero trata de encontrar un servidor que no esté en su misma máquina y que pertenezca a su grupo secundario preferido.
  2. Si ningún servidor cumple lo anterior, trata de buscar un servidor que pertenezca a su grupo secundario preferido aunque no esté en otra máquina.
  3. La tercera opción es que el servidor no pertenezca a su grupo secundario preferido, pero resida en otra máquina.
  4. La última opción es que ni pertenezca a su grupo preferido ni resida en otra máquina.

Para definir los servidores en un grupo de replicación y en el secundario, debemos definir, en cada servidor, a qué grupo pertenecen. El nombre de los grupos nos definimos los nosotros. En la siguiente figura podemos observar los nombres elegidos para un servidor.