ProHoster > Blog > Administrim > Si si GitLab ndihmon në krijimin e backup-eve për depo të mëdha NextCloud

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

Përshëndetje, Habr!

Sot dëshiroj të flas për përvojën tonë në automatizimin e ruajtjes së rezervave të të dhënave të mëdha të depozitave Nextcloud në konfiguracione të ndryshme. Unë punoj si CTO në "Molinia AK", ku merremi me menaxhimin e konfigurimeve të sistemeve IT; për ruajtjen e të dhënave përdoret Nextcloud, përfshirë një strukturë të shpërndarë me rezervim.

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

Historia e mëparshme

Gjatë administrimit të Nextcloud, del në pah problemi i organizimit të një ruajtjeje efektive që duhet patjetër të jetë e kriptuar, pasi të dhënat janë të vlefshme.

Ne ofrojmë opsione për ruajtjen e backups te ne ose te klienti në makinat e tij të ndara nga Nextcloud, çka kërkon një qasje fleksibile dhe të automatizuar ndaj administrimit.

Ka shumë klientë, të gjithë me konfigurime të ndryshme, dhe çdo njëri në platformat e veta dhe me veçoritë e veta. Këtu, metodika standarde kur e gjithë platforma ju takon, dhe backups bëhen nga crontab, nuk funksionon mirë.

Së pari, le të shohim të dhënat hyrëse. Na duhen:

  • ShkallĂ«zueshmĂ«ria nĂ« aspektin e njĂ« nodi ose disa. PĂ«r instalime tĂ« mĂ«dha, ne pĂ«rdorim minio si depo.
  • TĂ« jemi nĂ« dijeni tĂ« problemeve me ekzekutimin e backup-eve.
  • Duhet tĂ« ruajmĂ« backup te klientĂ«t dhe e ne.
  • TĂ« zgjidhim shpejt dhe lehtĂ« problemet.
  • KlientĂ«t dhe instalimet dallojnĂ« shumĂ« nga njĂ«ri-tjetri — nuk arrihet njĂ«llojshmĂ«ri.
  • ShpejtĂ«sia e rikuperimit duhet tĂ« jetĂ« minimale nĂ« dy skenarĂ«: rikuperimi i plotĂ« (disaster), njĂ« dosje — e fshirĂ« gabimisht.
  • Funksioni i deduplication-it Ă«shtĂ« i detyrueshĂ«m.

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

Për të zgjidhur problemin e menaxhimit të backup-eve, ne lidhem me GitLab. Më shumë në lidhje me këtë më poshtë.

Sigurisht, nuk jemi të parët që zgjidhim një problem të tillë, por na duket se përvoja jonë praktike e vuajtur mund të jetë e interesantë dhe jemi të gatshëm ta ndajmë atë.

Duke pasur parasysh se në kompaninë tonë është miratuar politika e opensource, ne kërkuam një zgjidhje me kod të hapur. Në këmbim, ne ndajmë zhvillimet tona dhe i publikojmë ato. Për shembull, në GitHub ka pluginin tonë për Nextcloud, të cilin e instalojmë te klientët, duke forcuar ruajtjen e të dhënave në rast të fshirjes aksidentale ose të qëllimshme.

Mjetet e backup-it

Kërkimi i metodave për zgjidhje e filluam me zgjedhjen e mjetit për krijimin e backup-it.

Tar-i i zakonshĂ«m + gzip nuk funksionon mirĂ« — tĂ« dhĂ«nat janĂ« tĂ« dyfishta. Inkremeti shpesh pĂ«rmban shumĂ« pak ndryshime nĂ« fakt, dhe shumica e tĂ« dhĂ«nave brenda njĂ« skedari pĂ«rsĂ«ritet.
Ka njĂ« tjetĂ«r problem — redundanca e ruajtjes sĂ« shpĂ«rndarĂ« tĂ« tĂ« dhĂ«nave. Ne pĂ«rdorim minio dhe tĂ« dhĂ«nat e tij nĂ« parim janĂ« tĂ« tepĂ«rta. Ose duhej bĂ«rĂ« backup pĂ«rmes vetĂ« minio – duke e ngarkuar atĂ« dhe duke pĂ«rdorur tĂ« gjitha lidhjet midis sistemit tĂ« skedarĂ«ve, dhe çfarĂ« nuk Ă«shtĂ« mĂ« pak e rĂ«ndĂ«sishme, ka rrezik tĂ« harrohet pĂ«r disa ndĂ«rtesa dhe meta-informacione. Ose tĂ« pĂ«rdorim deduplikimin.

