Konfigurer Amazon OpenSearch Service for høj tilgængelighed | Amazon Web Services

Konfigurer Amazon OpenSearch Service for høj tilgængelighed | Amazon Web Services

Tidsstempel: 31. maj 2023 kl. 12
Kildeknude: 2691649

Amazon OpenSearch Service er en fuldt open source søge- og analysemaskine, der sikkert låser op for realtidssøgning, overvågning og analyse af forretnings- og driftsdata til brugssager som anbefalingsmotorer, e-handelswebsteder og katalogsøgning. For at få succes i din virksomhed har du brug for, at dine systemer er yderst tilgængelige og effektive, minimerer nedetid og undgår fejl. Når du bruger OpenSearch Service som dit primære middel til at overvåge din infrastruktur, skal du også sikre dens tilgængelighed. Nedetid for OpenSearch Service kan have en betydelig effekt på dine forretningsresultater, såsom tab af omsætning, tab i produktivitet, tab i brandværdi og meget mere.

industristandard til måling af tilgængelighed er klasse på ni. OpenSearch Service giver 3 9'er tilgængelighed, når du følger bedste praksis, hvilket betyder, at den garanterer mindre end 43.83 minutters nedetid om måneden. I dette indlæg lærer du, hvordan du kan konfigurere dit OpenSearch Service-domæne til høj tilgængelighed og ydeevne ved at følge bedste praksis og anbefalinger, mens du konfigurerer dit domæne.

Der er to væsentlige elementer, der påvirker dit domænes tilgængelighed: ressourceudnyttelsen af ​​dit domæne, som for det meste er drevet af din arbejdsbyrde, og eksterne hændelser såsom infrastrukturfejl. Selvom førstnævnte kan kontrolleres gennem kontinuerlig overvågning af domænets ydeevne og sundhed og skalering af domænet i overensstemmelse hermed, kan sidstnævnte ikke. For at afbøde virkningen af ​​eksterne hændelser som f.eks. en tilgængelighedszoneafbrydelse, forekomst eller diskfejl eller netværksproblemer på dit domæne, skal du sørge for yderligere kapacitet, fordelt over flere tilgængelighedszoner, og beholde flere kopier af data. Undladelse af at gøre det kan resultere i forringet ydeevne, utilgængelighed og i værste fald tab af data.

Lad os se på de tilgængelige muligheder for at sikre, at domænet er tilgængeligt og effektivt.

Klyngekonfiguration

Under dette afsnit vil vi tale om forskellige konfigurationsmuligheder, du har for at konfigurere din klynge korrekt, hvilket inkluderer specificering af antallet af AZ til udrulningen, opsætning af master- og dataknudepunkter, opsætning af indekser og shards.

Multi-AZ-implementering

Dataknudepunkter er ansvarlige for at behandle indekserings- og søgeanmodninger i dit domæne. Implementering af dine dataknuder på tværs af flere tilgængelighedszoner forbedrer tilgængeligheden af ​​dit domæne ved at tilføje redundant datalagring og -behandling pr. zone. Med en Multi-AZ-implementering kan dit domæne forblive tilgængeligt, selv når en fuld tilgængelighedszone bliver utilgængelig. For produktionsbelastninger, AWS anbefaler at bruge tre tilgængelighedszoner til dit domæne. Brug to tilgængelighedszoner til regioner, der kun understøtter to for at forbedre tilgængeligheden. Dette sikrer, at dit domæne er tilgængeligt i tilfælde af en Single-AZ-fejl.

Dedikeret cluster manager (master noder)

