Amazon OpenSearch-service is een volledig open-source zoek- en analyse-engine die op veilige wijze real-time zoeken, bewaken en analyseren van bedrijfs- en operationele gegevens ontgrendelt voor gebruiksscenario's zoals aanbevelingsmotoren, e-commercesites en het doorzoeken van catalogi. Om succesvol te zijn in uw bedrijf, moeten uw systemen zeer beschikbaar en performant zijn, downtime minimaliseren en storingen voorkomen. Wanneer u OpenSearch Service gebruikt als uw primaire manier om uw infrastructuur te bewaken, moet u ook zorgen voor de beschikbaarheid ervan. Downtime voor de OpenSearch-service kan een aanzienlijk effect hebben op uw bedrijfsresultaten, zoals omzetverlies, productiviteitsverlies, verlies aan merkwaarde en meer.

De industriestandaard voor het meten van beschikbaarheid is klasse van negens. OpenSearch Service biedt 3 9's beschikbaarheid, wanneer u volgt 'best practices', wat betekent dat het minder dan 43.83 minuten downtime per maand garandeert. In dit bericht leert u hoe u uw OpenSearch Service-domein kunt configureren voor hoge beschikbaarheid en prestaties door best practices en aanbevelingen te volgen bij het instellen van uw domein.

Er zijn twee essentiële elementen die van invloed zijn op de beschikbaarheid van uw domein: het resourcegebruik van uw domein, dat grotendeels wordt bepaald door uw werklast, en externe gebeurtenissen zoals infrastructuurstoringen. Hoewel de eerste kan worden gecontroleerd door de prestaties en gezondheid van het domein continu te bewaken en het domein dienovereenkomstig te schalen, kan de laatste dat niet. Om de impact van externe gebeurtenissen, zoals een storing in de beschikbaarheidszone, een instantie- of schijffout of netwerkproblemen op uw domein, te beperken, moet u extra capaciteit voorzien, verdeeld over meerdere beschikbaarheidszones, en meerdere kopieën van gegevens bewaren. Als u dit niet doet, kan dit leiden tot slechtere prestaties, onbeschikbaarheid en, in het slechtste geval, gegevensverlies.

Laten we eens kijken naar de opties die voor u beschikbaar zijn om ervoor te zorgen dat het domein beschikbaar en performant is.

Clusterconfiguratie

In deze sectie zullen we het hebben over verschillende configuratie-opties die u nodig hebt om uw cluster correct in te stellen, waaronder het specificeren van het aantal AZ voor de implementatie, het instellen van de master- en dataknooppunten, het instellen van indexen en shards.

Multi-AZ-implementatie

Gegevensknooppunten zijn verantwoordelijk voor het verwerken van indexerings- en zoekverzoeken in uw domein. Door uw dataknooppunten in meerdere beschikbaarheidszones te implementeren, verbetert u de beschikbaarheid van uw domein door redundante gegevensopslag en -verwerking per zone toe te voegen. Met een Multi-AZ-implementatie kan uw domein beschikbaar blijven, zelfs wanneer een volledige Availability Zone niet meer beschikbaar is. Voor productiewerklasten, AWS raadt aan om drie beschikbaarheidszones voor uw domein te gebruiken. Gebruik twee beschikbaarheidszones voor regio's die slechts twee ondersteunen voor verbeterde beschikbaarheid. Dit zorgt ervoor dat uw domein beschikbaar is in het geval van een Single-AZ-storing.

Toegewijde clustermanager (hoofdknooppunten)

