lunes, 17 de septiembre de 2012

Alta Disponibilidad de Sesiones con Managed Servers en Cluster en WebLogic 12c


Las sesiones que crean nuestras aplicaciones son muy importantes, perderlas no es una opción y más cuando se están manejando compras o alguna otra transacción que implique algún monto monetario. Es necesario tener alta disponibilidad de estas sesiones. Oracle WebLogic posee una característica cuyo concepto ya es muy conocido: Un Cluster.

Cada aplicación dentro de WebLogic Server está alojada en un contenedor llamado Managed Server el cual es una analogía con el ya descontinuado OC4J del antiguo OAS. Si el Managed Server se caé, la aplicación dejaria de ser accesible para nuestros clientes o usuarios, lo cual en muchas empresas no puede suceder, siempre hay aplicaciones críticas, que deben estar disponibles. En WebLogic tambien se maneja el concepto "Machine", el cual no es más que la representación lógica de un servidor físico. Un Managed Server es asignado a un "Machine" y finalmente un "Cluster" es compuesto por uno o más Managed Servers alojados en uno o más "Machines".

A continuación la definición que oracle dá a cada uno de estos conceptos:

Administration Server: The Administration Server operates as the central control entity for the configuration of the entire domain. It maintains the domain's configuration documents and distributes changes in the configuration documents to Managed Servers. You can also use the Administration Server as a central location from which to monitor all resources in a domain.


Managed Server: Managed Servers host business applications, application components, Web services, and their associated resources. To optimize performance, Managed Servers maintain a read-only copy of the domain's configuration document. When a Managed Server starts up, it connects to the domain's Administration Server to synchronize its configuration document with the document that the Administration Server maintains.


Cluster: A cluster is a collection of multiple Oracle WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability.


Por lo tanto si tenemos una aplicación desplegada en nuestro cluster, automaticamente se alojará en cada uno de los Managed Servers que componen ese cluster logrando así Alta Disponibilidad, de tal manera que si un Managed Server se caé, los demás Managed Servers involucrados en el mismo cluster tomarán las sesiones y las seguiran manteniendo disponibles.


En este ejemplo crearemos un Dominio con un cluster compuesto de dos Managed Servers.

Las variables de entorno que debemos definir antes de iniciar el ejemplo son las siguientes:

JAVA_HOME= /usr/jrockit/jrockit-jdk1.6.0_33-R28.2.4-4.1.0
MW_HOME= /u02/Middleware
WLS_HOME= /u02/Middleware/wlserver_12.1/

Primero debemos ejecutar el Asistente de Configuración de Dominios, "config.sh" el cual se encuentra en el $WLS_HOME/common/bin

$cd $WLS_HOME/common/bin
$./config.sh

En la pantalla de bienvenida seleccionar la opcion "Create a new WebLogic domain".


En la pantalla de "Select Domain Source", seleccionar la opcion "Generate a domain configured automatically to support the following products". Luego dar clic en el boton Next.


Escribir el nombre del dominio, y la ruta en donde se crearán todos los archivos necesarios. Luego dar clic en el boton Next.


Especificar el usuario Administrador de nuestro dominio, su contraseña y una pequeña descripción del rol que desempeña. Luego dar clic en el boton Next.




Para nuestro ejemplo seleccionaremos la opcion "Development Mode" y Seleccionamos nuestro JDK, que en este ejemplo es Un Jrockit 1.6.0_33. Clic en el boton Next.


Seleccionamos las opciones "Administration Server" y "Managed Servers, Clusters and Machines". Pues vamos a configurar la "machine", el cluster y sus respectivos Managed Servers. Clic en el boton Next.


Ingresamos el Nombre de nuestro "Administration Server", la direccion en la que escuchará, el puerto y si usará algun puerto seguro. Para nuestro ejemplo unicamente especificamos los primeros tres campos: Name, Listen Address y Listen Port. Clic en el boton Next.


Creamos dos Managed Servers, uno con nombre "myserver_1" y el otro con nombre "myserver_2", escuchando el puerto 8001 y el 8002 respectivamente. No usan conexion segura. Clic en el boton Next.


