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)