Aller au contenu principal

Ordonnanceurs < Les incontournables < Workload Automation Autosys Edition

WA Autosys Ed. : Nouvelles fonctionnalités

Workload Automation Autosys Edition est la nouvelle version d’Autosys, elle reprend le moteur de la version 11.0 avec l’intégration des agents Cybermation.

E. Angenault

12 janvier 2011

 POPULARITE : 919 visites

Le System Agent

L’agent Cybermation remplace définitivement l’agent Autosys, ce dernier proposait 2 types de commandes : la commande système et l’attente de fichiers ainsi que des connecteurs pour les logiciels comme SAP ou PeopleSoft.

La nouvelle structure de l’agent permet d’intégrer de nouveaux types à travers un mécanisme de plugin, les anciens connecteurs étant eux-mêmes de nouveaux plugins. L’agent est en Java, et chaque plugins correspond à des jars supplémentaires.

Les agents suivants sont supportés :
- CA Workload Automation Agent for i5/OS
- CA Workload Automation Agent for Linux
- CA Workload Automation Agent for UNIX
- CA Workload Automation Agent for Windows
- CA Workload Automation Agent for z/OS

Le moteur reste compatible avec les anciens agents 4.5 et R11, les anciennes options restent accessibles. La migration en sera facilitée, d’autant qu’il est possible d’installer un agent Autosys des versions précédentes avec l’agent R11.3.

Les plugins permettent d’étendre l’agent. L’installation se fait à travers le ’PluginInstaller’ dont le rôle est de copier le jar correspondant dans le répertoire des modules et d’ajouter le paramètrage associé dans le fichier de configuration de l’agent. Les modules suivant sont actuellement supportés sur Unix/Linux et Windows :
- CA Workload Automation Agent for Application Services
- CA Workload Automation Agent for Databases
- CA Workload Automation Agent for PeopleSoft
- CA Workload Automation Agent for Oracle E-Business Suite
- CA Workload Automation Agent for SAP
- CA Workload Automation Agent for Web Services

Un fichier de sécurité locale permet de spécifier les autorisations pour les différents utilisateurs :

x a | d manager_userID agent_userID path

Agents supportés

- CA Workload Automation
- Agent for UNIX or Linux
- Command (CMD)
- CPU Monitoring (OMCPU)
- Disk Monitoring (OMD)
- File Trigger (FT)
- File Transfer Protocol (FTP)
- IP Monitoring (OMIP)
- Process Monitoring (OMP)
- Secure Copy (SCP)
- Text File Reading and Monitoring (OMTF)
- CA Workload Automation
- Agent for Windows
- Command (CMD)
- CPU Monitoring (OMCPU)
- Disk Monitoring (OMD)
- File Trigger (FT)
- File Transfer Protocol (FTP)
- IP Monitoring (OMIP)
- Process Monitoring (OMP)
- Secure Copy (SCP)
- Text File Reading and Monitoring (OMTF)
- Windows Event Log Monitoring Jobs (OMEL)
- Windows Service Monitoring (OMS)

Bases de données :
- Database Monitor (DBMON)
- Database Stored Procedure (DBPROC)
- Database Trigger (DBTRIG)
- Structured Query Language (SQL)

Mainframe :
- Agent for i5/OS
- i5/OS (I5)

Oracle E-Business Suite :
- Oracle E-Business Suite Copy Single Request (OACOPY)
- Oracle E-Business Suite Request Set (OASET)
- Oracle E-Business Suite Single Request (OASG)

PeopleSoft :
- PeopleSoft (PS)

SAP :
- SAP Batch Input Session (SAPBDC)
- SAP BW InfoPackage (SAPBWIP)
- SAP BW Process Chain (SAPBWPC)
- SAP Data Archiving (SAPDA)
- SAP Event Monitor (SAPEVT)
- SAP Job Copy (SAPJC)
- SAP Process Monitor (SAPPM)
- SAP R/3 (SAP)

