Hoe GitLab jou help om groot NextCloud-bergings te rugsteun

Haai Habr!

Vandag wil ek praat oor ons ervaring in die outomatisering van die rugsteun van groot data vanaf Nextcloud-bergings in verskillende konfigurasies. Ek werk as 'n diensstasie by Molniya AK, waar ons konfigurasiebestuur van IT-stelsels doen; Nextcloud word vir databerging gebruik. Insluitend, met 'n verspreide struktuur, met oortolligheid.

Die probleme wat voortspruit uit die kenmerke van die installasies is dat daar baie data is. Weergawe wat deur Nextcloud verskaf word, oortolligheid, subjektiewe redes en meer skep baie duplikate.

voorgeskiedenis

Wanneer Nextcloud geadministreer word, ontstaan ​​die probleem om 'n effektiewe rugsteun te organiseer, wat geïnkripteer moet word, aangesien die data waardevol is.

Ons bied opsies vir die stoor van rugsteun by ons of by die kliënt op aparte masjiene van Nextcloud, wat 'n buigsame outomatiese benadering tot administrasie vereis.

Daar is baie kliënte, almal met verskillende konfigurasies, en almal op hul eie webwerwe en met hul eie kenmerke. Dit is 'n standaardtegniek wanneer die hele webwerf aan jou behoort, en rugsteun van krone gemaak word; dit pas nie goed nie.

Kom ons kyk eers na die invoerdata. Ons benodig:

• Skaalbaarheid in terme van een nodus of meer. Vir groot installasies gebruik ons ​​minio as berging.
• Vind uit oor probleme met die uitvoer van rugsteun.
• Jy moet 'n rugsteun by jou kliënte en/of by ons hou.
• Hanteer probleme vinnig en maklik.
• Kliënte en installasies verskil baie van mekaar – eenvormigheid kan nie bereik word nie.
• Die herstelspoed moet minimaal wees in twee scenario's: volle herstel (ramp), een gids wat per ongeluk uitgevee is.
• Dedupliseringsfunksie word vereis.

Om die probleem van die bestuur van rugsteun op te los, het ons GitLab geïnstalleer. Meer besonderhede per pak.

Ons is natuurlik nie die eerste om so 'n probleem op te los nie, maar dit lyk vir ons of ons praktiese, swaarverdiende ervaring interessant kan wees en ons is gereed om dit te deel.

Aangesien ons maatskappy 'n oopbronbeleid het, was ons op soek na 'n oopbronoplossing. Op ons beurt deel ons ons ontwikkelings en plaas dit. Byvoorbeeld, op GitHub is daar ons inprop vir Nextcloud, wat ons aan kliënte verskaf, wat datasekuriteit verbeter in geval van toevallige of opsetlike uitvee.

Rugsteungereedskap

Ons het ons soektog na oplossingsmetodes begin deur 'n hulpmiddel vir die skep van rugsteun te kies.

Gereelde tar + gzip werk nie goed nie - die data is gedupliseer. 'n Inkrement bevat dikwels baie min werklike veranderinge, en baie van die data binne 'n enkele lêer word herhaal.
Daar is nog 'n probleem - oortolligheid van verspreide databerging. Ons gebruik minio en sy data is basies oorbodig. Of jy moes 'n rugsteun deur minio self maak - laai dit en gebruik al die spasies tussen die lêerstelsel, en, nie minder belangrik nie, is daar 'n risiko om van die emmers en meta-inligting te vergeet. Of gebruik deduplisering.

Rugsteunnutsgoed met duplisering is beskikbaar in oopbron (op Habré was daar Artikel oor hierdie tema) en ons finaliste was Borg и Plaatlik. Ons vergelyking van die twee toepassings is hieronder, maar vir nou sal ons jou vertel hoe ons die hele skema georganiseer het.

Bestuur van rugsteun

Borg en Restic is goed, maar nie een van die produkte het 'n gesentraliseerde beheermeganisme nie. Vir die doel van bestuur en beheer het ons 'n instrument gekies wat ons reeds geïmplementeer het, waarsonder ons ons nie ons werk kan voorstel nie, insluitend outomatisering - dit is die bekende CI/CD - GitLab.

Die idee is soos volg: gitlab-runner is geïnstalleer op elke nodus wat Nextcloud-data stoor. Die hardloper laat 'n skrif op 'n skedule loop wat die rugsteunproses monitor, en dit begin Borg of Restic.

Wat het ons gekry? Terugvoer van uitvoering, gerieflike beheer oor veranderinge, besonderhede in geval van 'n fout.

Hier hier op GitHub ons het voorbeelde van die skrif vir verskeie take geplaas, en ons het dit uiteindelik aan die rugsteun van nie net Nextcloud nie, maar ook baie ander dienste geheg. Daar is ook 'n skeduleerder daar as jy dit nie handmatig wil konfigureer nie (en ons wil nie) en .gitlab-ci.yml

Daar is nog geen manier om die CI/CD-timeout in die Gitlab API te verander nie, maar dit is klein. Dit moet verhoog word, sê maar 1d.

GitLab kan gelukkig nie net volgens 'n commit begin nie, maar slegs volgens 'n skedule, dit is presies wat ons nodig het.

Nou oor die wikkelskrif.

Ons stel die volgende voorwaardes vir hierdie skrif:

• Dit moet beide deur die hardloper en met die hand vanaf die konsole met dieselfde funksionaliteit bekendgestel word.
• Daar moet fouthanteerders wees:
• kode terug.
• soek vir 'n string in die log. Byvoorbeeld, vir ons kan 'n fout 'n boodskap wees wat die program nie as noodlottig beskou nie.
• Verwerking uitteltyd. Die deurlooptyd moet redelik wees.
• Ons benodig 'n baie gedetailleerde logboek. Maar slegs in die geval van 'n fout.
• 'n Aantal toetse word ook uitgevoer voordat daar begin word.
• Klein bonusse vir gerief wat ons nuttig gevind het tydens die ondersteuningsproses:
• Die begin en einde word in die syslog van die plaaslike masjien aangeteken. Dit help om stelselfoute en rugsteunwerking aan te sluit.
• Deel van die foutlogboek, indien enige, word na stdout uitgevoer, die hele log word na 'n aparte lêer geskryf. Dit is gerieflik om dadelik na CI te kyk en die fout te evalueer as dit triviaal is.
• Ontfoutingsmodusse.

Die volledige log word gestoor as 'n artefak in GitLab; as daar geen fout is nie, word die log uitgevee. Ons skryf die draaiboek in bash.

Ons sal graag enige voorstelle en opmerkings rakende oopbron oorweeg - welkom.

Hoe werk dit

'n Hardloper met 'n Bash-uitvoerder word op die rugsteunnodus geloods. Volgens die skeduleerder word werk CI/CD in 'n spesiale raap bekendgestel. Die hardloper loods 'n universele omhulskrif vir sulke take, dit kontroleer die geldigheid van die rugsteunbewaarplek, monteerpunte en alles wat ons wil hê, maak dan 'n rugsteun en maak die ou een skoon. Die voltooide rugsteun self word na S3 gestuur.

Ons werk volgens hierdie skema - dit is 'n eksterne AWS-verskaffer of 'n Russiese ekwivalent (dit is vinniger en die data verlaat nie die Russiese Federasie nie). Of ons installeer 'n aparte minio-kluster vir die kliënt op sy webwerf vir hierdie doeleindes. Ons doen dit gewoonlik om sekuriteitsredes, wanneer die kliënt glad nie wil hê dat die data hul kring verlaat nie.

Ons het nie die kenmerk gebruik om rugsteun via ssh te stuur nie. Dit voeg nie sekuriteit by nie, en die netwerkvermoëns van die S3-verskaffer is baie hoër as ons een ssh-masjien.

Om jou plaaslike masjien teen 'n hacker te beskerm, aangesien hy data op S3 kan uitvee, moet jy weergawebeheer aktiveer.
Die rugsteun enkripteer altyd die rugsteun.

Borg het 'n ongeënkripteerde modus none, maar ons beveel sterk nie aan om dit aan te skakel nie. In hierdie modus sal daar nie net geen enkripsie wees nie, maar die kontrolesom van wat geskryf word, word nie bereken nie, wat beteken dat integriteit slegs indirek nagegaan kan word, met behulp van indekse.

