Kuidas GitLab aitab teha suurte NextCloudi salvestuskohtade varukoopiaid

Tere, Habr!

Täna tahan rääkida meie kogemustest suurandmete varundamise automatiseerimise osas Nextcloudi salvestites erinevates konfiguratsioonides. Olen "Mollynia AK" CTO, kus tegeleme IT-süsteemide konfiguratsioonihaldusega; andmete salvestamiseks kasutame Nextcloudi, sealhulgas jaotatud struktuuris koos varundamisega.

Probleemid, mis tulenevad installatsioonide iseärasustest, seisnevad andmete rohkusest. Nextcloudi versioonihaldus, varundamine, subjektiivsed põhjused ja muu loovad palju dublette.

Eellugu

Nextcloudi administreerimisel kerkib teravalt esile tõhusate varunduste organiseerimise probleem, mida tuleb kindlasti krüpteerida, kuna andmed on väärtuslikud.

Pakume varundamise salvestamise võimalusi meie juures või kliendi eraldiseisvates Nextcloudist väljaspool asuvates masinates, mis nõuab paindlikku automatiseeritud lähenemist haldamisele.

Kliendid on paljusid, kõik erinevate konfiguratsioonide ja oma eripäradega. Siinkohal ei sobi standardne meetod, kus kogu keskkond kuulub sinule ja varundused tehakse croni kaudu.

Alustame sisendite vaatamisega. Meil on vajalik:

• Skaleeritavus, kas ühel sõlmel või mitmel. Suurte installatsioonide jaoks kasutame salvestamiseks minio.
• Teadlikkus varundamise probleemidest.
• Varundus peab olema kliendi juures ja/või meil.
• Probleemide kiire ja lihtne lahendamine.
• Kliendid ja installatsioonid erinevad üksteisest oluliselt — ühtsuse saavutamine ei õnnestu.
• Taastumise kiirus peab olema minimaalne kahes stsenaariumis: täielik taastamine (õnnetus), üks kaust — kustutatud eksituse tõttu.
• Deduplication funktsioon on kohustuslik.

Varunduste haldamise probleemide lahendamiseks oleme lisanud GitLabi. rohkem üksikasju allpool.

Ilma kahtlusteta ei ole me esimesed, kes sellist probleemi lahendavad, kuid arvame, et meie praktiline, kannatustega saadud kogemus võib olla huvitav ja oleme valmis seda jagama.

Kuna meie ettevõttes valitseb avatud koodi poliitika, otsisime lahendust avatud lähtekoodiga. Omalt poolt jagame oma arendusi ja avaldame need. Näiteks GitHubis on meie Nextcloudi plugin, mida me paigaldame klientidele, et tugevdada andmete kaitsmist juhusliku või kavandatud kustutamise korral.

Varundustooted

Otsime lahenduste meetodeid, alustades varukoopiate loomise vahendi valimisest.

Tavaline tar + gzip töötab halvasti - andmed korduvad. Inkrementaalne koopia sisaldab sageli tõeliselt väga vähe muudatusi ning suur osa andmetest ühes failis kordub.
On veel üks probleem - jaotatud andmehoidla üleliigsus. Me kasutame Minio't ja selle andmed on põhimõtteliselt üleliigsed. Kas pidime varukoopiaid tegema läbi Minio - koormama seda ja kasutama kõiki vahepealseid kihtide vahel ning mis on vähemalt sama oluline, on oht unustada osa ämbrite ja meta-informatsiooni. Või kasutada deduplication'i.

Deduplication'i vahendeid on avatud lähtekoodiga (Habr's olid artikleid sellel teemal) ja meie finalistideks said , kus "kõik töö toimub konteinerites". Kutsume nüüd ajas edasi 2013. aastasse, kui toimus Docker'i esimene väljaanne, ja konteinerid said lõpuks populaarseteks massiliseks lahenduseks. Sel ajal oli peamine tööriist konteinerite orkestreerimiseks ja Restic. Üksikasjad meie kahe rakenduse võrdlemise kohta allpool, aga räägime esmalt, kuidas me kogu skeemi korraldasime.

Varukoopiate loomise haldamine

