Por que meu nó do OpenSearch Service travou?

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.

As causas comuns de nós de cluster com falha incluem:

• 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.    Faça login no console do OpenSearch Service.

2.    No painel de navegação, em Clusters gerenciados (Managed clusters), escolha Domains (Domínios).

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

4.    Escolha a guia Cluster health (Integridade do cluster) e, em seguida, a métrica Nodes (Nós). Se o número de nós for menor que o número configurado para o cluster, então 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 pelas seguintes condições:

• A quantidade de dados no cluster em relação ao número de recursos.
• A carga de consulta no cluster.

À medida que a pressão da memória da JVM aumenta, acontece o seguinte:

• Em 75%: o OpenSearch Service inicia 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 Monitorando métricas de cluster do OpenSearch 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 Escolhendo 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 a documentação do Elasticsearch referente a fielddata.
• Se precisar agregar em campos de texto, altere o tipo de mapeamento para keyword (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, considere estes fatores:

• 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 Criação de snapshots de índices no Amazon OpenSearch Service. Além disso, não é possível recuperar dados que não foram capturados no último snapshot. Para obter mais informações, consulte Dimensionamento de domínios do Amazon OpenSearch Service e Criação e gerenciamento de domínios do Amazon OpenSearch Service.
• Certifique-se de ter pelo menos uma réplica. Um cluster de vários nós ainda pode ter perda de dados se não houver fragmentos de réplica.
• Ative o reconhecimento de zonas. Quando o reconhecimento de zonas está ativado, o OpenSearch Service inicia nós de dados em várias zonas de disponibilidade. O OpenSearch Service tenta distribuir fragmentos primários e seus fragmentos de réplica correspondentes para diferentes zonas de disponibilidade. Se houver falha em um nó ou em uma zona, seus dados ainda estarão disponíveis. Para obter mais informações, consulte Configuração de um domínio Multi-AZ no Amazon OpenSearch Service.

---

Informações relacionadas

Práticas operacionais recomendadas para o Amazon OpenSearch Service

Como torno meu domínio do Amazon OpenSearch Service mais tolerante a falhas?

Como posso aumentar a escala verticalmente ou horizontalmente de um domínio do Amazon OpenSearch Service?

Por que meu domínio do Amazon OpenSearch Service não sai do estado “Processing” (Processando)?