Workers secundários: VMs preemptivas e não preemptivas

Além de usar as VMs padrão do Compute Engine como workers do Dataproc (chamados de workers "principais"), os clusters do Dataproc podem usar workers "secundários".

As seguintes características se aplicam a todos os workers secundários em um cluster do Dataproc:

  • Somente processamento: workers secundários não armazenam dados. Elas só funcionam como nós de processamento. Portanto, você pode usar workers secundários para escalonar a computação sem escalonar o armazenamento.

  • Nenhum cluster secondary-worker-only: o cluster precisa ter workers principais. Se você criar um cluster e não especificar o número de workers principais, o Dataproc adicionará dois workers principais ao cluster.

  • Tipo de máquina: os workers secundários usam o tipo de máquina dos workers principais do cluster. Por exemplo, se você criar um cluster com workers principais que usam tipos de máquina n1-standard-4, todos os workers secundários adicionados ao cluster também usarão máquinas n1-standard-4.

  • Tamanho do disco permanente: como padrão, os workers secundários são criados com menos de 100 GB ou com o tamanho do disco de inicialização do worker principal. Esse espaço em disco é usado para armazenamento em cache local de dados e não está disponível por meio do HDFS. Você pode substituir o tamanho padrão do disco com o comando gcloud dataproc clusters create --secondary-worker-boot-disk-size na criação do cluster. É possível especificar essa sinalização mesmo que o cluster não tenha workers secundários no momento da criação.

  • Criação assíncrona: quando você adiciona workers secundários criando ou escalonando um cluster, eles podem não ser provisionados no momento em que a operação de criação ou atualização é concluída. Isso ocorre porque o Dataproc gerencia workers secundários usando grupos de instâncias gerenciadas (MIGs, na sigla em inglês), que criam VMs de forma assíncrona assim que podem ser provisionadas (consulte Como verificar o status de instâncias gerenciadas ).

Workers secundários preemptivos e não preemptivos

Há dois tipos de workers secundários: preemptivos e não preemptivos. Todos os workers secundários no cluster precisam ser do mesmo tipo, preemptivos ou não preemptivos. O padrão é preemptivo.

  • Workers secundários preemptivos: os workers preemptivos são o tipo de worker secundário padrão. Eles são recuperados e removidos do cluster se forem exigidos pelo Google Cloud para outras tarefas. A possível remoção de workers preemptivos pode afetar a estabilidade do job, mas você pode optar por usar instâncias preemptivas para reduzir os custos de computação por hora para processamento de dados não críticos ou criar clusters muito grandes com um menor custo total. Use a calculadora de preços do Google Cloud para fazer uma estimativa dos custos.

    • Para ter melhores resultados, o número de workers preemptivos no cluster precisa ser menor que 50% do número total de todos os workers (principais e todos os secundários) do cluster.

    • Ao usar workers preemptivos, os jobs provavelmente apresentarão um número maior de falhas transitórias de tarefas de workers únicos em comparação a jobs executados em workers não preemptivos. Para aumentar a tolerância do job a falhas de tarefas de nível inferior, defina valores de propriedade de cluster semelhantes aos valores de propriedade padrão usados com clusters de escalonamento automático para aumentar o número máximo de novas tentativas das tarefas e evitar falhas de jobs.

  • Workers secundários não preemptivos: crie um cluster com workers secundários não preemptivos para escalonar a computação sem sacrificar a estabilidade do job. Especifique "não preemptivo" como o tipo de worker secundário ("preemptivo" é o padrão).

Como usar workers secundários

Especifique o número e o tipo de workers secundários (preemptivos ou não preemptivos) ao criar um cluster por meio de uma solicitação da API Dataproc usando a ferramenta de linha de comando gcloud do SDK do Cloud ou do Console do Google Cloud.

  • Um cluster pode conter workers secundários preemptivos ou não preemptivos, mas não ambos.
  • É possível atualizar seu cluster depois que ele é criado para alterar o número, mas não o tipo, de workers secundários no cluster.
  • As atualizações de rótulos são propagadas para todos os workers secundários preemptivos em 24 horas. Atualmente, as atualizações de rótulo não se propagam para workers secundários não preemptivos atuais. As atualizações de rótulo se propagam para todos os workers adicionados a um cluster após uma atualização de rótulo. Por exemplo, se você escalonar o cluster, todos os novos workers principais e secundários terão os novos rótulos.

Comando gcloud

Use o comando gcloud dataproc clusters create para adicionar workers secundários a um cluster quando ele for criado. Após a criação de um cluster, você pode adicionar ou remover workers secundários de ou para o cluster com o comando gcloud dataproc clusters update (o número, mas não o tipo de workers secundários, pode ser atualizado).

Como criar um cluster com workers secundários

Para criar um cluster com workers secundários, use o comando gcloud dataproc clusters create com o argumento --num-secondary-workers. Os workers secundários são preemptivos por padrão, mas é possível adicionar workers secundários não preemptivos ao criar um cluster definindo --secondary-worker-type=non-preemptible (consulte o Exemplo 2).

Exemplo 1

O comando a seguir cria um cluster chamado "my-test-cluster" com dois workers preemptivos.

gcloud dataproc clusters create my-test-cluster \
    --num-secondary-workers=2 \
    --region=us-central1