Borg ja Restic on head, kuid kumbki toode ei oma tsentraliseeritud haldusmehhanismi. Haldamise ja kontrollimise eesmärgil valisime tööriista, mis on meil juba kasutusel, ilma milleta me ei suuda oma tööd ette kujutada, sealhulgas automatiseerimise osas - see on tuntud CI/CD - GitLab.

Idee seisneb järgmises: igale andmeid hoidvale Nextcloud'i sõlmele installitakse gitlab-runner. Runner käivitab ajakava alusel skripti, mis jälgib varukoopiate loomise protsessi, ja see käivitab Borgi või Restici.

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

Siin siit GitHubist oleme üles laadinud skripti näidised erinevate ülesannete jaoks, ning me sidusime selle lõpuks mitte ainult Nextcloud'i, vaid ka paljude teiste teenustega. Seal on ka ajakava, kui ei taha seda käsitsi seadistada (aga me ei taha) ja .gitlab-ci.yml

GitLabi API-s ei ole praegu võimalik muuta CI/CD ajapiiri, ja see on suhteliselt väike. Seda tuleb suurendada, ütleme kuni 1d.

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

Nüüd skripti ümber.

Seadsime sellele skripti jaoks järgmised tingimused:

• Peab töötama nii runneri kui ka käsitsi konsoolist sama funktsionaalsusega.
• Oluline on, et veahaldurid oleksid olemas:
• return code.
• stringi otsimine logis. Näiteks võib meile veaks olla sõnum, mida programm kriitiliseks ei pea.
• Ajavahemiku töötlemine. Täitmise aeg peab olema mõistlik.
• Meil on vaja üksikasjalikku logi. Kuid ainult vigade korral.
• Samuti viiakse enne alustamist läbi rida teste.
• Mõningaid mugavusi, mis me oleme toeks olles leidnud kasulikuks:
• Käivitamine ja lõpetamine fikseeritakse kohaliku masina sisselogis. See aitab siduda süsteemivead ja varundamise töö.
• Osad vealogist, kui need esinevad, väljastatakse stdout-s, kogu logi kirjutatakse eraldi faili. Mugav on kohe CI-s üle vaadata ja hinnata viga, kui see on triviaalne.
• Deebagimise režiimid.

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

Iga ettepanek ja märkused avatud lähtekoodiga oleme rõõmuga valmis arutama — oodatud.

Kuidas see töötab

Varundatavates sõlmedes käivitub runner bashi täitjaga. Ajakava järgi käivitatakse CI/CD ülesanne spetsiaalses repos. Runner käivitab skripti, universaalse ümbriku nende ülesannete jaoks, kus kontrollitakse varundamise repositoriumi, mount-punkte ja kõike, mida soovime, seejärel toimub varundamine ja vana kustutamine. Valmis varundus saadetakse S3-le.

Töötame sellise skeemi järgi — see on välisekspert AWS või Venemaa analoog (see on kiirem ja andmed ei lahku Venemaalt). Või paigaldame kliendile eraldi minio klastri nende territooriumile nende eesmärkide jaoks. Tavaliselt teeme seda turvakaalutlustel, kui klient ei soovi, et andmed lahkuvad nende piiridest.

Me ei kasutanud SSH kaudu varunduse saatmise funktsiooni. See ei suurenda turvalisust ning S3 pakkuja võrguvõimalused on oluliselt kõrgemad kui meie SSH masinal.

Kaitsmiseks häkkerite eest kohaliku masina peal — kuna ta võib kustutada andmeid S3-lt, tuleb kindlasti sisse lülitada versioonimine.
Varundaja krüpteerib alati varunduse.

Borgil on krüpteerimiseta režiim none, kuid me ei soovita seda igal juhul sisse lülitada. Selles režiimis ei toimu mitte ainult krüpteerimist, vaid ka kirjutatavatele andmetele ei arvutata kontrollsumma, mistõttu saab terviklikkust kontrollida ainult kaudselt, indeksite järgi.

Erakonna ajakava alusel kontrollitakse varunduste indeksite ja sisu terviklikkust. Kontrollimine toimub aeglaselt ja kaua, seetõttu käivitame selle eraldi kord kuus. See võib kesta mitu päeva.

Riidmine venekeeles

Peamised funktsioonid

• prepare valmistamine
• testkontroll valmiduse kontroll
• põhkäsu peamine käsk
• sundpostscript funktsioon, mis täidetakse lõpus või vea korral. Kasutame seda jaotise demonteerimiseks.

