jueves, 25 de octubre de 2012

Topologías de Oracle Coherence Parte 3


En la parte 2 del presente artículo se conoció la topología de replicación, en la cual vimos que es muy buena topología a implementar cuando nuestro ambiente realiza un gran porcentaje de lecturas y pocas escrituras, también vimos que la Disponibilidad es tan buena como nodos en el cluster existan. En esta parte del articulo se verá la topología distribuida, en qué ambientes se debería implementar, sus ventajas y desventajas.

Topología Distribuida:

La  topología distribuida de Oracle Coherence almacena  cierta parte de los objetos en cada uno de los nodos del cluster, es decir, distribuye toda la información entre los nodos, de tal manera que cada nodo posea 1/n de la información, donde n es el número de nodos en el cluster.

Ya que cada nodo del cluster posee únicamente 1/n de la información, podríamos afirmar que a diferencia de la topología de replicación, se tendrá que incurrir en un costo adicional en un porcentaje de solicitudes de lectura ya que no necesariamente la información va a estar local sino que se deberá ir a un diferente nodo y leer la información desde ahí.

Entonces podríamos afirmar que (N-1)/N de las operaciones de lectura irán a un diferente nodo a leer la información. Por lo tanto el tráfico en la red aumentará debido la transferencia de objetos entre los nodos. Sin embargo, la localización del nodo que posee un determinado objeto se realiza por una clave hash lo cual hace muy rápida la localización de dicho nodo, es casi una comunicación de punto a punto. Cada uno de los nodos del cluster conocen todas las claves hash necesitadas de todos los objetos.

En la siguiente imagen se puede apreciar que la lectura del objeto A es realizada de manera local logrando una latencia nula (Característica de la topología de replicación), mientras que el objeto B es leído desde el nodo 2, el objeto C desde el nodo 3 y el objeto D desde el nodo 4, creando en cada una de esas solicitudes de lectura un aumento de uso de la red.


También es necesario indicar que los objetos en cada uno de los nodos del cluster dentro de una topología distribuida se mantienen serializados, lo cual implica un costo adicional en cada una de las lecturas, el costo de deserialización. En esta topología distribuida a diferencia de la topología de replicación los objetos siempre se mantienen serializados, esto se realiza con la intención de que sea más rápida la transferencia de un objeto hacia otro nodo del cluster cuando lo necesite.

De las lecturas podremos sacar las siguientes conclusiones:

  • (N-1)/N de las operaciones de lectura se realizará obteniendo la información desde un nodo remoto, donde N es el número de nodos.
  • Una lectura lleva implícito el costo de deserialización.
  • En 1/N de las operaciones de lectura serán realizadas de manera local obteniendo una latencia nula, donde N es el número de nodos.
  • La identificación del nodo que posee un determinado objeto es realizado por una clave hash.

Las operaciones de escritura se ven mejoradas en esta topología distribuida a comparación de la topología de replicación ya que cada escritura es realizada únicamente en el nodo que posee el objeto. Sin embargo, si cada nodo posee únicamente 1/N parte de la información, la disponibilidad sería muy mala, de tal manera que si un nodo falla toda la información que ése nodo almacena se verá perdida. Coherence en ésta topología distribuida introdujo el concepto de Backup para remediar este problema.

Un nodo puede tener al menos un backup de toda la información que posee y alojarlo en otro nodo del cluster, de tal manera que cuando ese nodo tenga una falla, Coherence detecté en qué nodo se encuentra su respectivo backup, lo restaure y la información esté disponible nuevamente, siendo todo este proceso de recuperación totalmente transparente al usuario. Un nodo puede tener M backups si asi se desea, y cada escritura no es declara finalizada hasta que haya sido escrita en cada uno de los backups que posea el nodo. Sin embargo, hay que tomar en cuenta que para cada escritura realizada a un nodo se hará (Q -1) escrirutas adicionales, donde Q es el número de backups que posee ese nodo. Entonces podríamos decir que en esta topología la Disponibilidad es inversamente proporcional al rendimiento de las operaciones de escrituras. En la vida real con esta topología se maneja únicamente un backup para cada nodo para mejorar la Disponibilidad, lo cual es la recomendación de oracle.

En la siguiente imagen podemos observar que cada nodo posee un solo backup, por lo tanto porq cada escritura de un objeto, se realizará una escritura adicional. El objeto A es escrito de manera local al nodo 1 y su backup es realizado al nodo 4. El objeto C es escrito de manera remota al nodo 3 y su backup es escrito al nodo 1. Igualmente la ubicación del nodo que posee el objeto es realizado por una clave hash.


En la siguiente imagen se puede apreciar que el nodo 2 sufre una falla. El nodo 2 almacena el objeto B. Cuando Coherence reconoce la falla del nodo 2 automáticamente localiza el nodo en el que se encuentra su backup (nodo 3) y lo restaura, verifica qué backups de cuales nodos eran alojados en el nodo 2 (backup del objeto D) y vuelve a crear un backup en otro nodo (nodo 4).


En esta topología  se pueden crear nodos vacios, es decir que no almacenan objetos, sino que sirven únicamente como un punto de acceso a los objetos almacenados en los demás modos. A esta característica se le llama “Local Storage”.

En la siguiente imagen se puede ver que el nodo 1 y 2 no poseen objetos pues tiene la característica “LocalStorage=false”. Mientras que los nodos 3 y 4 almacenan toda la información.



CONCLUSION:
  • La mayoría de las lecturas se realizan a nodos remotos. 1/N de manera local con latencia nula, (N-1)/N de manera remota. Donde N es el numero de nodos.
  • El rendimiento de las escrituras se ve aumentado pues solo se realiza en el nodo que posee el objeto y en su respectivo nodo de backup, si este poseyera.
  • La Disponibilidad es inversamente proporcional al rendimiento de las escrituras.
  • Se pueden crear nodos vacios en diferentes versiones de JDK.
  • La localización del nodo para leer o escribir un objeto se realiza por claves  hash.
  • La recuperación ante fallas es transparente al usuario.

Revisado Por: Ing. Iván Garcia.

Articulo Completo listo para descargarse en el siguiente link: https://www.dropbox.com/s/7dv1aom6u1lzqan/Topologias%20de%20Coherence.pdf


martes, 16 de octubre de 2012

Topologías de Oracle Coherence Parte 2


En la parte 1 de este artículo de topologías vimos la importancia de tener altamente disponible nuestras aplicaciones, se realizaron algunas formulas para demostrar qué tan disponible es nuestro sistema. En esta segunda parte se tratará las ventajas y desventajas de una de las topologías básicas de Oracle Coherence: Topología de Replicación.

Topología de Replicación:

La topología de replicación almacena cada objeto que se envía a un determinado servidor de Coherence, en todos los demás servidores, de tal manera que cada cliente pueda acceder cualquier objeto de manera local, logrando con esto una latencia completamente nula.

En la siguiente imagen se puede observar que cada uno de los objetos (A,B,C,D) están replicados en cada uno de los servidores de Coherence. Y que cada lectura (get) está siendo realizada de manera local:


La latencia nula para un determinado objeto se logra después de su segunda lectura. Lo que sucede es que cuando un objeto es enviado al Cache de Coherence, se  “serializa” y luego se manda a escribir a los N servidores de Coherence que existan en el cluster. Cada uno de los servidores recibe el objeto serializado y así lo  mantiene hasta que reciba una primer solicitud de lectura, entonces deserializa el objeto y lo mantiene así para las siguientes lecturas, es ahí cuando se alcanza la latencia nula. Entonces podríamos decir que la primera lectura de un objeto implica un costo pequeño: El costo de deserializar el objeto.

Las escrituras en una topología de replicación no son tan eficientes como las lecturas, pues cada escritura implica N-1 escrituras adicionales, donde N es el número de servidores Coherence que se tienen en el cluster. Estas escrituras son necesarias realizarlas para que la información esté totalmente replicada, Coherence no  termina una escritura completamente hasta que no haya sido escrita en los demás servidores.

En la siguiente imagen se ve que cuando se escribe el objeto A en el servidor 1, éste se replica a los 3 servidores restantes:


De esto podemos concluir que el rendimiento de las escrituras decaerá conforme se aumente el número de servidores Coherence que se tenga en el cluster.