AWS anbefaler at bruge tre dedikerede cluster manager (CM) noder for alle produktionsopgaver. CM-noder sporer klyngens helbred, tilstanden og placeringen af ​​dens indekser og shards, kortlægningen for alle indekserne og tilgængeligheden af ​​dens dataknudepunkter, og den vedligeholder en liste over opgaver på klyngeniveau, der er i gang. Uden dedikerede CM-noder bruger klyngen dataknudepunkter, hvilket gør klyngen sårbar over for arbejdsbelastningskrav. Du bør dimensionere CM-noder baseret på opgavens størrelse – primært dataknudetællingerne, indekstællingerne og shard-tællingerne. OpenSearch Service implementerer altid CM-noder på tværs af tre tilgængelighedszoner, når det understøttes af regionen (to i én tilgængelighedszoner og én i andre tilgængelighedszoner, hvis regioner kun har to tilgængelighedszoner). For et kørende domæne fungerer kun én af de tre CM-noder som en valgt leder. De to andre CM-knudepunkter deltager i et valg, hvis den valgte CM-knude svigter.

Følgende tabel viser AWS' anbefalinger til CM-dimensionering. CM-noder fungerer baseret på antallet af noder, indekser, shards og kortlægning. Jo mere arbejde, jo mere computer og hukommelse skal du have og arbejde med klyngetilstanden.

Forekomsttælling Cluster Manager Node RAM Størrelse Maksimalt understøttet Shard Count Anbefalet minimum dedikeret Cluster Manager-instanstype
1-10 8 GiB 10,000 m5.stor.søgning eller m6g.stor.søgning
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

Indeks og skærver

Indeks er en logisk konstruktion, der rummer en samling af dokumenter. Du opdeler dit indeks til parallel behandling ved at angive et primært shardantal, hvor shards repræsenterer en fysisk enhed til lagring og behandling af data. I OpenSearch Service kan et shard enten være et primært shard eller et replika shard. Du bruger replikaer for holdbarhed – hvis den primære shard går tabt, promoverer OpenSearch Service en af ​​replikaerne til primær – og for at forbedre søgegennemstrømningen. OpenSearch Service sikrer, at de primære og replika-shards placeres i forskellige noder og på tværs af forskellige tilgængelighedszoner, hvis de er implementeret i mere end én tilgængelighedszone. For høj tilgængelighed anbefaler AWS at konfigurere mindst to replikaer for hvert indeks i en opsætning med tre zoner for at undgå forstyrrelser i ydeevne og tilgængelighed. I en Multi-AZ-opsætning vil du stadig have en kopi af dataene, hvis en node svigter eller i det værste tilfælde en tilgængelighedszone fejler.

Klyngeovervågning og -styring

Som nævnt tidligere er det kun halvdelen af ​​arbejdet at vælge din konfiguration baseret på bedste praksis. Vi skal også løbende overvåge ressourceudnyttelsen og ydeevnen for at afgøre, om domænet skal skaleres. Et under-provisioneret eller overudnyttet domæne kan resultere i ydeevneforringelse og i sidste ende utilgængelighed.

CPU udnyttelse

Du bruger CPU'en i dit domæne til at køre din arbejdsbyrde. Som en generel regel bør du målrette 60 % gennemsnitlig CPU-udnyttelse for enhver dataknude med peaks på 80 % og tolerere små spidser til 100 %. Når du overvejer tilgængelighed, og især i betragtning af utilgængeligheden af ​​en fuld zone, er der to scenarier. Hvis du har to tilgængelighedszoner, håndterer hver zone 50 % af trafikken. Hvis en zone bliver utilgængelig, vil den anden zone tage al den trafik, hvilket fordobler CPU-udnyttelsen. I så fald skal du have omkring 30-40 % gennemsnitlig CPU-udnyttelse i hver zone for at opretholde tilgængeligheden. Hvis du kører tre tilgængelighedszoner, tager hver zone 33 % af trafikken. Hvis en zone bliver utilgængelig, vil hver anden zone få cirka 17 % trafik. I dette tilfælde bør du målrette 50–60 % gennemsnitlig CPU-udnyttelse.

Hukommelsesudnyttelse

