Kuinka GitLab auttaa sinua varmuuskopioimaan suuria NextCloud-tallennustilaa

Hei Habr!

Tänään haluan puhua kokemuksistamme Big Datan varmuuskopioinnin automatisoinnista Nextcloud-varastoista eri kokoonpanoissa. Työskentelen huoltoasemana Molniya AK:ssa, jossa teemme IT-järjestelmien konfiguraatioiden hallintaa; Nextcloudia käytetään tietojen tallentamiseen. Mukaan lukien, hajautetulla rakenteella, redundanssilla.

Asennusten ominaisuuksista johtuvat ongelmat ovat se, että dataa on paljon. Nextcloudin tarjoamat versiot, redundanssi, subjektiiviset syyt ja paljon muuta luovat monia kaksoiskappaleita.

esihistoria

Nextcloudia hallittaessa syntyy ongelma tehokkaan varmuuskopion järjestämisessä, joka on salattava, koska tiedot ovat arvokkaita.

Tarjoamme vaihtoehtoja varmuuskopioiden tallentamiseen meillä tai asiakkaan luona erillisille koneille Nextcloudista, mikä edellyttää joustavaa automatisoitua hallintaa.

Asiakkaita on monia, kaikki eri kokoonpanoilla ja kaikki omilla sivustoillaan ja omilla ominaisuuksillaan. Tämä on vakiotekniikka, kun koko sivusto kuuluu sinulle ja varmuuskopiot tehdään kruunuista; se ei sovi hyvin.

Katsotaanpa ensin syötetietoja. Me tarvitsemme:

• Skaalautuvuus yhden tai useamman solmun osalta. Suurissa asennuksissa käytämme minioa varastona.
• Ota selvää varmuuskopiointiin liittyvistä ongelmista.
• Sinun on pidettävä varmuuskopio asiakkaidesi ja/tai meidän kanssamme.
• Käsittele ongelmat nopeasti ja helposti.
• Asiakkaat ja asennukset ovat hyvin erilaisia ​​- yhtenäisyyttä ei voida saavuttaa.
• Palautusnopeuden tulisi olla minimaalinen kahdessa tilanteessa: täydellinen palautuminen (katastrofi), yksi kansio tyhjennetään vahingossa.
• Deduplikointitoiminto vaaditaan.

Varmuuskopioiden hallinnan ongelman ratkaisemiseksi asensimme GitLabin. Tarkemmat tiedot taklakohtaisesti.

Emme tietenkään ole ensimmäisiä, jotka ratkaisevat tällaisen ongelman, mutta meistä näyttää siltä, ​​​​että käytännön, kovalla työllä ansaittu kokemuksemme voi olla mielenkiintoista ja olemme valmiita jakamaan sen.

Koska yrityksellämme on avoimen lähdekoodin käytäntö, etsimme avoimen lähdekoodin ratkaisua. Jaamme puolestamme kehitystyömme ja julkaisemme ne. Esimerkiksi GitHubissa on lisäosamme Nextcloudille, jonka tarjoamme asiakkaille, mikä parantaa tietoturvaa vahingossa tai tahallisesti tapahtuvan poistamisen varalta.

Varmuuskopiointityökalut

Aloitimme ratkaisumenetelmien etsimisen valitsemalla varmuuskopion luontityökalun.

Tavallinen tar + gzip ei toimi hyvin - tiedot kopioidaan. Kasvu sisältää usein hyvin vähän todellisia muutoksia, ja suuri osa yhden tiedoston tiedoista toistetaan.
On toinenkin ongelma - hajautetun tiedon tallennuksen redundanssi. Käytämme minioa ja sen tiedot ovat periaatteessa redundantteja. Tai sinun piti tehdä varmuuskopio itse minion kautta - lataa se ja käytä kaikki välikkeet tiedostojärjestelmän välillä, ja, mikä ei ole vähemmän tärkeää, on olemassa vaara, että unohdat jotkin kauhat ja metatiedot. Tai käytä deduplikaatiota.

Varmuuskopiointityökalut päällekkäisyydellä ovat saatavilla avoimessa lähdekoodissa (Habressa oli Artikkeli tässä aiheessa) ja finalistimme olivat Borg и Resti. Vertailumme kahdesta sovelluksesta on alla, mutta toistaiseksi kerromme, kuinka järjestimme koko järjestelmän.

Varmuuskopioiden hallinta

Borg ja Restic ovat hyviä, mutta kummallakaan tuotteella ei ole keskitettyä ohjausmekanismia. Valitsimme hallintaan ja ohjaukseen jo toteuttamamme työkalun, jota ilman emme voi kuvitellakaan työtämme, mukaan lukien automaatio - tämä on tuttu CI/CD - GitLab.