Mjetet e backup-it me deduplikim ekzistojnë në open source (kanë qenë në habrë artikulli në këtë temë) dhe finalistët tanë u bënë Borg dhe Restic. Për krahasimin tonë të dy aplikacioneve më poshtë, ndërsa për tani do të flasim 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 qĂ« tashmĂ« Ă«shtĂ« implementuar, pa tĂ« cilin nuk e imagjinojmĂ« punĂ«n tonĂ«, pĂ«rfshirĂ« automatizimin – ky Ă«shtĂ« CI/CD i njohur – GitLab.

Ideja qëndron në këtë: në çdo nodë që ruan të dhëna Nextcloud vendoset gitlab-runner. Runner-i nis në një orar skenarin që mbikëqyr procesin e backup-it, dhe ai nis Borg ose Restic.

ÇfarĂ« morĂ«m? NjĂ« feedback nga realizimi, kontroll tĂ« rehatshĂ«m mbi ndryshimet, detaje nĂ« rast tĂ« gabimit.

Ja këtu në GitHub ne kemi publikuar shembuj të skenarëve për detyra të ndryshme, dhe ne në përfundim e lidhëm me backup-in jo vetëm të Nextcloud, por edhe të shumë shërbimeve të tjera. Atje ndodhet gjithashtu planifikuesi, nëse nuk doni ta konfiguroni manualisht (e as ne nuk duam) dhe .gitlab-ci.yml

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

Fatmirësisht, GitLab di të nisë jo vetëm me commit-et, por edhe sipas orarit, kjo është pikërisht ajo që na nevoitet.

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

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

  • Duhet tĂ« nisĂ« si me runner-in, ashtu edhe me duar nga konsola me funksionalitet tĂ« njĂ«jtĂ«.
  • Duhen patjetĂ«r trajtues tĂ« gabimeve:
  • return code.
  • kĂ«rkimi i njĂ« string nĂ« log. PĂ«r shembull, pĂ«r ne njĂ« gabim mund tĂ« jetĂ« njĂ« mesazh qĂ« programi nuk e konsideron fatale.
  • Trajtimi i timeout. Koha e ekzekutimit duhet tĂ« jetĂ« e arsyeshme.
  • Na nevojitet njĂ« log mĂ« i detajuar. Por vetĂ«m nĂ« rast tĂ« gabimit.
  • Gjithashtu, bĂ«het njĂ« sĂ«rĂ« testesh para fillimit.
  • PĂ«rfitime tĂ« vogla pĂ«r lehtĂ«sim, qĂ« i kemi gjetur tĂ« dobishme gjatĂ« mbĂ«shtetjes:
  • Fillimi dhe pĂ«rfundimi regjistrohen nĂ« logun e makinĂ«s lokale. Kjo ndihmon nĂ« lidhjen e gabimeve tĂ« sistemit me funksionimin e backupit.
  • NjĂ« pjesĂ« e logut tĂ« gabimeve, kur ka, jepet nĂ« stdout, i gjithĂ« logu shkruhet nĂ« njĂ« skedĂ« tĂ« veçantĂ«. ËshtĂ« e lehtĂ« tĂ« shikoni menjĂ«herĂ« nĂ« CI dhe tĂ« vlerĂ«soni gabimin nĂ«se Ă«shtĂ« triviale.
  • Modet pĂ«r debuggim.

Logu i plotë ruhet si një artefakt në GitLab, nëse nuk ka gabime, atëherë logu fshihet. Skripti shkruhet në bash.

Çdo propozim dhe vĂ«rejtje mbi opensource do t'ishim tĂ« lumtur t'i shqyrtonim — e mirĂ«pritur.

Si funksionon kjo

Në nodën që bëhet backup, nis një runner me ekzekutuesin bash. Në planifikues në një repo të veçantë aktivizohet job CI/CD. Runner-i nis skriptin si një mbështjellës universal për këto detyra, në të kalon verifikime të vlefshmërisë së repository-t të backupit, pika të montimit dhe gjithçka që dëshirojmë, pastaj realizohet backupimi dhe pastrimi i të vjetrit. Backup-i përfundimtar dërgohet në S3.

