Tagasüsteem tuhandete virtuaalmasinate jaoks tasuta tööriistadega

Tere, hiljuti sattusin huvitavale ülesandele seadistada salvestusruum suure hulga plokkseadmete varukoopiate jaoks.

Igal nädalal teeme varukoopiaid kõigist virtuaalmasinatest meie pilves, seega peab olema suutlik hallata tuhandeid varukoopiaid ja teha seda võimalikult kiiresti ja tõhusalt.

Kahjuks ei sobi tavalised konfiguratsioonid RAID5, RAID6 antud juhul meile ei sobi, kuna nende suurte ketaste nagu meie omad taastamisprotsess on vaevarikas ja tõenäoliselt ei lõpe kunagi.

Vaatame, millised alternatiivid on:

Erasure Coding — RAID5, RAID6 analoog, kuid konfigureeritava pariteedi tasemega. Varundamine toimub mitte plokkide kaupa, vaid iga objekti kaupa eraldi. Lihtsaim viis proovida erasure coding’ut on käivitada minio.

DRAID — see on hetkel veel väljaandmata ZFS funktsioon. Erinevalt RAIDZ-st, DRAID-l on jaotatud pariteediblock ja taastamise ajal kaasab see kohe kõik massiivi kettad, mis talub paremini kettaidõrkeid ja taastub kiiremini pärast tõrke tekkimist.

Käes on server Fujitsu Primergy RX300 S7 Intel Xeon CPU E5-2650L 0 @ 1.80GHz protsessoriga , üheksa RAM-moodulitSamsung DDR3-1333 8Gb PC3L-10600R ECC registreeritud (M393B1K70DH0-YH9) , ketta riiulSupermicro SuperChassis 847E26-RJBOD1 , ühendatud läbiDual LSI SAS2X36 laiendaja ja 45 ketast Seagate ST6000NM0115-1YZ110 igaüks 6TB igaühe. Enne kui midagi otsustame, peame kõik korralikult testima.

Selleks olen valmistunud ja viinud läbi erinevate konfiguratsioonide testimise. Selleks kasutasin minio’t, mis toimis S3-tagasiühenduse jaoks ja käivitati erinevates režiimides erineva arvu sihtidega.

Peamiselt testiti minio juhtumit erasure coding vs tarkvara RAID sama ketaste ja pariteedi ketaste arvu puhul, nimelt: RAID6, RAIDZ2 ja DRAID2.

Teave: kui käivitate minio ühe ainsa sihtmärgiga, töötab minio S3 väravana, andes teie kohaliku failisüsteemi S3-salvestusena. Kui aga käivitate minio mitme sihtmärgiga, aktiveeritakse automaatselt Erasure Coding režiim, mis jaotab andmed teie sihtmärkide vahel, tagades talitlushäirete taluvuse.

Teadmiseks: kui käivitate minio vaid ühe sihtmärgiga, töötab minio S3-läbipääsu režiimis, andes teie kohaliku failisüsteemi S3-hoidina. Kuid juhul, kui käivitate minio mitme sihtmärgiga, aktiveeritakse automaatselt Erasure Coding režiim, mis jaotab andmed teie sihtkohtade vahel, pakkudes talitlushäiret tolerantsust.

Vaikimisi jagab minio sihtkohtadesse 16 ketta rühmadesse, kus igas grupis on 2 pariteeti. See tähendab, et kaks ketast võivad korraga rikki minna ilma andmete kaotamata.

Jõudluse testimiseks kasutasin 16 ketast, igaüks 6TB, ja kirjutasin neile väikeseid objekte, mille suurus oli 1MB, mis täpselt kirjeldas meie tulevast koormust, kuna kõik kaasaegsed varundustööriistad jagavad andmeid mitme megabaidi suuruste plokkideks ja kirjutavad neid nii.

Bänšmarkimiseks kasutati tööriista s3bench, mis käivitati eemalserveris ja saatis miniosse kümneid tuhandeid selliseid objekte sada voogu. Pärast seda üritas ta neid samamoodi tagasi nõuda.

Bänšmarkimise tulemused on esitatud järgmises tabelis:

Näeme, et minio oma erasure coding režiimis töötab kirjutamisel märkimisväärselt halvemini kui minio, mis on loodud tarkvara RAID6, RAIDZ2 ja DRAID2 peal sama konfiguratsiooni raames.

