Cronograma do outgrowing: qual é o próximo escalonador? [fechadas]

Question

Estamos usando o cron por tanto tempo quanto me lembro para lidar com todas as nossas necessidades de agendamento de tarefas. Tudo a partir de clones / snapshots de armazenamento, relatórios de bancos de dados, relatórios diários do sistema e verificações de monitoramento são agendados em algumas centenas de servidores via cron.

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

Nós tentamos uma oferta comercial, mas no final ela foi considerada muito cara como um passo a frente do cron.

Eu vejo outras opções por aí, como SLURM, Oracle Grid Engine, Torque / Maui, Quartz, DIET e 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 afins. Nosso ambiente é bastante variado (vários Linuxes, 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). / p>

Alguém tem alguma experiência de passar do cron para uma oferta gerenciada mais centralmente? Alguma dica para escolher o software ou se é melhor ir open source ou comercial?

    

Answer 1

Condor, OGE e Torque podem levá-lo até lá, mas apenas o Condor tem gerenciamento de dependências integrado com o Ferramenta DAGMan . O DAGMan permite que você configure um gráfico acíclico dirigido que descreva seu fluxo de trabalho e o gerente cuide da movimentação de trabalhos em seu fluxo de trabalho e avaliação dos 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 ter uma etapa filho executada no AIX quando o pai é executado no Linux ou no Windows. O DAGMan não está preocupado com o local de execução dos jobs, apenas com os códigos de saída aprovados ou reprovados.

Any tips for choosing the software or whether it is better to go open source or commercial?

Com algumas ressalvas, acho que as comunidades livres neste espaço valem bem a pena olhar.

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 no GE SCC, mas existem vários garfos do código que estão tentando se consolidar como projetos livres e de código aberto. A Univa, em especial, liderou a cobrança , contratando ex-Sun GE para continuar trabalhando em uma variante GE de fonte aberta, disponível gratuitamente. O Grid Engine tem duas coisas para isso: é fácil de configurar, ele pode lidar com trabalhos de curta duração (< 2 minutos) sem transmitir muita sobrecarga de agendamento nos trabalhos que reduz a taxa de transferência. A grande desvantagem é que não há suporte muito bom para o Windows. Alguns de nós nos esforçamos para portá-lo para rodar no Cygwin há muitos anos, mas não é tão bom quanto o nativo, com certeza.

Agora Condor é o meu favorito das três tecnologias que você mencionou. Há uma comunidade strong em torno da Condor e o software é muito maduro (> 20 anos agora). O suporte nativo para Windows e POSIX OS significa que ele é executado em todo o lugar muito bem. O DAGMan acima mencionado é apenas uma das muitas grandes peças que vêm com o Condor. Pode ser um pouco complicado de configurar, mas uma vez instalado e funcionando, é sólido. Tem uma linguagem incrivelmente flexível para fazer o trabalho < - > correspondência e construção de regras de uso para seus recursos. Ele também suporta o provisionamento dinâmico em máquinas, permitindo que os trabalhos selecionem quantos recursos de máquinas eles precisam e, em seguida, anunciar 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, tem DAGMan, que é uma ferramenta incrivelmente poderosa para gerenciamento de fluxo de trabalho. A desvantagem para a Condor é a sobrecarga de programação para trabalhos de curta duração pode ser onerosa. Você deseja que os trabalhos sejam executados por mais de 2 minutos de maneira ideal, 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 do que ao Condor. Existem complementos pagos que o @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, CycleCloud pode ficar seguro, virtualizados, pools que são pré-configurados com Condor, GridEngine ou Torque - então não há tempo gasto em descobrir essas coisas de sua parte. Seriam alguns dólares para criar pequenos pools de cada tecnologia e testá-los com cargas de trabalho representativas. (Disclaimer: Eu trabalho para a Cycle Computing, nós fazemos CycleCloud)

    

Answer 2

O Chronos parece muito promissor.

Chronos is Airbnb's replacement for cron. It is a distributed and fault-tolerant scheduler that runs on top of Apache Mesos. You can use it to orchestrate jobs. It supports custom Mesos executors as well as the default command executor. Thus by default, Chronos executes sh (on most systems bash) scripts. Chronos can be used to interact with systems such as Hadoop (incl. EMR), even if the Mesos slaves on which execution happens do not have Hadoop installed. Included wrapper scripts allow transfering files and executing them on a remote machine in the background and using asynchronous callbacks to notify Chronos of job completion or failures.

Eu também tenho um grande sucesso pessoal usando Jenkins como substituto do cron. Ele lida com a execução de trabalhos em servidores remotos muito bem. Aqui está um writeup nele: link

    

Answer 3

Nos últimos 4,5 anos, trabalhei com a plataforma de automação de servidores da HP (nee Opsware) e com o restante do conjunto de otimização de tecnologia de negócios (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 mudanças, 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 eu fiz um tempo atrás: gerenciamento do FLOSS Server e ferramentas de auditoria .

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

_{^{Isenção de responsabilidade - Eu trabalho para um parceiro da HP BTO e Adaptive}}

Answer 4

NOTA Uma abordagem completamente diferente do problema!

cron é antigo e desajeitado em certos termos.

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

As dependências do Inter Host podem ser resolvidas por "filas de notificação".

"Real" Eventos baseados no tempo são um pouco mais complicados, e é exatamente isso que o cron é (e é muito bom, pelo menos em relação a ambientes pequenos). Onde é difícil entender a ideia é evitar os hickups. Como em: todas as noites às 01h00 faça um instantâneo. Você pode ver alguns picos de carga ou muitos logins com falha, naquele exato momento, em toda a sua 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 implemente isso).

A coisa a se fazer é que, sem trabalhos baseados em tempo real, você não pode confiar em coisas como: sim, meus backups começam em 0200h e se eles ainda rodarem em 04:00, algo está errado. O que é mais fácil de fazer é garantir que nenhum trabalho que interfira seja executado ao mesmo tempo. Basta fazer um agente de bloqueio que consuma apenas um trabalho de cada vez.

A parte de gerenciamento seria uma interface web agradável em que as tarefas poderiam ser submetidas sob demanda ou - agora ele está de volta ao "cron" ou sua implementação favorita do programador de quartzo java tem uma granularidade em segundos AFAIK - - para a parte baseada no tempo apenas use o bom e velho cron:)

Por favor, não me desanime por ser OT - é um conceito bastante difícil, mas como a questão não descarta dinheiro, é melhor gastar dinheiro para obter a solução para os requisitos internos exatos criando algo em vez de gastar dinheiro comprando algo em que um fornecedor acha que preenche alguns requisitos:)

    

Answer 5

Eu usei Espresso (Cybermation) da CA. Não tenho certeza do que eles estão chamando agora. Eu também usei o UC4. Ambos trabalham, custam muito dinheiro (a meu ver), e podem ser um urso para manter, mas fazem o que diz na lata. / Edit - saudades que você diz que os aplicativos comerciais são muito caros. Eu posso definitivamente concordar, mas para algumas empresas, vale a pena, especialmente quando é para aplicativos de negócios que ganham dinheiro.

    

Answer 6

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