Oracle RAC 11g - Continuité de Service

**gabrielfotopoto** · 01/07/2009, 09h49

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 :

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

**agdid04** · 01/07/2009, 14h18

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** · 01/07/2009, 15h19

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

**laurentschneider** · 06/07/2009, 20h14

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** · 07/07/2009, 14h59

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** · 07/07/2009, 17h26

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é...

**orafrance** · 07/07/2009, 17h28

le truc, c'est qu'il a jamais parlé d'ASM... je pense que le souci est là. Et outre ce point, je me pose quand même la question de la pertinence économique par rapport à la standby

**laurentschneider** · 07/07/2009, 17h35

il n'a jamais non plus dit que la question monétaire était prioritaire.

Avec RAC, ton down-time se compte en secondes alors qu'avec standby, tu comptes en minutes.

Aussi avec 30m, il n'y a pas trop de problème de latence, donc RAC est OK, par contre, pour en cas de catastrophe naturelle, ça va être un peu limite...

**orafrance** · 07/07/2009, 17h36

ha oui, c'est pas faux... m'enfin, avec Dataguard tu peux tomber bien en dessous de la minute aussi quand même

**gabrielfotopoto** · 08/07/2009, 15h14

J'apporte juste une précision, l'ASM + Raw Devices sont utilisés dans notre configuration "bancale" et nous sommes sous une distribution Suse Linux.

Par contre je me rends vraiment compte que le Commercial ORACLE et notre Commercial interne ont du se méprendre quand aux besoins et aux préconisations...

Merci pour vos interventions, dans tous les cas.

Envoyé par 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é...

En fait dans nos tests, l'un d'eux prends en compte l'arrêt complet d'une de nos baies (chaque Baie comporte 1 serveur BDD et 1 SAN). Et donc, dans ce cas là, pour le moment nous n'avons aucune continuité de service.

Pour nous la continuité de service est primordial, notre système gère les alertes pour les Pompiers au niveau départemental, de ce fait il ne doit vraiment pas y avoir d'interruption de service. Mais il nous faut aussi de la performance, nous avons des départements avec plus de 80 000 interventions à l'année qui en sont très demandeurs.

Je pense que la Solution RAC, ASM+Raw Devices et DataGuard serait une solution correspondante à nos besoins.

**orafrance** · 08/07/2009, 16h10

Est-ce que comme Data Guard, il n'y a pas besoin d'un "observer" pour détecter les incidents ?

Il ne me semble pas me rappeler de ça mais bon... sait-on jamais

**laurentschneider** · 08/07/2009, 17h42

Envoyé par gabrielfotopoto

En fait dans nos tests, l'un d'eux prends en compte l'arrêt complet d'une de nos baies (chaque Baie comporte 1 serveur BDD et 1 SAN). Et donc, dans ce cas là, pour le moment nous n'avons aucune continuité de service.

Et pourquoi pas? Il reste encore une base et si tout est mirroré, ça ne devrait pas planter

**orafrance** · 08/07/2009, 17h43

Pour que ce soit mirroré faut bien que ce soit paramétré dans ASM non ? C'est pas mirroré d'office ou je me gourre ?

**laurentschneider** · 09/07/2009, 10h13

au niveau du voting disque :

crsctl query css votedisk

au niveau du disque ocr :

ocrcheck

au niveau de asm :

SELECT * FROM V$ASM_DISK

il faut que chaque disque groupe ait un disque de chaque FAILUREGROUP et que les disques de chaque soit correctement assignés à leur failure group distinct

**agdid04** · 10/07/2009, 16h14

Bonjour,

ha oui, c'est pas faux... m'enfin, avec Dataguard tu peux tomber bien en dessous de la minute aussi quand même:
Test =>J'ai activé dataguard avec un décalage de 12 secondes entre la standby et la primaire.
@+
Crdlt,

**gorgonath** · 11/09/2009, 15h28

Bonjour à tous,

J'ai exactement le même problème. La différence est que je suis sur du NAS et pas du SAN.

laurentschneider pourrais-tu être plus clair dans la phrase qui suit?
----------------
il faut que chaque disque groupe ait un disque de chaque FAILUREGROUP et que les disques de chaque soit correctement assignés à leur failure group distinct
-----------------

Je nai pas trouvé aucune documentation au sujet des assignation des failure group.

Merci.

**Mathias44** · 12/10/2009, 14h56

Bonjour,

La notion de failure group est liée à l'implémentation de la redondance dans ASM : le mirroring ASM te garantit qu'un extent (au sens ASM du terme) sera écrit dans chacun des failure groups. Les failure groups sont vus comme des listes de disques (ou de devices) liés au même SPOF (ex. controleur, baie...).
Avec du mirorring ASM on répond sans interruption de service à une panne de type perte de baie si les failure groups sont bien définis, et si la baie qui tombe n'héberge pas OCR et voting disks. Sans dataguard, je ne vois pas comment construire une solution sans interruption de service dans le cas de perte d'une baie, il faudra nécessairement à un moment reconstruire la conf OCR + voting pour que le clusterware reparte (à cause de des voting disks pincipalement).
Avec la 11gr2 il serait peut-être envisageable de le faire dans la mesure où le stockage de l'OCR et des voting est supporté sur ASM, donc potentiellement "mirrorable" sur 2 baies...

**laurentleturgez** · 12/10/2009, 16h31

@Gorgonath

Ce qu'a voulu dire Laurent (qu'il me corrige si je me plante), c'est que lorsque tu configures une redondance [prenons l'exemple de la redondance normale en miroir] tu créés deux failure group. Dans chacun de ces failure group, tu y mets des disques.

Il faut t'assurer que le disque 1 (sur le FG1) soit sur la baie 1, et que le disque 2 (sur le FG2) soit sur la baie 2.

Comme ca, si tu fumes un disque, voire une baie ... tu conserves la disponibilité de ta plate-forme !

Laurent

**Mathias44** · 12/10/2009, 16h44

Si tu fumes un disque oui, si tu fumes une baie ça se complique un peu avec une base RAC et le clusterware (du moins en 11gr1)

**laurentleturgez** · 12/10/2009, 17h07

Sauf si ton OCR est configuré (mirroré) sur 2 block devices, et que tu utilises 3 block devices de voting disk.

Ces caractéristiques (mirroring de l'OCR et des voting disk) sont recommandées pour les installations de cluster en 10g et 11gR1.

Avec la 11gR2 .... un diskgroup ASM de quorum avec la redondance "qui va bien" ... et le tour est joué.

Laurent

Oracle RAC 11g - Continuité de Service

Installation Oracle

Discussions similaires

Partager

Partager