Sin embargo, el estar manteniendo replicados todos los objetos en todos los servidores nos favorece en cuanto a Disponibilidad. La disponibilidad es directamente proporcional al número de servidores que se incluyan en el cluster. Cuando un servidor falla, únicamente el servidor que escribe un determinado objeto replicará el objeto a todos los demás servidores menos el que no está disponible. Cuando el servidor que falló vuelve a estar disponible, los servidores lo vuelven a tomar en cuenta para replicar los objetos.

En la siguiente imagen el servidor 2 ha dejado de estar disponible. Por lo tanto las escrituras del objeto A solo se realizan a los servidores 3 y 4.


En esta topología también se  tiene la limitante de la suma del tamaño de todos los objetos dentro de un servidor no debe sobrepasar el tamaño del servidor más pequeño, esto es porque todos los datos deben ser mantenidos en todos los servidores. Por ejemplo, si se tienen los siguientes tamaños para nuestros 4 servidores:

JVM1              =                     3GB.
JVM2              =                     3GB.
JVM3              =                     1GB.
JVM4              =                     3GB.

Cada uno de los servidores solo podrá soportar una cantidad de 1GB en objetos, aunque los servidores 1,2 Y 4 tengan 3GB. Por lo tanto, si lo que nos importa es la disponibilidad de nuestros objetos y el tamaño total de los objetos no excede 1GB nuestra configuración estaría bien. Sin embargo, si se desea tener un total de objetos que exceda 1GB podríamos sacrificar un poco de Disponibilidad y extraer el tercer servidor, dejando únicamente 3 servidores (JVM1, JVM2 y JVM4).

Conclusión:

  • Las lecturas son locales, una latencia nula.
  • Cada escritura requiere N-1 escrituras adicionales. Donde N es el número de servidores en nuestro cluster.
  • La Disponibilidad es tan buena como número de servidores se tenga en el cluster.
  • El tamaño del Cache se limita al tamaño del servidor más pequeño.
  • En esta topologia la Disponibilidad es inversamente proporcional al rendimiento de las lecturas.


Articulo Completo listo para descargarse en el siguiente link: https://www.dropbox.com/s/7dv1aom6u1lzqan/Topologias%20de%20Coherence.pdf

viernes, 12 de octubre de 2012

Taller SQL Tuning en USAC


En Septiembre del 2011 fue la primera conferencia que realicé sobre tecnología Oracle, fue dirigida a todos los estudiantes de Ciencias y Sistemas de la Universidad de San Carlos de Guatemala, el tema de la conferencia fue SQL Tunning, en el cual se trataron algunos de los siguientes temas:

  • Afinamiento de Sentencias SQL
  • Arquitectura de una base de Datos Oracle
  • Proceso de Commit
  • Optimizador Basado en Costos
  • Optimizador Basado en Reglas
  • Indices basados en funciones
  • Indices binarios
  • Indices de arboles
  • Indices Invisibles
  • Proceso de Parseo de una sentencia
  • SQL tuning Advisor 
  • Automatic Workload Repository
  • ADDM 


El objetivo es dar a conocer cómo funciona una base de datos oracle, la forma en que procesa cada sentencia DDL o DML y de qué manera podemos afinarla para que así se ejecute más eficientemente.


Esta conferencia fue impartida en el salón de videoconferencias de la Escuela de Ciencias y Sistemas en el horario de 7:00am a 12:30pm.

Para esta fecha ya contaba con el Oracle Certified Professional (OCP) en Oracle Database 11g, traté de transmitir todos los conocimientos que pude en tan poco tiempo, ya que un curso de SQL Tuning convencional dura 1 semana 4 horas dirias. Sentí poco tiempo para realizar éste taller, sin embargo, comprobé que los alumnos habían aprendido muy bien los conceptos que se dieron.

Luego de esto di un taller de construcción de una Physical Standby con Oracle Enterprise Edition, la cual fue dirigida al mismo grupo de estudiantes, esto fue a finales del 2011.

Esta conferencia solo fue el inicio de todo lo que me queda por compartir dentro de mi experiencia con tecnología Oracle.



Topologías de Oracle Coherence Parte 1


Introducción a Oracle Coherence:

Oracle Coherence es un producto dentro de Fusion Middleware que permite crear redes de datos en memoria para agilizar las lecturas/escrituras de nuestros objetos, esto sin descuidar la confiabilidad, la accesibilidad y la seguridad de los datos. Coherence también es una solución escalable, la capacidad de memoria puede llegar a ser tan grande como se requiera, solo es necesario agregar más nodos a la configuración.

