Contexte partagé entre serveurs (architecture & transactions distribué)

Bonjour,


Je travaille sur une architecture distribué dans laquelle j'ai plusieurs serveurs.
Un client 1 se connecte sur l'un des serveurs disponibles, on va dire "serveur 1", puis ce serveur 1 notifie les autres serveurs en leur disant qu'il va traiter la demande de client 1.

Voici un schéma que j'ai dessiné pour illustrer l'architecture (j'espère que vous n'êtes pas daltonien car c'est très coloré) :
Pièce jointe 159123

Le problème se situe surtout à l'étape 3) C), car rien ne dit que tous les serveurs vont avoir le temps de répondre, et si l'un des serveurs qui répond trop tard a déjà une transaction en cours avec client 1 alors serveur 1 ne le saura jamais.


Questions :
:fleche: 1. Connaissez-vous une architecture plus fiable et plus rapide que celle-ci ?
:fleche: 2. Comment résoudre le cas de l'étape 3) C) ?
:fleche: 3. Connaissez-vous une API Java Standard, et ou libre [populaire|documenté|gratuit] qui gère les contextes dans une architecture distribués ? (merci pour les liens)... sinon je serais obligé de créer des maps de contexte moi-même je vous dis pas le résultat :aie:


PS: Concernant les protocoles utilisés, il est fort probable que les flèches 1) et 4) soient en RESTful (HTTP), et les flèches 2) et 3) en Multicast (UDP/IP) avec message au format JSON.


Cordialement,

J'ai l'impression que tu cherche à faire du Load Balancing.
De ce que je connais de ce principe, on place une seule machine en frontale. Celle-ci répartie les clients entre les différents serveurs.
Cela a souvent cette forme :
Pièce jointe 159169

Tu peux trouver plus d'information ici :
http://fr.wikipedia.org/wiki/R%C3%A9partition_de_charge
http://en.wikipedia.org/wiki/Load_ba...28computing%29
http://www.le-load-balancing.com

Sachant que la problématique du Load Balancing est plus un problème architecture/réseau, ceux-ci ne sont pas généré classiquement au niveau applicatif. Par exemple au niveau de l'Apache :
http://www.le-load-balancing.com/exp...on/apache.html

Cordialement,
Patrick Kolodziejczyk.

Source de l'image :
http://blogs.getcertifiedgetahead.co...work-security/

Si ton but est de gérer à la main les verrous (pour des raisons à déterminer), le plus simple est de stocker tes verrous sur une base de données centrale. Ce sera plus réactif, tu aura d'office une réponse, il suffit de faire une ligne par client avec le serveur qui possède le verrou. Si ta transaction SQL commit, tu as le verrou.


Si le but est juste de s'assurer que toutes les demandes de clients 1 sont gérée par le même serveur web, il y a déjà des loadbalancer pour ça, comme indiqué.

Si le but est de faire une application J2EE distribuée sur plusieurs serveur, tu ne devrais pas avoir à te soucier des verrous, la couche EJB gère très bien les session EJB pour toi :)

Bonjour,


@kolotz
Oui je cherche à faire du Load Balancing. Le fait d'avoir un unique Hardware Load Balancer n'est pas en contradiction avec le principe de Haute disponibilité (-> SPOF*) ?
J'ai déjà lu les articles Wikipédia, merci pour les autres liens que je ne connaissais pas.

@_tchize
Dans l'ordre :

• Si j'utilise 1 base SQL dédiée aux verrous des utilisateurs, je crée 1 SPOF*.
• Pour m'assurer que 1 serveur gère le même client durant la durée de la transaction je dois moi-même trouver une solution, et ne pas utiliser de solution propriétaire (je dois utiliser des solutions open source & gratuit, voir créer l'algorithme qui s'en charge).
• Oui mon but est de créer une application JEE distribué sur plusieurs serveurs, mais je ne vois pas comment les EJB Session Bean standard peuvent gérer cela. Si tu fais références au @Clustered, c'est spécifique à du JBoss. J'ai trouvé de la documentation :
  https://docs.jboss.org/author/displa...lability+Guide , mais la configuration a l'air complexe, je n'ai pas compris comment faire pour configurer le failover (la bascule vers un autre serveur disponible).

Pour la notification de contexte entre les serveurs (le terme "Session affinity" est plus adapté je suppose), on nous a demandé d'utiliser du Multicast avec échange de message au format JSON (on considère dans notre cas que l'UDP est suffisamment fiable pour arriver chez le destinataire), par contre le notifieur possède un timeout (cf: le scénario C) de l'étape 3), et ça je ne vois toujours pas comment le résoudre, que ce soit au niveau applicatif ou hardware load balancer.


SPOF : Single Point Of Failure.

Cordialement,

Comment tu compte faire le loadbalancing vis à vis des clients sans point de contact unique? Tu compte faire du round-robin DNS?

Par le fait de dire que c'est déjà géré en Java, j'entends par là que si tes serveurs jboss, par exemple, sont en cluster, alors normalement les sessions sont déjà partégées entre les nodes du cluster, ton client doit pouvoir s'adresser indifférement à chaque node et tu n'a pas besoin de te poser la question si deux serveurs servent le même client en même temps. Je trouve curieux en fait ce besoin d'empêcher de s'adresser à deux nodes.

Il existe aussi des solution de mémoire clusterisée en java, comme hazzlecast, que je n'ai jamais essayé, qui pourrais répondre à ta problématique de savoir si un verrou est libre ou pas, chaque noeud du cluster apportant sa liste de verrou à l'ensemble. http://hazelcast.com/


Désolé, je répond un peu sur la spec général, je n'ai jamais eu besoin de clustering

Citation:

---

Oui je cherche à faire du Load Balancing. Le fait d'avoir un unique Hardware Load Balancer n'est pas en contradiction avec le principe de Haute disponibilité (-> SPOF*) ?

---

Un problème à la fois !
Cette problématique est géré avec la notion de redondance et de cluster :

Citation:

---

Envoyé par wikipédia

In a high-availability server cluster, each individual server may attain internal component redundancy by having multiple power supplies, hard drives, and other components. System level redundancy could be obtained by having spare servers waiting to take on the work of another server if it fails.

---

Pour une gestion client/serveur "classique", ce problème de fiabilisé une machine se produit toujours, car tu attaque qu'une seule et unique IP du point de vue du client.
L'idée du "Load Balancing Cluster" et de n'avoir qu'un simple traitement à fiabilisé (la redirection), de manière indépendante du processus métier traité.

Cordialement,
Patrick Kolodziejczyk.

source :
http://en.wikipedia.org/wiki/Single_point_of_failure