Jinsi GitLab hukusaidia kuhifadhi hifadhi kubwa za NextCloud

Habari Habr!

Leo nataka kuzungumza juu ya uzoefu wetu katika kusanidi nakala rudufu ya data kubwa kutoka kwa hifadhi za Nextcloud katika usanidi tofauti. Ninafanya kazi kama kituo cha huduma huko Molniya AK, ambapo tunafanya usimamizi wa usanidi wa mifumo ya TEHAMA; Nextcloud hutumiwa kuhifadhi data. Ikiwa ni pamoja na, na muundo uliosambazwa, na upungufu.

Matatizo yanayotokana na vipengele vya usakinishaji ni kwamba kuna data nyingi. Matoleo yaliyotolewa na Nextcloud, upungufu, sababu za kibinafsi, na zaidi huunda nakala nyingi.

kabla ya historia

Wakati wa kusimamia Nextcloud, shida ya kuandaa nakala rudufu yenye ufanisi inatokea, ambayo lazima ifiche, kwani data ni muhimu.

Tunatoa chaguzi za kuhifadhi nakala mahali petu au kwa mteja kwenye mashine tofauti kutoka Nextcloud, ambayo inahitaji mbinu rahisi ya kiotomatiki ya usimamizi.

Kuna wateja wengi, wote wakiwa na usanidi tofauti, na wote kwenye tovuti zao na sifa zao wenyewe. Hii ni mbinu ya kawaida wakati tovuti nzima ni yako, na nakala rudufu zinatengenezwa kutoka kwa taji; haifai vizuri.

Kwanza, hebu tuangalie data ya pembejeo. Tunahitaji:

• Scalability kwa suala la nodi moja au kadhaa. Kwa usakinishaji mkubwa tunatumia minio kama uhifadhi.
• Jua kuhusu matatizo ya kufanya nakala rudufu.
• Unahitaji kuweka nakala rudufu na wateja wako na/au nasi.
• Shughulikia matatizo haraka na kwa urahisi.
• Wateja na mitambo ni tofauti sana kutoka kwa kila mmoja - usawa hauwezi kupatikana.
• Kasi ya kurejesha inapaswa kuwa ndogo katika matukio mawili: urejeshaji kamili (janga), folda moja imefutwa kwa makosa.
• Chaguo za kurudisha nyuma zinahitajika.

Ili kutatua tatizo la kusimamia chelezo, tuliweka GitLab. Maelezo zaidi kwa tackle.

Kwa kweli, sisi sio wa kwanza kutatua shida kama hiyo, lakini inaonekana kwetu kwamba uzoefu wetu wa vitendo, uliopatikana kwa bidii unaweza kuvutia na tuko tayari kuishiriki.

Kwa kuwa kampuni yetu ina sera ya chanzo huria, tulikuwa tunatafuta suluhisho la chanzo huria. Kwa upande mwingine, tunashiriki maendeleo yetu na kuyachapisha. Kwa mfano, kwenye GitHub kuna programu-jalizi yetu ya Nextcloud, ambayo tunatoa kwa wateja, kuimarisha usalama wa data katika kesi ya kufutwa kwa bahati mbaya au kukusudia.

Zana za kuhifadhi nakala

Tulianza utafutaji wetu wa mbinu za ufumbuzi kwa kuchagua zana ya kuunda chelezo.

Tar + gzip ya kawaida haifanyi kazi vizuri - data inarudiwa. Ongezeko mara nyingi huwa na mabadiliko machache sana, na data nyingi ndani ya faili moja hurudiwa.
Kuna tatizo lingine - upungufu wa hifadhi ya data iliyosambazwa. Tunatumia minio na data yake kimsingi haina maana. Au ulilazimika kufanya nakala rudufu kupitia minio yenyewe - kuipakia na kutumia spacers zote kati ya mfumo wa faili, na, sio muhimu sana, kuna hatari ya kusahau kuhusu ndoo na meta-habari. Au tumia upunguzaji.

Zana za kuhifadhi nakala zilizo na nakala zinapatikana katika chanzo huria (kwenye Habré kulikuwa nakala kuhusu mada hii) na washindi wetu walikuwa Borg и Zuia. Ulinganisho wetu wa maombi mawili uko hapa chini, lakini kwa sasa tutakuambia jinsi tulivyopanga mpango mzima.

Kusimamia chelezo

Borg na Restic ni nzuri, lakini hakuna bidhaa iliyo na utaratibu wa udhibiti wa kati. Kwa madhumuni ya usimamizi na udhibiti, tulichagua chombo ambacho tayari tumetekeleza, bila ambayo hatuwezi kufikiria kazi yetu, ikiwa ni pamoja na automatisering - hii ni CI / CD inayojulikana - GitLab.

