Kuidas GitLab aitab luua varukoopiaid suurtest NextCloud salvestustest

Tere, Habr!

Täna soovin rääkida meie kogemustest suurte andmete salvestamise automatiseeritud varundamise osas Nextcloudis erinevates konfiguratsioonides. Olen "Moltni AK" tegevjuht, kus tegeleme IT süsteemide konfiguratsioonihaldusega, andmete salvestamiseks kasutame Nextcloudi. Sealhulgas, koos hajutatud struktuuriga ja varundamisega.

Probleemid tulenevad installatsioonide eripärast, kuna andmeid on palju. Nextcloud pakub versioonimist, varundamist, subjektiivseid põhjuseid ja muud, mis loob palju dubleeringuid.

Eelalugu

Nextcloudi haldamisel tõuseb teravalt esile tõhusate varukoopiate korraldamise probleem, mis tuleks kindlasti krüpteerida, kuna andmed on väärtuslikud.

Pakume varukoopia säilitamise võimalusi kas meie juures või kliendi eraldi masinatel, mis ei ole seotud Nextcloudiga, mis nõuab paindlikku automatiseeritud lähenemist haldamisele.

Kliente on palju, kõik nad on erinevate konfiguratsioonidega ning kõik oma platsidel ja omaduste poolest. Siin ei sobi standardne meetod, kus kogu plats kuulub sulle, ja varukoopiad tehakse croni abil.

Käime läbi vajalikud andmed. Me vajame:

• Mastaapsust ühe sõlme või mitme osas. Suurte paigalduste korral kasutame salvestuseks miniot.
• Saada teavitusi varukoopiate täitmise probleemidest.
• Peame hoidma varukoopiadi kliendi juures ja/või meie juures.
• Probleemidega tuleb kiiresti ja lihtsalt tegeleda.
• Kliendid ja paigaldused on omavahel väga erinevad — ühtsust ei õnnestu saavutada.
• Taastamise kiirus peab olema minimaalne kahes stsenaariumis: täielik taastamine (hädaolukord), ühe kausta kustutamine eksikombel.
• Dedupeerimise funktsioon on kohustuslik.

Varukoopiate haldamiseks sidusime GitLabi. Üksikasjad allpool.

Muidugi, me ei ole esimesed, kes seda probleemi lahendavad, kuid usume, et meie praktiline ja kurnav kogemus võib olla huvitav ning oleme valmis seda jagama.

Kuna meie ettevõttes on kehtestatud avatud lähtekoodiga poliitika, otsisime lahendust avatud lähtekoodiga. Samuti jagame oma arendustöid ja avaldame neid. Näiteks GitHubis on meie plugina Nextcloudile, mille me klientidele, mis suurendab andmete säilimist juhusliku või tahtliku kustutamise korral.

Varundamise vahendid

Lahenduste otsimise alustasime varundamisvahendi valimisega.

Tavaline tar + gzip ei tööta hästi – andmed dubleeritakse. Inkrement sisaldab sageli tegelikult väga vähe muudatusi, ning enamik andmeid ühe faili sees kordub.
On veel üks probleem – jaotatud andmehoidla ülemäärasus. Kasutame minio't ja tema andmed on põhimõtteliselt ülemäärased. Ent varundamine tuleb teha kas minio kaudu – koormates seda ja kasutades kõiki vahekihti failisüsteemi vahel, ning mis on mitte vähem oluline, on oht unustada osa bucketitest ja meta-informatsioonist. Või kasutada deduplikatsiooni.

Dedupikatsiooniga varundamisvahendid on avatud lähtekoodiga (Habr oli artikkel selle teema kohta) ja meie finalistideks said Borg ja Restic. Meie kahe rakenduse võrdlusest allpool, aga räägime seni, kuidas me kogu skeemi korraldasime.

Varundamise loomise haldamine

Borg ja Restic on head, kuid kumbagi toodet ei iseloomusta tsentraliseeritud haldussüsteem. Halduse ja kontrolli eesmärgil valisime tööriista, mis meil juba kasutuses on ja ilma milleta me oma tööd ette ei kujuta, sealhulgas automatiseerimise osas — see on tuntud CI/CD – GitLab.

