ProHoster > Blogs > Administrācija > Kā GitLab palīdz dublēt lielas NextCloud krātuves

Kā GitLab palīdz dublēt lielas NextCloud krātuves

Čau Habr!

Å odien es vēlos runāt par mÅ«su pieredzi, automatizējot lielo datu dublÄ“Å”anu no Nextcloud krātuvēm dažādās konfigurācijās. Strādāju par degvielas uzpildes staciju Molnija AK, kur veicam IT sistēmu konfigurācijas pārvaldÄ«bu, datu uzglabāŔanai tiek izmantots Nextcloud. Tai skaitā, ar sadalÄ«tu struktÅ«ru, ar atlaiÅ”anu.

Problēmas, kas rodas no instalāciju funkcijām, ir tādas, ka ir daudz datu. Nextcloud nodroÅ”inātā versija, dublÄ“Å”ana, subjektÄ«vi iemesli un daudz kas cits rada daudz dublikātu.

Aizvēsture

Administrējot Nextcloud, rodas efektÄ«vas dublÄ“Å”anas organizÄ“Å”anas problēma, kas ir jāŔifrē, jo dati ir vērtÄ«gi.

Mēs piedāvājam iespējas saglabāt dublējumus pie mums vai pie klienta atseviŔķās iekārtās no Nextcloud, kas prasa elastÄ«gu automatizētu pieeju administrÄ“Å”anai.

Ir daudz klientu, visi ar dažādām konfigurācijām, un visi atrodas savās vietnēs un ar savām Ä«paŔībām. Tas ir standarta paņēmiens, kad visa vietne pieder jums un dublējumkopijas tiek veidotas no kronām; tas neatbilst labi.

Vispirms apskatīsim ievades datus. Mums vajag:

  • MērogojamÄ«ba viena vai vairāku mezglu izteiksmē. Lielām instalācijām mēs izmantojam minio kā krātuvi.
  • Uzziniet par problēmām, kas saistÄ«tas ar dublÄ“Å”anas veikÅ”anu.
  • Jums ir jāveido rezerves kopija ar saviem klientiem un/vai pie mums.
  • Ātri un viegli risiniet problēmas.
  • Klienti un instalācijas ļoti atŔķiras viens no otra ā€“ vienveidÄ«bu nevar panākt.
  • AtkopÅ”anas ātrumam jābÅ«t minimālam divos gadÄ«jumos: pilnÄ«ga atkopÅ”ana (katastrofa), viena mape ir kļūdaini izdzēsta.
  • NepiecieÅ”ama deduplikācijas funkcija.

Kā GitLab palīdz dublēt lielas NextCloud krātuves

Lai atrisinātu dublējumu pārvaldības problēmu, mēs instalējām GitLab. Sīkāka informācija pēc rīkiem.

Protams, mēs neesam pirmie, kas risina Ŕādu problēmu, taču mums Ŕķiet, ka mÅ«su praktiskā, grÅ«ti iegÅ«tā pieredze var bÅ«t interesanta un esam gatavi ar to dalÄ«ties.

Tā kā mÅ«su uzņēmumam ir atvērtā pirmkoda politika, mēs meklējām atvērtā koda risinājumu. Savukārt mēs dalāmies ar savām norisēm un ievietojam tās. Piemēram, vietnē GitHub ir mÅ«su Nextcloud spraudnis, ko sniedzam klientiem, uzlabojot datu droŔību nejauÅ”as vai tÄ«Å”as dzÄ“Å”anas gadÄ«jumā.

DublēŔanas rīki

Mēs sākām meklēt risinājumu metodes, izvēloties rezerves izveides rīku.

Parastā tar + gzip nedarbojas labi - dati tiek dublēti. Pieaugums bieži satur ļoti maz faktisko izmaiņu, un liela daļa datu vienā failā tiek atkārtoti.
Ir vēl viena problēma - izkliedētās datu krātuves dublÄ“Å”ana. Mēs izmantojam minio, un tā dati bÅ«tÄ«bā ir lieki. Vai arÄ« jums bija jāizveido dublējums caur paÅ”u minio - ielādējiet to un izmantojiet visus starplikas starp failu sistēmu, un, kas ir ne mazāk svarÄ«gi, pastāv risks aizmirst par dažiem spaiņiem un metainformāciju. Vai arÄ« izmantojiet dedublikāciju.

