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

[LeoAnderson]

et ça n'offre aucun bénéfice de fail over puisque tout le monde est déconnecté ni de load balacing... :-S

[couak]

fail over si, mais à froid
c'est de la tolérance de panne et non de la haute dispo comme RAC

[orafrance]

déjà faudrait commencer par nous dire quelle dispo il faut :neutre:

c'est du 24/24 avec 0 déconnection ? il y a une tolérance de panne de combien de temps ? Des périodes de maintenance ont elles été défini ? etc...

le RAC c'est bien mais c'est très structurant dans l'architecture et ça revient TRES cher

pour le RAC je conseille quand même d'utiliser ASM qui permet de s'affranchir des problèmatiques disques (ou presque )

[lecharcutierdelinux]

Ce sujet m'interessse car j'ai moi-même des contraintes de la part de la DSI pour rendre la machine dispo au pire en 24H max (et encore ça serait déja la cata).

J'ajouterais juste une chose c'est qu'en cas de feu dans la salle serveur ou autre, votre RAC est HS.

Combien de temps mettriez-vous pour repartir d'un sinistre?

Pour ma part, on va surement partir sur du standby, à moins que l'on puisse faire du RAC entre différents sites?

[couak]

déjà faudrait commencer par nous dire quelle dispo il faut :neutre:

c'est du 24/24 avec 0 déconnection ? il y a une tolérance de panne de combien de temps ? Des périodes de maintenance ont elles été défini ? etc...

le RAC c'est bien mais c'est très structurant dans l'architecture et ça revient TRES cher

pour le RAC je conseille quand même d'utiliser ASM qui permet de s'affranchir des problèmatiques disques (ou presque )

Déjà dit dans le premier post :p une indispo de 10 min c'est pas la mort, c'est pour cela que j'avais émis l'hypothèse d'un cluster windows

[couak]

Ce sujet m'interessse car j'ai moi-même des contraintes de la part de la DSI pour rendre la machine dispo au pire en 24H max (et encore ça serait déja la cata).

J'ajouterais juste une chose c'est qu'en cas de feu dans la salle serveur ou autre, votre RAC est HS.

Combien de temps mettriez-vous pour repartir d'un sinistre?

Pour ma part, on va surement partir sur du standby, à moins que l'on puisse faire du RAC entre différents sites?

tu as Oracle Data Guard, ca marche avec RAC

en france, tu as quand même plus de chance d'avoir une bande de grévistes qui éteignent tous les serveurs d'une salle et qui t'empêche l'accès aux locaux plutôt qu'un incendie dans une salle de production

[LeoAnderson]

Du rac entre différents site : c'est mort !
RAC a besoin d'une liaison interconnect à 1 GB ...

quant au cluster windows, avoir 2 machines qui tournent mais une seule qui sert pendant que l'autre est ras la gueule, je vois mal l'intérêt... (surtout que si en cas de panne tout le monde est déconnecté, perd toutes son contexte, ...)

[orafrance]

Déjà dit dans le premier post :p une indispo de 10 min c'est pas la mort, c'est pour cela que j'avais émis l'hypothèse d'un cluster windows

ça marche très bien et c'est pas trop compliqué à mettre en oeuvre

lecharcutierdelinux -> tu peux faire du RAC distant mais il faut évidemment une bonne ligne. Un hopital que j'ai vu avait une salle de l'autre coté de la rue avec connexion fibre optique

[orafrance]

quant au cluster windows, avoir 2 machines qui tournent mais une seule qui sert pendant que l'autre est ras la gueule, je vois mal l'intérêt... (surtout que si en cas de panne tout le monde est déconnecté, perd toutes son contexte, ...)

On peut imaginer : un noeud Oracle et un noeud web par exemple avec un failover qui bascule Oracle sur le noeud web. De toute façon, en terme de coût un serveur supplémentaire a des chances d'être encore bien moins cher que la solution RAC

[couak]

c'est clair, mettre du RAC m'aurait obligé à passer en version standard, alors qu'en cluster windows je peux me permettre d'installer une version standard one

en terme de tarif pour un noeud bi-processeur intel dual-core :
- standard = ~22K€
- standard one = ~7K€
- sous vmware = 0€ vu que la licence aurait été mutualisée avec le parc de serveurs oracle déjà présent, mais pour la prod. ca n'a pas été validé

[LeoAnderson]

Attention : VMWARE n'est pas certifié me semble-t-il....

(déjà que l'admin 8i en RDP pose problème...)

[couak]

RAC sous VMware n'est pas supporté, ce qui ne veut pas dire que cela ne marche pas : je ne mettrais pas cela en production

par contre un standalone sous VMware est supporté par oracle et vmware, et j'ai des serveurs qui vont passer en production sous vmware incessamment sous peu après que leur alter-égo de développement aient été virutalisés depuis plus d'1 an

[LeoAnderson]

Désolé, mais non, VMWARE n'est pas supporté !

La note Note:249212.1 est claire :

Oracle has not certified any of its products on VMware virtualized
environments.

Après supporté par VMWARE, j'en sais rien, mais c'est pas eux qui vont me résoudre mes problèmes Oracle !

Et Oracle dit : "si on reproduit le bug sans VMWARE, on veut bien regarder, sinon, dém...-vous avec VMWARE"

Quant à vos serveurs de prod sous VMWARE, je suis content que ce soit les votres et pas les miens !

PS : la note est du 03/07/2007, elle est donc assez à jour....

[couak]

Effectivement, la note est claire, ils ont dû sûrement retourner leurs vestes entre l'euphorie de l'annonce il y a plusieurs mois de cela (support conjoint oracle et vmware) et la réalité d'aujourd'hui

Après c'est un risque à prendre, risque validé par :
- un environnement de dév. équivalent à la prod. virtualisé depuis 1 an : pas de problème oracle, méthode de backup identique, procédures DRP inchangées, etc.
- connaître des entreprises déjà passés sous vmware en prod. avec des bases en prod.
- un gain financier non négligeable
- une infra vmware supportée et stable
- une connaissance des bases impactées : rien d'exceptionnel, les applis réellement critiques sont infogérés, ce qui est à ma charge l'est moins, et n'utilisent pas de fonctionnalités poussées

Après je te l'accorde il y a toujours un doute, surtout quand oracle te dit "démerdez-vous" tout en admettant publiquement utiliser du vmware pour monter rapidement des environnements identiques à ceux des clients qui ont subis des crashs ou des bugs sévères. De toute façon, au pire je me fais virer pour faute professionnelle