Para la preparación del examen de Oracle RAC 11 (1Z0-058, Oracle Real Application Clusters 11g Release 2 and Grid Infrastructure Administration), he tenido que buscar gran cantidad de información de fuentes muy diversas: OBE, OTN, wikipedia, foros de Oracle...

Para preparar este examen no he tenido ninguna prisa, así que se ha antepuesto la pauta de intentar que parte del material fuera reutilizable, para mí mismo, principalmente.

Todo el que haya intentado especializarse en Oracle habrá notado la ausencia de documentación en Español. Para Oracle RAC 11 no iba a ser distinto.

Los vídeos de OBE son realmente buenos y entretenido, dentro de lo que cabe, por eso pensé que podría ser una buena idea traducir los más interesantes sobre RAC a español. Ya os adelanto que este es el primero y el último que traduzco, porque ha resultado más difícil de lo que pensaba.

En este vídeo se describe la arquitectura de Grid Naming Service GNS, un nuevo concepto incorporado en 11g R2:



00:00:07.268,00:00:09.268
Hola y bienvenido.

00:00:10.96,00:00:15.96
Me llamo J. Verrier...
(presentación)

00:00:20.039,00:00:25.039
Vamos a explorar la arquitectura de Grid Naming Services también conocida como GNS.

00:00:26.285,00:00:28.285
Introducida en Oracle RAC 11g Release 2.

00:00:30.867,00:00:36.867
Cuando estás utilizando Oracle RAC, todos los clientes deben
 ser capaces de alcanzar el nombre del clúster.

00:00:38.127,00:00:43.127
Esto quiere decir que todos los nombres de clústers
 debe poder ser resueltos por los clientes.

00:00:44.397,00:00:49.397
En los nombres de clúster incluímos los nombres de
 SCAN y los nombres de los nodos.

00:00:50.202,00:00:55.202
Por ahora, dejaremos los nombres de SCAN para más adelante de esta presentación.

00:00:56.099,00:01:02.099
Tradicionalmente, le puedes decir a los clientes los nombres
 de clúster configurando los ficheros de red

00:01:02.137,00:01:07.137
o tu servidor DNS. Indicando los nombres y las correspondientes direcciones.

00:01:09.892,00:01:13.892
Sin embargo, según el número de nodos en el clúster crece

00:01:14.025,00:01:19.025
esta parte de administración de la red, puede rápidamente volverse pesada

00:01:18.971,00:01:22.971
debido al número de entradas que tienes que mantener.

00:01:23.267,00:01:31.267
Este problema se resuelve añadiendo la función Oracle Grid Naming Service, GNS, al clúster.

00:01:32.694,00:01:34.694
La idea es bastante simple.

00:01:35.062,00:01:40.06
Deja que GNS recopila todos esos nombres y direcciones
 y se los pase a tu servidor DNS

00:01:39.933,00:01:48.93
para la resolución de los clientes, según el
 número de nodos en tu clúster evoluciona.

00:01:50.295,00:01:54.30
Para implementar GNS debes colaborar con el administrador de la red

00:01:54.267,00:01:58.27
para obtener una dirección IP en la red pública

00:01:57.957,00:01:59.96
para el GNS VIP.

00:02:01.069,00:02:07.07
Esta es la única dirección IP que debes
 tener durante la instalación de tu clúster.

00:02:07.106,00:02:13.11
También debes colaborar con el administrador del DNS para delegar el dominio al clúster.

00:02:13.097,00:02:18.10
Puede ser un dominio separado o un subdominio de un dominio existente.

00:02:18.577,00:02:28.58
El servidor DNS debe configurarse para redirigir todas las
 peticiones para este dominio nuevo
al GNS VIP.

00:02:28.793,00:02:38.79
Observa que en 11g R2, un GNS server está vinculado a
 un clúster particular y debe tener asignado un dominio único,

00:02:40.033,00:02:42.03
el cuál estará en su control.

00:02:43.236,00:02:51.24
El demonio de GNS, y el recurso de GNS VIP
 corren en uno de los nodos del clúster.

00:02:50.899,00:02:59.90
El demonio de GNS escucha en el GNS VIP,
 usando el puerto 53 para las peticiones DNS.

00:02:59.397,00:03:08.40
Oracle Clusterware gestiona el GNS y el GNS
 VIP para asegurarse que siempre están disponibles

00:03:07.733,00:03:12.73
Esto significa que si el nodo en el que está corriendo GNS falla

00:03:13.956,00:03:21.96
entonces Oracle Clusterware ordena a GNS junto a GNS
 VIP moverse a otro nodo en el clúster

