Niet verwonderlijk, hier bij Terugspoelen, we moeten veel gegevens beschermen (meer dan 2 petabytes waard). Een van de databases die we gebruiken heet Elasticsearch (ES of Opensearch, zoals het nu bekend staat in AWS). Simpel gezegd, ES is een documentendatabase die razendsnelle zoekresultaten mogelijk maakt. Snelheid is essentieel wanneer klanten op zoek zijn naar een bepaald bestand of item dat ze moeten herstellen met Terugspoelen. Elke seconde downtime telt, dus onze zoekresultaten moeten snel, nauwkeurig en betrouwbaar zijn.
Een andere overweging was een ramp herstel. Als onderdeel van onze Systeem- en organisatiecontroles niveau 2 (SOC2) certificeringsproces, moesten we ervoor zorgen dat we een werkend noodherstelplan hadden om de service te herstellen in het onwaarschijnlijke geval dat de hele AWS-regio uitviel.
“Een hele AWS-regio?? Dat gaat nooit gebeuren!” (Behalve voor wanneer het deed?)
Alles is mogelijk, er gaan dingen mis en om aan onze SOC2-vereisten te voldoen, hadden we een werkende oplossing nodig. Wat we met name nodig hadden, was een manier om de gegevens van onze klanten veilig, efficiënt en op een kosteneffectieve manier te repliceren naar een alternatieve AWS-regio. Het antwoord was om te doen wat Rewind zo goed doet: een back-up maken!
Laten we eens kijken hoe Elasticsearch werkt, hoe we het hebben gebruikt om veilig een back-up van gegevens te maken en ons huidige proces voor herstel na noodgevallen.
Momentopnamen
Eerst hebben we een snelle woordenschatles nodig. Back-ups in ES worden genoemd snapshots. Snapshots worden opgeslagen in een snapshot-repository. Er zijn meerdere soorten opslagplaatsen voor snapshots, waaronder een ondersteund door AWS S3. Aangezien S3 de mogelijkheid heeft om de inhoud ervan te repliceren naar een emmer in een andere regio, was het een perfecte oplossing voor dit specifieke probleem.
AWS ES wordt geleverd met een geautomatiseerde snapshot-repository die vooraf voor u is ingeschakeld. De repository is standaard geconfigureerd om elk uur snapshots te maken en u kunt er niets aan veranderen. Dit was een probleem voor ons omdat we een dagelijks snapshot verzonden naar een repository ondersteund door een van onze eigen S3-buckets, die was geconfigureerd om de inhoud ervan naar een andere regio te repliceren.
 |
