Paragem agendada do cluster

Para evitar incorrer em Google Cloud custos por um cluster inativo ou a necessidade de eliminar e recriar um cluster para evitar incorrer em custos do cluster, use a funcionalidade de paragem programada do cluster do Dataproc, que para todas as VMs do cluster. Não lhe é cobrado nenhum valor pelas VMs paradas, mas a cobrança dos recursos associados, como os discos persistentes, continua.

A paragem de um cluster para todas as VMs do cluster e faz com que todas as tarefas em execução falhem. Quando um cluster é parado, não pode atualizar o cluster, enviar tarefas para o cluster nem aceder a componentes opcionais no cluster através do gateway de componentes do Dataproc. Depois de parar um cluster, pode reiniciar o cluster e retomar o trabalho.

A paragem agendada de clusters está disponível para clusters criados com as versões 2.2.42+, 2.1.76+ e 2.0.57+ e versões de imagem posteriores.

Funcionalidades

  • Pode parar os clusters após um período de inatividade especificado, numa hora futura especificada ou após um período especificado a partir do pedido de criação do cluster.

  • A paragem agendada de clusters suporta clusters com trabalhadores secundários e clusters de escala zero.

  • Pode atualizar ou cancelar a configuração de paragem agendada do cluster.

Limitações e considerações

  • A paragem programada de clusters não é suportada para clusters com SSDs locais.
  • Não pode definir valores de paragem agendada de clusters através da Google Cloud consola.
  • Embora possa atualizar uma configuração de paragem agendada de um cluster, uma operação de paragem iniciada continua. Para verificar se a operação de paragem foi iniciada, examine os registos do cluster no Cloud Logging.
  • A atualização de uma agenda de paragem num cluster que já passou a hora de paragem agendada remove a configuração de paragem agendada. Para reativar a paragem agendada, inclua uma hora futura no seu pedido de atualização.

Ações que desativam a paragem agendada do cluster

Enquanto um cluster estiver em execução, as seguintes ações desativam a paragem agendada do cluster até que a ação de desativação seja revertida:

Cálculo do tempo de inatividade do cluster

Para que um cluster seja considerado inativo, têm de ser cumpridas as seguintes condições:

  • A criação do cluster está concluída (o tempo necessário para o aprovisionamento e o arranque do cluster é excluído do cálculo do tempo de inatividade)
  • não existem tarefas em execução no cluster
  • O cluster não está num estado STOPPED

O envio de um trabalho para o cluster ou a paragem de um cluster repõe o cálculo do tempo de inatividade.

A dataproc:dataproc.cluster-ttl.consider-yarn-activity propriedade do cluster afeta o cálculo do tempo de inatividade do cluster da seguinte forma:

  • Esta propriedade está ativada (definida como true) por predefinição.
  • Quando esta propriedade está ativada, a atividade da API YARN e Dataproc Jobs tem de estar inativa para iniciar e continuar a aumentar o cálculo do tempo de inatividade do cluster.
    • A atividade do YARN inclui aplicações do YARN pendentes e em execução.
    • A atividade da API Dataproc Jobs inclui tarefas pendentes e em execução enviadas para a API Dataproc Jobs.
  • Quando esta propriedade está definida como false, o cálculo do tempo de inatividade do cluster começa e continua apenas quando a atividade da API Dataproc Jobs está inativa.

Use a paragem programada do cluster

CLI gcloud

Pode definir valores de paragem agendados quando cria um cluster através da CLI do Google Cloud ou da API Dataproc. Depois de criar o cluster, pode atualizá-lo para alterar ou eliminar os valores de paragem agendada do cluster definidos anteriormente no cluster.

Bandeira Descrição Nível de detalhe mais preciso Valor mínimo Valor máximo
--stop-max-idle1 Aplica-se aos comandos de criação e atualização de clusters. A duração desde o momento em que o cluster entra no estado inativo (após a criação ou o arranque) até ao momento em que o cluster começa a parar. Indique a duração no formato IntegerUnit, em que a unidade pode ser "s, m, h, d" (segundos, minutos, horas e dias, respetivamente). Exemplos: "30m" ou "1d" (30 minutos ou 1 dia a partir do momento em que o cluster fica inativo). 1 segundo 5 minutos 14 dias
--no-stop-max-idle Aplica-se apenas ao comando de atualização do cluster. Cancela a paragem agendada do cluster através da flag --stop-max-idle definida anteriormente Não aplicável Não aplicável Não aplicável
--stop-expiration-time2 Aplica-se aos comandos de criação e atualização de clusters. A hora de início da paragem do cluster no formato de data/hora ISO 8601. Pode gerar a data/hora no formato correto através do gerador de data/hora. Por exemplo, "2017-08-22T13:31:48-08:00" especifica uma hora de validade de 13:21:48 no fuso horário UTC -8:00.1 segundo10 minutos a partir de agora 14 dias a partir da hora atual
--stop-max-age2 Aplica-se aos comandos de criação e atualização de clusters. A duração desde o momento do envio do pedido de criação do cluster até ao momento em que o cluster começa a parar. Indique a duração no formato IntegerUnit, em que a unidade pode ser "s, m, h, d" (segundos, minutos, horas, dias). Exemplos: "30m": 30 minutos a partir de agora; "1d": 1 dia a partir de agora. 1 segundo 10 minutos 14 dias
Notas:
  1. Pode transmitir a flag stop-max-idle com a flag stop-expiration-time ou stop-max-age no seu pedido de criação ou atualização do cluster. A primeira condição a tornar-se verdadeira entra em vigor para parar o cluster.
  2. Pode transmitir o indicador stop-expiration-time ou o indicador stop-max-age para o comando de criação ou atualização do cluster, mas não ambos.

