Gestion d’une ressource listener avec RAC 11g

Dans une configuration RAC simple on se retrouve généralement avec un listener associé à chaque noeud qui écoute sur le port standard 1521 sur le réseau public (celui par lequel vos applications ou vos serveurs d’applications vont accéder aux bases données).

Voici comment faire pour disposer d’un listener dédié (par exemple aux connexions des DBAs) sur un réseau distinct, ce listener ne fonctionnera que sur un seul nœud et basculera en cas de besoin sur un autre nœud disponible.

L’architecture que j’utilise pour cet exemple est la suivante :

• RAC 2 noeuds linux OEL5 (64bits), baies disques en attachement fibre
• Oracle Standard Edition 11.1.0.7 , CRS 11.1.0.7 (le fonctionnement est identique en version 10.2.0.4 ou 11.1.0.6) , OCR et voting en raw devices, Disk groupes ASM pour les fichiers des bases de données
• 3 Réseaux utilisant chacun une interface de type “bonding” (regroupant 2 cartes réseau) : bond1 pour l’interconnexion (10.0.0.),  bond2 pour le réseau public (192.168.0), bond3 pour le réseau d’administration dédié (143.46.43)
• Les serveurs sont nommés rac1 et rac2
• Contenu du fichier  /etc/hosts pour les 2 nœuds

## Réseau public
192.168.0.1   rac1
192.168.0.2   rac2
192.168.0.3   rac1-vip
192.168.0.4   rac2-vip

## Réseau admin
143.46.43.1 rac1-adm
143.46.43.2 rac2-adm
143.46.43.5 rac-adm   # Adresse virtuelle qui sera
                      # celle utilisée pour l'accès au listener

## Interconnect
10.0.0.1   rac1-priv
10.0.0.2  rac2-priv

Les étapes de la mise en oeuvre sont :

• Création d’une adresse VIP dédiée
• Création d’une ressource listener
• Configuration des instances et du réseau Net Oracle

Mais avant toute chose, pour être certain de pouvoir repartir en cas de fausse manipulation,  la sauvegarde du registre du cluster (OCR)

$ORA_CRS_HOME/bin/ocrconfig –export /home/oracle/save/ocr.save –s online

1 Création d’une adresse VIP dédiée

Création de la ressource  admin-vip pour l’adresse utilisée  pour l’administration (exécution des commandes en tant qu’utilisateur root) :

$ORA_CRS_HOME/bin/crs_profile -create admin-vip \
        -t application -p favored -h rac1 -a    \
        $ORA_CRS_HOME/bin/usrvip -o             \
        oi=bond3,ov=143.46.43.5,on=255.255.255.0

L’option -p favored -h rac1 donne la stratégie de placement de la ressource, ici de préférence sur le noeud rac1.

L’option -a précise le script permettant le contrôle  de la ressource (start|stop|status). Dans le cadre d’une adresse vip, celui-ci (usrvip) est fourni par Oracle dans la distribution.

L’option -o oi=bond3,ov=143.46.43.5,on=255.255.255.0 donne les spécifications réseaux : oi, interface sur laquelle démarrée l’adresse, ov=adresse IP, on, le masque de sous-réseau

La commande crs_profile ne fait pas autre chose que de créer un fichier de configuration nommé admin-vip.cab sous le répertoire $ORA_CRS_HOME/crs/profile

Enregistrement de la ressource dans l’OCR  par la commande suivante :

$ORA_CRS_HOME/bin/crs_register admin-vip

A partir de ce moment,  la ressource est visible par la commande crs_stat ;  par contre pour qu’elle puisse être controlée par l’utilisateur oracle, il faut donner à cet utilisateur les droits correspondant :

$ORA_CRS_HOME/bin/crs_setperm admin-vip -o root
$ORA_CRS_HOME/bin/crs_setperm admin-vip -u user:oracle:r-x

On peut alors démarrer la ressource depuis le compte oracle et vérifier que cela fonctionne :

$crs_start admin-vip
$crsstat

Name       Type             Target       State        Host
----------------------------------------------------------
admin-vip  application      ONLINE       ONLINE       rac1

On peut aussi réaliser une commande ping sur l’adresse 143.46.43.5 et une commande ifconfig -a pour voir si l’adresse est bien reliée à l’interface bond3.

2 Création de la ressource listener

Pour ce type de ressource le script de contrôle n’est pas fourni dans la distribution mais on peut en trouver des modèles sur le web par exemple ici.

En voici aussi un exemple (modifier les chemins pour ORA_CRS_HOME, ORACLE_HOME suivant votre propre configuration ):

#! /bin/bash
export ORA_CRS_HOME=/opt/CRS
export ORACLE_HOME=/opt/oracle/product/11.1.0/db_1
export PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/sbin:
export PATH=$PATH:$ORA_CRS_HOME/bin:$ORACLE_HOME/bin
export LOGDIR=$ORA_CRS_HOME/crs
export LOGFILE=$LOGDIR/lsnrsrv.log
Reload () {
su oracle -c "export ORACLE_HOME=/opt/oracle/product/11.1.0/db_1;\
 $ORACLE_HOME/bin/lsnrctl reload $1"
}

Start() {
su oracle -c "export ORACLE_HOME=/opt/oracle/product/11.1.0/db_1;\
 $ORACLE_HOME/bin/lsnrctl start $1"
}

Stop () {
su oracle -c "export ORACLE_HOME=/opt/oracle/product/11.1.0/db_1;\
 $ORACLE_HOME/bin/lsnrctl stop $1"
}

