Visão geral da criação e execução de jobs

Este documento explica o processo de execução e as opções de criação de jobs. Com os jobs em lote, é possível executar cargas de trabalho de processamento em lote no Google Cloud. Para saber mais sobre os componentes de um job e os pré-requisitos para usar o Batch, consulte Começar a usar o Batch.

Como funciona a criação e a execução de jobs

Para usar o Batch, crie um job que especifique sua carga de trabalho e os requisitos dela. Em seguida, o Batch executa automaticamente.

Os detalhes de como a criação e a execução de jobs funcionam são descritos nas seções a seguir:

Ciclo de vida do job

Esta seção descreve o ciclo de vida de um job e das tarefas dele, desde a criação até a exclusão.

Para cada carga de trabalho que você quer executar no Batch, siga este processo básico:

  1. Criar um trabalho:você define a carga de trabalho que quer executar especificando os executáveis, as tarefas e outros requisitos de um trabalho. Os detalhes para criar um job são apresentados na seção Opções de criação de jobs neste documento.
  2. Monitore e resolva problemas do job:quando você termina de criar um job, ele é automaticamente enfileirado, programado e executado nos recursos especificados. É possível conferir os detalhes de um job criado ou de qualquer uma das tarefas dele para ver o estado atual. Se necessário, cancele um job para interrompê-lo ou evitar que ele seja executado. Depois que um job estiver em execução ou concluído, também será possível monitorar e analisar o job usando registros. Se um job falhar, você poderá resolver o problema usando mensagens de erro, eventos de status ou registros para diagnosticar a questão antes de recriar o job.
  3. Excluir ou exportar o job:as informações de um job no Batch ficam disponíveis até que você ou Google Cloud as exclua. OGoogle Cloud exclui automaticamente um job 60 dias após a conclusão. Antes disso, você pode excluir o job por conta própria ou, se precisar manter as informações, exporte os dados do job no Batch antes da exclusão. As informações sobre um trabalho armazenado em outros serviços do Google Cloud não são afetadas quando um trabalho é excluído e têm políticas de retenção separadas. Por exemplo, os registros de um job são retidos e excluídos automaticamente de acordo com a política de retenção do Cloud Logging.

Depois de criar um job, ele passa pelos seguintes estados:

  1. Em fila (QUEUED): o pedido de job foi aceito e está aguardando na fila. O job permanece na fila do projeto até que possa ser programado, o que acontece quando os recursos necessários estão disponíveis e os jobs anteriores a ele foram avaliados. No entanto, para evitar que os jobs fiquem obsoletos, se um job exceder o tempo máximo de espera na fila, o Batch vai falhar automaticamente em vez de programá-lo.
  2. Programado (SCHEDULED): o job foi selecionado na fila para começar a ser executado e os recursos estão sendo alocados.
  3. Em execução (RUNNING): os recursos do job foram criados com sucesso e as tarefas podem começar a ser executadas.

    Quando um job está em execução, cada uma das tarefas passa pelos seguintes estados:

    1. Pendente (PENDING): a tarefa está aguardando uma VM para ser executada.
    2. Atribuída (ASSIGNED): a tarefa foi atribuída a uma VM para execução.
    3. Em execução (RUNNING): a tarefa está sendo executada em uma VM.
    4. Uma tarefa termina em um dos seguintes estados:

      • Concluída (SUCCEEDED): a tarefa foi concluída porque cada um dos executáveis atendeu a uma das seguintes condições:

        • O executável foi concluído (retornou um código de saída de zero).
        • O executável falhou (retornou um código de saída diferente de zero), mas era um executável não crítico (você ativou o campo ignoreExitStatus do executável).
        • O executável não foi concluído, mas era um executável em segundo plano (você ativou o campo background do executável).
      • Falha (FAILED): a tarefa falhou e parou de ser executada porque pelo menos um executável não atendeu às condições anteriores.

    Os recursos do job são excluídos antes da conclusão dele.

  4. Um job termina em um dos seguintes estados:

    • Concluído (SUCCEEDED): o job foi concluído porque todas as tarefas foram concluídas.
    • Falha (FAILED): o job falhou e parou de ser executado porque pelo menos uma das tarefas falhou.
    • Cancelado (CANCELLED): um usuário cancelou o job antes que ele fosse concluído ou falhasse.

