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 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 primário padrão para workers secundários, é possível 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. É possível substituir o tamanho padrão do disco pela gcloud dataproc clusters create --secondary-worker-boot-disk-size na criação do cluster. É possível especificar essa flag 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á 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 Dataproc padrão o tipo de worker secundário é a VM preemptiva padrão.

Exemplo: se você selecionar três workers secundários ao criar um cluster, poderá especificar que todos serão VMs do Spot ou VMs preemptivas (padrão) ou não preemptivas, mas não é possível especificar que cada um 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 "preemptivo" é usado nas seções a seguir para se referir a uma VM, worker ou nó, ele se refere aos tipos de VM preemptivos padrão e do Spot, a menos que seja usado para se referir expressamente ao tipo de VM "preemptivo padrão".

• A remoção de workers preemptivos pode afetar a estabilidade do job, use 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 Custo total (use a calculadora de preços do Google Cloud para estimar os custos).

• Para melhores resultados, o número de workers preemptivos no cluster deve ser inferior a 50% do número total de todos os workers (primários mais todos os workers 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. Aumentar a tolerância do trabalho a níveis baixos falha em tarefas, é possível definir 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 da tarefa e ajudar a evitar o job de segurança.

  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 esteja usando o Modo de flexibilidade aprimorado (EFM) com VMs preemptivas podem ajudar a mitigar esse resultado, a economia geral de as VMs preemptivas variam de acordo com o caso de uso. Em geral, empregos de curta duração adequado para uso em VM preemptiva, já que a probabilidade de preempções durante o job e menor tempo de execução. 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 computação em nuvem sem sacrificar a estabilidade do job. Para fazer isso, especifique "non-preemptible" como o tipo de worker secundário.

Como usar workers secundários

É possível especificar o número e o tipo de workers secundários ao criar um cluster usando o console do Google Cloud, CLI gcloud 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 seu cluster e, em seguida, atualizá-lo mais tarde para especificar um número positivo e tipo de workers secundários. Se você planeja atualizar o cluster mais tarde para incluir workers secundários, é preciso especificar com o tipo de worker secundário, quando você cria 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, é possível adicionar e remover workers secundários editando a configuração do cluster 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 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 Campo "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 gcloud dataproc clusters create com o argumento --num-secondary-workers. Observe que workers secundários são VMs preemptivas 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 usado para especificar o tipo do worker secundário).

Exemplo 1

O comando a seguir cria "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 o secondary-worker-type flag 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 sinalização pode ser especificada mesmo que o cluster não ter workers secundários no momento da criação.

Deixe o console do Google Cloud construir seu solicitação de criação do 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 seguinte solicitação POST 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 seguinte solicitação POST cria um "cluster2" com dois os workers da VM spot (preemptivas).

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 ou tipo padrão 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 seu 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: 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: [e-mail].

Se houver um problema de permissão com essa conta de serviço, o Dataproc registros não informarão a falha na criação de workers secundários, mas os workers com falha estarão 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 (abra o Dataproc página Clusters e, em seguida, clique no 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 vai mostrar nome do grupo de instâncias no formato dataproc-CLUSTER NAME-sw e o ID do grupo de instâncias será 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 [e-mail] 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]