View a markdown version of this page

Gerenciamento de clusters virtuais - Amazon EMR

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Gerenciamento de clusters virtuais

Um cluster virtual corresponde a um namespace do Kubernetes no qual o Amazon EMR está registrado. Você pode criar, descrever, listar e excluir clusters virtuais. Eles não consomem quaisquer recursos adicionais em seu sistema. Um único cluster virtual mapeia para um único namespace do Kubernetes. Dado esse relacionamento, você pode modelar clusters virtuais da mesma forma que modela namespaces Kubernetes para atender aos seus requisitos. Confira os possíveis casos de uso na documentação de visão geral dos conceitos do Kubernetes.

Para registrar o Amazon EMR com um namespace do Kubernetes em um cluster do Amazon EKS, você precisa do nome do cluster do EKS e do namespace que foi configurado para executar sua workload. Esses clusters registrados no Amazon EMR são chamados de clusters virtuais porque não gerenciam computação ou armazenamento físicos, mas direcionam para um namespace do Kubernetes no qual sua workload está programada.

nota

Antes de criar um cluster virtual, você deve concluir as etapas de 1 a 8 em Configuração do Amazon EMR no EKS.

Criação de um cluster virtual

Execute o comando apresentado a seguir para criar um cluster virtual ao registrar o Amazon EMR com um namespace em um cluster do EKS. virtual_cluster_nameSubstitua por um nome que você forneça para seu cluster virtual. eks_cluster_nameSubstitua pelo nome do cluster EKS. Substitua o pelo namespace namespace_name com o qual você deseja registrar o Amazon EMR.

aws emr-containers create-virtual-cluster \ --name virtual_cluster_name \ --container-provider '{ "id": "eks_cluster_name", "type": "EKS", "info": { "eksInfo": { "namespace": "namespace_name" } } }'

Como alternativa, você pode criar um arquivo JSON que inclua os parâmetros obrigatórios para o cluster virtual, como demonstra o exemplo a seguir.

{ "name": "virtual_cluster_name", "containerProvider": { "type": "EKS", "id": "eks_cluster_name", "info": { "eksInfo": { "namespace": "namespace_name" } } } }

Em seguida, execute o comando create-virtual-cluster apresentado a seguir com o caminho para o arquivo JSON.

aws emr-containers create-virtual-cluster \ --cli-input-json file://./create-virtual-cluster-request.json
nota

Para validar a criação com êxito de um cluster virtual, visualize o status dos clusters virtuais ao executar o comando list-virtual-clusters ou ao acessar a página Clusters virtuais no console do Amazon EMR.

Listagem de clusters virtuais

Execute o comando apresentado a seguir para visualizar o status dos clusters virtuais.

aws emr-containers list-virtual-clusters

Descrição de um cluster virtual

Execute o comando apresentado a seguir para obter mais detalhes sobre um cluster virtual, como o namespace, o status e a data de registro. 123456Substitua pelo seu ID de cluster virtual.

aws emr-containers describe-virtual-cluster --id 123456

Exclusão de um cluster virtual

Execute o comando apresentado a seguir para excluir um cluster virtual. 123456Substitua pelo seu ID de cluster virtual.

aws emr-containers delete-virtual-cluster --id 123456

Estados de um cluster virtual

A tabela a seguir descreve os quatro estados possíveis de um cluster virtual.

State Description

RUNNING

O cluster virtual está no estado RUNNING.

TERMINATING

O encerramento solicitado para o cluster virtual está em andamento.

TERMINATED

O encerramento solicitado foi concluído.

ARRESTED

O encerramento solicitado falhou devido a permissões insuficientes.

Limites de trabalho simultâneos para clusters virtuais