OpenSearch Service understøtter to typer affaldsindsamling. Den første er G1 garbage collection (G1GC), som bruges af OpenSearch Service noder, drevet af AWS Graviton 2. Den anden er Concurrent Mark Sweep (CMS), som bruges af alle noder, der drives af andre processorer. Ud af al den hukommelse, der er allokeret til en node, er halvdelen af ​​hukommelsen (op til 32 GB) tildelt Java-heapen, og resten af ​​hukommelsen bruges af andre operativsystemopgaver, filsystemcachen og så videre. For at bevare tilgængeligheden for et domæne anbefaler vi at holde den maksimale JVM-udnyttelse på omkring 80 % i CMS og 95 % i G1GC. Alt ud over det ville påvirke tilgængeligheden af ​​dit domæne og gøre din klynge usund. Vi anbefaler også at aktivere auto-tune, som aktivt overvåger hukommelsesudnyttelsen og udløser skraldeopsamleren.

Lagerudnyttelse

OpenSearch Service udgiver flere retningslinjer for dimensionering af domæner. Vi giver en empirisk formel, så du kan bestemme den rigtige mængde lagerplads, der kræves til dine behov. Det er dog vigtigt at holde øje med udtømning af lagerplads med tiden og ændringer i arbejdsbelastningskarakteristika. For at sikre, at domænet ikke løber tør for lagerplads og kan fortsætte med at indeksere data, bør du konfigurere amazoncloudwatch alarmer og overvåg din gratis lagerplads.

AWS anbefaler også at vælge et primært skærvantal, så hvert skær er inden for et optimalt størrelsesbånd. Du kan bestemme den optimale shard-størrelse gennem proof-of-concept-test med dine data og trafik. Vi bruger 10-30 GB primære shard-størrelser til søgninger og 45-50 GB primære shard-størrelser til log-analysebrug som rettesnor. Fordi shards er arbejderne i dit domæne, er de direkte ansvarlige for fordelingen af ​​arbejdsbyrden på tværs af dataknuderne. Hvis dine shards er for store, kan du opleve stress i din Java-heap fra store aggregeringer, dårligere forespørgselsydeevne og dårligere ydeevne på klyngeniveauopgaver som shard-rebalancering, snapshots og varm-til-varm-migreringer. Hvis dine shards er for små, kan de overvælde domænets Java-heap-plads, forringe forespørgselsydeevnen gennem overdreven internt netværk og gøre opgaver på klyngeniveau langsomme. Vi anbefaler også at holde antallet af shards pr. node proportionalt med den tilgængelige heap (halvdelen af ​​instansens RAM op til 32 GB) - 25 shards pr. GB Java-heap. Dette giver en praktisk grænse på 1,000 shards på enhver datanode i dit domæne.

Konklusion

I dette indlæg lærte du forskellige tips og tricks til at oprette et meget tilgængeligt domæne ved hjælp af OpenSearch Service, som hjælper dig med at holde OpenSearch Service effektiv og tilgængelig ved at køre den på tværs af tre tilgængelighedszoner.

Hold øje med en række indlæg, der fokuserer på de forskellige funktioner og funktionaliteter med OpenSearch Service. Hvis du har feedback om dette indlæg, så send det i kommentarfeltet. Hvis du har spørgsmål til dette indlæg, så start en ny tråd på OpenSearch Service-forum eller kontakt AWS support.

Om forfatterne

Rohin Bhargava er Sr. Product Manager hos Amazon OpenSearch Service-teamet. Hans passion hos AWS er ​​at hjælpe kunder med at finde den rigtige blanding af AWS-tjenester for at opnå succes for deres forretningsmål.

Prashant Agrawal er en Sr. Search Specialist Solutions Architect med Amazon OpenSearch Service. Han arbejder tæt sammen med kunderne for at hjælpe dem med at migrere deres arbejdsbelastninger til skyen og hjælper eksisterende kunder med at finjustere deres klynger for at opnå bedre ydeevne og spare på omkostningerne. Før han kom til AWS, hjalp han forskellige kunder med at bruge OpenSearch og Elasticsearch til deres søge- og loganalysebrug. Når du ikke arbejder, kan du finde ham på rejse og udforske nye steder. Kort sagt, han kan lide at lave Spis → Rejser → Gentag.

Tidsstempel:

Mere fra AWS Big Data