Sut mae GitLab yn eich helpu i wneud copi wrth gefn o storfeydd mawr NextCloud

Hei Habr!

Heddiw, rwyf am siarad am ein profiad o awtomeiddio'r copi wrth gefn o ddata mawr o storfeydd Nextcloud mewn gwahanol ffurfweddiadau. Rwy'n gweithio fel gorsaf wasanaeth yn Molniya AK, lle rydym yn rheoli cyfluniad systemau TG; defnyddir Nextcloud ar gyfer storio data. Gan gynnwys, gyda strwythur gwasgaredig, gyda diswyddiadau.

Y problemau sy'n deillio o nodweddion y gosodiadau yw bod llawer o ddata. Mae fersiynau a ddarperir gan Nextcloud, dileu swydd, rhesymau goddrychol, a mwy yn creu llawer o ddyblygiadau.

cynhanes

Wrth weinyddu Nextcloud, mae'r broblem o drefnu copi wrth gefn effeithiol yn codi, y mae'n rhaid ei amgryptio, gan fod y data'n werthfawr.

Rydym yn cynnig opsiynau ar gyfer storio copïau wrth gefn yn ein lle neu yn y cwsmer ar beiriannau ar wahân i Nextcloud, sy'n gofyn am ddull awtomataidd hyblyg o weinyddu.

Mae yna lawer o gleientiaid, pob un ohonynt â gwahanol gyfluniadau, a phob un ar eu gwefannau eu hunain a gyda'u nodweddion eu hunain. Mae hon yn dechneg safonol pan fo'r wefan gyfan yn eiddo i chi, ac mae copïau wrth gefn yn cael eu gwneud o goronau; nid yw'n ffitio'n dda.

Yn gyntaf, gadewch i ni edrych ar y data mewnbwn. Mae angen:

  • Scalability o ran un nod neu sawl un. Ar gyfer gosodiadau mawr rydym yn defnyddio minio fel storfa.
  • Dysgwch am broblemau gyda pherfformio copïau wrth gefn.
  • Mae angen i chi gadw copi wrth gefn gyda'ch cleientiaid a/neu gyda ni.
  • Delio â phroblemau yn gyflym ac yn hawdd.
  • Mae cleientiaid a gosodiadau yn wahanol iawn i'w gilydd - ni ellir cyflawni unffurfiaeth.
  • Dylai'r cyflymder adfer fod yn fach iawn mewn dwy senario: adferiad llawn (trychineb), un ffolder wedi'i ddileu trwy gamgymeriad.
  • Mae angen swyddogaeth dad-ddyblygu.

Sut mae GitLab yn eich helpu i wneud copi wrth gefn o storfeydd mawr NextCloud

I ddatrys y broblem o reoli copïau wrth gefn, fe wnaethom osod GitLab. Mwy o fanylion trwy daclo.

Wrth gwrs, nid ni yw'r cyntaf i ddatrys problem o'r fath, ond mae'n ymddangos i ni y gall ein profiad ymarferol, haeddiannol fod yn ddiddorol ac rydym yn barod i'w rannu.

Gan fod gan ein cwmni bolisi ffynhonnell agored, roeddem yn chwilio am ateb ffynhonnell agored. Yn ein tro, rydym yn rhannu ein datblygiadau ac yn eu postio. Er enghraifft, ar GitHub mae yna ein ategyn ar gyfer Nextcloud, a ddarparwn i gleientiaid, gan wella diogelwch data rhag ofn y bydd yn cael ei ddileu yn ddamweiniol neu'n fwriadol.

Offer wrth gefn

Dechreuon ni ein chwilio am ddulliau datrysiad trwy ddewis teclyn creu copi wrth gefn.

Nid yw tar + gzip rheolaidd yn gweithio'n dda - mae'r data'n cael ei ddyblygu. Mae cynyddran yn aml yn cynnwys ychydig iawn o newidiadau gwirioneddol, ac mae llawer o'r data o fewn un ffeil yn cael ei ailadrodd.
Mae problem arall - diswyddo storio data dosbarthedig. Rydym yn defnyddio minio ac mae ei ddata yn ddiangen yn y bôn. Neu roedd yn rhaid i chi wneud copi wrth gefn trwy minio ei hun - ei lwytho a defnyddio'r holl ofodwyr rhwng y system ffeiliau, a, heb fod yn llai pwysig, mae risg o anghofio am rai o'r bwcedi a'r meta-wybodaeth. Neu defnyddiwch ddiddyblygiad.