Exemplo de criação de cluster:

gcloud dataproc clusters create CLUSTER_NAME \
    --region=REGION \
    --stop-max-idle=DURATION \
    --stop-expiration-time=TIME \
    ... other flags ...

Exemplo de atualização de cluster:

Por exemplo:

gcloud dataproc clusters update CLUSTER_NAME \
    --region=REGION \
    --stop-max-idle=DURATION \
    --no-stop-max-age \
    ... other flags

API REST

Pode criar ou atualizar valores de paragem agendada num cluster definindo os campos e os valores da ClusterLifecycleConfig da API Dataproc, indicados na tabela seguinte, como parte de um pedido da API cluster.create ou cluster.patch do Dataproc.

Bandeira Descrição Nível de detalhe mais preciso Valor mínimo Valor máximo
idleStopTtl1 Aplica-se aos comandos de criação e atualização de clusters. A duração desde o momento em que o cluster entra no estado inativo após a criação ou a atualização do cluster até ao momento em que o cluster começa a parar. Indique uma duração em segundos com até nove dígitos fracionários, terminada por "s". Exemplo: "3,5s". Envie um pedido cluster.patch com uma duração vazia para cancelar um valor idleDeleteTtl definido anteriormente. 1 segundo 5 minutos
 14 dias
autoStopTime2 Aplica-se aos comandos de criação e atualização de clusters. A hora de começar a parar o cluster. Indique uma data/hora no formato RFC 3339 UTC "Zulu", com precisão de nanossegundos. Exemplo: "2014-10-02T15:01:23.045123456Z". 1 segundo 10 minutos a partir da hora atual 14 dias a partir da hora atual
autoStopTtl2 A duração desde o momento do envio do pedido de criação ou atualização do cluster até ao momento em que o cluster começa a parar. Indique uma duração em segundos com até nove dígitos fracionários, terminada por "s". Exemplo: "3,5s". 1 segundo 10 minutos.
Envie um pedido com uma duração vazia para cancelar um valor autoStopTtl definido anteriormente.cluster.patch		 14 dias
Notas:
  1. Pode transmitir a flag stop-max-idle com a flag stop-expiration-time ou stop-max-age no seu pedido de criação ou atualização do cluster. A primeira condição a tornar-se verdadeira entra em vigor para parar o cluster.
  2. Pode transmitir o indicador stop-expiration-time ou o indicador stop-max-age para o comando de criação ou atualização do cluster, mas não ambos.

Usar a paragem agendada com a eliminação agendada

Se usar a paragem programada de clusters com a eliminação programada de clusters, ao criar ou atualizar um cluster, tenha em atenção as seguintes restrições:

  • O período de stop-max-idle tem de ser inferior ou igual ao período de delete-max-idle ou ao período resultante de delete-max-age ou delete-expiration-time.

  • Os valores stop-max-age e stop-expiration-time têm de ser posteriores a delete-max-age e delete-expiration-time, respetivamente.

Veja as definições do cluster de paragens agendadas

CLI gcloud

Pode usar o comando gcloud dataproc clusters list para confirmar que um cluster tem a paragem agendada ativada.

 gcloud dataproc clusters list \
     --region=REGION

Exemplo de saída:

...
NAME         WORKER_COUNT ... SCHEDULED_STOP
CLUSTER_ID   NUMBER       ... enabled
...

Pode usar o comando gcloud dataproc clusters describe para verificar as definições de paragem agendada do LifecycleConfig. 

gcloud dataproc clusters describe CLUSTER_NAME \
    --region=REGION

Exemplo de saída:

...
lifecycleConfig:
  autoStopTime: '2018-11-28T19:33:48.146Z'
  idleStopTtl: 1800s
  idleStartTime: '2018-11-28T18:33:48.146Z'
...

Os valores autoStopTime e idleStopTtl são definidos pelo utilizador. O Dataproc gera o valor idleStartTime, que é a hora de início de inatividade do cluster mais recente.

Embora o Dataproc calcule o idleStartTime com base na cessação da atividade da tarefa, o mecanismo para a paragem agendada do cluster considera o idleStartTime e a última hora de início do cluster. Especificamente, se um cluster for parado por um utilizador ou pelo Dataproc, o cálculo de inatividade para a funcionalidade de paragem agendada é reposto. Isto significa que a contagem decrescente para uma paragem agendada é reiniciada no próximo início do cluster. No entanto, o idleStartTime não é reposto quando um cluster parado é reiniciado. Continua a refletir a última ocorrência de inatividade da tarefa antes da paragem.

Por conseguinte, têm de ser cumpridas duas condições para que o Dataproc pare um cluster com base no idleStopTtl:

  1. O cluster tem de ter estado inativo durante o período especificado por idleStopTtl desde que foi iniciado pela última vez.
  2. O cluster tem de estar inativo durante o período especificado por idleStopTtl desde a última reposição de idleStartTime.

API REST

Pode fazer um clusters.list pedido para confirmar se um cluster tem a paragem agendada ativada.