Cree un Cluster de nombre "mycluster" con modo de mensajes "unicast". Clic en Next.




Agregar nuestros dos Managed Servers (myserver_1, myserver_2) al cluster "mycluster".  Clic en el boton Next.




Crear una "Machine" de nombre "mymachine" que escuche todas las direcciones y que use el puerto 5556. Clic en el boton Next.


Agregar todos nuestros Managed Server incluido el Administration Server a nuestra Machine "mymachine". Clic en el boton Next.


Confirmar todos los datos y finalmente clic en el boton "Create" para que la creacion de nuestro dominio sea creado con una machine, un cluster con dos managed servers y un administration server.


Cuando la creación del dominio finalice, verificar que no haya terminado con errores y finalmente clic en el boton "done".


Una vez creado el dominio, levantamos nuestro Administration Server, para realizar esto debemos  realizar lo siguiente:

$cd $MW_HOME/user_projects/domains/test_domain
$./startWebLogic.sh &


Cuando nuestro Administration Server esté arriba, debemos levantar nuestro Node Manager, el cual es el encargado de comunicarse a los Managed Server y así poderlos subir desde la consola de administración web. Para levantar el Node Manager debemos ejecutar los siguientes pasos:

$cd $MW_HOME/wlserver_12.1/server/bin
$./startNodeManager.sh &


Una vez hecho esto, entramos a la consola de administración web mediante la url:

http://hostname:7001/console

Ingresamos el usuario y la contraseña de nuestro usuario administrador del dominio, tal como se muestra en la siguiente imagen:


Despues de registrarnos correctamente, iremos al panel de “Estructura de Dominio” que queda en la parte izquierda y seguiremos los siguientes pasos:
  1. Clic en Entorno
  2. Clic en Servidores
  3. Clic en la pestaña Control
  4. Seleccionar los Managed Servers myserver_1 y myserver_2.
  5. Clic en el botón “Iniciar”.

Para poder demostrar la alta disponibilidad que brinda un cluster, usaremos una aplicación ya precreada cuyo objetivo es almacenar “productos” dentro de un “carrito” e irlo guardando en una nueva sesión. Esta aplicación ya está empaquetada como un archivo “.ear” y está situado en el directorio /home/oracle de mi maquina.


Procedemos a realizar “deploy” de esta aplicación.

Dentro de la consola de administración web seguimos los siguientes pasos:

1.  Clic en Desplieges 
2.  Clic en “Instalar”


3.  Ingresamos el directorio “/home/oracle” en el campo “ruta de acceso” y elegimos la          aplicación “shoppingcart.ear”. Luego clic en el botón Siguiente.


4.  Clic en “Instalar Despliegue como Aplicación”. Clic en el botón Siguiente.


5.  Clic en “mycluster” para que la aplicación sea desplegada en “Todos los servidores del Cluster”. Clic en el botón Siguiente.


6.  Clic en “Copiar aplicación en cada uno de mis destinos” del menú “Accesibilidad de Origen”. Clic en el botón Siguiente.


7.  Clic en “No, revisaré la configuración más tarde” del menú “Configuracion adicional”. Clic en el botón Finalizar.


8.  Activar los cambios de la sesión y luego Iniciar la aplicación “Sirviendo todas las solicitudes”.


Ahora entramos a nuestra aplicación web por medio del primer managed server (myserver_1) mediante la siguiente dirección:

http://hostname:8001/shoppingcart/

Al entrar a la aplicación empezaremos a comprar productos:



Estos productos van guardándose en nuestro “Carrito” por medio de la creación de una “sesión”.

Si entramos a ver nuestro carrito aparecen los productos que hemos agregado:


Ahora Bajamos un Managed Server “myserver_1” para simular que hubo una caída del mismo, para eso entramos nuevamente a la consola de administración Web y seguimos los siguientes pasos:
  1. Clic en Entorno
  2. Clic en Servidores
  3. Clic en la pestaña Control.
  4. Seleccionamos el Managed Server “myserver_1”.
  5. Clic en el botón “Cerrar” y luego en la opción “Forzar Cierre Ahora”.