Mae offer wrth gefn gyda dyblygu ar gael mewn ffynhonnell agored (ar Habré roedd erthyglau am y thema hon) a'n terfynwyr oedd Borg и Restic. Mae ein cymhariaeth o’r ddau gais isod, ond am y tro byddwn yn dweud wrthych sut y trefnwyd y cynllun cyfan.

Rheoli copïau wrth gefn

Mae Borg a Restic yn dda, ond nid oes gan y naill gynnyrch na'r llall fecanwaith rheoli canolog. At ddibenion rheoli a rheoli, fe wnaethom ddewis offeryn yr ydym eisoes wedi'i weithredu, heb na allwn ddychmygu ein gwaith, gan gynnwys awtomeiddio - dyma'r CI/CD adnabyddus - GitLab.

Mae'r syniad fel a ganlyn: gosodir gitlab-runner ar bob nod yn storio data Nextcloud. Mae'r rhedwr yn rhedeg sgript ar amserlen sy'n monitro'r broses wrth gefn, ac mae'n lansio Borg neu Restic.

Beth gawson ni? Adborth o gyflawni, rheolaeth gyfleus dros newidiadau, manylion rhag ofn y bydd gwall.

Yma yma ar GitHub fe wnaethom bostio enghreifftiau o'r sgript ar gyfer gwahanol dasgau, ac yn y diwedd fe wnaethom ei atodi i gefn nid yn unig Nextcloud, ond hefyd llawer o wasanaethau eraill. Mae yna amserlennwr yno hefyd os nad ydych chi am ei ffurfweddu â llaw (ac nid ydym am wneud hynny) a .gitlab-ci.yml

Nid oes unrhyw ffordd i newid y terfyn amser CI/CD yn API Gitlab eto, ond mae'n fach. Mae angen ei gynyddu, dyweder i 1d.

Yn ffodus, gall GitLab lansio nid yn unig yn ôl ymrwymiad, ond dim ond yn ôl amserlen, dyma'n union sydd ei angen arnom.

Nawr am y sgript lapio.

Rydym yn gosod yr amodau canlynol ar gyfer y sgript hon:

  • Dylai gael ei lansio gan y rhedwr ac â llaw o'r consol gyda'r un swyddogaeth.
  • Rhaid cael trinwyr gwallau:
  • cod dychwelyd.
  • chwilio am linyn yn y log. Er enghraifft, i ni gall gwall fod yn neges nad yw'r rhaglen yn ei hystyried yn angheuol.
  • Goramser prosesu. Rhaid i'r amser arweiniol fod yn rhesymol.
  • Mae angen log manwl iawn arnom. Ond dim ond mewn achos o gamgymeriad.
  • Mae nifer o brofion hefyd yn cael eu cynnal cyn dechrau.
  • Bonysau bach er hwylustod a oedd yn ddefnyddiol i ni yn ystod y broses gefnogi:
  • Mae'r dechrau a'r diwedd yn cael eu cofnodi yn syslog y peiriant lleol. Mae hyn yn helpu i gysylltu gwallau system a gweithrediad wrth gefn.
  • Mae rhan o'r log gwall, os o gwbl, yn allbwn i stdout, mae'r log cyfan yn cael ei ysgrifennu i ffeil ar wahân. Mae'n gyfleus edrych ar CI ar unwaith a gwerthuso'r gwall os yw'n ddibwys.
  • Dulliau dadfygio.

Mae'r log llawn yn cael ei gadw fel arteffact yn GitLab; os nad oes gwall, mae'r log yn cael ei ddileu. Rydyn ni'n ysgrifennu'r sgript mewn bash.

Byddwn yn hapus i ystyried unrhyw awgrymiadau a sylwadau ynghylch ffynhonnell agored - croeso.

Sut mae hwn