DublÄ“Å”anas rÄ«ki ar dublÄ“Å”anu ir pieejami atvērtā avotā (HabrĆ© bija Raksts par Å”o tēmu) un mÅ«su finālisti bija Borg Šø AtpÅ«ta. Tālāk ir sniegts mÅ«su abu lietojumprogrammu salÄ«dzinājums, taču pagaidām mēs jums pastāstÄ«sim, kā mēs organizējām visu shēmu.

Dublējumu pārvaldība

Borg un Restic ir labi, taču nevienam no izstrādājumiem nav centralizēta vadÄ«bas mehānisma. PārvaldÄ«bas un kontroles nolÅ«kos izvēlējāmies jau ieviestu rÄ«ku, bez kura nevaram iedomāties savu darbu, tajā skaitā automatizāciju ā€“ tas ir visiem labi zināmais CI/CD ā€“ GitLab.

Ideja ir Ŕāda: gitlab-runner ir instalēts katrā mezglā, kurā tiek glabāti Nextcloud dati. Skrējējs izpilda skriptu pēc grafika, kas uzrauga dublÄ“Å”anas procesu, un tas palaiž Borg vai Restic.

Ko mēs saņēmām? Atsauksmes par izpildi, ērta izmaiņu kontrole, informācija kļūdas gadījumā.

Å”eit ir Å”eit, GitHub mēs ievietojām dažādu uzdevumu skripta piemērus, un galu galā mēs to pievienojām ne tikai Nextcloud, bet arÄ« daudzu citu pakalpojumu dublējumam. Tur ir arÄ« plānotājs, ja nevēlaties to konfigurēt manuāli (un mēs to nevēlamies) un .gitlab-ci.yml

Gitlab API vēl nevar mainīt CI/CD taimautu, taču tas ir mazs. Tas ir jāpalielina, teiksim 1d.

Par laimi GitLab var palaist ne tikai saskaņā ar apņemÅ”anos, bet tikai saskaņā ar grafiku, tas ir tieÅ”i tas, kas mums nepiecieÅ”ams.

Tagad par iesaiņojuma skriptu.

Å im skriptam mēs uzstādÄ«jām Ŕādus nosacÄ«jumus:

  • To vajadzētu palaist gan skrējējam, gan ar roku no konsoles ar tādu paÅ”u funkcionalitāti.
  • Ir jābÅ«t kļūdu apstrādātājiem:
  • atgrieÅ”anas kods.
  • meklējiet virkni žurnālā. Piemēram, mums kļūda var bÅ«t ziņojums, ko programma neuzskata par liktenÄ«gu.
  • Apstrādes noildze. Izpildes laikam jābÅ«t saprātÄ«gam.
  • Mums ir nepiecieÅ”ams ļoti detalizēts žurnāls. Bet tikai kļūdas gadÄ«jumā.
  • Pirms palaiÅ”anas tiek veikti arÄ« vairāki testi.
  • Nelieli bonusi ērtÄ«bām, kas mums noderēja atbalsta procesā:
  • Sākums un beigas tiek ierakstÄ«ti vietējās maŔīnas sistēmas žurnālā. Tas palÄ«dz savienot sistēmas kļūdas un dublÄ“Å”anas darbÄ«bu.
  • Daļa kļūdu žurnāla, ja tāda ir, tiek izvadÄ«ta uz stdout, viss žurnāls tiek ierakstÄ«ts atseviŔķā failā. Ir ērti uzreiz apskatÄ«t CI un novērtēt kļūdu, ja tā ir triviāla.
  • AtkļūdoÅ”anas režīmi.

Pilns žurnāls tiek saglabāts kā artefakts pakalpojumā GitLab; ja kļūdas nav, žurnāls tiek dzēsts. Mēs rakstām skriptu bash valodā.

Mēs ar prieku izskatÄ«sim visus ieteikumus un komentārus saistÄ«bā ar atvērto pirmkodu ā€“ laipni lÅ«dzam.