| Lijst met geautomatiseerde snapshots GET _cat/snapshots/cs-automated-enc?v&s=id |
Onze enige keuze was om onze eigen snapshot-repository en snapshots te maken en te beheren.
Het onderhouden van onze eigen snapshot-repository was niet ideaal en klonk als een hoop onnodig werk. We wilden het wiel niet opnieuw uitvinden, dus gingen we op zoek naar een bestaande tool die het zware werk voor ons zou doen.
Snapshot levenscyclusbeheer (SLM)
De eerste tool die we probeerden was Elastic’s Snapshot levenscyclusbeheer (SLM)een functie die wordt beschreven als:
De eenvoudigste manier om regelmatig een back-up van een cluster te maken. Een SLM-beleid maakt automatisch snapshots volgens een vooraf ingesteld schema. Het beleid kan ook momentopnamen verwijderen op basis van bewaarregels die u definieert.
U kunt zelfs uw eigen snapshot-repository gebruiken. Zodra we echter probeerden dit in onze domeinen in te stellen, mislukte het. We kwamen er al snel achter dat AWS ES een aangepaste versie van Elastic is. co’s ES en dat SLM niet werd ondersteund in AWS ES.
Beheerder
De volgende tool die we hebben onderzocht heet Elasticsearch-curator. Het was open-source en werd door Elastic.co zelf onderhouden.
Curator is gewoon een Python-tool waarmee u uw indices en snapshots kunt beheren. Het heeft zelfs hulpmethoden voor het maken van aangepaste opslagplaatsen voor snapshots, wat een toegevoegde bonus was.
We hebben besloten om Curator uit te voeren als een Lambda-functie, aangedreven door een geplande EventBridge-regel, allemaal verpakt in AWS SAM.
Zo ziet de uiteindelijke oplossing eruit:
ES Snapshot Lambda-functie
De Lambda maakt gebruik van de Curator-tool en is verantwoordelijk voor snapshot- en repositorybeheer. Hier is een diagram van de logica:
Zoals je hierboven kunt zien, is het een heel eenvoudige oplossing. Maar om het te laten werken, hadden we een paar dingen nodig:
- IAM-rollen om machtigingen te verlenen
- Een S3-bucket met replicatie naar een andere regio
- Een Elasticsearch-domein met indexen
IAM-rollen
De S3SnapshotsIAMRole-beurzen beheerder de machtigingen die nodig zijn voor het maken van de snapshot-repository en het beheer van de daadwerkelijke snapshots zelf:
De EsSnapshotIAMRole-beurzen Lambda de machtigingen die de curator nodig heeft om te communiceren met het Elasticsearch-domein:
Gerepliceerde S3-emmers
Het team had eerder gerepliceerde S3-buckets voor andere services opgezet om replicatie tussen regio’s in Terraform te vergemakkelijken. (Meer info daarover hier)
Met alles op zijn plaats, verliep de cloudformation-stack die werd ingezet tijdens de eerste productietests goed en waren we klaar … of waren we?
Back-up en herstel-a-thon I
Een deel van de SOC2-certificering vereist dat u de back-ups van uw productiedatabase valideert voor alle kritieke services. Omdat we graag wat lol hebben, hebben we besloten om elk kwartaal een “Backup and Restore-a-thon” te houden. We zouden aannemen dat de oorspronkelijke regio verdwenen was en dat we elke database moesten herstellen van onze cross-regionale replica en de inhoud moesten valideren.
Je zou kunnen denken: “Oh my, dat is een hoop onnodig werk!” en je zou half gelijk hebben. Het is veel werk, maar het is absoluut noodzakelijk! In elke Restore-a-thon hebben we ten minste één probleem ontdekt met services waarvoor back-ups niet zijn ingeschakeld, niet weten hoe ze moeten herstellen of toegang krijgen tot de herstelde back-up. Om nog maar te zwijgen van de praktische training en ervaring die teamleden opdoen door daadwerkelijk iets te doen dat niet onder de hoge druk van een echte storing staat. Net als het houden van een brandoefening, helpen onze driemaandelijkse Restore-a-thons ons team voorbereid en klaar te houden om elke noodsituatie aan te pakken.
De eerste ES Restore-a-thon vond plaats maanden nadat de functie was voltooid en in productie was genomen, dus er werden veel snapshots gemaakt en veel oude verwijderd. We hebben de tool geconfigureerd om snapshots voor 5 dagen te bewaren en al het andere te verwijderen.
Elke poging om een gerepliceerde momentopname uit onze repository te herstellen, mislukte met een onbekende fout en er was niet veel anders om door te gaan.
Snapshots in ES zijn incrementeel, wat betekent dat hoe hoger de frequentie van snapshots, hoe sneller ze worden voltooid en hoe kleiner ze zijn. De eerste snapshot voor ons grootste domein duurde meer dan 1,5 uur om te voltooien en alle daaropvolgende dagelijkse snapshots duurden minuten!
Deze observatie bracht ons ertoe om te proberen de eerste snapshot te beschermen en te voorkomen dat deze werd verwijderd door een naamachtervoegsel (-initial) te gebruiken voor de allereerste snapshot die werd gemaakt na het maken van de repository. Die initiële snapshotnaam wordt dan uitgesloten van het snapshotverwijderingsproces door Curator met behulp van een regex-filter.
We hebben de S3-buckets, snapshots en repositories leeggemaakt en zijn opnieuw begonnen. Na een paar weken te hebben gewacht op het verzamelen van snapshots, mislukte het herstel opnieuw met dezelfde cryptische fout. Deze keer merkten we echter dat de eerste snapshot (die we beschermden) ook ontbrak!
Omdat er geen fietsen meer over waren om aan het probleem te besteden, moesten we het parkeren om aan andere coole en geweldige dingen te werken waar we hier aan werken op Terugspoelen.
Back-up en herstel-a-thon II
Voor je het weet begint het volgende kwartaal en is het tijd voor weer een Backup and Restore-a-thon en beseffen we dat dit nog een hiaat is in ons disaster recovery plan. We moeten de ES-gegevens in een andere regio met succes kunnen herstellen.
We hebben besloten om extra logging aan de Lambda toe te voegen en dagelijks de uitvoeringslogs te controleren. Dagen 1 tot 6 werken prima – herstelt het werk, we kunnen alle snapshots opsommen en de eerste is er nog steeds. Op de 7e dag gebeurde er iets vreemds – de oproep om de beschikbare snapshots weer te geven, leverde een “niet gevonden”-fout op voor alleen de eerste snapshot. Welke externe kracht verwijdert onze snapshots??
We hebben besloten om de inhoud van de S3-bucket nader te bekijken en te zien dat het allemaal UUID’s (Universally Unique Identifier) zijn met enkele objecten die correleren met back-snapshots, behalve de eerste snapshot die ontbrak.
We zagen de tuimelschakelaar “versies weergeven” in de console en vonden het vreemd dat versiebeheer op de bucket was ingeschakeld. We hebben de versie-omschakeling ingeschakeld en zagen onmiddellijk “Markeringen verwijderen” overal, inclusief een op de eerste snapshot die de hele snapshot-set beschadigde.
Voor na
We realiseerden ons al snel dat de S3-bucket die we gebruikten een levenscyclusregel van 7 dagen had die alle objecten die ouder waren dan 7 dagen opschoonde.
De levenscyclusregel bestaat zodat onbeheerde objecten in de buckets automatisch worden verwijderd om de kosten laag te houden en de bucket netjes te houden.
We hebben het verwijderde object hersteld en voila, de lijst met snapshots werkte prima. Het belangrijkste was dat de restauratie een succes was.
De thuisstretch
In ons geval moet Curator de levenscyclus van de momentopname beheren, dus alles wat we moesten doen was voorkomen dat de levenscyclusregel iets in onze opslagplaatsen voor momentopnamen verwijdert met behulp van een padfilter met een bereik op de regel.
We hebben een specifiek S3-voorvoegsel gemaakt met de naam “/auto-purge” waarop de regel is gericht. Alles ouder dan 7 dagen in /auto-purge zou worden verwijderd en al het andere in de bucket zou met rust worden gelaten.
We hebben alles weer opgeruimd, > 7 dagen gewacht, het herstel opnieuw uitgevoerd met de gerepliceerde snapshots, en uiteindelijk werkte het feilloos – Back-up en herstel-a-thon eindelijk voltooid!
Conclusie
Het bedenken van een rampherstelplan is een zware mentale oefening. Het implementeren en testen van elk onderdeel ervan is nog moeilijker, maar het is een essentiële zakelijke praktijk die ervoor zorgt dat uw organisatie elke storm kan doorstaan. Natuurlijk, een huisbrand is een onwaarschijnlijke gebeurtenis, maar als het toch gebeurt, zul je waarschijnlijk blij zijn dat je hebt geoefend wat je moet doen voordat de rook begint te golven.
Het verzekeren van bedrijfscontinuïteit in het geval van een uitval van een provider voor de kritieke delen van uw infrastructuur brengt nieuwe uitdagingen met zich mee, maar biedt ook geweldige mogelijkheden om oplossingen zoals de hier gepresenteerde te verkennen. Hopelijk helpt ons kleine avontuur je om de valkuilen te vermijden die we tegenkwamen bij het bedenken van je eigen Elasticsearch-noodherstelplan.
Opmerking – Dit artikel is geschreven en bijgedragen door Mandeep Khinda, DevOps Specialist bij Rewind.