Você pode configurar limites de trabalho simultâneos em um cluster virtual do Amazon EMR no EKS para controlar quantas execuções de trabalho são executadas simultaneamente e quantas podem esperar na fila. Você define o limite de simultaneidade (maxConcurrentJobRuns) e a profundidade da fila (maxInQueueJobRuns) de forma independente, para poder limitar as execuções de tarefas em execução, as execuções de tarefas em fila ou ambas. Quando você define esses limites, a StartJobRun API fornece contrapressão no nível do cluster virtual. O trabalho é executado além do limite de execução, espera na fila no PENDING estado SUBMITTED ou em vez de começar imediatamente e, quando a fila estiver cheia, StartJobRun rejeita envios adicionais. Por exemplo, se você definir um cluster virtual para permitir 500 execuções de trabalho simultâneas e 100 execuções de trabalhos em fila, o 101º envio em fila será rejeitado e você poderá rebalancear essa carga de trabalho em outros clusters virtuais no mesmo cluster EKS ou adicionar capacidade. Quando você não define um limite de simultaneidade e a profundidade da fila continua aumentando, para que as execuções de tarefas permaneçam no PENDING estado SUBMITTED ou por mais tempo antes de começarem, isso pode indicar que o cluster EKS subjacente está com poucos recursos computacionais e não pode programar novos pods com rapidez suficiente. Nesse caso, direcione a carga de trabalho para outro cluster ou adicione capacidade.

Limites de trabalho simultâneos adicionam uma camada de controle na frente do agendador do Kubernetes e do ResourceQuota recurso no site do Kubernetes. Como elas são aplicadas antes da criação de qualquer podsStartJobRun, a carga excessiva é colocada em fila ou rejeitada na API, o que protege o cluster subjacente antes que os trabalhos cheguem até ele. O Kubernetes ainda impõe o teto real de CPU e memória abaixo.

Principais benefícios dos limites de trabalho simultâneos

  • Evita a sobrecarga de vizinhos ruidosos — limita o número de execuções de trabalhos em execução e em fila por cluster virtual, de forma que um único cluster virtual não possa monopolizar o cluster EKS compartilhado e causar falhas de agendamento de vizinhos ruidosos para outros clusters virtuais.

  • Permite a modelagem do tráfego — retorna uma rejeição imediata quando a fila de um cluster virtual está cheia, para que você possa redirecionar os envios para outros clusters virtuais em vez de sobrecarregar um único cluster virtual.

  • Fornece visibilidade — emite as JobsInQueue CloudWatch métricas por cluster virtual JobsRunning e no AWS/EMRContainers namespace para contagens de execução de tarefas ativas e em fila a cada 5 minutos, o que fornece um sinal de integridade para agendamento.

Começando com limites de trabalho simultâneos

Você configura limites de trabalho simultâneos com o schedulerConfiguration campo em um cluster virtual. Esse campo aceita dois parâmetros:

maxConcurrentJobRuns

O número máximo de execuções de trabalho que podem estar no RUNNING estado a qualquer momento.

maxInQueueJobRuns

O número máximo de execuções de trabalho que podem estar no SUBMITTED estado PENDING ou (profundidade da fila) a qualquer momento.

AWS CLI

Para definir limites ao criar um cluster virtual, especifique schedulerConfiguration em sua solicitação.

aws emr-containers create-virtual-cluster \ --name my-virtual-cluster \ --container-provider '{ ... }' \ --scheduler-configuration '{ "maxConcurrentJobRuns": 500, "maxInQueueJobRuns": 100 }'

Para alterar os limites de um cluster virtual existente, use o update-virtual-cluster comando.

aws emr-containers update-virtual-cluster \ --id virtual-cluster-id \ --scheduler-configuration '{ "maxConcurrentJobRuns": 500, "maxInQueueJobRuns": 100 }'

Para remover os limites de um cluster virtual, passe um vazioschedulerConfiguration. Isso limpa a configuração, portanto, nenhum limite se aplica e o cluster virtual retorna ao comportamento padrão (ilimitado). Observe que, em vez disso, omitir schedulerConfiguration da solicitação deixa os limites existentes inalterados — você deve passar um objeto vazio para eliminá-los.

aws emr-containers update-virtual-cluster \ --id virtual-cluster-id \ --scheduler-configuration '{}'

Para visualizar os limites atuais e as contagens de trabalhos em tempo real, use o describe-virtual-cluster comando. A resposta inclui você schedulerConfiguration e um SchedulerStatus objeto com o atual activeJobRunCount inQueueJobRunCount e.

nota

Quando você envia uma execução de trabalho para um cluster virtual cuja fila está cheia, StartJobRun retorna a. ValidationException

Escolhendo valores para máximo ConcurrentJobRuns e máximo InQueueJobRuns

