E-MapReduce:Cluster management FAQ

Posso atualizar um cluster EMR?

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

Quais serviços os clusters EMR suportam?

Os serviços suportados variam conforme o tipo e a versão do cluster. Para obter mais informações, consulte Versões de lançamento.

Posso adicionar o Zeppelin no console?

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

O EMR suporta Oozie e suas alternativas?

O componente Oozie não está incluído nos clusters DataLake do EMR que executam EMR V5.8.0 ou posterior, ou EMR V3.42.0 ou posterior. Se você precisar de um serviço de agendamento de fluxo de trabalho, use 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 do que uma 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 em hosts físicos diferentes 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 aplicativos 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 levam a uma falha de 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 ECS. Após a liberação de todas as instâncias, o cluster 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 serviços a um cluster existente

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

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

Alterações de configuração no lado do servidor para serviços como Spark, Hive e HDFS só entram em vigor após a reinicialização dos serviços. Alterações nas configurações do lado do cliente entram em vigor após clicar em Deploy Client Configuration, sem necessidade de reiniciar o serviço. 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 contínua?

O mecanismo de reinicialização contínua reinicia as instâncias ECS uma por uma. A próxima instância só é reiniciada depois que a atual e todos os seus serviços 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 sã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 escalar horizontalmente 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.

Posso 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 para o grupo de nós alvo a fim de expandir seus discos de dados. Para instruções específicas, consulte Expandir um disco.

Expansão e redução de cluster

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 escalar horizontalmente, certifique-se de que todos os pedidos relacionados estejam pagos. Um pedido não pago causará falha na operação de expansão. Para instruções específicas, consulte Escalar horizontalmente 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 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 escalar horizontalmente um cluster.

• Causa: Esse erro indica que o recurso de conjunto de implantação está ativado para 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 serviço?

Se não desejar que o EMR colete seus dados, desative a coleta de logs operacionais de serviço.

Procedimento:

1. Desative a coleta de logs operacionais de serviço.

   • 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 serviço está desativada.

   Nota

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

Quais informações os logs operacionais de serviço coletam?

Os logs operacionais de serviço incluem apenas logs dos componentes de serviço em execução no cluster. Ative ou desative a coleta de todos os logs de serviço 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 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

Instalar ou atualizar o EMR Doctor não reinicia nenhum serviço 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 serviços 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 serviços.

Quais dados o EMR Doctor coleta?

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

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 usados 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 tornar-se 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, deverá esperar até o terceiro dia para ver 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 usa 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 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 escalar horizontalmente novamente, ou escale 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 serviços desnecessários?

Não é possível excluir serviços existentes de um cluster. Uma vez iniciado, um serviço 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 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 a 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.

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

• Sintoma: Perda frequente de pacotes de rede ocorre no cluster, e os logs do sistema podem mostrar 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 excede 1.000 servidores e executa uma versão anterior ao EMR-5.18.0 ou EMR-3.52.0 (exclusivo), você pode encontrar instabilidade de rede e perda de pacotes. Otimize o gerenciamento do cache ARP ajustando parâmetros do sistema.

  O cache ARP armazena mapeamentos entre endereços IP e endereços MAC. Os parâmetros principais 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 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, escale horizontalmente para adicionar um novo nó. Para obter mais informações, consulte Escalar horizontalmente 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, envie 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 do cluster aos discos em nuvem

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

Procedimento:

1. Faça logon no console Tag.

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 serviço.

   Ao ativar a herança de tags, o sistema cria automaticamente uma função vinculada ao serviço chamada AliyunServiceRoleForTag para realizar operações relacionadas à herança de tags. Para obter mais informações, consulte Função vinculada ao serviço 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.

   

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 sua operação já está em andamento. Em caso afirmativo, não a envie novamente. Caso contrário, atualize a página do console. O console EMR gera automaticamente um novo token de cliente.

Erro: QuotaExceeded.PrivateIpAddress

• Sintoma: Você pode encontrar a seguinte mensagem de erro ao criar ou escalar horizontalmente 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, escalar horizontalmente um cluster ou atualizar uma configuração de serviço.

• 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 escale horizontalmente 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, procure processos anormais que estejam 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ó não 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 serviço.

         service taihao-proxy restart

  2. Após concluir as verificações e operações, tente novamente criar o cluster, escalá-lo horizontalmente ou atualizar a configuração do serviço.

Erro: "Insufficient account balance"

• Sintoma: Você encontra a seguinte mensagem de erro ao criar, escalar horizontalmente 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. Assim que seu saldo for suficiente, tente novamente a operação.

Erro: QuotaExceed.DiskCapacity

• Sintoma: Você pode encontrar a seguinte mensagem de erro ao escalar horizontalmente um cluster ou expandir 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 usada 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 escalar horizontalmente 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. Também é possível solicitar um aumento de cota no console 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 atingir o tempo limite 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 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.

Erro de inicialização do SparkContext no Gateway EMR