Discussion :

[gabrielfotopoto]

Bonjour à tous,

Nous essayons de parvenir à une continuité de service transparente pour les utilisateurs et de meilleures performances. Dans ce cadre là nous avons opté à la Solution Cluster d'ORACLE. Comme pré-requis nous savions que le SAN était nécessaire, nous avons donc pris 2 SAN EMC AX4.

Donc en résumé, nous avons 2 baies dans 2 locaux distants (une 30aine de mètres) dans lesquelles sont hébergées : un serveur de BDD et un SAN.

Notre DBA a mis en place le Cluster ORACLE. Tout parait fonctionnel, si nous coupons l'un des 2 serveurs, la continuité de service est bien présente. Toutefois, si nous coupons l'un des 2 SAN, tout est HS. Et c'est là que nous bloquons. Notre DBA nous a parlé d'un QUORUM à héberger sur un partage NFS distant, nous l'avons mis en place, mais le problème reste identique.

Nous n'arrivons pas à maintenir de la continuité de service si l'une des 2 Baies tombe...

Mes questions sont :

1. Doit-on revoir de A à Z l'architecture et héberger les SAN hors de nos Baies comprenant nos Serveurs de BDD ?
2. Doit-on revoir la mise en place du RAC dans lequel un ou plusieurs paramètres nous auraient échappés ?
3. Peut-on réellement envisager de la continuité de service en couplant le RAC et 2 SAN ?

[agdid04]

Bonjour,
Est ce que vous avez étudié la combinaison de RAC & DataGuard ?
RAC pour la haute dispo systeme et DataGuard celle des données.
Crdlt,

[gabrielfotopoto]

Je vais relayer l'info, mais je ne pense pas que l'on se soit penché dessus, merci du renseignement

[laurentschneider]

bien sur ce n'est pas le fonctionnement attendu!

quelle la technologie employee? tout asm et linux?

dans la cas d'une solution asm + raw devices , il faut bien sur placer des mirroirs du voting et ocr disque sur chacune des baies.

je pense qu'il faut commencer par voir si le log contient un truc special... apres il faut aussi voir avec le vendeur en cas d'une couche cluster entre le disque et oracle (style SunCluster)

bonne chance...
Laurent

[orafrance]

Là il y a probablement confusion entre haute-dispo et performance. En effet, le RAC c'est fait pour partager les données entre 2 serveurs... de fait, si un serveur tombe, la continuité de service est assuré MAIS comme les données sont partagés, si le disque est perdu tout tombe. C'est là que Data Guard intervient puisqu'il permet de répliquer les données sur une autre instance et donc un autre disque.

Le RAC sert donc d'abord à assurer un gain de perf en partageant les ressources sur 2 serveurs. Il est inutile pour la haute dispo puisque Data Guard suffit. En plus RAC est beaucoup plus cher puisqu'en Actif/Actif (failsafe) tu dois payer la license Enterprise sur les 2 serveurs alors qu'en Actif/Passif (standby), si le noeud passif passe actif moins de 10 jours, tu ne payes pas la license pour ce serveur (enfin, c'est à négcier mais en principe c'est comme ça).

Pour mieux comprendre, ce document qui traite des licenses proposent des graphiques intéressant : http://www.oracle.com/corporate/pricing/sig.pdf

La doc compléte d'Oracle : http://download.oracle.com/docs/cd/B...hafeatures.htm
Qui montre bien que pour les problèmes de disques le RAC impose au moins ASM

[laurentschneider]

si tu as rac et deux SAN à 30 mètres de distance, et que tu as bien sûr un mirroring ASM ou third-party cluster, alors il n'y a aucune raison que tu plantes la base si un des sites grille !

Après il faut voir pourquoi ça a planté. ça peut être un problème réseau ou autre.

Ou alors un des elements n'est pas mirroré...