You are here

ASM RAC : pré-requis

Le but de cette installation est de tester les possibilités de gestion des espaces disques avec ASM en s'approchant (au point de vue de la structure) de l'architecture d'une machine de production. Il sera ensuite possible de tester les options liées à RAC on installera donc une version "complète" de ASM+grid dès la première machine.

La distribution Linux choisie est celle proposée par Oracle (en plus j'ai une image système complète).

La machine virtuelle.

Les disques.

Notre machine est munie de 10 disques :

  1. système    hda    16Go    système et logiciels
  2. mini    xvda          10Go    disque "primaire" de ASM
  3. data    xvdb..e     4 x 10Go
  4. reco    xvdf..i       4 x 10Go

Le Linux utilisé (en machine virtuelle sous XEN) ne permet pas de reconnaitre plus de 4 disques sur le "contrôleur" IDE, les disques de la BDD seront donc présentés en "xvda . . . xvdh" comme des disques virtuels XEN.

Pour supporter cette architecture 2 processeurs et 3072Mo de mémoire sont attribués à la machine virtuelle, on attendra un peu pour 8 processeurs et 64Go de mémoire je n'ai pas cela en magasin.

 



















Afin que lors du boot de la machine les droits sur les disques soient attribués à notre user "oracle" et au groupe "dba" il faut créer un fichier "/etc/udev/rules.d/99-oracle-rules" qui contiendra pour nous :

# Rules for ASM
KERNEL=="xvda[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"

KERNEL=="xvdb[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"

KERNEL=="xvdc[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"
KERNEL=="xvdd[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"
KERNEL=="xvde[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"
KERNEL=="xvdf[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"
KERNEL=="xvdg[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"
KERNEL=="xvdh[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"
KERNEL=="xvdi[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"


Les disques DATA et RECO seront chacun créés en deux "failure group" distincts de 2 disques chacuns LVM et NFS permettent de simuler ce genre de choses sans disposer d'une "grosse" baie de disques ou d'une énorme caisse permettant de ranger et d'alimenter une telle série de disques) c'est ici bien plus économe en énergie !.

Tous les disques de la série des "xvd.." doivent être partitionnés avec une seule partition que l'on ne formatera même pas.



Les utilisateurs et mots de passe.

Afin de simplifier le système seul l'utlisateur "oracle" sera utilisé pour toutes les installations. Il est créé avec 4 groupes "oracle", "dba", "oinstall" et "oper" pour rester dans les vieux standards.

Les mots de passe des différents administrateurs seront tous les mêmes (ma mémoire défaille) afin de me simplifier les tests, vous avez le droit (et le devoir en prod) d'utiliser une palanquée d'utilisateurs, de mots de passe et de groupes différents (une grosse réflexion est alors nécessaire pour ne pas se retrouver le bec dans l'eau un peu plus tard).

Le réseau.

Notre machine "k2000-ora65" dispose de deux interfaces réseau :

  • 192.168.1.228    k2000-ora65

  • 192.168.3.228    k2000-ora65c

il faut en plus disposer de deux adresses "libres" pour la gestion du RAC et du cluster :

  • 192.168.1.150    pour l'adresse "virtuelle" du cluster (le tout dans une machine vitruelle ...)
  • 192.168.1.151    pour l'adresse "cluster"

Toutes ces adresses doivent être résolues de préférence par un DNS (cela devrait marcher avec un bon fichier "hosts") et il faut éviter d'utiliser le DHCP, il faut donc mettre en place des adresses "statiques" pour les deux interfaces de notre machine.

Les noms et les divers.

La machine ayant été faite à partir d'une image il y a un certain nombre de fichiers à modifier pour s'assurer du bon nom de baptème :

/etc/sysconfig/network:HOSTNAME=......

/etc/sysconfig/networking/profiles/default/network:HOSTNAME=.....

/etc/hosts    à mettre à jour


N'hésitez pas à mettre des noms complets "host.domaine" et des alias "host" dans /etc/hosts puis lancez la commande "hostname mon_bel_host" avant de redémarrer le système.

Il faur reconfigurer le serveur "ntpd" et le lancer, la modification est à réaliser dans le fichier "/etc/sysconfig/ntpd" où il faut modifier les paramètres pour y intégrer un "-x" :

OPTIONS="-u ntp:ntp -x  -p /var/run/ntpd.pid"

Ne pas oublier ensuite d'activer le service en permanence. J'ai aussi remplacé les serveurs de temps par celui que j'entretiens en local en indiquant son adresse IP dans le fichier "/etc/ntp.conf".

Le plan d'action.

  • Préparer tout ce qui figure ci-dessus

  • Faire un reboot

  • Vérifier que tout à "tenu" le reboot

  • Faire une image de sauvegarde

Paré pour la réalisation ... c'est fait, on "reboote".

Après le reboot un petit contrôle en "root" :

ls -al /dev | grep oracle
brw-rw----  1 oracle dba  202,   1 fév 25 15:36 xvda1
brw-rw----  1 oracle dba  202,  17 fév 25 15:36 xvdb1
brw-rw----  1 oracle dba  202,  33 fév 25 15:36 xvdc1
brw-rw----  1 oracle dba  202,  49 fév 25 15:36 xvdd1
brw-rw----  1 oracle dba  202,  65 fév 25 15:36 xvde1
brw-rw----  1 oracle dba  202,  81 fév 25 15:36 xvdf1
brw-rw----  1 oracle dba  202,  97 fév 25 15:36 xvdg1
brw-rw----  1 oracle dba  202, 113 fév 25 15:36 xvdh1

brw-rw----  1 oracle dba  202, 129 fév 25 15:36 xvdi1

Tout est bien de ce coté, voyons la résolution de noms :

host k2000-ora65
k2000-ora65.jpp.fr has address 192.168.1.228
# host k2000-ora65c
k2000-ora65c.jpp2.fr has address 192.168.3.228
# host k2000-ora65-vip
k2000-ora65-vip.jpp.fr has address 192.168.1.150
# host k2000-o-cluster
k2000-o-cluster.jpp.fr has address 192.168.1.151


C'est OK, vérifions que notre "ntpd" est présent :

ps -ef | grep ntpd

ntp       5078     1  0 15:34 ?        00:00:00 ntpd -u ntp:ntp -x -p /var/run/ntpd.pid




Tout est parfait, on va pouvoir tenter l'installation ... dans le prochain chapitre.