PDF de programación - Oracle Grid Naming Service

Oracle Grid Naming Service

Por Francisco Riccio



Introducción

Grid Naming Service (GNS) es una configuración que nos da la flexibilidad de colocar dinámicamente

más nodos en el cluster de una manera simple. GNS es uno de los pilares de Plug & Play, el cual es una

posibilidad que nos da Oracle de agregar o eliminar un servidor al cluster con el mínimo esfuerzo. La

información que es requerida por Plug & Play y por supuesto por GNS es almacenada en el archivo

profile.xml que se encuentra en las siguientes ubicaciones de cada servidor que conforma el cluster:

$ORACLE_HOME_GRID/gpnp/<hostname>/profile/peer/profile.xml

$ORACLE_HOME_GRID /gpnp/profile/peer/profile.xml (backup global)

Este archivo lleva información sobre la configuración del cluster, tales como: datos sobre la

interconnect, IP VIP, Storage del ASM, etc. Profile.xml es actualizado ni bien existe un cambio en la

configuración y es replicado en el profile de cada servidor. El responsable de realizar está replicación es

el proceso background: gpnpd.

Al colocar un nuevo equipo en el cluster teníamos que preocuparnos por las IP VIP y adicionalmente el

IP SCAN si recién iniciábamos una instalación nueva de Infraestructura Grid. GNS ahora se encarga de

asignar dinámicamente IPs a nuestras VIPs y a nuestro SCAN, estas IPs son obtenidas de un pool de IPs

reservadas. Para realizar esta labor, GNS solicita como parte de su implementación un servicio DNS y un

servicio DHCP.

Arquitectura

El servicio de GNS solo inicia en uno de los servidores del cluster y atiende por el puerto 53 protocolo

tcp. Este servicio está registrado como un recurso en el OCR, por lo cual, ante la caída del servidor que

lleva el servicio GNS automáticamente Clusterware migra el servicio a uno de los nodos sobrevivientes.

GNS tiene asignado una IP virtual estática la cual se iniciará como parte del servicio.

Iniciado el proceso GNS con su IP virtual estática, el proceso background orarootagent solicita al servidor

DHCP los IPs necesarios para asignarlo a cada servidor que conforma el cluster. Estos IPs sirven para

asignarlos a los IPs virtuales y a los IP SCAN cuya información es registrada en el servicio GNS.

El proceso background: mdns que se encuentra en cada servidor tiene registrado de manera interna el

hostname de cada equipo con su IP dinámica, él tiene la responsabilidad de realizar la resolución de

nombres solicitados por el servidor DNS. La comunicación sobre el requerimiento de resolución de

nombres entre el servidor DNS y el proceso background mdns se realiza mediante el background gnsd.

En la figura 1 se presenta de forma más detallada la comunicación que ocurre en una configuración GNS.



1

Figura 1



Una aplicación envía su cadena de conexión utilizando SCAN name (ejemplo: pcrac-scan.gns.oracle.com)

para conectarse a una de las instancias del cluster. El servidor DNS delegará al servicio GNS la resolución

del SCAN name con la finalidad que el cliente obtenga una IP SCAN. Con la IP que obtiene, la aplicación

es re direccionada al Listener SCAN correspondiente y luego él lo direccionará al Listener de Base de

Datos con menos carga. Para obtener la IP de un SCAN name, el servicio GNS se apoya en los procesos

background: mDNS que se ejecutan en cada servidor y en el proceso gnsd.













2

Implementación

La implementación realizada para nuestro ejemplo está basado sobre una plataforma Oracle Linux

versión 5.7 de 32 bits en todos los servidores. La Infraestructura Grid a instalar será una versión

11.2.0.3.

La red pública en esta implementación es la IP: 172.68.1.X

El servidor DNS y DHCP tiene la siguiente IP: 172.68.1.5

Los servidores que conforman el cluster tienen las siguientes IPs:

•

•

IP Pública: 172.68.1.30 y 172.68.1.40

IP Privada: 182.68.1.30 y 182.68.1.40

1) Configuración del Servidor DNS:

A continuación se detalla los archivos de configuración que permiten la habilitación del servicio DNS.

/var/named/chroot/etc/named.conf

options {

listen-on port 53 { 127.0.0.1; 172.68.1.5; };

directory "/var/named";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

};

zone "localdomain." IN {

type master;

file "localdomain.zone";

allow-update { none; };

};

zone "oracle.com" IN {

type master;

file "oracle.com.zone";

allow-update { none; };

};



3

zone "1.68.172.in-addr.arpa." IN {

type master;

file "1.68.172.in-addr.arpa";

allow-update { none; };

};

include "/etc/rndc.key";



Hasta aquí hemos creado una zona al dominio llamado oracle.com con su zona inversa.

