Si GitLab ndihmon në krijimin e backup-eve për depozita të mëdha në NextCloud

Përshëndetje, Habr!

Sot është fjala për përvojën tonë në automatizimin e kopjimit të të dhënave të mëdha në magazinat Nextcloud në konfiguracione të ndryshme. Unë punoj si CTO në "Mollia AK", ku merremi me menaxhimin e konfigurations të sistemeve IT, duke përdorur Nextcloud për ruajtjen e të dhënave. Kjo përfshin edhe një strukturë të shpërndarë me rezervim.

Problemet që burojnë nga veçoritë e instalimeve janë se ka shumë të dhëna. Versionimi që ofron Nextcloud, ruajtja, arsyet subjektive dhe çështje të tjera krijojnë shumë kopje të tepërta.

Pas historia

Gjatë administrimit të Nextcloud, ngushtohet problemi i organizimit të një backup-i efikas, i cili duhet të jetë patjetër i koduar, pasi të dhënat janë të çmuara.

Ne ofrojmë mundësi ruajtjeje të backup-it tek ne ose tek klienti në makinat e tij të veçanta nga Nextcloud, që kërkon një qasje automatizimi fleksibël në administrim.

Ka shumë klientë, të gjithë me konfiguracione të ndryshme, dhe secili në vendet e tij me veçoritë e tij. Këtu, metodologjia standarde kur e gjithë plataforma është e jotja dhe backup-et bëhen nga kroni, nuk përshtatet mirë.

Fillimisht, le të shohim të dhënat e hyrjes. Na nevojitet:

• Shtimi i kapacitetit për një nodë ose më shumë. Për instalime të mëdha, ne përdorim minio si depo.
• Të njoftoheni për problemet me realizimin e backup-it.
• Duhet të ruani backup në klientë dhe/apo në ne.
• Të zgjidhni shpejt dhe lehtësisht problemet.
• Klientët dhe instalimet dallojnë shumë nga njëra-tjetra — nuk arrijmë dot një uniformitet.
• Shpejtësia e rikuperimit duhet të jetë minimale në dy skenarë: rikuperim i plotë (katastrofë), një dosje — e fshirë aksidentalisht.
• Funksioni i dedupikimit është i detyrueshëm.

Për të menaxhuar backup-et, kemi integruar GitLab. Më shumë detaje më vonë.

Sigurisht, ne nuk jemi të parët që zgjidhim një problem të tillë, por besojmë se përvoja jonë praktike e fituar me mundim mund të jetë interesante dhe jemi të gatshëm ta ndajmë atë.

Duke qenë se në kompaninë tonë praktikohet politika e opensource, kërkuam një zgjidhje pikërisht me kod të hapur. Në të njëjtën mënyrë, ne ndajmë zhvillimet tona dhe i publikojmë. Për shembull, në GitHub ka pluginin tonë për Nextcloud, i cili e forcon ruajtjen e të dhënave në rast të fshirjes aksidentale ose qëllimisht.

Mjetet e backup-it

Kërkimi i metodave të zgjidhjes e filluam me zgjedhjen e një mjeti për krijimin e kopjeve rezervë.

Tar i zakonshëm + gzip funksionon keq — të dhënat rinovohen. Inkrementi shpesh përmban shumë pak ndryshime në fakt, dhe pjesa më e madhe e të dhënave brenda një skedari përsëritet.
Ka edhe një problem tjetër — tepricitet e ruajtjes së shpërndarë të të dhënave. Ne përdorim minio dhe të dhënat e tij janë në thelb tepricë. Ose duhej të bënim kopje rezervë përmes minio vetë – duke e ngarkuar atë dhe duke përdorur të gjitha ndërmjetësit midis sistemit të skedarëve, dhe çka është po aq e rëndësishme, ka rrezik të harrohet një pjesë e baketeve dhe informacionit meta. Ose të përdorim deduplication.

Mjetet për kopje rezervë me deduplication janë në open source (në Habr ishin artikullit në këtë temë) dhe finalistët tanë u bënë Borg dhe Restic. Më poshtë do të flasim për krahasimin e dy aplikacioneve, nd meanwhile do të tregojmë se si e organizuam gjithë skemën.

Menaxhimi i krijimit të kopjeve rezervë

Borg dhe Restic janë të mira, por asnjë nga produktet nuk ka një mekanizëm të centralizuar menaxhimi. Për qëllimin e menaxhimit dhe kontrollit, ne zgjodhëm një mjet të cilin e kemi tashmë të implementuar, pa të cilin nuk e imagjinonim punën tonë, përfshirë automatizimin — është CI/CD i njohur – GitLab.

