Ordonnancement des traitements informatiques

02. TWS : Présentation

IBM — 2010-07-17T12:38:00Z

La dernière version sortie en décembre 2009 termine un cycle de développement démarré en 2006 et permet à IBM de proposer une solution complète et intégrée entièrement pilotable par la nouvelle console graphique en mode web.

TWS se positionne comme une solution d'ordonnancement conçue pour gérer à la fois les travaux planifiés et les travaux non planifiés sur l'ensemble des systèmes de l'entreprise.

TWS supporte les environnements Linux, Unix, Windows, AS/400, z/OS, ainsi que le pilotage de SAP ou Oracle E-Business Suite avec le module additionnel TWS for Applications.

Principes de base

Planification

Basé sur une architecture de type Plan, le moteur TWS calcule pour chaque cycle de production (24 heures par défaut, mais jusqu'à 14 jours) le plan de production qui sera ensuite transféré à chacun des agents. Le Plan contient l'ensemble des traitements et leurs caractéristiques (dépendances, station de travail, caractéristiques horaires, ...) et permet à chacun des agents ou à chaque contrôleur de domaine de fonctionner de façon autonome même en cas de perte de connexion avec le serveur.

Gestion événementielle

La nécessité de pouvoir échanger avec l'extérieur et intégrer des événements non planifiés (réception d'un fichier par exemple) est assurée par un système complet où chaque agent est à même de détecter des événements externes, de les transférer au moteur de corrélation qui décidera d'actions automatiques en fonctions de règles et de conditions prédéfinies.

Interfaces

Console Web graphique

Depuis la version 8.5.1, TWS propose une console graphique en mode Web, la TDWC (Tivoli Dynamic Workload Console), qui permet d'assurer l'ensemble des fonctionnalités du produit, de la modélisation au reporting en passant par le pilotage. Il s'agit d'une console 100% web, autrement dit, aucune installation d'un client n'est nécessaire et la console propose toutes les fonctions de TWS à partir d'un simple navigateur (Firefox ou IE préconisés) rendant ainsi aisé le pilotage à distance (en astreinte par exemple).

Il s'agit donc d'une console utilisant les standards Web (liens hypertextes, URLs, ...) par opposition à une interface Microsoft (IBM se positionnant en défenseur de solutions non propriétaires, notamment vis à vis de Microsoft).

Mode Ligne de Commande (CLI)

IBM a comme stratégie de toujours proposer un mode ligne de commande pour pouvoir communiquer avec des solutions externes. TWS dispose donc d'un mode CLI complet, sécurisé et accessible à distance.

API / Interface JAVA

IBM propose également un jeu d'API qui va permettre d'utiliser les fonctions TWS via une API documentée ou via des Web Services.

L'ensemble des accès est sécurisé, à la fois par un mécanisme de rôles, mais également en fonction de critères logiques tels que des règles de nommage. Enfin, les actions sont auditées et conservées pour analyse ultérieure.

Principes d'utilisation

Le Job

Le job est l'unité élémentaire qui correspond à une tâche donnée. Il est notamment composé du programme ou du script à lancer et de son serveur associé. Un job contient également le login à utiliser, le ou les codes retours valides et les opérations de reprise en cas d'erreur.

Le Jobstream

Le jobstream est une unité logique de traitement. Le jobstream contient notamment les dépendances inter-jobs ou de ressources et le cycle d'exécution.

Le cycle d'exécution

Il est défini par l'utilisation de calendriers (par exemple les jours fériés) et de règles (tous les jeudis, le dernier jour ouvré du mois, ...). Les différents cycles sont combinés entre eux (mode inclusif ou exclusif) pour déterminer précisément la date d'exécution d'un traitement.

Les mécanismes de TWS permettent également de gérer les heures d'été/heures d'hiver et les différents fuseaux horaires.

Les ressources

TWS permet également de prendre en compte la disponibilité de ressources telles qu'un lecteur de bande ou une imprimante, ainsi que la validation d'actions par un opérateur.

Pilotage

La console TDWC permet d'effectuer le suivi et le pilotage entièrement à partir de l'interface graphique.