Wazo ni kama ifuatavyo: gitlab-runner imewekwa kwenye kila nodi inayohifadhi data ya Nextcloud. Kiendeshaji huendesha hati kwenye ratiba inayofuatilia mchakato wa kuhifadhi nakala, na huzindua Borg au Restic.

Tulipata nini? Maoni kutoka kwa utekelezaji, udhibiti unaofaa juu ya mabadiliko, maelezo ikiwa kuna hitilafu.

Hapa hapa kwenye GitHub tulichapisha mifano ya hati kwa kazi mbalimbali, na tukaishia kuiunganisha kwa chelezo ya sio Nextcloud tu, bali pia huduma zingine nyingi. Pia kuna kipanga ratiba hapo ikiwa hutaki kukisanidi wewe mwenyewe (na hatutaki) na .gitlab-ci.yml

Hakuna njia ya kubadilisha kuisha kwa CI/CD kwenye API ya Gitlab bado, lakini ni ndogo. Inahitaji kuongezwa, sema 1d.

GitLab, kwa bahati nzuri, inaweza kuzindua sio tu kulingana na ahadi, lakini kulingana na ratiba, hii ndio tunayohitaji.

Sasa kuhusu hati ya wrapper.

Tunaweka masharti yafuatayo kwa hati hii:

• Inapaswa kuzinduliwa wote na mkimbiaji na kwa mkono kutoka kwa console yenye utendaji sawa.
• Lazima kuwe na vidhibiti makosa:
• msimbo wa kurudi.
• tafuta kamba kwenye logi. Kwa mfano, kwetu, hitilafu inaweza kuwa ujumbe ambao programu haizingatii kuwa mbaya.
• Muda wa kuchakata umekwisha. Wakati wa kuongoza lazima uwe wa busara.
• Tunahitaji logi ya kina sana. Lakini tu katika kesi ya makosa.
• Vipimo kadhaa pia hufanywa kabla ya kuanza.
• Bonasi ndogo kwa urahisi ambazo tulipata kuwa muhimu wakati wa mchakato wa usaidizi:
• Mwanzo na mwisho zimeandikwa katika syslog ya mashine ya ndani. Hii husaidia kuunganisha makosa ya mfumo na uendeshaji wa chelezo.
• Sehemu ya logi ya makosa, ikiwa ipo, inatolewa kwa stdout, logi nzima imeandikwa kwa faili tofauti. Ni rahisi kutazama mara moja CI na kutathmini kosa ikiwa ni ndogo.
• Njia za utatuzi.

Logi kamili imehifadhiwa kama kisanii katika GitLab; ikiwa hakuna hitilafu, logi inafutwa. Tunaandika maandishi katika bash.

Tutafurahi kuzingatia mapendekezo na maoni yoyote kuhusu chanzo huria - karibu.

Jinsi gani kazi hii

Mkimbiaji aliye na mtekelezaji wa Bash amezinduliwa kwenye nodi ya chelezo. Kulingana na mpangaji, kazi CI/CD inazinduliwa kwa zamu maalum. Kiendeshaji huzindua hati ya jumla ya kazi kama hizo, hukagua uhalali wa hazina mbadala, sehemu za kupachika na kila kitu tunachotaka, kisha huhifadhi nakala rudufu na kusafisha ile ya zamani. Chelezo iliyokamilishwa yenyewe inatumwa kwa S3.

Tunafanya kazi kulingana na mpango huu - ni mtoaji wa AWS wa nje au sawa na Kirusi (ni haraka na data haitoki Shirikisho la Urusi). Au tunasakinisha kikundi tofauti cha minio kwa mteja kwenye tovuti yake kwa madhumuni haya. Kawaida tunafanya hivi kwa sababu za usalama, wakati mteja hataki data iondoke kwenye mzunguko wao kabisa.

Hatukutumia kipengele cha kutuma chelezo kupitia ssh. Hii haiongezi usalama, na uwezo wa mtandao wa mtoa huduma wa S3 ni wa juu zaidi kuliko mashine yetu moja ya ssh.

Ili kulinda mashine yako ya ndani kutoka kwa mdukuzi, kwa kuwa anaweza kufuta data kwenye S3, lazima uwashe uchapishaji.
Hifadhi rudufu kila wakati husimba nakala rudufu.

Borg ina modi ambayo haijasimbwa none, lakini hatupendekezi sana kuiwasha. Katika hali hii, sio tu hakutakuwa na usimbaji fiche, lakini hundi ya kile kinachoandikwa haijahesabiwa, ambayo ina maana kwamba uadilifu unaweza tu kuangaliwa kwa njia isiyo ya moja kwa moja, kwa kutumia indexes.

