Konfigurer Amazon OpenSearch Service for høy tilgjengelighet | Amazon Web Services

Konfigurer Amazon OpenSearch Service for høy tilgjengelighet | Amazon Web Services

Tidsstempel: 31. mai 2023 12:56
Kilde node: 2691649

Amazon OpenSearch-tjeneste er en fullstendig åpen kildekode søke- og analysemotor som sikkert låser opp sanntidssøk, overvåking og analyse av forretnings- og driftsdata for brukstilfeller som anbefalingsmotorer, e-handelssider og katalogsøk. For å lykkes i virksomheten din trenger du at systemene dine er svært tilgjengelige og ytende, minimerer nedetid og unngår feil. Når du bruker OpenSearch Service som din primære måte å overvåke infrastrukturen på, må du også sikre at den er tilgjengelig. Nedetid for OpenSearch Service kan ha en betydelig effekt på bedriftens resultater, for eksempel tap av inntekter, tap i produktivitet, tap i merkevareverdi og mer.

De industristandard for måling av tilgjengelighet er klasse på ni. OpenSearch-tjenesten gir 3 9-er tilgjengelighet når du følger beste praksis, som betyr at den garanterer mindre enn 43.83 minutter med nedetid i måneden. I dette innlegget vil du lære hvordan du kan konfigurere OpenSearch Service-domenet ditt for høy tilgjengelighet og ytelse ved å følge beste praksis og anbefalinger mens du konfigurerer domenet ditt.

Det er to essensielle elementer som påvirker domenets tilgjengelighet: ressursutnyttelsen av domenet ditt, som hovedsakelig er drevet av arbeidsbelastningen din, og eksterne hendelser som infrastrukturfeil. Selv om førstnevnte kan kontrolleres gjennom kontinuerlig overvåking av domenets ytelse og helse og skalere domenet deretter, kan sistnevnte ikke. For å dempe virkningen av eksterne hendelser som et Availability Zone-avbrudd, forekomst eller diskfeil, eller nettverksproblemer på domenet ditt, må du sørge for ekstra kapasitet, fordelt over flere tilgjengelighetssoner, og beholde flere kopier av data. Unnlatelse av å gjøre det kan føre til redusert ytelse, utilgjengelighet og i verste fall tap av data.

La oss se på alternativene som er tilgjengelige for deg for å sikre at domenet er tilgjengelig og gir resultater.

Klynge -konfigurasjon

Under denne delen vil vi snakke om ulike konfigurasjonsalternativer du må konfigurere klyngen din på riktig måte, som inkluderer å spesifisere antall AZ for distribusjonen, sette opp master- og datanodene, sette opp indekser og shards.

Multi-AZ-distribusjon

Datanoder er ansvarlige for å behandle indeksering og søkeforespørsler på domenet ditt. Ved å distribuere datanodene dine på tvers av flere tilgjengelighetssoner forbedres tilgjengeligheten til domenet ditt ved å legge til redundant datalagring og behandling per sone. Med en Multi-AZ-distribusjon kan domenet ditt forbli tilgjengelig selv når en full tilgjengelighetssone blir utilgjengelig. For produksjonsarbeidsmengder, AWS anbefaler å bruke tre tilgjengelighetssoner for domenet ditt. Bruk to tilgjengelighetssoner for regioner som kun støtter to for forbedret tilgjengelighet. Dette sikrer at domenet ditt er tilgjengelig i tilfelle en Single-AZ-feil.

Dedikert cluster manager (master noder)

AWS anbefaler å bruke tre dedikerte cluster manager (CM) noder for alle produksjonsoppgaver. CM-noder sporer klyngens helse, tilstanden og plasseringen av dets indekser og shards, kartleggingen for alle indeksene, og tilgjengeligheten til datanodene, og den opprettholder en liste over klyngenivåoppgaver som er i gang. Uten dedikerte CM-noder, bruker klyngen datanoder, noe som gjør klyngen sårbar for krav om arbeidsbelastning. Du bør dimensjonere CM-noder basert på størrelsen på oppgaven – først og fremst datanodene, indekstellingene og shardtellingene. OpenSearch Service distribuerer alltid CM-noder på tvers av tre tilgjengelighetssoner, når det støttes av regionen (to i én tilgjengelighetssoner og én i andre tilgjengelighetssoner hvis regioner bare har to tilgjengelighetssoner). For et løpende domene fungerer bare én av de tre CM-nodene som en valgt leder. De to andre CM-nodene deltar i et valg hvis den valgte CM-noden mislykkes.

