Passer au contenu

Les systèmes ouverts, adeptes des ordonnanceurs de tâches

Le monde des systèmes ouverts bénéficie aujourd’hui d’une offre assez importante d’ordonnanceurs de tâches. Les grands éditeurs de frameworks d’administration se sont largement appropriés ce marché.

Avec le rachat d’Unison et de son ordonnanceur Maestro, en septembre 1997, IBM donnait une nouvelle impulsion au marché des outils d’ordonnancement de tâches (job scheduling). Depuis, Maestro s’est transformé en Tivoli Workload Scheduler. Au printemps 1999, Computer Associates faisait l’acquisition de Platinum, notamment pour sa famille d’outils d’ordonnancement de tâches pour systèmes distribués, Autosys. Au même moment, BMC Software jetait son dévolu sur New Dimension, éditeur de Control-M, depuis à la base de la ligne de produits Incontrol, complémentaires du framework Patrol. Enfin, en janvier 2000, l’américain ASG faisait sien l’ordonnanceur multiplate-forme JS-Plan, développé par Sisro. Dans la foulée, il rachetait les outils destinés aux systèmes distribués, les passerelles d’ordonnancement ainsi que les consoles de planification de l’allemand Beta.
Cette consolidation au profit des grands de l’administration n’a cependant pas réussi à évincer du marché les éditeurs indépendants spécialisés tels qu’Absyss et OSM, ni ceux qui ont su se maintenir dans leur niche. Ainsi, Dollar Universe, d’Orsyp, est à l’origine de l’ordonnanceur de tâches proposé en standard dans la console OpenMaster, de Bull.

es ordonnanceurs ont dû prendre en charge les systèmes ouverts…

Editeur français, créé en 1989, Absyss a su capitaliser sur son expertise GCOS 8 pour étendre son expertise de l’ordonnancement de tâches aux environnements d’entreprise hétérogènes, grâce à VisualTOM. Ce dernier peut piloter des systèmes et des applications sous Unix, GCOS, OS/390, OS/400, OpenVMS et Windows NT, et s’interface à des consoles d’administration de type HP OpenView et OpenMaster, de Bull.
Il est donc loin le temps où l’ordonnancement de tâches se cantonnait aux grands systèmes. La contribution croissante des systèmes Unix et Windows NT aux processus stratégiques des entreprises appelle à un renouveau des ordonnanceurs de tâches, qui se doivent d’embrasser les environnements distribués. L’une des raisons de l’émergence d’une offre d’ordonnanceurs de tâches pour systèmes ouverts a été la pauvreté relative des Unix commerciaux en matière de fonctions d’automatisation. En standard, Unix ne s’appuie que sur la rudimentaire commande monoposte Cron. Cette lacune d’Unix a cependant été rapidement corrigée par l’arrivée d’ordonnanceurs de nouvelle génération, à l’origine positionnés sur Unix, mais dont la couverture s’est ensuite étendue à Windows NT, à OS/400 et même à 0S/390. Reste que dans le monde du mainframe, sous Unix ou NT, ce que l’on attend d’un ordonnanceur reste simple : il s’agit de lancer des tâches applicatives (établissement de rapports, transferts et consolidation de données, impression de factures, backup, etc.) exécutées les unes à la suite des autres sur une même machine ou sur des machines réparties sur un réseau, et de veiller à leur bon déroulement.

#8230; et s’adapter aux faiblesses de NT et d’Unix

Néanmoins, les contraintes pesant sur les ordonnanceurs ont changé de nature depuis l’époque du tout-mainframe. Auparavant, ils devaient piloter l’exécution des batches tournant sur un même grand système. Ce n’est plus le cas aujourd’hui. Sur mainframe, l’ordonnanceur représentait, par ailleurs, un point de faiblesse potentiel. S’il tombait en panne, l’exploitation s’arrêtait. Ce risque était cependant compensé par la grande fiabilité des mainframes. Sur les systèmes distribués actuels, en revanche, les fonctions de tolérance aux pannes et de redondance des ordonnanceurs ont dû être renforcées, en raison des défauts de fiabilité des serveurs Unix et surtout des serveurs Windows NT.
Avec les architectures distribuées, les ordonnanceurs ont eu à faire face à une démultiplication des arrêts non programmés des machines et des applications. Il leur a fallu répondre à d’autres contraintes liées aux risques d’indisponibilité et de congestion des réseaux et aux interdépendances des systèmes. Ils ont dû aussi prouver leur capacité d’évolution afin de soutenir la montée en charge des environnements applicatifs.

Une architecture de type gestionnaire central-agent

Ces difficultés ont pesé sur l’architecture et les fonctions des solutions originellement proposées par des pionniers tels que New Dimension, Platinum ou Unison. Un ordonnanceur de tâches, au sens moderne du terme, a une architecture de type gestionnaire-agent, lui permettant d’être déployé sur plusieurs niveaux. Les offres s’articulent autour d’une console de supervision centrale coiffant un ou plusieurs gestionnaires aptes à piloter plusieurs centaines d’agents. La console de supervision d’un ordonnanceur de tâches telle que Tivoli Workload Scheduler propose ainsi des fonctions d’administration à base de règles de gestionnaires et d’agents. Mais, elle permet aussi de suivre en temps réel le statut des tâches ainsi que leur exécution. Elle comporte également des outils de programmation événementielle pour la définition des scénarios d’ordonnancement. Elle s’appuie sur un langage de haut niveau, voire sur des outils de représentation graphique, autorisant la définition des options de déclenchements conditionnels et la gestion des dépendances interplates-formes. Les administrateurs ont aussi la possibilité d’intervenir pour déplacer l’exécution d’une tâche ou pour programmer un Batch ad hoc, non défini originellement. La console prend enfin en compte les interdépendances des différents travaux.
Certains ordonnanceurs, tels Dollar Universe, d’Orsyp, ou Control-M, de BMC (rebaptisé Incontrol), s’appuient sur des fonctions d’équilibrage de charges permettant de s’assurer que le lancement d’un travail ne sera autorisé que si les ressources nécessaires à son exécution sont réunies. Certaines consoles offrent également des fonctions de modélisation permettant de simuler l’impact de changements systèmes ou applicatifs sur la séquence d’exécution des batches. Les gestionnaires supervisés par la console sont chargés de piloter l’exécution des tâches définies dans un environnement ou un domaine applicatif donnés. Les agents sont déployés auprès de serveurs ou d’applications (SGBD ou ERP) pour contrôler les activités à un niveau local. Ils peuvent recevoir des instructions par lots, communiquées par leur gestionnaire à intervalles réguliers. L’autonomie d’action ainsi conférée les rend moins vulnérables à une panne du réseau ou à une interruption momentanée des communications avec les gestionnaires. Enfin, la recherche de la plus grande disponibilité a aussi conduit les éditeurs à interfacer les ordonnanceurs de tâches avec les consoles d’administration système. Les intérêts d’un tel rapprochement sont multiples.

La proactivité devient incontournable

On peut vouloir superviser de façon centralisée les processus actifs au sein de l’entreprise ou, à l’inverse, trouver avantage à exploiter les frameworks d’administration pour leurs capacités de découverte des réseaux et de remontée d’événements, permettant de programmer les déclenchements des tâches.
Il s’agira également de mettre en ?”uvre une administration de l’ordonnanceur, mais aussi des composants systèmes et applicatifs à sa disposition. Il serait, en effet, fâcheux qu’une production informatique soit paralysée à la suite de la surcharge d’un processeur ou d’une panne de disque.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Thierry Jacquot