Recursos de código aberto aprimorados do Yarn

Agendamento de tarefas com base em prioridades

No mecanismo de agendamento de recursos Yarn nativo, se todos os recursos do cluster Hadoop forem ocupados por jobs do MapReduce enviados anteriormente, os jobs enviados posteriormente serão mantidos em estado pendente até que todos os jobs em execução sejam executados e os recursos sejam liberados.

O cluster do MRS fornece o mecanismo de agendamento de prioridade de tarefa. Com esse recurso, você pode definir trabalhos de diferentes prioridades. Trabalhos de alta prioridade podem antecipar recursos liberados de trabalhos de baixa prioridade, embora os trabalhos de alta prioridade sejam enviados posteriormente. Os trabalhos de baixa prioridade que não são iniciados serão suspensos, a menos que esses trabalhos de alta prioridade sejam concluídos e os recursos sejam liberados, então eles podem ser iniciados adequadamente.

Esse recurso permite que os serviços controlem os trabalhos de computação de maneira mais flexível, obtendo assim maior utilização de recursos de cluster.

A reutilização de contêiner está em conflito com o agendamento de prioridade de tarefa. Se a reutilização de contêiner estiver habilitada, os recursos estão sendo ocupados e o agendamento de prioridade de tarefa não entrará em vigor.

Controle de permissão de Yarn

O mecanismo de permissão do Hadoop Yarn é implementado por meio de ACLs. O seguinte descreve como conceder diferentes controles de permissão para diferentes usuários:

• ACL de administração

  Um administrador de O&M é especificado para o cluster de YARN. A ACL de administração é determinada por yarn.admin.acl. O administrador de O&M do cluster pode acessar a IU da Web do ResourceManager e operar nós do NodeManager, filas e NodeLabel, mas não pode enviar tarefas.

• Fila de ACL

  Para facilitar o gerenciamento de usuários no cluster, os usuários ou grupos de usuários são divididos em várias filas às quais cada usuário e grupo de usuários pertence. Cada fila contém permissões para enviar e gerenciar aplicações (por exemplo, encerrar qualquer aplicação).

Funções de código aberto:

atualmente, o Yarn suporta as seguintes funções para usuários:

• Administrador de O&M do cluster
• Administrador de fila
• Usuário comum

No entanto, as APIs (como a IU da Web, a API REST e a API Java) fornecidos pelo Yarn não oferecem suporte ao controle de permissão específico da função. Portanto, todos os usuários têm permissão para acessar as informações do aplicação e do cluster, que não atendem aos requisitos de isolamento no cenário multi-locatário.

Esta é uma função aprimorada.

No modo de segurança, o gerenciamento de permissões é aprimorado para as APIs, como IU da Web, API REST e API Java fornecidas pelo Yarn. O controle de permissão pode ser realizado com base nas funções do usuário.

As permissões baseadas em funções são as seguintes:

• Administrador do Cluster O&M: executa operações de gerenciamento no cluster Yarn, como acessar a IU da Web do ResourceManager, atualizar filas, definir NodeLabel e executar alternância ativa/em espera.
• Administrador de fila: tem permissão para modificar e visualizar filas gerenciadas pelo cluster do Yarn.
• Usuário comum: tem permissão para modificar e exibir aplicativos auto-submetidos no cluster do Yarn.

Princípio do Superior Scheduler (Autodesenvolvido)

O Superior Scheduler é um mecanismo de agendamento projetado para o sistema de gerenciamento de recursos distribuídos de Hadoop YARN. É um programador de alto desempenho e de nível empresarial projetado para pools de recursos convergentes e requisitos de serviço multi locatário.

Superior Scheduler atinge todas as funções dos agendadores de código aberto, do Fair Scheduler e do Capacity Scheduler. Em comparação com os agendadores de código aberto, o Superior Scheduler é aprimorado na política de agendamento de recursos multi-locatário da empresa, isolamento de recursos e compartilhamento entre usuários em um locatário, desempenho de agendamento, uso de recursos do sistema e escalabilidade de cluster. O Superior Scheduler foi projetado para substituir os agendadores de código aberto.

Semelhante ao Fair Scheduler e ao Capacity Scheduler, o Superior Scheduler segue a API do plug-in do Yarn para interagir com o Yarn ResourceManager para oferecer funcionalidades de agendamento de recursos. Figura 1 mostra o diagrama geral do sistema.

Figura 1 Arquitetura interna do Superior Scheduler

Em Figura 1, o Superior Scheduler consiste nos seguintes módulos:

