Bonjour,
 
Je devrais mettre en place une telle architecture.
Si je résume bien (corrigez moi si c'est faux), le "load balancing" permet la répartition de charge : si ça rame, cela règle le problème.
Les requêtes étant redirigées tantôt sur une machine, tantôt sur l'autre.
Le clustering ne sert qu'aux "disaster recovery" : en gros sur une panne matériel, l'autre machine prend le relais et grâce au clustering, il n'y a aucune donnée de perdue (l'état de la base est le dernier état suite à la dernière transaction).
 
Moi ce que je recherche c'est la "chose" (:D) qui permet aucune coupure au client : que l'appli ne soit jamais arretée    
Et ce suite à maj de l'appli par exemple (nouvelle livraison).
Mais cela me paraît difficilement réalisable car les 2 serveurs doivent avoir la MEME application (même version), ce qui est logique.
donc pour faire une livraison (qui rajoute des colonnes en base par ex.), je suis obligé d'éteindre les 2 machines (coupure générale) et de ré déployer.
 
Merci de m'éclaircir sur le concept de "High Avalaibility".

ben un serveur opérationnel et un serveur de secours qui est une réplication du premier. Quand tu fais une livraison, tu arrêtes le serveur OP et met en opérationnel le secours, pendant ce temps là, tu mets à jour l'OP et tu teses avec la nouvelle version et quand c'est ok, tu mets en opérationnel l'OP, tu arrêtes le secours (ce qui fais que pendant qq minutes, t'as plus de secours), tu mets dessus la nouvelle version et tu le remets en secours de l'OP pas besoin de load balancing et clustering...

Je vois ce que tu veux dire....mais je ne suis vraiment pas sûr que ça marche   ...j'explique :
 
1) Je redirige les requêtes qui vont vers l'OP vers le secours (via DNS par ex.). OK
2) J'arrête l'OP. OK.
3) Je déploie la nouvelle appli sur l'OP. Supposons Hibernate met à jour le schéma. Là c'est le problème : comment se "réplique" le travail fait sur le serveur de secours pendant la maintenance sur la base de l'OP sachant qu'elle a changé.....je perds tout le travail qui se fait sur le secours .
Ensuite la réplication (sous MS SQL Server) marche-t-elle toujours si la base change (ça m'étonnerait fortement   ) : la réplication du serveur de secours vers la base du serveur OP ne devient plus possible car les 2 schémas ne sont plus identiques....
 
Voilà où je butte  

Pour les pbs liés aux BD, je pense qu'il faudra que tu développes un script de synchro entre les 2 BD en tenant compte des changements de schéma, à moins que ton sgbd soit capable de le faire...

Bon j'ai lu l'article ci : http://sqlpro.developpez.com/cours [...] onibilite/
Je pense partir sur du mirroring, ça à l'air le plus simple.
Pour le cas que je viens de citer, je vais devoir étudier la chose de près.
Mais ça va être chaud, je ne suis pas du tout DBA SQL Server    mais développeur
Euh, vous estimez un chiffrage de combien de temps pour mettre en place cette solution ? (mirroring de base)  

Dans ma tête, ce qu'il appelle mirroring pour MS sql server, c'est le mode maître-esclave sous MySQL 5, c'est ce à quoi je pensais quand je t'ai exposé ma solution.
Pour le chiffrage, ça dépend sur quel sgbd tu travailles. Si c'est ms sql server 2005, ça a l'air assez simple (de l'ordre de 1 à 2j/h à vue de nez). dans le cas contraire, ben ça va dépendre de ce que sait faire ton sgbd, de quelle manière et de ton niveau de compétence dessus...

Je prévois une 10aine de jours au moins    (auto formation, mise en place des machines, mise en place du mirroring, tests)
Ensuite, il y a l'application à paramétrer
Enfin, il y a un serveur DNS à mettre en place
 
Le tout je compte 20j
 
La doc me fait peur, j'y capte rien : http://technet.microsoft.com/en-us [...] er%29.aspx  

J'ai lu le début. En gros, c'est basé sur les transactions du serveur principal (le serveur maître en Mysql) qui sont mis dans des logs qui sont envoyés en mémoire, dans un buffer de logs, à une autre instance de ms sql server 2005 (l'esclave en mysql, le mirroir, ici) qui, dès prend ces logs et met à jour ses tables en mémoire, puis, dès qu'il peut, écrit les tables sur le disque.

Une autre approche sinon : la dynamic software updating (cf ce topic : http://forum.hardware.fr/hfr/Progr [...] 7187_1.htm )

OK merci c'est sympa    
En fait, à la base j'y connais rien dans la pratique sur ces "High Availibity" infrastructure. Je connais cependant la théorie un bon peu (après moult lecture).
Je cherche à permettre la haute disponibilité (disons déjà bien meilleur que celle actuelle) en partant sur les points à privilégier suivant :
 
1) Simplicité à mettre en oeuvre
2) Simplicité de maintenance
 
Et l'article cité plus haut sur developpez.com mets grandement en avant le mirroring sur ces critères...je pense donc foncer la dessus    
 
J'abandonne le clustering (exigent en terme de complexité et de maintenance) et le load balancing (l'appli ne "rame" pas et répond aux utilisateurs).
Je mets en place la redirection d'ip par contre pour passer la main du serveur de prod au serveur "warm stand by".
Le plus dur, va être la gestion du mirroring avec la BDD MS SQL, j'y connais rien ...et surtout quel(s) test(s) faire pour s'assurer que les conditions en prod soient reproduites et validées par les tests.
Il y a des tests de concurrence à mettre en place .

Une intro assez générale sur le sujet, ça peut toujours te servir.
 
Et NazzTazz (intervenant web principalement) a posté énormément de choses de qualité sur ce sujet, tu peux faire une recherche sur blabla@web sur son pseudo avec les mots clé qui vont bien. Mais en tout état de cause, c'est pas un problème de Java (et pas spécialement de prog), tu auras peut-être plus de réponses dans les cat réseau ou OSA

cad

http://forum.hardware.fr/forum2.ph [...] 0#t1199802