Ne punojmĂ« sipas kĂ«saj skeme — kjo Ă«shtĂ« njĂ« ofrues i jashtĂ«m AWS ose njĂ« analog rus (kjo Ă«shtĂ« mĂ« e shpejtĂ« dhe tĂ« dhĂ«nat nuk e braktisin RF-in). Ose i instalojmĂ« klientit njĂ« klaster tĂ« veçantĂ« minio nĂ« vendin e tij pĂ«r kĂ«to qĂ«llime. Zakonisht kĂ«shtu bĂ«jmĂ« pĂ«r arsye sigurie, kur klienti nuk dĂ«shiron qĂ« tĂ« dhĂ«nat tĂ« braktisin konturin e tij.

Nuk kemi përdorur funksionin e dërgimit të backupit përmes ssh. Kjo nuk shton siguri, dhe kapacitetet rrjetërore të ofruesit S3 janë shumë më të larta se një makinë tonë ssh.

PĂ«r tĂ« siguruar nga hakerĂ«t nĂ« makinĂ«n lokale — sepse ai mund tĂ« fshijĂ« tĂ« dhĂ«nat nĂ« S3, Ă«shtĂ« e domosdoshme tĂ« aktivizohet versionimi.
Backup-i gjithmonë e enkripton backup-in.

Borg ka një mod pa enkriptim none, por ne e rekomandojmë kategorikisht që të mos aktivizohet. Në këtë mod nuk do të ketë vetëm enkriptim, por ashtu nuk llogaritet checksum-i i asaj që shkruhet, dhe kështu integriteti mund të verifikohet vetëm në mënyrë indirekte, nëpërmjet indekseve.

Një kontroll i veçantë bëhet për integritetin e backupëve në indekse dhe përmbajtje. Kontrolli zhvillohet ngadalë dhe për një kohë të gjatë, prandaj ne e aktivizojmë atë veçmas një herë në muaj. Mund të zgjasë disa ditë.

Readme në rusisht

Funksionet kryesore

  • prepare pĂ«rgatitja
  • testcheck kontrolli i gatishmĂ«risĂ«
  • komandĂ« kryesore komanda bazĂ«
  • forco postskript njĂ« funksion qĂ« ekzekutohet nĂ« fund ose nĂ« rast tĂ« njĂ« gabimi. PĂ«rdoret pĂ«r tĂ« çmontuar seksionin.

Funksionet e shërbimit

  • cleanup shkruajmĂ« gabimet ose fshijmĂ« skedarin e logut.
  • kontrollo logun parsim logun pĂ«r tĂ« gjetur njĂ« varg me gabim.
  • kthehu menaxhuesi i daljes.
  • kontrollo kohĂ«n e shkaktuar kontrolli pĂ«r skadimin e kohĂ«s.

Mjedisi

  • VERBOSE=1 shfaqim gabimet menjĂ«herĂ« nĂ« ekran (stdout).
  • SAVELOGSONSUCCES=1 ruaj logun nĂ« rast suksesi.
  • INIT_REPO_IF_NOT_EXIST=1 KrijojmĂ« depo, nĂ«se ajo nuk ekziston. NĂ« mĂ«nyrĂ« default Ă«shtĂ« e çaktivizuar.
  • SKADIMI I KOHËS koha maksimale pĂ«r operacionin kryesor. Mund ta vendosni si ‘m’, ‘h’ ose ‘d’ nĂ« fund.

Rekrihimi i kopjeve të vjetra. Në mënyrë default:

  • MBAJ DITORE=7
  • MBAJ JAVORE=4
  • MBAJ MUJORE=6

Variablat brenda skriptit

  • ERROR_STRING — vargu pĂ«r kontrollin nĂ« log pĂ«r gabim.
  • EXTRACT_ERROR_STRING — shprehje pĂ«r shfaqjen e vargut nĂ« rast gabimi.
  • KILL_TIMEOUT_SIGNAL — sinjali pĂ«r tĂ« vrarĂ« nĂ«se skadon koha.
  • KURSIM — sa shumĂ« vargje me gabime nĂ« ekran.
  • COLORMSG — ngjyra e mesazhit (e verdhĂ« nĂ« mĂ«nyrĂ« default).