Erakordselt paluti mind testida miniot ext4 vs XFS. Üllatavalt, kuid minu koormuse puhul osutus XFS oluliselt aeglasemaks kui ext4.

Esimeses testierias näitas Mdadm ZFS-i ees ületust, kuid hiljem gmelikov soovis, et ZFS-i jõudlust saaks parandada, seades järgmised valikud:

xattr=sa atime=off recordsize=1M

ja pärast seda paranesid ZFS-i testid oluliselt.

Samuti võib täheldada, et DRAID ei too eriti suurt jõudluse kasu RAIDZ ees, kuid teoorias peaks see olema palju turvalisem.

Viimastes kahes testis püüdsin samuti andmefailid (special) ja ZIL (log) tuua SSD peegeldusele. Kuid andmematerjalide ülekanne ei toonud eriliselt kiiret kirjutamise kasu, kuid ZIL-i eemaldamisel SSDSC2KI128G8 silmusime 100% kasutuse piirides, nii et pean seda testi ebaõnnestunuks. Ma ei välista, et kui mul oleks olnud kiiremaid SSD-d, oleks see minu tulemusi tõsiselt parandanud, kuid kahjuks ei olnud neid mul.

Kokkuvõttes otsustasin jääda DRAIDi kasutamisele ja hoolimata oma beetastaatusest on see meie jaoks kõige kiirem ja tõhusam lahendus andmete salvestamiseks.

Loomisin lihtsa DRAID2 konfiguratsiooni koos kolme grupiga ja kahe jaotatud varu:

# zpool status data
  pool: data
 state: ONLINE
  scan: none requested
config:

    NAME                 STATE     READ WRITE CKSUM
    data                 ONLINE       0     0     0
      draid2:3g:2s-0     ONLINE       0     0     0
        sdy              ONLINE       0     0     0
        sdam             ONLINE       0     0     0
        sdf              ONLINE       0     0     0
        sdau             ONLINE       0     0     0
        sdab             ONLINE       0     0     0
        sdo              ONLINE       0     0     0
        sdw              ONLINE       0     0     0
        sdak             ONLINE       0     0     0
        sdd              ONLINE       0     0     0
        sdas             ONLINE       0     0     0
        sdm              ONLINE       0     0     0
        sdu              ONLINE       0     0     0
        sdai             ONLINE       0     0     0
        sdaq             ONLINE       0     0     0
        sdk              ONLINE       0     0     0
        sds              ONLINE       0     0     0
        sdag             ONLINE       0     0     0
        sdi              ONLINE       0     0     0
        sdq              ONLINE       0     0     0
        sdae             ONLINE       0     0     0
        sdz              ONLINE       0     0     0
        sdan             ONLINE       0     0     0
        sdg              ONLINE       0     0     0
        sdac             ONLINE       0     0     0
        sdx              ONLINE       0     0     0
        sdal             ONLINE       0     0     0
        sde              ONLINE       0     0     0
        sdat             ONLINE       0     0     0
        sdaa             ONLINE       0     0     0
        sdn              ONLINE       0     0     0
        sdv              ONLINE       0     0     0
        sdaj             ONLINE       0     0     0
        sdc              ONLINE       0     0     0
        sdar             ONLINE       0     0     0
        sdl              ONLINE       0     0     0
        sdt              ONLINE       0     0     0
        sdah             ONLINE       0     0     0
        sdap             ONLINE       0     0     0
        sdj              ONLINE       0     0     0
        sdr              ONLINE       0     0     0
        sdaf             ONLINE       0     0     0
        sdao             ONLINE       0     0     0
        sdh              ONLINE       0     0     0
        sdp              ONLINE       0     0     0
        sdad             ONLINE       0     0     0
    spares
      s0-draid2:3g:2s-0  AVAIL   
      s1-draid2:3g:2s-0  AVAIL   

errors: No known data errors

Nii, nüüd oleme salvestamisega hakkama saanud, räägime, millega me varundame. Siin tahaks kohe rääkida kolmest lahendusest, mida mul oli võimalus proovida, nimelt:

