Andesi - forum

Salut,

Je dirai que dans un cluster actif/actif, chaque "machine" répond à tour de rôle, en cas de plantage tout est dirigé sur la machine qui n'est pas plantée.

Dans un cluster actif/passif, il y a une "machine" qui est sollicitée, l'autre attend que la machine active se gauffre pour prendre la main.

Là, j'ai répondu selon ce que ça m'évoque. Lundi je poserai la question si je suis pas tout seul à bosser (OUIN !!! les vacances sont finies ). Et j'aurai peut être les avantages/inconvénients de chaque système.

Merci pour vos réponses
En fait la mise en place sera réalisé par le prestataire/fournisseur de la solution retenue donc l'installation des applis c'est leur problème.
Mon soucis est d'opter pour la solution qui nous assure le meilleur service 24/24 7/7 (la notion de coût  qui est accessoire vue l'investissent global requis )

L'une (celle en actif/passif) sera basée sur un truc Genre HeartBeat avec 2 Machines identiques reliées à une baie de disque (où, si j'ai bien compris les données du SGBDR Oracle 10g  seront mirorées en permanence pour assurer leur pérennité en cas de crash d'un disque)
L'accès à l'applicatif métiers se fera via un Frontal Web.
Le tout est basé sur le Service HP ServiceGuard For Linux

La seconde (actif/actif) est également basé sur Oracle 10g mais l'appli métier sera accessible via un client lourd installé sur les postes (ce qui me gène un peu).
Je sais que les données seront également sur une baie mais selon quelle principe ? (Type de raid ?) La doc n'est a mon grand regret pas tres explicite sur le principe.

Bon ce n'est pas trop mon truc alors j'espère que je ne dit pas des de conn...
Si j'ai bien compris

Actif/Actif = Load balancing
Répartition de la charge de travail entre les deux machines pour optimiser le rendement --> ceci semble indiquer qu'en cas de défaillance d'une machine, la charge est intégralement reportée sur celle qui rest  --> au prix d'un dégradation des performances ?

Actif/Passif = Failover
Une seule machine travail, en cas de défaillance de celle-ci, le heartBeat lance la seconde qui reprends l'activité en charge et devient la machine active --> cela semble indiquer que chacune des machines doit avoir un niveau de puissance suffisant pour assurer les traitements avec des temps de réponse acceptable ?

Même si cela me semble moins "bio" et "écologique"  (une des machines est juste là en attente d'une éventuelle défaillance de l'autre) la seconde solution me séduit plus:  Chaque machine est assez puissante pour faire tourner les brouettes et en cas de soucis , on ne constate pas de dégradation des perf ce qui pour nous est important.

J'a tout pigé ?

Dernière modification par freddec (02/08/2008 10:46:15)

Je ne sais pas si ton raisonnement pèche, mais il y a une autre dimension a prndre en compte, celui du coût.
Dans les 2 cas on est sur des produits avec Bi Xeon Quadri Coeur de l'ordre 40 000 € (baie de disque inclus et prestation incluses)

Mais dans le cas du
-actif/actif les 4 Proc tournent ensemble et requiert donc 4 Licences Oracle  (1 par proc)
-actif/passif seul 2 proc tournent en simultané et donc 2 Licences Oracle

A environ 11 500 € HT la licence, la paille commence a ressembler a une poutre !
Le serveur Actif/Passif nous reviens un peu plus cher du fait d'une puissance plus importante, mais on est qd meme loin des 23 000 € de différences (environ 2 000 à la louche !)

En outre dans la solution Actif/Passif
Le nombre de connexion simultanées au frontal web est limitée par les licences de l'applicatif acquisent (30 users maxi + une 40 aine de périphérique actifs genre modem, automates, autres serveur connectés...), 
La charge maximum de travail théorique est donc calculée en fonction de cela et le serveur adapté (enfin je suppose !)

En tous cas merci pour vos considérations qui ont éclairé ma lanterne. (pour ne pas dire allumé !)

Et quid de Postgres à la place de Oracle ?

Je sait trés bien que parfois, les éditeurs imposent la base, mais bon, je demande quand même au cas où hein
Et puis de plus en plus d'entreprises propose différent type de support autour de PgSQL.

De GROSSE discutions ont été menées pour intégrer une réplication simple, efficace et qui marche dans le core même de Postgres pour la prochaine version.

Mais tout ceci est à prendre avec des picettes. Quoiqu'il arrive, les choses bougent *beaucoup* pour faciliter la réplication avec PostgreSQL, que ce soit pour améliorer les projets connexes existant (comme Slony ou les Skytools) ou l'intégrer au sein même du projet (via le log shipping ou la résurrection de PostgreSQL-R dont l'auteur a finalement ouvert le code).

J'ai du mal à suivre la discussion et les conclusions d'où je suis actuellement, j'ai trop peu souvent accès à internet, trés peu de temps à consacrer et beaucoup trop de traffic à ce propos pour tout lire. Je crois qu'on s'oriente dans un premier temps vers une réplication asynchrone avec *peut-être* les esclaves accessible en lecture seule pour la 8.4 (ce qui soulève quelques défis poru les dévs).

Bref, encore une fois, ce projet me passionne toujours autant. La 8.4 va encore roxer massivement avec tout plein d'autre nouveautées et améliorations et les contributeurs et entreprises affluent de plus en plus vers cette magnifique communauté !

A noter pour les toulousains ou personne à mobilité large, une journée de conf consacrées à PostgreSQL est organisée le 4 Octobre. Pour plus d'info :
http://www.postgresqlfr.org/?q=node/1686
et
http://www.pgday.fr/doku.php/inscription

À bientôt tous !

Et bien comme je le disais, il existe ce genre de société aujourd'hui qui font ce genre de support pour PostgreSQL.

Si, les solutions libres ONT cette possibilité, c'est bien ici que repose justement toute l'économie du libre : le service !

Ceci dit, le coup du cout des compétences interne est imparable, lui. Domage...