Superando cron: qual é o próximo agendador? [fechadas]

Estamos usando o cron há tanto tempo quanto me lembro de lidar com todas as nossas necessidades de agendamento de tarefas. Tudo, desde clones / capturas instantâneas de armazenamento, relatórios em bancos de dados, relatórios diários do sistema e verificações de monitoramento, está programado em algumas centenas de servidores via cron.

As desvantagens são bastante óbvias: tarefas difíceis de gerenciar, nenhuma maneira fácil de criar dependências (especialmente em servidores diferentes) e, é claro, é inevitável que alguém "temporariamente" pule uma tarefa, mas depois se esqueça de remover o comentário.

Tentamos uma oferta comercial, mas, no final, foi considerada muito cara como um passo em relação ao cron.

Vejo outras opções por aí, como SLURM, Oracle Grid Engine, Torque / Maui, Quartzo, DIET, Condor, que parecem ser voltadas para ambientes de cluster maiores e mais homogêneos, com tarefas que seriam executadas em qualquer número de nós semelhantes: grid computing e similar. Nosso ambiente é bastante misto (vários Linux, AIX e FreeBSD) e precisamos criar dependências em diferentes tipos de sistemas (por exemplo, um trabalho em uma caixa Linux pode precisar determinar se um trabalho em uma caixa AIX deve ser executado.)

Alguém tem alguma experiência em mudar do cron para uma oferta mais gerenciada centralmente? Alguma dica para escolher o software ou se é melhor ir de código aberto ou comercial?

O Condor, o OGE e o Torque podem levá-lo até lá, mas apenas o Condor possui gerenciamento de dependência integrado com sua ferramenta DAGMan . O DAGMan permite configurar um gráfico acíclico direcionado que descreva seu fluxo de trabalho e o gerente se encarrega de percorrer os trabalhos em seu fluxo de trabalho e avaliar os resultados de aprovação / reprovação em cada etapa do fluxo. O Condor é relativamente independente de plataforma, o que significa que o DAGMan também é, e certamente você pode executar uma etapa filha no AIX quando o pai executou no Linux ou Windows. O DAGMan não se preocupa com o local onde os trabalhos são executados, apenas com os códigos de saída que passam ou falham.

Alguma dica para escolher o software ou se é melhor ir de código aberto ou comercial?

Com algumas ressalvas, acho que vale a pena observar as comunidades livres nesse espaço.

OGE está em um espaço estranho agora. Não é mais livre executar a variante GE produzida pela Oracle e a Oracle não está mais contribuindo com o código que grava de volta para o GE SCC, mas existem vários bifurcações do código que estão tentando ser utilizadas como projetos de código aberto e gratuitos. A Univa, em particular, liderou o processo , contratando desenvolvedores ex-Sun GE para continuar trabalhando em uma variante GE de código aberto e disponível gratuitamente. O Grid Engine tem duas coisas a seu favor: é fácil de configurar, ele pode lidar com trabalhos de execução curta (<2 minutos) sem transmitir muita sobrecarga de agendamento nos trabalhos que diminuem a produtividade. Sua grande desvantagem é que não há um suporte muito bom para o Windows. Alguns de nós se esforçam para portá-lo para rodar em Cygwin há muitos anos, mas com certeza não é tão bom quanto o nativo.

Agora, o Condor é o meu favorito das três tecnologias que você mencionou. Existe uma comunidade forte em torno do Condor e o software é muito maduro (> 20 anos agora). O suporte nativo ao Windows e ao sistema operacional POSIX significa que ele roda por todo o lugar muito bem. O mencionado DAGMan é apenas uma das muitas grandes peças que acompanham o Condor. Pode ser um pouco complicado de configurar, mas uma vez instalado e funcionando, é sólido. Ele possui uma linguagem incrivelmente flexível para realizar a correspondência de máquinas <-> e criar regras de uso para seus recursos. Ele também oferece suporte ao provisionamento dinâmico em máquinas, permitindo que os trabalhos selecionem a quantidade de recursos de máquinas necessários e, em seguida, anunciando novamente a diferença como ainda disponível. Ele suporta contadores de recursos globais para que você possa restringir coisas como licenças de software. E claro, possui o DAGMan, que é uma ferramenta incrivelmente poderosa para gerenciamento de fluxo de trabalho. A desvantagem do Condor é que a sobrecarga de agendamento para trabalhos de curta duração pode ser onerosa. O ideal é que os trabalhos sejam executados por mais de 2 minutos, caso contrário, o agendamento começa a se tornar uma grande parte do tempo do trabalho no sistema.

Torque é um pouco mais de nicho. Eu sei menos sobre isso, eu tenho medo. Ele se compara mais ao Grid Engine que ao Condor. Existem complementos pagos que a @warren mencionou que podem expandir o que o Torque básico e gratuito pode fazer.