'n Aparte skeduleerder kontroleer rugsteun vir die integriteit van indekse en inhoud. Die tjek is stadig en lank, so ons voer dit een keer per maand afsonderlik uit. Dit kan 'n paar dae neem.

Lees my in Russies

Hoof funksies

• prepare opleiding
• testcheck gereedheidskontrole
• maincommand Kern span
• forcepostscript 'n funksie wat op die ou end of per fout uitgevoer word. Ons gebruik dit om die partisie te ontkoppel.

Diensfunksies

• cleanup Ons teken foute aan of vee die loglêer uit.
• checklog ontleed die log vir die voorkoms van 'n reël met 'n fout.
• ret uitgang hanteerder.
• checktimeout kyk vir time-out.

omgewing

• VERBOSE=1 Ons vertoon foute onmiddellik op die skerm (stdout).
• SAVELOGSONSUCCES=1 stoor die log by sukses.
• INIT_REPO_IF_NOT_EXIST=1 Skep 'n bewaarplek as dit nie bestaan ​​nie. By verstek gedeaktiveer.
• TIMEOUT maksimum tyd vir die hoofoperasie. Jy kan dit aan die einde as 'm', 'h' of 'd' stel.

Bergingsmodus vir ou kopieë. Verstek:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Veranderlikes binne die skrif

• ERROR_STRING - string vir die aanmeldlog vir fout.
• EXTRACT_ERROR_STRING - uitdrukking vir wys string as fout.
• KILL_TIMEOUT_SIGNAL - sein vir doodmaak as uitteltyd.
• TAIL - hoeveel stringe met foute op die skerm.
• COLORMSG - kleur van boodskap (verstek geel).

Daardie script, wat wordpress genoem word, het 'n voorwaardelike naam, sy truuk is dat dit ook die mysql-databasis rugsteun. Dit beteken dat dit gebruik kan word vir enkel-node Nexcloud-installasies, waar jy ook die databasis kan rugsteun. Die gerief is nie net dat alles op een plek is nie, maar ook die inhoud van die databasis is naby aan die inhoud van die lêers, aangesien die tydsverskil minimaal is.

Restic vs Borg

Daar is ook vergelykings tussen Borg en Restic hier op Habré, en ons het nie die taak gehad om net nog een te maak nie, maar ons eie. Dit was vir ons belangrik hoe dit op ons data sou lyk, met ons besonderhede. Ons bring hulle.

Ons seleksiekriteria, benewens dié wat reeds genoem is (deduplisering, vinnige herstel, ens.):

• Weerstand teen onvoltooide werk. Kyk vir doodmaak -9.
• Grootte op skyf.
• Vereiste vir hulpbronne (SVE, geheue).
• Grootte van gestoorde blobs.
• Werk met S3.
• Integriteitskontrole.

Vir toetsing het ons een kliënt met regte data en 'n totale grootte van 1,6 TB geneem.
Voorwaardes.

Borg weet nie hoe om direk met S3 te werk nie, en ons het die skyf as 'n lont gemonteer, via goofies. Restic het dit na S3 self gestuur.

Goofys werk baie vinnig en goed, en daar is skyfkasmodule, wat die werk nog meer bespoedig. Dit is in die beta-stadium, en eerlikwaar, ons het tydens toetse (ander) met dataverlies neergestort. Maar die gerief is dat die rugsteunprosedure self nie veel lees vereis nie, maar meestal skryf, dus gebruik ons ​​die kas slegs tydens integriteitskontroles.

Om die invloed van die netwerk te verminder, het ons 'n plaaslike verskaffer gebruik - Yandex Cloud.

Vergelyking toets resultate.

• Kill -9 met 'n verdere herbegin was albei suksesvol.
• Grootte op skyf. Borg kan saamdruk, so die resultate is soos verwag.

Rugsteun
Grootte

Borg
562Gb

Plaatlik
628Gb

• Deur SVE
  Borg self verbruik min, met verstekkompressie, maar dit moet saam met die goofys-proses geëvalueer word. In totaal is hulle vergelykbaar en gebruik ongeveer 1,2 kerne op dieselfde virtuele toetsmasjien.
