RAC - Fast Application Notification

Hello,
Sauf erreur de ma part, cette fois les jours fériés / pont c'est FINI ! C'était cependant bien sympathique. Ca permet entre autre de lire sur des sujets que l'on a pas forcement eu l'occasion de bosser. Et comme les personnes que je côtoie sont une source infinie d'idées pour lami-dba, voila que tout d'un coup on se retrouve à parler de RAC (Real Application Cluster) et plus précisément ..."Comment être averti que mon RAC ne va pas bien, et plus spécialement... n'aurai je pas par hasard perdu un noeud.."

Normalement on ne perd pas un noeud (quoi que ...). Mais on peut tout simplement avoir un reboot inopiné d'une machine, une éviction de nœud (le fameux "Split Brain",...)

Alors certes, tout le monde dispose de ses outils de monitoring, encore faut-il qu'ils soient bien configurés, qu'ils prennent en compte des spécificités Oracle,...
Mais finalement qui sera le 1er informé que quelque chose est en train de partir au tas... avant même le client ;) qui au final reste le meilleur outil de monitoring ( re ;) )

Oracle a tout prévu.... Avez vous déjà entendu parler de Fast - Application - Notification.

Quoi est ce?

FAN est un mécanisme de notification haute disponibilité qu'Oracle RAC utilise pour notifier les autres processus de la configuration et des informations de niveau de service qui incluent les modifications d'état du service, telles que les événements UP ou DOWN. Les pilotes clients Oracle et les pools de connexions Oracle répondent aux événements FAN et prennent des mesures immédiates. Les événements FAN UP et DOWN peuvent s'appliquer aux instances, services et nœuds.

Maintenant que l'on sait qu'Oracle Communique avec lui même, il serait sympa de pas faire son crevard et de nous tenir également informé !
Nous allons voir que cela n'est pas si sorcier. Il suffit de créer vos scripts "maison" pour alerter qui de droit avec la bonne méthode (sms, mail, pigeon,...) et les déposer à l'emplacement suivant : $GRID_HOME/racg/usrco

Et voila ! le tour est joué. Le ou les scripts s’exécuteront comme des grands à chaque notification.
Je ne vais pas faillir à ma réputation de fainéant, et dans le cas présent, mon script se limitera au script minimum (vous noterez au passage les permissions données au fichier).

[oracle@jumbo usrco]$ ls -lrt
total 8
-rwxr-xr-x 1 oracle oinstall   94 May 22 14:03 callout.sh

[oracle@jumbo usrco]$ cat callout.sh
#!/bin/ksh
umask 022
FAN_LOGFILE=/tmp/callout.log
echo $* "reported="`date` >> $FAN_LOGFILE &
[oracle@jumbo usrco]$

J'avais prévenu... le strict minimum. Dans votre cas, vous y ajouterez peut être un envoi de mail, ou d'autres actions. Petite démonstration... Je vous rappelle ma configuration, une petit cluster de 2 noeuds (jumbo & romeo).

[oracle@jumbo usrco]$
[oracle@jumbo usrco]$ olsnodes -a
jumbo   Hub
romeo   Hub
[oracle@jumbo usrco]$

Pour le moment, tout fonctionne bien sur mon RAC, la preuve en est que le fichier /tmp/callout.log n'existe même pas...
Je vais maintenant simuler un crash de mon serveur...Via VirtualBox, j’éteins ma vM via un bon vieux Power Off (j'espère qu'elle reviendra à la vie ;)).

Mon noeud romeo est donc l'unique survivant de mon RAC... et comme attendu la notification de cet événement a déclenché l’exécution de mon script callout.sh. Ne reste plus qu'à jeter un œil dans les logs.

[oracle@romeo tmp]$ cat callout.log
NODE VERSION=1.0 host=jumbo status=nodedown reason=public_nw_down incarn=0 timestamp=2018-05-22 14:44:46 timezone=+02:00 vip_ips=192.168.1.70 reported=Tue May 22 14:44:47 CEST 2018
NODE VERSION=1.0 host=jumbo status=nodedown reason=member_leave incarn=422448321 timestamp=2018-05-22 14:44:44 timezone=+02:00 reported=Tue May 22 14:44:47 CEST 2018
SERVICEMEMBER VERSION=1.0 service=COMPTA database=lami instance=lami_2 host=romeo status=up reason=FAILURE card=1 timestamp=2018-05-22 14:44:48 timezone=+02:00 db_domain= reported=Tue May 22 14:44:48 CEST 2018
SERVICE VERSION=1.0 service=COMPTA database=lami instance=lami_2 host=romeo status=up reason=FAILURE timestamp=2018-05-22 14:44:48 timezone=+02:00 db_domain= reported=Tue May 22 14:44:48 CEST 2018
[oracle@romeo tmp]$

Nous avons une rafale de notifications concernant le host (jumbo) qui est down & avec forcement l'instance et les services. Ce que nous indique le log