Kill() {
PID=`ps -eaf|grep tns| grep -v grep|grep remote|awk '{ print $2; }'`
kill -9 $PID
return 0
}

Check() {
ps -eaf | grep tns | grep -v grep | grep -i " ${1} " && return 0
return 1
}

[ $# -eq 1 ] || exit 1
#env > /tmp/env.log
LISTENER=`basename "$_CAA_NAME" .lsn`
[ "$LISTENER" = "" ] && {
echo `date +'%d/%m/%y %T'`  invalid LISTENER NAME #>> $LOGFILE
exit 1
}

case $1 in
reload)         Reload $2;;
check)  Check $LISTENER
status=$?
exit $status
;;
start)  Start $LISTENER
Check $LISTENER
status=$?
exit $status
;;
stop)   status=0
Stop $LISTENER
Check $LISTENER
[ $? -eq 0 ] || Kill $LISTENER
exit $status
;;
*)      exit 1
esac

Ce fichier que j’ai nommé lsnrsrv.sh est à diffuser sur tous les noeuds du RAC, je l’ai mis pour ma part sous le répertoire /usr/local/bin

De même il faut définir une déclaration identique pour le listener LSNR_ADM dans les fichier listener.ora des deux noeuds :

LSNR_ADM =
   (DESCRIPTION_LIST =
      (DESCRIPTION =
         (ADDRESS = (PROTOCOL = TCP)(HOST = rac-adm)(PORT = 1523))
      )
   )

Création du  profile de la ressource lsnr_adm.lsn par l’utilisateur root (attention le nom de la ressource est utilisé pour définir le nom du listener dans le script de contrôle):

$ORA_CRS_HOME/bin/crs_profile -create lsnr_adm.lsn \
        -t application -r adm-vip -p favored       \
        -h rac1 -a /usr/local/bin/lsnrsrv.sh       \
        -o ci=30,ra=3

L’option -r précise la dépendance avec la ressource adm-vip (pas de démarrage si cette ressource n’est pas présente)

L’option -p favored -h rac1 précise la même stratégie de placement que pour la ressource adm-vip (démarrage de préférence sur le noeud rac1)

l’option -o ci=30,ra=3 définie les critéres de surveillance, ci=30 (check interval)  test de validité toutes les 30 secondes, ra=3 (restart attempt) nombre d’essai de redémarrage avant déplacement vers un autre noeud

Enregistrement et mise en place des droits sur la ressource

$ORA_CRS_HOME/bin/crs_register lsnr_adm.lsn

$ORA_CRS_HOME/bin/crs_setperm lsnr_adm.lsn -o root

$ORA_CRS_HOME/bin/crs_setperm lsnr_adm.lsn -u user:oracle:r-x

Démarrage du listener (donc de la ressource lsnr_adm.lsn) par le compte oracle

$crs_start lsnr_adm.lsn

Vérification par la commande crsstat

Name           Type             Target       State        Host
--------------------------------------------------------------
admin-vip      application      ONLINE       ONLINE       rac1
lsnr_adm.lsn   application      ONLINE       ONLINE       rac1

Ou par la commande standard sur le listenerdepuis rac1

$lsnrctl status lsnr_adm

En cas d’arrêt du noeud rac1, on constate bien la bascule de l’adresse vip et du listener LSNR_ADM vers le noeud rac2

commande crsstat depuis rac2, après arrêt de rac1  :

Name           Type             Target       State        Host
--------------------------------------------------------------
admin-vip      application      ONLINE       ONLINE       rac2
lsnr_adm.lsn   application      ONLINE       ONLINE       rac2

Attention quand le noeud rac1 revient les ressources admin-vip et lsnr_admin.lsn ne rebasculent pas automatiquement vers celui-ci, il faut utiliser une série de commande  crs_relocate (voir la documentation)

Si on veut changer cela il faut changer l’option ACTIVE_PLACEMENT des ressources (mettre pour cela la valeur à 1 -o ap=1)

A ce stade nous avons donc bien un listener dédié pour nos administrateurs mais celui-ci n’est pour l’instant à l’écoute d’aucune base de données; pour cela il faut que chacune des instances présentent s’enregistrent auprès de ce listener.

3 Configuration des instances et du réseau Net Oracle

Le paramètre remote_listener des instances est normalement déja configuré avec une valeur de type LSNR_REMOTE correspondant à la déclaration suivante dans les fichiers tnsnames.ora sous $ORACLE_HOME/network/admin de chaque noeud :

LSNR_REMOTE =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
   )

Les instances s’enregistrant ainsi au listener standard sur  le port 1521 des adresses vip.

Pour que les instances s’enregistrent aussi sur notre listener d’administration il suffit donc d’en ajouter la description dans la liste :

LSNR_REMOTE =
(DESCRIPTION =
   (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
   (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
   (ADDRESS = (PROTOCOL = TCP)(HOST = rac-adm)(PORT = 1523))
)

Puis de déclencher l’enregistrement du process PMON vers les listeners:

SQL>ALTER SYSTEM REGISTER ;

Voila vous disposez maintenant d’un listener dédié pour toutes vos opérations d’administration sur un réseau complètement indépendant des accès applicatifs.

La couche clusterware d’Oracle possède vraiment tous les outils d’un vrai cluster et peut être utilisé à ce titre pour une utilisation dans un mode Actif/Passif de toutes applications à conditions de posséder le bon script de controle (celui que le cluster utilise pour tester, démarrer et arrêter l’application). Je réserve d’autres post pour quelques exemples, en attendant n’hésitez pas à me faire part de vos remarques ou questions.