Version du 11 février 2011 à 10:26

Sommaire

1 Composants de RAC
2 Principes
- 2.1 Sur les noeuds du cluster
- 2.2 Sur les clients

Composants de RAC

Dans le cadre d’un cluster RAC, la couche cluster peut être gérée par une couche logicielle provenant de fournisseurs tiers :

Sun Cluster
IBM HACMP
Veritas Cluster ...

Oracle fournit sa propre couche cluster dénommée Cluster Ready Services ou CRS (ClusterWare depuis la version 10g)

Les processus principaux

L’ensemble de processus constituant le CRS est composé :

de 3 processus d’arrière plans (CRS, CSS et EVM)
d’un ensemble de processus supplémentaires gérant la communication avec les autres couches du cluster (Base de données, applications etc.)

NB : Sous Windows, les processus sont des threads rattachés au processus oracle.exe.

le processus CRS

Le processus CRS (CRS pour Cluster Ready Services) est la brique maîtresse du clusterWare Oracle. C’est ce processus qui gère les opérations de haute disponibilité dans le cluster. Le CRS gère l’ensemble des applications intégrées au cluster (Database, instance, service, listener etc.) définies et référencées dans l’OCR (cf définition plus loin).

Le CRS détecte les changements d’états de ressources. C’est le processus CRS qui redémarre automatiquement les ressources en cas de faute. Et ce, si la définition de la ressource dans l’OCR l’en autorise.

Ce processus est propriété de l’utilisateur root.
Son démarrage est piloté dans l’inittab du serveur par des scripts d’init.
Il redémarre automatiquement en cas d’arrêt.
Sous unix, il apparait dans la liste des processus sous le nom : crsd.bin

Par défaut, les fichiers de journaux et de trace de ce processus sont stockés dans : $CRS_HOME/log/$HOSTNAME/crsd/crsd.log

le processus CSS

Le processus CSS (CSS pour Cluster Synchronisation Services) gère la configuration du cluster dans l’évolution de l’appartenance (et de la non-appartenance) des noeuds au cluster.

C’est ce processus qui informe les autres noeuds la présence de nouveau noeud, ou du retrait d’anciens noeuds.

Ce processus est propriété de l’utilisateur oracle
Son démarrage est piloté dans l’inittab du serveur par des scripts d’init.
Son arrêt inopiné engendre le redémarrage du noeud.
Sous unix, il apparait dans la liste des processus sous le nom : ocssd.bin

Par défaut, les fichiers de journaux et de trace de ce processus sont stockés dans : $CRS_HOME/log/$HOSTNAME/cssd/ocssd.log

le processus EVM

Le processus EVM (EVM pour EVent Management) enregistre tous les événements enregistrés dans le cluster. Ce processus va publier les événements que le CRS génère. Pour cela, il va enregistrer ces événements dans le répertoire du logger ($CRS_HOME/evm/log) et exécuter (via le processus evmlogger, fils du processus evmd) les appels demandés.

Ce processus est propriété de l’utilisateur oracle
Son démarrage est piloté dans l’inittab du serveur par des scripts d’init.
Sous unix, il apparait dans la liste des processus sous le nom : evmd.bin.

Par défaut, les fichiers de journaux et de trace de ce processus sont stockés dans : $CRS_HOME/log/$HOSTNAME/evmd/log/evmd.log

Les fichiers d’événements sont dans $CRS_HOME/evm/log

Les processus annexes

OPROCD

Oprocd est un processus résident en mémoire. Ce processus surveille le cluster et réalise le "fencing" du cluster, (le Fencing est un isolement primitif d’un noeud lors d’une défaillance de celui-ci.). Lors de ce fencing, oprocd effectue des vérifications de fonctionnement, puis se fige. Si le reveil de l’OProcd n’a pas lieu avant une durée configurée, celui-ci procède au redémarrage du noeud du cluster.

RACG

Les processus RACG étendent le fonctionnement du clusterWare aux besoins des produits Oracle.

ONS (Oracle Notification Service)