Y como vemos el Managed Server “myserver_1” ya esta apagado:


Ahora la sesión tendría que ser retomada por el Managed Server “myserver_2”  por lo cual la sesión no se perdería y también la aplicación seguiría estando disponible para todos mis usuarios o clientes.

Volvemos a entrar a nuestra aplicación web por medio del segundo Managed Server (myserver_2):

http://hostname:8002/shoppingcart/

Vuelvo a entrar a ver los productos que mi carrito lleva recaudado y vemos que los productos que ya había comprado aún siguen en el carrito, y con esto confirmamos que la sesión no se perdió y que la aplicación sigue estando disponible gracias al Cluster de Managed Servers que hemos creado.




sábado, 15 de septiembre de 2012

Oracle WebLogic 12c versión Dev

Para instalar Weblogic 12 no necesitamos tener la instalación completa, Oracle tiene una versión más liviana dedicada únicamente para ambientes de pruebas. Esta versión es de aproximadamente 183MB. La pueden descargar en la siguiente dirección:


El  archivo está bajo la categoría Zip distribution with Oracle WebLogic Server only and intended for WebLogic Server development only.

El archivo se llama: Zip distribution for Mac OSX, Windows and Linux.

Tener un ambiente Weblogic es muy facil y rápido con ayuda de este Zip, prácticamente se resume a la siguiente frase: “Descomprima y uselo”.

El servidor que estoy usando para este ejemplo tiene las siguientes características:

Sistema Operativo: Oracle Linux 5.7 64 bits.
Memoria RAM: 2GB
Espacio en Disco: 10GB
Version de java: JDK 1.6.0_34

A continuación una imagen con las características:


El zip que descargamos desde el sitio de oracle lo hubicamos en “/home/oracle”, debe tener permisos para el usuario oracle y el grupo oinstall.

En la imagen podemos apreciar que el archivo se llama “wls1211_dev.zip”.

Se debe copiar el archivo wls1211_dev.zip al directorio que será nuestro “Middleware Home”, para este ejemplo se utilizó el directorio “/u01/Middleware”.

cp wls1211_dev.zip /u01/Middleware

Despues de haberlo copiado a nuestro Middleware Home, debemos establecer las variables de entorno necesarias: JAVA_HOME, PATH, MW_HOME.

Las variables para este ejemplo se establecieron a los siguientes valores:

export JAVA_HOME= /usr/java/jdk1.6.0_34      
export PATH=$JAVA_HOME/bin:$PATH
export MW_HOME=/u01/Middleware

Se aconseja que estas variables se establezcan en el archivo “.bash_profile” del usuario oracle para que sus valores queden permanentemente.

Luego de esto debemos de hacer el paso mágico, el paso considerado el más difícil de la instalación de WebLogic 12c versión Dev: =)

unzip wls1211_dev.zip


Una vez el archivo haya terminado de descomprimirse, se podrá ver que en el directorio Middleware Home se habran creado varios archivos, tal como lo muestra la siguiente imagen:


Ahora solo nos falta ejecutar el archivo que configura nuestra instalación:

$./configure.sh

Al terminar la ejecución del script, la terminal se verá como la siguiente imagen:



Cuando lleguemos a este paso ya tendríamos “instalado” nuestro WebLogic 12c para pruebas.

Ahora procederemos a crear un pequeño dominio para poder realizar deploy de nuestras aplicaciones.

Primero debemos establecer todas nuestras variables de nuestro ambiente middleware, para esto solo es necesario ejecutar el archivo setWLSEnv.sh hubicado en $MW_HOME/wlserver/server/bin, tal como lo muestra la siguiente imagen:



Oracle recomienda tener un directorio fuera al Middleware Home para alojar nuestros dominios, por lo que seguiremos esta recomendación y crearemos una carpeta en /home/oracle la cual alojará nuestro dominio.

mkdir –p /home/oracle/mydomain
cd /home/oracle/mydomain

Y crearemos el AdminServer, para esto debemos ejecutar la siguiente linea:



$java $JAVA_OPTIONS -Xmx1024m -XX:MaxPermSize=128m -Dweblogic.management.allowPasswordEcho = true weblogic.Server


 A continuación una imagen en la que se muestran esos pasos:


El parámetro “-Dweblogic.management.allowPasswordEcho=true” se pone para evitar el error “Native library(terminalio) to read password securely from commandline not found” provocado por el bug 9094115.

Despues de ejecutar el weblogic.Server, nos aparecerá el siguiente mensaje:

No config.xml was found.
Would you like the server to create a default configuration and boot? (y/n)

Escribir “y” y luego [Enter].



nos pedirá el usuario y la contraseña con que se accederá a la consola de Administración Web. Para nuestro ejemplo, usaremos el usuario weblogic y la contraseña manager1


Finalmente veremos a nuestro AdminServer estar en RUNNING MODE.




Ahora solo nos hace falta entrar a la consola de administración web y logearnos con el usuario “weblogic”, mediante la siguiente ruta:


http://<hostname>:7001/console









viernes, 14 de septiembre de 2012

Procesos muy largos en Weblogic son terminados de manera forzada


A veces nos podemos encontrar con que algunas de nuestras aplicaciones o WebServices que a simple vista  funcionan correctamente, son terminados de manera forzada por el servidor de WebLogic. Vuelven a revisar la aplicacion o WS y comprueban que está correcto. Pues sí, posiblemente el problema no sea la aplicación o WS, sino una mala configuración de los parámetros del WebLogic Server.

WebLogic Server posee la capacidad de poder detectar procesos "estancados", estos procesos estancados son los que llevan mucho tiempo en estar ejecutandose (no en estar ociosos), sin embargo, despues de un largo tiempo no retornan una respuesta. WebLogic no sabe si en realidad el proceso que está ejecutando es muy largo o está estancado, y la decision que toma es categorizarlo como un "proceso estancado". Luego de detectarlo, toma la decision de finalizarlo de manera forzada y así es como nuestra aplicación o WS termina abruptamente.

Lo bueno de tener herramientas de Oracle, es que "casi" todo es totalmente personalizable. Existen dos parametros que pueden ser afinados para poder detectar los procesos "estancados". Se puede cambiar el intervalo de tiempo en que es monitoreado todos los procesos que se están ejecutando, y también se puede cambiar el tiempo que debería llevar ejecutandose un proceso antes de poder ser categorizado como "proceso estancado".

Para poder cambiar estos parámetros debemos seguir lo siguiente:

  1. Logearse en la consola web del WebLogic Server.
  2. Clic en Environment.
  3. Clic en Servers.
  4. Clic en el ManagedServer en que está deployada nuestra aplicacion o nuestro WS.
  5. Clic en la pestaña Configuration.
  6. Clic en la sub pestaña "Tuning".
Estando ahi los parámetros que debemos modificar son:

  • Stuck Thread Max Time: El tiempo que un proceso deberia llevar ejecutandose (no ocioso) para poder ser categorizado como un "proceso estancado".
  • Stuck Thread Timer Interval: A cada cuanto tiempo se debería monitorear los procesos en ejecución para detectar "procesos estancados".

A continuación una imagen donde se puede ver estos parámetros:



Adicionalmente a estos parámetros existe uno más. Este puede ser encontrado de la siguiente manera:

  1. Logearse en la consola web del WebLogic Server.
  2. Clic en Environment
  3. Clic en Servers
  4. Clic en la pestaña "Configuration".
  5. Clic en la sub pestaña "Overload"
Ahi podemos encontrar el parámetro Stuck Thread Count el cual indica el número de "procesos estancados" que ese ManagedServer debería de tener antes de poder pasar a un estado de "FAILED".

Recuerde reiniciar el Server despues de realizar algun cambio en estos parámetros.





jueves, 13 de septiembre de 2012

Recuperación a Desastres para un ambiente SOA