Reporting

TWS propose désormais en standard un moteur de reporting graphique intégré. Outre les requêtes fournies avec le produit, il est possible d'effectuer ses propres requêtes SQL. Les données peuvent être exportées vers un tableur (.csv) ou un gestionnaire de projets (.xml) et IBM préconise d'utiliser un gestionnaire de projet externe pour les analyses de type Pert ou Gantt.

Fonctions avancées

Workload Service Assurance

Les fonctions de Workload Service Assurance permettent d'introduire la gestion des SLA (contrats de service) au coeur de la Production. Il devient ainsi possible de définir l'heure de fin « au plus tard » d'un traitement défini comme critique.

Durant son exécution, le traitement, mais surtout l'ensemble des prédécesseurs, sera analysé, supervisé et comparé par rapport aux statistiques d'exécutions précédentes, pour déterminer le risque de retard potentiel du job final par rapport à un traitement en amont (analyse du chemin critique).

En cas de retard potentiel, TWS peut automatique augmenter la priorité des traitements concernés, indiquer le risque aux opérateurs au travers d'une vue spécialisée, ou envoyer une alerte.

Scheduling dynamique

Précédemment proposé comme un composant optionnel, Tivoli Dynamic Workload Broker a été intégré à TWS à partir de la version 8.5.1 pour proposer les fonctions de scheduling dynamique en standard.

Chaque agent TWS surveille en temps réel les performances du serveur sur lequel il est installé et remonte les informations vers le serveur TWS. Le serveur TWS dispose ainsi d'une vision complète de l'ensemble des agents actifs, de leurs caractéristiques (type de CPU, mémoire) et de l'utilisation des ressources.

Les traitements quant à eux, ne sont plus associé à 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 en fonction de la stratégie d'optimisation choisie. On pourra par exemple choisir la stratégie "Maximize" pour l'utilisation maximale des ressources d'une machine, dans ce cas une autre machine du pool ne sera utilisée qu'en cas de surcharge.

Pour ces fonctions, TWS propose 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 ou ici.

TWS offre ainsi en standard les fonctions nécessaires pour tirer partie des environnements dynamiques qui commencent à entrer en production grâce aux développements des solutions à base de virtualisation.

Nouveaux Services

Ces choix confirment la volonté d'IBM de transformer l'infrastructure traditionnelle en architecture orientée service, le principe étant de remplacer les appels systèmes type script ou ligne de commande par des appels de type services.

TWS offre ainsi la possibilité d'intégrer l'appel à des Web Services, des applications Java ou même directement des ordres SQL ou des transferts de fichiers via ftp.

Il ne fait nul doute que le nombre de services proposés est amené à se développer dans le futur avec également la possibilité de créer des services personnalisés et adaptés à chaque entreprise.

Conclusion

Les dernières versions de TWS ont apporté beaucoup de nouvelles fonctionnalités tout en conservant les bases du produit qui en font sa simplicité et sa fiabilité.

Un effort particulier a été fait par IBM qui livre toutes les technologies nécessaires avec la version standard de TWS, en faisant ainsi une offre complète et intégrée.

On peut toujours reprocher à IBM de ne pas livrer les "goodies" qui flattent et emportent l'adhésion, mais on ne peut que constater qu'IBM propose une solution fiable, simple, standardisée, extrêmement riche fonctionnellement et évolutive qui saura répondre à toutes les problématiques des entreprises, quelle que soit leur taille.

IBM décline clairement sa stratégie pour rester leader sur le marché du Workload Automation et ouvre la voie vers la production de demain basée sur les environnements virtualisés et le cloud computing.

Enfin, on peut noter que pour tous les clients sous maintenance, IBM intègre en standard un support 24/365 en cas de problème bloquant la production.

Pour toute information complémentaire, vous pouvez contacter directement le responsable produit pour la France à l'adresse suivante : philippe.rame@fr.ibm.com

03. TWS : Architecture

IBM — 2010-07-17T11:09:44Z

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.

Cet article fait référence à la version TWS courante 8.5.x en 2010.

