Discussion :

[tck-lt]

Bonjour,

je possède l'architecture suivante :
- 2 serveurs sous Linux RHEL 4.8 (Oracle), un actif/un passif (migration RHEL prévue)
- Noyau 10.2.0.4
- Gestion LVM
- 20 instances (chacune sur un VG distinct)
- 2 baies SAN EMC VNX5300 (migration en cours depuis un CX500)

Aujourd'hui, je désirerais monter un cluster Oracle afin de pouvoir faire de la haute dispo. Je ne connais aucune solution particulière, cependant je suppose que la solution RAC proposée par Oracle correspond à mon besoin. Je me pose du coup quelques questions.
RAC est-il inclus dans une Standard Edition (j'ai lu que oui mais pour un "baby RAC") ?
L'utilisation d'ASM est-elle obligatoire ? (je ne l'utilise pas aujourd'hui)
Vaut-il mieux faire de l'actif/passif ou de l'actif/actif ?
Je ne dispose d'aucun miroir aujourd'hui, ni au niveau SAN, ni au niveau LV, qu'est-ce-qui est préconisé pour le RAC svp ?

Merci d'avance à ceux qui prendront le temps de répondre à mes questions.

PS : j'ai attaqué la doc mais en anglais je ne suis pas toujours sûr du sens des phrases à 100%.

[Pomalaix]

En prérequis, il faudrait définir très précisément ce que vous entendez par "haute dispo" : quels scénarios doivent être pris en charge par le mécanisme choisi, qu'il s'agisse de RAC ou autre chose ?

Concernant le RAC, ASM n'est pas obligatoire mais vivement conseillé, puisqu'il vous permet d'avoir des données accessibles simultanément par les différents noeuds du RAC, sans recours à un autre système de fichiers spécialisé.

De plus ASM vous permet de faire l'équivalent d'un RAID logiciel très performant, qui sera bienvenu si vous n'avez pas de RAID matériel intégré.

[ojo77]

De mémoire le RAC en standard edition est limité en nombre de processeur (à 4 selon Donald, le copiste en chef) et ASM est obligatoire et je crois que c'est limité à deux nœuds. Oracle recommande de redonder tout, même le disque, ça peut être fait par ASM.

RAC est par principe Actif / Actif et là, c'est le drame

Je m'explique avant qu'un grincheux fan de RAC ne vienne pourrir mon groove.

RAC est donc actif/actif et je dis que c'est le drame parce que la gestion des blocs est faite par un des deux nœuds (ou plutôt une des deux instances) qui va donc avoir besoin d'un certain nombre de blocs va demander, pour les blocs qu'elle ne gère pas, si l'instance qui les gère peut les lui refiler.
Soit l'instance les a et les lui refile (enfin si ils sont en mode share) soit elle ne les a pas et la première instance va donc charger les bloc depuis le disque, faire son boulot avec et le refiler à l'instance gestionnaire du bloc ...

Au bout 'un moment RAC se dit que tout ce mécanisme est un poil lourd et que si une instance demande tout le temps les mêmes blocs autant lui en donner la gestion, bien sûr tout celà ne se fait pas sans une structure mémoire qui liste les blocs qui ne sont pas gérés par leur instance mère , qu'il faut donc interroger à chaque besoin de bloc ...

La fonction de hashage est active même si un service n'est actif que sur une instance.

Et encore on est en 10g ... en 11 les algos de "ou que j'vais choper mon bloc" se compliquent encore pour gagner en efficacité.

Plus le nombre de bloc est élevé plus cette gestion fini par être coûteuse d'où le fameux drame si on compare à du mono instance sur un cluster en actif/passif qui ne se pose forcément pas toutes ces questions mais qui posent d'autres des problèmes par ailleurs.

En clair mon avis est le suivant : si vous voulez faire de la haute dispos avec Oracle et que vous supportez quelques minutes d'arrêt utilisez plutôt, par ordre de préférence :
- Dataguard
- Un cluster actif passif

Si vous ne pouvez pas supporter la coupure c'est vers RAC qu'il faut aller mais il va falloir tuner les requêtes, ce qui sans AWR est plus compliqué qu'avec, et ne pas lésiner sur l'interconnect

[tck-lt]

Merci pour ces premières réponses très instructives. Je vais affiner mes propos.

Tout d'abord, je peux tout à fait supporter quelques minutes d'arrêt, le temps de la bascule. Je cherche en fait à faire l'équivalent d'un cluster ARF, c'est-à-dire bascule automatique en cas de crash machine et/ou SAN. J'ai besoin de faire un PCA de tous les éléments de la chaine :
- serveur/OS/Noyau Oracle en actif/passif : les 2 serveurs sont identiques sur ces points. J'ai mis en place un script rsync pour la synchronisation de répertoires et/ou configurations
- Instances : les instances tournent sur le serveur actif. Si celui-ci tombe, que dois-je utiliser pour basculer sur l'autre sans corrompre les données ?
- LVM (là je devrais plus me tourner vers le forum Linux) : Quel miroir pour mes vg ?
- Fibres : utilisation du multipathing pour l'accès aux SANs
- LUN : une LUN primaire sur le SAN A et une LUN secondaire sur le SAN B ?
- Disque : tous les disques sont en RAID5

Plus j'avance dans mon descriptif et plus je me dis que ma problématique est plus une problématique Linux/Accès SAN qu'Oracle.

PS : je vais regarder le produit Dataguard en attendant

[tck-lt]

Je vais me diriger vers le forum Linux pour la suite, c'est plus une problématique Linux qu'Oracle finalement. Merci.

PS : je pense en particulier à l'outil OpenSVC