Følgende tabell viser AWS sine anbefalinger for CM-dimensjonering. CM-noder fungerer basert på antall noder, indekser, shards og kartlegging. Jo mer arbeid, desto mer data og minne trenger du for å holde og jobbe med klyngetilstanden.

Antall forekomster Cluster Manager Node RAM Størrelse Maksimalt støttet antall deler Anbefalt minimum dedikert Cluster Manager-forekomsttype
1-10 8 GiB 10,000 m5.stort.søk eller m6g.stort.søk
11-30 16 GiB 30,000 c5.2xlarge.search eller c6g.2xlarge.search
31-75 32 GiB 40,000 c5.4xlarge.search eller c6g.4xlarge.search
76 - 125 64 GiB 75,000 r5.2xlarge.search eller r6g.2xlarge.search
126 - 200 128 GiB 75,000 r5.4xlarge.search eller r6g.4xlarge.search

Indekser og skår

Indekser er en logisk konstruksjon som rommer en samling dokumenter. Du partisjonerer indeksen din for parallell behandling ved å spesifisere en primær shard-telling, der shards representerer en fysisk enhet for lagring og behandling av data. I OpenSearch Service kan et shard enten være et primært shard eller et replika shard. Du bruker replikaer for holdbarhet – hvis den primære shard går tapt, promoterer OpenSearch Service en av replikaene til primær – og for å forbedre søkegjennomstrømningen. OpenSearch-tjenesten sikrer at primær- og replika-shards plasseres i forskjellige noder og på tvers av forskjellige tilgjengelighetssoner, hvis de er distribuert i mer enn én tilgjengelighetssone. For høy tilgjengelighet anbefaler AWS å konfigurere minst to replikaer for hver indeks i et tre-sones oppsett for å unngå forstyrrelser i ytelse og tilgjengelighet. I et Multi-AZ-oppsett, hvis en node svikter eller i det sjeldne verste tilfellet en Availability Zone mislykkes, vil du fortsatt ha en kopi av dataene.

Klyngeovervåking og ledelse

Som diskutert tidligere, er det bare halve jobben å velge konfigurasjonen din basert på beste praksis. Vi må også kontinuerlig overvåke ressursutnyttelsen og ytelsen for å finne ut om domenet må skaleres. Et undertilordnet eller overutnyttet domene kan føre til ytelsesforringelse og til slutt utilgjengelighet.

CPU utnyttelse

Du bruker CPU-en i domenet ditt til å kjøre arbeidsmengden. Som en generell regel bør du målrette 60 % gjennomsnittlig CPU-utnyttelse for enhver datanode, med topper på 80 %, og tolerere små topper til 100 %. Når du vurderer tilgjengelighet, og spesielt med tanke på utilgjengeligheten til en full sone, er det to scenarier. Hvis du har to tilgjengelighetssoner, håndterer hver sone 50 % av trafikken. Hvis en sone blir utilgjengelig, vil den andre sonen ta all denne trafikken, noe som dobler CPU-utnyttelsen. I så fall må du ligge på rundt 30–40 % gjennomsnittlig CPU-utnyttelse i hver sone for å opprettholde tilgjengeligheten. Hvis du kjører tre tilgjengelighetssoner, tar hver sone 33 % av trafikken. Hvis en sone blir utilgjengelig, vil hver andre sone få omtrent 17 % trafikk. I dette tilfellet bør du målrette 50–60 % gjennomsnittlig CPU-utnyttelse.

Minnebruk

