E-MapReduce:Cluster management FAQ

É possível atualizar um cluster do EMR?

Não. Não é possível atualizar um cluster do EMR ou seus services. Para usar uma versão mais recente, libere o cluster existente e crie um novo.

Quais services os clusters do EMR suportam?

Os services suportados variam conforme o tipo e a versão do cluster. Para obter mais informações, consulte Visão geral de versões.

É possível adicionar o Zeppelin no console?

Não. Não é possível adicionar o Zeppelin como um novo service pelo console do EMR. Para adicionar o Zeppelin, instale-o em qualquer instância ECS do nó mestre. Também é possível instalar e manter manualmente outros componentes nas instâncias ECS. Para obter informações sobre os services que podem ser adicionados a diferentes tipos de clusters, consulte Adicionar services.

O EMR suporta o Oozie e suas alternativas?

O componente Oozie não está incluído nos clusters DataLake do EMR que executam o EMR V5.8.0 ou posterior, ou o EMR V3.42.0 ou posterior. Caso necessite de um service de agendamento de fluxo de trabalho, utilize o EMR Workflow. Para obter mais informações, consulte O que é o EMR Workflow?.

Motivo para três nós mestres em clusters HA

Os clusters de alta disponibilidade mais recentes do EMR utilizam três nós mestres para oferecer maior confiabilidade em comparação à configuração com dois nós mestres. Configurações com dois nós mestres não são mais suportadas, e o grupo de nós mestres não pode ser reduzido. Nesses clusters, o EMR distribui os nós mestres por diferentes hosts físicos para reduzir o risco de falhas.

Ativação da criptografia de disco de dados e seus efeitos

Após ativar a criptografia de disco de dados, os dados são criptografados tanto em trânsito quanto em repouso. Esse recurso ajuda a atender aos requisitos de segurança e conformidade. A criptografia de disco de dados é transparente para as aplicações na camada de sistema operacional das instâncias ECS e não afeta a execução de jobs.

Como limpar um cluster com falha

Falhas na criação de clusters geralmente ocorrem devido a configurações incorretas do RDS que causam falha na implantação, ou devido à falta de estoque de algumas instâncias ECS.

Se algumas instâncias ECS foram criadas, mas o status do cluster for Startup Failed, libere as instâncias no console do ECS. Após a liberação de todas as instâncias, o cluster do EMR será liberado automaticamente.

Se a implantação do EMR falhar e o status do cluster for Unexpectedly Terminated, nenhum recurso foi criado e nenhuma cobrança será gerada. Clique em Delete na coluna Actions do cluster para removê-lo.

Adição de services a um cluster existente

Sim. É possível adicionar services a um cluster após sua criação. Para obter mais informações, consulte Adicionar services.

Reinicialização de service após alterações de configuração

Alterações de configuração no lado do servidor para services como Spark, Hive e HDFS só entram em vigor após a reinicialização dos services. Alterações nas configurações do lado do cliente entram em vigor após clicar em Deploy Client Configuration, sem necessidade de reiniciar o service. Para obter mais informações sobre como modificar ou adicionar itens de configuração, consulte Gerenciar itens de configuração.

O que é uma reinicialização gradual?

O mecanismo de reinicialização gradual reinicia as instâncias ECS uma a uma. A próxima instância só é reiniciada depois que a atual e todos os seus services forem totalmente restaurados. Cada reinicialização de nó leva cerca de cinco minutos.

Associação de um IP público a um cluster existente

Solicite um endereço Elastic IP (EIP) e associe-o a uma instância ECS em uma Virtual Private Cloud (VPC) que não possua um endereço IP público. Isso permite acessar a instância ECS pela internet. Para obter mais informações, consulte Associar um EIP.

Quando ativar um conjunto de implantação