00:03:23.128,00:03:25.13
Ahora, la pregunta es

00:03:25.775,00:03:32.78
cómo GNS consigue todas los nombres de clúster y sus direcciones correspondientes

00:03:32.045,00:03:35.04
Esto se hace de dos formas distintas

00:03:35.388,00:03:43.39
De hecho, es durante el arranque de Clusterware, que el agente especializado ____

00:03:43.051,00:03:49.05
corriendo en cada nodo del clúster, solicitan qué nodos
 VIP y SCAN VIP a tu servidor DHCP.

00:03:51.48,00:03:59.48
Entonces, un servidor aleatorio registra esta información al servidor GNS automáticamente.

00:03:58.794,00:04:05.79
Así que, activar GNS en el clúster requiere
 un servidor DHCP en la red pública.

00:04:08.639,00:04:10.64
En cuanto a los nombres de clúster

00:04:10.961,00:04:15.96
es GNS que pregunta resolución de hostname a dirección

00:04:16.07,00:04:22.07
utilizando el proceso mDNS corriendo en cada nodo del clúster.

00:04:21.503,00:04:23.50
Esto se hace utilizando el protocolo mDNS

00:04:25.265,00:04:31.26
El proceso mDNS ve todos los interfaces y direcciones en la máquina

00:04:30.559,00:04:33.56
y los asocia a nombres de host

00:04:34.367,00:04:37.37
Este proceso también lo inicia Clusterware

00:04:36.933,00:04:45.93
Observa que mDNS también es responsable de GPnP (Grid Plug and Play) proccess discovery

00:04:44.862,00:04:47.86
en el contexto de no xxx y xxx, por ejemplo.

00:04:48.438,00:04:55.44
Sin embargo, no vamos a entrar en los detalles de GPnP en esta presentación

00:04:54.94,00:05:03.94
A las inserciones con 11g R2 es a lo que
 se le llama SCAN y SCAN listeners asociados.

00:05:02.928,00:05:07.93
El SCAN listener es básicamente el punto de entrada de tu clúster.

00:05:06.968,00:05:14.97
Está ahí para balancear la carga de las conexiones
 entrantes a los nodos de tu clúster

00:05:14.033,00:05:20.03
redireccionando las conexiones entrantes al nodo con menos carga

00:05:18.996,00:05:26.00
que tiene el servicio de la base de datos usando el listener local correspondiente

00:05:23.175,00:05:27.18
En tu clúster, en realidad hay 3 SCAN listeners.

00:05:28.052,00:05:35.05
Esto es para evitar "abarrotar" el listener cuando hay un montón de conexiones simultáneas

00:05:34.646,00:05:42.65
Lo bueno de los SCAN listeners es que
 aunque cada uno tiene su VIP correspondiente

00:05:42.332,00:05:50.33
todos resuelven a un nombre que se llama el
 Single Client Access Name o SCAN Name

00:05:49.762,00:05:58.76
Las direcciones de los tres SCAN LISTENER de los VIPS, ya
 que escanean si un SCAN listener falla en un nodo

00:05:57.703,00:06:05.70
el clúster lo pasará a otro nodo, por lo
 que siempre tendrás 3 SCAN listeners disponibles

00:06:04.577,00:06:15.58
Desde la perspectiva del cliente, la única información necesaria para
 conectar a un servicio de base de datos

00:06:13.4,00:06:17.4
es el nombre del servicio y el SCAN name

00:06:16.867,00:06:25.87
Para resolver la combinación el cliente reune una petición
 DNS. Mirando al nombre de dominio del clúster

00:06:26.635,00:06:37.64
en el nombre de SCAN, el DNS es capaz de preguntar al
 servidor GNS quién responde con un los tres SCAN VIPS.

00:06:36.202,00:06:47.20
Cuando el cliente vuelve del GNS con los tres SCAN VIP, toma
 uno de ellos utilizando el balanceo de carga del cliente

00:06:45.606,00:06:49.61
para obtener uno de los SCAN listeners.

00:06:48.671,00:07:00.67
Este SCAN listener es entonces responsable de redirigir la conexión al nodo con
 menos carga que corre con el servicio solicitado y su listener local

00:07:01.465,00:07:08.46
SCAN listener obtiene la información del balanceo de carga
 de las instancias de bases de datos

00:07:07.433,00:07:15.43
que añaden el remote_listener y el parámetro de inicialización apuntando a los SCAN listeners

00:07:17.0,00:07:21.0
Este es el final de la presentación

00:07:19.925,00:07:23.92
Espero que lo hayas encontrado útil

00:07:22.433,00:07:24.43
y gracias por verlo.