h1

El Oracle RAC: Qué es y cómo funciona

11/28/2007

Wizdoc [Icon By Buuf]  Tips & Tricks

EN Versión en Inglés / English Version

Una de las nuevas características incluidas en el software de Oracle es la creación de clusters de base de datos (llamado Real Application Cluster – 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 (Transparent Application Failover – 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:

Diag conceptual Oracle RAC
Fig.1 Diagrama conceptual del
funcionamiento de un Oracle RAC
(configuración en failover)

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 Componentes Oracle RAC
Fig.2 Diagrama de componentes Oracle RAC
(dar click en imagen para ver versión más grande)

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.

El problema radica en que de acuerdo al mismo Oracle (ver aquí), 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 Thin Client 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 Stored Procedures (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 (ver aquí).

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:

Diag conceptual Oracle RAC con balanceo
Fig.3 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:

  • 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 al heartbeat de los nodos) y puede configurarse de la siguiente manera:
    • 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.
    • 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.
    • La opción con Sun Cluster. De acuerdo a Sun Microsystems, el Sun Cluster permite realizar un redireccionamiento sin pérdida y sin necesidad de configuraciones adicionales a la plataforma: el Sun Cluster 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. (Modificado [12/12/2007]: Ya tenemos una implementación de Sun Cluster con Oracle RAC 10g R2: ver aqui el concepto y aqui cómo configurarlo).

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.

Actualización (12/12/2007)

La última versión del Oracle RAC (para Oracle 10g release 2) incluye un cambio mayor en cuanto a la tecnología implementada por la solución. Así entonces, ya se tienen dos características que hacían bastante falta:

  • Ya existe, como parte de la arquitectura del Oracle RAC, el balanceo de carga entre los nodos que componen el cluster. Dicho balanceo puede hacerse ya sea mediante round robin, o consumo de recursos (CPU y memoria).
  • La configuración del balanceo puede hacerse desde el cliente o el servidor:
    • Los clientes delgados (thin clients), como es el caso de JDBC, pueden configurarse para hacer uso del balanceo de cargas, cambiando la URL de conexión de tal forma que puedan conectarse a cualquiera de los N nodos que conforman el cluster:
      URL convencional

      "jdbc:oracle:thin:@nodo_unico:1521", "username", "password"

      URL para un Oracle RAC (nodos nodo_1 y nodo_2)

      "jdbc:oracle:thin:@ (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = nodo_1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = nodo_2)(PORT =1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = miservicio) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))))", "username", "password"

      Como puede apreciarse, es prácticamente el contenido de un archivo tnsnames.ora lo que se está definiendo en el URL de conexión del driver, y no es necesario instalar componentes adicionales.

    • Tanto los thick clients como los OCI clients pueden configurar el balanceo desde el tnsnames.ora como se venía haciendo anteriormente.

Como nota adicional, el balanceo de cargas se realiza solito sin ningún problema, siempre y cuando lo único que exista en los nodos del Oracle RAC sea la base de datos en sí; es decir el RAC no funciona correctamente si en los filesystems de dichos nodos existe algo más, como archivos de logueo o información adicional que se desea almacenar y sincronizar en dichos nodos. En ese caso, sí debe utilizarse la alternativa de un componente de balanceo adicional.

5 comentarios

  1. excelente informacion


  2. Me parece bien con un balanceador fisico, hay varios en el mercado
    solo para ajustar iguales puntos de vista o recomendacion, cual es la marca de un balancedor que les a funcionado bien , base a experiencias que an tenido para sistemas de base de datos en especial en oracle.


    • No tengo el modelo específico, pero en aplicaciones de alta criticidad hemos usado los BIG-IP Traffic Managers de F5 (http://www.f5.com/products/big-ip/). En términos generales, esos balanceadores son los Ferraris del mundo del balanceo, por lo que son muy buenos pero también muy muy caros (US$40,000 c/u). Otros balanceadores que hemos usado son los M440 de Barracuda, aunque esos son para aplicaciones menos críticas. En cuanto a los switches para conectar toda la plataforma, normalmente usamos CISCO.


  3. Estimados,
    Gracias por el detalle de que es un RAC , y en base a lo mismo, me podrían ayudar a aclarar que función cumple el interconec dentro del RAC con una IP Privada.
    De acuerdo a lo que he podido averiguar hasta el momento esta IP privada (interconec) es lo que permite la comunicación directa entre los nodos, de manera de mantener la comunicación directa entre ellos. El problema que no estoy claro con este concepto y me es necesario aclararlo más al detalle.


    • En el manual de usuario viene todo (http://docs.oracle.com/cd/B28359_01/rac.111/b28255/oifcfg.htm), pero a grandes razgos: si no usas interconnect, puedes tener acceso a recursos en red fuera del cluster RAC; en caso de usarlo, cada nodo sólo podrá tener visibilidad a los otros nodos del arreglo.

      El concepto parte de que sólo tienes un arreglo de discos donde se almacenarán las tablas y ultimadamente, los archivos (.dbf) de la base de datos. Cada nodo tiene corriendo un motor de base de datos (oracle.exe) para que en caso de que uno se caiga, otro nodo responda la petición. La comunicación entre ellos es para que si un nodo se cae mientras ocurre una “transacción al aire”, otro pueda tomar esa transacción sin que se pierda o sea necesario que el cliente la reenvíe.



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: