Cómo balancear sesiones en RAC

Uno de los puntos clave para llevar a cabo una implementación exitosa de una aplicación conectada a una base de datos Oracle en Real Application Cluster es entender y configurar el balanceo de las sesiones y la alta disponibilidad que el ambiente RAC nos ofrece.

Este post esta dedicado a entender el balanceo de sesiones. La configuración de Alta Disponibilidad será tratada en otro momento.

Comunmente, pueden existir problemas debidos a las diferentes aplicaciones existentes y a su naturaleza de conexión con la base de datos. Entre los problemas más comunes que me ha tocado observar se encuentran los siguientes:

• Las aplicaciones no pueden conectarse al ambiente en modo RAC. Únicamente se pueden conectar a uno de los nodos.
• Uno de los nodos es quien procesa la mayor parte de la carga mientras que el/los otros(s) nodo(s) prácticamente no realizan ningún trabajo.

A continuación explicaré de que forma Oracle realiza el balanceo de carga en un entorno Real Application Clusters, y para ello partiré de las siguientes primicias:

• Todos los tipos de balanceo disponibles (9i – 10g, ya que no he probado en 11g) ocurren al momento de iniciar la conexión.
• Las buenas aplicaciones se conectan una sola vez y permanecen conectadas (El costo de establecer una conexión con la base de datos es muy alto).

Ahora bien, los diferentes tipos de balanceo existentes son:

• Aleatorio. Es configurado a nivel cliente en la cadena de conexión o mediante hardware de balanceo y aleatoriamente distribuyen la conexión a las diferentes instancias. La parte negativa de este método es que no se toma en cuenta la carga en el nodo seleccionado o bien si el nodo está disponible, por lo cual pudieran causarse 'timeouts' a nivel TCP/IP.
  Para confiugurar este método se debe crear una cadena de conexión como la siguiente:
  RAC10G =
  (DESCRIPTION =
  (ADDRESS = (PROTOCOL = TCP)(HOST = srvrac1vip.oratest.com)(PORT = 1521))
  (ADDRESS = (PROTOCOL = TCP)(HOST = srvrac2vip.oratest.com)(PORT = 1521))
  (LOAD_BALANCE=yes)
  (CONNECT_DATA =
  (SERVER = DEDICATED)
  (SERVICE_NAME = rac10g.oratest.com)
  )
  )

• Basado en la carga del nodo. El balanceo se realiza a nivel listener y es el método predefinido de Oracle. Este método redirige las conexiones dependiendo del perfil de carga que el PMON de cada una de las instancias reporta dinámicamente al listener. La frecuencia de actualización del valor del perfil de carga depende de la carga misma, es decir, entre mayor sea la carga mayor es la frecuencia con la que el PMON actualiza el perfil de carga. Sin embargo, lo anterior está basado en la carga total en el NODO, no en la carga de las sesiones.
  Este método puede resultar muy bueno para conexiones que tienen una vida corta pero puede degradar el desempeño para las conexiones persistentes cuando la carga cambia a través del tiempo, es decir, el balanco inicial puede resultar finalmente desbalanceado.
  Este metodo no se recomienda para servidores de aplicación o metodos de conexión a través de un 'pool' de conexiones.

• Basado en el número de sesiones. El balanceo se realiza a nivel listener y es utilizado para distribuir el número de conexiones en cada instancia tomando en cuenta únicamente el número de sesiones conectadas a cada uno de los nodos.
  Este método permite evitar las llamadas “tormentas de conexiones” las cuales no son más que muchas conexiones haciendo una operación de 'logon' en un intervalo muy pequeño de tiempo.
  PMON registra la información de carga de nodo aproximadamente cada 60 segundos en promedio y es por este motivo que las "tormentas de conexiones" no pueden ser bien balanceadas mediante el metodo basado en la carga del nodo. El impacto directo de las "tormentas de conexiones" es una gran pérdida de rendimiento en el nodo afectado y como consecuencia una pérdida general de rendimiento y escalabilidad del cluster.
  Para configurar este método es necesario definir el siguiente parámetro del listener.
  PREFER_LEAST_LOADED_NODE_ =OFF

Ahora bien, entendamos como funciona el proceso de conexión a una base de datos en RAC:

1. El cliente desea iniciar una conexión a la base de datos y busca en su cadena de conexión la dirección correspondiente a la instancia.
   Si la cadena de conexión tiene configurado un balanceo, aleatoriamente seleccionará uno de los destinos configurados y enviará la petición de conexión.
2. Cuando el listener recibe la petición de conexión a la instancia, verificará de acuerdo al método configurado (B o C) a cual de las instancias se debe asignar la conexión.
3. Si la instancia en el nodo local es la candidata para la conexión, entonces el listener inicia el proceso de autenticación.
4. Si la instacia candidata para la conexión se encuentra en otro nodo, el listener regresa la cadena de conexión hacia el listener correspondiente al que el cliente deberá intentar conectarse e iniciar el proceso de autenticación.

En conclusión, es necesario llevar a cabo un estudio en función del tipo de aplicaciones que se desplieguen en un entorno RAC y cuidadosamente seleccionar la opción a utilizar. Aquí, la recomendación por mi parte es utilizar una combinación de la opción A con alguna de las otras dos opciones (B o C).

Referencias
=========

• Metalink nota 300903.1
• Oracle® Database Net Services Administrator’s Guide