Oracle RAC for not so dummies

¿Qué es un Cluster?

Un clúster está formado por dos o más servidores independientes pero interconectados. 

Algunos clústeres están configurados de modo tal que puedan proveer alta disponibilidad permitiendo que la carga de trabajo sea transferida a un nodo secundario  si el nodo principal deja de funcionar. Otros clústeres están diseñados para proveer escalabilidad permitiendo que los usuarios o carga se distribuya entre los nodos. Ambas configuraciones son consideradas clústeres.

Una característica importante que tienen los clústeres es que se presentan a las aplicaciones como si fueran un solo servidor. Es deseable que la administración de diversos nodos de un clúster sea lo más parecida posible a la administración de una configuración de un solo nodo. El software de administración del clúster debería proveer este nivel de transparencia.

Para que los nodos puedan actuar como si fueran un solo servidor, los archivos deben estar almacenados de modo tal que puedan ser accedidos por todos los nodos del clúster.

En resumen, un clúster es un grupo de servidores independientes que cooperan comportándose como si fueran un solo sistema.

¿Qué es Oracle Real Application Clusters?

Real Application Clusters es un software que permite utilizar un clúster 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.

Coordinación de recursos globales en un entorno RAC

En ambientes de una sola instancia, los mecanismos de bloqueo coordinan el acceso a recursos comunes como ser una simple fila de una tabla. Los mecanismos de lockeo previenen la posibilidad de que dos procesos modifiquen un mismo recurso al mismo tiempo.

En entornos RAC, la sincronización “internodo” es crítica para mantener una adecuada coordinación entre los distintos procesos en diferentes nodos, previniendo que estos procesos modifiquen el mismo recurso al mismo tiempo. La sincronización internodo garantiza que cada instancia vea la versión más reciente de un bloque de la buffer cache.

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 clúster. Global Cache Services (GCS) y Global Enqueue Services (GES) administran la información del GRD.

Cada instancia mantiene una parte de la GRD en su propia SGA. GCS y GES nominan a una instancia para administrar la información particular de un recurso. Esta instancia es llamada Resource Master. De este modo cada instancia sabe en qué instancia está masterizado cada recurso.

Mantener una cache coherente es también una parte muy importante dentro de la actividad de un RAC. El algoritmo Cache fusión es el encargado de mantener una cache coherente utilizando técnicas que mantienen múltiples copias consistentes de un mismo bloque entre diferentes instancias Oracle. Este algoritmo es implementado por GCS.

GES administra todos los recursos inter instancia que no maneja Oracle Fusión:

• Dictionary cache locks,
• Llibrary cache locks,
• Deadlock detection.

Coordinación en el uso de la cache global.

Analizaremos un breve ejemplo puntual de coordinación del uso de la cache global.

El escenario planteado en este ejemplo es el siguiente:

• Dos instancias en RAC. Nodo 1 y Nodo 2.
• Un bloque de datos ha sido modificado (dirtied) por el Nodo 1.
• El Nodo 2 intentará modificar el mismo bloque.

Veamos qué ocurre para que el Nodo 2 modifique el bloque:

• El Nodo 2, que intenta modificar el bloque, submite un requerimiento a GCS.
• GCS transmite el requerimiento al “holder” del recurso. En este caso, el Nodo 1 es el quien tiene el recurso.
• El Nodo 1 recibe el mensaje y envía el bloque a la segunda instancia. El Nodo 1 mantiene el bloque “sucio” (también llamado “past image”).
• Cuando el Nodo 2 recibe el bloque, informa a GCS que ahora es el “holder” del bloque. 

Reconfiguración dinámica del GRD (Global Resource Directory)

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 clúster. Cada instancia mantiene una porción del GRD en su propia SGA.

Cuando una instancia abandona el clúster, 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 clúster, 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.

Afinidad de objetos y remasterización dinámica

Global Cache Services (GCS), el encargado de administrar el Global Resource Directory (GRD) junto a Global Enqueue Services (GES), implementa un algoritmo para migrar dinámicamente recursos del GRD. 

A este algoritmo se lo conoce como remasterización dinámica. La idea básica de la remasterización dinámica es mantener un recurso de la buffer cache en la instancia que mas lo accede. GCS lleva un registro de los requerimientos por instancia y por objeto de modo tal que dispone de la información necesaria para migrar en forma dinámica recursos de una instancia a otra que lo accede más.

Memoria en una instalación de Oracle RAC

La memoria específica para la administración del RAC se aloca 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 un base de datos Oracle single instance a RAC, si se pretende que cada nodo mantenga su 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.

Ejecución paralelizada en RAC

El optimizador basado en costos incorpora consideraciones de ejecución en paralelo a fin de obtener planes de ejecución óptimos.

En entornos RAC las decisiones del optimizador se hacen tanto a nivel intranodo como internodo. 
Por ejemplo, si una consulta requiere de 6 procesos para completar  su tarea y existen 6 procesos esclavos ociosos en el nodo local (el nodo al que está conectado el usuario) entonces la consulta se resuelve utilizando solamente recursos locales. De este modo se logra un paralelismo intranodo eficiente y se elimina el overhead que generaría una resolución internodo. 

Sin embargo, si existieran sólo 2 procesos esclavos ociosos en el nodo local, entonces se usarán los 2 procesos locales mas 4 de otro para completar el query. En este último caso se utiliza paralelismo intranodo e internodo a fin de acelerar el procesamiento.

Otro aspecto a considerar es que frecuentemente las consultas son particionados de forma perfecta entre los procesos esclavos; de modo tal que no todos terminan al mismo tiempo. La tecnología de procesamiento paralelo de Oracle detecta en forma dinámica el proceso que están ociosos porque ya finalizaron y vuelve a asignarle trabajo tomado de las tablas de colas de los procesos sobrecargados. De este modo Oracle redistribuye el trabajo en forma dinámica y eficiente entre todos los procesos.  

Procesos background en RAC.

En una configuración RAC aparecen una serie de nuevos procesos background. La función primaria de estos procesos es mantener una administración coherente entre todos los nodos que conforman el clúster: 

• LMON. Global Enqueue Service Monitor 
• LMD 0. Global Enqueue Service Daemon 
• LMS x. Global Cache Service (x puede ir de 0 a n) 
• LCK. Proceso de lockeo DIAG. 

Proceso de diagnóstico También aparecen nuevos procesos a nivel de clúster para la administración de Oracle Clusterware: 

• CRSD y RACGIMON motores para operaciones de alta disponibilidad 
• OCSSD provee accesos de membrecía a nodos y grupos de servicios 
• EVMD detecta eventos y reacciona invocando procesos. 
• OPROCD monitor de procesos del clúster (no esta presente en Linux ni Windows)