¿La Disponibilidad es importante?

El tema de la disponibilidad se subestima en la vida real, esto es un error. La disponibilidad de nuestros datos debe ser un tema de mucha importancia, podemos establecer la disponibilidad como un “todo”, a esto le llamaremos: La disponibilidad del Sistema.

La disponibilidad del sistema puede ser definido como el producto de la disponibilidad de cada componente que está dentro de nuestro sistema.

DS=DC1*DC2*DC3*….*DCn

Donde:            DS=Probabilidad de Disponibilidad del Sistema
                        DC1=Probabilidad de Disponibilidad del Componente 1
                        DCn=Probabilidad de Disponibilidad del Componente N

Por ejemplo, si tuviéramos los siguientes componentes:

  • Servidor Web
  • Servidor de aplicaciones
  • Servidor de base de datos

Y cada uno de los anteriores componentes tuviera una disponibilidad del 99%, entonces se espera que la Disponibilidad del Sistema (DS) sea la siguiente:

DS=0.99*0.99*0.99=0.97=97%

Si usted considera que su empresa puede tolerar un sistema con disponibilidad del 97%, está bien. Sin embargo, debe tomar en cuenta que el 97% de Disponibilidad es 11 días al año. ¿Acepta su empresa 11 días al año sin servicio?

Existen dos maneras de mejorar la disponibilidad de nuestro sistema:

1.    Desacoplar componentes: Para tener componentes aislados dentro de nuestro sistema, de tal manera que si un componente falla no afecte a los demás y en consecuencia… no afecte el sistema.

Coherence logra tener componentes desacoplados introduciendo el concepto de operaciones asincrónicas. Esto permite que aunque la capa de datos este inaccesible coherence seguirá aceptando operaciones de lectura/escritura. Las escrituras las irá encolando de tal manera que cuando la capa de datos este nuevamente disponible se realicen las operaciones sobre ella. Esto trae como beneficio que una falla de Base de datos sea totalmente transparente al usuario final.

Sin embargo, hay que tomar en cuenta los siguientes puntos:

·        Muchas aplicaciones utilizando una misma base de datos puede provocar conflictos. Al tener las escrituras de manera asíncronas puede haber conflictos entre las escrituras de las demás aplicaciones. 

·        Cada vez que un usuario necesite consultar datos “viejos”, se debe realizar el refrescado de estos elementos de manera síncrona, lo cual agrega un pequeño costo a la lectura.

·       Si toda la configuración de coherence se cae, las operaciones asíncronas encoladas se perderán pues todo está en memoria. Entiéndase “toda” la configuración como todas las maquinas virtuales de java en todos los servidores involucrados en la configuración de coherence, incluido sus backups. Esto es poco probable, sin embargo, es necesario dejarlo claro.

2.       Redundancia en los componentes: Si usted quiere alcanzar una alta disponibilidad de manera síncrona, la única alternativa es aumentar la redundancia de los componentes.

Sin embargo, la redundancia no es suficiente para lograr una disponibilidad del 100%. Para comprobar esto calculemos la probabilidad de falla de todo un conjunto de componentes redundantes:

FCC=FC1*FC2*…*FCN.

Donde      FCC=Probabilidad de Falla del Conjunto de Componentes redundantes.
                 FC1=Probabilidad de Falla del Componente 1.
                 FCN=Probabilidad de Falla del Componente N.

Haciendo uso del dato “Disponibilidad de un componente” podemos calcular su probabilidad de Falla:

FC=1-DC

Donde      FC=Probabilidad de Falla de un Componente.
                 DC=Probabilidad de Disponibilidad de un Componente.

Por ejemplo, nuestro componente Servidor de Aplicaciones tiene una disponibilidad del 99% entonces su Probabilidad de Falla es:

FC=1-0.99=0.01

Si a este componente le agregamos un Servidor de Aplicaciones de tal manera que nuestro componente ahora sea redundante, tendríamos la siguiente probabilidad de Disponibilidad:

DC=1-(0.01*0.01)=1-0.0001=0.9999=99.99%