Mae rhedwr gydag ysgutor Bash yn cael ei lansio ar y nod wrth gefn. Yn ôl y trefnydd, mae swydd CI/CD yn cael ei lansio mewn maip arbennig. Mae'r rhedwr yn lansio sgript lapio cyffredinol ar gyfer tasgau o'r fath, mae'n gwirio dilysrwydd y storfa wrth gefn, pwyntiau gosod a phopeth yr ydym ei eisiau, yna'n gwneud copi wrth gefn ac yn glanhau'r hen un. Anfonir y copi wrth gefn gorffenedig ei hun i S3.

Rydym yn gweithio yn unol â'r cynllun hwn - mae'n ddarparwr AWS allanol neu'n cyfateb yn Rwsia (mae'n gyflymach ac nid yw'r data'n gadael Ffederasiwn Rwsia). Neu rydym yn gosod clwstwr mini ar wahân ar gyfer y cleient ar ei wefan at y dibenion hyn. Rydym fel arfer yn gwneud hyn am resymau diogelwch, pan nad yw'r cleient am i'r data adael eu cylched o gwbl.

Ni wnaethom ddefnyddio'r nodwedd o anfon copi wrth gefn trwy ssh. Nid yw hyn yn ychwanegu diogelwch, ac mae galluoedd rhwydwaith y darparwr S3 yn llawer uwch na'n peiriant un ssh.

Er mwyn amddiffyn eich peiriant lleol rhag haciwr, gan ei fod yn gallu dileu data ar S3, rhaid i chi alluogi fersiwn.
Mae'r copi wrth gefn bob amser yn amgryptio'r copi wrth gefn.

Mae gan Borg fodd heb ei amgryptio none, ond nid ydym yn argymell yn gryf ei droi ymlaen. Yn y modd hwn, nid yn unig na fydd unrhyw amgryptio, ond nid yw gwiriad yr hyn sy'n cael ei ysgrifennu yn cael ei gyfrifo, sy'n golygu mai dim ond yn anuniongyrchol y gellir gwirio cywirdeb, gan ddefnyddio mynegeion.

Mae trefnydd ar wahân yn gwirio copïau wrth gefn i sicrhau cywirdeb mynegeion a chynnwys. Mae'r siec yn araf ac yn hir, felly rydyn ni'n ei redeg ar wahân unwaith y mis. Gall gymryd sawl diwrnod.

Readme yn Rwsieg

Prif swyddogaethau

  • prepare hyfforddiant
  • testcheck gwiriad parodrwydd
  • maincommand tîm craidd
  • forcepostscript swyddogaeth a gyflawnir yn y diwedd neu drwy gamgymeriad. Rydyn ni'n ei ddefnyddio i ddadosod y rhaniad.

Swyddogaethau gwasanaeth

  • cleanup Rydym yn cofnodi gwallau neu'n dileu'r ffeil log.
  • checklog dosrannu'r log ar gyfer y digwyddiad o linell gyda gwall.
  • ret triniwr allanfa.
  • checktimeout gwiriwch am egwyl.

Yr amgylchedd

  • VERBOSE=1 Rydym yn arddangos gwallau ar y sgrin ar unwaith (stdout).
  • SAVELOGSONSUCCES=1 arbed y log ar lwyddiant.
  • INIT_REPO_IF_NOT_EXIST=1 Creu ystorfa os nad yw'n bodoli. Wedi'i analluogi yn ddiofyn.
  • TIMEOUT uchafswm amser ar gyfer y prif weithrediad. Gallwch ei osod fel 'm', 'h' neu 'd' ar y diwedd.

Modd storio ar gyfer hen gopïau. Rhagosodedig:

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

Newidynnau y tu mewn i'r sgript

  • ERROR_STRING — llinyn ar gyfer y log ticio i mewn am wall.
  • EXTRACT_ERROR_STRING — mynegiant ar gyfer y llinyn dangos os yw'n wall.
  • KILL_TIMEOUT_SIGNAL — arwydd ar gyfer lladd os goramser.
  • TAIL — sawl llinyn gyda gwallau ar y sgrin.
  • COLORMSG — lliw y neges (melyn diofyn).

