Un de nos environnements RAC est géré par GridApp Clarity. En subtance il s’agit d’une solution qui masque la complexité liée à la gestion de RAC (C’est pas moi qui le dit !) et permet aux moins initiés après 3 ou 4 clics d’ajouter ou de retirer des noeuds comme à la fête.

Toujours est-il que la nuit dernière, j’ai vu pour la première fois et sans que j’intervienne, la chose suivante arriver sur un vrai environnement et production et hautement disponible :

• Nous avions 3 clusters de 2 noeuds :
• La production
• La qualif
• Le développement
• Le responsable de la production a clique sur les 3/4 boutons de son interface web
• 2’30 minutes plus tard nous avions :
• la production : 4 noeuds
• La qualif : 1 noeud
• Le dév : 1 noeud

Le tout avec 0 downtime ! Je ne vous dis pas d’acheter ce produit mais je vais vous expliquer l’excellente idée, « Behind the scene », pour réaliser ce petit exploit ; Avant d’entrer dans le détail :

• Je vous rassure, les DBA (et moi par la même occasion 😉 ), ça n’a pas fonctionné du premier coup et comme le produit repose entièrement sur les procédures standards (runInstaller, dbca, netca…), il y a encore quelques limitations et notamment pour gérer les mises à jour et les standby
• Pourquoi ça répond à un vrai besoin ?
• Les systèmes ont toujours des cycles de vie et production, qualif et développement ne sont jamais à plein régime en même temps. Ça peut être n’importe quoi comme le lancement de la saison de foot américain, par exemple (c’est dans 4 heures !). Et même si une activité n’est pas saisonnière, quand une application ou une nouvelle fonctionnalité passe en production il est extrêmement peu probable que la qualif fonctionne à plein régime non ?
• Les machines virtuelles (vmware, etc) ne sont pas compatibles avec le fonctionnement de RAC en production : croyez-le ou faites-en l’expérience ! Et quand elles le sont (dlpar, etc), elles sont incompatibles avec ma vision de l’intérêt de RAC
• Enfin, la seule manière réaliste de s’en sortir à laquelle j’avais pensé jusqu’à présent [étroitesse d’esprit ?] pour adresser ce besoin de déplacer les machines en fonction de l’activité, c’était d’avoir un seul cluster et d’arrêter et redémarrer les instances en fonction des besoins sur les différents noeuds. Supprimer un noeud, même avec GridControl en 10g demande un effort trop important pour imaginer l’utiliser au quotidien ! Ça pourrait être une bonne idée sauf que vous allez mixer prod, qualif et dev, même si ce n’est le clusterware, ça n’a jamais enthousiasmé que moi, je crois.

Bon alors comment ils font ? En fait rien d’exceptionnel et c’est ça que j’adore !

• Prenez un ensemble de serveurs sur lesquels vous installez les mêmes systèmes d’exploitation/patchs… leurs serveurs ont des caractéristiques semblables, Vous pouvez également en prendre de 3 à 20000 ;
• Disons que vous vouliez installer un cluster 2 noeuds… Installez le clusterware, le logiciel de base de données et créez la base de données sur plus de noeuds ; disons 3 en mettant chaque logiciel sur un stockage externe pour pouvoir changez facilement le logiciel d’un serveur à un autre. Avant de faire cette installation, changez le nom de chaque machine pour qu’il soit cohérent avec votre nom de cluster ; par exemple les machines se nommeront prod1,prod2,prod3 lorsqu’elles feront partie de votre cluster de production. Avoir des noms différents pour la même machine permet d’éviter par la suite de confondre les machines lorsqu’elles se déplacent d’un cluster à l’autre. Ça permet également de « transporter » le clusterware d’un serveur a l’autre sans refaire l’installation.
• Comme vous vouliez que 2 noeuds, vous allez désactiver un noeud, c’est à dire :
• stoppez tous les composants oracle et cluster
• démonter tous les systèmes de fichiers externes qui contiennent les logiciels et l’inventory
• conserver et enlevez de la machine tous les fichiers oracle qui ne sont pas dans l’arborescence de notre logiciel comme :
• /etc/oratab. /etc/orainst.loc, /etc/oracle/*, /etc/inittab, /etc/init.d/init.crs… et j’en oublie
• les fichiez permettant de créer l’equivalence ssh pour Oracle
• Désactivez la configuration réseau et /etc/hosts
• Renommez la machine avec son nom d’origine. La machine est de nouveau vierge d’Oracle et peut faire parti d’un autre cluster
• Activez le noeud 3 du cluster de nouveau devient simple et peut être effectué avec n’importe quel autre serveur ayant les mêmes caractéristiques ou presque
• Changez le nom du serveur selon le nom du noeud du cluster
• Poussez tous les fichiers sur ce serveur qui ne sont pas dans le répertoire des logiciels et de l’inventory Oracle,
• Montez les systèmes de fichiers
• Démarrez clusterware et instance de base de données.
• Le tout, si c’est scripté, en 3 minutes
• Il est toujours possible d’ajouter un noeud si jamais vous aviez prévu trop court au départ avec runInstaller, dbca…
• Cerise sur le gâteau… Si vous avez la possibilité d’activer désactivez un noeud, le jour ou vous perdez une machine de notre RAC, vous pouvez la réactiver sur un autre serveur en 3 minutes aussi et la capacité de votre RAC n’est pas impactée. Remarquez que ça vous oblige à avoir du spare ou d’utiliser un autre environnement comme la qualif. Si vous n’activez pas tous les noeuds, c’est aussi pour respecter votre contrat de licence, non ?

Comprenons nous bien, je ne suis pas en train de vous conseiller cette solution : pour plein de raisons et d’abord parce que je ne jure que par Oracle. Il n’empêche que, après cette nuit, je regrette que cette approche ne soit pas implémentée dans EM ou que je n’ai pas du temps pour développer mon jeu de script et faire la même chose.

Je vous laisse y réfléchir !

NB : Pour ceux qui voudraient ce lancer dans l’aventure ou si vous réinstallez un clusterware sur la même machine sous Linux ;), supprimez les répertoire /var/tmp/.oracle, /usr/tmp/.oracle et /tmp/.oracle pour que le nouveau clusterware démarre (cf note 315125.1).