Benji Backup — fork Backy2, spetsialiseeritud lahendus plokkseadmestike varundamiseks, omab tihedat integratsiooni Cephiga. Suudab võtta vahepealsed muudatused snapshot'ide vahel ja vormida neist inkrementaalse varukoopia. Toetab suurt hulka salvestusbackend'e, sealhulgas nii kohalikke kui ka S3 lahendusi. Nõuab deduplikeerimise häshtabeli salvestamiseks eraldi andmebaasi. Miinustest: on kirjutatud Pythonis ja tal on veidi mitte-reaktiivne CLI.

Borg Backup — fork Attic, pikka aega tuntud ja tõestatud lahendus varundamiseks, suudab andmeid varundada ja hästi deduplikerida. Suudab salvestada varukoopiad nii kohalikult kui ka kaugserverisse läbi SCP. Suudab varundada plokkseadmeid, kui käivitada lippudega --special, miinustest: varukoopia loomisel blokeerib repository täielikult, seetõttu on soovitatav iga virtuaalmasina jaoks luua eraldi repository, see pole aga probleem, kuna need on väga kergesti loodud.

Restic — aktiivselt arenev projekt, kirjutatud Go-s, piisavalt kiire ja toetab suurt hulka salvestusbackend'e, sealhulgas nii kohalikke salvestusi kui ka SCP, S3 ja palju muud. Eriti väärib mainimist, et on loodud rest-server restic'i jaoks, mis võimaldab kõige kiiremini eksportida salvestust kaugkasutamiseks. Kõigist ülalkirjeldatutest meeldis see mulle kõige rohkem. Suudab varundada stdin'ist. Märkimisväärseid miinuseid peaaegu ei ole, kuid on mitmeid eripärasid:

• Esiteks proovisin seda kasutada üldise repository režiimis kõigi virtuaalmasinate jaoks (nagu Benji) ja see töötas isegi hästi, kuid taastamisprotsessid võtsid üsna kaua aega, kuna iga kord enne taastamist proovib restic lugeda kõigi varukoopiate metaandmeid. See probleem lahendus väga lihtsalt, nagu ka Borgi puhul, luues iga virtuaalmasina jaoks eraldi repository. See lähenemine osutus samuti varukoopiate haldamisel väga efektiivseks. Eraldi repository'd võivad omada eraldi parooli andmetele juurdepääsuks, samuti ei pea me kartma, et globaalne repository võiks kuidagi puruneda. Uute repository'de loomine on samuti sama lihtne kui Borg Backupis.

  Igal juhul toimub deduplikeerimine ainult varasema versiooni varunduse suhtes, eelmine varukoopia määratakse antud varunduse jaoks path'i põhjal, nii et kui varundate erinevaid objekte stdin'ist ühisse repositoriumisse, ärge unustage näidata valikut --stdin-filename, või öelda valikut igal korral selgelt --parent.

• Teiseks, taastamine stdout'i on oluliselt aeglasem kui taastamine failisüsteemi oma paralleelsuse tõttu. Tulevikus on plaanis lisada tihedam tugi plokkseadmestiku varukoopiatele.

• Kolmandaks, hetkel soovitatakse kasutada master'i versiooni, kuna versioon 0.9.6-l on tõrge suurte failide pika taastamise osas.

Varukoopia efektiivsuse ja kirje / taastamise kiirusest testimiseks lõin eraldi repositoriumi ja proovisin varundada väikest virtuaalse masina pilti (21 GB). Tehti kaks varundust ilma originaali muutmata, kasutades iga loetletud lahenduse käigus, et uurida, kui palju kiiremini / aeglasemalt deduplikeeritud andmed kopeeritakse.

Kuidas näeme, Borg Backup'il on parim algse varukoopia efektiivsuse koefitsient, kuid see kaotab nii kirje kui ka taastamise kiirusel.

Restic osutus kiiremaks kui Benji Backup, kuid taastab stdout'i aeglasemalt, ja kirjutada otse plokkseadmestikku, kahjuks, ta ei oska veel.

Kaaludes kõiki plusse ja miinuseid, otsustasin jääda restic jot rest-server nagu kõige mugavam ja perspektiivikam lahendus varukoopiaks.

Selles screencastis võite näha, kuidas 10-gigabitine kanal on täielikult kasutuses mitme samaaegselt käivitatud varukoopia operatsiooni ajal. Tasub märkida, et kettaruumi kasutus ei tõuse üle 30%.

Saadud lahendusega olen rohkem kui rahul!

Allikas: habr.com