Oracle rac
- 1. ORACLE RAC Oracle Real ApplicationClusters (RAC) es una opción software para el SGBD Oracle producida por la Corporación Oracle. Introducción Oracle RAC permite que múltiples computadoras ejecuten el software de SGBD de Oracle simultáneamente mientras acceden a una base de datos individual. Esto se llama una base de datos en grupo (cluster o clustered). En una base de datos de Oracle no-RAC, una base de datos individual es accedida por una instancia individual. La base de datos se considera la colección de ficheros de datos, ficheros de control, y ficheros redo log localizados en disco. La instancia se considera la colección de procesos del sistema operativo y memoria relacionada de Oracle que están ejecutándose en el computador. En Oracle RAC, dos o más computadoras (cada una con una instancia) acceden concurrentemente a una base de datos individual. Esto permite que una aplicación o usuario se conecte a alguno de los computadores y tenga acceso a los mismos datos. ORACLE RAC Real Application Clusters o RAC es un software que permite utilizar un cluster de servidores ejecutando múltiples instancias sobre una misma base de datos. Los archivos de base de datos quedan almacenados en discos, física o lógicamente conectados a cada nodo, de modo tal que todas las instancias activas pueden leerlos o escribirlos. El software de RAC maneja el acceso a los datos, de modo tal que los cambios en los datos son coordinados entre las instancias y cada instancia ve imágenes consistentes de la base. El interconnect del cluster permite que las instancias se pasen entre ellas información de coordinación e imágenes de los datos. Esta arquitectura permite que los usuarios y aplicaciones se beneficien de la potencia de procesamiento de múltiples máquinas. La arquitectura RAC también ofrece redundancia; por ejemplo, en el caso de que un nodo quede inutilizado, la aplicación continuará accediendo a los datos vía el resto de las instancias disponibles. Un cluster es un grupo de servidores independientes que cooperan comportándose como si fueran un solo sistema. En entornos RAC, la sincronización “internodo” es crítica para mantener una adecuada coordinación entre los distintos procesos en diferentes nodos. RAC utiliza lo que se conoce como Global Resource Directory (GRD)para registrar información sobre cómo los recursos son utilizados dentro de una base de datos en cluster. Global Cache Services (GCS) y Global Enqueue Services (GES) administran la información del GRD. Acerca de la reconfiguración dinámica, RAC utiliza el Global Resource Directory (GRD) para registrar información sobre cómo son utilizados los recursos dentro de una base de datos en cluster. Cada instancia mantiene una porción del GRD en su propia SGA. Cuando una instancia abandona el cluster, es necesario redistribuir la porción del GRD que administraba entre los nodos sobrevivientes. Algo análogo ocurre cuando una nueva instancia se suma al cluster, las porciones del GRD de cada instancia necesitan redistribuirse para crear la nueva porción de GRD correspondiente a la instancia que se suma. En vez de remasterizar todos los recursos a través de todos los nodos, RAC utiliza un algoritmo denominado lazy remastering que remasteriza una cantidad mínima de recursos durante una reconfiguración. La memoria específica para la administración del RAC se aloja mayoritariamente en la Shared pool. Como los bloques pueden ser cacheados a través de las instancias es necesario contar también con buffer caches más grandes. Al migrar una base de datos Oracle single instance a RAC, si se pretende que cada nodo mantenga su
- 2. rendimiento con los mismos niveles de carga que en single instance, habrá que asignar un 10% más de memoria a la buffer cache y un 15% más a la shared pool. Estos valores son heurísticos, basados en experiencias de RAC a través del tiempo. Sin embargo, hay que considerar que generalmente los requerimientos por instancia se ven reducidos cuando la misma cantidad de usuarios y carga de trabajo es distribuido en múltiples nodos. Una de las nuevas características incluidas en el software de Oracle es la creación de clusters de base de datos (llamado Real ApplicationCluster – RAC). De acuerdo a Oracle, esta funcionalidad permite disponibilidad 24/7, desempeño y escalabilidad. Adicionalmente a esto se incluye la definición de failover transparente (TransparentApplicationFailover – TAF) que utilizan las aplicaciones para sincronizar sus peticiones con el clúster de Oracle sin que éstas se enteren que alguno de los nodos del clúster se ha desconectado. ¿Cómo funciona? Conceptualmente, la arquitectura del Oracle RAC se muestra en la siguiente figura: Diagrama conceptual del funcionamiento de un Oracle RAC (configuración en failover)
- 3. Las peticiones a la base de datos son generadas por la aplicación (por ejemplo, desde un pool de conexiones configurado en un Application Server), y el Oracle RAC en su conjunto es el encargado de direccionar las peticiones al servidor que esté en funcionamiento. Nótese que en esta configuración no existe un balanceo de cargas, por lo que la configuración mostrada es exclusivamente en failover (es decir, todas las peticiones llegarán al Nodo 1, y sólo en caso de que éste deje de funcionar, las peticiones se redireccionarán al Nodo 2). Ahora bien, es necesario contemplar cómo funciona realmente el Oracle RAC. Esto se puede ver mejor si utilizamos un diagrama de componentes de software: Diagrama de componentes Oracle RAC En realidad, el cliente o servicio de Oracle está configurado para tener como conexión primaria el Nodo 1; si no es posible ejecutar la petición enviada a dicho servidor, el servicio se encarga de realizar un redireccionamiento de la misma hacia el servidor de respaldo (en este caso el Nodo 2). Adicionalmente, es necesario mencionar que lo que está corriendo en los Nodos 1 y 2 es el listener del motor de base de datos, no la base en sí: la información de la base (los archivos que componen la DB) se encuentra en un arreglo de discos con configuración en mirror para proveer redundancia y por lo tanto, alta disponibilidad. En resumen: Oracle RAC es un componente de software que permite la creación de múltiples instancias del motor de base de datos de forma independiente, compartiendo un mismo almacenamiento. Sin embargo, RAC posee dos limitaciones muy importantes que es necesario considerar: 1. No existe un balanceo de carga entre los nodos de base de datos que componen el Oracle RAC: ésta configuración por default sólo permite el failover de las peticiones realizadas sobre la base de datos y si el diseño de la arquitectura requiere la optimización de recursos, prácticamente se está desperdiciando la mitad del poder de procesamiento de la capa del back-end. 2. Dicho failover no es tan transparente como dice Oracle (ver adelante). Utilizando TAF Una vez que un nodo del Oracle RAC se desconecta (ya sea por falla de hardware, red o sobredemanda de recursos), todas las transacciones deben ser redireccionadas automáticamente al nodo de respaldo. El punto de dicho esquema consiste en no perder las transacciones que se encontraban en vuelo en el momento de la desconexión.
- 4. El problema radica en que de acuerdo al mismo Oracle, para hacer uso la funcionalidad de TAF es necesario utilizar el API del Oracle Call Interface – OCI. En pocas palabras, es necesario instalar un cliente de Oracle en el servidor de aplicaciones, y el simple uso de un driver de conexión a la base de datos (por ejemplo, el ThinClient de Java) no es suficiente. Adicionalmente, cuando menos para la versión 10g de Oracle, TAF sólo realiza failover transparente para queries de tipo SELECT. Todos los demás tipos de operaciones marcarán un error automáticamente: Queries transaccionales o de manipulación de datos: INSERT, UPDATE y DELETE. Operaciones de manejo de sesión: ALTER SESSION y SQL*Plus. Objetos temporales (aquellos que utilizan el espacio de trabajo TEMP). Estados obtenidos durante la ejecución de StoredProcedures (PL/SQL). Así entonces, llegamos a la siguiente conclusión: Oracle RAC no garantiza por sí mismo un failover transparente (sólo garantiza disponibilidad de la base de datos). El failover es implementado por el OCI en el cliente de Oracle, con ciertas restricciones. Esto limita la viabilidad de Oracle RAC considerando el costo-beneficio pues éste se cotiza de forma separada al motor de la base de datos. Mejorando Oracle RAC Sin embargo, no todo está perdido. Ambos problemas (balanceo de cargas y failover transparente) pueden ser resueltos mediante un clúster con balanceo de carga por hardware o software. La escalabilidad de dicha solución depende más bien del presupuesto con el que se cuenta, pero soporta la decisión de implementar un Oracle RAC para alta disponibilidad de la base de datos. El esquema conceptual se muestra en la siguiente figura: Oracle RAC con balanceo de cargas El encargado de realizar la distribución de carga es el balanceador. Éste puede ser un componente de software (por ejemplo, un Web Server con balanceo round-robin como Apache) o uno de hardware (como un Switch F5) de tal forma que:
- 5. No exista dependencia hacia un Oracle Client instalado en el servidor de aplicaciones. Esto es especialmente importante cuando no se puede instalar este componente o es necesario incrementar la portabilidad de la plataforma. Se optimizan los recursos al distribuir la carga entre los dos o más servidores que componen la solución. El componente de balanceo es el encargado de detectar las caídas de los nodos de la capa de back-end. El cómo se detectan dichas caídas depende del componente utilizado (por ejemplo, mediante pings alheartbeat de los nodos) y puede configurarse de la siguiente manera: o Redireccionamiento al primer error. Cuando ocurre un error de desconexión, el componente redirecciona las demás peticiones que lleguen hacia los demás nodos de la plataforma, hasta que vuelva a recuperar el heartbeat del nodo afectado. El detalle es que las peticiones en vuelo regresan un error. Esto se tendría que resolver con un mecanismo de reintento ya sea en la aplicación misma o en el contenedor (en caso de que el Servidor de Aplicaciones y el driver de base de datos soporten dicha funcionalidad). Para este caso particular, puede utilizarse el Oracle Cache Fusion, que básicamente es un componente que permite sincronizar bloques de datos entre los nodos del clúster, pero con esta solución perdemos el balanceo de cargas. o Redireccionamiento sin pérdida. Este se logra utilizando una combinación del cliente OCI, el balanceador de carga y una configuración especial del TAF donde se especifica que las peticiones deben lanzarse a ambos nodos de la plataforma y el que llega primero es resuelto (descartando el segundo). Esto en efecto permite un failover completamente transparente sin necesidad de modificaciones en la aplicación, pero tiene un inconveniente: duplica el tráfico transaccional entre las capas de middle y back end. o La opción con SunCluster. De acuerdo a Sun Microsystems, el SunCluster permite realizar un redireccionamiento sin pérdida y sin necesidad de configuraciones adicionales a la plataforma: el SunCluster y los agentes instalados en cada uno de los nodos se dedican a sincronizar las peticiones evitando la pérdida de transacciones en caso de un error. Esto es el equivalente al failover de una aplicación web donde las sesiones de usuario se migran entre los nodos activos del clúster en caso de que uno falle. Conclusiones Oracle RAC es un componente que nos permite agregar alta disponibilidad a nuestro back-end al ofrecer múltiples instancias de una base de datos (con una sola unidad de almacenamiento), permitiendo con la ayuda de un componente de balanceo, alta escalabilidad y disponibilidad de los servicios ofrecidos por la base de datos.