Configurare Amazon OpenSearch Service per l'alta disponibilità | Servizi Web Amazon

Configurare Amazon OpenSearch Service per l'alta disponibilità | Servizi Web Amazon

Timestamp: 31 maggio 2023 12:56
Nodo di origine: 2691649

Servizio Amazon OpenSearch è un motore di ricerca e analisi completamente open source che sblocca in modo sicuro la ricerca, il monitoraggio e l'analisi in tempo reale dei dati aziendali e operativi per casi d'uso come motori di raccomandazione, siti di e-commerce e ricerca nel catalogo. Per avere successo nella tua azienda, hai bisogno che i tuoi sistemi siano altamente disponibili e performanti, riducendo al minimo i tempi di inattività ed evitando guasti. Quando utilizzi OpenSearch Service come mezzo principale per monitorare la tua infrastruttura, devi assicurarne anche la disponibilità. I tempi di inattività per OpenSearch Service possono avere un effetto significativo sui risultati aziendali, come perdita di entrate, perdita di produttività, perdita di valore del marchio e altro ancora.

Il standard di settore per la misurazione della disponibilità è la classe dei nove. Il servizio OpenSearch fornisce 3 9 di disponibilità, quando segui best practice, il che significa che garantisce meno di 43.83 minuti di downtime al mese. In questo post imparerai come configurare il tuo dominio del servizio OpenSearch per disponibilità e prestazioni elevate seguendo le best practice e i consigli durante la configurazione del tuo dominio.

Esistono due elementi essenziali che influenzano la disponibilità del tuo dominio: l'utilizzo delle risorse del tuo dominio, che è guidato principalmente dal tuo carico di lavoro, ed eventi esterni come i guasti dell'infrastruttura. Sebbene il primo possa essere controllato attraverso il monitoraggio continuo delle prestazioni e dell'integrità del dominio e ridimensionando il dominio di conseguenza, il secondo non può. Per mitigare l'impatto di eventi esterni come un'interruzione della zona di disponibilità, un errore dell'istanza o del disco o problemi di rete sul tuo dominio, devi eseguire il provisioning di capacità aggiuntiva, distribuirla su più zone di disponibilità e conservare più copie dei dati. In caso contrario, potrebbero verificarsi prestazioni ridotte, indisponibilità e, nel peggiore dei casi, perdita di dati.

Diamo un'occhiata alle opzioni a tua disposizione per assicurarti che il dominio sia disponibile e performante.

Configurazione del cluster

In questa sezione parleremo delle varie opzioni di configurazione necessarie per impostare correttamente il cluster, che include la specifica del numero di zone di disponibilità per la distribuzione, l'impostazione dei nodi master e dati, l'impostazione di indici e shard.

Distribuzione Multi-AZ

I nodi dati sono responsabili dell'elaborazione dell'indicizzazione e delle richieste di ricerca nel tuo dominio. La distribuzione dei tuoi nodi di dati su più zone di disponibilità migliora la disponibilità del tuo dominio aggiungendo l'archiviazione e l'elaborazione dei dati ridondanti per zona. Con un'implementazione Multi-AZ, il tuo dominio può rimanere disponibile anche quando un'intera zona di disponibilità diventa non disponibile. Per i carichi di lavoro di produzione, AWS consiglia di utilizzare tre zone di disponibilità per il tuo dominio. Utilizza due zone di disponibilità per le regioni che ne supportano solo due per una migliore disponibilità. Ciò garantisce che il tuo dominio sia disponibile in caso di errore Single-AZ.

Gestore cluster dedicato (nodi master)

AWS consiglia di utilizzare tre nodi cluster manager (CM) dedicati per tutti i carichi di lavoro di produzione. I nodi CM monitorano l'integrità del cluster, lo stato e la posizione dei suoi indici e shard, la mappatura per tutti gli indici e la disponibilità dei suoi nodi di dati e mantiene un elenco di attività a livello di cluster in corso. Senza nodi CM dedicati, il cluster utilizza nodi di dati, il che rende il cluster vulnerabile alle richieste del carico di lavoro. È necessario dimensionare i nodi CM in base alle dimensioni dell'attività, in primo luogo, i conteggi dei nodi di dati, i conteggi degli indici e i conteggi degli shard. Il servizio OpenSearch distribuisce sempre i nodi CM in tre zone di disponibilità, se supportato dalla regione (due in una zona di disponibilità e uno in altre zone di disponibilità se le regioni hanno solo due zone di disponibilità). Per un dominio in esecuzione, solo uno dei tre nodi CM funziona come leader eletto. Gli altri due nodi CM partecipano a un'elezione se il nodo CM eletto fallisce.