04. TWS : Installation

IBM — 2010-07-17T10:54:46Z

Depuis la suppression des composants framework en 2006, l'installation d'un système TWS est devenue simple et rapide.

Installation du serveur

La première étape consiste à mettre en place la base de données utilisée par le logiciel, sachant que TWS utilise désormais une base standard du marché. Dans le cas de l'utilisation de DB2 (fourni sans surcoût), il suffit de lancer la procédure d'installation et de terminer en intégrant le numéro de licence fourni. Pour les clients préférant utiliser Oracle, l'installation est à la charge du client.

La seconde étape consiste à installer le serveur TWS. La procédure d'installation proposée installe automatiquement l'ensemble des composants du moteur (engine), à savoir le gestionnaire de Plan, le composant de distribution, le moteur de gestion des événements, le moteur de gestion de la console web et le moteur de scheduling dynamique.

L'installation de la console Web est la dernière étape pour finaliser l'installation du serveur. L'installation consiste en fait à installer l'application "Tivoli Dynamic Workload Console" sur le serveur. La console étant accessible via un navigateur Web, aucune installation n'est nécessaire sur les postes clients. Après un arrêt/redémarrage du moteur TWS, l'infrastructure serveur est opérationnelle et peut être accédée à partir d'un navigateur de type Firefox ou Internet Explorer.

Si l'on souhaite utiliser les fonctions de scheduling dynamique, on installera également en complément la console dédiée au langage JSDL.

Enfin pour rendre l'environnement opérationnel, on utilise la commande JnextPlan qui permet de créer le Plan initial.

Installation d'un agent

L'installation d'un agent est également très rapide et peut être automatisée (installation en mode silencieux). Après avoir spécifié ses caractéristiques et celles du serveur, l'installation se déroule automatiquement.

Une fois installé, l'agent doit être déclaré dans la base, soit en mode ligne de commande (CLI), soit directement à partir de la console Web.

L'agent sera opérationnel automatiquement dès la prochaine montée du Plan, mais il peut être activé instantanément en demandant une mise à jour du Plan (JnextPlan -f 0000).

L'installation d'une configuration simple serveur + agent est alors terminée.

05. TWS : Documentations

IBM — 2010-07-17T08:01:00Z

MàJ le 17 juillet 2010

Fidèle à sa politique d'ouverture et de support aux standards ouverts, IBM met à disposition du public l'ensemble de ses documentations sur son site web :

Manuels TWS (manuels produits multi-langues) :

- Redbooks TWS (documentations pratiques en anglais) :

06. TWS : Cursus de formation IBM

IBM — 2010-07-16T23:29:40Z

MàJ le 17 juillet 2010

IBM propose régulièrement des cursus de formation à TWS :

Cursus de formation TWS distribué

Cursus de formation TWS z/OS

IBM propose également une certification TWS

02. Agent open source pour Autosys : Mise en oeuvre

E. Angenault — 2010-05-27T13:58:28Z

Autosys

L'intégration de l'agent open source scheduler doit être transparente pour les équipes Autosys, on doit donc pouvoir gérer les traitements avec les outils d'Autosys, principalement les outils de pilotage.

Le principe est donc de disposer de l'ensemble des définitions dans le référentiel d'Autosys tout en ajoutant un minimum de modification pour l'exécution à distance.

Machine virtuelle

On va définir dans un premier temps, une machine virtuelle afin de lier la machine distante OSS avec l'agent Autosys. La machine virtuelle est la cible du traitement.

La machine virtuelle sert à préciser la machine relai sur laquelle on soumet le job tout en ayant une vue sur la machine distante. Ceci se fait par une machine virtuelle, dont le nom contient la machine relai, pointant sur la machine distante.

Code JIL

insert_machine: ATS-EXS-unitmpap01
 machine: atsprdweb04
 max_load: 100

La syntaxe respecte la norme de nommage des cibles tout en ajoutant un nouveau type : E qui signifie Externe à autosys.

La commande autorep -m ATS-EXS-unitmpap01 permet d'identifier les composants :