Kā tas darbojas

Rezerves mezglā tiek palaists skrējējs ar Bash izpildÄ«tāju. Saskaņā ar plānotāju, darbs CI/CD tiek palaists Ä«paŔā rāceņā. Skrējējs palaiž universālu iesaiņojuma skriptu Ŕādiem uzdevumiem, pārbauda dublējuma repozitorija derÄ«gumu, pievienoÅ”anas punktus un visu, ko mēs vēlamies, pēc tam izveido dublējumu un notÄ«ra veco. Pati pabeigtā dublÄ“Å”ana tiek nosÅ«tÄ«ta uz S3.

Mēs strādājam pēc Ŕīs shēmas - tas ir ārējs AWS nodroÅ”inātājs vai Krievijas ekvivalents (tas ir ātrāks un dati neiziet no Krievijas Federācijas). Vai arÄ« Å”im nolÅ«kam mēs instalējam klientam viņa vietnē atseviŔķu minio klasteru. Mēs parasti to darām droŔības apsvērumu dēļ, kad klients nevēlas, lai dati vispār izietu no viņa ķēdes.

Mēs neizmantojām dublējuma sÅ«tÄ«Å”anas funkciju, izmantojot ssh. Tas nepalielina droŔību, un S3 nodroÅ”inātāja tÄ«kla iespējas ir daudz augstākas nekā mÅ«su vienai ssh maŔīnai.

Lai aizsargātu savu vietējo datoru no hakera, jo viņŔ var izdzēst datus S3, jums ir jāiespējo versiju izveide.
Dublējums vienmēr Å”ifrē dublējumu.

Borgam ir neÅ”ifrēts režīms none, taču mēs stingri neiesakām to ieslēgt. Å ajā režīmā ne tikai nebÅ«s Å”ifrÄ“Å”anas, bet arÄ« netiek aprēķināta rakstÄ«tā kontrolsumma, kas nozÄ«mē, ka integritāti var pārbaudÄ«t tikai netieÅ”i, izmantojot indeksus.

AtseviŔķs plānotājs pārbauda dublējumkopiju indeksu un satura integritāti. Pārbaude ir lēna un ilga, tāpēc reizi mēnesÄ« to veicam atseviŔķi. Tas var ilgt vairākas dienas.

Lasi mani krievu valodā

Galvenās funkcijas

  • prepare treniņŔ
  • testcheck gatavÄ«bas pārbaude
  • maincommand galvenā komanda
  • forcepostscript funkcija, kas tiek izpildÄ«ta beigās vai kļūdas dēļ. Mēs to izmantojam, lai atvienotu nodalÄ«jumu.

Servisa funkcijas

  • cleanup Mēs ierakstām kļūdas vai izdzÄ“Å”am žurnāla failu.
  • checklog parsējiet žurnālu, lai atrastu rindu ar kļūdu.
  • ret izejas apstrādātājs.
  • checktimeout pārbaudiet taimautu.

vide

  • VERBOSE=1 Mēs nekavējoties parādām kļūdas ekrānā (stdout).
  • SAVELOGSONSUCCES=1 veiksmes gadÄ«jumā saglabājiet žurnālu.
  • INIT_REPO_IF_NOT_EXIST=1 Izveidojiet repozitoriju, ja tā neeksistē. Atspējots pēc noklusējuma.
  • TIMEOUT maksimālais laiks galvenajai darbÄ«bai. Beigās varat to iestatÄ«t kā "m", "h" vai "d".

Vecu kopiju uzglabāŔanas režīms. Noklusējums:

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

MainÄ«gie lielumi skripta iekÅ”pusē

  • ERROR_STRING ā€” virkne kļūdu reÄ£istrācijas žurnālam.
  • EXTRACT_ERROR_STRING ā€” izteiksme rādÄ«t virkni, ja kļūda.
  • KILL_TIMEOUT_SIGNAL ā€” signāls nogalināŔanai, ja taimauts.
  • TAIL ā€” cik virkņu ar kļūdām ekrānā.
  • COLORMSG ā€” ziņojuma krāsa (pēc noklusējuma dzeltena).

