Discussion :

[scaleo]

J'ai une application qui exploite une base de données, cette application contient un serveur tcp auquel ce connecte des clients qui envoie des données sous forme XML l'application recherche dans la base de données effectue des opérations sur les données et renvoie la réponse au clients.

J'ai pensé faire l'architecture suivante afin d'ajouter une tolérance aux pannes :



Qu'en pensez vous?

[LefortLudovic]

Il se passe quoi si ton maitre est down ?

[bruno_pages]

... ou si le serveur MySQL tombe en panne ? mais peut etre que le dessin ne montre pas bien l'architecture choisie ?

d'autre part il y a trois instance servers, c'est pour faire un vote 2 parmis 3, ou on suppose que les pannes sont 'franches' ... ce qui est loin de représenter les 'vrais' cas de tolérances aux pannes

[souviron34]

et si la panne est sur le disque de la BD ?

[Desboys]

Bonjour,
c'est une architecture matérielle ou logicielle?
Pour moi, tolérance aux pannes m'amènent à des concepts de redondance, fail-over ...
J'ai plus l'impression que ton maître va répartir les requêtes sur les instances serveurs, et dans ce cas là c'est plus pour traiter une montée en charge importante ( load balancing ici ).

Donc définit clairement les objectifs recherchés ( répartition? tolérance aux pannes? service dégradé en cas de sinistre? ... )
Dégage les limites suites aux contraintes divers ( parc client, coût des équipements, capacité des OS, etc ... )
Et dimensionne le tout pour que ça passe comme demandé.

Certes, je ne suis pas expert en architecture, mais j'espère aider par mon point de vue.

S. Desbois

[scaleo]

C'est vrai que mon schéma n'est pas très clair. je vais tenter de vous expliquez le fonctionnement du système.

j'ai un cluster sql qui est attaqué par une applie nommé Lexicon server (serveur de lexique), cette application reçois des instructions cherche des données dans le serveur sql effectue des calculs puis renvoie la réponse. Le problème c'est que l'application ne doit surtout pas tomber en rade, il faut donc que je trouve un moyen pour que si une instance tombe en caraf une autre prenne le relais

Par exemple un des lexicon server reçois des instructions mais tombe en rade et donc ne renverra rien qu'une autre instance sur un autre serveur prenne le relais.


L'idée d'un serveur maître bien que séduisante me parait pas très bonne si jamais le maître tombe en rade humm tout tombe avec.


Il ne s'agit pas d'une application dans le cadre de mon travaille mais d'une application perso, en fait avec des collègues je bosse sur un moteur de recherche et ont revoie l'architecture pour booster le monstre.


NB: C'est un moteur pour le "fun" pas pour concurrencer Google !!!!

[scaleo]

Bonjour,
c'est une architecture matérielle ou logicielle?
Pour moi, tolérance aux pannes m'amènent à des concepts de redondance, fail-over ...
J'ai plus l'impression que ton maître va répartir les requêtes sur les instances serveurs, et dans ce cas là c'est plus pour traiter une montée en charge importante ( load balancing ici ).

Donc définit clairement les objectifs recherchés ( répartition? tolérance aux pannes? service dégradé en cas de sinistre? ... )
Dégage les limites suites aux contraintes divers ( parc client, coût des équipements, capacité des OS, etc ... )
Et dimensionne le tout pour que ça passe comme demandé.

Certes, je ne suis pas expert en architecture, mais j'espère aider par mon point de vue.

S. Desbois

Concrètement il faut effectivement répartir les requêtes sur les instances du Lexicon server afin de monter en charge, mais aussi s'assurer que si une des instances tombe en rade qu'une autre prenne le relais et traite les données de l'instance qui est tombé.

L'autre problème est que si une instance tombe en caraf les sockets y étant rattaché tombe aussi dès lors comment pour l'instance prenant le relais renvoyé les données au client ? MSMQ me parait adapter (on est sous w2k3) pour cela qu'en pensez vous ?