Ideja është si më poshtë: në çdo nod që ruan të dhënat e Nextcloud vendoset gitlab-runner. Runner-i ekzekuton me një orar një skript që monitoron procesin e backup-it, dhe ai aktivizon Borg ose Restic.

Çfarë morëm? Kthim informacioni nga ekzekutimi, kontroll i lehtë mbi ndryshimet, detaje në rast gabimi.

Këtu është këtu në GitHub ne kemi publikuar shembuj të skripteve për detyra të ndryshme, dhe ne përfundimisht e lidhëm atë me backup-in jo vetëm të Nextcloud, por edhe të shumë shërbimeve të tjera. Po ashtu, aty është edhe planifikuesi, nëse nuk e doni ta konfigurooni me dorë (dhe ne nuk e duam) dhe .gitlab-ci.yml

Në API-në e GitLab-it, fatmirësisht, nuk ka mundësi për të ndryshuar kohën e pritjes CI/CD, dhe ajo është e vogël. Duhet ta rrisim, le të themi deri në 1d.

GitLab, fatmirësisht, mund të aktivizohet jo vetëm me commit, por edhe në një orar, kjo është pikërisht ajo që na nevojitet.

Tani për skriptin e mbështjellës.

Ne vendosëm këto kushte për këtë skript:

• Duhet të ekzekutohet si nga runner-i, ashtu edhe manualisht nga konsola me funksionalitet të njëjtë.
• Përveç kësaj, duhet të ketë trajtues gabimesh:
• kodin e kthimit.
• kërkimi i një linje në log. Për shembull, për ne, një mesazh që programi nuk e konsideron fatal mund të jetë një gabim.
• Trajtimi i timeout. Koha e ekzekutimit duhet të jetë e arsyeshme.
• Na nevojitet një log shumë më i detajuar. Por vetëm në rast të një gabimi.
• Po ashtu, kryhen një sërë testesh para fillimit.
• Një disa shtesa të vogla për lehtësinë, të cilat i kemi gjetur të dobishme gjatë mbështetjes:
• Fillimi dhe përfundimi regjistrohen në skedarin e sistemit të makinës lokale. Kjo ndihmon për të lidhur gabimet e sistemit me operimin e backup-it.
• Një pjesë e log-ëve të gabimeve, kur ato ekzistojnë, jepet në stdout, e gjithë log-u shkruhet në një skedar të veçantë. E lehtë për të parë menjëherë në CI dhe për të vlerësuar gabimin nëse është triviale.
• Modet për debagim.

Log-u i plotë ruhet si një artefakt në GitLab, nëse nuk ka gabime, atëherë log-u fshihet. Skripti shkruhet në bash.

Çdo propozim dhe vërejtje mbi open-source do të jemi të lumtur t'i shqyrtojmë - mirëseerdhët.

Si funksionon

Një runner me ekzekutorin bash niset në nodën e backup-it. Në planifikuesin në një rep të veçantë niset një punë CI/CD. Runner-i e nis skriptin si një mbulesë universale për këto detyra, në të zhvillohen kontrolli i vlefshmërisë së rep-it të backup-it, pikave të montimit dhe gjithçkaje që duam, pastaj realizohet backup-i dhe pastrimi i të vjetrave. Backup-i i gatshëm dërgohet në S3.

Ne punojmë sipas kësaj skeme - është një ofrues i jashtëm AWS ose një analoge ruse (është më e shpejtë dhe të dhënat nuk largohen nga RF). Ose i vendosim klientit një klaster të veçantë minio në hapësirën e tij për këto qëllime. Në përgjithësi, e bëjmë këtë për arsye sigurie, kur klienti nuk dëshiron aspak që të dhënat të dalin nga konturi i tij.

Ne nuk e përdorim veçorinë e dërgimit të backup-it përmes ssh. Kjo nuk shton siguri, dhe kapacitetet rrjetore të ofruesit S3 janë shumë më të larta se sa një makinë tonë ssh.

Për të mbrojtur nga hakerët në makinë lokale - pasi ai mund të fshijë të dhënat në S3, është domosdoshmërisht të aktivizoni versionimin.
Backup-i gjithmonë e enkripton backup-in.

Borg ka një mod të paedukuar none, por ne kategorikisht nuk e rekomandojmë aktivizimin e tij. Në këtë mod nuk do të ketë vetëm enkriptim, por as nuk llogaritet checksum-i i asaj që shkruhet, kështu që është e mundur të kontrolloni integritetin vetëm në mënyrë indirekte, nëpërmjet indekseve.

