Workers secundários do Dataproc

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

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: por padrão, 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.

  Em vez de usar o tipo de máquina de worker principal padrão para workers secundários, você pode especificar uma ou mais listas classificadas de tipos de máquina para workers secundários. Consulte VMs flexíveis do Dataproc para mais informações.

• 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 flag mesmo que o cluster ter workers secundários quando forem criados.

• 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á três tipos de workers secundários: VMs spot, VMs preemptivas padrão e VMs não preemptivas. Se você especificar workers secundários para seu cluster, eles precisam ser do mesmo tipo. O tipo de worker secundário padrão do Dataproc é a VM preemptiva padrão.

Exemplo: se você selecionar três workers secundários ao criar um cluster, é possível especificar que os três serão VMs spot ou todos os três (padrão) preemptivas, ou todas as três serão VMs não preemptivas, mas não é possível especificar que cada uma será de um tipo diferente.

Uma VM spot é o tipo mais recente de VM do Compute Engine VM preemptiva. Ela compartilha o modelo de preços de custo mais baixo das VMs preemptivas padrão, mas, ao contrário da VM preemptiva padrão com uma vida útil máxima de 24 horas, a VM spot não tem vida útil máxima. Workers de VM preemptiva padrão e spot são recuperados e removidos de um cluster do Dataproc exigidos pelo Google Cloud para outras tarefas.

Workers preemptivos

Observação: quando o termo "preemptiva" é usado nas seções a seguir para se referir ao uma VM, worker ou nó, ela se refere aos atributos preemptivos e de VM preemptiva spot, a menos que ela seja usada para se referir expressamente a a instância "preemptiva padrão" Apenas tipo de VM.

• Embora a possível remoção de workers preemptivos possa afetar a estabilidade do job, convém usar instâncias preemptivas para reduzir os custos de computação por hora para processamento de dados não críticos ou para criar clusters muito grandes com um custo total menor. Use a Calculadora de preços do Google Cloud para estimar os 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 secundários) no 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.

  Considere usar Aprimorado Modo de flexibilidade: se você estiver usando VMs preemptivas com o Spark.

• Uma consideração de economia de custos: usar VMs preemptivas nem sempre economizam porque as preempções podem causar uma execução mais longa do job, com resultados custos de job maiores. Embora o uso do modo de flexibilidade aprimorada (EFM, na sigla em inglês) com VMs preemptivas possa ajudar a reduzir esse resultado, a economia geral de custos de VMs preemptivas vai variar de acordo com cada caso de uso. Geralmente, os jobs de curta duração são mais adequados para o uso de VMs preemptivas, já que a probabilidade de preemptões durante a execução do job será menor. Tente diferentes opções de job, como nenhuma VM preemptiva e VMs preemptivas com EFM, para estimar custos e chegar à melhor solução.

Workers não preemptivos

• É possível criar um cluster com workers secundários não preemptivos para escalonar a computação sem sacrificar a estabilidade do job. Para fazer isso, especifique "não preemptivo" como o tipo de worker secundário.

Como usar workers secundários

Você pode especificar o número e o tipo de workers secundários ao criar um cluster usando o console do Google Cloud, a gcloud CLI ou a API Dataproc.

• Os workers secundários precisam ser do mesmo tipo.
• É 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. Atualizações de marcadores não sejam propagadas para os workers secundários atuais não preemptivos. 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.

Se você planeja adicionar workers secundários ao de um cluster mais tarde. É possível especificar 0 workers secundários (exemplo de sinalização de comando gcloud: --num-secondary-workers=0) ao criar o cluster. Em seguida, atualize o cluster para especificar um número positivo e o tipo de workers secundários. Se você planeja atualizar o cluster mais tarde para incluir workers secundários, especifique "secondary-worker-type" ao criar o cluster.

Console

Você pode especificar o número de workers secundários ao criar um Dataproc no console do Google 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 Google Cloud.

Como criar um cluster com workers secundários

É possível definir o número e o tipo de workers secundários que serão aplicados a um novo cluster na seção "Nós de trabalho secundários" da página "Configurar nós" do Dataproc Criar um cluster do console do Google Cloud. Especifique o número e o tipo de conta secundária workers nos campos "Nós de trabalho secundários" e "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 Google 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

Atualize o cluster para remover todos os workers secundários conforme explicado anteriormente, especificar 0 no "Nós de trabalho secundários".

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, é possível adicionar ou remover workers secundários do ou cluster com o gcloud dataproc clusters update (é possível atualizar o número, mas não o tipo dos workers secundários).

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 VMs preemptivas padrão por padrão. É possível especificar workers secundários não preemptivos ao criar um cluster definindo --secondary-worker-type=non-preemptible. A propriedade dataproc:secondary-workers.is-preemptible.override não é mais usada para especificar o tipo do worker secundário.

Exemplo 1

O comando a seguir cria o "cluster1" com dois workers secundários preemptivos padrão (tipo padrão).

gcloud dataproc clusters create cluster1 \
    --num-secondary-workers=2 \
    --region=us-central1

Exemplo 2

O comando a seguir usa a flag secondary-worker-type para criar "cluster2" com dois workers secundários spot (preemptivos).

gcloud dataproc clusters create cluster2 \
    --num-secondary-workers=2 \
    --secondary-worker-type=spot \
    --region=us-central1

Exemplo 3:

O comando a seguir usa a flag secondary-worker-type para criar "cluster3" com dois workers secundários não preemptivos.

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

Para alterar o tamanho do disco de inicialização do worker secundário: Por padrão, todos os workers secundários são criados com o menor 100 GB ou 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. É possível substituir o tamanho padrão do disco com o comando gcloud dataproc clusters create --secondary-worker-boot-disk-size na criação do cluster. Essa flag pode ser especificada mesmo que o cluster não tenha workers secundários no momento da criação.

Deixe o console do Google Cloud construir sua solicitação de criação de cluster. Clique nos links de REST equivalente ou linha de comando na parte de baixo do painel esquerdo da página Criar um cluster do Dataproc para que o console do Google Cloud construa uma solicitação REST de API equivalente ou um comando da ferramenta gcloud.

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 "example-cluster" para usar quatro workers secundários (do tipo padrão ou especificado quando você criou o cluster).

gcloud dataproc clusters update example-cluster \
    --num-secondary-workers=4 \
    --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 "example-cluster".

gcloud dataproc clusters update example-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 workers secundários são padrão preemptiva ou VMs por padrão.

Exemplo 1

A solicitação POST a seguir cria um "cluster1" com dois workers de VM preemptivos padrão (tipo padrão).

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

{
  "clusterName": "cluster1",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2
    }
  }
}

Exemplo 2

A solicitação POST a seguir cria um "cluster2" com dois workers de VM Spot (preemptivos).

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

{
  "clusterName": "cluster2",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2,
      "preemptibility": "SPOT"
    }
  }
}

Exemplo 3:

A seguinte solicitação POST cria "cluster3" com dois workers secundários não preemptivos.

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

{
  "clusterName": "cluster3",
  "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 solicitação PATCH a seguir atualiza um cluster para ter quatro workers secundários (do tipo padrão ou especificado quando você criou o cluster).

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

Deixe o console do Google Cloud construir sua solicitação de criação de cluster. Você pode clicar nos links REST ou linha de comando equivalente na parte de baixo do painel esquerdo do Dataproc Criar um cluster para ter o console do Google Cloud criar uma solicitação de API REST equivalente ou uma ferramenta gcloud comando.

Solução de problemas de workers secundários

• Problemas de permissão da conta de serviço: os workers secundários são criados em um grupo gerenciado de instâncias. Se houver um problema de permissão, os registros do Dataproc não vão informar a falha na criação de workers secundários, mas os workers com falha vão ser listados na guia Instâncias de VM da página Detalhes do cluster no console do Google Cloud sem uma marca de seleção verde. Para conferir a listagem, 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 de instâncias gerenciadas:para verificar se há um problema com permissões de grupo gerenciado de instâncias:

  1. Encontre o nome do grupo de instâncias gerenciadas (instanceGroupManagerName).

     Console

     1. Abra os Clusters do Dataproc e clique no nome do cluster para abrir a página Detalhes do cluster para o cluster.
     2. Clique em REST equivalente na parte de baixo da página e confira o valor de config.secondaryWorkerConfig.managedGroupConfig.instanceGroupManagerName.

     Google Cloud CLI

     Execute o gcloud dataproc clusters describe. com a sinalização --format para exibir o instanceGroupManagerName.

     gcloud dataproc clusters describe CLUSTER_NAME \
         --region=REGION \
         --format='value(config.secondaryWorkerConfig.managedGroupConfig.instanceGroupManagerName)'
     

     API REST

     Envie uma solicitação clusters.get para retornar o valor de config.secondaryWorkerConfig.managedGroupConfig.instanceGroupManagerName.
  2. Confira os registros na Análise de registros.

  • Selecione o tipo de recurso Google Compute Engine Instance Group e filtre pelo nome do grupo de instâncias gerenciadas.

  • Como alternativa, é possível aplicar um filtro de geração de registros para `resource.type="gce_instance_group" e resource.labels.instance_group_name=INSTANCE_GROUP_MANAGER_NAME.