Um conjunto de implantação é um recurso do ECS que controla a estratégia de distribuição das instâncias ECS. Recomendamos ativar o recurso de conjunto de implantação para grupos de nós principais que utilizam tipos de instância com discos locais, visando melhorar a segurança dos dados. Um conjunto de implantação impede que várias instâncias ECS sejam implantadas no mesmo host físico. Isso evita um ponto único de falha e ajuda a prevenir a perda de dados locais do HDFS no EMR caso um host físico falhe.

Devido às limitações dos conjuntos de implantação do ECS, no máximo 20 instâncias ECS podem ser adicionadas a um conjunto de implantação. Para obter mais informações, consulte Ativar um conjunto de implantação.

Especificação de um conjunto de implantação durante a expansão do cluster

Por padrão, conjuntos de implantação estão ativados para tipos de instância com discos locais e desativados para outros tipos de instância. Ajuste essa configuração conforme necessário. Para obter instruções sobre como ativar um conjunto de implantação, consulte Ativar um conjunto de implantação.

Especificação do tamanho do disco durante a expansão do cluster

Ao expandir um cluster, as configurações do grupo de nós determinam o tamanho do disco para os novos nós. Esse tamanho não pode ser alterado durante o processo de expansão. Se necessário, ajuste o tamanho do disco do grupo de nós. Para obter instruções sobre como expandir um disco, consulte Expandir um disco.

É possível expandir ou reduzir discos?

Apenas a expansão de discos de dados é permitida. Não é possível reduzir discos de dados ou redimensionar discos de sistema.

Na aba Nodes do cluster desejado, clique em Expand Disk no grupo de nós alvo para expandir seus discos de dados. Para obter instruções específicas, consulte Expandir um disco.

Expansão e redução de clusters

Sim, mas as regras de dimensionamento variam conforme o tipo de nó:

• Expansão: Apenas grupos de nós principais e de tarefas podem ser expandidos. Por padrão, a configuração dos novos nós é idêntica à dos nós existentes. Antes de expandir, certifique-se de que todos os pedidos relacionados estejam pagos. Um pedido não pago causará falha na operação de expansão. Para obter instruções específicas, consulte Expandir um cluster.

• Redução: O grupo de nós mestres não suporta redução. As regras para outros grupos de nós variam conforme o tipo:

  • Para grupos de nós de tarefas com instâncias preemptíveis ou pagamento conforme o uso e grupos de nós Gateway com pagamento conforme o uso, consulte Reduzir um cluster.

  • Para grupos de nós principais com pagamento conforme o uso, grupos de nós de tarefas por assinatura e grupos de nós principais por assinatura, consulte Reduzir manualmente um grupo de nós.

Erro: "AddNumber is not valid" durante a expansão

• Sintoma: Você recebe a mensagem de erro The specified parameter AddNumber is not valid. add instances number :xxx larger than deploymentSet availableAmount: xxx deploymentSetId: ds-uf6gwfou0a13kekupt14xxxx ao expandir um cluster.

• Causa: Esse erro indica que o recurso de conjunto de implantação está ativado para o seu cluster e o número de nós no grupo de nós atingiu o limite do conjunto de implantação. Para obter mais informações sobre conjuntos de implantação, consulte Ativar um conjunto de implantação.

• Solução: Entre em contato com o Suporte do ECS para solicitar um aumento na cota do conjunto de implantação da sua conta.

Como parar a coleta de logs de service?

Se você não desejar que o EMR colete seus dados, desative a coleta de logs operacionais de service.

Procedimento:

1. Desative a coleta de logs operacionais de service.

   • Durante a criação do cluster: Na etapa de configuração de software, clique em Collect Service Operational Logs.

   • Após a criação do cluster: Na página Basic Information do cluster desejado, na seção Software Information, clique em Collection Status of Service Operational Logs.

2. Verifique se a coleta está desativada.

   Verifique se namenode-log existe em /usr/local/ilogtail/user_log_config.json. Se não existir, a coleta de logs de service está desativada.

   Nota

   Após desativar a coleta de logs de service, a sincronização da configuração leva cerca de dois a três minutos. Aguarde a conclusão.

