Prenons comme hypothèse de travail un cluster 3 nœuds sous Linux. Imaginons maintenant qu’une panne sérieuse, nécessitant un arrêt prolongé survienne sur un de ces serveurs et qu’il faille le remplacer.
Je dis bien le remplacer, donc un nouveau serveur avec le même nom et les mêmes adresses IP et non pas ajouter un nouveau serveur pour retrouver la puissance initiale.
Je vous propose de suivre la procédure suivante.
Première étape : nettoyage des références du serveur sorti du cluster
Imaginons que nous ayons perdu le serveur ayant pour nom « noeud006 ».
Sur un des serveurs survivants, en tant que root, une fois l’environnement grid infrastructure positionné, supprimez le serveur noeud006 du clusterware.
crsctl delete node -n noeud006
Dé-configurez de la VIP sur le serveur en panne
/u01/grid/11.2/bin/srvctl remove vip -i noeud006-vip -f
Suite à la perte du serveur, la VIP s’est déplacée sur un des serveurs survivants. Une fois celui-ci localisé, en tant que root, identifiiez l’interface réseau supportant la VIP à l’aide de la commande ifconfig et arrêtez l’interface réseau.
ifconfig bond0:3 down
Sur un des serveurs survivants, on met maintenant à jour l’inventaire en supprimant le nœud en panne des différents ORACLE_HOME où il est référencé.
Sous le user grid
./runInstaller -updateNodeList ORACLE_HOME=Grid_home "CLUSTER_NODES={noeud002,noeud004}" CRS=TRUE
Sous oracle, pour chaque version de noyau base de données installé :
./runInstaller -updateNodeList ORACLE_HOME=db_home "CLUSTER_NODES={noeud002,noeud004}" CRS=TRUE
A ce stade, nous avons supprimé toutes références du serveur dans le clusterware. Les instances de base de données qui étaient installées sur le serveur en panne sont toujours définies et attachées à ce serveur.
Seconde étape : ré-insertion du nœud dans le cluster
Une fois l’OS installé sur le nouveau serveur,
la configuration réseau en place, identique au serveur en panne,
le zoning SAN fait et les disques présentés,
on refait la configuration ASM.
En tant que root, vérifiez l’installation de cvudisk
rpm -qa cvuqdisk
S’il n’est pas installé, installez cvudisk
CVUQDISK_GRP=oinstall; export CVUQDISK_GRP rpm -iv cvuqdisk-1.0.9-1.rpm
- Effectuez la configuration ASM
assurez-vous de la présence des disques
vérifiez l’installation des packages asmlib
sous le user root , lancez la commande
rpm -qa | grep oracleasm
si les packages ne sont pas installés, procédez à l’installation puis lancez la configuration de ASM
Lancez l’initialisation de Asmlib avec la commande suivante :
/usr/sbin/oracleasm configure -i
Et saisir les valeurs suivantes :
This will configure the on-boot properties of the Oracle ASM library
driver. The following questions will determine whether the driver is
loaded on boot and what permissions it will have. The current values
will be shown in brackets ('[]'). Hitting <ENTER> without typing an
answer will keep that current value. Ctrl-C will abort.
Default user to own the driver interface []: grid
Default group to own the driver interface []:asmadmin
Start Oracle ASM library driver on boot (y/n) [n]: y
Scan for Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration: done
Cette procédure crée le fichier suivant /etc/sysconfig/oracleasm.
Pour accélérer la séquence de boot en évitant de scanner des disques ne supportant pas d’ASM, modifiez le fichier /etc/sysconfig/oracleasm de la façon suivante :
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning ORACLEASM_SCANORDER="mapper" # ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan ORACLEASM_SCANEXCLUDE="oracleasm sd"
Une fois les modifications effectuées, lancez les commandes suivantes :
arrêt du process oracleasm
oracleasm exit
démarrage du process oracleasm
oracleasm init
recherche des disques asm connus des autres nœuds du cluster
oracleasm scandisks
- Contrôlez que le propriétaire de ORACLE_BASE est bien grid:oinstall
- Contrôlez l’échange des clefs ssh et la disparition du finger print
Sur le nouveau serveur en tant que user grid
ssh-keygen -t dsa cd .ssh ssh-copy-id -i id_dsa.pub grid@noeud004 ssh-copy-id -i id_dsa.pub grid@noeud002 ssh-copy-id -i id_dsa.pub grid@noeud006 ssh noeud002 ssh noeud004 ssh noeud006 ssh noeud002-priv ssh noeud004-priv ssh noeud006-priv ssh noeud006-vip ssh noeud002-vip ssh noeud002-priv.fq.dn ssh noeud004-priv.fq.dn ssh noeud006-priv.fq.dn ssh noeud002-vip.fq.dn ssh noeud006-vip.fq.dn ssh noeud002.fq.dn ssh noeud004.fq.dn ssh noeud006.fq.dn
Sur le nouveau serveur en tant que user oracle
ssh-keygen -t dsa cd .ssh ssh-copy-id -i id_dsa.pub oracle@noeud004 ssh-copy-id -i id_dsa.pub oracle@noeud002 ssh-copy-id -i id_dsa.pub oracle@noeud006 ssh noeud002 ssh noeud004 ssh noeud006 ssh noeud002-priv ssh noeud004-priv ssh noeud006-priv ssh noeud006-vip ssh noeud002-vip ssh noeud002-priv.fq.dn ssh noeud004-priv.fq.dn ssh noeud006-priv.fq.dn ssh noeud002-vip.fq.dn ssh noeud006-vip.fq.dn ssh noeud002.fq.dn ssh noeud004.fq.dn ssh noeud006.fq.dn
- Lancez l’utilitaire clusterverify
Une fois les prérequis contrôlés, sur un des serveurs survivants lancer la commande clusterverify en tant que user grid.
cluvfy stage -pre nodeadd -n noeud006 -verbose
Effectuez les corrections éventuelles puis, une fois que clusterverify retourne un résultat successful, lancez l’installation de grid infrastructure sur le nouveau nœud avec la commande suivante en tant que user grid :
export ORACLE_SID=${GRID_SID}
export ORAENV_ASK=NO;. oraenv
$ORACLE_HOME/oui/bin/addNode.sh -silent "CLUSTER_NEW_NODES={noeud006}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={noeud006-vip}"
Une fois l’installation terminée, personnellement j’aime bien rebooter le nouveau serveur pour valider que la couche cluster démarre correctement, que tous les disques ASM sont bien présents ainsi que les éventuels montages acfs.
Troisième étape : installation des noyaux de base de données
On peut maintenant réinstaller le ou les noyaux de base de données sur le nouveau serveur.
A partir d’un des serveurs survivants, en tant que user oracle, positionnez l’environnement correspondant au noyau à réinstaller.
puis 2 solutions :
- Soit le noyau est sur un FS partagé; dans ce cas, lancez la commande :
addNode.sh -silent -nocopy "CLUSTER_NEW_NODES={noeud006}"
- Soit le noyau est sur un FS non partagé; dans ce cas la commande est :
addNode.sh -silent "CLUSTER_NEW_NODES={noeud006}"
Il ne vous reste plus qu’à :
réinstaller l’agent oracle si nécessaire,
à refaire la configuration du listener en cas de dataguard ou de spécificités,
à reconstruire les fichiers tnsnames.
