Conception d'application multi-sites

Bonjour à tous !

Voilà, il se trouve que je me trouve à nouveau devant une problématique que j'ai déjà rencontré en termes d'architecture, et j'aurais aimé avoir un retour d'expérience, savoir ce que vous préconiseriez, si vous avez déjà rencontré ce genre de cas ce que ça a donné ...

Expression synthétique du besoin :

- Le client a n sites (ou filiales) qui utilisent la même application de gestion
- Chaque site DOIT être totalement indépendant (le client ne peut se permettre une indisponibilité en cas d'indisponibilité d'accès au net) ce qui exclut toute architecture totalement centralisée
- Les données de référence de l'application sont gérées en central et répliquées dans les différents sites, mais selon certaines règles de gestion les sites peuvent modifier certaines données.
- Tous les sites utilisent les mêmes données de référence
- Chaque site peut être paramétré (activation de modules logiciels etc ...)
- Les sites ont des données propres, qui peuvent potentiellement être visibles des autres sites
- Le client a besoin d'une application centrale qui donne une vue consolidée des données locales
- Les besoins du client vont certainement évoluer fortement donc les problématiques de maintenance et de deploiement sont essentielles.

La technologie employée est relativement annexe dans la problématique (même si dans le dossier que je traite elle a déjà été définie par le client).

Merci d'avance pour vos idées / réponses :-)

Ch'tig

Citation:

---

Envoyé par chtig

- Chaque site DOIT être totalement indépendant (le client ne peut se permettre une indisponibilité en cas d'indisponibilité d'accès au net) ce qui exclut toute architecture totalement centralisée

---

Bah déja, a part avoir une copie en local des données de référence sur chaque site, je ne vois pas de solution

Citation:

---

Envoyé par chtig

- Les données de référence de l'application sont gérées en central et répliquées dans les différents sites, mais selon certaines règles de gestion les sites peuvent modifier certaines données.
- Tous les sites utilisent les mêmes données de référence

---

Alors la, probleme: Que se passe-t-il lorsqu'un site modifie les données de ref et que les autres sites utilisent ces données ? Petit conflit, gros soucis....
P-e mettre un mecanisme de verrou exclusif sur tous les sites pour ce type de modif....

Citation:

---

Envoyé par chtig

- Chaque site peut être paramétré (activation de modules logiciels etc ...)
- Les sites ont des données propres, qui peuvent potentiellement être visibles des autres sites

---

potentiellement visibles + sites indépendants => replication en local sur le site, comme les données de ref et avec les memes problemes de synchro, update, ...

Citation:

---

Envoyé par chtig

- Le client a besoin d'une application centrale qui donne une vue consolidée des données locales

---

De TOUTES les données locales ? Arg! Si la contrainte "sites indépendants" est tjrs viable, alors encore replication... :aie:

Citation:

---

Envoyé par chtig

- Les besoins du client vont certainement évoluer fortement donc les problématiques de maintenance et de deploiement sont essentielles.

---

Font ch..r ces clients :mrgreen:

Bref, la contrainte la plus forte c'est quand meme "sites indépendants". Faudrait essayer de la faire sauter pour la visibilité des données locales des autres sites et la vue consolidée de l'application centrale. Sinon ca veut dire des repliques partout !!!! re-arg!

Salut !

Déjà merci pour ta participation, je commençais à désespérer :oops:
Je suis assez d'accord avec toi, les clients sont pénibles ;-)
D'autant plus pénible que tu trouves plein de gentils commerciaux et autres consultants qui te disent "mais pas de souci monsieur, le web c'est génial ça permet de tout faire".