Event_type qui peut prendre une de ces valeurs Node / Instance / Database / ServiceMember / service
Status qui peut prendre la valeur Up / Down / NodeDown / Not_Restarting
Reason qui pourra prendre la valeur USER ou FAILURE. A savoir que mon cas, vu qu'il s'agit d'un power OFF... j'ai évidemment la valeur Failure.
Un horodatage ... bien pratique pour les RCA ;)

Nous aurions pu dans notre script mettre des conditions pour déclencher un sms ou un mail. Typiquement si pour Reason, la valeur est USER, on peut envisager qu'il s'agisse d'une maintenance et donc à priori pas de raison d'alerter la terre entière.
Toujours dans mon exemple, on note que le service COMPTA est maintenant UP sur mon second noeud à savoir romeo.

Remarque : le fait d'avoir une notification que le service soit maintenant up sur romeo sous-entend qu'il ne l'était pas avant mon arrêt brutal.
Why ?
Because !!

[oracle@romeo tmp]$ srvctl config service -db lami -s compta |grep instance
Preferred instances: lami_1
Available instances: lami_2

J'avais volontairement créer ce service "compta" pour qu'il soit de façon préférentiel sur l'instance lami_1 et le cas échéant (en cas de perte de lami_1) sur lami_2. Et c'est bien ce qu'il vient de se passer, et je le prouve ;)

[oracle@romeo tmp]$
[oracle@romeo tmp]$ srvctl status service -db lami -s compta
Service COMPTA is running on instance(s) lami_2
[oracle@romeo tmp]$

Et lorsque l'on a décidé d'implémenter des services avec des affinités sur des nœuds d'un cluster, il peut être intéressant d'être notifié lorsqu'un failover se produit sur le dit service...
Car une fois que le mon serveur jumbo va revenir à la vie, il faudra penser à basculer le service sur son nœud préférentiel;
Il est maintenant temp de rappeler jumbo à la vie ! Let's go ! Je redémarre la VM... et au bout de quelques minutes mon cluster est de nouveau UP avec ses deux noeuds jumbo & romeo.
Je vérifie ce que cela donne pour mon service compta.

[oracle@romeo tmp]$
[oracle@romeo tmp]$ srvctl status service -db lami -s compta
Service COMPTA is running on instance(s) lami_1
[oracle@romeo tmp]$

Etrange ! je n'ai absolument rien fait....et il a rebasculé sur son noeud préférentiel... Je vous aurai donc menti ! Non ca n'est pas le genre de la maison...
En réalité, toujours dans $GRID_HOME/racg/usrco j'ai un autre script ... dont le boulot est justement de vérifier que si un service ne se trouve pas sur un noeud préférentiel, et bien qu'il y retourne !!!!! Dehors vilain !
Je ne détaillerai pas ce script car il n'est pas de moi. On peut le trouver sur le blog de Ilmar Kerm à l url suivante : https://ilmarkerm.eu/blog/2012/05/scipt-to-automatically-move-rac-11gr2-services-back-to-preferred-instances/

Je peux cependant en vérifiant le log sur jumbo.

[oracle@jumbo tmp]$ cat RelocateService.log
Tue May 22 15:07:48 CEST 2018
[lami][jumbo.localdomain] Instance lami_1 up
ORACLE_HOME=/u01/app/oracle/product/12.2.0.1/db_1
Service compta
 enabled
 preferred
 not running on preferred lami_1
 relocate lami_2 -> lami_1
[oracle@jumbo tmp]$

Pas besoin de commentaires... ca parle pour soit.. Mon script callout.sh a également été verbeux pour notifier le retour à la vie de jumbo.

[oracle@jumbo tmp]$ cat callout.log
INSTANCE VERSION=1.0 service=lami database=lami instance=lami_1 host=jumbo status=up reason=BOOT timestamp=2018-05-22 15:07:51 timezone=+02:00 db_domain= reported=Tue May 22 15:07:48 CEST 2018
SERVICEMEMBER VERSION=1.0 service=COMPTA database=lami instance=lami_1 host=jumbo status=up reason=USER card=2 timestamp=2018-05-22 15:08:04 timezone=+02:00 db_domain= reported=Tue May 22 15:08:01 CEST 2018
[oracle@jumbo tmp]$

Tout ceci nous montre que sur des simples notifications du cluster, nous pouvons déclencher toute une série d'action par scripts (vous aurez compris qu'on peut positionner plusieurs scripts). Les possibilités sont multiples, pourquoi ne pas

envisager un démarrage à distance d'une application après un reboot intempestif d'un noeud (certaines appli ne se reconnectant pas automatiquement).
la création automatique de ticket vers le support ou l'astreinte DBA, si l'on prend comme postulat que la perte d'un noeud peut avoir un impact.
Dans la mesure ou l'on peut filtrer sur l'event type, le status ou la reason, tout ceci reste personnalisable à souhait un peut comme le burger de chez FIve Guys ;)

Et pour ceux qui veulent approfondir, je vous invite à lire ce "white Paper" de chez Oracle: http://www.oracle.com/technetwork/database/options/clustering/overview/fastapplicationnotification12c-2538999.pdf

Enjoy !