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.
Atualizado em 2023-05-19 GMT+08:00

Solução HA do YARN

Princípios e solução de implementação de HA

O ResourceManager no YARN gerencia recursos e agenda tarefas no cluster. Em versões anteriores ao Hadoop 2.4, SPOFs podem ocorrer em ResourceManager no cluster do YARN. A solução HA do YARN usa nós redundantes de ResourceManager para enfrentar desafios de confiabilidade de serviço e tolerância a falhas.

Figura 1 Arquitetura de HA do ResourceManager

HA de ResourceManager é conseguido usando nós ResourceManager ativo-em espera, como mostrado em Figura 1. Semelhante à solução HA do HDFS, o HA do ResourceManager permite que apenas um nó do ResourceManager esteja no estado ativo a qualquer momento. Quando o ResourceManager ativo falha, a alternância ativo-em espera pode ser disparado automaticamente ou manualmente.

Quando a função de failover automático não estiver desativada, após o cluster do YARN, os administradores de cluster do MRS precisarão executar o comando yarn rmadmin para alternar manualmente um dos nós do ResourceManager para o estado ativo. Em um evento de manutenção planejado ou uma falha, espera-se que primeiro rebaixem o ResourceManager ativo para o estado de espera e o ResourceManager de espera para o estado ativo.

Quando o failover automático é ativado, um ActiveStandbyElector interno baseado no ZooKeeper é usado para decidir qual nó do ResourceManager deve ser o ativo. Quando o ResourceManager ativo é defeituoso, outro nó do ResourceManager é automaticamente selecionado para ser o ativo para assumir o nó defeituoso.

Quando os nós ResourceManager do cluster são implantados no modo HA, a configuração yarn-site.xml usada pelos clientes precisa listar todos os nós do ResourceManager. O cliente (incluindo ApplicationMaster e NodeManager) procura o ResourceManager ativo no modo de sondagem. Ou seja, o cliente precisa fornecer o mecanismo de tolerância a falhas. Se o ResourceManager ativo não puder ser conectado com, o cliente procurará continuamente por um novo no modo de sondagem.

Depois que o nó do ResourceManager em espera se torna ativo, as aplicações de camada superior podem recuperar seu status quando a falha ocorre. Para obter detalhes, consulte Reinicialização do ResourceManager. Quando a Reinicialização do ResourceManager está habilitada, o nó do ResourceManager reiniciado carrega as informações do nó do ResourceManager ativo anterior e assume as informações de status do contêiner em todos os nós do NodeManager para continuar o serviço em execução. Desta forma, as informações de status podem ser salvas através da execução periódica de operações de ponto de verificação, evitando a perda de dados. Certifique-se de que os nós do ResourceManager ativo e em espera possam acessar as informações de status. Atualmente, são fornecidos três métodos para compartilhar informações de status por sistema de arquivos (FileSystemRMStateStore), banco de dados LevelDB (LeveldbRMStateStore) e ZooKeeper (ZKRMStateStore). Entre eles, apenas ZKRMStateStore suporta o mecanismo de Fencing. Por padrão, o Hadoop usa o ZKRMStateStore.

Para obter mais informações sobre a solução HA do YARN, visite o seguinte site:

http://hadoop.apache.org/docs/r3.1.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html

https://hadoop.apache.org/docs/r3.3.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html