Se você quiser experimentar as três tecnologias e ver como elas funcionam com suas cargas de trabalho específicas, o CycleCloud pode criar pools seguros, virtualizados e pré-configurados com Condor, GridEngine ou Torque - para que você não perca tempo tentando descobrir essas coisas. da sua parte. Seriam alguns dólares para montar pequenos pools de cada tecnologia e experimentá-los com cargas de trabalho representativas. (Aviso: trabalho para a Cycle Computing, criamos a CycleCloud)

Chronos parece muito promissor.

Chronos é o substituto do cron do Airbnb. É um planejador distribuído e tolerante a falhas que é executado sobre o Apache Mesos. Você pode usá-lo para orquestrar trabalhos. Ele suporta executores personalizados do Mesos, bem como o executor de comando padrão. Portanto, por padrão, o Chronos executa scripts sh (na maioria dos sistemas). O Chronos pode ser usado para interagir com sistemas como o Hadoop (incluindo o EMR), mesmo se os escravos do Mesos nos quais a execução ocorre não tiver o Hadoop instalado. Os scripts de wrapper incluídos permitem transferir arquivos e executá-los em uma máquina remota em segundo plano e usar retornos de chamada assíncronos para notificar o Chronos sobre a conclusão ou falhas do trabalho.

Também liderei um grande sucesso pessoal usando Jenkins como um substituto do cron. Ele lida com a execução de trabalhos em servidores remotos bastante bem. Aqui está um artigo: http://www.22ideastreet.com/blog/2014/05/02/replace-local-cron-with-jenkins/

Nos últimos 4,5 anos, trabalhei com a plataforma de automação de servidor da HP (nee Opsware) e com o restante do pacote Business Technology Optimization (automação de rede, orquestração de operações, etc.).

Para um ambiente grande o suficiente, o gerenciamento de tarefas via SA é uma ferramenta altamente viável (e desejável). Em conjunto com o OO, os trabalhos podem ser controlados via gerenciamento de controle de alterações, emissão de bilhetes, etc.

Aqui está a parte não tão divertida: é cara (muito cara). Você pode verificar algumas das sugestões em uma pergunta semelhante que fiz há algum tempo: Ferramentas de gerenciamento e auditoria do FLOSS Server .

Eu também diria que o Torque / Maui / Moab (da Adaptive Computing ) é muito legal: não tem certeza dos preços, mas também são ferramentas altamente flexíveis.

NOTA Uma abordagem completamente diferente do problema!

cron é antigo e desajeitado em certos termos.

Se você está realmente procurando novas maneiras de agendar, eu tentaria algo com base em um middleware de mensagens. Pense no RabbitMQ com clientes em cada servidor.

As dependências entre hosts podem ser resolvidas por "filas de notificação".

Eventos baseados em tempo "reais" são um pouco mais complicados, é para isso que serve o cron (e é muito bom, pelo menos em ambientes pequenos). Onde é difícil se apossar da idéia é evitar hickups. Como em: todas as noites às 01:00, faça um instantâneo. Você pode ver alguns picos de carga ou muitos logins com falha nesse exato momento, em toda a infraestrutura. Se você tiver uma abordagem baseada em fila, obterá pelo menos algum desvio de graça (embora não seja garantido - a menos que alguma lógica o implemente).

A solução é que, sem trabalhos baseados em tempo real, você não pode confiar em coisas como: sim, meus backups começarão às 0200h e, se ainda funcionarem às 0400h, algo está errado. O que é mais fácil é garantir que não sejam executados 2 trabalhos que interfiram no mesmo tempo. Basta criar um agente de bloqueio que consuma apenas um trabalho por vez.

A parte de gerenciamento seria uma interface da Web agradável, na qual os trabalhos poderiam ser enviados sob demanda ou - agora, voltemos ao "cron" ou à sua implementação favorita dele, o planejador de quartzo java tem uma granularidade nos segundos AFAIK - para o parte baseada no tempo basta usar bom cron velho :)

Por favor, não me diminua o voto por ser OT - é um conceito bastante grosseiro, mas como a pergunta não descarta dinheiro, pode-se gastar o dinheiro para obter a solução para os requisitos internos exatos, criando algo em vez de gastar o dinheiro comprando algo em que um fornecedor pensa que preenche alguns requisitos :)

Eu usei o Espresso (Cybermation) da CA. Não tenho certeza do que eles estão chamando agora. Eu também usei UC4. Ambos trabalham, custam muito dinheiro (no meu entender) e podem ser um urso para manter, mas fazem o que diz na lata. / Editar - faltou dizer que os aplicativos comerciais são muito caros. Definitivamente, posso concordar, mas para algumas empresas vale a pena, especialmente quando se trata de aplicativos de negócios que geram dinheiro.

Trabalhei com o Open Source Job Scheduler como uma opção para substituir um crontab central de mais de 2000 linhas em um ambiente de produção. As coisas ficaram tão complicadas com o cron que não conseguimos determinar o que eram as janelas de tempo de inatividade ou como lidar com as dependências entre servidores. Este produto ajudou, mas era um pouco complexo de configurar.