Multi-instances

Ce chapitre décrit une utilisation plus poussée et technique du déploiement de la solution SAINet afin de permettre une redondance et de meilleures performances grâce à la répartition de charge.

Le schéma ci-dessous représente un exemple d’architecture possible de la solution:

Dans cette configuration, le Load balancer possède une adresse publique qui sera utilisée directement par le client riche et le client Web.

De manière générale, un portail SAINet doit être accessible publiquement et pouvoir communiquer avec le serveur SAINet. Par conséquent, il est mis dans une zone DMZ.

La configuration de ce réseau dépend de chaque installation et relève du service informatique.

C’est le point d’entrée principal de SAINet. Il s’agit d’une machine et/ou une application qui va simplement rediriger les requêtes sur une des instances du serveur SAINet en arrière-plan.

Le nom de l’instance est définie par la propriété server.sainet.instance.name. Chaque instance doit porter un nom différent afin de pouvoir être identifiée de manière unique.

Afin de pouvoir effectuer cette redirection, l’instance du serveur SAINet qui répond à une requête va toujours injecter le header Sai-Server-Instance. Ce header doit ensuite être transmis en retour au client lors de la réponse par le Load balancer. Pour les prochains appels, le client injectera ce header dans la requête afin de permettre au Load balancer de rediriger l’appel correctement.

En résumé, si le header Sai-Server-Instance est présent (et que l’instance est disponible), le Load balancer redirige la requête sur l’instance mentionnée. Dans le cas contraire, le Load balancer est libre de rediriger la requête vers l’instance qu’il souhaite.

Chaque instance doit avoir une vision de la GED en accord avec la base de données. Dans l’exemple ci-dessus, les deux instances accèdent au même partage réseau et voient donc les mêmes fichiers.

Il est nécessaire de définir les propriétés relatives à la GED (sainet.fs.root.ged ou SAINET_EDMS_GED) afin de préciser l’emplacement de la GED.

Les instances doivent accéder à la même base de données. Cela est nécessaire car certaines données doivent être communes entre les instances (typiquement pour les verrous afin d’informer un utilisateur qu’un autre est en train de travailler sur le même enregistrement).

Lorsque plusieurs instances doivent être installées, l’instance MASTER doit être installée en suivant la procédure normale. Il est recommandé d’installer la base de données ainsi que la GED sur un serveur dédié afin que toutes les instances pointent dessus.

Pour chacune des instances SLAVE, la procédure suivante doit être appliquée:

• Définir le type d’instance à SLAVE ainsi que son nom (voir ici).
• Définir les variables permettant d’accéder à la base de données du MASTER (voir ici).
• Ne pas configurer le mount/volume pour accéder à la GED du MASTER, ni rediriger la GED. La création des fichiers doit être purement locale lors de l’installation.
• Effectuer l’installation initiale. La base de données ne sera pas touchée et les dossiers locaux seront créés.
• Créer le mount/volume pour accéder à la GED du MASTER ou son chemin d’accès ([SAINET_EDMS_GED](https://doc.sai-erp.net/080_doc_system/090_configuration.html#configuration-edms)).
• Redémarrer l’instance SLAVE.

Le fonctionnement des mises à jour en mode multi-instances et décrit ici.