• Superior Scheduler Engine é um mecanismo de agendamento de alto desempenho com ricas políticas de agendamento.
• Superior Yarn Scheduler Plugin funciona como uma ponte entre o Yarn ResourceManager e o Superior Scheduler Engine e interage com o Yarn ResourceManager.

  O princípio de agendamento dos programadores de código aberto é que os recursos correspondam aos jobs com base nos batimentos cardíacos dos nós de computação. Especificamente, cada nó de computação envia periodicamente mensagens para ResourceManager de Yarn para notificar o status do nó e inicia o agendador para atribuir tarefas ao próprio nó. Neste mecanismo de agendamento, o período de agendamento depende do batimento cardíaco. Se a escala de cluster aumentar, pode ocorrer gargalo na escalabilidade do sistema e no desempenho de agendamento. Além disso, como os recursos correspondem aos trabalhos, a precisão de agendamento de um agendador de código aberto é limitada. Por exemplo, a afinidade de dados é aleatória e o sistema não suporta políticas de agendamento baseadas em carga. O agendador pode não fazer a melhor escolha devido à falta da exibição de recursos global ao selecionar tarefas.

  O Superior Scheduler adota vários mecanismos de agendamento. Existem tópicos de agendamento dedicados no Superior Scheduler, separando batimentos cardíacos com agendamento e evitando tempestades de batimentos cardíacos do sistema. Além disso, o Superior Scheduler combina tarefas com recursos, fornecendo a cada tarefa agendada uma visualização de recursos global e aumentando a precisão do agendamento. Comparado com o agendador de código aberto, o Superior Scheduler se destaca em taxa de transferência do sistema, uso de recursos e afinidade de dados.

Figura 2 Comparação do Superior Scheduler com os agendadores de código aberto

Além da taxa de transferência e da utilização aprimoradas do sistema, o Superior Scheduler oferece os seguintes principais recursos de agendamento:

• Vários pools de recursos

  Vários pools de recursos ajudam a dividir logicamente os recursos do cluster e compartilhá-los entre vários locatários ou filas. A divisão de pools de recursos suporta recursos heterogêneos. Os pools de recursos podem ser divididos exatamente de acordo com os requisitos do isolamento de recursos da aplicação. Você pode configurar políticas adicionais para filas diferentes em um pool.

• Agendamento multi-locatário (reserve, min, share e max) em cada pool de recursos

  O Superior Scheduler fornece uma política de agendamento multi-locatário hierárquica flexível. Políticas diferentes podem ser configuradas para diferentes locatários ou filas que podem acessar diferentes pools de recursos. A figura a seguir lista as políticas suportadas:

  Tabela 1 Descrição da política

  Nome	Descrição
  reserve	Esta política é usada para reservar recursos para um locatário. Mesmo que o locatário não tenha trabalhos disponíveis, outro locatário não pode usar o recurso reservado. O valor pode ser uma porcentagem ou um valor absoluto. Se a porcentagem e o valor absoluto estiverem configurados, a porcentagem será calculada automaticamente em um valor absoluto e o valor maior será usado. O valor de reserve padrão é 0. Em comparação com o método de especificar um pool de recursos dedicado e hosts, a política reserve fornece uma função de reserva flutuante flexível. Além disso, como nenhum host específico é especificado, a afinidade de dados para o cálculo é melhorada e o impacto dos hosts defeituosos é evitado.
  min	Esta política permite a preempção de recursos mínimos. Outros locatários podem usar esses recursos, mas o locatário atual tem a prioridade de usá-los. O valor pode ser uma porcentagem ou um valor absoluto. Se a porcentagem e o valor absoluto estiverem configurados, a porcentagem será calculada automaticamente em um valor absoluto e o valor maior será usado. O valor padrão é 0.
  Compartilhar	Essa política é usada para recursos compartilhados que não podem ser preemptivos. Para usar esses recursos, o locatário atual precisa esperar que outros locatários concluam trabalhos e liberem recursos. O valor pode ser uma porcentagem ou um valor absoluto.
  max	Esta política é usada para o máximo de recursos que podem ser utilizados. O locatário não pode obter mais recursos do que o valor máximo permitido. O valor pode ser uma porcentagem ou um valor absoluto. Se a porcentagem e o valor absoluto estiverem configurados, a porcentagem será calculada automaticamente em um valor absoluto e o valor maior será usado. Por valor padrão, não há restrição de recursos.

  Figura 3 mostra a política de alocação de recursos do locatário.

  Figura 3 Políticas de agendamento de recursos
  
  

  Na figura acima, Total indica o número total de recursos, não a política de agendamento.

  Comparado com os agendadores de código aberto, o Superior Scheduler suporta tanto a porcentagem quanto o valor absoluto de locatários para alocação de recursos, abordando com flexibilidade os requisitos de agendamento de recursos dos locatários ao nível empresarial. Por exemplo, os recursos podem ser alocados de acordo com o valor absoluto dos locatários de nível 1, evitando o impacto causado por mudanças na escala do cluster. No entanto, os recursos podem ser alocados de acordo com a porcentagem de alocação dos sublocatários, melhorando o uso de recursos no locatário de nível 1.

• Agendamento de recursos heterogêneo e multidimensional

  O Superior Scheduler suporta as seguintes funções, exceto agendamento de CPU e memória:

  • Os rótulos de nó podem ser usados para identificar atributos multidimensionais de nós, como GPU_ENABLED e SSD_ENABLED, e podem ser agendados com base nesses rótulos.
  • Os pools de recursos podem ser usados para agrupar recursos do mesmo tipo e alocá-los a locatários ou filas específicas.
