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

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.

Parte 3: Topologias de Coherence Parte 3

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

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

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.

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.