Cron dépassé: quel est le prochain ordonnanceur? [fermé]

Nous utilisons cron depuis aussi longtemps que je me souvienne de gérer tous nos besoins de planification des tâches. Tout, des clones de stockage / instantanés aux rapports sur les bases de données, aux rapports quotidiens du système et aux contrôles de surveillance, est planifié sur quelques centaines de serveurs via cron.

Les inconvénients sont assez évidents: difficile à gérer les travaux, pas de moyen facile de créer des dépendances (en particulier sur différents serveurs), et, bien sûr, il est inévitable que quelqu'un saute "temporairement" un travail mais oublie plus tard de supprimer le commentaire.

Nous avons essayé une offre commerciale, mais au final, elle a été jugée trop chère comme une étape de cron.

Je vois d'autres options, telles que SLURM, Oracle Grid Engine, Torque / Maui, Quartz, DIET, Condor qui semblent être orientées vers des environnements de cluster plus grands et plus homogènes avec des travaux qui s'exécuteraient sur un nombre quelconque de nœuds similaires: le calcul en grille etc. Notre environnement est assez mixte (divers Linux, AIX et FreeBSD), et nous devons créer des dépendances entre différents types de systèmes (par exemple, un travail sur un boîtier Linux peut avoir besoin de déterminer si un travail sur un boîtier AIX doit s'exécuter.)

Quelqu'un a-t-il une expérience pour passer de cron à une offre gérée de manière plus centralisée? Des conseils pour choisir le logiciel ou s'il est préférable d'aller open source ou commercial?

Condor, OGE et Torque peuvent tous vous y emmener, mais seul Condor a une gestion des dépendances intégrée avec son outil DAGMan . DAGMan vous permet de configurer un graphique acyclique dirigé qui décrit votre flux de travail et le gestionnaire se charge de parcourir les tâches de votre flux de travail et d'évaluer les résultats de réussite / échec à chaque étape du flux. Condor est relativement indépendant de la plate-forme, ce qui signifie que DAGMan l'est également, et vous pouvez certainement exécuter une étape enfant sur AIX lorsque le parent s'exécute sur Linux ou Windows. DAGMan ne se soucie pas de l'endroit où les travaux s'exécutent, juste que les codes de sortie sont réussis ou échoués.

Des conseils pour choisir le logiciel ou s'il est préférable d'aller open source ou commercial?

Avec quelques mises en garde, je pense que les communautés libres dans cet espace valent la peine d'être examinées.

OGE est maintenant dans un espace étrange. Il n'est plus gratuit d'exécuter la variante GE produite par Oracle et Oracle ne fournit plus de code qu'il réécrit au GE SCC, mais il existe plusieurs fourches du code qui tentent de se poursuivre en tant que projets open source gratuits. Univa en particulier a mené la charge en embauchant d'anciens développeurs de Sun GE pour continuer à travailler sur une variante GE open source et librement disponible. Grid Engine a deux choses à faire: il est facile à configurer, il peut gérer des travaux de courte durée (<2 minutes) sans imposer une surcharge de planification sur les travaux qui ralentit le débit. Son gros inconvénient est qu'il n'y a pas un très bon support pour Windows. Certains d'entre nous ont fait des efforts pour le faire fonctionner sur Cygwin il y a de nombreuses années, mais ce n'est pas aussi bon que natif, c'est sûr.

Maintenant, Condor est mon préféré parmi les trois technologies que vous avez mentionnées. Il existe une forte communauté autour de Condor et le logiciel est très mature (> 20 ans maintenant). La prise en charge native de Windows et du système d'exploitation POSIX signifie qu'il fonctionne très bien partout. Le DAGMan susmentionné n'est que l'une des nombreuses grandes pièces fournies avec Condor. Cela peut être une touche compliquée à configurer, mais une fois qu'il est opérationnel, il est solide. Il a un langage incroyablement flexible pour faire le travail <-> correspondant à la machine et construire vos règles d'utilisation pour vos ressources. Il prend également en charge le provisionnement dynamique sur les machines, permettant aux jobs de sélectionner la quantité de ressources machines dont ils ont besoin, puis de republier la différence comme étant toujours disponible. Il prend en charge les compteurs de ressources mondiaux afin que vous puissiez vous limiter à des choses comme les licences de logiciels. Et bien sûr, il a DAGMan, qui est un outil incroyablement puissant pour la gestion des flux de travail. L'inconvénient de Condor est que les frais généraux de planification pour les travaux de courte durée peuvent être lourds. Vous voulez des travaux qui durent plus de 2 minutes dans l'idéal, sinon la planification commence à devenir une grande partie du temps du travail dans le système.

Le couple est un peu plus niche. J'en sais moins, j'en ai peur. Il se compare davantage à Grid Engine qu'à Condor. @Warren a mentionné des modules complémentaires payants qui peuvent étendre ce que le couple de base gratuit peut faire.

Si vous voulez essayer les trois technologies et voir comment elles fonctionnent avec vos charges de travail spécifiques, CycleCloud peut créer des pools sécurisés, virtualisés, préconfigurés avec Condor, GridEngine ou Torque - donc pas de temps à comprendre de votre part. Ce serait quelques dollars pour faire tourner de petits pools de chaque technologie et les essayer avec des charges de travail représentatives. (Avertissement: je travaille pour Cycle Computing, nous faisons CycleCloud)

Chronos semble très prometteur.

Chronos est le remplacement d'Airbnb pour cron. Il s'agit d'un planificateur distribué et tolérant aux pannes qui s'exécute au-dessus d'Apache Mesos. Vous pouvez l'utiliser pour orchestrer des travaux. Il prend en charge les exécuteurs Mesos personnalisés ainsi que l'exécuteur de commandes par défaut. Ainsi, par défaut, Chronos exécute les scripts sh (sur la plupart des systèmes bash). Chronos peut être utilisé pour interagir avec des systèmes tels que Hadoop (y compris EMR), même si les esclaves Mesos sur lesquels l'exécution se produit n'ont pas Hadoop installé. Les scripts d'encapsulation inclus permettent de transférer des fichiers et de les exécuter sur une machine distante en arrière-plan et d'utiliser des rappels asynchrones pour informer Chronos de la fin ou des échecs de la tâche.

J'ai également connu un grand succès personnel en utilisant Jenkins comme remplacement cron. Il gère très bien l'exécution des travaux sur des serveurs distants. Voici un résumé à ce sujet: http://www.22ideastreet.com/blog/2014/05/02/replace-local-cron-with-jenkins/

Au cours des 4,5 dernières années, j'ai travaillé avec la plate-forme d'automatisation de serveurs HP (nee Opsware) et le reste de la suite Business Technology Optimization (Network Automation, Operations Orchestration, etc.).

Pour un environnement suffisamment grand, la gestion des tâches via SA est un outil hautement viable (et souhaitable). En collaboration avec OO, les tâches peuvent être contrôlées via la gestion du contrôle des modifications, la billetterie, etc.

Voici la partie pas si amusante: c'est cher (très cher). Vous pouvez vérifier certaines des suggestions dans une question similaire que j'ai posée il y a un certain temps: Outils de gestion et d'audit de FLOSS Server .

Je dirais également que Torque / Maui / Moab (d' Adaptive Computing ) sont très cool: je ne suis pas sûr du prix, mais ce sont aussi des outils très flexibles.

REMARQUE Une approche complètement différente du problème!

cron est vieux et maladroit à certains égards.

Si vous cherchez en effet de nouvelles façons de planifier, j'essaierais quelque chose basé sur un middleware de messagerie. Pensez RabbitMQ avec des clients sur chaque serveur.

Les dépendances entre hôtes peuvent être résolues par des «files d'attente de notification».

Les événements basés sur le temps "réel" sont un peu plus délicats, c'est en fait à cela que sert cron (et est plutôt bon, du moins en ce qui concerne les petits environnements). Là où il est difficile de mettre la main sur l'idée, c'est d'empêcher les accrochages. Comme dans: tous les soirs à 0100h faites un instantané. Vous pourriez voir des pics de charge ou de nombreuses connexions défaillantes à ce moment précis à travers toute votre infrastructure. Si vous avez une approche basée sur la file d'attente, vous obtiendrez au moins une certaine déviation gratuitement (bien que ce ne soit pas garanti - sauf si une logique l'implémente).

La chose à contourner est que sans travaux basés sur le temps réel, vous ne pouvez pas vous fier à des choses comme: ouais mes sauvegardes commenceront à 0200h et si elles fonctionnent toujours à 0400h, quelque chose ne va pas. Ce qui est plus facile à faire, c'est de s'assurer qu'aucun 2 travail qui interfère n'est exécuté en même temps. Créez simplement un agent de blocage qui ne consommera qu'un seul travail à la fois.

La partie de gestion serait une belle interface Web où les travaux pourraient être soumis à la demande, ou - maintenant, revenons à «cron» ou à votre implémentation préférée, le planificateur de quartz java a une granularité en secondes AFAIK - pour le partie basée sur le temps il suffit d'utiliser un bon vieux cron :)

S'il vous plaît ne me dévalorisez pas pour être OT - c'est un concept assez approximatif mais comme la question n'exclut pas l'argent, on pourrait aussi bien dépenser l'argent pour obtenir la solution pour les besoins internes exacts en créant quelque chose plutôt que de dépenser l'argent en achetant quelque chose où un vendeur pense qu'il remplit certaines conditions :)

J'ai utilisé Espresso (Cybermation) de CA. Je ne sais pas comment ils l'appellent maintenant. J'ai également utilisé UC4. Ils travaillent tous les deux, coûtent beaucoup d'argent (à ma connaissance) et peuvent être un ours à entretenir, mais ils font ce qui est indiqué sur l'étain. / Modifier - vous avez manqué que vous disiez que les applications commerciales sont trop chères. Je suis tout à fait d'accord, mais pour certaines entreprises, cela en vaut la peine, surtout quand il s'agit d'applications commerciales qui rapportent de l'argent.

J'ai travaillé avec l' Open Source Job Scheduler comme option pour remplacer un crontab central de 2000+ lignes dans un environnement de production. Les choses se sont tellement compliquées avec cron, que nous n'avons pas pu déterminer quelles étaient les fenêtres d'indisponibilité ni comment gérer les dépendances inter-serveurs. Ce produit a aidé, mais était un peu complexe à configurer.