Por que meu nó do Amazon OpenSearch Service travou?

Última atualização: 30-07-2021

Um dos nós no meu cluster do Amazon OpenSearch Service (sucessor do Amazon Elasticsearch Service) está inativo. Por que o nó falhou e como posso evitar que isso aconteça novamente?

Breve descrição

Cada nó do OpenSearch Service é executado em uma instância separada do Amazon Elastic Compute Cloud (Amazon EC2). Um nó com falha é uma instância que não está respondendo aos sinais de pulsação dos outros nós. Sinais de pulsação são sinais periódicos que monitoram a disponibilidade dos nós de dados no cluster.

Aqui estão as causas comuns de nós de cluster com falha:

  • Alta pressão de memória da Máquina Virtual Java (JVM)
  • Falha de hardware

Resolução

Confira se há nós com falha

1.    Abra oconsole do OpenSearch Service.

2.    Escolha o nome do domínio do OpenSearch Service.

3.    Escolha a guia Integridade do cluster e, em seguida, a métrica Nós. Se o número de nós for menor que o número configurado para o cluster, isso indica que um nó está inativo.

Observação: a métrica Nós pode ser imprecisa durante alterações na configuração do cluster ou qualquer manutenção de rotina para o serviço. Esse comportamento é esperado.

Identificar e solucionar problemas de alta pressão de memória da JVM

A pressão de memória da JVM de refere à porcentagem de heap de Java usada para todos os nós de dados em um cluster do OpenSearch Service. A alta pressão de memória da JVM pode causar alto uso da CPU e outros problemas de performance do cluster.

A pressão de memória da JVM é determinada pelos seguintes fatores:

  • A quantidade de dados no cluster em relação à quantidade de recursos.
  • A carga de consulta no cluster.

Veja o que acontece à medida que a pressão de memória da JVM aumenta:

  • Em 75%: o OpenSearch Service aciona o coletor de resíduos Concurrent Mark Sweep (CMS). O coletor CMS é executado com outros processos para manter o mínimo de pausas e interrupções. Observação: o OpenSearch Service publica várias métricas de coleta de resíduos no Amazon CloudWatch. Essas métricas podem ajudar a monitorar o uso de memória da JVM. Para obter mais informações, consulte Monitorar métricas de cluster com o Amazon CloudWatch.
  • Acima de 75%: se o coletor CMS não conseguir recuperar memória suficiente e o uso permanecer acima de 75%, a JVM do OpenSearch Service tentará liberar memória. A JVM do OpenSearch Service também tentará impedir uma exceção JVM OutOfMemoryError (OOM), retardando ou interrompendo os processos.
  • Se a JVM continuar crescendo e o espaço não for recuperado, a JVM do OpenSearch Service interromperá os processos que tentam alocar memória. Se um processo crítico for interrompido, um ou mais nós do cluster poderão falhar. É uma melhor prática manter o uso da CPU abaixo de 80%.

Para evitar uma alta pressão de memória da JVM, siga estas melhores práticas:

  • Evite consultas em intervalos amplos, como consultas curinga.
  • Evite enviar um grande número de solicitações ao mesmo tempo.
  • Certifique-se de ter o número apropriado de fragmentos. Para obter mais informações sobre a estratégia de indexação, consulte Escolher o número de fragmentos.
  • Certifique-se de que os fragmentos sejam distribuídos uniformemente entre os nós.
  • Evite agregar em campos de texto. Isso ajuda a evitar aumentos nos dados de campo. Quanto mais dados de campo tiver, mais espaço de heap será consumido. Use a operação de API GET _cluster/stats para conferir os dados de campo. Para obter mais informações, consulte Fielddata no site do Elasticsearch.
  • Se precisar agregar em campos de texto, altere o tipo de mapeamento para palavra-chave. Se a pressão de memória da JVM ficar muito alta, use as seguintes operações de API para limpar o cache de dados de campo: POST /index_name/_cache/clear (cache de nível de índice) e POST */_cache/clear (cache de nível de cluster).
    Observação: limpar o cache pode interromper as consultas que estão em andamento.

Identificar e solucionar problemas de falha de hardware

Às vezes, falhas de hardware podem afetar a disponibilidade de um nó do cluster. Para limitar o impacto de possíveis falhas de hardware, confira o seguinte:

  • Certifique-se de que haja mais de um nó no cluster. Um cluster de nó único é um único ponto de falha. Não é possível usar fragmentos de réplica para fazer backup de dados, porque os fragmentos primários e de réplica não podem ser atribuídos ao mesmo nó. Se o nó ficar inativo, é possível restaurar dados de um snapshot. Para obter mais informações sobre snapshots, consulte Criar snapshots de índice no Amazon OpenSearch Service. Não é possível recuperar dados que não foram capturados no último snapshot. Para obter mais informações, consulte Dimensionar domínios do OpenSearch Service e Criar e gerenciar domínios do OpenSearch Service.
  • Certifique-se de ter pelo menos uma réplica. Um cluster de vários nós ainda pode sofrer perda de dados se não houver fragmentos de réplica.
  • Habilite o reconhecimento de zona. Quando o reconhecimento de zona está ativado, o OpenSearch Service inicia nós de dados em várias zonas de disponibilidade. O OpenSearch Services tenta distribuir fragmentos primários e seus fragmentos de réplica correspondentes para diferentes zonas. Se houver falha em um nó ou uma zona de disponibilidade, seus dados ainda estarão disponíveis. Para obter mais informações, consulte Configurar um domínio multi-AZ.