Si a cada uno de los 2 componentes restantes que tenemos en nuestro Sistema (Servidor Web y Servidor de Bases de Datos) le agregamos un servidor de tal manera que sean ahora redundantes, la disponibilidad de cada componente quedaría de la siguiente manera:

·         Servidor Web                        =          99.99%
·         Servidor de Aplicaciones     =          99.99%
·         Servidor de Base de Datos  =          99.99%

Entonces la disponibilidad de todo nuestro Sistema quedaría de la siguiente manera:

DS=0.9999*0.9999*0.9999=0.9997=99.97%

Y la probabilidad de falla de todo nuestro Sistema quedaría así:

FS=1-0.9997=0.0003=0.03%

CONCLUSION:

·         Sin redundancia, nuestro sistema tendría 11 días sin servicio al año.
·         Con redundancia, (un componente más) nuestro sistema tiene solamente 2.6 horas al año.

Reformulo mi pregunta anterior: ¿Acepta su empresa 2.6 horas al año sin servicio?

2.6 horas al año sin servido es un dato relativamente aceptable, sin embargo ¡no es 100% de Disponibilidad!

Por intuición vemos que el 100% de Disponibilidad lo vamos alcanzando proporcionalmente a la redundancia que se le dé a cada componente, pero ahí ya tendríamos que involucrar el factor costo. ¿Existe alguna alternativa que nos elimine la necesidad de compra de N componente redundantes? ¡Sí, Oracle Coherence!
           
Arquitectura de Oracle Coherence:

Oracle Coherece trabaja con una arquitectura de “Cluster”.

Esta definición ya es muy conocida, sin embargo, a continuación expongo la definición formal:

Cluster: Es un conjunto de componentes interconectados entre sí trabajando como uno solo.

Un cluster de Oracle Coherence está formado por varios “servidores coherence” que no son más que instancias de maquinas virtuales java las cuales trabajan interconectadas entre sí para formar un solo componente: El cache de Coherence.

Cada una de estos servidores puede alojar datos de varias maneras las cuales dependen de los siguientes principales factores:

  • ¿Sus aplicaciones realizan muchas lecturas?
  • ¿Sus aplicaciones realizan muchas escrituras?
  • ¿Sus aplicaciones toleran leer datos que no están a la fecha?
  • ¿Sus aplicaciones necesitan tener los datos altamente seguros?
  • ¿Es muy grande la cantidad de datos que manejan sus aplicaciones?
  • ¿Utiliza SUN JDK u Oracle Jrockit?

Dependiendo de las respuestas que se les dé a cada una de las anteriores preguntas se puede elegir entre  las siguientes topologías  básicas de Coherence:

NOTA: las 3 topologías presentadas a continuación no son las únicas de las cuales dispone Oracle Coherence, las topologías son muy personalizables.
  1. Topología de Replicación
  2. Topología Particionada
  3. Near-Cache
En la siguiente parte del articulo “Topologías de Coherence Parte 2” estaré tratando la topología de Replicación, ventajas y desventajas.

Parte 2: Topologias de Coherence Parte 2.

Articulo Completo listo para descargarse en el siguiente link: https://www.dropbox.com/s/7dv1aom6u1lzqan/Topologias%20de%20Coherence.pdf

lunes, 8 de octubre de 2012

Anécdota Oracle Coherence


Esta anécdota es entre el equipo de Soporte de Oracle Coherence y un cliente que ha utilizado  Oracle Coherence por mucho tiempo:

"This particular customer has been using Coherence for almost 5 years. When a bug was discovered that effects the particular release they were using, the support team sent the patch and the installation instructions to the customer. They received a polite reply:

You have got to be kidding me!? We haven't had a second of downtime in the last 5 years. We are not touching a thing!!"


*Extraido del libro Oracle Coherence 3.5 de Aleksandar Seovic, 2010.

jueves, 4 de octubre de 2012

Conferencia SOA en COECYS 2012


El miércoles 26 de Septiembre tuve la oportunidad de presentarme por primera vez como conferencista en el Congreso de Estudiantes de Ciencias y Sistemas (COECYS) organizado por estudiantes de la Universidad de San Carlos de Guatemala (USAC). Durante mi época estudiantil había asistido a este congreso como espectador, sin embargo, esta vez fue diferente, me presentaba como un conferencista más, tratando de compartir los conocimientos que ha adquirido. El tema del cual hablé fue “Agilidad Empresarial con SOA” y la agenda fue la siguiente:

  • ¿Quién es Oracle? ¿Quién es Datum?
  • ¿Cómo crear una organización ágil?
  • ¿Qué es SOA?
  • Adoptando SOA en el negocio
  • Construyendo un proceso SOA
  • Herramientas SOA de Oracle
  • ¿Cómo se implementa SOA?
  • Soluciones Comunes Habilitadas por SOA



