Ordonnancement.org

TWS : Architecture

TWS fonctionne suivant un mécanisme basé sur un plan de production calculé à intervalles réguliers (par défaut 24 heures) et transmis aux différents agents. L’architecture TWS assure ainsi une indépendance de fonctionnement pour chacun des agents (Agents FTA ou Fault Tolerant Agent).

Le Plan est néanmoins dynamique et un nouveau traitement peut être soumis très simplement à n’importe quel moment (traitements "à la volée").

L’ensemble des fonctions TWS est sécurisé (interface LDAP possible) et accessible, soit via la console web graphique (client léger), soit via le mode ligne de commande (CLI) très complet.

Un agent peut être Master, Backup Master, Domain Manager ou FTA suivant les fonctionnalités activées.

Architecture TWS

 Fonctions Serveur

• Master

Le Master est constitué de la base de modélisation (DB2 intégré ou Oracle), du moteur TWS pour le calcul et la distribution du plan de production, du moteur d’application chargé de gérer et corréler les événements et la console graphique web 2.0 et du moteur de reporting pour la génération d’états paramétrables (SQL).

Le Master gère le Plan courant (production en cours), les plans historiques (archivés et qui permettent d’analyser une production passée) et les plans prévisionnels (pour déterminer la production sur une période future sans limitations).

Il dispose de la liste des agents générés à partir d’un ping régulier, dès que l’agent est accessible, le plan courant lui est envoyé.

Le moteur de gestion des événements permet de traiter les événements (réception en provenance des différents systèmes), les corréler (conditions "and" et "or", timeout,...) et déclencher des actions automatiques personnalisées (soumission d’un job, envoi d’un mail, réponse à un message, envoi d’un événement vers un système de supervision ou de HelpDesk, ...)

• Backup Master

Le Backup Master est un agent disposant de la fonctionnalité backup. Lorsque le Master est indisponible, la commande switch permet de promouvoir le Backup en Master. La base de données doit être accessible pour le calcul du plan de production suivant.

• Domain Manager

Un domaine est un regroupement de machines pouvant communiquer entre elles à travers le Domain Manager. Il est possible de définir une hiérarchie de domaine qui permet d’optimiser les communications réseaux.

Un Domain Manager a la capacité à résoudre les dépendances inter-systèmes sans nécessiter une communication avec le Master. Il est ainsi possible de définir un site distant comme entièrement autonome du Master une fois le Plan reçu.

* Si on possède des notions d’administration NT, on peut faire une analogie avec les domaines NT et les relations d’approbations.

 Agents

• Agents FTA (Fault Tolerant Agent)

Chaque agent dispose d’une copie du plan actif en local, en cas de coupure réseau, l’agent est autonome et peut continuer à exécuter et à suivre les traitements planifiés. les informations de suivi seront remontées vers le Master lors de la reconnexion du réseau. D’autre part, les traitements étant exécutés et pilotés par l’agent en local, le temps de latence est extrêment faible et le débit maximisé.

Lorsqu’une condition d’enchaînement est nécessaire (dépendance), elle est demandée à l’agent qui doit la poster. Si nécessaire, la dépendance sera résolue par le Domain Manager en charge de l’agent. En cas de coupure réseau, la condition reste en attente de rétablissement.

L’agent FTA est secondé par plusieurs composants intégrés en standard :

Un composant de détection des événements qui permet de détecter des événements non planifiés tels que l’arrivée et la persistance d’un fichier, un message dans un fichier texte, un changement d’état TWS (départ d’un job, perte de la connexion avec le Master, événement SAP, ...) et les remonter vers le moteur situé sur le Master.

Un composant de suivi des performances (monitoring) qui permet d’assurer en temps réel le suivi des caractéristiques et des performances de la machine (type de système, consommation CPU, mémoire, ...). Ce composant est utilisé par le scheduling dynamique (voir ci-dessous).

• Xagent (eXtended agent)

L’agent étendu est directement rattaché à un agent et dispose donc du plan local de celui ci, il est considéré comme une extension de l’agent.

De par son mécanisme, l’Xagent fait aussi office de connecteurs (SAP, Oracle Applications, ...) pour gérer en un point unique l’ensemble de la production.

• Mode Agentless

L’agent étendu permet de piloter des systèmes sans agents (mode agentless) si l’installation d’un agent n’est pas souhaitée. Ce mode est disponible pour les systèmes Unix et Linux et utilise les fonctions SSH.

 Architecture dynamique

Avec l’avènement de la virtualisation, et bientôt du Cloud Computing, il devient aujourd’hui nécessaire de pouvoir utiliser une architecture dynamique qui s’adapte en fonction de la charge. On peut ainsi imaginer l’ajout de machine virtuelle en supplément pour les traitements de fin de mois par exemple.

Avec ce type d’architecture, il n’est plus possible d’associer un traitement à un serveur, mais plutôt à des caractéristiques requises. On spécifiera par exemple qu’un traitement doit s’exécuter sur une machine de type x86 avec 2GO de mémoire disponible et TWS choisira automatiquement la machine disponible la plus adaptée (par exemple la plus rapide).

TWS offre pour ces fonctions une interface adaptée et un nouveau mode de définition des traitements basé sur le JSDL (Job Submission Definition Language), voir l’Open Grid Forum ici.

Ce mode de définition très souple va permettre à IBM d’enrichir facilement le type de traitements pilotés par TWS et le Fixpack FP1 sorti en mai 2010 ajoute le support de traitements de type FTP, SQL ou Web Services via le JSDL.

Note : Cette fonction était autrefois disponible au travers du module optionnel Tivoli Dynamic Workload Broker. Elle est désormais intégrée en standard à TWS depuis la version 8.5.1 sortie en décembre 2009.

Architecture TWS

Le document issu de http://Ordonnancement.org est mis à disposition sous les termes de la licence Creative Commons, vous pouvez l'utilisez dans vos documents à condition de citer l'auteur IBM, vous êtes aussi libre de le modifier. Par contre, vous devez le redistribuer dans les mêmes conditions et la commercialisation ne peut se faire qu'avec l'accord de l'auteur.