Machine Name Max Load Current Load Factor O/S
 _____________________________ __________ ______________ ______ 
 ATS-EXS-unitmpap01.atsprdweb04 100 0 ----

Ce qui signifie :

Machine virtuelle pour l'application ATS soumettant des jobs Unix à la machine unitmpap01 en passant par le relais atsprdweb04.

Définition du JOB

Le job autosys aura le format suivant :

 insert_job: ATSR-TSTOSS-EUX-Encapsulation job_type: c 
 box_name: ATSR-TSTOSS-B-Test_OSS
 command: $${ATS-OSS-UNX} hostname
 machine: ATS-EXS-unitmpap01
 owner: autosys
 permission: 
 description: "Lancement de la commande en passant par"
 std_out_file: >/tmp/test.log
 std_err_file: >/tmp/test.log
 alarm_if_fail: 0

Open source scheduler

On utilisera 2 agent open source scheduler, le premier est sur la même machine que l'agent autosys et est directement utilisé par le script comme un client, on l'appelera superviseur. L'autre installation est sur la machine distante, on l'utilisera simplement pour la l'exécution distante des commandes, aucun log n'est créé à distance, et la connexion est persistante dans le cadre de ce projet. On aurait pu aussi l'utiliser comme agent autonome et déléguer l'ensemble de la soumission.

Superviseur SUPERVISOR

Le superviseur est installé sur la même machine que l'agent Autosys et fera le lien entre l'agent Autosys et l'agent distant Open source scheduler. Il est nécessaire de mettre à jour le fichier de configuration pour définir les « process_class » indiquant les machines distantes : config/scheduler.xml

Job de test

Ce job de test permet d'exécuter une commande shell qui sera prise en compte dés sa création sur l'ordonnanceur. Ce job est multiplateforme et sera donc exécuté aussi bien sur unix que sur windows.

test.job.xml

Agent distant REMOTE

On ajoute le superviseur dans la configuration de l'agent pour remonter les informations dans la base de données dédiées à la partie open scheduler.

  udp_port = "5556"
 mail_xslt_stylesheet = "config/scheduler_mail.xsl"
 supervisor = "SUPERVISOR:5556" >

On ajoute ensuite l'adresse IP du superviseur pour lui permettre d'exécuter les commandes sur l'agent :

Utilisation du heartbeat

Le heartbeat permet à un script de réveiller régulièrement l'agent afin que ce dernier indique au serveur que le script est toujours en cours d'exécution. Si la surveillance est activée côté serveur, une alerte est renvoyée si le heartbeat n'arrive pas dans le temps imparti.

La mise en place est assez simple puisqu'il s'agit simplement d'envoyer un kill -USR2 à l'agent. Dans un script Autosys, la commande unix sera la suivante :

kill -USR2 $__jc_pid

Pour retrouver l'information du heartbeat d'un job dans la base de données, on peut utiliser la requête SQL suivante :

select
 job_name,
 status,
 heartbeat_interval,
 last_heartbeat,
 pid,
 jc_pid
 from
 jobst
 where
 status=1
 and job_name like 'JOB'
 order by
 last_heartbeat desc

Pour mettre en place la surveillance sur le serveur, il est nécessaire d'ajouter l'option Check_Heartbeat dans le fichier de configuration.

# Check job heartbeat every 2 minutes.
 Check_Heartbeat=2

Le test suivant concerne un job renvoyant un heartbeat régulier et souhaitant une alarme si le dernier heartbeat excède 5 minutes :

Code JIL

insert_job: ATSR-THEART-CUX-Test_Heart_Beat job_type: c 
 box_name: ATSR-THEART-B 
 command: sleep 600
 machine: atststtt01
 owner: auto_T01
 permission: 
 description: "Test du heartbeat"
 alarm_if_fail: 0
 heartbeat_interval: 5

Event_demon

[14:11:13.8414] [1] Checking Heartbeats...
 [14:11:24.0308] [3] EVENT: CHANGE_STATUS STATUS: RUNNING JOB: ATSC-TSTXIT-B 
 [14:11:24.3002] [1] EVENT: ALARM ALARM: MISSING_HEARTBEAT JOB: ATSR-THEART-CUX-Test_Heart_Beat