Exemplo 2

O comando a seguir usa a sinalização secondary-worker-type para criar um cluster "my-test-cluster" com dois workers secundários não preemptivos.

gcloud dataproc clusters create my-test-cluster \
    --num-secondary-workers=2 \
    --secondary-worker-type=non-preemptible \
    --region=us-central1

Como atualizar um cluster com workers secundários

Para atualizar um cluster e adicionar ou remover workers secundários, use o comando gcloud dataproc clusters update com o argumento --num-secondary-workers.

Exemplo

O comando a seguir atualiza um cluster chamado "my-test-cluster" para usar dois workers secundários.

gcloud dataproc clusters update my-test-cluster \
    --num-secondary-workers=2 \
    --region=us-central1

Como remover todos os workers secundários de um cluster

Para remover todos os workers secundários de um cluster, use o comando gcloud dataproc clusters update com --num-secondary-workers definido como 0.

Exemplo

O comando a seguir remove todos os workers secundários de um cluster.

gcloud dataproc clusters update my-test-cluster \
    --num-secondary-workers=0 \
    --region=us-central1

API REST

Como criar um cluster com workers secundários

Use a API clusters.create do Dataproc para adicionar workers secundários a um cluster quando ele for criado. Observe que os workers secundários são preemptivos por padrão, mas é possível adicionar workers secundários não preemptivos aos clusters, conforme mostrado no Exemplo 2.

Exemplo 1

A solicitação POST a seguir cria um cluster com dois workers preemptivos.


POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster-name",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2
    }
  }
}

Exemplo 2

A solicitação POST a seguir cria um cluster com dois workers secundários não preemptivos.


POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster-name",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2,
      "preemptibility": "NON_PREEMPTIBLE"
    }
  }
}

Como atualizar um cluster com workers secundários

Use a API clusters.patch do Dataproc para adicionar e remover workers secundários.

Exemplo

A seguinte solicitação PATCH atualiza um cluster para ter dois workers secundários.


PATCH /v1/projects/project-id/regions/region/clusters/cluster-name?updateMask=config.secondary_worker_config.num_instances
{
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2
    }
  }
}

Console

Você pode especificar o número de workers secundários ao criar um cluster do Dataproc no Console do Cloud. Após a criação de um cluster, você pode adicionar e remover workers secundários editando a configuração do cluster no Console do Cloud.

Como criar um cluster com workers secundários

Defina o número e o tipo de workers secundários a serem aplicados a um novo cluster na seção "Nós de workers secundários" do painel "Configurar nós" na página Criar um cluster do Dataproc do Console do Cloud. Especifique o número e o tipo de workers secundários nos campos "Nós de workers secundários" e "Capacidade de preempção", respectivamente.

Como atualizar um cluster com instâncias secundárias

Para atualizar o número de workers secundários em um cluster, clique no nome do cluster na página Clusters do Console do Cloud. Na página Detalhes do cluster. Clique na guia "CONFIGURAÇÃO" e depois em "EDITAR" e atualize o número no campo "Nós de workers secundários".

Como remover todas as instâncias secundárias de um cluster

Para remover todos os workers secundários de um cluster, atualize a configuração do cluster conforme explicado acima, especificando 0 no campo "Nós de workers secundários".

Solução de problemas de workers secundários

Problemas de permissão da conta de serviço: para criar workers secundários, usamos um grupo gerenciado de instâncias e o Compute Engine usa a conta de serviço do agente de serviço das APIs do Google do seu projeto para executar operações do grupo gerenciado de instâncias. Esse nome de conta de serviço é formatado da seguinte maneira: project-id@cloudservices.gserviceaccount.com.

Quando há um problema de permissão nessa conta de serviço, os registros do Dataproc não informam a falha na criação de workers secundários, mas os workers com falha são listados na guia INSTÂNCIAS DE VM, na página Detalhes do cluster, no Console do Google Cloud, sem a marca de seleção verde. Abra a página Clusters do Dataproc e clique no nome do cluster para abrir a página Detalhes do cluster.

  • Problemas de permissões do grupo gerenciado de instâncias: para verificar se há um problema com as permissões do grupo gerenciado de instâncias, veja os registros no Explorador de registros para o tipo de recurso do "Google Compute Engine Instance Group" e filtre o ID do grupo de instâncias correspondente. O filtro de ID do grupo de instâncias exibe o nome do grupo no formato dataproc-CLUSTER NAME-sw e o ID do grupo é preenchido automaticamente na consulta de geração de registros. Em vez de usar os filtros suspensos, é possível aplicar um filtro de geração de registros para resource.type="gce_instance_group" e resource.labels.instance_group_name="dataproc-CLUSTER NAME-sw".

  • Problemas de permissão de imagem personalizada: quando as VMs do cluster do Dataproc são criadas com imagens personalizadas, recuperadas de outro projeto, é preciso atribuir o papel Compute Image User à conta de serviço project-id@cloudservices.gserviceaccount.com do projeto. Veja Conceder acesso às imagens a um grupo gerenciado de instâncias. Quando o papel correto não é atribuído, esta mensagem de erro é exibida nos registros: Required 'compute.images.useReadOnly' permission for 'projects/[IMAGE PROJECT]/global/images/[IMAGE NAME]