Para mais informações, consulte estados de jobs e estados de tarefas na documentação de referência.

Filas e agendamento de jobs

Em geral, os jobs têm mais chances de serem executados e concluídos mais cedo se forem menores e exigirem apenas alguns recursos comuns. Os jobs de exemplo na documentação do Batch, que geralmente são muito pequenos e usam recursos mínimos, podem ser concluídos em poucos minutos.

Especificamente, o tempo que um job leva para concluir o enfileiramento e o agendamento varia para diferentes jobs e em diferentes momentos com base nos seguintes fatores:

  • Pré-requisitos de job especificados pelo usuário:qualquer pré-requisito que você exija que seja atendido antes da programação do job.

    Por padrão, um job não tem pré-requisitos. Também é possível especificar que um job não pode ser programado até que um ou mais jobs atuais tenham sido concluídos ou falhado. Para mais informações, consulte Programar jobs dependentes (Prévia).

  • Prioridade do job:a prioridade de um job em relação às prioridades de outros jobs no seu projeto.

    Também é possível especificar a prioridade de um job incluindo a flag --priority para a CLI gcloud ou o campo JSON priority. É possível definir a prioridade de um job como um número entre 0 (prioridade mais baixa) e 99 (prioridade mais alta). Definir uma prioridade mais alta pode ajudar um job a ser executado antes de jobs de prioridade mais baixa no seu projeto.

    Se você não configurar a prioridade de um job, ele usará a prioridade mais baixa, 0. Se dois jobs enfileirados tiverem a mesma prioridade, o job criado primeiro terá a prioridade mais alta.

  • Disponibilidade de recursos do job:disponibilidade dos recursos necessários do job nos locais permitidos.

    Primeiro, um job não pode ser executado se você especificar recursos que não são oferecidos nesse local. Quando isso acontece, o job falha com um erro de disponibilidade de zona.

    Em segundo lugar, um job tem mais chances de ser atrasado ou falhar se algum dos recursos necessários estiver com baixa capacidade em relação à demanda atual devido a erros de disponibilidade de recursos. Como resultado, seu job pode ser executado antes quando você precisa de menos recursos, que são mais comuns, e não restringe a execução do job em nenhuma zona de uma região.

    Para mais informações sobre os recursos de um job, consulte Execução de job neste documento. Para mais informações sobre os locais que você pode especificar para um job em lote e os recursos dele, consulte a página Locais.

  • Cotas e limites:os limites que seu projeto tem para recursos e solicitações de Google Cloud .

    Um job não pode ser executado se exceder um limite ou a cota do projeto para qualquer um dos recursos ou solicitações necessários. Quando isso acontece, o Batch pode atrasar um job e tentar de novo mais tarde ou falhar o job e mostrar um erro relacionado.

    Para evitar atrasos e erros no job, crie jobs que obedeçam a todos os limites relevantes e verifique se o projeto tem cota relevante suficiente. Para mais informações, consulte Cotas e limites de lote.

Execução do trabalho

O tempo necessário para a execução de um job pode variar de acordo com o agendamento de tarefas e os recursos do job.

Agendamento de tarefas

Quando um job é executado, as tarefas são programadas de acordo com o campo de política de programação (schedulingPolicy), que permite especificar uma das seguintes opções:

  • Assim que possível (AS_SOON_AS_POSSIBLE) (padrão): as tarefas são executadas assim que os recursos ficam disponíveis e podem ser executadas em paralelo. A quantidade de tarefas executadas por vez depende das tarefas paralelas por VM permitidas pelos recursos do job e outras opções de configuração, conforme explicado em Recursos do job neste documento.
  • Em ordem (IN_ORDER): as tarefas são executadas uma de cada vez em ordem crescente de índice.

