Serveurs à haute disponibilité

Les serveurs à haute disponibilité s'exécutent de façon légèrement différente des serveurs individuels.

Tous les serveurs utilisent la même base de données et un partage de fichiers commun. Le partage de fichiers est utilisé pour les journaux et plusieurs autres répertoires, notamment logs, var/email, var/plugins et var/repository. Chaque serveur gère également individuellement certaines informations de configuration, telles que les ports et les hôtes. La base de données est utilisée pour les informations de configuration, les données d'exécution, etc.

Etant donné que les serveurs partagent la base de données, ils s'exécutent tous dans le même intervalle.

Certains propriétés de configuration restent sur le serveur, comme les informations de base de données et de connexion JMS. La configuration de la base de données est traitée lors de l'installation du produit ; aucune configuration supplémentaire n'est requise après l'installation.

Importation de fichiers (CodeStation)

Tous les serveurs recherchent les modifications des versions de composant. Les intervalles d'interrogation sont spécifiés par un paramètre configuré par l'utilisateur (15 minutes par défaut). La base de données traite la synchronisation du serveur : avant d'écrire des données dans le référentiel, un serveur acquiert un verrou dans la base de données. Les heures d'interrogation sont réinitialisées une fois un travail terminé.

Evénements

Les événements sont traités par le serveur qui les déclenche.

Moteur de flux de travail

Les flux de travail se composent d'activités. Les activités peuvent être exécutées de façon séquentielle, en parallèle ou selon une combinaison de ces deux types d'exécution. Un flux de travail classique se compose de plusieurs activités séquentielles, par exemple :

Pour les communications reposant sur JMS, les agents peuvent être configurés de plusieurs façons :

Tous les serveurs interrogent constamment les flux de travail en instance ; par conséquent, n'importe quel serveur peut initier le flux de travail. Le serveur qui acquiert ce flux de travail exécute les tâches suivantes :

  1. Il crée une instance d'environnement d'exécution de l'activité A et acquiert un verrou de base de données.
  2. Il enregistre la commande permettant l'envoi dans la base de données.
  3. Il envoie la commande à l'agent sur JMS.
  4. Il libère le verrou de base de données.

Une fois le travail terminé, l'agent envoie un message de réponse sur JMS. Le message est écrit dans la base de données (par l'un des serveurs) et l'activité suivante est démarrée (par l'un des serveurs). Le serveur qui a démarré l'activité B exécute les mêmes étapes que celles décrites précédemment.

Dans le flux de travail simple esquissé ici, les activités peuvent toutes être traitées par le même serveur ou par des serveurs différents (ou une combinaison). Bien entendu, il en irait de même si ce flux de travail comportaient trois activités parallèles.

Un flux de travail d'application est géré par un enregistrement unique dans la base de données (une seule unité d'exécution traite un flux de travail simultanément).

Gestion des défaillances

Lors du traitement d'une application, les échecs de commande sont signalés dans le flux de travail. L'auteur de l'application est en charge de la gestion des erreurs. La restauration de composant peut être gérée avec une commande/des étapes de restauration. La restauration, telle qu'appliquée ici, consiste à réinstaller une version de composant antérieure.

Si le serveur est défaillant alors qu'un agent exécute une commande, le maillage JMS affecte le flux de travail à un autre serveur.

Si un agent est défaillant ou qu'il disparaît lors de l'exécution d'une commande (n'oubliez pas que l'échec d'une étape n'entraîne pas l'échec de l'agent lui-même), le serveur suppose que la commande est toujours en cours d'exécution ; il n'existe pas de délai d'attente automatique. Normalement, il n'est pas possible d'affecter un intervalle de délai d'attente.


Commentaires en retour