Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Computação
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Redes
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Gerenciamento e governança
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
Cloud Operations Center
Resource Governance Center
Migração
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Análises
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
IoT
IoT Device Access
Outros
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Segurança e conformidade
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Blockchain
Blockchain Service
Serviços de mídia
Media Processing Center
Video On Demand
Live
SparkRTC
Armazenamento
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Cloud Server Backup Service
Storage Disaster Recovery Service
Scalable File Service
Volume Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Bancos de dados
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Aplicações de negócios
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Data Lake Factory
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Distribuição de conteúdo e computação de borda
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Soluções
SAP Cloud
High Performance Computing
Serviços para desenvolvedore
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
Cloud Application Engine
MacroVerse aPaaS
KooPhone
KooDrive
Central de ajuda/ MapReduce Service/ Visão geral de serviço/ Componentes/ YARN/ Recursos de código aberto aprimorados do Yarn

Recursos de código aberto aprimorados do Yarn

Atualizado em 2023-05-19 GMT+08:00

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.

Tabela 2 Análise comparativa

Agendamento

Agendador de código aberto do Yarn

Superior Scheduler

Agendamento multi-locatário

Em clusters homogêneos, o Capacity Scheduler ou o Fair Scheduler podem ser selecionados e o cluster não suporta o Fair Scheduler. O Capacity Scheduler suporta o agendamento por porcentagem e o Fair Scheduler suporta o agendamento por valor absoluto.

  • Suporta clusters heterogêneos e vários pools de recursos.
  • Suporta reservation para garantir acesso direto aos recursos.

Agendamento de reconhecimento de localidade de dados

A política de agendamento de nó para job reduz a taxa de sucesso da localização de dados e afeta potencialmente o desempenho da execução de aplicações.

A job-to-node scheduling policy pode reconhecer a localização de dados com mais precisão e a taxa de acerto de job do agendamento de localização de dados é maior.

Agendamento balanceado com base na carga de hosts

Incompatível

O agendamento balanceado pode ser alcançado quando o Superior Scheduler considera a carga do host e a alocação de recursos durante o agendamento.

Agendamento justo de vários usuários em um locatário

Incompatível

Suporta palavras-chave default e others.

Razão de espera do job

Incompatível

Razões de espera de job ilustram por que um job precisa esperar.

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

Usamos cookies para aprimorar nosso site e sua experiência. Ao continuar a navegar em nosso site, você aceita nossa política de cookies. Saiba mais

Feedback

Feedback

Feedback

0/500

Conteúdo selecionado

Envie o conteúdo selecionado com o feedback