Recursos de job

Cada job em lote é executado em um grupo gerenciado de instâncias regional (MIG), que é um grupo de uma ou mais instâncias de máquina virtual (VM) do Compute Engine correspondentes, cada uma localizada em uma das zonas incluídas. Cada VM tem hardware dedicado para núcleos de CPU (especificamente CPUs virtuais (vCPUs)) e memória, que afetam o desempenho do seu job, e um disco de inicialização, que armazena uma imagem do sistema operacional (SO) e instruções para executar o job.

Durante o tempo de execução de um job, o Batch cria e exclui automaticamente os recursos que atendem às suas especificações. Ao criar um job, você configura os recursos dele especificando o seguinte:

  • Recursos de computação por tarefa:a menos que os valores padrão sejam suficientes, especifique os recursos de computação (vCPUs, memória e, se necessário, armazenamento extra no disco de inicialização) necessários para a execução de cada tarefa. Para mais informações, consulte os campos recursos de computação por tarefa (computeResource).

  • Recursos de VM:opcionalmente, você também pode especificar as VMs do job, como o tipo de máquina e o SO, e recursos adicionais, como GPUs e volumes de armazenamento, principalmente usando os campos da política de recursos de VM (instances[].policy) ou o campo alternativo instances[].instanceTemplate. (Opcionalmente, você também pode usar os campos instanceFlexibilityPolicy se quiser permitir vários tipos de máquina para um job.)

    Se você deixar esses campos indefinidos (o que não é possível ao criar um job usando o consoleGoogle Cloud ), o Batch vai tentar selecionar automaticamente VMs compatíveis e não vai adicionar outros recursos.

O número de VMs e de tarefas que podem ser executadas simultaneamente em cada VM varia para diferentes jobs com base no agendamento de tarefas e nos requisitos de hardware especificados. Se você especificar que as tarefas de um job sejam executadas IN_ORDER, o job terá uma VM e executará apenas uma tarefa por vez. Caso contrário, se as tarefas de um job forem executadas AS_SOON_AS_POSSIBLE, você poderá estimar o número de VMs e de tarefas simultâneas usando a seguinte fórmula:

\[{vmsPerJob}=\frac{taskCount}{parallelTasksPerVm}\]

Esta fórmula tem os seguintes valores:

  • \({vmsPerJob}\): o número máximo de VMs para um job. A quantidade real de VMs criadas para um job pode ser menor. Por exemplo, se o Batch espera que seja mais rápido executar um job com menos recursos do que esperar por mais recursos. Esse valor também é limitado pelos limites de VMs simultâneas por job.
  • \({taskCount}\): o número total de tarefas do job, que você define usando o campo de contagem de tarefas (taskCount).
  • \({parallelTasksPerVM}\): o número máximo de tarefas que podem ser executadas em uma VM simultaneamente.

    Esse valor é determinado por todos os seguintes critérios:

    • O valor mínimo é uma tarefa.

    • O valor máximo é o menor entre 20 tarefas e, se definido, o valor do campo Número máximo de tarefas paralelas por job (parallelism).

    • Se o campo máximo de tarefas paralelas por VM (taskCountPerNode) estiver definido, esse valor será usado.

      Caso contrário, se taskCountPerNode não estiver definido, o Batch decidirá um valor dividindo o número total de recursos de computação (especificamente vCPUs) por VM na quantidade necessária para cada tarefa:

      \[{parallelTasksPerVm}=\frac{vcpusPerVm}{vcpusPerTask}\]

      Esta fórmula tem os seguintes valores:

      • \({vcpusPerVm}\): o número total de vCPUs por VM, que é determinado pelo tipo de máquina das VMs do seu job.

      • \({vcpusPerTask}\): o número de vCPUs por tarefa, que é determinado pela conversão das unidades do campo "vCPUs por tarefa (cpuMilli)".