Application Services :
- Entity Bean (ENTYBEAN)
- Hypertext Transfer Protocol (HTTP)
- Java Remote Method Invocation (JAVARMI)
- JMS Publish (JMSPUB)
- JMS Subscribe (JMSSUB)
- JMX-MBean Attribute Get (JMXMAG)
- JMX-MBean Attribute Set (JMXMAS)
- JMX-MBean Create Instance (JMXMC)
- JMX-MBean Operation (JMXMOP)
- JMX-MBean Remove Instance (JMXMREM)
- JMX-MBean Subscribe (JMXSUB)
- Plain Old Java Object (POJO)
- Session Bean (SESSBEAN)

Web Services :
- Plain Old Java Object (POJO)
- Web Service (WBSVC)

Traitements z/OS :
- z/OS Data Set Trigger (ZOSDST)
- z/OS Manual (ZOSM)
- z/OS Regular (ZOS)

Les types command, box et filewatcher restent accessible pour la compatibilité des anciens JIL.

Tous les types ne sont pas encore implémentés dans la 11.3, il devraient l’être dans les prochains Service Pack :
- Micro Focus (MICROFOCUS)
- SNMP Value Get (SNMPGET)
- SNMP Value Set (SNMPSET)
- Wake on LAN (WOL)

Définitions

Appel de commandes

La méthode d’exécution de la commande est paramètrable. En 4.5, la commande était directement soumise après chargement éventuel du profil, dans le cas de commande comme le dir, l’agent préfixait automatiquement par un "cmd.exe /c".

Ce n’est plus le cas en 11.3 sauf si on a défini au préalable le paramètrage comme suit :

oscomponent.lookupcommand=true
oscomponent.cmdprefix.force=true

Substitution de commandes

On ne peut plus utiliser la substitution de commande dans le champ watch_file comme on pouvait le faire en 4.5 ou en 4.5 :

watch_file: \tmp\`date`

File watcher

Pour conserver la compatibilité, le file watcher est toujours présent pour les anciens agents. Si ce type de job est utilisé un nouvel agent le fonctionnement est le suivant :
- le traitement vérifie le fichier toutes les 30 secondes
- si le fichier est créé ou mis à jour entre 2 vérifications, on attend 1 minute de plus (par défaut). Si le fichier n’a pas évolué pendant cette période, le traitement se termine.

On peut toujours modifier l’intervalle de polling en utilisant le paramètre watch_interval.

Dieze dans les noms d’objet

L’utilisation caractère # (dièze) dans les noms d’objets n’est plus permise.

Ressources

On peut maintenant définir des ressources virtuelles et les utiliser comme des dépendances. Il existe 3 types de ressources :
- depletable
- renewable
- threshold

Ce type de ressources permet de gérer les accès concurrents.

La fréquence de vérification peut être spécifiée dans la configuration du serveur avec le champ ResourceWaitPollInterval.

Alertes de planifications

Deux nouveaux évènements ont ajoutés :
- le must_start_times qui permet de définir une heure ou une liste d’heures. Si le traitement ne démarre pas à l’heure spécifié, une alarme est envoyée. Cet évènement correspond à une heure au plus tard.
- le must_complete_times qui définit l’heure ou les heures de fin. Si l’heure est dépassée, une alarme est envoyée. Cet évènement est pratique dans le cadre de SLA.

Configuration Agent

variables d’environnement

Les variables sont maintenant définies dans un fichier de configuration dont la localisation est précisé dans l’agentparm.txt, on distingue les variables pour les différents agents agents et les variables spécifiques à une instance. Le champ envvar du jil qui permet de passer une variable au traitement.

Journaux

Le nouvel agent 11.3 écrit les logs dans les répertoires suivants :
- Répertoire_d’installation/SystemAgent/Nom_agent/log pour les logs internes à l’agent
- Répertoire_d’installation/SystemAgent/Nom_agent/spool pour les logs d’exécution

Agent Windows

Le format de profile sur Windows n’est plus stocké en base de registres, la migration de ce format vers celui de la 11.3 est pris en charge dans la procédure d’upgrade. Sinon, la commande autoprofm peut être exécutée manuellement.

Configuration Serveur

Calcul de charge machine

Le vmstat n’est plus utilisé par les nouveaux agents, on utilise maintenant le job type CPUMON.

Localhost