La tabella seguente mostra le raccomandazioni di AWS per il dimensionamento CM. I nodi CM funzionano in base al numero di nodi, indici, frammenti e mappatura. Maggiore è il lavoro, maggiore è il calcolo e la memoria necessari per conservare e lavorare con lo stato del cluster.

Conteggio istanze Dimensione RAM nodo Gestione cluster Numero massimo di shard supportati Tipo minimo consigliato di istanza di Cluster Manager dedicato
1-10 8 GiB 10,000 m5.large.search o m6g.large.search
11-30 16 GiB 30,000 c5.2xlarge.search o c6g.2xlarge.search
31-75 32 GiB 40,000 c5.4xlarge.search o c6g.4xlarge.search
76 - 125 64 GiB 75,000 r5.2xlarge.search o r6g.2xlarge.search
126 - 200 128 GiB 75,000 r5.4xlarge.search o r6g.4xlarge.search

Indici e frammenti

Gli indici sono un costrutto logico che ospita una raccolta di documenti. Partiziona l'indice per l'elaborazione parallela specificando un numero di shard primari, in cui gli shard rappresentano un'unità fisica per l'archiviazione e l'elaborazione dei dati. In OpenSearch Service, uno shard può essere uno shard primario o uno shard di replica. Le repliche vengono utilizzate per la durabilità (se lo shard primario viene perso, OpenSearch Service promuove una delle repliche a primario) e per migliorare il throughput della ricerca. Il servizio OpenSearch garantisce che gli shard primari e di replica siano collocati in nodi diversi e in diverse zone di disponibilità, se distribuiti in più di una zona di disponibilità. Per l'alta disponibilità, AWS consiglia di configurare almeno due repliche per ogni indice in una configurazione a tre zone per evitare interruzioni delle prestazioni e della disponibilità. In una configurazione Multi-AZ, se un nodo si guasta o, nel raro caso peggiore, una zona di disponibilità fallisce, avrai comunque una copia dei dati.

Monitoraggio e gestione dei cluster

Come discusso in precedenza, selezionare la configurazione in base alle best practice è solo metà del lavoro. Dobbiamo anche monitorare continuamente l'utilizzo e le prestazioni delle risorse per determinare se il dominio deve essere ridimensionato. Un dominio con provisioning insufficiente o utilizzo eccessivo può comportare un degrado delle prestazioni e infine l'indisponibilità.

Utilizzo della CPU

Utilizzi la CPU nel tuo dominio per eseguire il tuo carico di lavoro. Come regola generale, dovresti raggiungere un utilizzo medio della CPU del 60% per qualsiasi nodo di dati, con picchi all'80% e tollerare piccoli picchi fino al 100%. Quando si considera la disponibilità, e soprattutto considerando l'indisponibilità di una zona completa, ci sono due scenari. Se hai due zone di disponibilità, ogni zona gestisce il 50% del traffico. Se una zona diventa non disponibile, l'altra zona prenderà tutto quel traffico, raddoppiando l'utilizzo della CPU. In tal caso, è necessario avere un utilizzo medio della CPU di circa il 30-40% in ciascuna zona per mantenere la disponibilità. Se stai eseguendo tre zone di disponibilità, ciascuna zona assorbe il 33% del traffico. Se una zona diventa non disponibile, ogni altra zona guadagnerà circa il 17% di traffico. In questo caso, dovresti scegliere come target un utilizzo medio della CPU del 50-60%.

Utilizzo della memoria

