Konfigurera Amazon OpenSearch Service för hög tillgänglighet | Amazon webbtjänster

Konfigurera Amazon OpenSearch Service för hög tillgänglighet | Amazon webbtjänster

Tidsstämpel: 31 maj 2023 12:56
Källnod: 2691649

Amazon OpenSearch Service är en sök- och analysmotor med helt öppen källkod som säkert låser upp realtidssökning, övervakning och analys av affärs- och driftsdata för användningsfall som rekommendationsmotorer, e-handelswebbplatser och katalogsökning. För att bli framgångsrik i din verksamhet behöver du att dina system är högst tillgängliga och prestanda, minimerar stilleståndstid och undviker misslyckanden. När du använder OpenSearch Service som ditt primära sätt att övervaka din infrastruktur måste du också säkerställa dess tillgänglighet. Driftstopp för OpenSearch Service kan ha en betydande effekt på dina affärsresultat, såsom förlust av intäkter, förlust i produktivitet, förlust av varumärkesvärde och mer.

Smakämnen industristandard för mätning av tillgänglighet är klass av nior. OpenSearch Service ger 3 9:or av tillgänglighet när du följer bästa praxis, vilket innebär att den garanterar mindre än 43.83 minuters driftstopp i månaden. I det här inlägget kommer du att lära dig hur du kan konfigurera din OpenSearch Service-domän för hög tillgänglighet och prestanda genom att följa bästa praxis och rekommendationer när du konfigurerar din domän.

Det finns två väsentliga faktorer som påverkar din domäns tillgänglighet: resursutnyttjandet av din domän, som mestadels styrs av din arbetsbelastning, och externa händelser som infrastrukturfel. Även om den förra kan kontrolleras genom kontinuerlig övervakning av domänens prestanda och hälsa och skala domänen därefter, kan den senare inte. För att mildra effekterna av externa händelser som ett avbrott i tillgänglighetszonen, instans- eller diskfel, eller nätverksproblem på din domän, måste du tillhandahålla ytterligare kapacitet, fördelad över flera tillgänglighetszoner, och behålla flera kopior av data. Underlåtenhet att göra det kan leda till försämrad prestanda, otillgänglighet och, i värsta fall, dataförlust.

Låt oss titta på de alternativ som är tillgängliga för dig för att säkerställa att domänen är tillgänglig och fungerar.

Klusterkonfiguration

Under det här avsnittet kommer vi att prata om olika konfigurationsalternativ som du måste ställa in ditt kluster på rätt sätt, vilket inkluderar att specificera antalet AZ för distributionen, ställa in huvud- och datanoderna, ställa in index och shards.

Multi-AZ-distribution

Datanoder är ansvariga för att bearbeta indexering och sökförfrågningar på din domän. Genom att distribuera dina datanoder över flera tillgänglighetszoner förbättras tillgängligheten för din domän genom att lägga till redundant datalagring och bearbetning per zon. Med en Multi-AZ-distribution kan din domän förbli tillgänglig även när en fullständig tillgänglighetszon blir otillgänglig. För produktionsbelastningar, AWS rekommenderar att du använder tre tillgänglighetszoner för din domän. Använd två tillgänglighetszoner för regioner som endast stöder två för förbättrad tillgänglighet. Detta säkerställer att din domän är tillgänglig i händelse av ett Single-AZ-fel.

Dedikerad klusterhanterare (masternoder)

AWS rekommenderar att du använder tre dedikerade klusterhanterare (CM) noder för alla produktionsbelastningar. CM-noder spårar klustrets hälsa, tillståndet och platsen för dess index och skärvor, mappningen för alla index och tillgängligheten för dess datanoder, och den upprätthåller en lista över klusternivåuppgifter som pågår. Utan dedikerade CM-noder använder klustret datanoder, vilket gör klustret sårbart för arbetsbelastningskrav. Du bör storleksanpassa CM-noder baserat på storleken på uppgiften – i första hand datanodantal, indexantal och shardantal. OpenSearch Service distribuerar alltid CM-noder över tre tillgänglighetszoner när det stöds av regionen (två i en tillgänglighetszoner och en i andra tillgänglighetszoner om regioner bara har två tillgänglighetszoner). För en löpande domän fungerar bara en av de tre CM-noderna som en vald ledare. De andra två CM-noderna deltar i ett val om den valda CM-noden misslyckas.

Följande tabell visar AWS rekommendationer för CM-dimensionering. CM-noder fungerar baserat på antalet noder, index, skärvor och mappning. Ju mer arbete, desto mer dator och minne behöver du hålla och arbeta med klustertillståndet.

Antal instanser Cluster Manager Node RAM-storlek Maximalt antal skärvor som stöds Rekommenderad minsta dedikerad Cluster Manager-instanstyp
1-10 8 GiB 10,000 m5.large.search eller m6g.large.search
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

Index och skärvor

Index är en logisk konstruktion som innehåller en samling dokument. Du partitionerar ditt index för parallell bearbetning genom att ange ett primärt shardantal, där shards representerar en fysisk enhet för lagring och bearbetning av data. I OpenSearch Service kan en shard antingen vara en primär shard eller en replika shard. Du använder repliker för hållbarhet – om den primära skärvan går förlorad marknadsför OpenSearch Service en av replikerna till primär – och för att förbättra sökgenomströmningen. OpenSearch Service säkerställer att de primära och replika skärvorna placeras i olika noder och över olika tillgänglighetszoner, om de distribueras i mer än en tillgänglighetszon. För hög tillgänglighet rekommenderar AWS att du konfigurerar minst två repliker för varje index i en trezonsuppsättning för att undvika störningar i prestanda och tillgänglighet. I en Multi-AZ-inställning, om en nod misslyckas eller i sällsynta värsta fall en tillgänglighetszon misslyckas, har du fortfarande en kopia av data.