Idea on seuraava: gitlab-runner asennetaan jokaiseen solmuun, joka tallentaa Nextcloud-tietoja. Runner suorittaa skriptin aikataulussa, joka valvoo varmuuskopiointiprosessia, ja käynnistää Borgin tai Resticin.

Mitä saimme? Palaute toteutuksesta, kätevä muutosten hallinta, yksityiskohdat virheen sattuessa.

Täällä täällä GitHubissa julkaisimme esimerkkejä eri tehtävien komentosarjasta, ja päädyimme liittämään sen paitsi Nextcloudin, myös monien muiden palvelujen varmuuskopioon. Siellä on myös ajastin, jos et halua määrittää sitä manuaalisesti (emmekä halua) ja .gitlab-ci.yml

Gitlab API:ssa ei ole vielä mahdollista muuttaa CI/CD-aikakatkaisua, mutta se on pieni. Sitä on lisättävä, sanotaanko 1d.

Onneksi GitLab voi käynnistää ei vain sitoumuksen mukaan, vaan vain aikataulun mukaan, tämä on juuri sitä mitä tarvitsemme.

Nyt käärekäsikirjoituksesta.

Asetamme tälle skriptille seuraavat ehdot:

• Se tulisi käynnistää sekä juoksijalla että käsin konsolista samalla toiminnallisuudella.
• Virheenkäsittelijöitä pitää olla:
• palautuskoodi.
• etsi merkkijono lokista. Esimerkiksi meille virhe voi olla viesti, jota ohjelma ei pidä kohtalokkaana.
• Käsittelyn aikakatkaisu. Toimitusajan tulee olla kohtuullinen.
• Tarvitsemme erittäin yksityiskohtaisen lokin. Mutta vain virheen sattuessa.
• Ennen käynnistystä suoritetaan myös useita testejä.
• Pienet bonukset, joista pidimme apua tukiprosessin aikana:
• Alku ja loppu tallennetaan paikallisen koneen syslogiin. Tämä auttaa yhdistämään järjestelmävirheet ja varmuuskopiointitoiminnot.
• Osa virhelokista, jos sellainen on, tulostetaan stdoutiin, koko loki kirjoitetaan erilliseen tiedostoon. On kätevää katsoa välittömästi CI:tä ja arvioida virhe, jos se on vähäpätöinen.
• Virheenkorjaustilat.

Täysi loki tallennetaan artefaktina GitLabiin; jos virhettä ei ole, loki poistetaan. Kirjoitamme käsikirjoituksen bashilla.

Otamme mielellämme kaikki avoimeen lähdekoodiin liittyvät ehdotukset ja kommentit - tervetuloa.

Kuinka tämä toimii

Runner, jossa on Bash-suorittaja, käynnistetään varasolmussa. Aikatauluttajan mukaan työ CI/CD käynnistetään erikoisnauriissa. Runner käynnistää yleisen wrapper-skriptin tällaisia ​​tehtäviä varten, se tarkistaa varmuuskopiovaraston, liitospisteiden ja kaiken haluamamme kelvollisuuden, sitten varmuuskopioi ja puhdistaa vanhan. Itse valmis varmuuskopio lähetetään S3:een.

Työskentelemme tämän järjestelmän mukaan - se on ulkoinen AWS-palveluntarjoaja tai venäläinen vastaava (se on nopeampi ja tiedot eivät poistu Venäjän federaatiosta). Tai asennamme asiakkaan sivustolle erillisen miniklusterin näitä tarkoituksia varten. Yleensä teemme tämän turvallisuussyistä, kun asiakas ei halua tietojen poistuvan piiristään ollenkaan.

Emme käyttäneet varmuuskopion lähettämistä ssh:n kautta. Tämä ei lisää turvallisuutta, ja S3-palveluntarjoajan verkkoominaisuudet ovat paljon korkeammat kuin yhdellä ssh-koneellamme.

Suojataksesi paikallista konettasi hakkereilta, koska hän voi poistaa tietoja S3:sta, sinun on otettava versiointi käyttöön.
Varmuuskopio salaa aina varmuuskopion.

Borgilla on salaamaton tila none, mutta emme suosittele sen kytkemistä päälle. Tässä tilassa ei vain ole salausta, mutta myös kirjoitettavan tarkistussummaa ei lasketa, mikä tarkoittaa, että eheys voidaan tarkistaa vain epäsuorasti indeksien avulla.

