Discussion :

[couak]

Bonjour,

J'ai un besoin de mettre une base de données Oracle en haute dispo, et plusieurs solutions (et questions qui vont avec) se posent :

Mettre en place RAC
N'ayant jamais mis en place RAC, je vois plusieurs inconvénients qui risqueraient de chambouler beaucoup de choses chez moi :
- Mise en place d'ASM : toujours habitué au filesystem de l'OS, je n'arrive pas à mesurer la portée des changements dans l'administration de la base
- Payer des licences Oracle 10g Standard : bah oui, j'aurais préféré payer des licences 10g Standard One qui sont bien moins onéreuses
- DRP/PRA : en cas de sinistre, je ne vois pas trop comment repartir d'une sauvegarde de la base sur une autre machine physique qui ne sera pas clustérisée => faut-il remonter des disques en ASM ? Un seul noeud peut-il suffire ? Peut-on envisager de repartir sur des fichiers stockés sur le filesystem de l'OS plutôt que sur le filesystem d'un ASM ?
- Impossibilité de mettre du VMWare : Oracle supporte bien l'environnement VMWare mais pour un standalone ; RAC n'est pas supporté sur du VMWare et un flou règne encore sur une date probable de support
Cela ne m'empêchera pas de monter les serveurs de tests sur du VMWare (ça m'évite de brancher des machines sur la baie SAN grâce aux disques virtuels partagés) mais le faire en production serait une faute professionnelle....
- Est-ce bien utile ? Le but premier est d'avoir le taux d'indisponibilité le moins gênant pour un être humain, disons qu'une indispo de quelques minutes peut être envisagée, il suffira que cet être humain se fasse servir un café le temps que son bon de sortie soit générée

Faire un cluster OS (windows 2003 server)
- Qu'en est-il des licences Oracle ? Faut-il payer pour les 2 noeuds ?
- Jamais mis cela en place, mais à priori pour Oracle c'est transparent car ce serait comme un shutdown/startup, des retours d'expériences ?
- Est-ce qu'il y a des pièges pour ce genre de cluster ?

Faire une standby database
- A priori le moins chambouleur au niveau administration

Question : que feriez-vous à ma place ? Que conseillerez-vous ? Ai-je oublié des solutions ? Est-ce qu'il y a des pièges à éviter ?

[bouyao]

- Mise en place d'ASM : toujours habitué au filesystem de l'OS, je n'arrive pas à mesurer la portée des changements dans l'administration de la base

Tu peut monter un RAC sans ASM, il suffit que la base soit partagées par les noeuds

- DRP/PRA : en cas de sinistre, je ne vois pas trop comment repartir d'une sauvegarde de la base sur une autre machine physique qui ne sera pas clustérisée => faut-il remonter des disques en ASM ? Un seul noeud peut-il suffire ? Peut-on envisager de repartir sur des fichiers stockés sur le filesystem de l'OS plutôt que sur le filesystem d'un ASM ?

La sauvegarde, se fait par Rman.
RAC protége une instance ou un système est non pas un site, pour cela, il faut combiner RAC et dataguard (coût elevé), ou separer les nœuds sur des sites differentes ne dépassant pas 300 km et il faut avoir des lignes Gigabit
(coût très elevés)

- Est-ce bien utile ? Le but premier est d'avoir le taux d'indisponibilité le moins gênant pour un être humain, disons qu'une indispo de quelques minutes peut être envisagée, il suffira que cet être humain se fasse servir un café le temps que son bon de sortie soit générée

Dans mon cas, quelques minutes ca peut couter très cher.
Par exemple, si tu veut te servir un café, tu trouve un queue pour la machine a café de 20 000 personnes.

Question : que feriez-vous à ma place ? Que conseillerez-vous ? Ai-je oublié des solutions ? Est-ce qu'il y a des pièges à éviter ?

Ca depend du cout de l'indsiponibilité de vos systèmes. Demain, je te donnerais : temps d'indisponibilité minimum et l'architecture a prevoir.

[louping]