Para tener un ambiente altamente disponible debemos considerar la construcción de un DRS (Disaster Recovery Site) el cual nos proporciona ventajas como, preservar cada una de las transacciones que se realizan en nuestro ambiente de producción, protegiéndonos ante desastres naturales, virus, fallas de hardware, errores de software, o errores de usuarios; facilidad al  realizar una recuperación desde el sitio de producción o desde el sitio de contingencia; facilidad para realizar mantenimientos de ambientes completos con ayuda de un switchover.

Idealmente el sitio de contingencia debe ser construido geográficamente muy lejos, otro país.

Para poder crear un DRS para un ambiente SOA, debemos considerar los siguientes puntos:

  • El punto de acceso de los clientes a nuestro ambiente SOA.
  • Estructura de Directorios idénticos entre el sitio de producción (SITE-1) y el sitio de continencia (SITE-2), puntos de montaje, tamaño de discos, permisos, hostname, misma versión de sistema operativo, misma version de software de Middleware, etc.
  • Replicación de Archivos binarios y archivos de configuración del Middleware.
  • Replicación de la data transaccional de nuestra base de datos.

El acceso a los clientes hacia nuestro ambiente SOA debe ser lo más transparente posible ante un desastre, es decir, inicialmente los clientes van a estar conectándose a nuestro ambiente de producción (SITE-1) pero cuando ocurra un desastre se deberán conectar a nuestro ambiente de contingencia (SITE-2), este cambio debe ser lo más rápido y transparente.

A continuación se muestra una imagen en la que se  ve como estaría la configuración en un inicio.
  • Los clientes se conectan al sitio de producción (SITE-1).
  • La base de datos está replicando la data al sitio de contingencia (SITE-2).
  • Los binarios y los archivos de configuración del Middleware se están replicando hacia el sitio de contingencia (SITE-2).

Es necesario dejar claro que la replicación de los binarios y archivos de configuración es a través de mirroring entre los discos que utiliza el Middleware, mientras que la replicación de la data de nuestra base de datos es por medio de los "archived logs" generados por la base de datos de producción, enviados a la base de datos de contingencia y luego aplicados a esta última. La replicación de la base de datos se hace por medio de "Data Guard" y la configuración es llamada "Physical Standby", para saber cómo crear una configuración de éste tipo pueden visitar el siguiente enlace:

http://docs.oracle.com/cd/B19306_01/server.102/b14239/create_ps.htm#i63561

Cuando ocurra un desastre (Failover) o se necesite realizar un mantenimiento planificado (Switchover), se deberá cortar la sincronización SITE-1->SITE-2 tanto de los binarios y archivos de configuración del middleware, como la sincronización de nuestra base de datos. Se deberá cortar la conexión de los usuarios hacia el sitio de producción (SITE-1) y redireccionarlos hacia el sitio de continencia (SITE-2) tal como se ve en la siguiente imagen:

Una vez el sitio de contingencia ya esté activado y los clientes estén debidamente redireccionados a éste nuevo sitio, la configuración quedaría de la siguiente manera para un Switchover (Mantenimiento planificado):

El SITE-2 será el ambiente de producción y el SITE-1 pasará a ser el ambiente de contingencia, la replicación seguirá realizándose, solamente que ahora en dirección inversa: desde el SITE-2->SITE-1. Por lo tanto todos los cambios que se estén realizando en el nuevo ambiente (SITE-2) no se estarían perdiendo, pues el SITE-1 se estaría sincronizando.

La siguiente imagen demuestra como quedaría la configuración:


Si se tratara de un Failover, se estaría asumiendo que el SITE-1 estaría completamente perdido. Los clientes estarían conectándose al SITE-2 y ya no habría replicación de binarios y archivos de configuración del Middleware, tampoco de la data de nuestra BD.

La configuración después de un failover quedaría como muestra la siguiente imagen:


Para más información sobre recuperación a desastres para un ambiente Middleware porfavor visite el siguiente enlace de oracle:

http://docs.oracle.com/cd/E23943_01/doc.1111/e15250/toc.htm


Oracle ACE Director Award - Deiby Gómez

Thanks #OracleACE Program for this awesome certificate recognizing the work I have done in the community for the last year. Looking forwa...