Mae gan y sgript honno, a elwir yn wordpress, enw amodol, ei gamp yw ei bod hefyd yn gwneud copi wrth gefn o'r gronfa ddata mysql. Mae hyn yn golygu y gellir ei ddefnyddio ar gyfer gosodiadau un-nôd Nexcloud, lle gallwch chi hefyd wneud copi wrth gefn o'r gronfa ddata. Y cyfleustra yw nid yn unig bod popeth mewn un lle, ond hefyd mae cynnwys y gronfa ddata yn agos at gynnwys y ffeiliau, gan fod y gwahaniaeth amser yn fach iawn.

Restic yn erbyn Borg

Mae yna gymariaethau hefyd rhwng Borg a Restic yma ar Habré, ac nid oedd gennym y dasg o wneud un arall yn unig, ond ein rhai ein hunain. Roedd yn bwysig i ni sut y byddai'n edrych ar ein data, gyda'n manylion. Rydyn ni'n dod â nhw.

Ein meini prawf dethol, yn ychwanegol at y rhai a grybwyllwyd eisoes (dyblygiad, adferiad cyflym, ac ati):

  • Gwrthwynebiad i waith anorffenedig. Gwiriwch am ladd -9.
  • Maint ar ddisg.
  • Gofyniad am adnoddau (CPU, cof).
  • Maint y smotiau storio.
  • Gweithio gyda S3.
  • Gwiriad uniondeb.

Ar gyfer profi, fe wnaethom gymryd un cleient gyda data go iawn a chyfanswm maint o 1,6 TB.
Amodau.

Nid yw Borg yn gwybod sut i weithio'n uniongyrchol gyda S3, ac fe wnaethom osod y ddisg fel ffiws, trwy goofys. Anfonodd Restic ef i S3 ei hun.

Mae Goofys yn gweithio'n gyflym ac yn dda iawn, ac mae yna modiwl cache disg, sy'n cyflymu'r gwaith hyd yn oed yn fwy. Mae yn y cam beta, ac, a dweud y gwir, cawsom ddamwain gyda cholli data yn ystod profion (eraill). Ond y cyfleustra yw nad oes angen llawer o ddarllen ar y weithdrefn wrth gefn ei hun, ond yn bennaf ysgrifennu, felly dim ond yn ystod gwiriadau cywirdeb y byddwn yn defnyddio'r storfa.

Er mwyn lleihau dylanwad y rhwydwaith, gwnaethom ddefnyddio darparwr lleol - Yandex Cloud.

Canlyniadau profion cymharu.

  • Roedd Kill -9 gydag ailgychwyn pellach yn llwyddiannus.
  • Maint ar ddisg. Gall Borg gywasgu, felly mae'r canlyniadau yn ôl y disgwyl.

Backuper
Maint

Borg
562Gb

Restic
628Gb

  • Gan CPU
    Nid yw Borg ei hun yn defnyddio llawer, gyda chywasgu rhagosodedig, ond rhaid ei werthuso ynghyd â'r broses goofys. Yn gyfan gwbl, maent yn gymaradwy ac yn defnyddio tua 1,2 craidd ar yr un peiriant rhithwir prawf.
  • Cof. Mae Restic tua 0,5GB, mae Borg tua 200MB. Ond mae hyn i gyd yn ddibwys o'i gymharu â storfa ffeiliau'r system. Felly fe'ch cynghorir i ddyrannu mwy o gof.
  • Roedd y gwahaniaeth ym maint y blob yn drawiadol.

Backuper
Maint

Borg
tua 500MB

Restic
tua 5MB

  • Mae profiad S3 Restic yn ardderchog. Nid yw gweithio gyda Borg trwy goofys yn codi unrhyw gwestiynau, ond nodwyd ei bod yn ddoeth gwneud umount ar ôl i'r copi wrth gefn gael ei gwblhau i ailosod y storfa'n llwyr. Hynodrwydd S3 yw na fydd talpiau heb eu pwmpio byth yn cael eu hanfon i'r bwced, sy'n golygu bod data heb ei lenwi'n gyfan gwbl yn arwain at ddifrod mawr.
  • Mae'r gwiriad cywirdeb yn gweithio'n dda yn y ddau achos, ond mae'r cyflymder yn wahanol iawn.
    Restic Oriau 3,5.
    Borg, gyda storfa ffeil SSD 100GB - Oriau 5.Tua'r un canlyniad cyflymder os yw'r data ar ddisg leol.
    Mae Borg yn darllen yn uniongyrchol o S3 heb storfa Oriau 33. Yn wrthun o hir.