Å im skriptam, ko sauc par WordPress, ir nosacÄ«ts nosaukums, tā viltÄ«ba ir tāda, ka tas dublē arÄ« mysql datubāzi. Tas nozÄ«mē, ka to var izmantot viena mezgla Nexcloud instalācijām, kur varat arÄ« dublēt datubāzi. ĒrtÄ«bas ir ne tikai tas, ka viss ir vienuviet, bet arÄ« datu bāzes saturs ir tuvu failu saturam, jo ā€‹ā€‹laika starpÄ«ba ir minimāla.

Restiks pret Borgu

Ir arÄ« salÄ«dzinājumi starp Borg un Restic Å”eit uz Habrē, un mums nebija uzdevums izveidot tikai vēl vienu, bet gan savu. Mums bija svarÄ«gi, kā tas izskatÄ«sies uz mÅ«su datiem, ar mÅ«su specifiku. Mēs tos atvedam.

MÅ«su atlases kritēriji, papildus jau nosauktajiem (dedublikācija, ātra atkopÅ”ana utt.):

  • IzturÄ«ba pret nepabeigtiem darbiem. PārbaudÄ«t, vai nav nogalināts -9.
  • Izmērs diskā.
  • PrasÄ«bas pēc resursiem (CPU, atmiņa).
  • Uzglabāto lāsumu lielums.
  • Darbs ar S3.
  • Integritātes pārbaude.

TestÄ“Å”anai paņēmām vienu klientu ar reāliem datiem un kopējo izmēru 1,6 TB.
Nosacījumi

Borgs nezina, kā strādāt tieÅ”i ar S3, un mēs uzstādÄ«jām disku kā droÅ”inātāju, izmantojot dumji. Restic to nosÅ«tÄ«ja uz S3 pats.

Goofys strādā ļoti ātri un labi, un tādi ir diska keÅ”atmiņas modulis, kas vēl vairāk paātrina darbu. Tas ir beta stadijā, un, atklāti sakot, mēs avarējām ar datu zudumu testu laikā (citi). Bet ērtÄ«bas ir tādas, ka paÅ”ai dublÄ“Å”anas procedÅ«rai nav nepiecieÅ”ams daudz lasÄ«t, bet galvenokārt rakstÄ«t, tāpēc mēs izmantojam keÅ”atmiņu tikai integritātes pārbaudēs.

Lai samazinātu tīkla ietekmi, mēs izmantojām vietējo pakalpojumu sniedzēju - Yandex Cloud.

SalīdzinoŔās pārbaudes rezultāti.

  • Nogalināt -9 ar turpmāku restartÄ“Å”anu abi bija veiksmÄ«gi.
  • Izmērs diskā. Borgs var saspiest, tāpēc rezultāti ir tādi, kā gaidÄ«ts.

Rezerves kopija
Izmērs

Borg
562Gb

Atpūta
628Gb

  • Pēc CPU
    Pats Borgs patērē maz, ar noklusējuma kompresiju, bet tas jāvērtē kopā ar goofys procesu. Kopumā tie ir salÄ«dzināmi un izmanto aptuveni 1,2 kodolus vienā testa virtuālajā maŔīnā.
  • Atmiņa. Restic ir aptuveni 0,5 GB, Borg ir aptuveni 200 MB. Bet tas viss ir nenozÄ«mÄ«gs, salÄ«dzinot ar sistēmas faila keÅ”atmiņu. Tāpēc ir ieteicams pieŔķirt vairāk atmiņas.
  • Lāses lieluma atŔķirÄ«ba bija pārsteidzoÅ”a.

Rezerves kopija
Izmērs

Borg
apmēram 500 MB

