Ordonnancement.org

Intégration d’Open Source Job Scheduler

Les conditions du projet

Le but est le remplacement complet du serveur Control-M par un ordonnanceur qui pourra s’installer sur le serveur d’application et qui sera capable de reprendre l’ensemble des tâches. Il faut un produit qui consomme peu tout en proposant un niveau de fonctionnalités équivalent.

TWS reste l’outil principal d’automatisation, il faudra donc faire communiquer TWS avec Open Source Job Scheduler sans faire de changement sur TWS, les séquences définies sur TWS restent inchangées.

Le système n’est pas sans rappeler une précédente série d’articles que je vous invite à consulter : Open Source Scheduler sur une architecture Autosys

La politique de sécurité du site doit être respectée, par exemple en évitant une connexion ssh sur le serveur TWS.

Le budget est réduit et le forfait proposé est de 60 jours. A la fin de la bascule, une économie de 80% doit être réalisée et fournir un retour sur investissement inférieur à 1 an.

Architecture en place

Ancienne architecture

Le cluster "logistique" est composé de deux serveurs d’application, un pour la production et le second pour développement qui fait aussi office de backup.

L’ordonnancement est géré par Control-M. Il est installé sur un serveur séparé et prend en charge la communication avec TWS. Le serveur Control-m prend en charge l’ensemble des applications de logistique.

La communication TWS est contrôlé par un agent TWS qui tourne sur le serveur Control-M.

Nouvelle architecture

Nouvelle architecture

On conserve les serveurs d’applications sur lesquels on installe Open Source Job Scheduler qui devient l’automate. Une instance d’Open Source Job Scheduler est installée par serveur et reprend les tâches du Control-M ainsi que la communication avec TWS.

Les objets à créer sur le nouvel ordonnanceur sont les suivants :
 600 traitements
 250 séquences
 100 lancements

TWS lance les traitements à travers un agent par appel des services web Open Source Job Scheduler.

Pour la partie base de données, une base Oracle 11g avec 50 de tablespaces est utilisée par les 2 instances.

L’installation des agents se fait en mode batch, un package contenant les binaires et des fichiers de configuration dont seulement quelques paramètres diffèrent comme, par exemple, le nom de la machine. Ce mode d’installation garantie l’homogénéité sur les différentes installations et une réinstallation facile du produit en cas de problème sur la machine.

Migration

Control-M propose nativement un export XML, on obtient un fichier XML par table. Open Source Job Scheduler utilise le même type de format.

L’automatisation est réalisée par des feuilles de style XSLT et est contrôlée par ANT. Ce système est très ingénieux car il utilise les outils appropriés à la manipulation des fichiers XML.

Le processus est en 6 étapes :
 La configuration à partir des données XML extraites de Control-M
 La collecte des données pour construire les modèles génériques
 La construction de ressources additionnel pour Job Scheduler (synchroniosation, verrous, ...)
 La génération des différents objets (traitements, séquences, ordres...)
 Une version du live folder pour les mises à jour
 Le déploiement sur les serveurs d’application (par le live folder)

L’adaptation manuelle à été inférieure à 5%.

Conclusion

Open Source Job Scheduler est tout à fait adapté dans ce genre de situation, il est assez léger et assez souple pour s’intégrer dans une architecture existante. Le projet a été mené intelligemment en utilisant les outils et les méthodes appropriés, cet ensemble a conduit à un retour sur investissement rapide.

Ancienne architecture

Nouvelle architecture

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 E. Angenault, 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.