OpenSearch Service supporta due tipi di Garbage Collection. Il primo è G1 Garbage Collection (G1GC), utilizzato dai nodi OpenSearch Service, alimentato da AWS Gravitone 2. Il secondo è Concurrent Mark Sweep (CMS), utilizzato da tutti i nodi alimentati da altri processori. Di tutta la memoria allocata a un nodo, metà della memoria (fino a 32 GB) viene assegnata all'heap Java e il resto della memoria viene utilizzato da altre attività del sistema operativo, dalla cache del file system e così via. Per mantenere la disponibilità per un dominio, consigliamo di mantenere l'utilizzo massimo di JVM a circa l'80% in CMS e al 95% in G1GC. Qualunque cosa al di là di ciò influirebbe sulla disponibilità del tuo dominio e renderebbe il tuo cluster non integro. Si consiglia inoltre di abilitare l'ottimizzazione automatica, che monitora attivamente l'utilizzo della memoria e attiva il Garbage Collector.

Utilizzo dello spazio di archiviazione

OpenSearch Service pubblica diverse linee guida per dimensionamento dei domini. Forniamo una formula empirica in modo che tu possa determinare la giusta quantità di spazio di archiviazione richiesto per le tue esigenze. Tuttavia, è importante tenere d'occhio l'esaurimento dello spazio di archiviazione nel tempo e i cambiamenti nelle caratteristiche del carico di lavoro. Per garantire che il dominio non esaurisca lo spazio di archiviazione e possa continuare a indicizzare i dati, è necessario configurare Amazon Cloud Watch allarmi e monitorare lo spazio di archiviazione libero.

AWS consiglia inoltre di scegliere un numero di shard primari in modo che ogni shard rientri in una fascia di dimensioni ottimale. Puoi determinare la dimensione ottimale dello shard attraverso test di prova con i tuoi dati e il tuo traffico. Usiamo dimensioni di shard primari da 10 a 30 GB per i casi d'uso di ricerca e dimensioni di shard primari da 45 a 50 GB per i casi d'uso di analisi dei log come linea guida. Poiché gli shard sono i lavoratori nel tuo dominio, sono direttamente responsabili della distribuzione del carico di lavoro tra i nodi di dati. Se i tuoi shard sono troppo grandi, potresti notare stress nel tuo heap Java a causa di grandi aggregazioni, prestazioni di query peggiori e prestazioni peggiori su attività a livello di cluster come ribilanciamento di shard, snapshot e migrazioni hot-to-warm. Se i tuoi shard sono troppo piccoli, possono sovraccaricare lo spazio dell'heap Java del dominio, peggiorare le prestazioni delle query a causa di un'eccessiva rete interna e rallentare le attività a livello di cluster. Consigliamo inoltre di mantenere il numero di shard per nodo proporzionale all'heap disponibile (metà della RAM dell'istanza fino a 32 GB): 25 shard per GB di heap Java. Questo rende un limite pratico di 1,000 shard su qualsiasi nodo di dati nel tuo dominio.

Conclusione

In questo post, hai appreso vari suggerimenti e trucchi per configurare un dominio a disponibilità elevata utilizzando OpenSearch Service, che ti aiuta a mantenere OpenSearch Service efficiente e disponibile eseguendolo su tre zone di disponibilità.

Resta sintonizzato per una serie di post incentrati sulle varie caratteristiche e funzionalità con OpenSearch Service. Se hai un feedback su questo post, invialo nella sezione commenti. Se hai domande su questo post, apri una nuova discussione sul Forum del servizio OpenSearch o contattare Supporto AWS.

Circa gli autori

Rohin Bhargava è un Sr. Product Manager con il team di Amazon OpenSearch Service. La sua passione in AWS è aiutare i clienti a trovare il giusto mix di servizi AWS per raggiungere il successo per i loro obiettivi di business.

Prashant Agrawal è Senior Search Specialist Solutions Architect con Amazon OpenSearch Service. Lavora a stretto contatto con i clienti per aiutarli a migrare i loro carichi di lavoro nel cloud e aiuta i clienti esistenti a mettere a punto i loro cluster per ottenere prestazioni migliori e risparmiare sui costi. Prima di entrare in AWS, ha aiutato vari clienti a utilizzare OpenSearch ed Elasticsearch per i loro casi d'uso di ricerca e analisi dei log. Quando non lavora, puoi trovarlo in viaggio ed esplorare nuovi posti. Insomma, gli piace fare Mangia → Viaggia → Ripeti.

Timestamp:

Di più da Big Data di AWS