Atpūta
apmēram 5 MB

  • Restic S3 pieredze ir lieliska. Darbs ar Borg, izmantojot goofys, nerada nekādus jautājumus, taču ir atzÄ«mēts, ka ir ieteicams veikt umount pēc tam, kad dublÄ“Å”ana ir pabeigta, lai pilnÄ«bā atiestatÄ«tu keÅ”atmiņu. S3 Ä«patnÄ«ba ir tāda, ka nepietiekami sÅ«knēti gabali nekad netiks nosÅ«tÄ«ti uz spaini, kas nozÄ«mē, ka nepilnÄ«gi aizpildÄ«ti dati rada lielus bojājumus.
  • Integritātes pārbaude darbojas labi abos gadÄ«jumos, taču ātrums ievērojami atŔķiras.
    Restic 3,5 stundas.
    Borg, ar 100 GB SSD failu keÅ”atmiņu - 5 stundas.Apmēram tāds pats ātrums, ja dati atrodas lokālajā diskā.
    Borgs lasa tieÅ”i no S3 bez keÅ”atmiņas 33 stundas. BriesmÄ«gi garÅ”.

BÅ«tÄ«ba ir tāda, ka Borg var saspiest un tam ir lielāki lāsumi, kas padara uzglabāŔanas un GET/PUT operācijas S3 lētākas. Taču tas maksā sarežģītāku un lēnāku verifikāciju. Runājot par atkopÅ”anas ātrumu, mēs nepamanÄ«jām nekādas atŔķirÄ«bas. Nākamās dublējumkopijas (pēc pirmās) Restic aizņem nedaudz ilgāk, bet ne ievērojami.

Pēdējais, bet ne mazāk svarīgais izvēlē bija kopienas lielums.

Un mēs izvēlējāmies borgu.

Daži vārdi par kompresiju

Borga arsenālā ir lielisks jauns saspieÅ”anas algoritms - zstd. Kompresijas kvalitāte nav sliktāka par gzip, bet daudz ātrāka. Un ātrumā salÄ«dzināms ar noklusējuma lz4.

Piemēram, MySQL datu bāzes dump ir saspiests divas reizes labāk nekā lz4 ar tādu paÅ”u ātrumu. Tomēr pieredze ar reāliem datiem rāda, ka Nextcloud mezgla kompresijas pakāpē ir ļoti maz atŔķirÄ«bu.

Borgam ir diezgan bonusa saspieÅ”anas režīms - ja failam ir augsta entropija, tad kompresija netiek pielietota vispār, kas palielina ātrumu. Veidojot, iespējota opcija
-C auto,zstd
zstd algoritmam
Tātad, izmantojot Å”o opciju, mēs saņēmām, salÄ«dzinot ar noklusējuma saspieÅ”anu
560Gb un 562Gb attiecÄ«gi. IepriekÅ” minētā piemēra dati, ļaujiet man jums atgādināt, bez saspieÅ”anas rezultāts ir 628Gb. 2GB starpÄ«bas rezultāts mÅ«s nedaudz pārsteidza, taču domājām, ka tomēr izvēlēsimies to. auto,zstd.

Rezerves pārbaudes metode

Saskaņā ar plānotāja teikto, virtuālā maŔīna tiek palaista tieÅ”i no pakalpojumu sniedzēja vai no klienta, kas ievērojami samazina tÄ«kla slodzi. Vismaz tas ir lētāk nekā paÅ”am celt un vadÄ«t satiksmi.

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/

Izmantojot to paÅ”u shēmu, mēs pārbaudām failus ar antivÄ«rusu (pēc fakta). Galu galā lietotāji Nextcloud augÅ”upielādē dažādas lietas, un ne visiem ir antivÄ«russ. Pārbaužu veikÅ”ana lieÅ”anas laikā aizņem pārāk daudz laika un traucē uzņēmējdarbÄ«bu.

Mērogojamība tiek panākta, palaižot skrējējus dažādos mezglos ar dažādiem tagiem.
MÅ«su uzraudzÄ«ba vienā logā apkopo rezerves statusus, izmantojot GitLab API; ja nepiecieÅ”ams, problēmas ir viegli pamanāmas un tikpat viegli lokalizējamas.

Secinājums

Rezultātā mēs droÅ”i zinām, ka veidojam dublējumkopijas, ka mÅ«su dublējumkopijas ir derÄ«gas, problēmas, kas ar tām rodas, aizņem maz laika un tiek atrisinātas dežūras administratora lÄ«menÄ«. Dublējumkopijas aizņem ļoti maz vietas, salÄ«dzinot ar tar.gz vai Bacula.

Avots: www.habr.com

Pievieno komentāru