Y gwir amdani yw y gall Borg gywasgu ac mae ganddo smotiau mwy - sy'n gwneud storio a gweithrediadau GET/PUT yn S3 yn rhatach. Ond daw hyn ar gost dilysu mwy cymhleth ac arafach. O ran y cyflymder adfer, ni wnaethom sylwi ar unrhyw wahaniaeth. Mae Restic yn cymryd copïau wrth gefn dilynol (ar ôl y cyntaf) ychydig yn hirach, ond nid yn sylweddol.

Yn olaf ond nid lleiaf yn y dewis oedd maint y gymuned.

Ac fe ddewison ni borg.

Ychydig eiriau am gywasgu

Mae gan Borg algorithm cywasgu newydd ardderchog yn ei arsenal - zstd. Nid yw'r ansawdd cywasgu yn waeth na gzip, ond yn llawer cyflymach. Ac yn debyg mewn cyflymder i'r diofyn lz4.

Er enghraifft, mae dymp cronfa ddata MySQL wedi'i gywasgu ddwywaith yn well na lz4 ar yr un cyflymder. Fodd bynnag, mae profiad gyda data go iawn yn dangos mai ychydig iawn o wahaniaeth sydd yng nghymhareb cywasgu'r nod Nextcloud.

Mae gan Borg fodd cywasgu eithaf bonws - os oes gan y ffeil entropi uchel, yna ni chaiff cywasgu ei gymhwyso o gwbl, sy'n cynyddu'r cyflymder. Wedi'i alluogi gan opsiwn wrth greu
-C auto,zstd
ar gyfer yr algorithm zstd
Felly gyda'r opsiwn hwn, o'i gymharu â'r cywasgu rhagosodedig, cawsom
560Gb a 562Gb yn y drefn honno. Mae'r data o'r enghraifft uchod, gadewch imi eich atgoffa, heb gywasgu y canlyniad yw 628Gb. Roedd canlyniad gwahaniaeth 2GB yn ein synnu braidd, ond roeddem yn meddwl y byddem yn ei ddewis wedi'r cyfan. auto,zstd.

Dull dilysu wrth gefn

Yn ôl y trefnydd, mae'r peiriant rhithwir yn cael ei lansio'n uniongyrchol gan y darparwr neu'r cleient, sy'n lleihau llwyth y rhwydwaith yn fawr. O leiaf mae'n rhatach na'i godi eich hun a gyrru traffig.

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/

Gan ddefnyddio'r un cynllun, rydym yn gwirio ffeiliau gyda gwrthfeirws (ar ôl y ffaith). Wedi'r cyfan, mae defnyddwyr yn uwchlwytho gwahanol bethau i Nextcloud ac nid oes gan bawb wrthfeirws. Mae cynnal arolygiadau ar adeg arllwys yn cymryd gormod o amser ac yn ymyrryd â busnes.

Scalability yn cael ei gyflawni trwy redeg rhedwyr ar wahanol nodau gyda gwahanol dagiau.
Mae ein monitro yn casglu statws wrth gefn trwy'r API GitLab mewn un ffenestr; os oes angen, mae problemau'n cael eu sylwi'n hawdd ac yr un mor hawdd eu lleoleiddio.

Casgliad

O ganlyniad, rydym yn gwybod yn sicr ein bod yn gwneud copïau wrth gefn, bod ein copïau wrth gefn yn ddilys, bod problemau sy'n codi gyda nhw yn cymryd ychydig o amser ac yn cael eu datrys ar lefel y gweinyddwr ar ddyletswydd. Nid yw copïau wrth gefn yn cymryd llawer o le o gymharu â tar.gz neu Bacula.

Ffynhonnell: hab.com

Ychwanegu sylw