Impact van infrastructuurstoringen op scherf in Amazon OpenSearch Service

Amazon OpenSearch-service is een beheerde service die het eenvoudig maakt om OpenSearch en verouderde Elasticsearch-clusters op schaal te beveiligen, implementeren en gebruiken in de AWS Cloud. Amazon OpenSearch Service levert alle bronnen voor uw cluster, start het en detecteert en vervangt automatisch defecte knooppunten, waardoor de overhead van zelfbeheerde infrastructuren wordt verminderd. De service maakt het u gemakkelijk om interactieve loganalyses uit te voeren, real-time applicatiebewaking, website-zoekopdrachten en meer door de nieuwste versies van OpenSearch aan te bieden, ondersteuning voor 19 versies van Elasticsearch (versies 1.5 tot 7.10) en visualisatiemogelijkheden aangedreven door OpenSearch-dashboards en Kibana (versies 1.5 tot 7.10).

In de nieuwste release van de servicesoftware hebben we de shardtoewijzingslogica bijgewerkt om belastingsbewust te zijn, zodat wanneer shards opnieuw worden verdeeld in het geval van knooppuntstoringen, de service niet toestaat dat overgebleven knooppunten worden overbelast door shards die eerder op het defecte knooppunt werden gehost. Dit is vooral belangrijk voor Multi-AZ-domeinen om consistente en voorspelbare clusterprestaties te bieden.

Als u meer achtergrondinformatie wilt over logica voor het toewijzen van shards in het algemeen, zie dan a.u.b Demystificatie van Elasticsearch-shardtoewijzing.

De uitdaging

Van een Amazon OpenSearch Service-domein wordt gezegd dat het "gebalanceerd" is wanneer het aantal knooppunten gelijkelijk is verdeeld over geconfigureerde beschikbaarheidszones en het totale aantal shards gelijkelijk is verdeeld over alle beschikbare knooppunten zonder concentratie van shards van een index op een index knooppunt. OpenSearch heeft ook een eigenschap genaamd "Zone Awareness" die, indien ingeschakeld, ervoor zorgt dat de primaire shard en de bijbehorende replica worden toegewezen in verschillende beschikbaarheidszones. Als u meer dan één exemplaar van gegevens hebt, zorgt het hebben van meerdere beschikbaarheidszones voor een betere fouttolerantie en beschikbaarheid. In het geval dat het domein wordt uitgeschaald of ingeschaald of tijdens het falen van knooppunt(en), herverdeelt OpenSearch automatisch de shards tussen beschikbare knooppunten terwijl de toewijzingsregels worden nageleefd op basis van zonebewustzijn.

Hoewel het shard-balancing-proces ervoor zorgt dat shards gelijkmatig worden verdeeld over beschikbaarheidszones, worden shards in sommige gevallen, als er een onverwachte storing optreedt in een enkele zone, opnieuw toegewezen aan de overgebleven knooppunten. Dit kan ertoe leiden dat de overgebleven knooppunten overweldigd raken, wat de clusterstabiliteit beïnvloedt.

Als bijvoorbeeld één knooppunt in een cluster met drie knooppunten uitvalt, verdeelt OpenSearch de niet-toegewezen scherven opnieuw, zoals weergegeven in het volgende diagram. Hier vertegenwoordigt "P" een primaire shard-kopie, terwijl "R" een replica-scherfkopie vertegenwoordigt.

Dit gedrag van het domein kan in twee delen worden verklaard: tijdens een storing en tijdens herstel.

Tijdens falen

Een domein dat in meerdere beschikbaarheidszones is geïmplementeerd, kan tijdens zijn levenscyclus met meerdere soorten storingen te maken krijgen.

Volledige zonestoring

Een cluster kan om verschillende redenen een enkele Beschikbaarheidszone kwijtraken, evenals alle knooppunten in die zone. Vandaag probeert de service de verloren nodes in de resterende gezonde beschikbaarheidszones te plaatsen. De service probeert ook de verloren scherven in de resterende knooppunten opnieuw te maken terwijl de toewijzingsregels worden gevolgd. Dit kan enkele onbedoelde gevolgen hebben.