Opções de criação de jobs

Criar e executar um job básico explica os fundamentos, incluindo como definir um executável usando um script ou imagem do contêiner e como configurar variáveis de ambiente predefinidas e personalizadas.

Depois de entender os fundamentos da criação de jobs, crie um job que use uma ou mais das seguintes opções de configuração adicionais:

  • Controlar o acesso a um job:

  • Configure outras opções para um job:

    • Configurar a comunicação de tarefas usando uma biblioteca MPI explica como configurar um job com tarefas interdependentes que se comunicam entre si em diferentes VMs usando uma biblioteca de Message Passing Interface (MPI). Um caso de uso comum para MPI são cargas de trabalho de computação de alto desempenho (HPC) de acoplamento rígido.

    • Personalize os recursos em que um job é executado:

      • Definir recursos de job usando um modelo de instância de VM explica como especificar um modelo de VM do Compute Engine para definir os recursos de um job ao criar um job. Essa é uma alternativa a especificar os recursos de um job diretamente usando o campo instances[].policy.

      • Usar GPUs em um job explica como definir um job que usa uma ou mais unidades de processamento gráfico (GPUs). Os casos de uso comuns para jobs que usam GPUs incluem cargas de trabalho de processamento de dados intensivo ou de machine learning (ML).

      • Usar volumes de armazenamento para um job explica como definir um job que pode acessar um ou mais volumes de armazenamento externos. As opções de armazenamento incluem discos permanentes novos ou atuais, SSDs locais novos, buckets do Cloud Storage atuais e um sistema de arquivos de rede (NFS) atual, como um compartilhamento de arquivos do Filestore.

      • A visão geral do ambiente do SO da VM mostra quando e como personalizar o ambiente do sistema operacional (SO) da VM para um job, incluindo a imagem do SO da VM e os discos de inicialização do job.

    • Otimizar vários aspectos de um job:

      • Melhorar o monitoramento e a análise:

      • Programar jobs dependentes (prévia) explica como especificar um job que não é executado até que um ou mais jobs de dependência existentes sejam concluídos ou falhem. Se você tiver uma carga de trabalho com requisitos de recursos variados, poderá reduzir os custos e o uso da cota separando os tipos de VMs usadas para operações de baixa demanda (como preparação de dados) e operações com uso intensivo de computação (como processamento de dados).

      • Automatizar novas tentativas de tarefas explica como tentar novamente as tarefas de um job automaticamente após todas as falhas ou as falhas especificadas. As novas tentativas automáticas podem ajudar a reduzir o atrito na solução de problemas e o tempo de execução geral necessário para jobs que apresentam erros temporários. Por exemplo, use novas tentativas automáticas para um job executado em VMs spot, que oferecem descontos significativos, mas podem não estar sempre disponíveis e podem ser interrompidas a qualquer momento.

      • Limitar tempos de execução usando tempos limite explica como limitar o tempo permitido para execução de uma tarefa ou um executável. Ao evitar tempos de execução excessivos, você pode reduzir custos e atrasos inesperados.

      • Melhorar a capacidade de obtenção de recursos:

      • Reduzir a latência:

        • Colocar VMs no mesmo local para reduzir a latência explica como reduzir a latência de rede entre as VMs de um job exigindo que elas estejam localizadas fisicamente próximas umas das outras. Esse benefício de desempenho pode ser especialmente útil para jobs que têm comunicações de rede frequentes entre VMs, como tarefas que se comunicam usando bibliotecas MPI.

        • Usar streaming de imagens explica como melhorar o tempo de inicialização do job fazendo streaming de imagens de contêiner do Artifact Registry.

  • Use outros serviços para criar e executar jobs:

A seguir