Oracle RAC 11g - Continuité de Service

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 ?

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,

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

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

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 :?

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

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 :koi:

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

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

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.

Citation:

---

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.

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

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

Citation:

---

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 :?

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 ?

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

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,

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.

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

@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 ! :ccool:

Laurent

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) :)

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

Laurent

Je te rejoins tout à fait sur la r2, mais en r1 même avec 3 voting, ou 5 ou 31, tu n'as qu'une chance sur 2 pour que css ne s'arrête pas, si la baie qui tombe est celle qui contient le moins de voting. A moins que tu ne disposes d'un produit pour mirorrer ces devices, comme ASM en 11gr2.
Non ?

Avoir un nombre multiple de disques votant permet d'assurer la continuité de service en cas de crash.

Si un noeud vient à perdre la synchro avec les autres noeuds, il faut qu'il discute sur un disque votant (VD). Si on perd une baie et que le CSS est capable de trouver un VD disponible il l'utilise.

Laurent

Citation:

---

Si on perd une baie et que le CSS est capable de trouver un VD disponible il l'utilise

---

Pas un mais plus de la moitié des votants, non ? D'où les soucis que j'évoquais en cas de perte de la "mauvaise" baie (celle qui contiendrait + de la moitié des votants). Pour peu que tu sois en boot on SAN : perte des noeuds rattachés à la baie, perte du cssd sur les survivants, perte d'ASM sur les survivants, perte du service, perte du DBA :)

En lisant la note 428681.1, on peut lire

Citation:

---

3) Because we do not allow the removal from all voting disks, there need to be at least one, one spare raw or block device is needed if the existing raw devices should be reused.

---

Je n'ai pas le souvenir d'avoir lu qu'il fallait la moitié des disques pour que cela continue de fonctionner, du moins lors d'une simple panne. Si tu as un lien, de la doc, je suis preneur ! :D

Après, si on évoque une double panne du genre :
- J'ai deux baies, 3 VD, 2 VD sur la baie 1, et 1 VD sur la baie 2
- je perds ma baie 1 ou ma baie 2 ... pas de problème, le CRS voit encore au moins un VD, il n'a pas de raisons d'évincer un noeud du cluster
- en revanche, si à cette panne, tu ajoutes une perte d'interconnect (que tu n'auras pas pris soin de doubler ! :calim2:) ...

Là on se trouve dans le cadre d'une double panne. Si, à cet instant, on se retrouve avec la baie disposant de 2 VD, les votes peuvent poser problème et la décision d'éviction peut devenir problématique ... mais on est dans le cadre d'une double panne non négligeable (1 baie + interconnect) !

Laurent

Bonjour Laurent,

Cette documentation traite de près le sujet qui nous passionne :)

Si tu le souhaites, et pour éviter de polluer le forum malgré l'intérêt de cette conversation, je t'envoie mon mail par MP pour que nous puissions échanger, on est en train de monter une configuration de ce genre pour un client avec un clusterware et ASM en 11.1

A+

Mathias

Ok ca marche !

Laurent