Perché il mio nodo Amazon OpenSearch Service si è arrestato in modo anomalo?

Ultimo aggiornamento: 30/07/2021

Uno dei nodi del mio cluster Amazon OpenSearch Service (successore di Amazon Elasticsearch Service) è inattivo. Perché il nodo si è arrestato e come posso evitare che ciò si ripeta?

Breve descrizione

Ciascun nodo di OpenSearch Service viene eseguito su un'istanza Amazon Elastic Compute Cloud (Amazon EC2) separata. Un nodo arrestato è un'istanza che non risponde ai segnali di heartbeat provenienti dagli altri nodi. I segnali di heartbeat sono segnali periodici che monitorano la disponibilità dei nodi di dati nel cluster.

Di seguito sono elencate le cause più comuni dell'arresto dei nodi di cluster:

  • Alta pressione sulla memoria della Java Virtual Machine (JVM)
  • Guasto dell'hardware

Risoluzione

Controllo della presenza di nodi arrestati

1.    Apri la console di OpenSearch Service.

2.    Scegli il nome del tuo dominio OpenSearch Service.

3.    Scegli la scheda Cluster health (Integrità del cluster), quindi scegli il parametro Nodes (Nodi). Se il numero di nodi è inferiore al numero configurato per il cluster, ciò significa che un nodo è inattivo.

Nota: il parametro Nodes (Nodi) può essere impreciso durante le modifiche alla configurazione del cluster o qualsiasi intervento di manutenzione ordinaria del servizio. Si tratta di un comportamento normale.

Identificazione e risoluzione dei problemi relativi all'alta pressione sulla memoria della JVM

La pressione sulla memoria della JVM si riferisce alla percentuale di heap Java usata per tutti i nodi di dati in un cluster di OpenSearch Service. L'alta pressione sulla memoria della JVM può causare un utilizzo della CPU elevato e altri problemi relativi alle prestazioni del cluster.

La pressione sulla memoria della JVM è determinata dai seguenti fattori:

  • La quantità di dati sul cluster in proporzione alla quantità di risorse.
  • Il carico di query sul cluster.

Ecco cosa succede quando la pressione sulla memoria della JVM aumenta:

  • Al 75%: OpenSearch Service attiva il garbage collector Concurrent Mark Sweep (CMS). Il collector CMS viene eseguito insieme ad altri processi per ridurre al minimo le pause e le interruzioni. Nota: OpenSearch Service pubblica diversi parametri di garbage collection su Amazon CloudWatch. Questi parametri possono aiutare a monitorare l'utilizzo della memoria della JVM. Per ulteriori informazioni, consulta Monitoraggio dei parametri del cluster con Amazon CloudWatch.
  • Sopra il 75%: se il collector CMS non riesce a recuperare memoria sufficiente e l'utilizzo rimane superiore al 75%, la JVM di OpenSearch Service tenta di liberare memoria. La JVM di OpenSearch Service tenta inoltre di impedire un'eccezione JVM OutOfMemoryError (OOM) rallentando o arrestando i processi.
  • Se la JVM continua ad aumentare e lo spazio non viene recuperato, la JVM di OpenSearch Service interromperà i processi che tentano di allocare memoria. Se un processo critico viene arrestato, uno o più nodi del cluster potrebbero non subire un arresto. La best practice è mantenere l'utilizzo della CPU al di sotto dell'80%.

Per evitare l'alta pressione sulla memoria della JVM, si consiglia di attenersi alle seguenti best practice:

  • Evitare le query su intervalli ampi, ad esempio le query con metacaratteri.
  • Evitare di inviare un numero di richieste elevato contemporaneamente.
  • Assicurasi di avere il numero adeguato di partizioni. Per ulteriori informazioni sulla strategia di indicizzazione, consultare Scelta del numero di partizioni.
  • Assicurarsi che le partizioni siano distribuite uniformemente tra i nodi.
  • Evitare l'aggregazione sui campi di testo. Ciò aiuta a prevenire l'aumento dei dati del campo. Maggiore è il numero di dati del campo a disposizione, maggiore è lo spazio di heap consumato. Usare l'operazione API GET _cluster/stats per controllare i dati del campo. Per ulteriori informazioni, consulta fielddata sul sito Web di Elasticsearch.
  • Se è necessario eseguire l'aggregazione sui campi di testo, modificare il tipo di mappatura in keyword. Se la pressione sulla memoria della JVM diventa troppo alta, usare le seguenti operazioni API per cancellare la cache dei dati del campo: POST /index_name/_cache/clear (cache a livello di indice) e POST */_cache/clear (cache a livello di cluster).
    Nota: la cancellazione della cache può interrompere le query in corso.

Identificazione e risoluzione dei problemi relativi ai guasti hardware

A volte i guasti hardware possono influire sulla disponibilità dei nodi del cluster. Per limitare l'impatto di potenziali guasti hardware, controlla quanto segue:

  • Assicurati di avere più di un nodo nel cluster. Un cluster a nodo singolo è un singolo punto di errore. Non è possibile usare le partizioni replicate per eseguire il backup dei dati, perché le partizioni principali e replicate non possono essere assegnate allo stesso nodo. Se il nodo diventa inattivo, è possibile ripristinare i dati da uno snapshot. Per ulteriori informazioni sulle istantanee, consulta Creazione di snapshot di indice in Amazon OpenSearch Service. Tieni presente che non è possibile recuperare i dati che non erano già stati acquisiti nell'ultimo snapshot. Per ulteriori informazioni, consulta Dimensionamento dei domini Amazon OpenSearch Service e Creazione e gestione di domini Amazon OpenSearch Service.
  • Assicurati di avere almeno una replica. Un cluster a più nodi può comunque subire una perdita di dati se non sono presenti partizioni replicate.
  • Abilita l'opzione di zone awareness. Quando l'opzione di zone awareness è abilitata, OpenSearch Service avvia nodi di dati in più zone di disponibilità. OpenSearch Services tenta di distribuire le partizioni principali e le corrispondenti partizioni replicate in zone diverse. Se si verifica un errore in un nodo o in una zona di disponibilità, i dati sono ancora disponibili. Per ulteriori informazioni, consulta Configurazione di un dominio multi-AZ.