OpenSearch Service støtter to typer søppelinnsamling. Den første er G1 søppelinnsamling (G1GC), som brukes av OpenSearch Service-noder, drevet av AWS Graviton 2. Den andre er Concurrent Mark Sweep (CMS), som brukes av alle noder som drives av andre prosessorer. Av alt minnet som er allokert til en node, er halvparten av minnet (opptil 32 GB) tilordnet Java-haugen, og resten av minnet brukes av andre operativsystemoppgaver, filsystembufferen og så videre. For å opprettholde tilgjengeligheten for et domene anbefaler vi å holde den maksimale JVM-utnyttelsen på rundt 80 % i CMS og 95 % i G1GC. Alt utover det vil påvirke tilgjengeligheten til domenet ditt og gjøre klyngen din usunn. Vi anbefaler også å aktivere auto-tune, som aktivt overvåker minneutnyttelsen og utløser søppeloppsamleren.

Lagringsutnyttelse

OpenSearch Service publiserer flere retningslinjer for dimensjonering av domener. Vi gir en empirisk formel slik at du kan bestemme den riktige mengden lagring som kreves for dine behov. Det er imidlertid viktig å holde øye med uttømming av lagring med tiden og endringer i arbeidsbelastningskarakteristikker. For å sikre at domenet ikke går tom for lagring og kan fortsette å indeksere data, bør du konfigurere Amazon CloudWatch alarmer og overvåk din ledige lagringsplass.

AWS anbefaler også å velge et primært shardtall slik at hvert shard er innenfor et optimalt størrelsesbånd. Du kan bestemme den optimale shard-størrelsen gjennom proof-of-concept-testing med data og trafikk. Vi bruker 10–30 GB primære shard-størrelser for brukstilfeller for søk og 45–50 GB primære shard-størrelser for brukstilfeller for logganalyse som en retningslinje. Fordi shards er arbeiderne i domenet ditt, er de direkte ansvarlige for fordelingen av arbeidsmengden på tvers av datanodene. Hvis skårene dine er for store, kan du oppleve stress i Java-haugen din fra store aggregeringer, dårligere søkeytelse og dårligere ytelse på klyngenivåoppgaver som rebalansering av skjær, øyeblikksbilder og migreringer fra varme til varme. Hvis skårene dine er for små, kan de overvelde domenets Java-haugplass, forverre søkeytelsen gjennom overdreven intern nettverksbygging og gjøre oppgaver på klyngenivå trege. Vi anbefaler også å holde antallet shards per node proporsjonalt med heapen som er tilgjengelig (halvparten av forekomstens RAM opptil 32 GB) – 25 shards per GB Java-heap. Dette gir en praktisk grense på 1,000 shards på enhver datanode i domenet ditt.

konklusjonen

I dette innlegget lærte du ulike tips og triks for å sette opp et svært tilgjengelig domene ved hjelp av OpenSearch Service, som hjelper deg med å holde OpenSearch Service presterende og tilgjengelig ved å kjøre den på tvers av tre tilgjengelighetssoner.

Følg med for en rekke innlegg som fokuserer på de ulike funksjonene og funksjonene med OpenSearch Service. Hvis du har tilbakemeldinger om dette innlegget, send det inn i kommentarfeltet. Hvis du har spørsmål om dette innlegget, start en ny tråd på OpenSearch Service-forum eller kontakt AWS-støtte.

Om forfatterne

Rohin Bhargava er senior produktsjef med Amazon OpenSearch Service-teamet. Hans lidenskap hos AWS er ​​å hjelpe kunder med å finne den riktige blandingen av AWS-tjenester for å oppnå suksess for sine forretningsmål.

Prashant Agrawal er en seniorsøkespesialist løsningsarkitekt med Amazon OpenSearch Service. Han jobber tett med kunder for å hjelpe dem med å migrere arbeidsmengdene til skyen og hjelper eksisterende kunder med å finjustere klynger for å oppnå bedre ytelse og spare kostnader. Før han begynte i AWS, hjalp han ulike kunder med å bruke OpenSearch og Elasticsearch for deres søk og logganalysebruk. Når du ikke jobber, kan du finne ham på reise og utforske nye steder. Kort sagt, han liker å gjøre Eat → Travel → Repeat.

Tidstempel:

Mer fra AWS Big Data