Kontrolli i backup-eve për integritetin e indekseve dhe përmbajtjes bëhet përmes një programatori të veçantë. Kontrolli ndodh ngadalë dhe gjatë, prandaj ne e aktivizojmë atë veçmas një herë në muaj. Mund të zgjasë disa ditë.

Lexo në shqip

Funksionet kryesore

• prepare përgatitja
• testcheck kontrolli i gatishmërisë
• komandë e parë komanda kryesore
• forcepostscript funksioni që ekzekutohet në fund ose në rast gabimi. Përdoret për të çmontuar ndarjen.

Funksionet e shërbimit

• cleanup regjistrojmë gabimet ose fshijmë skedarin e log.
• kontrollilog analizojmë logun për të gjetur stringun me gabim.
• ret menaxher i daljes.
• kontrollit të kohës kontrolli për kohëzgjatjen.

Mjedisi

• VERBOSE=1 shfaqim gabimet në ekran menjëherë (stdout).
• SAVELOGSONSUCCES=1 ruajmë logun kur jemi të suksesshëm.
• INIT_REPO_IF_NOT_EXIST=1 Krijojmë repository nëse nuk ka pasur. Në parazgjedhje është e fikur.
• KOHA koha maksimale për operacionin kryesor. Mund ta përcaktoni si ‘m’, ‘h’ ose ‘d’ në fund.

Rezi i ruajtjes së kopjeve të vjetra. Në parazgjedhje:

• MBYLL_DITORE=7
• MBYLL_JAVORE=4
• MBYLL_MUAJORE=6

Variablat brenda skriptit

• ERROR_STRING — string për kontrollin në log për gabim.
• EXTRACT_ERROR_STRING — shprehje për të shfaqur stringun në rast gabimi.
• KILL_TIMEOUT_SIGNAL — sinjali për të vrarë nëse ka kaluar koha.
• TAIL — sa shumë stringje me gabime në ekran.
• COLORMSG — ngjyra e mesazhit (default e verdhë).

Skedari i quajtur wordpress, ka funksionin se bën backup të bazës mysql. Kështu mund të përdoret për instalime të përkohshme të Nexcloud, ku gjithashtu mund të bëhet backup i bazës. Lehtësia nuk është vetëm në faktin se gjithçka është në një vend, por edhe përmbajtja e bazës është e afërt me përmbajtjen e skedarëve, pasi ndryshimi në kohë është minimal.

Restic vs Borg

Krahasimet midis Borg dhe Restic janë gjithashtu këtu në Habr, dhe ne nuk e patëm qëllim të bënim thjesht një tjetër, por tonin tonë. Ishte e rëndësishme për ne se si do të dukej në të dhënat tona, me specifikat tona. Ne i paraqesim ato.

Kriteret tona përzgjedhës, përveç atyre të përmendura më parë (deduplication, rikuperim i shpejtë, etj.):

• Qëndrueshmëria ndaj punës së papërfunduar. Kontrolli në kill -9.
• Madhësia në disk.
• Kërkesat për resurse (CPU, memorie).
• Madhësia e blob-eve të ruajtura.
• Puna me S3.
• Kontrolli i integritetit.

Për testim, morëm një klient me të dhëna reale dhe një madhësi totale prej 1.6TB.
Kushtet.

Borg nuk di të punojë drejtpërdrejt me S3, dhe ne e montuam si një disk fuse, përmes goofys. Restic e dërgonte drejtpërdrejt në S3.

Goofys punon shumë shpejt dhe mirë, dhe ka një modul të caches disk, që e acceleron edhe më shumë funksionimin. Ai është në fazën beta dhe, për ta pranuar, kemi pasur rënie me humbje të dhënash në testet (të tjera). Por e mira është se vetë procedura e backup-it nuk kërkon lexim të madh, kryesisht shkrim, ndaj ne përdorim vetëm cache gjatë verifikimit të integritetit.

Për të reduktuar ndikimin e rrjetit, kemi përdorur një ofrues lokal - Yandex Cloud.

Rezultatet e testeve të krahasimit.

• Kill -9 me rinisjen e mëtejshme, të dyja kaluan me sukses.
• Madhësia në disk. Borg mund të kompresojë, prandaj rezultatet janë të pritshme.

Backuper
Madhësia

Borg
562Gb

Restic
628Gb

• Për CPU
  Borg vetë konsumon pak, me kompresimin default, por duhet të vlerësohet së bashku me procesin goofys. Në tërësi janë krahasues dhe ushqejnë rreth 1,2 bërthamë në të njëjtën maqinë virtuale për testim.