ONS est un service simple fonctionnement en PUSH permettant la diffusion de message à tous les noeuds du cluster.

Les fichiers ou disques de gestion

le registre du cluster ou Oracle Cluster Registry ou OCR

Le registre du cluster ou OCR est un fichier ou disque partagé du cluster qu’il convient de sécuriser (réplication baie, multiplexage).

Cet OCR contient la définition des éléments constitutifs du cluster ainsi que leur état.

On y trouvera entre autres : la définition noeuds, les interfaces réseaux, les adresses VIP, les bases de données, la définition et le paramétrage des ressources, leur dépendances etc etc.

Ce fichier est mis à jour automatiquement lorsque l’administrateur utilise les outils de configurations comme srvctl, crs_register, crsctl).

On obtient les informations sur l’OCR par la commande ocrcheck :

# $CRS_HOME/bin/ocrcheck 
Status of Oracle Cluster Registry is as follows : 
       Version                  :          2 
       Total space (kbytes)     :     513652 
       Used space (kbytes)      :       5152 
       Available space (kbytes) :     508500 
       ID                       : 1318599504 
       Device/File Name         : /dev/rdsk/c3t8d0s1 
                                  Device/File integrity check succeeded 
       Device/File Name         : /dev/rdsk/c4t10d0s1 
                                  Device/File integrity check succeeded 

       Cluster registry integrity check succeeded

NB : Lorsqu’on reconfigure un service comme vu dans cet article , on modifie directement les entrées de la ressource définie dans l’OCR

Le disque votant ou Voting Disk

Le disque votant est un périphérique disque partagé permettant de gérer l’appartenance au cluster. De ce fait, il est intimement lié au processus CSS. De plus, il permet les arbitrage d’appartenance au cluster lorsque tous les liens d’interconnexions sont rompus.

On obtient les informations des disques votant avec la commande crsctl :

# $CRS_HOME/bin/crsctl query  css votedisk 
0.     0    /dev/rdsk/c3t8d0s3 
1.     0    /dev/rdsk/c4t10d0s3 
2.     0    /dev/rdsk/c3t9d0s3 

located 3 votedisk(s).

Il est recommandé de multiplexer de manière impaire le disque votant. Si il est unique, alors la redondance du support devra être assurée (par une baie, ou tout autre mécanisme).

Sa taille est d’environ 50Mo par fichier.

Principes

Sur les noeuds du cluster

Certains éléments sont spécifiques à chaque noeud du cluster, d'autres son partagés par tous.

Stockage

Les noeuds (2 ou plus) disposent chacun, individuellement, des binaires Oracle, ainsi que des fichiers d'initialisation (PFILE ou SPFILE selon la configuration de départ).

Tous les noeuds partagent les disques OCR et Voting Disk. Ils partagent également les disques de données (où sont stockés les fichiers des bases en cluster).

Adresses réseau

Chaque serveur dispose de 3 adresses réseau : Une adresse publique sur le réseau local, utilisée pour accéder à la machine en dehors d'Oracle Une adresse virtuelle (VIP), dans la même plage d'adresse du réseau local, initialisée par Oracle lorsque le cluster démarre, utilisée par les clients Oracle pour accéder aux bases en RAC (cf plus bas configuration des clients) Une adresse privée, dédiée au lien entre les noeuds du cluster. Cette adresse est dans une plage non utilisée sur le réseau local ; le lien peut passer par le réseau (non conseillé) ou être un lien croisé (entre deux noeuds) ou un « mini »-réseau dédié entre plusieurs noeuds.

Listeners

Deux modes sont disponibles, sans être exclusifs (les deux peuvent être activés simultanément) :

FAILOVER (TAF : Transparent Application Failover)

Oracle RAC propose le FAILOVER en configurant un listener par noeud du cluster afin de gérer les requêtes de connexion à un même service (un service représente une base de données enregistrée auprès des listener du cluster). Si un noeud ou une interconnexion échoue, l'adresse IP virtuelle (VIP) est réallouée à un noeud survivant, permettant la notification de panne rapide aux clients connectés par cette VIP. Si le client (ET l'application) sont compatibles et configurés pour le TAF, le client est reconnecté à un noeud actif.