Erillinen ajoitusohjelma tarkistaa varmuuskopioiden hakemistojen ja sisällön eheyden. Sekki on hidas ja pitkä, joten teemme sen erikseen kerran kuukaudessa. Se voi kestää useita päiviä.

Readme venäjäksi

Päätoiminnot

• prepare koulutus
• testcheck valmiustarkastus
• maincommand ydinjoukkue
• forcepostscript toiminto, joka suoritetaan lopussa tai virheen seurauksena. Käytämme sitä osion poistamiseen.

Palvelutoiminnot

• cleanup Tallennamme virheet tai poistamme lokitiedoston.
• checklog jäsentää lokista virheen sisältävän rivin esiintymisen.
• ret poistumiskäsittelijä.
• checktimeout tarkista aikakatkaisu.

ympäristö

• VERBOSE=1 Näytämme virheet näytöllä välittömästi (stdout).
• SAVELOGSONSUCCES=1 tallenna loki onnistumisen jälkeen.
• INIT_REPO_IF_NOT_EXIST=1 Luo arkisto, jos sitä ei ole olemassa. Ei käytössä oletuksena.
• TIMEOUT päätoiminnon enimmäisaika. Voit asettaa sen lopussa "m", "h" tai "d".

Säilytystila vanhoille kopioille. Oletus:

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

Muuttujat skriptin sisällä

• ERROR_STRING — merkkijono virheen kirjautumislokin varalta.
• EXTRACT_ERROR_STRING — lauseke näytä merkkijonolle jos virhe.
• KILL_TIMEOUT_SIGNAL — signaali tappamisesta, jos aikakatkaisu.
• TAIL — kuinka monta merkkijonoa, joissa on virheitä näytöllä.
• COLORMSG — viestin väri (oletusasetus keltainen).

Skriptillä, jota kutsutaan wordpressiksi, on ehdollinen nimi, sen temppu on, että se varmuuskopioi myös mysql-tietokannan. Tämä tarkoittaa, että sitä voidaan käyttää yhden solmun Nexcloud-asennuksiin, joissa voit myös varmuuskopioida tietokannan. Mukavuus ei ole vain se, että kaikki on yhdessä paikassa, vaan myös tietokannan sisältö on lähellä tiedostojen sisältöä, koska aikaero on minimaalinen.

Restic vs Borg

Borgin ja Resticin välillä on myös vertailuja täällä Habrella, ja meidän tehtävänä ei ollut tehdä vain toista, vaan omamme. Meille oli tärkeää, miltä se näyttäisi tiedoissamme, erityispiirteidemme kanssa. Tuomme ne.

Valintakriteerimme edellä mainittujen lisäksi (duplikaatio, nopea palautus jne.):

• Kestää keskeneräistä työtä. Tarkista tappaminen -9.
• Koko levyllä.
• Resurssitarve (CPU, muisti).
• Tallennettujen möykkyjen koko.
• Työskentely S3:n kanssa.
• Eheyden tarkistus.

Testaukseen otimme yhden asiakkaan, jolla oli todellista dataa ja jonka kokonaiskoko oli 1,6 TB.
Olosuhteissa.

Borg ei osaa työskennellä suoraan S3:n kanssa, ja asensimme levyn sulakkeeksi, kautta hölmöjä. Restic lähetti sen itse S3:lle.

Goofys toimii erittäin nopeasti ja hyvin, ja niitä on levyvälimuistimoduuli, mikä nopeuttaa työtä entisestään. Se on beta-vaiheessa, ja suoraan sanottuna kaatimme tietojen menettämiseen testien aikana (muut). Mukavuus on kuitenkin se, että varmuuskopiointiprosessi itsessään ei vaadi paljon lukemista, vaan enimmäkseen kirjoittamista, joten käytämme välimuistia vain eheystarkistuksissa.

Verkon vaikutuksen vähentämiseksi käytimme paikallista palveluntarjoajaa - Yandex Cloudia.

Vertailutestien tulokset.

• Kill -9 ja uusi uudelleenkäynnistys onnistuivat molemmat.
• Koko levyllä. Borg voi pakata, joten tulokset ovat odotetut.

Varmuuskopioija
koko

Borg
562Gb

Resti
628Gb

• CPU:n mukaan
  Borg itse kuluttaa vähän, oletuspakkauksella, mutta se on arvioitava yhdessä goofys-prosessin kanssa. Kaiken kaikkiaan ne ovat vertailukelpoisia ja käyttävät noin 1,2 ydintä samassa virtuaalikoneessa.