Teenusefunktsioonid

• cleanup salvestame vead või kustutame logifaili.
• checklog parsing logi vea stringi otsimiseks.
• ret väljumise käitleja.
• checktimeout ajaülevaatus.

Keskkond

• VERBOSE=1 kuvame vead kohe ekraanile (stdout).
• SAVELOGSONSUCCES=1 salvestame logi eduka tulemuse korral.
• INIT_REPO_IF_NOT_EXIST=1 Loome repot, kui seda polnud. Vaikimisi on see keelatud.
• TIMEOUT maksimaalne aeg põhitegevuse jaoks. Saate selle lõppu seada 'm', 'h' või 'd'.

Vana koopia hoidmise režiim. Vaikimisi:

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

Muudatused skripti sees

• ERROR_STRING — string logi kontrollimiseks vea jaoks.
• EXTRACT_ERROR_STRING — väljend, et kuvada string, kui on viga.
• KILL_TIMEOUT_SIGNAL — signaal tapmiseks, kui aega on üle.
• TAIL — kui palju strings vigadest ekraanil.
• COLORMSG — sõnumi värv (vaikimisi kollane).

See skript, mis nimetatakse wordpress, on tinglikult teada, selle eelis on see, et see varundab ka mysql andmebaasi. Seetõttu saab seda kasutada ka Nextcloudi ühekordsetes paigaldustes, kus on võimalik ka andmebaasi varundamine. Mugavus ei seisne ainult selles, et kõik on ühes kohas, vaid ka andmebaasi sisu on tihedalt seotud failide sisuga, kuna ajavahe on minimaalne.

Restic vs Borg

Borg ja Restic'i võrdlused on sealhulgas siin Habr'is, ja meie ülesanne ei olnud lihtsalt teha lihtsalt veel üks, vaid oma. Meie jaoks oli oluline, kuidas see meie andmetega, meie spetsiifikaga välja näeb. Me toome neid.

Meie valikukriteeriumid, peale juba mainitud (de-deduplikatsioon, kiire taastamine jne.):

• Töö katkestamisele vastupidavus. Kontrollimine kill -9 peal.
• Suurus kettal.
• Ressursside nõudlikkus (CPU, mälu).
• Salvestatavate blobide suurus.
• Töö S3-ga.
• Tõejärjestuse kontroll.

Testimiseks võtsime ühe kliendi, kellel on reaalne andmestik ja kogumaht 1,6TB.
Tingimused.

Borg ei oska otse S3-ga töötada, ja me montisime selle fuse kettana, läbi goofys. Restic saatis S3-sse ise.

Goofys töötab väga kiiresti ja hästi, ning sellele on saadaval ketta vahemälu moodul, mis kiirendab tööprotsessi veelgi. See on beetaversioonis ja tunnistama peab, et meil esines katsetel (teistel) andmete kaotamisega probleeme. Kuid mugavage see, et ise varundamisprotseduur ei nõua suurt lugemist, vaid peamiselt kirjutamist, seetõttu kasutame vahemälu ainult andmete terviklikkuse kontrollimisel.

Et vähendada võrgu mõju, kasutasime kohalikke teenusepakkujat — Yandex Cloud.

Testimistulemused võrdlemiseks.

• Kill -9 koos edasise taaskäivitamisega, mõlemad läksid edukalt.
• Suurus kettal. Borg suudab andmeid tihendada, seega on tulemused oodatavad.

Backuper
Suurus

, kus "kõik töö toimub konteinerites". Kutsume nüüd ajas edasi 2013. aastasse, kui toimus Docker'i esimene väljaanne, ja konteinerid said lõpuks populaarseteks massiliseks lahenduseks. Sel ajal oli peamine tööriist konteinerite orkestreerimiseks
562Gb

Restic
628Gb

• CPU järgi
  Iseseisvalt kulutab borg vähe, vaikimisi tihendamisega, kuid seda tuleb koos goofys protsessiga hinnata. Kokku on nad võrdsed ja kasutavad umbes 1,2 tuuma samal testimise virtuaalmasinal.