Ky skript, i quajtur wordpress, ka një emër të caktuar, dhe karakteristika e tij është se ai gjithashtu bën backup të bazës mysql. Kështu, mund të përdoret për instalime njëniveçare të Nexcloud, ku mund të bëhet edhe backup i bazës. Lehtësia nuk është vetëm në mënyrë që gjithçka të jetë në një vend, por edhe përmbajtja e bazës është e afërt me përmbajtjen e skedave, pasi diferenca e kohës është minimale.

Restic vs Borg

Krahasimi midis Borg dhe Restic është gjithashtu këtu në Habré, dhe s'kishim qëllim të bënim thjesht një tjetër, por tonin. Na interesonte si do të dukej ajo në të dhënat tona, me specifikat tona. Ne i paraqesim.

Kriteret tona të zgjedhjes, përveç atyre që u përmendën tashmë (deduplication, rikuperim të shpejtë etj.):

  • QĂ«ndrueshmĂ«ria ndaj punĂ«s sĂ« ndĂ«rprerĂ«. Kontrollimi pĂ«r kill -9.
  • MadhĂ«sia nĂ« disk.
  • KĂ«rkesat pĂ«r burime (CPU, memorie).
  • MadhĂ«sia e blloqeve 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, prandaj e montuam si disk fuse, përmes goofys. Restic dërgoi në S3 vetë.

Goofys punon shumë shpejt dhe mirë, dhe ka modulin e caches disk, që gjithashtu e përshpejton punën. Ai është në fazën beta, por, të pranoj, kishte rënien me humbje të të dhënave në testet (të tjera). Por lehtësia është se vetë procedura e backup-it nuk kërkon shumë lexim, përkundrazi shkrim, prandaj cache-in e përdorim vetëm gjatë kontrollit të integritetit.

PĂ«r tĂ« reduktuar ndikimin e rrjetit, pĂ«rdorĂ«m njĂ« ofrues vendor — Yandex Cloud.

Rezultatet e testimit të krahasimit.

  • Kill -9 me rinisje mĂ« pas, tĂ« dy kaluan me sukses.
  • MadhĂ«sia nĂ« disk. Borg di tĂ« kompresojĂ«, prandaj rezultatet janĂ« tĂ« pritura.

Backuper
Madhësia

Borg
562Gb

Restic
628Gb

  • PĂ«r CPU
    Borg vetë shpenzon pak, me kompresim të parazgjedhur, por duhet vlerësuar së bashku me procesin goofys. Në përmbledhje, ato janë të krahasueshme dhe konsumojnë rreth 1.2 bërthama në një makinë virtuale të testimit të njëjtë.
  • Memoria. Restic rreth 0,5Gb, Borg rreth 200Mb. Por kĂ«to janĂ« tĂ« padukshme nĂ« krahasim me keshtjen e skedarĂ«ve tĂ« sistemit. Prandaj, Ă«shtĂ« mirĂ« tĂ« alokoni mĂ« shumĂ« memorie.
  • Dallimi nĂ« madhĂ«sinĂ« e blobĂ«ve rezultoi tĂ« ishte madhor.

Backuper
Madhësia

Borg
rreth 500Mb

Restic
rreth 5Mb

  • Puna me S3 nga Restic Ă«shtĂ« e shkĂ«lqyer. Puna e Borg me goofys nuk ka probleme, por Ă«shtĂ« vĂ«nĂ« re se Ă«shtĂ« mirĂ« tĂ« bĂ«ni umount pas pĂ«rfundimit tĂ« rezervimit pĂ«r tĂ« shkelur plotesisht keshtjen. Veçoria e punĂ«s S3 Ă«shtĂ« se copat e papĂ«rfunduara kurrĂ« nuk do tĂ« dĂ«rgohen nĂ« bucket, dhe kjo do tĂ« thotĂ« se tĂ« dhĂ«nat qĂ« nuk janĂ« plotĂ«sisht ngarkuar rezultojnĂ« nĂ« dĂ«mtime tĂ« mĂ«dha.
  • Kontrolli i integritetit funksionon mirĂ« nĂ« tĂ« dy rastet, por shpejtĂ«sia ndryshon ndjeshĂ«m.
    Restic – 3.5 orĂ«.
    Borg, me keshtjen e skedarĂ«ve 100Gb SSD – 5 orĂ«. Rezultati Ă«shtĂ« pĂ«rafĂ«rsisht i njĂ«jtĂ« nĂ« shpejtĂ«si nĂ«se tĂ« dhĂ«nat janĂ« nĂ« diskun lokal.
    Borg lexon direkt nga S3 pa keshtë 33 orë. Më të ngadalta.