Os limites certos dependem de três coisas: quanto trabalho seu cluster Amazon EKS pode executar ao mesmo tempo, quão intermitentes são seus envios e como você deseja que o cluster virtual se comporte quando estiver cheio. Use a orientação a seguir para escolher um ponto de partida e, em seguida, refiná-lo a partir dos contadores ativos.

Configuração máxima ConcurrentJobRuns (slots em execução)

maxConcurrentJobRunsé uma grade de proteção baseada em contagem e granularidade de trabalho. Uma estimativa aproximada aqui pode proteger o cluster subjacente do Amazon EKS de ser degradado devido à carga e pode melhorar a disponibilidade.

  • Comece com a capacidade dividida pela área ocupada por trabalho. Baseie-se no que cada tarefa solicita (driver, executores e sobrecarga de memória) e direcione aproximadamente 70 a 80 por cento da capacidade do seu namespace para deixar espaço para sobrecarga de driver, aumento de escala de nós e intermitências.

  • Limite o tamanho de cada trabalho (T-shirt dimensionamento). Limite cada trabalho spark.dynamicAllocation.maxExecutors e padronize-o em alguns tamanhos — por exemplo, pequeno (20 executores), médio (100) e grande (aproximadamente 500) — para que, maxConcurrentJobRuns multiplicado pelo limite, mapeie previsivelmente a capacidade, em vez de provisionamento excessivo ou insuficiente, para uma média variável. Para obter a matemática mais limpa, direcione cada classe de tamanho para seu próprio cluster virtual.

  • Sintonize a partir de contadores ao vivo. Comece de forma conservadora e aumente o valor gradualmente enquanto observa activeJobRunCount a JobsRunning métrica no AWS/EMRContainers namespace.

Configuração máxima InQueueJobRuns (profundidade da fila)

maxInQueueJobRunscontrola o tamanho do backlog que o cluster virtual aceita antes de começar a rejeitar os envios. É um tampão de absorção de explosão. Considere os seguintes fatores.

  • Perfil de intermitência — Dimensione a fila para absorver as intermitências de envio que você espera acima da sua taxa de execução. Se os pipelines programados executarem várias tarefas ao mesmo tempo, uma fila maior evita rejeições falsas. Baseie a profundidade no tamanho esperado da explosão, em vez de em um múltiplo fixo demaxConcurrentJobRuns, e valide-a em relação ao limite de tempo de drenagem a seguir.

  • Tempo de espera aceitável — Os trabalhos em fila aguardam a liberação de um espaço em execução. O trabalho no final de uma fila cheia espera aproximadamente a profundidade da fila dividida pela taxa de transferência de conclusão. Por exemplo, se os trabalhos terminarem em N por minuto e a fila mantiver Q, a cauda aguardará cerca de Q dividido por N minutos. Mantenha isso dentro do seu SLA. Como os trabalhos armazenados em buffer falham após 30 minutos se nenhum espaço for liberado, mantenha-se maxInQueueJobRuns pequeno o suficiente para que uma fila cheia seja drenada em 30 minutos com uma taxa de conclusão estável. Caso contrário, os trabalhos em fila expirarão.

  • Contrapressão em comparação com o buffer — Uma fila mais profunda suaviza as intermitências, mas atrasa a rejeição cheia de filas que você usa para modelar o tráfego e aumenta a latência da cauda. Uma fila mais rasa falha rapidamente, o que dá aos clientes um sinal rápido e acionável para tentar novamente ou encaminhar para outro lugar. Escolha se você prefere carregar ou eliminar o buffer e redirecioná-lo.

  • Comportamento de nova tentativa do cliente — Quando a fila está cheia, StartJobRun retorna a. ValidationException Certifique-se de que seus remetentes lidem com essa exceção — tente novamente com o backoff ou encaminhe a carga de trabalho para outro cluster virtual. Defina a profundidade para que as rejeições ocorram somente durante uma sobrecarga genuína, não durante a operação de rotina.

Considerações sobre limites de trabalho simultâneos

  • Nenhum limite é aplicado por padrão. Os clusters virtuais e as cargas de trabalho existentes não são afetados, a menos que você defina explicitamente. schedulerConfiguration

  • Como os contadores são mantidos em um sistema distribuído, às vezes você pode esperar um pequeno delta transitório do valor real. A reconciliação interna corrige qualquer desvio.