Kipanga ratiba tofauti hukagua chelezo kwa uadilifu wa faharasa na maudhui. Cheki ni polepole na ndefu, kwa hivyo tunaiendesha kando mara moja kwa mwezi. Inaweza kuchukua siku kadhaa.

Soma kwa Kirusi

Kazi kuu

• prepare maandalizi
• testcheck kuangalia utayari
• maincommand timu ya msingi
• forcepostscript chaguo la kukokotoa ambalo linatekelezwa mwishoni au kwa hitilafu. Tunatumia kuteremsha kizigeu.

Vipengele vya huduma

• cleanup Tunarekodi makosa au kufuta faili ya kumbukumbu.
• checklog changanua logi kwa kutokea kwa mstari na hitilafu.
• ret toka kwa kidhibiti.
• checktimeout angalia muda umeisha.

mazingira

• VERBOSE=1 Tunaonyesha makosa kwenye skrini mara moja (stdout).
• SAVELOGSONSUCCES=1 kuokoa kumbukumbu juu ya mafanikio.
• INIT_REPO_IF_NOT_EXIST=1 Unda hazina ikiwa haipo. Imezimwa kwa chaguomsingi.
• TIMEOUT muda wa juu wa operesheni kuu. Unaweza kuiweka kama 'm', 'h' au 'd' mwishoni.

Hali ya kuhifadhi nakala za zamani. Chaguomsingi:

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

Vigezo ndani ya hati

• ERROR_STRING - kamba kwa logi ya hundi kwa hitilafu.
• EXTRACT_ERROR_STRING - usemi wa mfuatano wa kuonyesha ikiwa ni makosa.
• KILL_TIMEOUT_SIGNAL - ishara ya kuua ikiwa umeisha.
• TAIL — ni nyuzi ngapi zenye hitilafu kwenye skrini.
• COLORMSG - rangi ya ujumbe (njano chaguo-msingi).

Hati hiyo, inayoitwa wordpress, ina jina la masharti, hila yake ni kwamba pia inahifadhi hifadhidata ya mysql. Hii inamaanisha kuwa inaweza kutumika kwa usakinishaji wa nodi moja ya Nexcloud, ambapo unaweza pia kuhifadhi hifadhidata. Urahisi sio tu kwamba kila kitu kiko katika sehemu moja, lakini pia yaliyomo kwenye hifadhidata iko karibu na yaliyomo kwenye faili, kwani tofauti ya wakati ni ndogo.

Restic dhidi ya Borg

Pia kuna ulinganisho kati ya Borg na Restic Hapa ni kwa Habre, na hatukuwa na kazi ya kutengeneza nyingine tu, bali yetu wenyewe. Ilikuwa muhimu kwetu jinsi ingeonekana kwenye data yetu, na maelezo yetu maalum. Tunawaletea.

Vigezo vyetu vya uteuzi, pamoja na vile vilivyotajwa tayari (kupunguza, kurejesha haraka, nk):

• Upinzani kwa kazi ambayo haijakamilika. Angalia kuua -9.
• Ukubwa kwenye diski.
• Mahitaji ya rasilimali (CPU, kumbukumbu).
• Ukubwa wa matone yaliyohifadhiwa.
• Kufanya kazi na S3.
• Ukaguzi wa uadilifu.

Kwa majaribio, tulichukua mteja mmoja aliye na data halisi na ukubwa wa jumla wa TB 1,6.
Masharti.

Borg hajui jinsi ya kufanya kazi moja kwa moja na S3, na tuliweka diski kama fuse, kupitia goofys. Restic aliituma kwa S3 yenyewe.

Goofys kazi haraka sana na vizuri, na kuna moduli ya kashe ya diski, ambayo huharakisha kazi hata zaidi. Iko katika hatua ya beta, na, kusema ukweli, tulianguka na kupoteza data wakati wa majaribio (wengine). Lakini urahisi ni kwamba utaratibu wa chelezo yenyewe hauhitaji kusoma sana, lakini zaidi kuandika, kwa hivyo tunatumia kache tu wakati wa ukaguzi wa uadilifu.

Ili kupunguza ushawishi wa mtandao, tulitumia mtoa huduma wa ndani - Yandex Cloud.

Matokeo ya kulinganisha ya majaribio.

• Kill -9 kwa kuanzisha upya yote mawili yalifanikiwa.
• Ukubwa kwenye diski. Borg inaweza kukandamiza, kwa hivyo matokeo ni kama inavyotarajiwa.

Backuper
Ukubwa

Borg
562Gb

Zuia
628Gb

• Kwa CPU
  Borg yenyewe hutumia kidogo, na ukandamizaji chaguo-msingi, lakini lazima itathminiwe pamoja na mchakato wa goofys. Kwa jumla, zinaweza kulinganishwa na hutumia takriban cores 1,2 kwenye mashine moja ya majaribio ya mtandaoni.