AWS raadt aan om drie speciale clustermanagerknooppunten (CM) te gebruiken voor alle productietaken. CM-knooppunten volgen de status van het cluster, de status en locatie van de indexen en shards, de mapping voor alle indexen en de beschikbaarheid van de gegevensknooppunten, en het onderhoudt een lijst met lopende taken op clusterniveau. Zonder speciale CM-knooppunten gebruikt het cluster gegevensknooppunten, waardoor het cluster kwetsbaar is voor werkbelasting. U moet de grootte van CM-knooppunten bepalen op basis van de grootte van de taak, in de eerste plaats het aantal gegevensknooppunten, het aantal indexen en het aantal shards. OpenSearch Service implementeert CM-nodes altijd in drie beschikbaarheidszones, indien ondersteund door de regio (twee in één beschikbaarheidszone en één in andere beschikbaarheidszones als regio's slechts twee beschikbaarheidszones hebben). Voor een lopend domein werkt slechts één van de drie CM-knooppunten als gekozen leider. De andere twee CM-knooppunten nemen deel aan een verkiezing als het gekozen CM-knooppunt faalt.

De volgende tabel toont de aanbevelingen van AWS voor CM-maatvoering. CM-knooppunten werken op basis van het aantal knooppunten, indexen, shards en mapping. Hoe meer werk, hoe meer rekenkracht en geheugen u nodig hebt om de clusterstatus vast te houden en ermee te werken.

Indexen en scherven

Indexen zijn een logische constructie waarin een verzameling documenten is ondergebracht. U partitioneert uw index voor parallelle verwerking door een primair aantal shards op te geven, waarbij shards een fysieke eenheid vertegenwoordigen voor het opslaan en verwerken van gegevens. In de OpenSearch-service kan een shard een primaire shard of een replica-shard zijn. U gebruikt replica's voor duurzaamheid - als de primaire shard verloren gaat, promoveert OpenSearch Service een van de replica's tot primaire - en voor het verbeteren van de zoekdoorvoer. OpenSearch Service zorgt ervoor dat de primaire en replica-scherven in verschillende knooppunten en in verschillende beschikbaarheidszones worden geplaatst, indien ingezet in meer dan één beschikbaarheidszone. Voor hoge beschikbaarheid raadt AWS aan om ten minste twee replica's voor elke index te configureren in een opstelling met drie zones om verstoring van de prestaties en beschikbaarheid te voorkomen. Als in een Multi-AZ-configuratie een knooppunt uitvalt of in het zeldzame slechtste geval een Beschikbaarheidszone uitvalt, hebt u nog steeds een kopie van de gegevens.

Clusterbewaking en -beheer

Zoals eerder besproken, is het selecteren van uw configuratie op basis van best practices slechts het halve werk. We moeten ook continu het gebruik en de prestaties van bronnen monitoren om te bepalen of het domein moet worden geschaald. Een domein dat onvoldoende is ingericht of te veel wordt gebruikt, kan leiden tot verslechtering van de prestaties en uiteindelijk tot onbeschikbaarheid.

CPU-gebruik

U gebruikt de CPU in uw domein om uw workload uit te voeren. Als algemene regel geldt dat u zich moet richten op 60% gemiddeld CPU-gebruik voor elk gegevensknooppunt, met pieken van 80%, en kleine pieken tot 100% moet tolereren. Als je kijkt naar de beschikbaarheid, en vooral als je kijkt naar de onbeschikbaarheid van een volledige zone, zijn er twee scenario's. Als u twee beschikbaarheidszones heeft, verwerkt elke zone 50% van het verkeer. Als een zone niet meer beschikbaar is, neemt de andere zone al dat verkeer over, waardoor het CPU-gebruik wordt verdubbeld. In dat geval moet u in elke zone een gemiddeld CPU-gebruik van ongeveer 30-40% hebben om de beschikbaarheid te behouden. Als u drie beschikbaarheidszones gebruikt, neemt elke zone 33% van het verkeer voor zijn rekening. Als een zone niet meer beschikbaar is, krijgt elke andere zone ongeveer 17% verkeer. In dit geval moet u zich richten op 50-60% gemiddeld CPU-gebruik.

Geheugengebruik

OpenSearch Service ondersteunt twee soorten afvalinzameling. De eerste is G1 Garbage Collection (G1GC), die wordt gebruikt door OpenSearch Service-nodes, mogelijk gemaakt door AWS Graviton 2. De tweede is Concurrent Mark Sweep (CMS), die wordt gebruikt door alle knooppunten die worden aangedreven door andere processors. Van al het geheugen dat aan een knooppunt is toegewezen, wordt de helft van het geheugen (maximaal 32 GB) toegewezen aan de Java-heap en wordt de rest van het geheugen gebruikt door andere taken van het besturingssysteem, de cache van het bestandssysteem, enzovoort. Om de beschikbaarheid van een domein te behouden, raden we aan om het maximale JVM-gebruik op ongeveer 80% te houden in CMS en 95% in G1GC. Alles daarbuiten zou van invloed zijn op de beschikbaarheid van uw domein en uw cluster ongezond maken. We raden ook aan om automatisch afstemmen in te schakelen, waarmee het geheugengebruik actief wordt gecontroleerd en de vuilnisophaaldienst wordt geactiveerd.

Opslaggebruik

OpenSearch Service publiceert verschillende richtlijnen voor grootte van domeinen. We bieden een empirische formule zodat u de juiste hoeveelheid opslagruimte kunt bepalen die nodig is voor uw vereisten. Het is echter belangrijk om op de uitputting van de opslag na verloop van tijd en veranderingen in werklastkenmerken te letten. Om ervoor te zorgen dat het domein niet zonder opslagruimte komt te zitten en gegevens kan blijven indexeren, moet u configureren Amazon Cloud Watch alarmen en bewaak uw vrije opslagruimte.

AWS raadt ook aan om een ​​primaire shard-telling te kiezen, zodat elke shard binnen een optimale grootteband valt. U kunt de optimale shardgrootte bepalen door middel van proof-of-concept-testen met uw gegevens en verkeer. We gebruiken 10-30 GB primaire shard-grootten voor use-cases voor zoeken en 45-50 GB primaire shard-grootten voor use-cases voor loganalyse als richtlijn. Omdat shards de werkers in uw domein zijn, zijn zij direct verantwoordelijk voor de verdeling van de werklast over de dataknooppunten. Als uw shards te groot zijn, ziet u mogelijk stress in uw Java-heap door grote aggregaties, slechtere queryprestaties en slechtere prestaties bij taken op clusterniveau, zoals het herbalanceren van shards, snapshots en hot-to-warm-migraties. Als uw shards te klein zijn, kunnen ze de Java-heapruimte van het domein overbelasten, queryprestaties verslechteren door overmatige interne netwerken en taken op clusterniveau vertragen. We raden ook aan om het aantal shards per node in verhouding te houden tot de beschikbare heap (de helft van het RAM-geheugen van de instantie tot 32 GB): 25 shards per GB Java-heap. Dit maakt een praktische limiet van 1,000 shards op elk gegevensknooppunt in uw domein.

Conclusie

In dit bericht heb je verschillende tips en trucs geleerd om een ​​domein met een hoge beschikbaarheid op te zetten met behulp van de OpenSearch-service, waarmee je de OpenSearch-service krachtig en beschikbaar kunt houden door deze in drie beschikbaarheidszones uit te voeren.

Blijf op de hoogte voor een reeks berichten over de verschillende functies en functionaliteiten met OpenSearch Service. Als je feedback hebt over dit bericht, geef deze dan door in het opmerkingengedeelte. Als je vragen hebt over dit bericht, start dan een nieuw draadje op de OpenSearch Service-forum of contact AWS-ondersteuning.

Over de auteurs

Rohin Bhargava is Senior Product Manager bij het Amazon OpenSearch Service-team. Zijn passie bij AWS is om klanten te helpen de juiste mix van AWS-services te vinden om succes te behalen voor hun zakelijke doelen.

Prashant Agrawal is een Sr. Search Specialist Solutions Architect met Amazon OpenSearch Service. Hij werkt nauw samen met klanten om hen te helpen hun workloads naar de cloud te migreren en helpt bestaande klanten hun clusters te verfijnen om betere prestaties te bereiken en kosten te besparen. Voordat hij bij AWS kwam, hielp hij verschillende klanten bij het gebruik van OpenSearch en Elasticsearch voor hun gebruiksscenario's voor zoek- en loganalyse. Als hij niet aan het werk is, kun je hem zien reizen en nieuwe plaatsen ontdekken. Kortom, hij doet graag Eten → Reizen → Herhalen.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoAiStream. Web3 gegevensintelligentie. Kennis versterkt. Toegang hier.
• De toekomst slaan met Adryenn Ashley. Toegang hier.
• Koop en verkoop aandelen in PRE-IPO-bedrijven met PREIPO®. Toegang hier.
• Bron: https://aws.amazon.com/blogs/big-data/configure-amazon-opensearch-service-for-high-availability/