LOAD BALANCING

Oracle RAC propose l'équilibrage de charge en distribuant les connexions entre les DISPATCHERS des noeuds du cluster, qui eux-même répartissent ces requêtes sur les instances des bases en cluster des noeuds les moins chargés.

Plusieurs LISTENER sont donc déclarés, au moins un par noeud. Chaque noeud connait son propre LISTENER et les LISTENER des autres noeuds. Exemple de configuration sur le premier noeud d'un cluster :

LISTENER_RAC1= 
 (DESCRIPTION_LIST =
 (DESCRIPTION= 
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521)(IP = FIRST))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521)(IP = FIRST)))
SID_LIST_LISTENER_RAC1= 
  (SID_LIST= 
    (SID_DESC= 
      (SID_NAME=) 
      (ORACLE_HOME=/u01/app/oracle/11/db_1)

Il en va de même pour les clients.

Sur les clients

Le tableau suivant résume les options disponibles pour le TNSNAMES.ORA (le client doit obligatoirement être en version 10g minimum).

Option	Parameter Setting
Try each address, in order, until one succeeds	FAILOVER=on
Try each address, randomly, until one succeeds Note: This option is not enabled if Use Options Compatible with Net8 8.0 Clients is selected in Oracle Net Manager.	LOAD_BALANCE=on FAILOVER=on
Try one address, selected at random Note: This option is not enabled if Use Options Compatible with Net8 8.0 Clients is selected in Oracle Net Manager.	LOAD_BALANCE=on
Use each address in order until destination reached	SOURCE_ROUTE=on
Use only the first address Note: This option is not enabled if Use Options Compatible with Net8 8.0 Clients is selected in Oracle Net Manager.	LOAD_BALANCE=off FAILOVER=off SOURCE_ROUTE=off

2.2.1  TAF (Transparent Application Failover)

Exemples de configuration (source : http://download.oracle.com/docs/cd/B28359_01/network.111/b28316/advcfg.htm) : Example: TAF with Connect-Time Failover and Client Load Balancing Implement TAF with connect-time failover and client load balancing for multiple addresses. In the following example, Oracle Net connects randomly to one of the protocol addresses on sales1-server or sales2-server. If the instance fails after the connection, the TAF application fails over to the other node's listener, reserving any SELECT statements in progress. sales.us.example.com=

(DESCRIPTION=
 (LOAD_BALANCE=on) 
 (FAILOVER=on) 
 (ADDRESS=
      (PROTOCOL=tcp)  
      (HOST=sales1-server)  
      (PORT=1521)) 
 (ADDRESS=
      (PROTOCOL=tcp)  
      (HOST=sales2-server)  
      (PORT=1521)) 
 (CONNECT_DATA=
    (SERVICE_NAME=sales.us.example.com) 
    (FAILOVER_MODE=
      (TYPE=select) 
      (METHOD=basic))))

13.3.5.2 Example: TAF Retrying a Connection TAF also provides the ability to automatically retry connecting if the first connection attempt fails with the RETRIES and DELAY parameters. In the following example, Oracle Net tries to reconnect to the listener on sales1-server. If the failover connection fails, Oracle Net waits 15 seconds before trying to reconnect again. Oracle Net attempts to reconnect up to 20 times. sales.us.example.com=

(DESCRIPTION=
 (ADDRESS=
      (PROTOCOL=tcp)  
      (HOST=sales1-server)  
      (PORT=1521)) 
 (CONNECT_DATA=
    (SERVICE_NAME=sales.us.example.com) 
    (FAILOVER_MODE=
      (TYPE=select) 
      (METHOD=basic)
      (RETRIES=20)
      (DELAY=15))))

13.3.5.3 Example: TAF Pre-Establishing a Connection A backup connection can be pre-established. The initial and backup connections must be explicitly specified. In the following example, clients that use net service name sales1.us.example.com to connect to the listener on sales1-server are also preconnected to sales2-server. If sales1-server fails after the connection, Oracle Net fails over to sales2-server, preserving any SELECTstatements in progress. Likewise, Oracle Net preconnects to sales1-server for those clients that use sales2.us.example.com to connect to the listener on sales2-server. sales1.us.example.com=

(DESCRIPTION=
 (ADDRESS=
      (PROTOCOL=tcp)  
      (HOST=sales1-server)  
      (PORT=1521)) 
 (CONNECT_DATA=
    (SERVICE_NAME=sales.us.example.com) 
    (INSTANCE_NAME=sales1) 
    (FAILOVER_MODE=
      (BACKUP=sales2.us.example.com) 
      (TYPE=select) 
      (METHOD=preconnect))))

sales2.us.example.com=

(DESCRIPTION=
 (ADDRESS=
      (PROTOCOL=tcp)  
      (HOST=sales2-server)  
      (PORT=1521)) 
 (CONNECT_DATA=
    (SERVICE_NAME=sales.us.example.com) 
    (INSTANCE_NAME=sales2)
    (FAILOVER_MODE=
      (BACKUP=sales1.us.example.com) 
      (TYPE=select) 
      (METHOD=preconnect))))
2.2.2  LOAD BALANCING

Exemples de configuration (même source que ci-dessus) : The following example shows a TNSNAMES.ORA file configured for client load balancing: sales.us.example.com=

(DESCRIPTION=
 (ADDRESS_LIST=
 (LOAD_BALANCE=on)
  (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) 
  (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521)))
 (CONNECT_DATA=
   (SERVICE_NAME=sales.us.example.com)))

The following example shows a tnsnames.ora file configured for connect-time failover: sales.us.example.com=

(DESCRIPTION=
 (ADDRESS_LIST=
  (LOAD_BALANCE=off)
  (FAILOVER=ON)
  (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) 
  (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521)))
 (CONNECT_DATA=(SERVICE_NAME=sales.us.example.com)))
3  Installation

L'installation sera documentée avec les éléments suivants : 2 noeuds dans le cluster (« rac1 » et « rac2 »), serveur 64 bits chaque noeud est un serveur sous Linux CentOS 5 x86_64 le cluster est géré par Clusterware d'Oracle 10g ils disposent chacun d'un disque interne, et de 4 disques partagés par des liens fibre Les disques partagés sont gérés par ASM (Automatique Storage Management) d'Oracle, au dessus de partitions RAW DEVICE. les réseau publiques et VIP sont dans la plage 10.1.86 le réseau privé est dans la plage 192.168.1 On se connectera « root » dans un premier temps pour paramétrer le système.

IMPORTANT : CentOS n'étant pas officiellement reconnu par Oracle, il faut « faire passer » le système pour un RedHat. Editer le fichier /etc/redhat-release et remplacer le contenu par « redhat-4 » sur tous les noeuds du futur cluster.

3.1  Obtenir les logiciels

Les logiciels suivants seront utilisés : Oracle 10g (10.2.0.1) CRS (10201_clusterware_linux_x86_64.zip) Oracle DB software (10201_database_linux_x86_64.zip) Oracle patch upgrade to 10.2.0.4 (p6810189) Clusterware et Oracle Database seront donc en version 10.2.0.4 à la fin de l'installation. IMPORTANT : S'assurer qu'on dispose des versions correspondant au système : 32 ou 64 bits !

3.2  Configurer les disques partagés

Les disques partagés sont gérés sur les deux serveurs par les outils MULTIPATH compatibles avec les liens fibres multiples. Après différents tests, la procédure correcte de configuration est la suivante. Vérifier que les disques sont visibles sur les 2 serveurs. Commande multipath sur le noeud 1 :

multipath -ll

mpath3 (36006016009c12200a2307179ff5cdf11) dm-10 DGC,RAID 5 [size=20G][features=1 queue_if_no_path][hwhandler=1 emc][rw] \_ round-robin 0 [prio=2][active]

\_ 2:0:1:3 sdj 8:144  [active][ready] 
\_ 3:0:1:3 sdv 65:80  [active][ready]