Além de usar VMs padrão do Compute Engine como workers do Dataproc (chamados de workers "principais"), os clusters do Dataproc podem usar workers secondary.
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áquinasn1-standard-4.Em vez de usar o tipo de máquina de worker principal 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 modificar o tamanho padrão do disco com o comando
gcloud dataproc clusters create --secondary-worker-boot-disk-sizena criação do cluster. É possível especificar essa sinalização mesmo que o cluster não tenha workers secundários quando for criado.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 o cluster, eles precisarão ser do mesmo tipo. O tipo de worker secundário padrão do Dataproc é a VM preemptiva padrão.
Por exemplo, se você selecionar três workers secundários ao criar um cluster, pode especificar que os três serão VMs spot ou todos os três serão VMs preemptivas (padrão) ou todos os três serão VMs 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 preemptiva do Compute Engine. Ela compartilha o modelo de preços de menor custo das VMs preemptivas padrão, mas, diferentemente da VM preemptiva padrão com ciclo de vida máximo de 24 horas, a VM spot não tem um ciclo de vida máximo. Os workers de VM preemptiva padrão e spot serão recuperados e removidos de um cluster do Dataproc se forem exigidos pelo Google Cloud para outras tarefas.
Workers preemptivos
Embora a possível remoção de workers preemptivos afete a estabilidade do job, é possível usar instâncias preemptivas para reduzir os custos de computação por hora no processamento de dados não críticos ou criar clusters muito grandes a um custo total menor. É possível usar a calculadora de preços do Google Cloud para estimar os custos.
Para melhores resultados, o número de workers preemptivos no cluster precisa ser inferior a 50% do número total de todos os workers (principais e secundários) no cluster.
Ao usar workers preemptivos, seus jobs provavelmente apresentarão um número maior de falhas transitórias de tarefas de worker único em comparação com os jobs executados em workers não preemptivos. Para aumentar a tolerância do job a falhas de tarefas de baixo nível, 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 de tarefas e ajudar a evitar falhas de jobs.
Uma consideração sobre a economia de custos: o uso de VMs preemptivas nem sempre economiza custos, já que as preempções podem causar uma execução mais longa do job, o que resulta em custos de job mais altos. Embora o uso do Modo de flexibilidade aprimorado (EFM, na sigla em inglês) com VMs preemptivas possa ajudar a reduzir esse resultado, a economia geral de custos das VMs preemptivas varia de acordo com o caso de uso. Geralmente, jobs de curta duração são mais adequados para uso de VM preemptiva, porque a probabilidade de preempções durante a execução do job será menor. Para estimar os custos e encontrar a melhor solução, experimente opções de job diferentes, como nenhuma VM preemptiva e VMs preemptivas com EFM.
Workers não preemptivos
- Crie um cluster com workers secundários não preemptivos para escalonar a computação sem sacrificar a estabilidade do job. Para isso, especifique "não preemptiva" 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, a gcloud CLI ou a API do 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. As atualizações de rótulo não são propagadas para os trabalhos 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.
Console
É possível especificar o número de workers secundários ao criar um cluster do 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 no console do Google Cloud.
Como criar um cluster com workers secundários
Defina 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" do painel "Configurar nós" na página Criar um cluster do Dataproc do console do Google Cloud. Especifique o número e o tipo de workers secundários 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
Para remover todos os workers secundários de um cluster, atualize a configuração do cluster conforme explicado anteriormente, especificando 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 dele ou para ele com o comando gcloud dataproc clusters update. É possível atualizar o número, mas não o tipo de 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. Observe que os workers secundários são VMs preemptivas padrão.
Para especificar workers secundários não preemptivos ao criar um cluster, defina --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.
O comando a seguir cria o "cluster1" com dois workers secundários preemptivos (tipo padrão) padrão.
gcloud dataproc clusters create cluster1 \ --num-secondary-workers=2 \ --region=us-central1Exemplo 2
O comando a seguir usa a sinalização secondary-worker-type para criar "cluster2" com dois workers secundários spot (antecipados).
gcloud dataproc clusters create cluster2 \ --num-secondary-workers=2 \ --secondary-worker-type=spot \ --region=us-central1
Exemplo 3
O comando a seguir usa a sinalização 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
Como atualizar um cluster com workers secundários
Para atualizar um cluster para adicionar ou remover workers secundários, use o comando gcloud dataproc clusters update com o argumento --num-secondary-workers.
O comando a seguir atualiza o "example-cluster" para usar quatro workers secundários do tipo padrão ou do tipo 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.
O comando a seguir remove todos os workers secundários do "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 os workers secundários são VMs preemptivas padrão.
Exemplo 1A 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 2A solicitação POST a seguir cria um "cluster2" com dois workers de VM spot (antecipados).
POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters
{
"clusterName": "cluster2",
"config": {
"secondaryWorkerConfig": {
"numInstances": 2,
"preemptibility": "SPOT"
}
}
}
Exemplo 3
A solicitação POST a seguir cria o "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.
ExemploA solicitação PATCH a seguir atualiza um cluster para ter quatro workers secundários do tipo padrão ou do tipo 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
}
}
}
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.
Se houver um problema de permissão nessa conta de serviço, os registros do Dataproc não informarão a falha na criação de workers secundários, mas os workers com falha serã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 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 ID do grupo de instâncias exibirá o nome do grupo no formato de
dataproc-CLUSTER NAME-swe 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 pararesource.type="gce_instance_group"eresource.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çoproject-id@cloudservices.gserviceaccount.comdo 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]