Quais informações os logs operacionais de service coletam?

Os logs operacionais de service incluem apenas logs dos componentes de service em execução no cluster. Ative ou desative a coleta de todos os logs de service com um único clique. Observe que, ao desativar a coleta de logs, o recurso de verificação de integridade do cluster e o suporte técnico ficarão limitados.

Quais tipos de cluster suportam o EMR Doctor?

Apenas os tipos de cluster DataLake e Hadoop suportam o recurso de verificação de integridade. Após a criação do cluster, utilize esse recurso na aba Monitoring and Diagnostics > Health Check do cluster desejado no console do EMR.

Se o seu cluster Hadoop não possuir esse recurso, ative o EMR Doctor. Para obter mais informações, consulte Ativar o EMR Doctor (para clusters Hadoop).

Impacto da instalação ou atualização do EMR Doctor

A instalação ou atualização do EMR Doctor não reinicia nenhum service nem afeta seus jobs existentes. Após a instalação, o EMR Doctor configura automaticamente os parâmetros necessários no cluster existente, eliminando a necessidade de configurações manuais.

Durante a instalação ou atualização, o EMR Doctor implanta configurações para os services YARN, Spark, Tez e Hive. Se você modificou e salvou algumas configurações, mas ainda não as implantou, certifique-se de que o processo de implantação não afete os services.

Quais dados o EMR Doctor coleta?

O EMR Doctor não coleta seus dados reais, nem verifica seus arquivos ou o conteúdo deles.

O EMR Doctor coleta apenas dados de eventos necessários, como horários de início e término de jobs, métricas e contadores.

O EMR Doctor é gratuito?

Sim. Atualmente, o EMR Doctor é gratuito.

Como a coleta de dados afeta a execução de jobs?

A coleta de metadados de armazenamento do EMR Doctor ajusta dinamicamente os recursos utilizados para coleta com base nos recursos do usuário, sem consumir recursos excessivos.

A coleta de jobs do EMR Doctor utiliza tecnologia de sonda Java e não inicia um processo Java separado para monitoramento. A coleta é realizada de forma assíncrona e não bloqueia o processo principal do job. Se a sobrecarga da coleta ficar muito alta, o EMR Doctor descarta dados automaticamente. Também é possível ajustar parâmetros como a frequência de coleta.

Quando os relatórios de coleta ficam disponíveis?

Após a instalação ou atualização do EMR Doctor, o recurso de relatório diário analisa dados com base nos jobs executados e na coleta de metadados de armazenamento. Portanto, o cluster deve ter uma carga de trabalho ativa.

• Jobs de computação: Após a coleta dos jobs de computação no cluster, o relatório mais recente fica disponível no dia seguinte. O relatório fornece uma avaliação do cluster e recomendações baseadas na análise do status de execução dos jobs do dia anterior.

• Análise de armazenamento: O EMR Doctor não ativa a análise de armazenamento por padrão. Ative-a manualmente. Após a ativação, a coleta geralmente ocorre por volta das 10h. Após a conclusão da coleta, a análise é executada e um relatório é gerado na madrugada do dia seguinte. Se você ativar a coleta à tarde, será necessário aguardar até o terceiro dia para visualizar os resultados.

Valores específicos para configurações recomendadas

O EMR Doctor fornece recomendações direcionais, como reduzir a configuração de memória ou modificar parâmetros de GC, mas não fornece valores específicos de parâmetros. Isso ocorre porque o EMR Doctor utiliza amostragem pontual para coleta, minimizando o impacto no seu programa. Teste e valide todas as configurações recomendadas para suas cargas de trabalho específicas.

Erro: "Insufficient ECS inventory" durante a expansão

• Sintoma: A expansão do cluster falha, com motivo de falha "Insufficient ECS inventory_OutofStock" ou "Insufficient ECS inventory_OperationDenied.NoStock".

• Causa: O tipo de instância ECS do grupo de nós que você deseja expandir possui estoque insuficiente para atender à sua solicitação.