• Muisti. Restic on noin 0,5 Gt, Borg on noin 200 Mt. Mutta tämä kaikki on merkityksetöntä järjestelmän tiedostovälimuistiin verrattuna. Joten on suositeltavaa varata enemmän muistia.
• Ero möykkyjen koossa oli silmiinpistävä.

Varmuuskopioija
koko

Borg
noin 500 MB

Resti
noin 5 MB

• Resticin S3-kokemus on erinomainen. Työskentely Borgin kanssa goofysin kautta ei herätä kysymyksiä, mutta on todettu, että on suositeltavaa tehdä umount sen jälkeen, kun varmuuskopiointi on valmis, jotta välimuisti nollataan kokonaan. S3:n erikoisuus on, että alipumpattuja paloja ei koskaan lähetetä ämpäriin, mikä tarkoittaa, että puutteellisesti täytetty data johtaa suuriin vaurioihin.
• Eheyden tarkistus toimii hyvin molemmissa tapauksissa, mutta nopeus vaihtelee huomattavasti.
  Resti 3,5 tuntia.
  Borg, jossa on 100 Gt SSD-tiedostovälimuisti - 5 tuntia. Nopeus on suunnilleen sama, jos tiedot ovat paikallisella levyllä.
  Borg lukee suoraan S3:sta ilman välimuistia 33 tuntia. Hirveän pitkä.

Tärkeintä on, että Borg voi pakata ja siinä on suurempia blobeja - mikä tekee tallennus- ja GET/PUT-toiminnoista S3:ssa halvempia. Mutta tämä maksaa monimutkaisemman ja hitaamman vahvistuksen. Mitä tulee palautumisnopeuteen, emme huomanneet mitään eroa. Restic vie seuraavat varmuuskopiot (ensimmäisen jälkeen) hieman kauemmin, mutta ei merkittävästi.

Viimeisenä mutta ei vähäisimpänä valinnassa oli yhteisön koko.

Ja valitsimme borgin.

Muutama sana puristamisesta

Borgin arsenaalissa on erinomainen uusi pakkausalgoritmi - zstd. Pakkauslaatu ei ole huonompi kuin gzip, mutta paljon nopeampi. Ja nopeudeltaan verrattavissa oletusarvoiseen lz4:ään.

Esimerkiksi MySQL-tietokantavedos pakataan kaksi kertaa paremmin kuin lz4 samalla nopeudella. Kokemus todellisista tiedoista osoittaa kuitenkin, että Nextcloud-solmun pakkaussuhteessa on hyvin vähän eroa.

Borgilla on melko bonuspakkaustila - jos tiedostolla on korkea entropia, pakkausta ei käytetä ollenkaan, mikä lisää nopeutta. Otetaan käyttöön valinnalla luotaessa
-C auto,zstd
zstd-algoritmille
Joten tällä vaihtoehdolla saimme oletuspakkaukseen verrattuna
560 Gb ja 562 Gb vastaavasti. Yllä olevan esimerkin tiedot, muistutan teitä, ilman pakkausta tulos on 628Gb. 2 Gt:n eron tulos yllätti meidät jonkin verran, mutta ajattelimme, että valitsemme sen kuitenkin. auto,zstd.

Varmuuskopion vahvistusmenetelmä

Aikatauluttajan mukaan virtuaalikone käynnistetään suoraan palveluntarjoajalta tai asiakkaalta, mikä vähentää huomattavasti verkon kuormitusta. Ainakin se on halvempaa kuin itse kasvattaminen ja liikenteen ohjaaminen.

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/

Samaa järjestelmää käyttämällä tarkistamme tiedostot viruksentorjuntaohjelmalla (todellisuuden jälkeen). Loppujen lopuksi käyttäjät lataavat erilaisia ​​asioita Nextcloudiin, eikä kaikilla ole virustorjuntaa. Tarkastusten tekeminen kaatamisen yhteydessä vie liikaa aikaa ja häiritsee liiketoimintaa.

Skaalautuvuus saavutetaan ajamalla juoksijat eri solmuissa eri tunnisteilla.
Valvontamme kerää varmuuskopioiden tilat GitLab API:n kautta yhteen ikkunaan, tarvittaessa ongelmat havaitaan helposti ja lokalisoidaan yhtä helposti.

Johtopäätös

Tämän seurauksena tiedämme varmasti, että teemme varmuuskopioita, että varmuuskopiomme ovat päteviä, niiden kanssa ilmenevät ongelmat vievät vähän aikaa ja ne ratkaistaan ​​päivystäjätasolla. Varmuuskopiot vievät todella vähän tilaa verrattuna tar.gz- tai Baculaan.

Lähde: will.com