• Kumbukumbu. Restic ni takriban 0,5GB, Borg ni takriban 200MB. Lakini hii yote ni ndogo ikilinganishwa na cache ya faili ya mfumo. Kwa hivyo ni vyema kutenga kumbukumbu zaidi.
• Tofauti katika saizi ya blob ilikuwa ya kushangaza.

Backuper
Ukubwa

Borg
takriban 500MB

Zuia
takriban 5MB

• Uzoefu wa S3 wa Restic ni bora. Kufanya kazi na Borg kupitia goofys hakuzushi maswali yoyote, lakini imebainika kuwa inashauriwa kufanya umount baada ya kuhifadhi nakala kamili ili kuweka upya kache kabisa. Upekee wa S3 ni kwamba chunks zilizopigwa chini hazitatumwa kwenye ndoo, ambayo ina maana kwamba data isiyojazwa kikamilifu husababisha uharibifu mkubwa.
• Cheki cha uadilifu hufanya kazi vizuri katika visa vyote viwili, lakini kasi inatofautiana sana.
  Restic Masaa 3,5.
  Borg, iliyo na kashe ya faili ya SSD ya 100GB - Masaa 5.Takriban matokeo sawa ya kasi ikiwa data iko kwenye diski ya ndani.
  Borg inasoma moja kwa moja kutoka kwa S3 bila kache Masaa 33. Muda mrefu sana.

Jambo la msingi ni kwamba Borg inaweza kubana na ina matone makubwa zaidi - ambayo hufanya uhifadhi na GET/PUT shughuli katika S3 kuwa nafuu. Lakini hii inakuja kwa gharama ya uthibitishaji ngumu zaidi na polepole. Kuhusu kasi ya uokoaji, hatukugundua tofauti yoyote. Restic inachukua chelezo zinazofuata (baada ya ya kwanza) kwa muda mrefu kidogo, lakini sio kwa kiasi kikubwa.

Mwisho kabisa katika uchaguzi ulikuwa ukubwa wa jumuiya.

Na tulichagua borg.

Maneno machache kuhusu compression

Borg ina algorithm mpya bora ya ukandamizaji katika safu yake ya uokoaji - zstd. Ubora wa ukandamizaji sio mbaya zaidi kuliko gzip, lakini kwa kasi zaidi. Na kulinganishwa kwa kasi na lz4 chaguo-msingi.

Kwa mfano, utupaji wa hifadhidata ya MySQL umebanwa mara mbili bora kuliko lz4 kwa kasi sawa. Walakini, uzoefu na data halisi unaonyesha kuwa kuna tofauti ndogo sana katika uwiano wa ukandamizaji wa nodi ya Nextcloud.

Borg ina modi ya ukandamizaji wa mafao - ikiwa faili ina entropy ya juu, basi ukandamizaji hautumiki kabisa, ambayo huongeza kasi. Imewezeshwa na chaguo wakati wa kuunda
-C auto,zstd
kwa algorithm ya zstd
Kwa hivyo na chaguo hili, kwa kulinganisha na compression chaguo-msingi, tulipata
560Gb na 562Gb mtawalia. Data kutoka kwa mfano hapo juu, napenda kukukumbusha, bila compression matokeo ni 628Gb. Matokeo ya tofauti ya 2GB yalitushangaza, lakini tulidhani kwamba tungeichagua. auto,zstd.

Mbinu ya uthibitishaji

Kwa mujibu wa mpangilio, mashine ya kawaida inazinduliwa moja kwa moja kutoka kwa mtoa huduma au kutoka kwa mteja, ambayo hupunguza sana mzigo wa mtandao. Angalau ni nafuu kuliko kuinua mwenyewe na kuendesha trafiki.

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/

Kutumia mpango huo huo, tunaangalia faili na antivirus (baada ya ukweli). Baada ya yote, watumiaji hupakia vitu tofauti kwa Nextcloud na sio kila mtu ana antivirus. Kufanya ukaguzi wakati wa kumwaga huchukua muda mwingi na huingilia biashara.

Scalability hupatikana kwa kukimbia wakimbiaji kwenye nodi tofauti zilizo na lebo tofauti.
Ufuatiliaji wetu hukusanya hali za chelezo kupitia API ya GitLab katika dirisha moja; ikihitajika, matatizo yanaonekana kwa urahisi na kubinafsishwa kwa urahisi.

Hitimisho

Matokeo yake, tunajua kwa hakika kwamba tunafanya nakala, kwamba chelezo zetu ni halali, matatizo yanayotokea nao huchukua muda kidogo na yanatatuliwa kwa kiwango cha msimamizi wa wajibu. Hifadhi rudufu huchukua nafasi kidogo sana ikilinganishwa na tar.gz au Bacula.

Chanzo: mapenzi.com