• Memoria. Restic përafërsisht 0,5Gb, Borg rreth 200Mb. Por kjo është e parëndësishme krahasuar me cache-in e skedarëve të sistemit. Pra, është e dëshirueshme të ndahen më shumë memorje.
• Differenca në madhësinë e blob-ve u tregua e jashtëzakonshme.

Backuper
Madhësia

Borg
rreth 500Mb

Restic
rreth 5Mb

• Puna me S3 nga Restic është e shkëlqyer. Puna e Borg-it përmes goofys nuk ka probleme, por është vënë re se është e dëshirueshme që pas përfundimit të kopjimit të bëhet umount për të resetuar plotësisht cache-në. Karakteristika e punës me S3 është se copat e pamjaftueshme nuk do të dërgohen kurrë në bucket, që do të thotë se të dhënat e padërguara plotësisht çojnë në dëmtime të mëdha.
• Kontrolli i integritetit funksionon mirë në të dyja rastet, por shpejtësia ndryshon ndjeshëm.
  Restic – 3.5 orë.
  Borg, me cache skedash 100GB SSD – 5 orë.Rreth një rezultat të ngjashëm për shpejtësi nëse të dhënat ndodhen në diskun lokal.
  Borg lexon direkt nga S3 pa cache 33 orë. E tmerrshme e gjatë.

Në përfundim, Borg di të comprimojë dhe ka blob-e më të mëdha — që e bën ruajtjen dhe operacionet GET/PUT në S3 më të lira. Por për këtë duhen paguar kontrolli më i komplikuar dhe më i ngadalshëm. Sa i përket shpejtësisë së rikuperimit — nuk kemi vënë re ndonjë ndryshim. Kopjimet e mëpasshme (pas të parës) restic i bën disi më gjatë, por jo ndjeshëm.

Pesha e komunitetit nuk ishte në vend të fundit në zgjedhje.

Dhe ne zgjodhëm borg.

Disa fjalë në lidhje me kompresimin

Borg ka një algoritëm të mrekullueshëm kompresimi të ri - zstd. Në cilësinë e kompresimit nuk është më i keq se gzip, por është ndjeshëm më i shpejtë. Dhe është krahasues në shpejtësi me lz4-në e paracaktuar.

Për shembull, një dump i bazës MySQL comprimon rreth dy herë më mirë se lz4 me të njëjtën shpejtësi. Megjithatë, përvoja me të dhëna reale tregon se ka një ndryshim shumë të vogël në degëzimin e nodit Nextcloud.

Në Borg ka një modifikim bonus të kompresimit - nëse skedari ka entropi të lartë, kompresimi nuk aplikohet fare, gjë që rrit shpejtësinë e funksionimit. Aktivizohet me opsionin gjatë krijimit.
-C auto,zstd
për algoritmin zstd.
Tani, me këtë opsion, në krahasim me kompresimin e paracaktuar, ne morëm
560Gb dhe 562Gb përkatësisht. Të dhënat nga shembulli më sipër, kujtoj, pa kompresim rezultati ishte 628Gb. Rezultati me diferencën prej 2Gb na befasoi pak, por vendosëm që të zgjidhim gjithsesi auto,zstd..

Metodika e verifikimit të backup-it.

Përmes planifikuesit, një virtualizim nis direkt te ofruesi ose te klienti, gjë që ul ndjeshëm ngarkesën rrjetore. Të paktën është më e lirë se sa ta ngresh vetë dhe të ushqesh trafik.

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/

Me të njëjtën skemë ne kontrollojmë skedarët me antivirus (post faktum). Përdoruesit ngarkojnë të ndryshme në Nextcloud dhe jo të gjithë kanë antivirus. Të kryesh verifikimin në momentin e ngarkesës merr shumë kohë dhe pengon biznesin.

Mundësia për shkallëzim arrihet duke nisur runner-a në node të ndryshme me etiketa të ndryshme.
Në monitorimin tonë mblidhen statuset e backup-eve përmes API-së së GitLab në një dritare, dhe në rast nevoja problemet njihen lehtësisht dhe po ashtu lokalizohen.

Përfundimi

Si përfundim, ne e dimë saktësisht që bëjmë backup-e, që backup-et tona janë valide, problemet që lidhen me to kërkojnë pak kohë dhe zgjidhen në nivelin e administratorit të shërbimit. Backup-et realisht marrin pak hapësirë në krahasim me tar.gz ose Bacula.

Burimi: habr.com