• Agendamento justo de vários usuários em um locatário

  Em um locatário folha, vários usuários podem usar a mesma fila para enviar jobs. Em comparação com os agendadores de código aberto, o Superior Scheduler suporta a configuração de políticas flexíveis de compartilhamento de recursos entre diferentes usuários em um mesmo locatário. Por exemplo, os usuários VIP podem ser configurados com maior peso de acesso a recursos.

• Agendamento de reconhecimento de localidade de dados

  O Superior Scheduler adota a política de agendamento de job para nó. Ou seja, o Superior Scheduler tenta agendar jobs especificados entre os nós disponíveis para que o nó selecionado seja adequado para os jobs especificados. Ao fazer isso, o agendador terá uma visão geral do cluster e dos dados. A localização é garantida se houver uma oportunidade de colocar as tarefas mais próximas dos dados. O agendamento de código aberto usa a política de agendamento de nó para job para corresponder os jobs apropriados a um determinado nó.

• Reserva dinâmica de recursos durante o agendamento de contêiner

  Em um ambiente de computação heterogêneo e diversificado, alguns contêineres precisam de mais recursos ou vários recursos. Por exemplo, o job do Spark pode exigir grande memória. Quando tais contêineres competem com contêineres que exigem menos recursos, os contêineres que exigem mais recursos podem não obter recursos suficientes dentro de um período razoável. Agendadores de código aberto alocam recursos para jobs, o que pode causar reservas de recursos não razoáveis para esses jobs. Esse mecanismo leva ao desperdício de recursos gerais do sistema. O Superior Scheduler difere dos agendadores de código aberto nos seguintes aspectos:

  • Correspondência baseada em requisitos: o Superior Scheduler agenda jobs para os nós e seleciona os nós apropriados para reservar recursos para melhorar o tempo de inicialização dos contêineres e evitar desperdícios.
  • Reequilíbrio do locatário: quando a lógica de reserva está ativada, os agendadores de código aberto não estão em conformidade com a política de compartilhamento configurada. O Superior Scheduler usa métodos diferentes. Em cada período de programação, o Superior Scheduler percorre todos os locatários e tenta equilibrar os recursos com base na política de vários locatários. Além disso, o Superior Scheduler tenta atender a todas as políticas (reserve, min e share) para liberar recursos reservados e direcionar recursos disponíveis para outros contêineres que devem obter recursos sob diferentes locatários.
• Controle dinâmico de status da fila (Open/Closed/Active/Inactive)

  Vários status de fila são suportados, ajudando os administradores de cluster do MRS a gerenciar e manter vários locatários.

  • Status aberto (Open/Closed): se o status for Open por padrão, as aplicações enviadas à fila serão aceitos. Se o status for Closed, nenhuma aplicação será aceita.
  • Status ativo (Active/Inactive): se o status for Active por padrão, os recursos podem ser agendados e alocados para aplicações no locatário. Os recursos não serão agendados para filas no status Inactive.
• Motivo pendente da aplicação

  Se a aplicação não for iniciado, forneça os motivos de pendência do job.

Tabela 2 descreve o resultado da comparação dos agendadores de código aberto do Superior Scheduler e do Yarn.

Em conclusão, o Superior Scheduler é um agendador de alto desempenho com várias políticas de agendamento e é melhor do que o Capacity Scheduler em termos de funcionalidade, desempenho, uso de recursos e escalabilidade.

Isolamento rígido da CPU

O Yarn não pode controlar estritamente os recursos da CPU usados por cada contêiner. Quando o subsistema da CPU é usado, um contêiner pode ocupar recursos excessivos. Portanto, CPUset é usado para controlar a alocação de recursos.

Para resolver esse problema, os recursos da CPU são alocados para cada contêiner com base na proporção de núcleos virtuais (vCores) para núcleos físicos. Se um contêiner requer um núcleo físico inteiro, o contêiner o possui. Se um contêiner precisar apenas de alguns núcleos físicos, vários contêineres podem compartilhar o mesmo núcleo físico. A figura a seguir mostra um exemplo da cota de CPU. A proporção dada de vCores para núcleos físicos é de 2:1.

Figura 4 Cota da CPU

Característica de código aberto aprimorada: otimizando o desempenho da reinicialização

Geralmente, o ResourceManager recuperado pode obter aplicações em execução e concluídas. No entanto, um grande número de aplicações concluídas pode causar problemas como inicialização lenta e tempo de ResourceManagers de comutação/reinicialização de HA.

Para acelerar a inicialização, obtenha a lista de aplicações inacabadas antes de iniciar o ResourceManagers. Neste caso, a aplicação concluída continua a ser recuperada no thread assíncrono em segundo plano. A figura a seguir mostra como a recuperação do ResourceManager começa.

Figura 5 Iniciar a recuperação do ResourceManager