Klusterövervakning och förvaltning

Som diskuterats tidigare är det bara halva jobbet att välja din konfiguration baserat på bästa praxis. Vi behöver också kontinuerligt övervaka resursutnyttjandet och prestanda för att avgöra om domänen behöver skalas. En undertillgänglig eller överutnyttjad domän kan resultera i prestandaförsämring och så småningom otillgänglighet.

CPU-utnyttjande

Du använder processorn i din domän för att köra din arbetsbelastning. Som en allmän regel bör du sikta på 60 % genomsnittlig CPU-användning för vilken datanod som helst, med toppar på 80 %, och tolerera små toppar till 100 %. När du överväger tillgänglighet, och särskilt med tanke på otillgängligheten av en hel zon, finns det två scenarier. Om du har två tillgänglighetszoner hanterar varje zon 50 % av trafiken. Om en zon blir otillgänglig tar den andra zonen all trafik, vilket fördubblar CPU-användningen. I så fall måste du ligga på cirka 30–40 % genomsnittlig CPU-användning i varje zon för att bibehålla tillgängligheten. Om du kör tre tillgänglighetszoner tar varje zon 33 % av trafiken. Om en zon blir otillgänglig kommer varje annan zon att få cirka 17 % trafik. I det här fallet bör du rikta in dig på 50–60 % genomsnittlig CPU-användning.

Minneutnyttjande

OpenSearch Service stöder två typer av sophämtning. Den första är G1 garbage collection (G1GC), som används av OpenSearch Service-noder, som drivs av AWS Graviton 2. Den andra är Concurrent Mark Sweep (CMS), som används av alla noder som drivs av andra processorer. Av allt minne som allokerats till en nod är hälften av minnet (upp till 32 GB) tilldelat Java-högen, och resten av minnet används av andra operativsystemuppgifter, filsystemets cache och så vidare. För att bibehålla tillgängligheten för en domän rekommenderar vi att du håller den maximala JVM-användningen på cirka 80 % i CMS och 95 % i G1GC. Allt utöver det skulle påverka tillgängligheten för din domän och göra ditt kluster ohälsosamt. Vi rekommenderar också att du aktiverar auto-tune, som aktivt övervakar minnesutnyttjandet och triggar sopsamlaren.

Utnyttjande av lagring

OpenSearch Service publicerar flera riktlinjer för storlek på domäner. Vi tillhandahåller en empirisk formel så att du kan bestämma rätt mängd lagring som krävs för dina behov. Det är dock viktigt att hålla utkik efter uttömning av lagring med tiden och förändringar i arbetsbelastningsegenskaper. För att säkerställa att domänen inte tar slut på lagringsutrymme och kan fortsätta att indexera data bör du konfigurera amazoncloudwatch larmar och övervaka ditt lediga lagringsutrymme.

AWS rekommenderar också att man väljer ett primärt antal skärvor så att varje skärva ligger inom ett optimalt storleksband. Du kan bestämma den optimala skärvstorleken genom proof-of-concept-testning med din data och trafik. Vi använder 10–30 GB primära skärvstorlekar för sökanvändningsfall och 45–50 GB primära skärvstorlekar för användningsfall för loganalys som en riktlinje. Eftersom shards är arbetarna i din domän, är de direkt ansvariga för fördelningen av arbetsbelastningen över datanoderna. Om dina skärvor är för stora kan du se stress i din Java-hög från stora aggregationer, sämre frågeprestanda och sämre prestanda för uppgifter på klusternivå som ombalansering av skärvor, ögonblicksbilder och varma-till-varma-migreringar. Om dina skärvor är för små kan de överväldiga domänens Java-högutrymme, försämra frågeprestanda genom överdrivet internt nätverk och göra uppgifter på klusternivå långsamma. Vi rekommenderar också att du håller antalet shards per nod proportionellt mot den tillgängliga högen (hälften av instansens RAM-minne upp till 32 GB) – 25 shards per GB Java-hög. Detta gör en praktisk gräns på 1,000 XNUMX shards på vilken datanod som helst på din domän.

Slutsats

I det här inlägget lärde du dig olika tips och tricks för att konfigurera en högst tillgänglig domän med OpenSearch Service, som hjälper dig att hålla OpenSearch Service prestanda och tillgänglig genom att köra den över tre tillgänglighetszoner.

Håll utkik efter en serie inlägg som fokuserar på de olika funktionerna och funktionerna med OpenSearch Service. Om du har feedback om det här inlägget, skicka in det i kommentarsfältet. Om du har frågor om detta inlägg, starta en ny tråd på Forum för OpenSearch Service eller kontakta AWS-support.

Om författarna

Rohin Bhargava är Sr. Product Manager med Amazon OpenSearch Service-teamet. Hans passion på AWS är att hjälpa kunder att hitta den rätta mixen av AWS-tjänster för att nå framgång för sina affärsmål.

Prashant Agrawal är en Sr. Search Specialist Solutions Architect med Amazon OpenSearch Service. Han arbetar nära kunderna för att hjälpa dem att migrera sina arbetsbelastningar till molnet och hjälper befintliga kunder att finjustera sina kluster för att uppnå bättre prestanda och spara kostnader. Innan han började med AWS hjälpte han olika kunder att använda OpenSearch och Elasticsearch för deras användningsfall för sökning och logganalys. När du inte arbetar kan du hitta honom på resande fot och utforska nya platser. Kort sagt, han gillar att göra Äta → Resa → Upprepa.

Tidsstämpel:

Mer från AWS Big Data