Enlaces externos

Qué es un cluster?

Qué es Oracle Real Application Clusters?

La coordinación de recursos globales en un entorno RAC.

Un ejemplo de coordinación en el uso de la cache global.

• 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.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” 
• Un ejemplo de coordinación para la escritura en disco.
• El Nodo 1 envía a GCS un requerimiento de escritura a disco.
• GCS reenvía el requerimiento al Nodo 2, pues es el “holder” de la versión más actual del bloque.El Nodo 2 recibe el requerimiento y escribe el bloque a disco.
• El Nodo 2 notifica a GCS que se completo la escritura.
• GCS ordena a todos los “holders” de imágenes pasadas del bloque que descarten dichas imágenes.

Un cluster está formado por dos o mas servidores independientes pero interconectados. Algunos clusters 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 clusters estan diseñados para proveer escalabilidad permitiendo que los usuarios o carga se distribuya entre los nodos. Ambas configuraciones son consideradas clusters.

Una caracteristica importante que tienen los clusters es que se presentan a las aplicaciones como si fueran un solo servidor. Es deseable que la administración de diversos nodos de un cluster sea lo mas parecida posiblie a la administración de una configuración de un solo nodo. El software de administración del cluster 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 cluster.

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

Real Application Clusters es un software que permite utilizar un cluster de servidores ejecutando multiples 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 via el resto de las instancias disponibles.

En ambientes de una sola instancia, los mecanismos de lockeo 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 sincronizacion 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 cluster. 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 intancia para administrar la información particular de un recurso. Esta instancia es llamada Resource Master. De este modo cada instancia sabe en que 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 fusion es el encargado de mantener una cache coherente utilizando técncias 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 interinstancia que no maneja Oracle Fusion: dictionary cache locks, library cache locks, deadlock detection.

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

El escenario planteado en este ejemplo es el siguiente:

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

En el escenario que describiré a continuación, veremos cómo una instancia puede llevar adelante un checkpoint o reemplazar buffers en cache (como respuesta a requerimientos  de free buffers) en cualquier momento. Como múltiples versiones del mismo bloque de datos (con diferentes cambios) pueden existir en las caches de cada instancia del cluster, un protocolo manejado por GCS asegura que se escriba a disco sólo la versión del bloque que corresponda. GCS debe asegurar además que todas las versiones previas del bloque sean “purgadas” del resto de las caches. El requerimiento de escritura puede originarse en cualquiera de las instancias (que puede tener o no la última versión del bloque). En nuestro escenario suponemos que la primer instancia tiene una imagen pasada del bloque y ejecuta un requerimiento de escritura a disco:

Reconfiguracion dinamica del 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 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.

Afinidad de objetos y remasterización dinámica

Global Cache Services (GCS), el encargado de admininistrar el Globlal 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 remasterizacion 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.

Requerimientos adicionales de memoria para 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 un query 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 el query 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 los queries nos 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 los 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. Esta tecnología la aplica tanto a nivel intranodo como internodo.

Oracle RAC & Storage

• El voting file que es utilizado por algunos procesos para monitorear el estado de los nodos del cluster. Este archivo ocupa aproximadamente 20 MB.

• El OCR file (Oracle Cluster Registry) que mantiene información sobre los componentes de alta disponibilidad dentro del cluster. Su tamaño es de aproximadamente 100 MB.

La instalación de una base de datos Oracle RAC 10g comprende dos fases. En la primer etapa se instala el software de cluster. En la segunda etapa se instala el software de base de datos que incluye los componentes RAC y se crea la base en cluster. El Oracle Home que se usa para Oracle Clusterware (el software de cluster propio de Oracle) debe ser diferente del que se usa para el software de RAC.

Si bien es posible instalar el software de Oracle RAC en un storage compartido, es recomendable que se instale en un file system local a cada nodo. De este modo se evita que el software sea un posible punto único de falla en nuestro ambiente de alta disponibilidad.

Existen dos archivos muy importantes que deben quedar almacenados en storage compartido:

Tanto el voting file como el OCR file no pueden ser almacenado en ASM puesto que deben poder ser accedidos antes de levantar cualquier instancia Oracle. Ambos archivos pueden ser redundantes. La recomendación para estos archivos es almacenarlos en raw devices dentro de los discos más rápidos de los que se disponga.

Para crear la base de datos Oracle RAC se siguen los siguientes pasos:

• Instalacion del software de Oracle

• Tareas previas a la creacion de la base de datos

• Controles previos a la creacion de la base de datos

• Instalacion del agente de Enterprise Manager en cada nodo

• Creacion de la base de datos Oracle en cluster

• Ejecucion de tareas posteriores a la creacion de la base de datos clusterizada

• Que el sistema operativo este certificado

• Que se cumplan los requerimientos de configuracion de parametros kernel

• Que esten disponibles los paquetes (packages) de sistema operativo con las revisiones correctas

• Que esten disponibles las versiones correspondientes de los paquetes glibc y glibc-compat

• de proposito general

• transaccional

• Datawarehouse

• Avanzado (customizacion a cargo del usuario)

Para instalar el software de Oracle se utiliza OUI (Oracle Universal Installer). OUI se ejecuta con usuario “oracle” utilizando el comando runInstaller

database/runInstaller

Cuando aparece la pantalla “Welcome” hacer click en “next” para continuar.

Pantalla “Select installation type”

Seleccionar el tipo de instalación deseado y hacer click en “next”

Pantalla “Specify File Locations”

En la seccion “Destination” de esta pantalla  estan los campos que indican el nombre del Oracle Home y el path de los productos instalados. Notese que el software de la base no puede compartir la misma ubicacion (Oracle Home) que el software de Oracle Clusterware instalado previamente.

El campo “Field” es completado automaticamente con un valor por defecto o sugerido. Aqui hay que aceptar el nombre sugerido o ingresar el nombre de Oracle Home que se decida. Luego, en el campo “Path” se debe ingresar el path absoluto para la instalacion. Por ejemplo:

/u01/app/oracle/product/10.2.0/db_1

Completados estos campos, hacer click en “Next” para continuar.

Pantalla “Specify Cluster Installation”

OUI detecta los nodos que componen el cluster. Aqui se debe indicar si se pretende copiar la instalacion a los nodos reconocidos y seleccionados del cluster o si se quiere una instalacion simple. Hacer click en la opcion “Cluster Installation” y asegurarse de seleccionar todos los nodos de la lista. Si no aparecen todos los nodos, habra que salir de OUI , asegurarse de que Oracle Clusterware este corriendo en todos los nodos y reiniciar OUI. Hacer click en “Next” para proceder con la instalacion.

Pantalla “Product-Specific  Prerequisite checks”

La pantalla “Product-Specific Prerequisite Checks” verifica que se cumplan los requerimientos de sistema operativo a fin de poder llevar adelante una instalacion exitosa. Los requerimientos incluyen:

Ademas OUI chequea que la variable del entorno de usuario ORACLE_BASE este configurada y con un valor valido.

Cada vez que finaliza correctamente un chequeo, el check box “Succeded” es seleccionado automaticamente. Finalmente los resultados de la verificacion son mostrados en pantalla. Toda verificacion fallida sera reportada. Si nos encontramos con algun error, es recomendable abrir otra terminal y corregir el problema. Cuando todas las verificaciones son exitosas, hacer click en el boton “Next” para continuar.

 Pantalla “Select Configuration Option”

En esta pantalla se puede elegir crear una base de datos como parte del proceso de instalación del software de Oracle. Tambien es posible elegir configurar ASM. Si se selecciona crear una base de datos habra que seleccionar tambien uno de los tipos de bases preconfiguradas:

Si se selecciona una de estas opciones, OUI nos solicitara informacion especifica de la base de datos: nombre del cluster, nombre de la base, opciones de almacenamiento compartido, etc. Cuando OUI finaliza, DBCA es lanzado para instalar la base con la informacion provista.

Tambien se puede dejar para otro momento la creacion de la base haciendo click en el boton “Install database Software only”. Esta opcion habilita la posibilidad de crear la base en forma manual utilizando DBCA en otro momento posterior a la instalacion del software. Para continuar, hacer click en el boton “Next”.

Pantalla “Check Summary”

La pantalla “Check Summary” permite revisar toda la informacion provista a OUI: informacion de los nodos, requerimientos de espacio y componentes de software seleccionados. Si se esta satisfecho con este resumen, hacer click en “Install” para proceder con la instalacion del software. Si no se esta satisfecho, se puede hacer click en el boton “Back” para retroceder y hacer las modificaciones apropiadas.

Pantalla “Install”

La pantalla “Install” permite monitorear el progreso de la instalacion. Durante este proceso, OUI copia el software al nodo local y a los nodos remotos.

El script “root.sh”

Al final de la instalacion, OUI muestra una caja de dialogo indicando que se debe ejecutar el script root.sh con el usuario root en todos los nodos en que se estara instalando el software. Ejecutar el script en cada nodo y luego hacer click en el boton “OK” de la caja de dialogo para continuar.