• Wanneer de shards van de getroffen zone opnieuw worden toegewezen aan gezonde zones, activeren ze shardherstel waardoor de latentie kan toenemen omdat het extra CPU-cycli en netwerkbandbreedte verbruikt.
• Voor een n-AZ, n-copy setup, (n>1), worden de overgebleven n-1 beschikbaarheidszones toegewezen met de n-de shard-kopie, wat ongewenst kan zijn omdat het scheefheid in de shard-distributie kan veroorzaken, wat ook kan resulteren in onevenwichtig verkeer over knooppunten. Deze knooppunten kunnen overbelast raken, wat kan leiden tot verdere storingen.

Gedeeltelijke zonestoring

In het geval van een gedeeltelijke zonestoring of wanneer het domein slechts enkele knooppunten in een beschikbaarheidszone verliest, probeert Amazon OpenSearch Service de defecte knooppunten zo snel mogelijk te vervangen. Als het echter te lang duurt om de knooppunten te vervangen, probeert OpenSearch de niet-toegewezen scherven van die zone toe te wijzen aan de overgebleven knooppunten in de Beschikbaarheidszone. Als de service de knooppunten in de getroffen beschikbaarheidszone niet kan vervangen, kan deze deze toewijzen aan de andere geconfigureerde beschikbaarheidszone, wat de verdeling van shards zowel over als binnen de zone verder kan scheeftrekken. Dit heeft weer onbedoelde gevolgen.

• Als de knooppunten op het domein niet genoeg opslagruimte hebben voor de extra shards, kan het domein worden geblokkeerd door schrijven, wat gevolgen heeft voor de indexering.
• Vanwege de scheve verdeling van shards kan het domein ook scheef verkeer over de knooppunten ervaren, wat de latenties of time-outs voor lees- en schrijfbewerkingen verder kan vergroten.

Herstel

Om het gewenste aantal knooppunten van het domein te behouden, lanceert Amazon OpenSearch Service tegenwoordig dataknooppunten in de resterende gezonde beschikbaarheidszones, vergelijkbaar met de scenario's die worden beschreven in het bovenstaande gedeelte over mislukkingen. Om na een dergelijk incident een goede nodedistributie over alle Availability Zones te garanderen, was handmatige tussenkomst van AWS nodig.

Wat verandert er

Om de algehele foutafhandeling te verbeteren en de impact van fouten op de gezondheid en prestaties van het domein te minimaliseren, voert Amazon OpenSearch Service de volgende wijzigingen door:

• Geforceerd zonebewustzijn: OpenSearch heeft een reeds bestaande configuratie voor het balanceren van shards, geforceerd bewustzijn genaamd, die wordt gebruikt om de beschikbaarheidszones in te stellen waaraan shards moeten worden toegewezen. Als u bijvoorbeeld een bewustzijnsattribuut met de naam zone hebt en knooppunten configureert in zone1 en zone2, kunt u gedwongen bewustzijn gebruiken om te voorkomen dat OpenSearch replica's toewijst als er slechts één zone beschikbaar is:

cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2

Met deze voorbeeldconfiguratie, als u twee knooppunten start met node.attr.zone ingesteld op zone1 en maak een index met vijf shards en één replica, OpenSearch maakt de index en wijst de vijf primaire shards toe, maar geen replica's. Replica's worden slechts eenmaal toegewezen aan knooppunten node.attr.zone ingesteld op zone2 beschikbaar.

Amazon OpenSearch Service gebruikt de geforceerde bewustzijnsconfiguratie op Multi-AZ-domeinen om ervoor te zorgen dat shards alleen worden toegewezen volgens de regels van zonebewustzijn. Dit zou de plotselinge toename van de belasting op de knooppunten van de gezonde beschikbaarheidszones voorkomen.