• Solução: Aguarde até que o tipo de instância ECS necessário esteja em estoque e tente expandir novamente, ou expanda criando um novo grupo de nós e selecionando um tipo de instância ECS diferente. Para obter mais informações, consulte Criar um grupo de nós.

Erro: "Insufficient ECS inventory" durante a criação do cluster

• Sintoma: A criação de um cluster ou a adição de um grupo de nós falha, com motivo de falha "Insufficient ECS inventory_OutofStock" ou "Insufficient ECS inventory_OperationDenied.NoStock".

• Causa: O tipo de instância ECS selecionado para o cluster ou grupo de nós possui estoque insuficiente.

• Solução: Ao criar o cluster, selecione outro tipo de instância ECS que tenha estoque suficiente e atenda aos seus requisitos de negócios.

Como excluir services desnecessários?

Não é possível excluir services existentes de um cluster. Uma vez iniciado, um service não pode ser excluído pelo console ou via API.

Como fazer logon em um nó de cluster

Após a criação de um cluster do EMR, faça logon no nó mestre usando a senha definida durante a criação do cluster. Para obter informações sobre como fazer logon em outros nós, consulte Fazer logon em outros nós de um cluster.

Como visualizar o vSwitch de uma instância

No EMR on ECS, as informações do vSwitch estão associadas aos grupos de nós e não podem ser visualizadas diretamente na página Basic Information. Acesse a página Nodes e clique no nome do grupo de nós ao qual a instância pertence para visualizar as informações do vSwitch associado.

Na página Node Management do cluster do EMR, selecione o grupo de nós desejado (como emr-master) na lista de grupos de nós à esquerda. No painel de detalhes à direita, visualize o ID do vSwitch no campo vSwitch.

Resolução de perda de pacotes em um cluster de grande escala

• Sintoma: Ocorre perda frequente de pacotes de rede no cluster, e os logs do sistema podem apresentar mensagens de erro como neighbour: arp_cache: neighbor table overflow!. Isso indica que a tabela de cache do Address Resolution Protocol (ARP) está cheia e não consegue mais gerenciar mapeamentos de endereços IP para MAC, causando problemas de desempenho de rede.

• Causa: Em sistemas distribuídos de grande escala, especialmente quando um único cluster ultrapassa 1.000 servidores e executa uma versão anterior ao EMR-5.18.0 ou EMR-3.52.0 (exclusivo), podem ocorrer instabilidade de rede e perda de pacotes. Otimize o gerenciamento do cache ARP ajustando os parâmetros do sistema.

  O cache ARP armazena mapeamentos entre endereços IP e endereços MAC. Os principais parâmetros são:

  • net.ipv4.neigh.default.gc_thresh1: Número mínimo de entradas a serem mantidas no cache ARP. A coleta de lixo não é realizada se o número de entradas estiver abaixo desse valor. O valor padrão é 128.

  • net.ipv4.neigh.default.gc_thresh2: Limite flexível para o número de entradas no cache ARP. A coleta de lixo é realizada dentro de 5 segundos se o número de entradas exceder esse valor. O valor padrão é 512.

  • net.ipv4.neigh.default.gc_thresh3: Limite rígido para o número de entradas no cache ARP. O valor padrão é 1024.

  Nota

  Os valores padrão são muito baixos para clusters com mais de 1.000 nós e podem causar perda de pacotes de rede e instabilidade. Portanto, os parâmetros devem ser ajustados.

• Solução:

  1. Edite o arquivo /etc/sysctl.conf e adicione o seguinte conteúdo para aumentar o limite de capacidade do cache ARP e otimizar o valor máximo de rastreamento de conexões.

     net.ipv4.neigh.default.gc_thresh1 = 512
     net.ipv4.neigh.default.gc_thresh2 = 2048
     net.ipv4.neigh.default.gc_thresh3 = 10240
     net.nf_conntrack_max = 524288

  2. Execute o comando sudo sysctl -p para aplicar as novas configurações.

     Nota

     Se encontrar a mensagem de erro sysctl: cannot stat /proc/sys/net/nf_conntrack_max: No such file or directory ao executar o comando sysctl -p, execute primeiro o comando sudo modprobe nf_conntrack para carregar o módulo correspondente. Em seguida, execute o comando sysctl -p novamente para atualizar a configuração.

