Agent Open Source sur une architecture Autosys

Open Source Scheduler en tant qu’agent distant

Cet article présente une architecture "agentless" avec un agent open source. Le terme d’agentless signifiant que l’agent n’est pas un agent de l’éditeur. La solution habituellement préconisée repose sur une commande distante (rsh, ssh...) pour la soumission des traitements. Ce type de commande présente des inconvénients dont le principal est le fait de ne pas avoir de vision du traitement en exécution.
L’agent open source va offrir toutes les fonctionnalités d’un agent tout en bénéficiant d’un système de licence plus souple, l’intérêt de la solution est donc tout aussi technique que financier.

Qu’est ce qu’une architecture agentless ?

BMC a été le premier a proposer une architecture agentless pour la version 6.3 de Control-M, le principe est de pouvoir exécuter un traitement sur une machine distante sans installer d’agent Control-M. Le serveur utilise les mécanismes SSH sur Unix et WMI pour Windows pour l’exécution et remonte les informations sur la console de pilotage. Le principal intérêt est un gain financier puisqu’une licence pour la machine distante n’est plus nécessaire.

Techniquement, il n’y a rien de révolutionnaire, d’autant plus qu’un certain nombre d’administrateurs d’ordonnanceurs ont mis en place ce type de solution. Par contre, le fait que BMC, reconnu pour son expertise dans la production, annonce ce type de solution comme tout à fait valide et inscrit dans une logique économique a permis de légitimer le système.

En parallèle et alors que le marché de l’ordonnancement proposait une multitude d’ordonnanceurs, des sociétés se sont positionné sur la partie agent en proposant des agents universels comme Stonebranch. Le principe est d’utiliser un moteur existant pour soumettre ses traitements sur une machine distante à travers un agent capable de recevoir les ordres d’un client, l’ordonnanceur utilise le client pour soumettre les traitements.

L’intérêt de ce type de solution est de disposer de fonctionnalités supplémentaires utilisables à partir de son ordonnanceur, les sites disposant de plusieurs ordonnanceurs n’ont besoin que d’une installation par machine.

Dans une moindre mesure, CA proposait un agent universel pouvant soumettre des traitements à partir de TNG Workload ou d’Autosys. Mais dans cet exemple, l’agent était réduit à la simple soumission.

Ces différents exemples démontrent qu’une architecture d’ordonnancement peut être conçue avec des agents qui ne sont pas obligatoirement fournis par le même éditeur dans la mesure où il n’y a pas perte de fonctionnalités ou défaut de communication. Dans le cas d’agents Cybermation ou AppWorx (racheté respectivement pas CA et UC4), la solution ne sera pas viable car ces agents embarquent de nombreuses fonctionnalités mais pour des agents qui se limite à la soumission de traitements, l’utilisation d’un nouvel agent apporte un bénéfice certain.

Pourquoi un agent Open Source Scheduler ?

Le choix de cet agent rentre dans la logique du test qui consiste à utiliser l’interopérabilité des composants, un composant open source est donc tout disposé puisqu’il respecte, généralement, les standards et qu’un accès au code permet d’ajouter des améliorations sur les fonctionnalités de l’agent ou la partie communication.

L’agent est écrit en Java, ce qui facilite sa portabilité sur les différents OS et permet son emploi dans une architecture distribuée, pour les besoins de notre étude il était nécessaire de disposer des agents sur les plateformes windows, linux et solaris.

L’autre avantage de l’open source par rapport à une solution éditeur classique est de pouvoir disposer de l’ensemble des moyens d’informations : documentations et forum pour la partie support. Les versions complètes sont en libre téléchargement. Ce libre accès au produit et à l’information tout en bénéficiant d’un support est idéale pour monter rapidement une maquette.

Quelle architecture mettre en place ?

L’architecture repose sur l’extension de l’architecture client/serveur existante, on dispose d’un serveur Autosys hébergeant le moteur et le référentiel (base de données Oracle) ainsi qu’un agent. Un superviseur OSS est le point d’entrée pour les différents agents OSS installés, d’un point de vue sécurité, il est seul à pouvoir soumettre les traitements sur les agents distants.

On peut éventuellement mettre en place en place une base de données OpenScheduler qui servira à stocker les informations d’exécutions. Une console web permettra la publication des informations contenues dans la base de données. Cette partie est facultative mais si elle mise en place, il faudra considérer les communications indiquées en pointillés bleus.

Pour éviter un point de défaillances sur la communication réseau, il est conseillé de mettre l’agent Autosys et le superviseur sur la même machine. Si on suit cette logique, ces deux composants peuvent aussi être hébergés sur le serveur Autosys.

Un script Perl permet d’assurer la communication entre l’agent Autosys et le superviseur OSS. Pour une intégration optimale, cette communication doit se faire dans les deux sens :
- de l’agent autosys vers le superviseur pour la soumission
- du superviseur vers l’agent pour indiquer régulièrement le statut du job, puis en fin de traitement le retour du statut et l’exit code.

Etant donné que le principe est d’étendre l’architecture existante, les interfaces Autosys restent le point d’entrée pour la définition des traitements et le suivi de l’exploitation, il n’a donc aucun impact pour l’utilisateur, que ce soit au niveau de la configuration du poste client ou la manière de travailler.

Dans le cas de problème de charge sur l’agent autosys, il sera tout à fait possible d’installer de nouveaux superviseurs pour distribuer la charge. Inversement, si le problème de charge est au niveau du serveur, des jobs peuvent rassemblés au niveau du jobchain d’OSS pour réduire le nombre de jobs côté autosys. Le principe est de pouvoir équilibrer les jobs et les composants entre le serveur autosys et l’agent distant.

Quelle sont les fonctionnalités Autosys à émuler ?

Du côté ordonnanceur, Autosys est aussi un bon candidat dans la mesure où l’agent dispose du minimum de fonctionnalité mais qu’il est capable de communiquer étroitement avec le serveur. Concernant les fonctionnalités, un agent autosys ne peut que soumettre des commandes et attendre l’arrivée d’un fichier. Au niveau de la communication avec le serveur, l’agent peut recevoir des demandes de kill et est capable de remonter régulièrement des heartbeats.

Pour la partie envoi de kill, le serveur Autosys utilise le paramètre KillSignals qui par défaut indique 2 et 9, ce qui signifie l’envoi d’une demande d’interruption puis une demande d’arrêt. La demande d’interruption peut être traitée, ce qui n’est pas le cas de la demande d’arrêt. Le principe est donc de prendre en charge la première demande avant la demande d’arrêt brutal.
La partie Heartbeat a été commentée dans un cas pratique précédent (Voir Jobs cycliques déportés). Pour lier étroitement le serveur Autosys et l’agent distant, le script perl pourra vérifier l’état du traitement et envoyer régulièrement un kill –USR2.

Autosys permet de définir des machines virtuelles qui servent dans le cas d’alias, de queues batch ou d’équilibrage de charge. Ce système pourra être utilisé afin d’indiquer l’agent distant, nous aurons ainsi un alias pour visualiser le nom de l’agent distant qui pointera sur la machine physique hébergeant le superviseur. L’ensemble des informations est donc visualisable sur la console.

Les interfaces autosys peuvent remonter les journaux d’exécutions des traitements, pour disposer des informations de soumission à travers le superviseur et d’exécution sur l’agent distant, il suffira de renvoyer les informations, à travers le script Perl, sur la sortie standard et/ou la sortie d’erreur. Le choix de ce qui doit être renvoyé sur les différentes sorties dépend principalement du mode de fonctionnement du site.

5 mars 2011