Localhost est devenu un mot réservé. On se rappelle les versions antérieures ou on pouvait définir le serveur comme suit :
- `hostname`qui permettait de récupérer le nom du serveur mais obligeait le serveur a exécuter cette commande.
- locahost qui n’était valide que pour les serveurs disposant de licence globale type entreprise
- $$serveur qui plantait les traitement en cas de bascule (à moins de bidouiller avec les notify).

Maintenant, c’est simplement "localhost" a qui on peut éventuellement attribuer un nom plus joli avec le paramètre LocalMachineDefinition.

Paramètres de démarrage

Les paramètres de démarrage du serveur Autosys qui étaient passées en ligne de commande dans les précédentes versions, sont maintenant définies dans le fichier de configuration. Elles ne sont plus accessibles en tant que paramètres de l’eventor.
- Global Auto Hold (ancienne option -G) est maintenant défini dans le champ GlobalAutoHold
- Chase (ancienne option -n) correspond au champ ChaseOnStartup

Maintenance

L’option LOGROLLOVER permet de spécifier le moment l’heure à laquelle le journal du serveur sera sauvegardé. Il est aussi possible d’indiquer une taille maximum pour le journal, la sauvegarde se fera alors dés que la taille du fichier est atteinte.

Support IPv6

IPv6 est maintenant supporté, c’était une demande des Etats-Unis car en France je ne connais pas beaucoup de site en IPv6. Ce format est compréhensible par la JIL pour la définition des machines.

Supervision

La partie alerte a évoluée pour une meilleure intégration avec des outils de supervision, plus particulièrement avec NSM et son Event Manager.

Surveillance continue

La surveillance continue peut être activée sur les traitements suivants :
- CPU Monitoring (OMCPU)
- Database Monitor (DBMON)
- Database Trigger (DBTRIG)
- Disk Monitoring (OMD)
- File Trigger (FT)
- Text File Reading and Monitoring (OMTF)
- Windows Event Log Monitoring (OMEL)
- Windows Services Monitoring (OMS)

Lorsque les seuils sont atteints, un évènement ALERT est écrit dans le journal du serveur. Ces informations sont ensuite accessibles par la commande

autorep -J -d

On regrettera que ces évènements ne puisse être traités autrement que par un outil de supervision comme NSM. Une simple intégration dans le notify aurait permi d’éviter de passer par un gestionnaire d’alertes.

L’arrêt de ce type de traitement se fait comme pour un file watcher :

kill de job par un sendevent  -KILLJOB

Message d’évènements dans le journal

Le texte associé à un évènement est écrit dans le journal du serveur, cette information permet l’ajout d’explication dans les logs et facilite la gestion des messages.

Evènements STATE_CHANGE

Certains nouveaux traitemens, comme le type z/OS, passent par différents changements d’état pendant l’exécution.

Ces états sont inscrits dans le journal et accessible par un autorep -d.

Cross instance

les changements sur les instances croisées sont les suivants :
- les évènements externes sont stockés dans le table ujo_ext_event
- on peut croiser une instance 4.5 et 11.3 en utilisant un serveur d’application léger installé sur la partie 11.3.
- les instances peuvent utiliser des cryptages différents qu’on spécifie avec l’attribut xcrypt_key.

Mainframe

On peut définir et surveiller des dépendances inter instances entre Autosys Edition et CA7 Edition. Ces dépendances permettent de définir des chaînes contenant des traitements exécutés aussi bien du mainframe que sur distribué.

Commandes

Prévisions

Une nouvelle commande de forecast permet de créer un rapport pour les traitements futurs suivant une date spécifiée.

Autoping

Le paramètre -S de la commande autoping permet de vérifier la connexion de l’agent vers le serveur en passant par le serveur d’application. Si l’agent est inférieur à la version 11.3, c’est un test de connexion de base de données qui est effectué.

Clean files

Le clean_files ne sert plus que pour les anciens agents. Le nettoyage des fichiers est prise en charge par l’agent 11.3.

Commandes supprimées

Les commandes suivantes ne sont plus disponibles :
- autodwp
- autosys_report
- autosys_wv
- job_delete (remplacée par archive_jobs)
- job_profiles
- ntgetdate
- xql / zql


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.