• Mälu. Restic umbes 0,5Gb, Borg umbes 200Mb. Kuid see kõik on tühine võrreldes süsteemi failide vahemäluga. Seega on soovitav eraldada rohkem mälu.
• Blobide suuruste vahe osutus silmapaistvaks.

Backuper
Suurus

, kus "kõik töö toimub konteinerites". Kutsume nüüd ajas edasi 2013. aastasse, kui toimus Docker'i esimene väljaanne, ja konteinerid said lõpuks populaarseteks massiliseks lahenduseks. Sel ajal oli peamine tööriist konteinerite orkestreerimiseks
umbes 500Mb

Restic
umbes 5Mb

• Töötamine S3-ga Resticuga on suurepärane. Borgi töö goofys'i kaudu ei tekita küsimusi, kuid on märgatud, et varundamise lõppedes on soovitatav teha umount, et vahemälu täielikult lähtestada. S3 tööspetsifikaat on see, et alla laadimata tükid ei saadeta kunagi ämbri, seega osaliselt alla laaditud andmed põhjustavad suuri kahjustusi.
• Integriteedi kontroll töötab mõlemal juhul hästi, kuid kiirus erineb oluliselt.
  Restic – 3,5 tundi.
  Borg, 100Gb SSD failide vahemäluga – 5 tundi. Umbes sama kiirus, kui andmed asuvad kohalikul kettal.
  Borg loeb otse S3-st ilma vahemäluta 33 tundi. Kohutavalt pikk.

Kokkuvõttes suudab Borg andmeid tihendada ja tal on suuremad blobid — mis teeb S3-s salvestamise ja GET/PUT operatsioonid odavamaks. Kuid selle eest tuleb maksta keerulisema ja aeglasema kontrollimisega. Mis puudutab taastamise kiirus — siis me ei märganud mingit erinevust. Järgnevate varunduste (pärast esimest) hulgas teeb Restic veidi kauem, kuid mitte oluliselt.

Kogukonna suurus ei olnud valikus viimasel kohal.

Ja me valisime Borgi.

Mõned sõnad tihendamise kohta

Borgil on oma arsenalis suurepärane uus tihendamisalgoritm — zstd. Tihendamise kvaliteet ei ole halvem kui gzip, kuid oluliselt kiirem. Ja kiiruselt võrreldav vaikimisi lz4-ga.

Näiteks MySQL andmebaasi dump tihendatakse kaks korda paremini kui lz4 sama kiirusel. Siiski näitab kogemus reaalsetel andmetel, et Nextcloud nodi tihendamisel on erinevus väga väike.

Borgis on üsna tore tihendamise režiim — kui failil on suur entropia, siis tihendamine ei toimu üldse, mis suurendab töö kiirus. Seda saab lubada loomise ajal valikuga
-C auto,zstd
zstd algoritmi jaoks
Nii et selle valikuga saime võrreldes vaike tihendamisega
560Gb ja 562Gb vastavalt. Eelmiste näidete andmed, tuletan meelde, ilma kokkusurumiseta on tulemus 628Gb. 2Gb vahe üllatas meid, kuid otsustasime siiski kõik valida. auto,zstd.

Varukoopia kontrollimise meetodika

Virtuaalmasin käivitub otse teenusepakkuja või kliendi juures, mis vähendab võrgu koormust. See on vähemalt odavam kui oma juures tõstatada ja trafiku edastamine.

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 kontrollime faile viirusetõrjega (tagantjärele) sama skeemi järgi. Lõppude lõpuks laadivad kasutajad Nextcloudi erinevat sisu ja mitte kõikidel pole viirusetõrjet. Kontrollimine üleslaadimise hetkel võtab liiga palju aega ja segab äri.

Mastaapsus saavutatakse erinevate siltidega jooksutajate käivitamisega erinevates nodides.
Meie jälgimises kogutakse varukoopiate staatuseid läbi GitLabi API ühte aknasse, vajadusel on probleemid kergesti märgatavad ja samuti kergesti lokaliseeritavad.

Kokkuvõte

Kokkuvõttes teame täpselt, et teeme varukoopiaid, et meie varukoopiad on kehtivad, ja probleemid, mis nendega tekivad, võtavad vähe aega ja lahendatakse ööde administraatori tasemel. Varukoopiad võtavad võrreldes tar.gz või Baculaga tõeliselt vähe ruumi.

Allikas: habr.com