• Load-Aware Shard-toewijzing: Amazon OpenSearch Service houdt rekening met factoren zoals de ingerichte capaciteit, de werkelijke capaciteit en het totale aantal shard-kopieën om te berekenen of een knooppunt wordt overbelast met meer shards op basis van de verwachte gemiddelde shards per knooppunt. Het zou shard-toewijzing voorkomen wanneer een knooppunt een shard-telling heeft toegewezen die deze limiet overschrijdt.

Note dat elke niet-toegewezen primair kopiëren zou nog steeds zijn toegestaan ​​op het overbelaste knooppunt om te voorkomen dat het cluster op handen is voor gegevensverlies.

Evenzo brengt Amazon OpenSearch Service, om het probleem van handmatig herstel aan te pakken (zoals beschreven in het gedeelte Herstel hierboven), ook wijzigingen aan in de interne schaalcomponent. Met de nieuwere wijzigingen zal Amazon OpenSearch Service geen nodes starten in de resterende beschikbaarheidszones, zelfs niet als het eerder beschreven foutscenario wordt doorlopen.

Het visualiseren van het huidige en nieuwe gedrag

Een Amazon OpenSearch Service-domein is bijvoorbeeld geconfigureerd met 3-AZ, 6 dataknooppunten, 12 primaire shards en 24 replica-shards. Het domein wordt geleverd over AZ-1, AZ-2 en AZ-3, met twee knooppunten in elk van de zones.

Huidige shardtoewijzing:
Totaal aantal scherven: 12 primaire + 24 replica = 36 scherven
Aantal beschikbaarheidszones: 3
Aantal scherven per zone (zonebewustzijn is waar): 36/3 = 12
Aantal knooppunten per beschikbaarheidszone: 2
Aantal scherven per knooppunt: 12/2 = 6

Het volgende diagram biedt een visuele weergave van de domeinconfiguratie. De cirkels geven het aantal scherven aan dat aan het knooppunt is toegewezen. Amazon OpenSearch Service wijst zes shards per node toe.

Tijdens een gedeeltelijke zonestoring, waarbij één knooppunt in AZ-3 uitvalt, wordt het defecte knooppunt toegewezen aan de resterende zone en worden de scherven in de zone herverdeeld op basis van de beschikbare knooppunten. Na de hierboven beschreven wijzigingen zal het cluster geen nieuw knooppunt maken of shards herdistribueren na het uitvallen van het knooppunt.

In het bovenstaande diagram, met het verlies van één knooppunt in AZ-3, zou Amazon OpenSearch Service proberen de vervangende capaciteit in dezelfde zone te lanceren. Vanwege een storing kan de zone echter beschadigd raken en kan de vervanging niet worden gestart. In dat geval probeert de service capaciteitstekort op te starten in een andere gezonde zone, wat kan leiden tot zone-onbalans tussen beschikbaarheidszones. Scherven op de getroffen zone worden gepropt op het overgebleven knooppunt in dezelfde zone. Met het nieuwe gedrag zou de service echter proberen capaciteit in dezelfde zone te lanceren, maar zou het lanceren van een capaciteitstekort in andere zones vermijden om onbalans te voorkomen. De shard-toewijzer zou er ook voor zorgen dat de overgebleven knooppunten niet overbelast raken.

Evenzo, in het geval dat alle knooppunten in AZ-3 verloren gaan of de AZ-3 beschadigd raakt, brengt Amazon OpenSearch Service de verloren knooppunten in de resterende beschikbaarheidszone naar boven en herverdeelt het ook de scherven op de knooppunten. Na de nieuwe wijzigingen zal Amazon OpenSearch Service echter geen knooppunten toewijzen aan de resterende zone of proberen verloren scherven opnieuw toe te wijzen aan de resterende zone. Amazon OpenSearch Service wacht tot het herstel is uitgevoerd en het domein na herstel terugkeert naar de oorspronkelijke configuratie.

Als uw domein onvoldoende capaciteit heeft om het verlies van een beschikbaarheidszone op te vangen, kan de doorvoer voor uw domein afnemen. Het wordt daarom ten zeerste aanbevolen om de best practices te volgen bij het bepalen van de grootte van uw domein, wat inhoudt dat er voldoende resources beschikbaar zijn om het verlies van een enkele Beschikbaarheidszone-storing op te vangen.

