Neste documento, explicamos como criar jobs que são executados em recursos reservados e como impedir que os jobs consumam reservas.
As reservas são um recurso do Compute Engine. Uma reserva oferece um nível muito alto de garantia de capacidade para uma ou mais VMs com a configuração de hardware especificada. Uma reserva de VM gera os custos dessa VM desde o momento da criação até a exclusão da reserva. No entanto, enquanto você estiver consumindo essa VM, o custo total será equivalente a uma VM sem uma reserva.
Em geral, as reservas são úteis quando a disponibilidade de capacidade é extremamente importante ou para evitar erros na obtenção de recursos. Para o Batch especificamente, considere usar reservas dedicadas para ajudar a minimizar o tempo de programação de jobs ou tente usar reservas existentes enquanto elas não estão sendo usadas. Se você tiver reservas subutilizadas, como as necessárias para descontos por compromisso de uso, poderá configurar jobs para tentar consumi-las enquanto não estiverem sendo usadas e otimizar os custos incorridos. Se preferir priorizar a disponibilidade de recursos para outras cargas de trabalho no seu projeto, bloqueie explicitamente um job para que ele não consuma reservas.
Para saber mais sobre reservas, consulte a documentação do Compute Engine sobre reservas.
Antes de começar
- Se você nunca usou o Batch, leia Começar a usar o Batch e ative o serviço concluindo os pré-requisitos para projetos e usuários.
- Verifique se você tem permissões para criar uma reserva ou visualizar uma reserva atual que você quer que as VMs de um job consumam conforme necessário.
-
Para receber as permissões necessárias para criar um job, peça ao administrador para conceder a você os seguintes papéis do IAM:
-
Editor de jobs em lote (
roles/batch.jobsEditor
) no projeto -
Usuário da conta de serviço (
roles/iam.serviceAccountUser
) na conta de serviço do job, que por padrão é a conta de serviço padrão do Compute Engine
Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.
Também é possível conseguir as permissões necessárias por meio de papéis personalizados ou de outros papéis predefinidos.
-
Editor de jobs em lote (
Restrições
Além das restrições gerais para reservas, o Batch também tem as seguintes restrições:
- As VMs de um job não podem consumir reservas compartilhadas.
- As VMs de um job não podem consumir reservas se uma delas especificar uma política de posicionamento compacto.
- Se você criar um job usando o console do Google Cloud , as VMs dele vão consumir automaticamente as reservas correspondentes. Para consumir uma reserva específica ou impedir que
VMs consumam reservas, defina o campo
reservation
ao criar um job usando a CLI gcloud ou a API Batch.
Requisitos
Esta seção resume os requisitos para que as VMs de um job consumam uma reserva. Para mais informações sobre todos os requisitos, consulte os requisitos gerais para reservas na documentação do Compute Engine e o procedimento para planejar sua configuração mais adiante neste documento.
Para que as VMs de um job sejam geralmente capazes de consumir uma reserva, todas as condições a seguir precisam ser atendidas:
O job e a reserva precisam especificar propriedades de VM que correspondam exatamente.
Você precisa obedecer a todas as restrições neste documento e a todos os outros requisitos gerais para reservas.
Para que cada VM de um job consuma uma reserva, ela precisa ter capacidade não utilizada disponível durante o tempo de execução da VM.
A capacidade não utilizada de uma reserva é a diferença entre a contagem de VMs e o número de VMs que a consomem atualmente. As VMs tentam consumir reservas sempre que você tem capacidade de reserva não utilizada. Assim, uma VM pode começar a consumir uma reserva quando é criada ou mais tarde durante o tempo de execução. Uma VM não para de consumir uma reserva até que a VM pare de ser executada ou a reserva seja excluída.
Dependendo da capacidade total não utilizada da reserva, nenhuma, algumas ou todas as VMs de um job podem consumir reservas, e a quantidade de VMs reservadas pode variar durante o tempo de execução do job.
Criar e executar um job que pode consumir VMs reservadas
Planeje sua configuração. Para garantir que seu job e sua reserva sejam compatíveis, siga estas etapas.
Se você quiser consumir uma reserva que já existe, crie um job com uma configuração correspondente. Caso contrário, se você planeja criar uma nova reserva, selecione as opções de configuração que preferir.
Determine as propriedades da reserva. Devido às restrições, o tipo de compartilhamento precisa ser projeto único, que é a opção padrão para uma reserva. Determine os valores que você quer usar para as seguintes propriedades de reserva:
- Tipo de consumo*
- Contagem de VMs†
*O tipo de consumo da reserva (segmentada especificamente ou consumida automaticamente) determina quais VMs podem consumir a reserva.
†A contagem de VMs representa a capacidade total de uma reserva. Ao decidir esse valor, considere o número de VMs do job.
Determine as propriedades da VM para o job e a reserva. Devido às restrições, nem o job nem a reserva podem especificar uma política de posicionamento compacto, que é a opção padrão para reservas e jobs. Determine os valores que você quer usar para as seguintes propriedades de VM, que precisam corresponder exatamente à reserva e ao trabalho:
- Projeto
- Zona*
- Tipo de máquina†
- Plataforma mínima de CPU† (se houver‡)
- Tipo e contagem de GPU† (se houver‡)
- Tipo e contagem de SSD local† (se houver‡)
- Afinidade de reserva†#
*As VMs de job precisam estar localizadas na mesma zona que as VMs reservadas. Inclua essa zona no campo
allowedLocations[]
do job ou, se omitir o campoallowedLocations[]
, defina o local do job como a região que contém essa zona.†O job precisa definir todas essas propriedades usando os subcampos
policy
ou um modelo de instância de VM. Um job não pode especificar uma combinação de subcampospolicy
e um modelo.‡ Um campo opcional não pode ser definido para um recurso e omitido do outro. Defina ou omita o campo opcional para a reserva e o job. Se o job especificar um modelo de instância de VM, isso também se aplicará aos campos do modelo especificado.
#O tipo de consumo da reserva determina a afinidade de reserva necessária para as VMs do job, que você precisa especificar no job da seguinte maneira:
- Se o job estiver usando um modelo de instância de VM, o modelo precisará configurar a afinidade de reserva conforme explicado na documentação de reservas.
- Se o job não estiver usando um modelo e a reserva for
especificamente segmentada, especifique o nome da reserva no campo
reservation
do job. - Caso contrário, se o job não estiver usando um modelo e a reserva for consumida automaticamente, omita o campo
reservation
do job.
Prepare a reserva. Se ainda não tiver feito isso, crie a reserva que você quer que as VMs do job consumam. Verifique se a reserva tem as propriedades planejadas.
Crie e execute o job. É possível criar e executar um job que consome VMs da reserva preparada usando a CLI gcloud ou a API Batch:
gcloud
Crie um arquivo JSON que especifique os detalhes de configuração do job e defina os subcampos do recurso de instância de VM (
instances[]
) para corresponder exatamente às propriedades de VM de uma reserva.Por exemplo, para criar um job de script básico que consome VMs de uma reserva, crie um arquivo JSON com o seguinte conteúdo:
{ "taskGroups": [ { "taskSpec": { "runnables": [ { "script": { "text": "echo Hello world from task ${BATCH_TASK_INDEX}" } } ] }, "taskCount": 3 } ], "allocationPolicy": { "instances": [ { VM_RESOURCES } ], }, "logsPolicy": { "destination": "CLOUD_LOGGING" } }
Substitua
VM_RESOURCES
pelos recursos de VM que correspondem à reserva que você quer que o job consuma especificando os subcamposinstances[]
planejados nas etapas anteriores.Por exemplo, comece com o seguinte valor para
VM_RESOURCES
:"installGpuDrivers": INSTALL_GPU_DRIVERS, "policy": { "machineType": "MACHINE_TYPE", "minCpuPlatform": "MIN_CPU_PLATFORM", "accelerators": [ { "type": "GPU_TYPE", "count": GPU_COUNT } ], "disks": [ { "newDisk": { "sizeGb": LOCAL_SSD_SIZE, "type": "local-ssd" }, "deviceName": "LOCAL_SSD_NAME" } ], "reservation": "SPECIFIC_RESERVATION_NAME" }
Para usar esse valor, faça todas as seguintes mudanças:
Quer usar um modelo de instância?
Sim:substitua o campo
policy
pelo campoinstanceTemplate
e especifique um modelo de instância de VM existente que corresponda à reserva. Por exemplo, consulte o exemplo de código para usar um modelo de instância de VM. Se a reserva usar GPUs ou SSDs locais, também será necessário configurar os camposinstallGpuDrivers
evolumes[]
do job, respectivamente. Caso contrário, pule as demais mudanças.Não:substitua
MACHINE_TYPE
pelo mesmo tipo de máquina da reserva.
A reserva inclui uma plataforma mínima de CPU?
Sim:substitua
MIN_CPU_PLATFORM
pela mesma plataforma mínima de CPU.Não:remova o campo
minCpuPlatform
.
A reserva inclui GPUs?
Sim:substitua
INSTALL_GPU_DRIVERS
,GPU_TYPE
eGPU_COUNT
para corresponder à reserva. Por exemplo, confira o exemplo de código para usar GPUs.Não:remova os campos
installGpuDrivers
eaccelerators[]
.
A reserva inclui SSDs locais?
Sim:substitua
LOCAL_SSD_SIZE
eLOCAL_SSD_NAME
para corresponder à reserva e monte os SSDs locais adicionando o campovolumes[]
ao job. Por exemplo, consulte o exemplo de código para usar SSDs locais.Não:remova o campo
disks[]
.
A reserva usa o tipo de consumo com segmentação específica?
Sim:substitua
SPECIFIC_RESERVATION_NAME
pelo nome da reserva.Não:remova o campo
reservation
.
Por exemplo, suponha que você esteja usando uma reserva consumida automaticamente para
n2-standard-32
VMs que não especifica nenhuma plataforma mínima de CPU, GPUs ou SSDs locais. Além disso, você não quer especificar um modelo de instância de VM. Nesse caso, substituaVM_RESOURCES
pelo seguinte valor:"policy": { "machineType": "n2-standard-32" }
Para criar e executar o job, use o comando
gcloud batch jobs submit
:gcloud batch jobs submit JOB_NAME \ --location LOCATION \ --config JSON_CONFIGURATION_FILE
Substitua:
JOB_NAME
: o nome do job.LOCATION
: o local do job. A menos que o job especifique o campoallowedLocations[]
, essa precisa ser a região que contém a zona da reserva.JSON_CONFIGURATION_FILE
: o caminho para um arquivo JSON com os detalhes de configuração do job.
API
Faça uma solicitação
POST
para o métodojobs.create
que define os subcampos do recurso de instância de VM (instances[]
) para corresponder exatamente às propriedades de VM de uma reserva.Por exemplo, para criar um job de script básico que consuma VMs de uma reserva, faça a seguinte solicitação:
POST https://batch.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/jobs?job_id=JOB_NAME { "taskGroups": [ { "taskSpec": { "runnables": [ { "script": { "text": "echo Hello world from task ${BATCH_TASK_INDEX}" } } ] }, "taskCount": 3 } ], "allocationPolicy": { "instances": [ { VM_RESOURCES } ], }, "logsPolicy": { "destination": "CLOUD_LOGGING" } }
Substitua:
PROJECT_ID
: o ID do projeto do seu projeto.LOCATION
: o local do job. A menos que o job especifique o campoallowedLocations[]
, essa precisa ser a região que contém a zona da reserva.JOB_NAME
: o nome do job.VM_RESOURCES
: os recursos de VM que correspondem à reserva que você quer que o job consuma especificando os subcamposinstances[]
planejados nas etapas anteriores.Por exemplo, comece com o seguinte valor para
VM_RESOURCES
:"installGpuDrivers": INSTALL_GPU_DRIVERS, "policy": { "machineType": "MACHINE_TYPE", "minCpuPlatform": "MIN_CPU_PLATFORM", "accelerators": [ { "type": "GPU_TYPE", "count": GPU_COUNT } ], "disks": [ { "newDisk": { "sizeGb": LOCAL_SSD_SIZE, "type": "local-ssd" }, "deviceName": "LOCAL_SSD_NAME" } ], "reservation": "SPECIFIC_RESERVATION_NAME" }
Para usar esse valor, faça todas as seguintes mudanças:
Quer usar um modelo de instância?
Sim:substitua o campo
policy
pelo campoinstanceTemplate
e especifique um modelo de instância de VM existente que corresponda à reserva. Por exemplo, consulte o exemplo de código para usar um modelo de instância de VM. Se a reserva usar GPUs ou SSDs locais, também será necessário configurar os camposinstallGpuDrivers
evolumes[]
do job, respectivamente. Caso contrário, pule as demais mudanças.Não:substitua
MACHINE_TYPE
pelo mesmo tipo de máquina da reserva.
A reserva inclui uma plataforma mínima de CPU?
Sim:substitua
MIN_CPU_PLATFORM
pela mesma plataforma mínima de CPU.Não:remova o campo
minCpuPlatform
.
A reserva inclui GPUs?
Sim:substitua
INSTALL_GPU_DRIVERS
,GPU_TYPE
eGPU_COUNT
para corresponder à reserva. Por exemplo, confira o exemplo de código para usar GPUs.Não:remova os campos
installGpuDrivers
eaccelerators[]
.
A reserva inclui SSDs locais?
Sim:substitua
LOCAL_SSD_SIZE
eLOCAL_SSD_NAME
para corresponder à reserva e monte os SSDs locais adicionando o campovolumes[]
ao job. Por exemplo, consulte o exemplo de código para usar SSDs locais.Não:remova o campo
disks[]
.
A reserva usa o tipo de consumo com segmentação específica?
Sim:substitua
SPECIFIC_RESERVATION_NAME
pelo nome da reserva.Não:remova o campo
reservation
.
Por exemplo, suponha que você esteja usando uma reserva consumida automaticamente para
n2-standard-32
VMs que não especifica nenhuma plataforma mínima de CPU, GPUs ou SSDs locais. Além disso, você não quer especificar um modelo de instância de VM. Nesse caso, substituaVM_RESOURCES
pelo seguinte valor:"policy": { "machineType": "n2-standard-32" }
Criar e executar um job que não pode consumir VMs reservadas
Para impedir que um job consuma reservas, defina o
camporeservation
como NO_RESERVATION
. Para mais informações sobre como evitar o consumo de reservas, consulte Impedir que instâncias de computação consumam reservas na documentação do Compute Engine.
É possível criar e executar um job que não pode consumir nenhuma VM reservada usando a CLI gcloud ou a API Batch.
gcloud
Crie um arquivo JSON que especifique os detalhes de configuração do job e defina o campo
reservation
comoNO_RESERVATION
.Por exemplo, para criar um trabalho de script básico que não pode consumir reservas, crie um arquivo JSON com o seguinte conteúdo:
{ "taskGroups": [ { "taskSpec": { "runnables": [ { "script": { "text": "echo Hello world from task ${BATCH_TASK_INDEX}" } } ] }, "taskCount": 3 } ], "allocationPolicy": { "instances": [ { "policy": { "reservation": "NO_RESERVATION" } } ], }, "logsPolicy": { "destination": "CLOUD_LOGGING" } }
Para criar e executar o job, use o comando
gcloud batch jobs submit
:gcloud batch jobs submit JOB_NAME \ --location LOCATION \ --config JSON_CONFIGURATION_FILE
Substitua:
JOB_NAME
: o nome do job.LOCATION
: o local do job.JSON_CONFIGURATION_FILE
: o caminho para um arquivo JSON com os detalhes de configuração do job.
API
Faça uma solicitação POST
ao
método jobs.create
que define o campo reservation
como NO_RESERVATION
.
Por exemplo, para criar um job de script básico que não pode consumir reservas, faça a seguinte solicitação:
POST https://batch.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/jobs?job_id=JOB_NAME
{
"taskGroups": [
{
"taskSpec": {
"runnables": [
{
"script": {
"text": "echo Hello world from task ${BATCH_TASK_INDEX}"
}
}
]
},
"taskCount": 3
}
],
"allocationPolicy": {
"instances": [
{
"policy": {
"reservation": "NO_RESERVATION"
}
}
],
},
"logsPolicy": {
"destination": "CLOUD_LOGGING"
}
}
Substitua:
PROJECT_ID
: o ID do projeto do seu projeto.LOCATION
: o local do job.JOB_NAME
: o nome do job.
A seguir
- Se você tiver problemas para criar ou executar um job, consulte Solução de problemas.
- Ver jobs e tarefas.
- Saiba mais sobre outras opções de criação de jobs.