Tratamento de um evento SystemMaintenance.Redeploy

Se você receber um evento de sistema do tipo Instance redeployment due to system maintenance (SystemMaintenance.Redeploy) para uma instância de disco local, isso indica que a Alibaba Cloud detectou riscos potenciais de falha de software ou hardware no host subjacente da instância ECS. Esse risco exige que a instância ECS seja reimplantada. Não clique em Redeploy diretamente no console do ECS para evitar perda de dados.

Solução:

1. Verifique os detalhes do evento para identificar o nó afetado.

2. No grupo de nós que contém o nó com falha, expanda para adicionar um novo nó. Para obter mais informações, consulte Expandir um cluster.

3. Reduza o nó com falha.

   • Para reduzir um grupo de nós principais ou um grupo de nós de tarefas por assinatura, consulte Reduzir manualmente um grupo de nós.

     Nota

     Ao liberar uma instância ECS por assinatura, o ECS calcula e exibe o valor do reembolso. Se tiver dúvidas, abra um ticket e selecione Elastic Compute Service para Product.

   • Para reduzir um grupo de nós de tarefas com pagamento conforme o uso, consulte Reduzir um cluster.

Adição automática de tags de ID de cluster a discos cloud

Para marcar automaticamente os discos cloud das instâncias ECS do seu cluster do EMR com o ID do cluster, ative a herança de tags no console de Tags.

Procedimento:

1. Faça logon no console de Tags.

2. No painel de navegação à esquerda, escolha Tags > Tag inheritance.

3. Leia as instruções para ativar o recurso e marque a caixa de seleção para criar uma função vinculada ao service.

   Ao ativar a herança de tags, o sistema cria automaticamente uma função vinculada ao service chamada AliyunServiceRoleForTag para realizar operações relacionadas à herança de tags. Para obter mais informações, consulte Função vinculada ao service para Tag.

4. Clique em Enable and set rules.

5. Configure as regras de herança de tags.

   Para recursos que suportam herança de tags, especifique as chaves de tag a serem herdadas. Escolha herdar todas as chaves de tag ou apenas chaves específicas.

   Em Associated Resource Types, selecione ECS Instance Disks e, em seguida, selecione All Tag Keys nas opções expandidas abaixo.

6. Clique em OK.

Para obter mais informações sobre configurações de tags, consulte Herança de tags.

Erro: IdempotentParameterMismatch

• Sintoma: Você pode encontrar a seguinte mensagem de erro ao realizar operações como liberar um cluster ou atualizar uma configuração.

• Causa: O mesmo token de cliente foi usado em várias solicitações.

  The request uses the same client token as a previous, but non-identical request. Do not reuse a client token with different requests, unless the requests are identical.

• Solução: Verifique se a operação já está em andamento. Nesse caso, não a envie novamente. Caso contrário, atualize a página do console. O console do EMR gera automaticamente um novo token de cliente.

Erro: QuotaExceeded.PrivateIpAddress

• Sintoma: Você pode encontrar a seguinte mensagem de erro ao criar ou expandir um cluster.

  [QuotaExceeded.PrivateIpAddress] The specified VSwitch "vsw-xxxx" does not have enough IP addresses.

• Causa: O vSwitch selecionado não possui endereços IP privados disponíveis suficientes para atender à solicitação de criação ou expansão do cluster.

• Solução: Crie um novo grupo de nós e selecione um vSwitch que tenha um número suficiente de endereços IP disponíveis. Em seguida, tente novamente a operação de criação ou expansão do cluster.

Erro: LostProxy

• Sintoma: O erro "taihao-proxy disconnect" ocorre ao criar um cluster, expandir um cluster ou atualizar uma configuração de service.