Op dit moment vereist de service, zodra het domein is hersteld, handmatige tussenkomst om de capaciteit over beschikbaarheidszones te verdelen, wat ook shard-bewegingen met zich meebrengt. Met het nieuwe gedrag is er echter geen interventie nodig tijdens het herstelproces, omdat de capaciteit terugkeert in de getroffen zone en de scherven ook automatisch worden toegewezen aan de herstelde knooppunten. Dit zorgt ervoor dat er geen concurrerende prioriteiten zijn voor de resterende middelen.

Wat je kunt verwachten

Nadat u uw Amazon OpenSearch Service-domein hebt bijgewerkt naar de nieuwste versie van de servicesoftware, worden de domeinen die zijn geconfigureerd met best practices zal meer voorspelbare prestaties hebben, zelfs na het verlies van een of meer dataknooppunten in een beschikbaarheidszone. Er zullen minder gevallen zijn van overbezetting van de shard in een knooppunt. Het is een goede gewoonte om voldoende capaciteit in te richten om een ​​storing in een enkele zone te kunnen tolereren

Soms ziet u een domein geel worden tijdens dergelijke onverwachte storingen, omdat we geen replicascherven toewijzen aan overbelaste knooppunten. Dit betekent echter niet dat er gegevensverlies zal zijn in een goed geconfigureerd domein. We zullen er nog steeds voor zorgen dat alle voorverkiezingen worden toegewezen tijdens de storing. Er is een geautomatiseerd herstel aanwezig, dat zorgt voor het balanceren van de knooppunten in het domein en ervoor zorgt dat de replica's worden toegewezen zodra de fout is hersteld.

Werk de servicesoftware van uw Amazon OpenSearch Service-domein bij om deze nieuwe wijzigingen op uw domein toe te passen. Meer details over het updateproces van de servicesoftware vindt u in de Amazon OpenSearch Service-documentatie.

Conclusie

In dit bericht zagen we hoe Amazon OpenSearch Service onlangs de logica heeft verbeterd om knooppunten en scherven te verdelen over beschikbaarheidszones tijdens zonale storingen.

Deze wijziging helpt de service om meer consistente en voorspelbare prestaties te garanderen tijdens node- of zonestoringen. Domeinen zullen geen verhoogde latenties of schrijfblokken zien tijdens het verwerken van schrijf- en leesbewerkingen, die vroeger soms aan het licht kwamen vanwege overmatige toewijzing van shards op knooppunten.

Over de auteurs

Bukhtawar Khan is een Senior Software Engineer die werkt aan Amazon OpenSearch Service. Hij is geïnteresseerd in gedistribueerde en autonome systemen. Hij levert een actieve bijdrage aan OpenSearch.

Anshu Agarwal is een Senior Software Engineer die werkt aan AWS OpenSearch bij Amazon Web Services. Ze is gepassioneerd door het oplossen van problemen met betrekking tot het bouwen van schaalbare en zeer betrouwbare systemen.

Shourya Dutta Biswas is een Software Engineer die werkt aan AWS OpenSearch bij Amazon Web Services. Hij is gepassioneerd door het bouwen van zeer veerkrachtige gedistribueerde systemen.

Rishab Nahata is een Software Engineer die werkt aan OpenSearch bij Amazon Web Services. Hij is gefascineerd door het oplossen van problemen in gedistribueerde systemen. Hij levert een actieve bijdrage aan OpenSearch.

Ranjith Ramachandra is een Engineering Manager die werkt aan Amazon OpenSearch Service bij Amazon Web Services.

Jon Handler is een Senior Principal Solutions Architect, gespecialiseerd in AWS-zoektechnologieën - Amazon CloudSearch en Amazon OpenSearch Service. Hij is gevestigd in Palo Alto en helpt een breed scala aan klanten om hun zoek- en loganalyse-workloads goed in te zetten en goed te laten werken.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://aws.amazon.com/blogs/big-data/impact-of-infrastructure-failures-on-shard-in-amazon-opensearch-service/