• Geheue. Restic is ongeveer 0,5 GB, Borg is ongeveer 200 MB. Maar dit is alles onbeduidend in vergelyking met die stelsel lêer kas. Dit is dus raadsaam om meer geheue toe te ken.
• Die verskil in blobgrootte was treffend.

Rugsteun
Grootte

Borg
ongeveer 500 MB

Plaatlik
ongeveer 5 MB

• Die ervaring met Restic se S3 is uitstekend. Werk met Borg deur goofys laat geen vrae ontstaan ​​nie, maar daar is opgemerk dat dit raadsaam is om umount te doen nadat die rugsteun voltooi is om die kas heeltemal terug te stel. Die eienaardigheid van S3 is dat ondergepompte stukke nooit na die emmer gestuur sal word nie, wat beteken dat onvolledig gevulde data tot groot skade lei.
• Die integriteitskontrole werk goed in beide gevalle, maar die spoed verskil aansienlik.
  Rustig 3,5 uur.
  Borg, met 'n 100GB SSD-lêerkas - 5 uur.Ongeveer dieselfde spoed resultaat as die data op 'n plaaslike skyf is.
  Borg lees direk vanaf S3 sonder kas 33 uur. Monsterlik lank.

Die kern van die saak is dat Borg kan saamdruk en groter blobs het - wat berging en GET/PUT-bewerkings in S3 goedkoper maak. Maar dit kom ten koste van meer komplekse en stadiger verifikasie. Wat die herstelspoed betref, het ons geen verskil opgemerk nie. Restic neem die daaropvolgende rugsteun (na die eerste) 'n bietjie langer, maar nie aansienlik nie.

Laaste maar nie die minste in die keuse was die grootte van die gemeenskap.

En ons het borg gekies.

'n Paar woorde oor kompressie

Borg het 'n uitstekende nuwe kompressie-algoritme in sy arsenaal - zstd. Die kompressiekwaliteit is nie erger as gzip nie, maar baie vinniger. En vergelykbaar in spoed met die verstek lz4.

Byvoorbeeld, 'n MySQL-databasisstorting word twee keer beter as lz4 saamgepers teen dieselfde spoed. Ervaring met werklike data toon egter dat daar baie min verskil is in die kompressieverhouding van die Nextcloud-knooppunt.

Borg het 'n taamlike bonus-kompressiemodus - as die lêer 'n hoë entropie het, word kompressie glad nie toegepas nie, wat die spoed verhoog. Geaktiveer deur opsie tydens skep
-C auto,zstd
vir die zstd-algoritme
So met hierdie opsie, in vergelyking met die verstekkompressie, het ons
560Gb en 562Gb onderskeidelik. Die data uit die voorbeeld hierbo, laat ek jou herinner, sonder kompressie is die resultaat 628Gb. Die resultaat van 'n verskil van 2 GB het ons ietwat verras, maar ons het gedink dat ons dit tog sou kies. auto,zstd.

Rugsteun verifikasie metode

Volgens die skeduleerder word die virtuele masjien direk vanaf die verskaffer of vanaf die kliënt geloods, wat die netwerklading aansienlik verminder. Dit is darem goedkoper as om dit self te verhoog en verkeer te bestuur.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

Deur dieselfde skema te gebruik, gaan ons lêers na met 'n antivirus (na die tyd). Gebruikers laai immers verskillende dinge na Nextcloud op en nie almal het 'n antivirus nie. Om inspeksies uit te voer ten tyde van skink neem te veel tyd in beslag en meng met besigheid in.

Skaalbaarheid word bereik deur hardlopers op verskillende nodusse met verskillende etikette te laat loop.
Ons monitering versamel rugsteunstatusse via die GitLab API in een venster; indien nodig, word probleme maklik opgemerk en net so maklik gelokaliseer.

Gevolgtrekking

Gevolglik weet ons vir seker dat ons rugsteun maak, dat ons rugsteun geldig is, probleme wat daarmee opduik neem min tyd en word op die vlak van die diensadministrateur opgelos. Rugsteun neem baie min spasie op in vergelyking met tar.gz of Bacula.

Bron: will.com