Se habló de Oracle como líder mundial en gestión de la información y de Datum como Partner de Oracle y líder en consultoría/soporte en Guatemala, después de esa pequeña introducción se pasó a hablar más formalmente sobre el tema de agilidad y  SOA.

El departamento de IT de una organización padece de muchos problemas de agilidad y esto tiene como consecuencia que las personas de negocio se vean retrasadas o retenidas por IT, esto provoca un fracaso total cuando la organización debe competir ante otras organizaciones en el mercado.





SOA proporciona esa agilidad que la organización necesita basándose estrictamente en la alineación entre IT y los procesos de Negocio. IT no debe funcionar como un departamento totalmente independiente al Negocio, sino deben trabajan en conjunto, como una sola pieza.

Luego de hablar sobre todas las características de SOA, sus fundamentos, sus beneficios para con IT y con el Negocio, de qué manera se efectúa el ROI y de hacer mucho énfasis en que la Gobernanza ocupa un papel muy importancia en el éxito de SOA, también se habló de The Open Group Architecture Framework (TOGAF) como metodología para implementación de una arquitectura empresarial orientada a servicios, cada una de sus fases y su respectiva explicación.



Y finalmente se habló sobre la tecnología líder mundialmente para soportar una arquitectura empresarial orientada a servicios: ORACLE.
Oracle posee varias herramientas las cuales facilitan llevar a la realizar el concepto SOA. Entre estas herramientas se encuentran:

  • Oracle Service Bus: Proporciona ruteo, monitoreo de la salud de los servicios y servidores, facilida la integración entre ambiente heterogeneos y la virtualización de los servicios.

  • Oracle JDeveloper con plugin de SOA: Herramienta para la creación y diseño de los servicios web, sean compuestos o no.

  • Oracle BPEL process Manager: Motor que se ejecuta dentro del servidor WebLogic cuyo propocito es ejecutar los servicios BPEL creados con JDeveloper.

  • Oracle Business Activity Monitoring (BAM): Herramienta para monitorear el comportamiento de la organización en tiempo real. BAM es una herramienta basada en eventos. Proporciona varios reportes prediseñados listos para ser usados y tambien posee facilidad y rapidez para crear nuevos.

  • Oracle Enterprise Repository: Repositorio de Assets y su respectiva metadata involucrada en el proyecto SOA.

  • Oracle Service Registry: Este concepto es parecido al de "páginas amarillas" es una lista muy bien clasificada de los servicios web que posee la organización para ser descubiertos fácilmente y ser reutilizados rápidamente en el diseño y creación de otros servicios web.

  • Oracle Database: La base de datos que almacenará toda la metadata de las herrameintas del Middleware.

  • Oracle WebLogic Server: Servidor de aplicaciones en el cual se desplegarán todas las aplicaciones, servicios web, servicios web compuestos, etc.




Finalizada la conferencia se dio unos minutos para resolver dudas de los espectadores.

Presentarme como conferencista por primera vez en  COECYS 2012 fue una experiencia muy satisfactoria, espero tener la oportunidad de participar nuevamente en este congreso en los años posteriores  y tener más conocimiento para compartir.

A continuación unas imagenes de la maravillosa experiencia de dar a conocer SOA en COECYS:


En la imagen anterior se habló sobre la facilidad que proporciona SOA al incorporar una nueva funcionalidad dentro de un proceso de negocio, sin SOA este tipo de cambios tendria como concecuencia realizar modificaciones tipo efecto dominó en todas las demás aplicaciones dependientes.



En la imagen anterior se habló sobre las herramientas que Oracle posee para soportar una Arquitectura Orientada a Servicios.

COECYS 2012 fue realizado en el centro TICs del Instituto Técnico de Capacitación y Productividad (INTECAP), en la ciudad de Guatemala, durante la semana del 24 al 28 de Septiembre.



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.




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...