ASM RAC : installation ASM et cluster

Comme d'habitude se rendre dans le répertoire où le logiciel a été décompressé, ici sur un montage Samba et lancer la commande "./runInstaller.sh" qui démarre l'installeur "OUI". Après quelques contrôles et un certain temps la fenêtre de "OUI" s'ouvre. 
Ouvrir un terminal "root" en ssh sur la machine, cela va servir ! 
  
Ecran 1 "Option d'installation", cocher "Installer ... pour un cluster, comme cela on pourra plus tard tenter le RAC puisque un "cluster" d'une seule machine ne mérite guère son nom ! 

Ecran 2 "Type d'installation", cocher "Installation Standard" 

Ecran 3 : "Configuration du cluster", garder les noms proposés (toute la partie réseau a été préparée pour cela). 
 
a) Il faut identifier les interfaces réseau, "eth0" en "public" et "eth1" en "privé". 
 
b) paramétrer la connexion ssh en la configurant puis en testant 
 

Ecran 4 : "Emplacement d'installation", Il faut (terminal "root" que vous avez déjà ouvert) créer le répertoire "11.2.0" dans /opt et faire un "chown oracle:dba 11.2.0", le rouge de la zone disparait alors par miracle. 
Il faut sélectionner "Automatic Storage Management" pour le "type de stockage...". Il faut aussi donner le mot de passe de "SYSASM" (c'est "dieu le père", l'équivalent du user "SYS" pour la base de données), ne pas perdre ce mot de passe ! Je sélectionne "dba" pour le groupe "OSASM". 

Mon mot de passe n'entre pas dans les règles il me faut donc confirmer, on voit d'ailleurs la zone en jaune sur l'écran. 
Ecran 5 : "Groupes de disque ASM", on ne crée ici que le groupe initial, on l'appelera "DATA" pour rester dans le standard. Cocher la redondance "externe" car un seul disque est réservé (je m'en fous c'est un RAID0 !à. Après avoir "modifié l chemin de repérage" 
 
on voit apparaître notre premier disque, rappelez vous celui réservé sur /dev/hdb1 en dehors de notre future "batterie" de disques. On sélectionne le disque "candidat". 
 

Ecran 6 : "Créer un inventaire", créer (terminal "root") le répertoire "/opt/oraInventory" et executer "chown oracle:dba oraInventory" et faire immédiatement "Suivant". 

Ecran 7 : "Vérification des pré-requis", si rien ne cloche il ne devrait pas y avoir de problèmes et l'écran "Récapitulatif" s'affiche : 

Et on clique "Fin" pour que cette N...! de machine se mette sérieusement à bosser et que je puisse aller déguster mon café : 
 

Enfin arrive le moment des scripts "root" (dans le beau terminal que vous avez ouvert) :

• /opt/oraInventory/orainstRoot.sh
• /opt/11.2.0/grid/root.sh

Le premier est une simple formalité, le deuxième est beaucoup plus importat (et long) car il configure réellement le "cluster".

./orainstRoot.sh 
Modification des droits d'accès de /opt/oraInventory. 
Ajout de droits d'accès en lecture/écriture pour le groupe. 
Suppression des droits d'accès en lecture/écriture/exécution pour le monde. 
Modification du nom de groupe de /opt/oraInventory en oracle. 
L'exécution du script est terminée. Pas bavard et court ! Il n'en pas de même pour le suivant : 
/root.sh 2>&1 | tee ROOT.LOG 
Running Oracle 11g root.sh script... 
The following environment variables are set as: 
    ORACLE_OWNER= oracle 
    ORACLE_HOME=  /opt/11.2.0/grid 
Enter the full pathname of the local bin directory: [/usr/local/bin]:

Après l'appui sur "Entrée" il se passe des choses (prévoir un deuxième café ou une petite promenade) ... la suite du listing en fichier attaché pour information. 
Après appui sur OK c'est reparti : 

pour le final (une minute!).Et c'est l'instant tant attendu : 

Après fermeture de la session X "oracle" il y a 41 processes qui tournent sous le user "oracle" !

L'étape suivante est : une bonne sauvegarde avant d'aller plus loin suivi d'un redémarrage pour vérifier que tout est toujours en place.

Au redémarrage, les disques sont toujjours là (et attribués à "oracle"), et nous pouvons remarquer que la machine est dotée de deux pseudo interfaces réseau supplémentaires et qu'elle répond bien aux noms supplémentaires préparés :

• k2000-ora65-vip 
  ping -c1 k2000-ora65-vip 
  PING k2000-ora65-vip.jpp.fr (192.168.1.150) 56(84) bytes of data. 
  64 bytes from k2000-ora65-vip.jpp.fr (192.168.1.150): icmp_seq=1 ttl=64 time=0.038 ms 
  
  --- k2000-ora65-vip.jpp.fr ping statistics --- 
  1 packets transmitted, 1 received, 0% packet loss, time 0ms 
  rtt min/avg/max/mdev = 0.038/0.038/0.038/0.000 ms
• k2000-o-cluster 
  ping -c1 k2000-o-cluster 
  PING k2000-o-cluster.jpp.fr (192.168.1.151) 56(84) bytes of data. 
  64 bytes from k2000-o-cluster.jpp.fr (192.168.1.151): icmp_seq=1 ttl=64 time=0.041 ms 
  --- k2000-o-cluster.jpp.fr ping statistics --- 
  1 packets transmitted, 1 received, 0% packet loss, time 0ms 
  rtt min/avg/max/mdev = 0.041/0.041/0.041/0.000 ms

Si l'on regarde les interfaces deux pseudo interfaces ont ét créés :

# ifconfig eth0:1 
eth0:1    Link encap:Ethernet  HWaddr 00:16:3E:30:07:01   
          inet adr:192.168.1.151  Bcast:192.168.1.255  Masque:255.255.255.0 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
          Interruption:177 Adresse de base:0x2000 
# ifconfig eth0:2 
eth0:2    Link encap:Ethernet  HWaddr 00:16:3E:30:07:01   
          inet adr:192.168.1.150  Bcast:192.168.1.255  Masque:255.255.255.0 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
          Interruption:177 Adresse de base:0x2000 
..

Tout semble OK pour passer à l'étape suivante : configurer notre jeu de disques ASM pour accueillir en toute sécurité nos bases de données.