software para gerenciamento de processos em lote no unix

2

Estou procurando uma boa solução de código aberto para gerenciar muitos trabalhos em lote em um cluster de máquinas. Analisei as soluções indicadas nesta postagem , mas ela não parece ser realmente o que estou procurando, ou talvez os projetos mencionados tenham pouca documentação.

Temos um bom conjunto de operações em lote que precisam acontecer em vários cronogramas. Essas operações em lote às vezes têm dependências, pois nos registros são processados com a tarefa em lote A, então as tarefas em lote B e C podem ser executadas nos dados resultantes. A utilização de recursos (balanceamento de empregos entre as nossas máquinas de lote) provavelmente não é um problema tão grande, apesar de que seria um ótimo bônus.

Hoje lidamos com isso com uma combinação de scripts fcron e shell. Mas é claro que é bastante difícil acompanhar quais trabalhos estão programados para serem executados em quais máquinas. Também nem sempre é óbvio quando algum trabalho foi interrompido (ou está sendo executado muito mais do que o esperado) ou até mesmo falha apenas para a direita.

Este não pode ser um problema exclusivo para nós. Na verdade, tínhamos uma solução doméstica em uma empresa anterior, mas nunca fornecíamos código aberto. Alguém tem uma boa solução?

    
por rhettg 29.10.2009 / 03:06

4 respostas

2

Existem várias soluções que você pode querer dar uma olhada:

Torque - Esta é uma variação da base de código original do PBS (Portable Batch Scheduler) . Eles o chamam de gerenciador de recursos porque, tecnicamente, ele não cuida dos trabalhos de agendamento, embora inclua vários agendadores. No entanto, ele cuidará de gerenciar e alocar sua CPU, memória, arquivo e outros recursos consumíveis do nó de computação. Se você tem algo mais do que as necessidades básicas de agendamento, você provavelmente vai querer complementá-lo com o Maui Cluster Agendador . Eu sei mais sobre isso porque é o que usamos. Pode ser um pouco difícil, porque a maioria é desenvolvida pela comunidade, e a maioria dos desenvolvedores são sysadmins e não engenheiros de software. Há um produto comercial que surgiu da mesma base de código da PBS chamada PBS Professional , que parece mais maduro e está disponível por uma taxa relativamente modesta.

Mecanismo Sun Grid - Semelhante aos sistemas baseados em PBS, mas escritos pela Sun. O gerenciador de recursos e o planejador estão mais integrados nesse sistema e oferecem alguns modos diferentes de operação e alocação de recursos. Apesar de ser um produto da Sun, aparentemente funciona bem no Linux e em outros sistemas operacionais, não apenas na solaris.

Plataforma LSF - É outra oferta comercial popular no mesmo espaço.

Condor - Outro sistema de agendamento de lotes mais adequado para alto rendimento, toneladas de trabalhos curtos.

SLURM - é outra oferta de código aberto. Não é tão maduro quanto os produtos baseados em PBS, mas tem uma arquitetura mais agradável baseada em plugins e é fácil de instalar se você usar a distribuição CAOS NSA Linux e o gerenciador de cluster Perceus. Veja este artigo da Linux Magazine para um exemplo de como é fácil começar a trabalhar.

Qual desses você escolhe é basicamente uma questão de preferência e corresponde às suas necessidades. Eu diria que o Torque e o SGE têm uma pequena inclinação para clusters multiusuários em um ambiente de computação científica. Com base no que vi do PBS Professional da Altair, parece que é muito mais adequado para um ambiente comercial e tem um conjunto de ferramentas melhor para o desenvolvimento de fluxos de trabalho específicos do produto. O mesmo vale para o LSF.

O SLURM e o Condor são provavelmente os mais fáceis de usar e, se seus requisitos forem relativamente modestos, eles podem ser os mais adequados. No entanto, se você precisa de políticas de agendamento mais complicadas e muitos usuários enviam trabalhos para seus sistemas, eles podem estar faltando a esse respeito sem serem complementados por um agendador externo.

    
por 29.10.2009 / 05:56
1

Isso pode ser exagerado para o seu caso, mas você fez o check out do planejador de lote de Torque opensource para clusters? É comumente usado em grades de computação e grandes clusters: Sobre o Torque .

    
por 29.10.2009 / 03:14
1

Você já investigou o Gearman?

Um aplicativo com tecnologia Gearman consiste em três partes: um cliente, um trabalhador e um servidor de trabalho. O cliente é responsável por criar um trabalho para ser executado e enviá-lo para um servidor de trabalho. O servidor de trabalho encontrará um funcionário adequado que possa executar o trabalho e encaminhar o trabalho. O trabalhador executa o trabalho solicitado pelo cliente e envia uma resposta ao cliente por meio do servidor de trabalho. O Gearman fornece APIs de cliente e de trabalho que seus aplicativos chamam para falar com o servidor de tarefas do Gearman (também conhecido como comando de engrenagem) para que você não precise lidar com rede ou mapeamento de trabalhos.

link

Felicidades

    
por 29.10.2009 / 17:22
0

Eu posso não entender a complexidade do que você tem que alcançar, mas para os casos em que trabalho, é tratado assim. Você determina o local para executar a tarefa cron com base no final da fonte de dados. Um script executado a partir da máquina com os dados a serem processados reúne o que precisa ser processado e, no final desse script, usa scp para enviá-lo ao próximo sistema e ssh para executar o script no segundo sistema. Você pode executar um script remoto por ssh com:

ssh hostname "/ usr / local / caminho / para / script"

O segundo sistema faz sua coisa com os dados, e no final desse script, faz qualquer scp adicional de dados e ssh no próximo sistema, etc. Desta forma, há uma cadeia de eventos, e apenas um cron envolvido . Com uma tarefa cron na máquina de origem, não há como adivinhar se um segundo cron pode ser executado com segurança em um determinado período, dependendo de o primeiro cron ter terminado. Você só precisa configurar algumas entradas de .ssh / authorized_keys e ir embora. Os resultados de qualquer falha são relatados pelo cron inicial na primeira máquina, mesmo que ocorram downstream.

    
por 29.10.2009 / 05:33