Idee seisneb järgmis: iga andmeid salvestav Nextcloudi node paigaldatakse gitlab-runner. Rannert käivitab ajakava alusel skripti, mis jälgib varundusprotsessi ja see käivitab Borgi või Restici.

Mida me saime? Tagasiside täitmisest, mugav kontroll muutuste üle, üksikasjad vea korral.

Siin on siin GitHubis oleme välja pannud skripti näited erinevate ülesannete jaoks, mille oleme lõpuks sidunud mitte ainult Nextcloudi, vaid ka paljude teiste teenuste varundusega. Seal on samuti ajakava, kui te ei soovi seda käsitsi seadistada (ja me ei soovi) ja .gitlab-ci.yml

GitLabi API-s pole hetkel võimalust CI/CD timeouti muuta, kuid see on üsna lühike. Seda tuleb suurendada, ütleme, et 1d.

Õnneks oskab GitLab käivitada mitte ainult commit'i alusel, vaid ka ajakava järgi, mis on just see, mida me vajame.

Nüüd skripti katte kohta.

Seadsime sellele skriptile sellised nõuded:

• Peab käima nii runnerina kui ka käsitsi konsoolist sama funktsionaalsusega.
• Vigade käitlejad peavad olema kindlasti olemas:
• tagastus kood.
• stringi otsimine logis. Näiteks võib meie jaoks veaks olla sõnum, mida programm ei pea kriitiliseks.
• Aegumise käitlemine. Täitmise aeg peaks olema mõistlik.
• Vajame väga detailset logi, kuid ainult vea korral.
• Enne algust toimub ka mitmeid teste.
• Mugavused, mis me leidsime toredateks toetuste haldamise käigus:
• Käivitamine ja lõpetamine registreeritakse kohaliku masina süsteemilogis. See aitab siduda süsteemi vigu ja varukoopia töö.
• Osa vealogist, kui need on olemas, antakse stdout-i, kogu logi kirjutatakse eraldi faili. Mugav on kohe CI vaadata ja hinnata viga, kui see on triviaalne.
• Veabugide režiimid.

Täielik logi salvestatakse artefaktina GitLabi, kui viga ei ole, siis logi kustutatakse. Skripti kirjutame bashis.

Igale avatud koodiga seonduvale ettepanekule ja märkusele oleme avatud — tere tulemast.

Kuidas see toimib

Varundatav node käivitab runneri bash executoriga. Planeerija kaudu käivitatakse job CI/CD spetsiaalses repost. Runner käivitab universaalse skripti selliste ülesannete jaoks, kus kontrollitakse varundusrepo, mount-punkte ja kõike, mida soovime. Siis tehakse varundamine ja vana eemaldamine. Valmis varundus saadetakse S3-le.

Me töötame sellise skeemi alusel — see on välitingimustes teenusepakkuja AWS või Venemaa analoog (see on kiirem ja andmed ei lahku Venemaalt). Kas paneme kliendile eraldi minio kihi tema ruumis selliste eesmärkide jaoks. Tavaliselt teeme seda turvalisuse kaalutlustel, kui klient ei soovi, et andmed lahkuksid nende kontuurist.

Me ei hakanud kasutama varuneda saatmise funktsiooni ssh kaudu. See ei lisa turvalisust ja S3 teenusepakkuja võrguvõimalused on palju paremad kui meie üks ssh masin.

Häkkerite kaitsmiseks kohaliku masina pealt — sest ta võib kustutada andmeid S3-lt, tuleb kindlasti sisse lülitada versioonimine.
Varundaja krüpteerib alati varunduse.

Borgil on olemas krüpteerimata režiim. ei midagi, kuid me ei soovita tungivalt selle aktiveerimist. Selles režiimis ei toimu mitte ainult krüpteerimist, vaid ka kirjutatava sisu kontrollsummat ei arvutata, seega saab terviklikkust kontrollida ainult kaudselt, indeksite kaudu.

Erineva ajakava alusel kontrollitakse varukoopiaid indeksite ja sisu terviklikkuse osas. Kontrollimine toimub aeglaselt ja pikalt, nii et käivitame selle eraldi kord kuus. See võib kesta mitu päeva.

Readme eesti keeles

Peamised funktsioonid

• prepare valmistamine
• testcheck valmiduse kontrollimine
• peamine käsk põhikäsk
• forcepostscript funktsioon, mis täidetakse lõpuks või vea korral. Kasutame seda jaotuse lahtiühendamiseks.

Teenusefunktsioonid

• cleanup salvestame vead või kustutame logifaili.
• checklog parsing logi viga sõnaga.
• ret väljapääsu käitleja.
• checktimeout kontrollimine aja ületamiseks.

Keskkond

• VERBOSE=1 kuvame vead kohe ekraanile (stdout).
• SAVELOGSONSUCCES=1 salvestame logi eduka toimingu korral.
• INIT_REPO_IF_NOT_EXIST=1 Loome reposi, kui seda pole olnud. Vaikimisi keelatud.
• TIMEOUT maksimaalne aeg põhitoiminguks. Saate selle lõpuks seadistada 'm', 'h' või 'd'.

Vanade koopiaide säilitamise režiim. Vaikimisi:

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

Muutujad skripti sees

• ERROR_STRING — string logi kontrollimiseks vea korral.
• EXTRACT_ERROR_STRING — väljend, mis näitab stringi, kui on viga.
• KILL_TIMEOUT_SIGNAL — signaal tapmiseks, kui toimub aegumine.
• TAIL — mitu stringi, kus on vead ekraanil.
• COLORMSG — sõnumi värv (vaikimisi kollane).

See skript, mida nimetatakse wordpressiks, kannab tinglikku nime. Selle omadus on see, et see varundab ka MySQL andmebaasi. Seega võib seda kasutada ühekordsete Nexcloud installatsioonide jaoks, kus saab samal ajal ka andmebaasi varundada. Mugavus seisneb mitte ainult selles, et kõik on ühes kohas, vaid ka andmebaasi sisu on lähedane failide sisule, kuna vahe on aega minimaalne.

Restic vs Borg

Borgi ja Restici võrdlused on sealhulgas siin Habr's, ja meil ei olnud ülesannet teha lihtsalt veel üks, vaid oma. Meile oli oluline, kuidas see meie andmete, meie spetsiifika puhul välja näeb. Toome neid.

Meie valikukriteeriumid, peale juba mainitud (deduplication, kiire taastamine jne):

• Tugevus lõpetamata töö suhtes. Kontroll kill -9.
• Keti suurus.
• Resursside nõudlikkus (CPU, mälu).
• Ladustatavate blobide suurus.
• Töö S3-ga.
• Tervekuse kontroll.

Testimiseks võtsime ühe kliendi reaalsete andmetega, mille kogusumma on 1,6TB.
Tingimused.

Borg ei oska otse S3-ga töötada, seega montasime selle fuse-kettana, kasutades goofys. Restic edastas andmed S3-sse ise.

Goofys töötab väga kiiresti ja tõhusalt, ning sellel on diskivahendi vahemälu, mis veelgi kiirendab tööd. See on beetaversioonis ja ausalt öeldes on meil testide jooksul olnud andmete kadumisega seonduvaid probleeme (teistes). Kuid mugavuseks ei nõua varundamisprotseduur suurt lugemist, pigem kirjutamist, seega kasutame vahemälu ainult andmete terviklikkuse kontrollimise ajal.

Võrgu mõju vähendamiseks kasutasime kohaliku teenusepakkuja — Yandex Cloud.

Testimise tulemused võrdlemiseks.

• Kill -9 ja edasine taaskäivitamine läksid mõlemad edukalt.
• Kettaruumi suurus. Borg suudab andmeid tihendada, seega on tulemused oodatud.

Varundaja
Suurus

Borg
562Gb

Restic
628Gb

• CPU kohta
  Borg ise tarbib vähe ressursse, vaikeseade tihendamisel, kuid hinnata tuleb koos goofysi protsessiga. Kokkuvõttes on need sarnased ja kasutavad umbes 1,2 südamikku samal katse virtuaalmasinal.