Effectivement, la contrainte la plus forte c'est l'indépendance totale des sites. A mon sens, dans ce type de projet, le client doit mesurer l'importance d'une telle décision, et envisager la possibilité d'une réelle centralisation avec mode dégradé en local (genre que lecture etc ...). J'ai eu par le passé un VRAI cas où ce besoin ne pouvait pas être détourné, car la qualité des connexions réseau était vraiment pitoyable, et pas améliorable (en gros plein de sites perdus au fin fond des campagnes où il y a même pas l'électricité correctement).

Le souci ici c'est clairement les problèmes de réplications des données dans tous les sens, avec conflits potentiels et tout le toutim.
Une réplication db ? Pas envisageable à mon sens, dès qu'on a plus d'une dizaine de sites je suis convaincu qu'on va tout mettre par terre sinon.
Un EAI ? Oui, mais bon là ya un sacré boulot de développement des interfaces ....
Un "simple" gestionnaire de queue ? Je ne sais pas trop, je connais mal ...
Solution WEB ? Solution Client/Serveur ? Dans l'absolu, pour ce genre de produit, je dirais plutôt client/serveur parce que je vois pas l'intérêt de faire du web et de le déployer dans n sites ...

Voilà, quelques bouts de réflexion, mais justement ça serait cool d'avoir des réactions :-)

Citation:

---

Envoyé par chtig

Salut !

Déjà merci pour ta participation, je commençais à désespérer :oops:

---

Pas de probleme... tant qu'il s'agit de parler et que ce n'est pas moi qui met en oeuvre.... :D

Citation:

---

Envoyé par chtig

Une réplication db ? Un EAI ? Un "simple" gestionnaire de queue ? Solution WEB ? Solution Client/Serveur ?

---

Je suis d'accord pour eviter une vraie replication de db, trop lourd !

Par contre, on peut p-e creer des repliques "légères" ne contenant que les données utiles. Comment recupérer ces données ? je vois bien une communication inter-site par WebService, du type Query/Response.

On peut aussi utiliser les WebService pour la mise a jour des données. Apres il faut trouver un mecanisme pour resynchroniser tous les sites...

Eventuellement, les web services peuvent être intéressants, mais il ne s'agit là que de la méthode de discussion avec les bases de données, pas vraiment de la stratégie de discussion.
Notamment, dans le cas des updates possibles de chaque côté, l'EAI avec réconciliation devient à mon sens inévitable ...

Oui, je pense que l'EAI est la seule solution envisageable avec les contraintes citées.

Est-ce qu'une solution de type Cluster de serveurs d'application et Cluster de base de données ne permettrait pas d'avoir non pas l'indépendance mais un niveau de tolérance aux pannes acceptable.
Dans le cluster de serveurs d'applis, on peut imaginer au minimum une machine physique par site. Au niveau du réseaux télécom, il est aussi possible d'avoir physiquement plusieurs liens physiques vers les différents groupes de machines ?

Je suis pas sur que le Cluster se dégrade en plusieurs StandAlone lorsque le reseau est coupé, puis qu'il reconsolide les donnée lorsque le reseau revient :roll:

Même refléxion que pseudocode, là je ne connais pas assez bien pour savoir, mais j'avoue douter que ça se passe de manière magique en cas de coupure réseau puis rétablissement ...

Permettez moi de penser que vous ne connaissez effectivement pas le fonctionnement d'un cluster.
Un cluster synchronise ces noeuds automatiquement (cluster serveur d'appli ou cluster de DB). Côté client, la génération d'un proxy dans le cas d'un cluster, génère un proxy intelligent. Ce proxy intelligent est capable d'orienter les appels vers le noeud le plus adéquate en fonction de la stratégie de répertition de charge. Il est aussi capable de réorienter les appels quand un noeud se plante.
En mettant les noeuds dans des sous-réseaux différents, on se prémuni aussi de défaillances réseaux.
Notez qu'il n'y a pas de problématique du genre "mais que se passe t-il quand un noeud redémarre?", c'est le cluster qui prend tout en charge (pas d'inquiétude ici, cela fait longtemps que les clusters savent fonctionner !!!).

Citation:

---

Envoyé par ego

Côté client, la génération d'un proxy dans le cas d'un cluster, génère un proxy intelligent. Ce proxy intelligent est capable d'orienter les appels vers le noeud le plus adéquate en fonction de la stratégie de répertition de charge.

---

Ca c'est du Load-Balancing.

Citation:

---

Il est aussi capable de réorienter les appels quand un noeud se plante.
En mettant les noeuds dans des sous-réseaux différents, on se prémuni aussi de défaillances réseaux.

---

Ca c'est du Fail-Over.

Citation:

---

Envoyé par ego

Un cluster synchronise ces noeuds automatiquement (cluster serveur d'appli ou cluster de DB).

---

Perso, j'imagine mal comment un cluster d'appli ou de BdD peut faire un "merge" automatique de données, sans avoir de connaisance du metier :roll:.

Tu as raison sur le failover et load-balancing mais ce que j'essaye de vous présenter c'est une solution qui rendent caduques certaines exigences (indépendance) décrites à l'origine du post. Car comme tu l'as dit, faire plein de synchro, dur dur.

Citation:

---

Envoyé par ego

Tu as raison sur le failover et load-balancing mais ce que j'essaye de vous présenter c'est une solution qui rendent caduques certaines exigences (indépendance) décrites à l'origine du post. Car comme tu l'as dit, faire plein de synchro, dur dur.

---

Oui c'est vrai que l'exigence "Chaque site DOIT être totalement indépendant" est un poil contraignante :aie:. Il faudrait attenuer cette contrainte par un mode "degradé" ou seul la lecture des données de ref est possible, mais pas les updates ou les acces inter-site.

[Hors Sujet] @ego: super ton tuto sur les use-case :ccool: [/Hors Sujet]

S'il reste nécessaire de faire des réplications, peut être faut-il regarder sur ce que savent faire les DB en natif, je ne connais pas super bien cette partie mais je crois que par exemple avec Oracle, on peut définir des DB esclaves qui servent de mirroir d'une base maitre

Plusieurs BD savent faire du réplicat en natif (Oracle, SqlServer, et même Access), mais c'est un chouilla le bazar si un réplicat pert sa synchro. En clair, on est obligé de créer un nouveau réplicat et donc de rebalancer toute la base.

Au moment de la synchronisation, on peut demander un rapport d'erreur (cad les données d'un site qui ont été éjectées parce qu'un autre site en a mis de plus récentes ou plus anciennes suivant la politique de gestion des conflits).
Se pose donc le pb de gérer tout ça, plus ou moins à la main.

Et cela pose un pb supplémentaire : quelle est la volumétrie des données ? (de toute la base / de ce que chaque site a besoin / des mises à jours + suppressions)

J'avais par ailleurs travaillé sur une maquette (le contrat n'as pas abouti) pour un client ou, en mode dégradé :
- il était en lecture seule + ajout,
- il stockait ses modifs et suppressions.
Quand le site central "revenait", l'appli faisait la comparaison entre le site central et la base locale sur les enregistrements à modifier. S'il y avait un écart, l'appli le signalait à l'utilisateur (avec un double écran : "données actuellement présentes sur le site" vs "données telles que vous aviez souhaité les modifier")

Yvan

Merci à tout le monde pour la participation !
En fait, comme je le disais au début, je voulais débattre du problème en général car ce n'est pas la première fois que je rencontre ce type de contraintes.
Seulement, là, la nécessité de mettre à jour les données existantes dans tous les cas (y compris perte du réseau vers le site central) est vraiment importante, car il s'agit de l'application centrale du client sur laquelle presque tout le monde travaille, et cette application a pour but de gérer des dossiers qui ne font que s'étoffer. Donc utiliser l'application, c'est dans 1 cas sur 100 créer un dossier, 99 cas sur 100 en enrichir un existant.

Mon problème reste assez entier et je ne vois pas de réelle bonne solution. La volonté d'une application par site n'est pas fondamentalement contraignante, mais la volonté d'une DB par site est beaucoup plus embêtante.

Avez-vous déjà mis en place de bons systèmes (ETL, EAI, autres ...) qui permettent de faire du merge de données en prenant en considération les défaillances possibles du réseau ?