Download grátis do Condor , download do Condor no download do software

Agendar e executar aplicativos intensivos de CPU remoto usando os ciclos ociosos de estações de trabalho distributivas O Condor é um sistema especializado de gerenciamento de carga de trabalho para trabalhos intensivos de computação. Como outros sistemas de lote completos, o Condor fornece um mecanismo de enfileiramento de emprego, a política de programação, o esquema de prioridade, o monitoramento de recursos e o gerenciamento de recursos. Os usuários submetem seus empregos seriais ou paralelos para Condor, Condor coloca-os em uma fila, escolhe quando e onde executar os trabalhos com base em uma política, monitora cuidadosamente seu progresso e, finalmente, informa o usuário após a conclusão. O que fornece funcionalidade semelhante à de Um sistema de fila de lote mais tradicional, a romance da arquitetura do Condor permite que ele tenha sucesso em áreas onde os sistemas tradicionais de agendamento falham. O Condor pode ser usado para gerenciar um cluster de nós de computação dedicados (como um cluster "Beowulf"). Além disso, mecanismos exclusivos permitem que o condor efetivamente aproveite a energia da CPU desperdiçada de outra forma de trabalho de desktop. Por exemplo, o Condor pode ser configurado para usar apenas máquinas de desktop onde o teclado e o mouse estão ociosos. Se o condor deve detectar que uma máquina não está mais disponível (como uma tecla de prensa detectada), em muitas circunstâncias, o Condor é capaz de produzir transparentemente um ponto de verificação e migrar um trabalho para uma máquina diferente, que de outra forma seria ociosa. O Condor não requer um sistema de arquivos compartilhado em máquinas - se nenhum sistema de arquivos compartilhado estiver disponível, o Condor pode transferir os arquivos de dados do trabalho em nome do usuário, ou Condor pode ser capaz de redirecionar de forma transparente todas as solicitações de E / S do trabalho para o enviar máquina. Como resultado, o Condor pode ser usado para combinar perfeitamente toda a energia computacional de uma organização em um recurso. Condor monitora uma piscina de máquinas para encontrar máquinas ociosas que são usadas para concluir os trabalhos enviados, e também fornece mecanismos remotos de sistema e verificação de verificação que permitem a execução remota transparente e migração de trabalho.Note: Condor é licenciado e distribuído sob a licença do Apache. O que há de novo nesta versão: · Esta versão é incompatível ao se comunicar com versões anteriores do Condor se o CCB estiver ativado ou se o private_network_name estiver configurado. · Atualizou a versão Drmaa. Esta nova versão é compatível com o GFD.133, o padrão de recomendação do Drmaa 1.0 Grid. Três novas funções foram adicionadas para atender aos requisitos da especificação e vários bugs foram corrigidos. Novas características: · Adicionado suporte para usar qualquer script reconhecido como um executável em um arquivo de envio no Windows. Para mais informações, consulte a seção 6.2.6 na página . · Melhor suporte para redes privadas: Adicionado CCB, o corretor de conexão do Condor. É semelhante na funcionalidade do GCB, o intermediário de conexão genérica, mas tem várias vantagens, incluindo facilidade de uso e trabalhar no Windows, bem como plataformas UNIX. O GCB continua a funcionar, mas podemos removê-lo algum tempo na série 7.3 de desenvolvimento. O principal recurso ausente no CCB no momento que a impede de substituir o GCB, é suporte para conectividade de uma rede privada para outra. O CCB funciona apenas ao se conectar de uma rede pública a um privado. Por exemplo, os trabalhos podem ser enviados de um Condor_Schedd na Internet pública para Condor_startd Daemons em uma rede privada, se os daemons Condor_startd estiverem configurados para usar um servidor CCB acessível ao daemon Condor_schedd. No entanto, se o daemon Condor_schedd estiver em uma rede privada e os daemons Condor_startd estiverem em uma rede privada diferente, o CCB não ajuda. Para mais informações sobre CCB, consulte a seção 3.7.3. · Adicionado suporte para uma afinidade da CPU em plataformas Linux. · Adicionado suporte para a opção Condor_Q-Better-Analisar no Windows. · Adicionado Want_hold. Quando o preempt se torna verdadeiro, se Ganhar_hold for verdade, o trabalho é colocado em espera pelo motivo (opcionalmente) especificado por want_hold_reason e want_hold_subcode. Essas expressões políticas são avaliadas pela máquina de execução. Como de costume, o proprietário do trabalho pode especificar periodic_release e / ou periodic_remove expressões para reagir a estados de espera específicos automaticamente. · Adicionado a função de classad depuração (). Veja a seção 4.1.1 para os detalhes dessa função. · O Condor_Schedd agora pode usar somas de verificação MD5 para evitar armazenar várias cópias do mesmo executável em seu diretório de spool. Observe que este recurso afeta apenas executáveis enviados para o Condor_Schedd através do comando Copy_to_Spool em um arquivo de envio de envio. · Reduzido o número de sono que o Condor_Dagman faz para manter a consistência do arquivo de log quando um DAG usa vários logs de usuário para trabalhos do nó. Dagman agora faz um sono por ciclo de envio, em vez de um sono para cada submete. · Adicionado o sinalizador de linha de comando -import_env para condor_submit_dag. Isso explicitamente coloca o ambiente do Supertor no arquivo .condor.sub. · Otimizou a remoção de um grande número de empregos. Anteriormente, a remoção de dezenas de milhares de empregos fez com que o daemon Condor_schedd consumisse um monte de tempo de CPU por vários minutos. · Uso de memória reduzido pelo daemon condor_shadow. Como há um processo Condor_Shadow por trabalho de execução, isso ajuda a aumentar o número de trabalhos em execução que uma máquina de envio pode manipular. No Linux 2.6, descobrimos que a execução de 10.000 empregos de uma única máquina de envio requer cerca de 10gbytes de RAM do sistema. Também encontramos nesse caso que para executar mais de 10.000 trabalhos simultâneos requer uma máquina de envio de 64 bits. Em uma plataforma Linux de 32 bits, a memória do kernel está esgotada, independentemente de quanta ram adicional o sistema tem. · Reduziu o uso da memória do daemon Condor_Collector, quando update_collector_with_tcp = true. Adições e alterações variáveis de configuração: · A nova variável de configuração Open_verb_for__files permite que o intérprete padrão para scripts com uma extensão ext será alterado. Para mais informações, consulte a seção 6.2.6 na página . · A nova variável de configuração CCB_Address configura um daemon para usar um ou mais servidores CCB para permitir a comunicação com os componentes do Condor fora da rede privada. Veja a página . · A nova variável de configuração MAX_FILE_Descriptores (somente em plataformas UNIX) especifica o limite de descritor de arquivo necessário para um daemon Condor. Os descritores de arquivos são um recurso do sistema usado para arquivos abertos e para conexões de rede. Condor daemons que fazem muitas conexões de rede simultâneas podem exigir um número maior de descritores de arquivos. Por exemplo, consulte a página para obter informações sobre os requisitos do descritor de arquivos do CCB. · As novas variáveis de configuração enforce_cpu_affinity e slotx_cpu_affinity nas plataformas Linux permitem que o Condor bloqueie os slots para dadas CPUs. · A nova variável de configuração Debug_Time_Format permite uma especificação personalizada para o formato do tempo impresso no início de cada linha no arquivo de log do daemon. Veja 3.3.4 para a definição completa dessa variável. · A nova variável de configuração Share_spooled_executables é um valor booleano que determina se o daemon Condor_Schedd usará somas de verificação MD5 para evitar armazenar várias cópias do mesmo executável no diretório de spool. A configuração padrão é verdadeira.

Condor Software Relacionado