HTCondor

O HTCondor pode ser habilitado facilmente em um cluster do CycleCloud modificando o "run_list" na seção de configuração da definição do cluster. Há três componentes básicos de um cluster HTCondor. O primeiro é o "gerente central" que fornece os daemons de agendamento e gerenciamento. O segundo componente de um cluster HTCondor é um ou mais agendadores dos quais os trabalhos são enviados para o sistema. O componente final é um ou mais nós de execução que são os hosts que executam a computação. Um modelo HTCondor simples pode ser semelhante a:

[cluster htcondor]

  [[node manager]]
  ImageName = cycle.image.centos7
  MachineType = Standard_A4 # 8 cores

      [[[configuration]]]
      run_list = role[central_manager]

  [[node scheduler]]
  ImageName = cycle.image.centos7
  MachineType = Standard_A4 # 8 cores

      [[[configuration]]]
      run_list = role[condor_scheduler_role],role[filer_role],role[scheduler]

  [[nodearray execute]]
  ImageName = cycle.image.centos7
  MachineType = Standard_A1 # 1 core
  Count = 1

      [[[configuration]]]
      run_list = role[usc_execute]

Importar e iniciar um cluster com definição no CycleCloud produzirá um nó "gerenciador" e um "agendador", bem como um nó "execute". Os nós de execução podem ser adicionados ao cluster por meio do cyclecloud add_node comando. Para adicionar mais 10 nós de execução:

cyclecloud add_node htcondor -t execute -c 10

Dimensionamento automático do HTCondor

O CycleCloud dá suporte ao dimensionamento automático para HTCondor, o que significa que o software monitorará o status da fila e ativará e desativará nós conforme necessário para concluir o trabalho em uma quantidade ideal de tempo/custo. Você pode habilitar o dimensionamento automático para HTCondor adicionando Autoscale=true à sua definição de cluster:

[cluster htcondor]
Autoscale = True

Uso Avançado do HTCondor

Se você souber o tempo de execução médio dos trabalhos, poderá definir average_runtime (em minutos) em seu trabalho. O CycleCloud usará isso para iniciar o número mínimo de nós (por exemplo, cinco trabalhos de 10 minutos iniciarão apenas um único nó em vez de cinco quando average_runtime estiver definido como 10).

Nodearray de dimensionamento automático

Por padrão, o HTCondor solicitará núcleos do nodearray chamado 'execute'. Se um trabalho exigir uma nodearray diferente (por exemplo, se determinados trabalhos dentro de um fluxo de trabalho tiverem um alto requisito de memória), você poderá especificar um slot_type atributo para o trabalho. Por exemplo, a adição +slot_type = "highmemory" fará com que o HTCondor solicite um nó da nodearray "highmemory" em vez de "execute" (observe que isso atualmente requer htcondor.slot_type = "highmemory" ser definido na seção do [[[configuration]]] nodearray). Isso não afetará a forma como o HTCondor agenda os trabalhos, portanto, talvez você queira incluir o slot_type atributo iniciado nas expressões ou rank no requirements trabalho. Por exemplo: Requirements = target.slot_type = "highmemory".

Enviando trabalhos para o HTCondor

A maneira mais genérica de enviar trabalhos para um agendador HTCondor é o comando (executar em um nó do agendador):

condor_submit my_job.submit

Um arquivo de envio de exemplo pode ter esta aparência:

      Universe = vanilla
      Executable = do_science
      Arguments = -v --win-prize=true
      Output = log/$(Cluster).$(Process).out
      Error = log/$(Cluster).$(Process).err
      Should_transfer_files = if_needed
      When_to_transfer_output = On_exit
      +average_runtime = 10
      +slot_type = "highmemory"
      Queue

Referência de configuração do HTCondor

Veja a seguir as opções de configuração específicas do HTCondor que você pode definir para personalizar a funcionalidade:

Opções de configuração do HTCondor-Specific	Descrição
htcondor.agent_enabled	Se for verdadeiro, use o condor_agent para envio de trabalho e sondagem. Padrão: false
htcondor.agent_version	A versão do condor_agent a ser usada. Padrão: 1.27
htcondor.classad_lifetime	O tempo de vida padrão de classads (em segundos). Padrão: 700
htcondor.condor_owner	A conta do Linux que possui os scripts de redução do HTCondor. Padrão: raiz
htcondor.condor_group	O grupo linux que possui os scripts de redução de escala do HTCondor. Padrão: raiz
htcondor.data_dir	O diretório para logs, diretórios de spool, diretórios de execução e arquivo de configuração local. Padrão: /mnt/condor_data (Linux), C:\All Services\condor_local (Windows)
htcondor.ignore_hyperthreads	(Somente Windows) Defina o número de CPUs como metade das CPUs detectadas como uma maneira de "desabilitar" o hiperthreading. Se estiver usando o dimensionamento automático, especifique a contagem de núcleos não hiperthread com a Cores configuração na seção [[nó]] ou [[nodearray]]. Padrão: false
htcondor.install_dir	O diretório no qual o HTCondor está instalado. Padrão: /opt/condor (Linux), C:\condor (Windows)
htcondor.job_start_count	O número de trabalhos que um schedd iniciará por ciclo. 0 é ilimitado. Padrão: 20
htcondor.job_start_delay	O número de segundos entre cada intervalo de início do trabalho. 0 é imediato. Padrão: 1
htcondor.max_history_log	O tamanho máximo do arquivo de histórico de trabalho em bytes. Padrão: 20971520
htcondor.max_history_rotations	O número máximo de arquivos de histórico de trabalho a serem mantidos. Padrão: 20
htcondor.negotiator_cycle_delay	O número mínimo de segundos antes que um novo ciclo de negociadores possa começar. Padrão: 20
htcondor.negotiator_interval	Com que frequência (em segundos) o condor_negotiator inicia um ciclo de negociação. Padrão: 60
htcondor.negotiator_inform_startd	Se for verdade, o negociador informa o início quando ele é correspondido a um trabalho. Padrão: true
htcondor.remove_stopped_nodes	Se for true, os nós de execução interrompidos serão removidos da exibição CycleServer em vez de serem marcados como "inativos".
htcondor.running	Se for verdade, os daemons de coletor e negociador do HTCondor são executados no gerente central. Caso contrário, somente o condor_master será executado. Padrão: true
htcondor.scheduler_dual	Se for verdade, os agendadores executam dois schedds. Padrão: true
htcondor.single_slot	Se verdadeiro, trata o computador como um único slot (independentemente do número de núcleos que o computador possui). Padrão: false
htcondor.slot_type	Define o slot_type de uma matriz de nós para dimensionamento automático. Padrão: executar
htcondor.update_interval	O intervalo (em segundos) para o iniciado publicar uma atualização no coletor. Padrão: 240
htcondor.use_cache_config	Se for verdadeiro, use cache_config para ter o CycleServer de sondagem de instância para configuração. Padrão: false
htcondor.version	A versão do HTCondor a ser instalada. Padrão: 8.2.6

Arquivo de configuração gerado automaticamente pelo HTCondor

O HTCondor tem um grande número de configurações, incluindo atributos definidos pelo usuário. O CycleCloud oferece a capacidade de criar um arquivo de configuração personalizado usando atributos definidos no cluster:

Atributo	Descrição
htcondor.custom_config.enabled	Se for verdadeiro, um arquivo de configuração será gerado usando os atributos especificados. Padrão: false
htcondor.custom_config.file_name	O nome do arquivo (colocado em htcondor.data_dir/config) a ser gravado. Padrão: ZZZ-custom_config.txt
htcondor.custom_config.settings	Os atributos a serem gravados no arquivo de configuração personalizado, como htcondor.custom_config.settings.max_jobs_running = 5000

Observação

Atributos de configuração do HTCondor que contêm um . não pode ser especificado usando esse método. Se esses atributos forem necessários, eles deverão ser especificados em um livro de receitas ou em um arquivo instalado com cluster-init.

O CycleCloud dá suporte a um conjunto padrão de atributos de preenchimento automático entre agendadores:

Atributo	Descrição
cyclecloud.cluster.autoscale.stop_enabled	O dimensionamento automático está habilitado neste nó? [true/false]
cyclecloud.cluster.autoscale.idle_time_after_jobs	A quantidade de tempo (em segundos) para um nó ficar ocioso após concluir trabalhos antes de ser reduzido horizontalmente.
cyclecloud.cluster.autoscale.idle_time_before_jobs	A quantidade de tempo (em segundos) para um nó ficar ocioso antes de concluir trabalhos antes de ser reduzido.