只要我记得要处理我们所有的工作计划需求，我们一直在使用cron。 从存储克隆/快照到数据库报告到日常系统报告到监视检查的所有内容都通过cron安排在几百台服务器上。
缺点是非常明显的：难以pipe理工作，没有简单的方法来创build依赖关系（特别是在不同的服务器上），当然，有人“暂时”跳过一个工作，但后来忘记删除评论是不可避免的。
我们尝试了一个商业产品，但是最终它被认为是从cron上升的过于昂贵。
我看到其他的select，例如SLURM，Oracle Grid Engine，Torque / Maui，Quartz，DIET，Condor，这些选项看起来都是面向更大，更均匀的集群环境，并且可以在任意数量的类似节点上运行：网格计算等等。 我们的环境相当混杂（各种Linux，AIX和FreeBSD），我们需要在不同types的系统之间创build依赖关系（例如，Linux机器上的作业可能需要确定是否应该运行AIX机器上的作业）。
有没有人从cron转向更集中pipe理的产品？ 有关select软件的任何提示，或者开源还是商业更好？
Condor，OGE和Torque都可以让你在那里，但是只有Condor使用它的DAGMan工具内置了依赖pipe理。 DAGMan允许您设置一个定向的非循环图表来描述您的工作stream程，而pipe理者负责转移您工作stream程中的工作，并评估stream程中每个步骤的合格/不合格结果。 Condor是相对平台不可知论的，这意味着DAGMan也是如此，当父母在Linux或Windows上运行时，您当然可以在AIX上运行一个子步骤。 DAGMan不关心工作在哪里，只是退出代码是通过还是失败。
有关select软件的任何提示，或者开源还是商业更好？
有一些注意事项，我认为这个空间的免费社区是非常值得关注的。
OGE现在处于一个奇怪的空间。 运行Oracle生产的GE变体不再是免费的，Oracle不再提供写回GE SCC的代码，但是现在有几种试图将自己的代码当作免费的开源项目的代码。 尤其是Univa领导着这项工作 ，聘请了前Sun的开发人员继续开发一个开放源代码，免费提供的GE变体。 Grid Engine有两件事情：它很容易设置，它可以处理短时间运行（<2分钟）的作业，而不会给作业造成太多的调度开销，从而降低吞吐量。 它的缺点是对Windows没有很好的支持。 我们中的一些人花了一些努力，把它移植到Cygwin多年前运行，但它不是肯定的本地。
现在，Condor是我所提到的三种技术中最受欢迎的。 Condor周围有一个强大的社区，软件非常成熟（现在> 20岁）。 本地Windows和POSIX操作系统的支持意味着它在各地运行得非常好。 前面提到的DAGMan只是Condor的许多伟大作品之一。 这可能是一个复杂的设置，但一旦它运行起来，它坚如磐石。 它具有令人难以置信的灵活的语言来进行工作机器匹配，并为您的资源build立使用规则。 它还支持机器上的dynamicconfiguration，让作业select他们需要多less机器资源，然后重新宣传差异仍然可用。 它支持全球资源计数器，所以你可以限制软件许可等事情。 当然，它有DAGMan，这是一个非常强大的工作stream程pipe理工具。 Condor的缺点是短期工作的调度开销可能是繁重的。 你希望理想的工作时间超过2分钟，否则调度开始成为系统中工作时间的重要组成部分。
扭矩是多一点利基。 我恐怕对此知之甚less。 它比Condor更多地比较Grid Engine。 @warren提到的付费附加组件可以扩展基本的，免费的Torque可以做的事情。
如果您想尝试使用这三种技术，并了解它们如何与您的特定工作负载配合使用， CycleCloud可以创build预先configuration了Condor，GridEngine或Torque的安全，虚拟化的池 – 所以没有时间花费在计算这些东西上就你而言。 将每个技术的小池分成几块钱，然后用具有代表性的工作负载来尝试。 （免责声明：我为Cycle Computing工作，我们做CycleCloud）
Chronos看起来很有希望。
Chronos是Airbnb的cron替代品。 它是一个运行在Apache Mesos之上的分布式容错调度器。 您可以使用它来编排作业。 它支持自定义的Mesos执行程序以及默认的命令执行程序。 因此，默认情况下，Chronos执行sh（在大多数系统bash）脚本。 Chronos可用于与Hadoop（包括EMR）等系统交互，即使发生执行的Mesos从站没有安装Hadoop。 包含的包装脚本允许在后台传输文件并在远程机器上执行它们，并使用asynchronouscallback来通知Chronos工作完成或失败。
我也用Jenkins作为cron替代品取得了巨大的成功。 它很好地处理远程服务器上的执行作业。 这里有一个关于它的文章： http ://www.22ideastreet.com/blog/2014/05/02/replace-local-cron-with-jenkins/
在过去的4.5年中，我曾与惠普（nes Opsware）服务器自动化平台以及业务技术优化套件（networking自动化，操作编排等）的其余部分合作。
对于一个足够大的环境来说，通过SA进行工作pipe理是一个高度可行的工具。 结合面向对象，可以通过变更控制pipe理，票务等来控制工作。
这里不是那么有趣的部分：它很昂贵（非常昂贵）。 您可能会检查一些我曾经问过的类似问题中的一些build议： FLOSS服务器pipe理和审计工具 。
我还想说，来自Adaptive Computing的 Torque / Maui / Moab 非常酷：定价不确定，但是它们也是高度灵活的工具。
免责声明 – 我为惠普BTO和Adaptive的合作伙伴工作
注意完全不同的问题！
克朗在某种程度上是古老而笨重的。
如果你确实在寻找新的方法来做计划，我会尝试一些基于消息中间件的事件。 想想每个服务器上的客户端的RabbitMQ。
Inter Host依赖关系可以通过“通知队列”来解决。
“真正的”基于时间的事件有点棘手，这实际上是cron的目标（至less在小型环境中是相当擅长的）。 如果搞定这个想法很难，那就是防止混帐。 就像在每个0100H每晚做一个快照。 在这个时候，你可能会看到一些负载峰值或很多失败的login。 如果你有一个基于方法的队列，你至less会得到一些免费的偏差（尽pipe不能保证 – 除非有一些逻辑实现了这个偏差）。
要解决的问题是，如果没有基于实时的工作，你不能依赖于这样的事情：是的，我的备份将在0200h开始，如果他们仍然在0400h运行有什么问题。 更容易做的是确保没有2个干扰的工作同时运行。 只要制作一个阻止代理，一次只会占用一份工作。
pipe理部分将是一个很好的Web界面，可以按需提交作业，或者 – 现在它可以返回到“cron”或您最喜欢的实现它的Java石英调度程序在几秒钟内粒度AFAIK – 为基于时间的部分只是使用好老cron 🙂
请不要低估我作为加时 – 这是一个相当粗糙的概念，但既然这个问题不排除金钱，不如花钱，通过创造一些东西而不是花费来获得确切的内部需求的解决scheme通过购买一个供应商认为它满足一些要求的东西的钱:)
我使用了来自CA的Espresso（Cybermation）。 不知道他们现在叫什么。 我也用过UC4。 他们都工作，花了很多钱（据我的理解），可以成为一个熊维护，但他们做它所说的锡。 /编辑 – 错过了你说的商业应用程序太昂贵了。 我完全可以同意，但是对于一些公司来说，这是值得的，特别是在商业应用程序赚钱的时候。
我已经使用开源作业调度程序作为选项来replace生产环境中的2000+行中央crontab。 cron的事情变得非常复杂，我们无法确定停机时间窗口是什么，或者如何处理服务器间依赖关系。 这个产品有帮助，但设置有点复杂。