Procedemos a crear la especificación de ambas zonas:

/var/named/chroot/var/named/oracle.com.zone

$TTL 86400

@ IN SOA pcdns root.pcdns.oracle.com (

42 ; serial (d. adams)

3H ; refresh

15M ; retry

1W ; expiry

1D ) ; minimum

IN NS pcdns.oracle.com

pcdns IN A 172.68.1.5

pcgns1 IN A 172.68.1.30

pcgns2 IN A 172.68.1.40

$ORIGIN gns.oracle.com.

@ IN NS gns-srv.gns.oracle.com.

gns-srv.gns.oracle.com. IN A 172.68.1.235



Al final de la especificación de la zona debemos crear un sub-dominio, en mi caso llamado

gns.oracle.com. Este sub-dominio realizará la resolución de nombres al interno del cluster.

También debemos registrar en el subdominio "gns.oracle.com" un hostname que resuelva por la IP

virtual estática de GNS, en nuestro ejemplo es: gns-srv.gns.oracle.com (172.68.1.235).



4

Se recomienda que la resolución de IPs públicas mediante los hostname de los servidores que forman el

cluster se deberían registrar en el dominio tal como se detalla en el ejemplo.

La zona inversa tiene la siguiente configuración:

/var/named/chroot/var/named/1.68.172.in-addr.arpa

$ORIGIN 1.68.172.in-addr.arpa.

$TTL 1H

@ IN SOA pcdns.oracle.com. root.oracle.com. ( 2

3H

1H

1W

1H )

@ IN NS pcdns.oracle.com.

5 IN PTR pcdns.oracle.com.

30 IN PTR pcgns1.oracle.com.

40 IN PTR pcgns2.oracle.com.

235 IN PTR gns-srv.gns.oracle.com.



Nota:

• El servidor DNS debe tener instalado el rpm: caching-nameserver.

• El archivo resolv.conf, nsswitch y host de cada servidor que forma el cluster deben tener el

siguiente contenido acorde a nuestro ejemplo:

/etc/resolv.conf

search gns.oracle.com oracle.com

nameserver 172.68.1.5

/etc/nsswitch.conf

Reemplazar la línea:

hosts: files dns

Por:



5

hosts: dns files nis

Siempre la primera resolución se debe dar por el servicio DNS en caso contrario puede ocasionar

una inconsistencia de resolución de nombres.

/etc/hosts

127.0.0.1

localhost.localdomain

localhost

182.68.1.30 pcgns1-priv.oracle.com

pcgns1-priv

182.68.1.40 pcgns2-priv.oracle.com

pcgns2-priv









2) Configuración del Servidor DHCP:

A continuación se detalla los archivos de configuración que permiten la habilitación del servicio DHCP.

/etc/dhcpd.conf

ddns-update-style interim;

ignore client-updates;

subnet 172.68.1.0 netmask 255.255.255.0 {

range 172.68.1.220 172.68.1.234;

default-lease-time 86400;

option routers 172.68.1.1;

option ip-forwarding off;

option broadcast-address 172.68.1.255;

option subnet-mask 255.255.255.0;

option time-offset -28800;

option domain-name "gns.oracle.com";

option domain-name-servers 172.68.1.5;

}



En esta configuración, el servidor DHCP puede asignar IPs en el siguiente rango: 172.68.1.220/234. Estas

IPs serán asignadas para los IP VIP y SCAN.





6

/etc/sysconfig/dhcpd

# Command line options here

DHCPDARGS="eth0"



En este archivo estamos definiendo que mediante la tarjeta eth0 será la que escuchará las peticiones de

asignación de IP.



3) Instalación de Infraestructura Grid:

Para instalar Infraestructura Grid con GNS debemos escoger la opción avanzada.

Figura 2





7

Figura 3



En la figura 3 podemos apreciar lo siguiente:

• El SCAN name está asignado al sub-dominio gns.oracle.com y asimismo el hostname (pcgns-

scan) no está registrado en el servidor DNS.

• En el campo GNS Sub Domain debemos colocar el nombre del sub-dominio que en nuestro caso

es: gns.oracle.com

• GNS VIP Address es la IP Virtual fija que tendrá el servicio GNS y atenderá por el puerto 53. Esta

IP está definida en el servidor DNS.

En la siguiente pantalla de la instalación podemos apreciar que los servidores tienen asignación

automática para sus IPs virtuales.



8

Figura 4



Al acabar la instalación de la Infraestructura Grid podemos realizar algunas pruebas de validación, las

cuales se detallan:

Cada SCAN VIP tiene una IP que está en el rango de asignaciones del servicio DHCP.





















9

Asimismo la tarjeta de red eth0 tiene asignada nuevas IPs las cuales son la IP VIP & SCAN.











10

Debemos validar además que el SCAN name está reso