Articles autour des SGBD Oracle, SQL Server & PostgreSQL
22 Mai 2018
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 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]$
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 !
/image%2F1471192%2F20180924%2Fob_b16cb7_lamidba2409.jpg)
/image%2F1471192%2F20180605%2Fob_eb592f_kenya288.jpg)
/image%2F1471192%2F20180529%2Fob_53f193_kenya01-234.jpg)
/image%2F1471192%2F20180522%2Fob_1df270_taz01-75.jpg)