• Mälu. Restic umbes 0,5Gb, Borg umbes 200Mb. Kuid kõik see on ebaoluline võrreldes süsteemi failide vahemäluga. Seega soovitatakse anda rohkem mälu.
• Blobi suuruse erinevus oli silmatorkav.

Varundaja
Suurus

Borg
umbes 500Mb

Restic
umbes 5Mb

• Restici S3 töö on suurepärane. Borgi töö goofys kaudu ei tekita probleeme, kuid on täheldatud, et soovitatav on pärast varundamise lõppu teha umount, et täielikult vahemälu vabastada. S3 töö eripära on see, et mitteülekantavaid chunk'e ei saadeta kunagi ämbrisse, mistõttu mittetäielikud andmed toovad kaasa suuri kahjustusi.
• Kõikide juhtumite integreerituse kontroll töötab hästi, kuid kiirus erineb oluliselt.
  Restic – 3,5 tundi.
  Borg, 100GB SSD failivahemäluga – 5 tundi. Umbes sama kiirus, kui andmed asuvad kohalikul kettal.
  Borg loeb otse S3-st ilma vahemäluta 33 tundi. Üli pikk aeg.

Kokkuvõttes suudab Borg tihendada ja tal on suuremad blobid — see muudab säilitamise ja S3 GET/PUT operatsioonide odavamaks. Kuid selle eest tuleb maksta keerukama ja aeglasema kontrollimisega. Mis puudutab taastamise kiirus, siis me ei täheldanud erinevust. Järgnevad varundamised (pärast esimest) resticiga võtavad veidi rohkem aega, kuid mitte oluliselt.

Tähtis tegur valiku tegemisel oli ka kogukonna suurus.

Ja me valisime borgi.

Mõned sõnad tihendamise kohta

Borg'il on suurepärane uus kompressioonalgrithm - zstd. Kompressioonikvaliteedilt ei jää see alla gzip'ile, kuid on oluliselt kiirem. Kiiruselt on see võrreldav vaikimisi lz4'iga.

Näiteks MySQL andmebaasi dump kompressitakse umbes kaks korda paremini kui lz4 sama kiirusel. Siiski näitab kogemus reaalsed andmetega, et Nextcloud'i node'del on kompressiooni määrade vahel väga vähe erinevusi.

Borg'il on üsna boonuseh mode, kus kui failil on kõrge entropia, ei rakendata kompressiooni üldse, mis kiirendab tööprotsessi. See võimalus aktiveeritakse loomisel.
-C auto,zstd
zstd algoritmiga
Nii et selle valikuga võrreldes vaikimisi kompressiooniga saame
560Gb ja 562Gb vastavalt. Eelmise näite andmed, tuletan meelde, kompressioonita on tulemus 628Gb. 2Gb erinevuse tulemus üllatas meid veidi, kuid otsustasime lõpuks valida auto,zstd.

Varukoopia kontrollimise meetodika

Süsteem tõstatab virtuaalmasina otse teenusepakkuja või kliendi juures, mis vähendab oluliselt võrgu koormust. Vähemalt on see odavam kui kasutada enda infrastruktuuri ja andmeid edastada.

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/

Antiviiruse kontroll toimub sama skeemi alusel (tagantjärele). Lõppude lõpuks laadivad kasutajad Nextcloudi erinevaid faile ning mitte kõigil pole antiviirust. Failide kontrollimise tegemine üleslaadimise hetkel võtab liiga palju aega ja häirib äritegevust.

Skaleeritavus saavutatakse erinevates node'ides erinevate märkide (tagide) abil jooksutades.
Meie jälgimise süsteemis kogutakse varukoopiate staatust läbi GitLabi API ühes aknas; vajadusel on probleemid kergesti märgatavad ja samamoodi kergesti lahendatavad.

Kokkuvõte

Kokkuvõttes teame, et varukoopiad tehakse, meie varukoopiad on kehtivad, nende probleemide lahendamine võtab vähe aega ja toimub ringkonnasekretäri tasandil. Varukoopiad võtavad tegelikult võrreldes tar.gz või Baculaga tõeliselt vähe ruumi.

Allikas: habr.com