NĂ« pĂ«rfundim, Borg di tĂ« kompresojĂ« dhe ka blobĂ« mĂ« tĂ« mĂ«dhenj — çka e bĂ«n ruajtjen dhe operacionet GET/PUT nĂ« S3 mĂ« tĂ« lira. Por pĂ«r kĂ«tĂ« duhet tĂ« paguash me njĂ« verifikim mĂ« tĂ« komplikuar dhe mĂ« tĂ« ngadalshĂ«m. Sa i pĂ«rket shpejtĂ«sisĂ« sĂ« rikuperimit — nuk e vĂ«rejmĂ« ndonjĂ« diferencĂ«. Rezervimet pas sĂ« parĂ«s (pas sĂ« parĂ«s) restic i bĂ«n pak mĂ« tĂ« gjatĂ«, por jo domethĂ«nĂ«se.

Një nga arsyet kryesore për zgjedhjen ishte madhësia e komunitetit.

Dhe ne zgjodhëm borg.

Disa fjalë për kompresimin

Borg ka nĂ« arsenalin e tij njĂ« algoritĂ«m tĂ« shkĂ«lqyer tĂ« kompresimit — zstd. NĂ« cilĂ«sinĂ« e kompresimit nuk Ă«shtĂ« mĂ« keq se gzip, por Ă«shtĂ« shumĂ« mĂ« i shpejtĂ«. Dhe Ă«shtĂ« i krahasueshĂ«m nĂ« shpejtĂ«si me lz4 tĂ« parazgjedhur.

Për shembull, dump-i i bazës së të dhënave MySQL kompresohet 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ë diferencë shumë të vogël në gradën e kompresimit të nodës Nextcloud.

NĂ« Borg ka njĂ« mod tĂ« bonusit tĂ« kompresimit — nĂ«se skedari ka entropi tĂ« madhe, atĂ«herĂ« kompresimi nuk aplikohet fare, çka rrit shpejtĂ«sinĂ« e punĂ«s. Aktivizohet me opsionin gjatĂ« krijimit
-C auto,zstd
për algoritmin zstd
Kështu me këtë opsion në krahasim me kompresimin sipas parazgjedhjes kemi arritur
560Gb dhe 562Gb përkatësisht. Të dhënat nga shembulli më sipër, le të kujtojmë, pa kompresim rezultoi 628Gb. Rezultati me 2Gb diferencë na çuditi pak, por vendosëm që ta zgjedhim gjithsesi. auto,zstd.

Metodologjia e kontrollit të backup-it

Virtualka e nisur nga planifikuesi përfundon direkt te ofruesi ose te klienti, çka ul ndjeshëm ngarkesën në rrjet. Të paktën është më lirë se sa të nisim një nga vetja dhe të dërgojmë 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ëjtin sistem ne kontrollojmë skedarët me antivirus (postfactum). Përdoruesit ngarkojnë të ndryshme në Nextcloud dhe jo të gjithë kanë antivirus. Të kryesh kontrollin në momentin e ngarkimit merr shumë kohë dhe pengon biznesin.

Shkallëzimi arrihet duke nxitur runner-at në node të ndryshme me etiketat përkatëse.
Në monitorimin tonë mbledhim statuset e backup-eve përmes API GitLab në një dritare, nëse është e nevojshme problemet shihen lehtësisht dhe gjithashtu lokalizohen me lehtësi.

PĂ«rfundim

Si rezultat, ne e dimë me siguri që backup-et i krijojmë, që backup-et tanë janë valide, problemet që ndodhin me to janë të shpejta për t'u zgjidhur dhe menaxhohen në nivelin e administratorit të turnit. Backup-et realisht zënë pak hapësirë krahasuar me tar.gz ose Bacula.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster