Introducción a ASM

ASM son las siglas de Automatic Storage Management, que es un producto de Oracle que hace de gestor de volúmenes lógicos y/o sistema de ficheros para albergar los ficheros de las bases de datos de la misma compañía. De esta forma, cuando se crea una base de datos Oracle se puede escoger que el almacenamiento para sus archivos sea ASM en vez de un sistema de archivos normal. ¿Pero qué es en realidad ASM? ASM es una instancia Oracle, con su SGA y sus procesos background, que interactúan con las instancias de la base de datos "cliente" para proporcionarle la información necesaria para que pueda leer y escribir en los archivos de datos (datafiles, control files, redo logs, archived logs, flashback logs, spfiles, RMAN backups, Incremental tracking bitmaps y datapumps dumpfiles). Es importante notar que ASM no sirve los bloques de datos a las instancias "cliente", sino que son ellas mismas las que acceden a los discos para leer o escribir. ASM lo único que hace es proporcionarle metainformación sobre dónde leer o escribir los datos.

La instancia ASM, como instancia que es, en vez de montar una base de datos monta disk groups, que son agrupaciones de ASM disks que se usan de forma transparente como si fuera uno sólo. Para verlo con más facilidad, es como si los disk groups fueran tablespaces y los ASM disks, datafiles. Los ASM disks pueden ser LUNs, discos físicos, particiones de discos físicos o incluso volúmenes lógicos aunque Oracle no recomienda esto último porque existiría solapamiento de funciones entre el volume manager instalado y el propio ASM.

ASM puede dar servicio tanto a una base de datos única como a un RAC (Real Application Cluster), que de hecho es donde es más habitual instalarlo. En un RAC, ASM corre en cada nodo y se comunica con el resto de ASMs del RAC a través de la interconexión, pero no nos perdamos en la configuración de RAC y ASM.

Retomando el término disk group, como hemos dicho, un fichero de las bases de datos "cliente" se asigna a un único disk group (un fichero sólo se asocia a un disk group, pero un disk group tiene multitud de ficheros). Las extensiones de los ficheros se distribuyen homogéneamente entre los ASM disks que conforman el disk group equilibrando así la carga de trabajo de los discos y mejorando el rendimiento general del sistema. Normalmente, las instancias usan sólo 2 disk groups para alojar todos sus archivos, una para datos y otra para fast recovery area.

Otra de las funcionalidades de ASM es que permite añadir o eliminar en caliente ASM disks redistribuyendo el contenido del disk group entre los ASM disks que haya. Si se quiere eliminar un ASM disk, antes ASM tiene que redistribuir los datos del disco a eliminar entre los restantes. Si se añade un ASM disk, ASM redistribuye el contenido del disk group entre todos los ASM disks, dado que ahora hay uno más. Lo más interesante es que esta operación la hace ASM en caliente permitiendo a las instancias acceder a sus ficheros mientras se está produciendo el rebalanceo.

Además de poder hacer redistribución (striping), ASM puede hacer redundancia (mirroring) de los datos. Para ello, al crear un disk group se indica el failure group asociado y ASM distribuye cada copia a un fail group distinto. La ídea del fail group es coger los ASM disks del disk group y hacer grupos distintos, los llamados fail groups, de forma que cada grupo esté protegido de los fallos que pueda tener el otro. Ahora bien, en función del tipo de contingencia para la que nos queramos proteger tendremos una agrupaciones u otras. Por ejemplo, un disk group con dos ASM disks podemos definirlo con dos fail groups, cada uno con un sólo disco. Así, la avería de un disco no me dejaría sin datos (tengo otro réplica del afectado). Pero si hay una avería de la controladora de los discos, que es común para ambos, nos quedaríamos sin acceso a los datos. Entonces habría que escoger discos distintos en distintas controladoras. ¿Y si se avería el hardware en donde residen ambas controladoras?. De acuerdo, pues usamos dispositivos de almacenamiento absolutamente distintos. ¿Y si se prende fuego el CPD?.... y así podemos seguir hasta el infinito.

En relación a la redundancia, también se puede hacer réplica de los datos duplicándolos o triplicándolos. Cuando se define el disk group se indica si la replicación será EXTERNAL (sin replicación ASM), NORMAL (se duplican los datos) o HIGH (se triplican los datos). En una configuración NORMAL serán necesarios dos fail groups y en HIGH, tres fail groups.

Por último y para acabar esta breve introducción, sólo decir ASM se puede integrar completamente con OMF (Oracle Managed Files) escribiéndo únicamente el nombre del disk group allí donde se tendría que poner el nombre completo del archivo.

Continuaré escribiendo cosas de ASM, esto es sólo ha sido una breve introducción para coger nociones de qué es y para qué sirve.


Juan Lorenzo Arellano.
Infor Consult Soluciones.
www.inforconsult.es

Single Cliente Access Name (SCAN)

En Oracle11g Release 2 se ha creado un nuevo esquema de conexión SQL*Net para la arquitectura Real Application Cluster (RAC), donde los clientes no conectan a los listener locales de los nodos del cluster directamente; ahora se usan unas direcciones IPs, llamadas direcciones SCAN (normalmente son tres), que son asociadas con un mismo nombre de dominio o nombre del cluster, también llamado nombre SCAN, de forma que cuando un cliente interroga al DNS por ese dominio, éste responde con una IP distinta cada vez (de entre las tres configuradas) y de forma cíclica.

Durante la instalación del RAC se crean los tres listener que escuchan por las tres IPs SCAN y es Oracle Clusterware el que reparte estos listener por los nodos del cluster según sus algoritmos de reparto de recursos en función de la carga de los nodos. Los clientes conectan al cluster usando el nombre SCAN que el DNS resolverá por una de tres IPs, lo que hará que los clientes conecten al listener SCAN que escucha por dicha IP. Los listener SCAN conocen los servicios ofrecidos por el cluster (a través del parámetro REMOTE_LISTENER de cada instancia), qué instancias ofrecen dichos servicios y con qué nivel de saturación, de forma que el listener SCAN redirecciona la petición al listener local del nodo que atiende el servicio solicitado por el cliente con la menor carga de trabajo.

De esta forma si añadimos o eliminamos nodos del cluster los clientes no se ven afectados porque seguirán conectando al nombre SCAN y cuyo listener SCAN redireccionará al listener del nodo adecuado. Además, dado que Oracle Clusteware mueve los listener SCAN entre los nodos, si quitamos un nodo en el que está corriendo un listener SCAN éste será movido a otro nodo y el cliente no se enterará de la operación resultando transparente para él.

Las instancias del cluster saben siempre en qué nodos están corriendo los listener SCAN por medio del parámetro REMOTE_LISTENER, cuyo valor es dirección_scan:puerto_scan. Las instancias del cluster resuelven la dirección_scan por las tres IPs, y la correspondencia entre la IP SCAN y el nodo en donde reside dicha IP (recuérdese que Oracle Clusterware mueve los listener SCAN entre los nodos) se hace a través del protocolo TCP/IP ARP. Por tanto, cuando Oracle Clusteware mueve los listener SCAN de un nodo a otro, ni en los clientes ni en las instancias se debe modificar nada porque el cambio se hace por debajo del nivel de applicación.

Para gestionar los listener SCAN se debe usar la herramienta del clusterware srvctl:

Saber el estado de las IPs SCAN:

c:\> srvctl status scan
SCAN VIP scan1 is enabled
SCAN VIP scan1 is running on node
SCAN VIP scan2 is enabled
SCAN VIP scan2 is running on node
SCAN VIP scan3 is enabled
SCAN VIP scan3 is running on node

Saber el estado de los listener SCAN:

c:\> srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node

Parar los listener SCAN:

c:\> srvctl stop scan_listener [-f force] --> para todos los listener SCAN
c:\> srvctl stop scan_listener -i 2 --> para el listener 2

Arrancar todos los listener SCAN:

c:\> srvctl start scan_listener --> arranca los listener SCAN en los nodos que el clusterware considere.
c:\> srvctl start scan_listener -n nombre_del_nodo --> arranca los listener SCAN en el nodo indicado
c:\> srvctl start scan_listener -i 2 [-n nombre_del_nodo] --> arranca el listener 2 [en el nodo indicado]

Finalmente, sólo añadir que la redirección que hacen los listener SCAN hacia los listener locales de los nodos se hace a través de la dirección IP virtual o VIP, es decir, los listener locales de los nodos escuchan tanto por la IP pública como por la VIP. Esto permite poder seguir usando conexiones clientes como hasta ahora, es decir, usando en el descriptor de conexión la IP virtual del nodo al que queremos conectarnos sin preocuparnos por SCAN para nada. Esto es especialmente valioso si tenemos en cuenta que para que un cliente pueda usar SCAN debe tener versión Oracle11g Release 2 o superior, de forma que tras una migración de nuestro servidor a Oracle11g nuestros clientes pueden permanecer inalterados, aunque no es lo recomendable.

Juan Lorenzo Arellano
Infor Consult Soluciones.
www.inforconsult.es