Les datafiles de RAC peuvent être mis sur raw-devices, ou sur un filesystem propriété Oracle, le CFS.
Le CFS (je crois que c'est le nom) permet de partager des fichiers (les datafiles) en écriture par plusieurs machines, ce qui n'est pas le cas de l'UFS ou du NFS, un seul à la fois.
Le raw-device est la couche avant le UFS, avant le montage en filesystem, cela parait barbare mais lorsque qu'un datafile est full, on en ajoute un autre, et on est sûr d'avoir des datafiles contigus, ce qui n'est pas le cas sur un filesystem avec le RESIZE.

RAC est chère, mais contrairement à Dataguard, en plus de la haut disponibilité, tu as plusieurs instances travaillant en parallèle, du loadbalancing et du failover.
De plus, il faut une double compétence Système et Oracle.

RMAN est le meilleur outils, on a essayé avec BEGIN BACKUP ; dd ; END BACKUP ... BOF Avec RMAN, une resto db de 60Gb en 1/2h

Notre PROD actuel est sur du 3510 miroir hard, évolution vers DMX sans miroir, mais on peut très bien envisager une machine et une moitié de la baie de disque dans deux bâtiments. Il faut de la fibre pour le miroir de la baie et du 1Gb pour l'interconnexion (entre instance)

Pour Dataguard, il te faudra une intervention humaine pour repartir..
Pour RAC, tu peux même faire des évolutions sur les machines, installer un interim patch sans interruption du service.

Finalement, je me demande si c'est pas RAC le plus simple en admin, faut juste ajouter des notions de Cluster.

A+

[couak]

Cool, 2 réponses et 2 votes pour RAC
Il est clair que je préférerais mettre du RAC mais la grande appréhension c'est de chambouler la prod. actuelle avec trop de nouveautés comme RAC, ASM, (ou OCFS) et RMAN. Ce qui me fera plaisir ne le sera pas forcément pour mes autres collègues de la prod.

Les grandes contraintes sont :
- le temps : je suis sur d'autres projets techniques en mm temps et je ne sais pas si j'aurais le temps d'aborder ma remise à niveau technique, la mise en place de RAC, l'administration, un nouveau mode de backup et la nouvelle procédure de DRP
- et toutes les questions à la con que je me pose, genre "et si sur la baie SAN j'agrandis la LUN qui héberge les data de RAC, comment va-t-il le prendre ?", ou "sur quel noeud et comment je vais installer notre scheduler préféré avec tant de noeuds oracle ?"

Un temps d'indispo de quelques minutes c'est pas la mort pour l'appli qui va en avoir besoin, ca fait pencher la balance vers des trucs connus au pire les users rallument un PC sous DOS 6.22 pour faire les remontées avec l'ancienne appli...
Par contre, mettre du RAC c'est avoir une archi solide et évolutive pour les prochains projets

[louping]

On a mis presque 1 an pour mettre la PROD en RAC, cela fait bien 6 mois qu'on doit passer d'une baie vers une autre plus rapide, en ajoutant un noeud. Il faut avoir tester le loadbalancing, le failover, les scénarios de restauration, et documenter un beau OPM. Sinon, ça serre à rien..

Pour RMAN, c'est un outil qui peut paraitre compliqué mais en faite très simple, et c'est un super truc sur un CV.

Et pour le scheduler (ControlM), il attaque l'adresse virtuelle du noeud 1, cette adresse virtuelle peut avoir basculée sur un autre noeud en cas de pb..

Avec Dataguard, on arrive aussi à basculer l'appli sur la secondaire, migrer la primaire, repartir sur la primaire, migrer la secondaire, mais c'est chaud...

A+

[couak]

Bon c'est tranché : vais faire du cluster windows avec MSCS
Le soft "Oracle Fail Safe" permet de de configurer facilement un cluster windows (et uniquement windows), le téléchargement est à part de la DB mais la licence est incluse avec Oracle

La proc. est assez simple :

1) monter le cluster windows
L'environnement de dév. est sous vmware donc je suis parti de template de machines avec OS pré-installé et j'ai créée des disques partagés pour simuler la baie SAN qui sera en production

2) installer oracle (et le patcher) sur chaque noeud sur un disque local

3) créer une base avec les fichiers données sur une ressource disque du cluster

4) installer "oracle fail safe" sur chaque noeud

5) lancer le manager et se laisser guider : fail safe va détecter les ressources cluster et la base précédemment créée, et paramétrer correctement les noeuds du cluster

Au niveau disponibilité, c'est pas du RAC car à chaque failover tout le monde est déconnecté et la base redémarre sur l'autre noeud
Par contre ca a l'avantage de n'apporter pas/peu de nouveautés par rapport à un standalone, et de se mettre en place en moins d'une demi-journée

[kilog]

Bonjour

Shareplex de la sociéte Quest? n'estce pas une alternative à RAC?

Voici un URL qui en donne queques caracteristiques http://www.quest.com/shareplex-architecture/

Shareplex est un logiciel qui permet de faire de la replication entre un site A source, et un site B, destination.
Cette solution est utile non seulement pour la mise en place de plusieurs types de solution de replication, mais aussi lorsque l'on veut migrer d'une version x à une version y d'Oracle.

A en lire la doc cela semble assez vertueux et beaucoup plus rapide et efficace que la solution Streams d'Oracle.

Mes sites A et B sont distants de 280km, A recois les transactions, B est spécialisé pour que du Reporting, avec un délai acceptable de MAJ de 60mn, et j'ai une bande passante faible.

Dois-je l'adopter ou me contenter de Rman?

Merci

[orafrance]

ce n'est donc pas comparable au RAC

RAC = une seule base répartie sur X serveur
Shareplex = réplication... Shareplex c'est Streams sous Oracle

[LeoAnderson]

A en lire la doc cela semble assez vertueux et beaucoup plus rapide et efficace que la solution Streams d'Oracle.

Tu m'étonnes ! ils vont pas dire "il faut acheter notre truc en plus de la license Oracle mais on fait moins bien..."

mais j'avoue avoir du mal à concevoir qu'un éditeur, aussi brillant et spécialisé soit-il arrive à faire mieux que ce que propose Oracle...
Là où ils sont peut-être (et même sûrement) plus forts, c'est dans le packaging... là où Oracle propose un outil généraliste qui peut s'adapter à tous les contextes opérationnels, ils vont vous proposer une customisation pour un type de réplication bien précis mais tuné aux petits oignons...

[orafrance]

pour faire une standby logique Shareplex était plus performant qu'Oracle jusqu'à la 10g

Streams est désormais beaucoups plus fiable

[orafrance]

mais tuné aux petits oignons...

euh... non pas vraiment ça fonctionne mieux qu'Oracle ce qui est déjà pas mal... mais pas excempt de problème

[kilog]

euh... non pas vraiment ça fonctionne mieux qu'Oracle ce qui est déjà pas mal... mais pas excempt de problème

D'apres nos amis de Quest, Shareplex est moins gourmand en bande passante que Streams. Dois-je donc m'y engager d'autant plus que "ça fonctionne mieux qu'Oracle",

ou alors me réfugier dans une Rman + script faute de bande passante pour utiliser Streams.

Ce serait bien qu'DBA ayant déployé Shareplex s'exprime...

[LeoAnderson]

de toute façon, vous allez bien faire des recettes et qualifier la méthode la plus performantes ?

vous n'allez pas simplement vous baser sur 2 témoignages dans un forum pour trancher ?

[orafrance]

Ce serait bien qu'DBA ayant déployé Shareplex s'exprime...

c'est ce que j'ai fait

Mais je ne connaissais pas Streams que maintenant je mets en place. Et franchement, Streams a l'air de mieux tourner que Shareplex. Note que Streams ne semble être fiable que depuis la 10G.

Pour moi, Oracle < 10.2 Shareplex sinon, Streams. Au niveau du traffic je vois pas bien ce qui pourrait changer sachant que dans les 2 technos c'est les mêmes infos qui sont stockées. Streams a un avantage non négligeable en terme de gestion de conflits par contre le support Quest est plus réactif.

Comme le dit Leo, il faut faire des prototypes avec les 2 solutions pour connaitre le produit le plus adapté.