• Causa: O agente de gerenciamento do EMR (proxy) em um nó do cluster perdeu sua conexão.

• Solução:

  1. Verifique o status do cluster e corrija problemas nos nós.

     • Se vários nós estiverem desconectados, verifique as métricas de cpu e memória.

       • Se a utilização de cpu ou memória estiver alta, o cluster está sobrecarregado. Atualize a configuração ou expanda o cluster para reduzir a pressão.

       • Se a utilização de cpu e memória estiver baixa, verifique a configuração do grupo de segurança para garantir que a comunicação de rede esteja normal.

     • Se apenas alguns nós estiverem desconectados, verifique a carga nesses nós para determinar se a utilização de cpu ou memória atingiu 100%. Se a carga estiver muito alta, verifique se há processos anormais consumindo recursos. Se encontrar algum, encerre-os e verifique se o status do nó retorna ao normal. Se nenhum processo anormal for encontrado, considere as seguintes soluções:

       • Para um nó mestre, investigue os processos com alto consumo de cpu. Atualize a especificação do nó mestre ou adicione nós MASTER-EXTEND para distribuir a carga.

       • Para um nó que não seja mestre, se uma única instância ECS estiver sobrecarregada ou não responder, descomissione o nó problemático ou adicione um novo nó.

         Faça logon no nó e execute o seguinte comando para reiniciar o service.

         service taihao-proxy restart

  3. Após concluir as verificações e operações, tente novamente criar o cluster, expandi-lo ou atualizar a configuração do service.

  Erro: "Insufficient account balance"

  • Sintoma: Você encontra a seguinte mensagem de erro ao criar, expandir ou atualizar um cluster.

    InvalidAccountStatus.NotEnoughBalance Message: Your account does not have enough balance to order pay-as-you-go products. 

  • Causa: Sua conta tem saldo insuficiente.

  • Solução: Verifique o saldo da sua conta e certifique-se de que seja suficiente para cobrir o custo dos recursos necessários. Após ter saldo suficiente, tente novamente a operação.

  Erro: QuotaExceed.DiskCapacity

  • Sintoma: Você pode encontrar a seguinte mensagem de erro ao expandir um cluster ou aumentar um disco.

    [QuotaExceed.DiskCapacity] The used capacity of disk type has exceeded the quota in the zone,  quota check fail.

  • Causa: A cota de disco da instância atingiu seu limite.

  • Solução: A capacidade utilizada do tipo de disco especificado excedeu a cota na zona de disponibilidade. Acesse o Quota Center para consultar e solicitar um aumento na sua cota de capacidade de disco.

  Erro: QuotaExceed.ElasticQuota

  • Sintoma: Você pode encontrar a seguinte mensagem de erro ao criar ou expandir um cluster.

    QuotaExceed.ElasticQuota Message: The number of the specified ECS instances has exceeded the quota of the specified instance type. 

  • Causa: A cota de instâncias ECS foi atingida.

  • Solução: Selecione um tipo de instância diferente ou reduza o número de instâncias e tente novamente. Você também pode solicitar um aumento de cota no console do ECS ou no Quota Center.

  Tratamento de falhas em ações de bootstrap

  Verifique o log de execução da ação de bootstrap com falha no histórico de operações:

  • Se o log contiver uma mensagem de erro clara, corrija o script de bootstrap com base na mensagem de erro e tente novamente a operação.

  • Se o log contiver a palavra-chave exitCode mas nenhum erro claro, adicione logs mais detalhados ao script de bootstrap para melhor depuração e, em seguida, tente novamente a operação.

  • Se a tarefa expirar ou não houver saída no log, verifique o seguinte:

    • Certifique-se de que o usuário tenha permissões de leitura no bucket do OSS onde o script de bootstrap está localizado.

    • Verifique a configuração de rede do ECS para garantir que ele possa acessar o endpoint interno do OSS e, em seguida, tente novamente a operação.