Demande de kill La demande de kill d'un traitement doit être prise en charge et relayé vers l'agent distant. La configuration Autosys ($AUTOUSER/config.INS) indique quels types de signaux sont envoyés :

# List of Signals to Send to a Job for the KILLJOB event
 KillSignals=2,9

Ce qui signifie qu'un kill -2 est envoyé puis un kill -9 si le précédent n'a pas répondu assez rapidement.

Si le signal 9 (SIGTERM) ne peut être récupéré, il est tout de même possible d'exécuter des commandes à la réception de l'avertissement SIGINT (demande d'interruption). Pour information, le SIGINT est similaire à un Control-C. La mise en place se fait en 2 temps :
indication de la routine en début de script
ajout de la routine qui relaira le kill sur l'agent distant.

Extrait du script ATS2OSS.pl

# Routage du signal INT 
 $SIG{INT} = "trapINT";
 …
 # sous programme de kill
 sub trapINT {
 print "===================================================================\n";
 print timestamp()."\n";
 print "DEMANDE DE KILL\n";
 print "-------------------------------------------------------------------\n";
 print sendmessage($mac,$port,"");
 unlink($file);
 print "===================================================================\n";
 print timestamp()."\n";
 print "FIN DE JOB - RETOUR AUTOSYS\n";
 print "-------------------------------------------------------------------\n";
 exit(-1);
 }

Gros plan sur Visual TOM

E. Angenault — 2010-02-22T09:31:55Z

Moteur d'évènement

Le changement majeur a été une refonte du moteur en supprimant l'ancien mécanisme basé sur du polling par un système évènementiel plus performant permettant ainsi de réduire fortement les temps de soumission.

Base de données

L'autre évolution a été de réduire l'utilisation de la base de données en déléguant la partie historique à une base externe, PostgreSQL. Pour rappel, la base de données est basé sur Codebase (famille xBase dont DBase II est l'ancêtre) or les principales critiques formulées contre VTom concernaient principalement les performances de la base de données.

La 4.2 permettait déjà de conserver un historique dans la base de données mais la 5.1 permet de sauvegarder directement ce type d'informations dans la base. La partie codebase ne concerne maintenant plus que ce qui est utile au moteur.

L'utilisation de Postgres permet de réduire drastiquement le volume de la base de données dédiés au moteur et consommateur de performances pour remplir une base dont le rôle principal est le stockage.

Est-ce suffisant pour éviter les réorganisations ? Ce n'est pas évident car les ajouts et suppressions d'enregistrements entrainent des zones vides qu'il faut de toute manière supprimer pour optimiser.

On notera que le bidouilleur se réjouira de pouvoir générer ses rapports directement en SQL sans impact sur sa production mais que du côté d'Absyss on préfère que le client fasse ses demandes de rapports auprès du support à travers les demandes d'évolutions afin d'en garantir la pérennité.

L'utilisation de la base de données a aussi permis la sauvegarde de données supplémentaires comme l'historique des actions avec la version 4.3 qui permet de disposer d'un audit.

Télé-diffusion

La télé-diffusion permet d'effectuer tout type de modification d'objet à distance et ceci à travers un simple fichier INI. Ce moyen de communication avec l'outil, présent en 4.2 et amélioré avec la 4.4, présente un réel intérêt pour l'administrateur qui pourra facilement interfacer ses outils.

Pour un exemple concret sur l'utilité du système voir le forum VTOMDEV.

Du point de vue de l'exploitant, il est indispensable de disposer d'un outil d'export générant un fichier de données dont le format est compréhensible par le format d'import car les modifications d'objets se font simplement par remplacement dans le fichier de données, évitant ainsi l'écriture de scripts.

La prochaine version de VTOM (5.3) offrira une interface ergonomique aux mécanismes de télé-diffusion pour simplifier la sélection des objets et automatiser les changements par des règles de substitution.

Ressources

VTOM est certainement l'ordonnanceur qui propose la plus grande diversité de type de ressource et la version 4.3 en a apporté une de plus : la ressource générique. La ressource est un élément fondamental de l'ordonnanceur puisqu'elle va permettre l'exécution de la tâche seulement si cette dernière dispose bien des moyens nécessaires.

Le principe de la ressource générique est simplement d'utiliser le résultat d'un script ce qui permet de définir n'importe quel élément de sa production comme un moyen d'exécution.

Client DMZ

C'est en version 4.4, qu'est apparu le client DMZ. Ce client ne fait aucune connexion vers le réseau interne et évite ainsi une ouverture de parefeu qui entrainerait un trou de sécurité. Ce type d'agent est vital pour une architecture sécurisée mais bien trop rare dans le catalogue des autres éditeurs pour qu'on le souligne ici.

Absyss propose différents composants logiciels afin de répondre aux différents types d'architecture, le client DMZ vient compléter une gamme qui contenait déjà différents types de serveurs (backup et départemental), d'agents comme le NET client, de connecteurs et d'interfaces utilisateurs.

Interfaces

VTOM dispose de différentes interfaces en plus de l'interface utilisateur, comme l'interface web, ISuperviser de la version 4.4, ou l'interface de conception, IGraphBuilder de la version 4.6.

La version 5.1 propose une nouvelle interface JAVA qui fait l'unanimité des utilisateurs grâce à son système de vues offrant ainsi des écrans optimisés en fonction de l'utilisateur.

Une gestion des utilisateurs par profil simplifie la gestion en affectant directement à chaque utilisateur un ensemble de droits.

Chaque utilisateur ouvre une session sur le serveur, ce qui permet à celui-ci de renvoyer en mode push toute modification à l'ensemble des utilisateurs. L'utilisateur voit en temps réel les modifications effectuées par les autres utilisateurs.

L'aspect prévisionnel est ajouté en 5.2 ainsi que les statistiques et les graphs intégrant des compteurs fonctionnels

La version 5.3 proposera des tableaux de bord récapitulant différents compteurs d'exploitation dans une vue globale afin d'évaluer d'un coup d'oeil l'état de sa production en distinguant les anomalies et les blocages sur l'ensemble de ses environnements.

Conclusion

VTOM bénéficie de mises à jour régulières et d'évolutions majeures annuelles pour aboutir à un produit performant et agréable à l'utilisation avec quelques options uniques mais qui se révèlent rapidement indispensables.

L'implantation de la société en France apporte un support de proximité qui se révèle plus efficace que celui des multinationales dont le support français est trop souvent réduit à l'état de relai.

Au niveau de l'architecture, les différents composants logiciels répondent à toutes les problématiques réseaux. L'utilisation de la base de données permet de bénéficier d'un historique des données sans impact sur les performances. L'interface Java permet une installation homogène quelque soit la plateforme. Des connecteurs pour les ERP Dynamics et M3 (Lawson), disponible dans la prochaine version, en plus des connecteurs standards (SAP, Peoplesoft...).

L'interface de la version 5.1 est une évolution majeure pour le produit, pour sa partie graphique et son mode push mais surtout pour sa prise en main. La facilité d'utilisation est visible pour l'exploitant à travers les vues mais elle simplifie aussi le travail de l'administrateur dés l'installation jusqu'à la gestion des utilisateurs.

Surveillance générique pour Dollar Universe

E. Angenault — 2010-01-21T15:21:23Z

La mise en place de la surveillance est extrêmement simple à réaliser dans la mesure où les fichiers nécessaires sont déjà dans le répertoire des binaires.

Voici les etapes :
Arrêt $U (non obligatoire)
on utilise la bibliothèque libuxspv_com.so au lieu de libuxspv.com dans uxexe/lib (on aurait pu tout aussi bien utiliser la surveillance patrol, tng, tivoli...)
on crée un fichier d'environnement uxsetenv_com dans $UXMGR

Modifications des liens

Connectez vous sur le noeud $U
Aller dans uxexe
Lister les bibliothèques de supervision :

cd $UXEXE/lib
 ls -rtl /libuxspv*

Ce qui nous donne :

-rwxr-xr-x 1 root other 6684 Dec 13 2005 libuxspv.so
 -r-xr-xr-x 1 root other 6684 Dec 13 2005 libuxspv.so_model
 -rwxr-xr-x 1 root other 10892 Dec 13 2005 libuxspv_tiv.so
 -rwxr-xr-x 1 root other 16016 Dec 13 2005 libuxspv_ito.so
 -rwxr-xr-x 1 root other 1560888 Dec 13 2005 libuxspv_pat.so
 -r-xr-xr-x 1 root other 13784 Dec 13 2005 libuxspv_com.so
 -rwxr-xr-x 1 root other 8360 Dec 13 2005 libuxspv_tv.so
 -r-xr-xr-x 1 root other 14204 Dec 13 2005 libuxspv_tng.so

$U appelle systématiquement libuxspv.so, le but du jeu est donc de remplacer cette bibliothèque par celle qui permettra de renvoyer les informations vers son outil de supervision.

Dans notre cas, on utilisera libuxspv_com.so qui correspond à la surveillance générique. Le changement peut être fait par simple copie ou par création d'un lien symbolique.

Exemple avec une création de lien :

rm libuxspv.so
 ln -s libuxspv_com.so libuxspv.so

Variables d'environnement

La configuration de la surveillance se fait à travers des variables d'environnement qui l'on stockera dans le fichier uxsetenv_com.

Contenu du fichier uxsetenv_com :

#!/bin/ksh
 #set -vx
 # -----------------------------------------------------------------
 # uxsetenv_com ? Environnement pour la supervision generique
 # -----------------------------------------------------------------
 # Description : Ce script positionne l'environnement necessaire au
 # fonctionnement de la supervision applicative generique de
 # Dollar Universe Non Stop Services.
 # -----------------------------------------------------------------
 export U_COM_SND_T=YES
 export U_COM_SND_I=YES
 export U_COM_SND_O=YES
 export U_COM_SND_W=NO
 export U_COM_SND_R=YES
 export U_COM_SND_E=NO
 
 export U_COM_WORD_R=Refuse
 export U_COM_WORD_E=Demarre
 export U_COM_WORD_W=Attente
 export U_COM_WORD_O=Horaire depasse
 export U_COM_WORD_I=Incidente
 export U_COM_WORD_T=Termine
 
 export U_COM_TRACE=n
 
 export UXSPV_MSGJOB=$UXMGR/U_SPV_JOB

Dans ce fichier d'exemple, on ne traitera pas les évènements des uprocs en cours de démarrage et celles en attente. Suivant vos besoins, vous pouvez ajoutez ou supprimer d'autres types d'évènements.

Le mode TRACE permettra de suivre la communication entre le $U et votre script de surveillance.

La prise en compte de ces variables se fera à travers l'uxsetenv puisque ce dernier est systématiquement chargé.

Fin du fichier uxsetenv :

# Ajout de la supervision generique
 . $UXMGR/uxsetenv_com

Script de supervision

Le script de surveillance proprement dit est indiqué par la variable globale UXSPV_MSGJOB.

Pour effectuer un minimum de modification sur les fichiers d'origine, j'ai simplement inclus un appel vers mon script Perl.

Contenu du fichier U_SPV_JOB :

#!/bin/ksh
 #set -vx
 # -----------------------------------------------------------------
 # U_SPV_JOB ? Supervision generique
 # -----------------------------------------------------------------
 # Description : This script receives a message each time a status
 # transition is detected for a Dollar Universe job. This script
 # sends the incoming message to your supervision tool.
 # -----------------------------------------------------------------
 # -----------------------------------------------------------------
 # Positionnement de l'environnement Dollar Universe
 . $UXMGR/uxsetenv
 
 # Environnement TNG
 AGENTWORKS_DIR=MON_AGENT_TNG
 export AGENTWORKS_DIR
 if [ -f ${AGENTWORKS_DIR}/scripts/envset ]
 then
 . $AGENTWORKS_DIR/scripts/envset
 fi
 
 # Positionnement de variables, eventuellement en fonction du contexte
 echo ---------------------------------------------------------------->>$UXLOG/u_spv_job.log
 echo $1 >> $UXLOG/u_spv_job.log
 exec $UXMGR/spv2tng.pl "$1" >>$UXLOG/u_spv_job.log
 
 # -----------------------------------------------------------------

Dans cet exemple, j'utilise l'exécutable awtrap fournit par CA, cet outil se trouve dans un répertoire "MON_AGENT_TNG", cela peut être un autre outil (ou bien un envoi de mail sur des jobs critiques ou la création d'un log particulier...), dans tous les cas on profite de ce script pour initialiser l'environnement.

Script de connexion

Le script perl se charge de traiter l'information fournie par le SPV pour l'envoyer en trap. Le script perl recupère les infirmations, puis fais un uxlst ctl qu'il envoie sous forme de trap. Quel est l'interet de refaire un uxlst ctl ? Simplement pour avoir l'ensemble des informations (jalon, noeud, user...).

Les 2 méthodes renvoient la même chaîne de caractères, mise à part que la deuxième complète les espaces avec les données du suivi d'exploitation.

L'aspect performance est discutable et la mise en place déconseillé pour les noeuds chargés mais dans l'exemple est intéressant dans la mesure où l'on souhaite remonter nu maximum d'informations.

Script spv2tng.pl :

#!/usr/bin/perl
 @Infos = split(" ",$ARGV[0]);
 
 # 2 formats : avec ou sans uproc
 if ($#Infos==11) {
 ($dummy, $status, $job, $ses, $upr, $mu, $date, $time, $nupr, $nses, $soc, $s) = @Infos;
 }
 else {
 ($dummy, $status, $job, $upr, $mu, $date, $time, $nupr, $nses, $soc, $s) = @Infos;
 }
 
 # On en fait une ligne de suivi d'exploitation
 # BIRJGPSG BIRGPSG T_BIR01 TERMINE 20070413 1100 20070413 1100
 birexptt SYS_BATCH 2107 100 0009018 0016326 20070413 birexplo 000 000 99 00162
 21
 # Methode 1 : sprintf. probleme : il manque des infos (reprise, jalon...)
 #$res = "sprintf(" %10s %10s %10s %21s %10s %4s %10s %4s %10s %31s %6s %03d %07d %07d %1
 0s %12s %03d %03d %02d %07d");
 
 # Methode 2 : on refait un uxlst
 $uxlst = `$ENV{UXEXE}/uxlst ctl full ses=$ses upr=$upr mu=$mu nupr=$nupr nsess=$nses`;
 
 @UX = split("\n",$uxlst);
 $line = $UX[4];
 
 ##########################################################
 # Envoi de trap
 
 $host = 'DESTINATAIRE DES TRAPS';
 
 print STDERR "$line\t$host\n";
 `awtrap -h $host -p 162 -c public 1.3.6.1.4.1.311 6 . 1.3.6.1.4.1.311 -s "$line"` ;

Du côté serveur, on devrait récpetionner des messages de ce type : %CATD_I_060, SNMPTRAP: -c public 311 IP_SOURCE MACHINE 6 0 11:56:52 2 OID: 1.3.6.1.4.1.311 .iso.org.dod.internet.private.enterprises.microsoft VALUE: IU_TEST TEST T_IU INCIDENTE 13/04/2007 1743 13/04/2007 1743 global SYS_BATCH 0067 100 0000271 0000303 13/04/2007 uniexp_a 000 000 00 0000313 OID: 1.3.6.1.3.1057.1 .iso.org.dod.internet.experimental.1057.1 VALUE: IP_SOURCE

Langue

E. Angenault — 2009-10-18T09:23:25Z

Dollar Universe propose différentes langues pour son interface.

- 00. Aspects généraux

Evaluer Autosys

E. Angenault — 2009-10-18T08:37:53Z

CA fournit de nombreuses plaquettes marketing sur le produit et sur le futur mais aucune information technique n'est publique, il est nécessaire de passer par une présentation avant-vente à moins que vous ne soyez déjà client CA.

- 00. Aspect généraux