Õhuke Linuxi failisüsteemide varundamine. Kuidas luua kolme terabaidi suuruste MySQL andmebaaside töökoopiaid 20 sekundi jooksul

Minu nimi on Yuriy, ma olen süsteemiadministratsiooni meeskonna juht ettevõttes Sitimobil. Täna jagan oma kogemusi Linuxi failisüsteemide õhukese varundamise (thin provisioning) tehnoloogia kasutamisest ning räägin, kuidas seda saab rakendada ettevõtte CI/CD-protsessides. Vaatleme olukorda, kus meil on vaja koodide automaatseks testimiseks, kui sisu jõuab tootmisse, võimalikult kiiresti MySQL andmebaasi koopiaid, mis oleksid võimalikult lähedased „tootmisversioonile”, saadaval lugemiseks ja kirjutamiseks.

Sissejuhatus: miks anda vale nõu?

Loogiline küsimus, kuna olemas on tõestatud andmebaasi skeemide migratsioonimehhanismid testkeskkondadesse. Miks viia peamine mitte-sharditud andmebaas selliste mahudeni? Ja testimiseks ei ole kõik andmed vajalikud. Püüan seletada.

Umbes aasta tagasi, meie taksikogujaga (2018. aastal kasvasime lõpetatud sõitude osas umbes 15 korda) aktiivse kasvu taustal, kasvasid andmemahud, serverite koormus ja väljalaskete sagedus. Me jäime järgmisesse olukorda:

• Peamine MySQL andmebaas suurenes umbes 1000 tabelini, mille kogumaht oli 2,5 TB, ja jätkas kasvu.
• Ei olnud võimalik kiiresti shardida ja andmebaasi laiali viia. Vanade lähenemiste korral „kirjutan andmebaasi, mida tahan ja kuidas tahan”, hulk JOIN-e ja sisemisi tabelite sõltuvusi, ei võimaldanud seda.
• Ei olnud mehhanismi andmebaasi skeemi migratsioonideks testkeskkondadesse.
• Ei olnud automaatset koodi testimist tootmisse laskmisel.

Viimast probleemi sooviti lahendada võimalikult kiiresti. Postmani jaoks oli juba kirjutatud testid põhifilosoofia monoliidi kontrollimiseks, kuid puudus ajakohane andmebaas. Samuti ei saanud me öösel replikat luua, teha sellest meistriks ja anda seda päeva jooksul hävitamiseks: väga suur hulk väljalaskmisi ja muudatusi, sealhulgas andmetes ja andmebaasi skeemis, oleks teinud stendi juba päeva keskpaigaks mittetöötavaks. Ja väljalaskmiste piiramisega ainult tööpäevadel ei oleks olnud efektiivne.

Sellegipoolest ülesanne täideti: esimene töötav stend saadi juba kahe nädala jooksul. Selle möödunud aasta jooksul on see läbinud palju muudatusi ja jätkab kasutamist.

Edasi kirjeldan ma põhjalikult kõik etapid ja sammud meie lahenduse arengus. Te veendute, et see meetod väärib eksisteerimist.

Mis on „õhuke reserveerimine“?
See on riist- või tarkvaratehnoloogia (tuntud ka kui sparse volumes), mis võimaldab eraldada rohkem vajalikke ressursse, kui tegelikult on saadaval. Eraldatav maht peab siiski vastama just-enough (nii palju kui vajalik) ja just-in-time (vajaliku ajaga) kriteeriumidele. Peamiselt rakendatakse õhket reserveerimist erinevates andmesalvestussüsteemides, et pakkuda ketaspinda vajalikus mahus, mis ületab tegelikult kättesaadavad. Tehnoloogiat toetavad erinevad failisüsteemid, nagu LVM2, ZFS, BTRFS. Seda kasutatakse laialdaselt virtualiseerimise hüperviisorites. Õhuke reserveerimine võimaldas meil kiiresti luua põhikettast andmete lõikes nii palju koopiaid, kui meil oli vaja (MySQL andmebaasi data-kaust).

Esimene stand, õhukese LVM tehnoloogia

Seda peatükki võib nimetada ka „Kuidas teha võimalikult kiireid snapshots suurtest andmemahtudest kasutades õhukest LVM, vähendades failisüsteemi ja MySQL andmebaasi stabiilsust lubamatule tasemele.“

Kuna olime juba kasutanud LVM-i operatsioonisüsteemi põhiosade ehitamiseks, otsustasime alustada just sellest. Esiteks vajasime eraldi füüsilist masinat – meie MySQL põhialuse koopiat, millel saaksime nõudmisel luua koopiana snapshots ja tõsta see üles eraldi MySQL eksemplariga. Testimise ajaks lubasime sellel eksemplaril kasutada muudetavaid operatsioone ja testide lõppedes kustutasime selle edukalt. Serveri konfiguratsioon oli järgmine:

• 2 x Intel Silver 4114 (10×2,2 GHz HT)
• 8 x 32 GB DDR4
• 8 x 1920 GB Intel SSD RAID-kontrolleris Adaptec RAID-10

RAID-kontrolleri ja tarkvara RAID MD valimise teemal võiks kirjutada eraldi artikli. Ütlen vaid, et meie valikusse mõjutasid kaks tegurit:

• Kuna ülesande seadmisel installisime kõik andmebaasid RAID-kontrolleritele, võib öelda, et see kujunes ajalooliselt nii.
• Erinevus jõudluses failisüsteemi sünteetilistes testides ja erinevates MySQL operatsioonide testides oli minimaalne.

Me jagasime saadud RAID-10: tegime ühe Volume Group (VG) kogu ruumi peale (ligikaudu 6,7 GB ülekande kuludega) ja lõime loogilise partitsiooni (Logical Volume, LV) süsteemi jaoks 50 GB. Tavalistes oludes määraksime kogu ülejäänud ruumi MySQL partitsiooniks. Kuid meil oli vaja peenvaru, seega lõime esmalt nn pooli, mille sees lõime partitsiooni /var/lib/mysql jaoks 3,5 TB (baseerudes prognoositavatel andmebaasi mahtudel):

lvcreate -l 100%FREE -T vga/thin
lvcreate -V 3.5T -T vga/thin -n mysql

Formateerisime partitsiooni ext4-formaadis, mountisime selle, kirjutasime koopia ja saime algse seista. Siis tegime API, mis peaks looma snapshots, tõstma MySQL andmebaasi koopia määratud pordil ja kustutama loodud koopia. Kuna kasutatakse ainult süsteemi kutseid, valisime skriptide kirjutamise keeleks tavalise bash'i ja API sidumiseks HTTP → bash rakendasime open source lahenduse. goexpose, kirjutatud Go-s.

Kord me avaldame meie bash-skriptid open source'ina, kuid praegu kirjeldan lihtsalt põhilist algoritmi:

Põhi snapshot'i loomine snapmain:

1. Peamine koopia peatatakse.
2. Seame lukustuse snapshot'i snapmain operatsioonide jaoks.
3. Loome uue snapshot'i snapmain.
4. Käivitame MySQL ja eemaldame lukustuse.

Andmebaasi loomine suvalisel pordil snapmain'ist:

1. Seame lukustuse konkreetsele andmebaasi koopia (port).
2. Kontrollime, kas põhikoopia snapshot'i loomisel on lukustus. Kui see on olemas, ootame ja kontrollime iga 5 sekundi järel.
3. Kontrollime, kas on olemas vana LV-partitsioon koopia.
   3.1 Kui see on olemas, peatame MySQL koopia kill -9 abil ja kustutame LV-partitsiooni.
4. Loome snapmain'ist uue koopia.
5. Valmistame ja mountime direktorid selle koopia jaoks.
6. Eemaldame slave'i tunnused (failid) ja käivitame MySQL koopia.
7. Teeme sellest meistri.
8. Eemaldame lukustuse.

Andmebaasi kustutamine suvalisel pordil:

1. Seame lukustuse konkreetsele andmebaasi koopia (port).
2. Tapan MySQL koopia kill -9 abil.
3. Unmountime direktorid.
4. Kustutame LV-partitsiooni ja eemaldame lukustuse.

Näited uue andmebaasi koopia partitsioonide kloonimise käskudest:

lvcreate -n stage_3307 -s vga/snapmain
lvchange -ay -K vga/stage_3307
mount -o noatime,nodiratime,data=writeback /dev/mapper/vga-stage_3307 /mnt/stage_3307

Nüüd räägime põhiprobleemist, millega me kokku puutusime õhukese varundamise kasutamisel. Me pidime silmitsi seisma SSD-kettaste tulemuslikkusega. See juhtus Thin LVM eripärade tõttu: see töötab põhimõtteliselt madala taseme seadme plokkidega, mille vaikimisi suurus on 4 MB. Kuidas see välja nägi:

1. Loome snapshots põhiosast /var/lib/mysql.
2. Käivitame replikatsiooni, et jõuda meistriga samasse punktisse.
3. Igasugune muudatus replikatsiooni tabelites sunnib salvestama vanad, muutmata andmeplokid snapshot'i osas.
4. Igasugune muudatus üles tõstetud testieksemplaris sunnib salvestama vanad, muutmata andmeplokid selle eksemplari kloonitud snapshot'i osas.
5. Saame 100% sisend-väljund operatsioonide koormuse seadmel, aeglustades igasuguseid toiminguid ja viies replikatsiooni järk-järgult tagasi.
6. Tööpäeva lõpuks saame mitme tunni võrra maha jäänud keskkonna.

Kuidas me sellega võitlesime, et saada mõistlikum tulemus (peamised punktid):

RAID-kontroller:

• Lülitasime välja kõik vahemälu tüübid vaikimisi.
• Seadsime writeback (andmete jõudmine vahemällu lõpetab kirjutamise enne, kui tegelik salvestamine kettale toimub).

Failisüsteem:

• Mountimispunktis /var/lib/mysql määrasime noatime,nodiratime,data=writeback
• Lülitasime välja ext4 logimise tune2fs'i abil.

MySQL:

• Määrasime innodb_flush_method = O_DSYNC (suurendasime kirjutamiskiirust, vähendades seeläbi usaldusväärsust).
• Lülitasime välja logimise, logid pole meile vajalikud.
• Määrasime innodb_buffer_pool_size = 4G (mida väiksem on InnoDB puu suurus, seda kiiremini MySQL peatub, ja seda kiiremini saame snapshot'i luua).

See ei ole kaugeltki täielik nimekiri, eriti MySQL-i osas. Kuid ülejäänud muutused on vähem tähtsad ja sageli ei ole need alati ja täpselt rakendatavad. Näiteks, et kettaid koormust vähendada, viisime isegi innodb_parallel_doublewrite_path kausta /dev/shm, mis säästis mõnes olukorras kuni 5 sekundit vale lõpetamise järgselt.

Miks me peatame MySQL enne snapshot'i loomist? Me võime selle teha töötava replikatsiooni pealt. Jah, see on õige, kuid uus andmebaasi eksemplar selle snapshot'i pealt loetakse vaikimisi rikutuks ja vajab käivitamisel täielikku skaneerimist. Replikatsiooni peatamine on kindlasti kiirem, ehkki see osutub kogu protsessi jooksul kõige kestvAMAKS toiminguks.

Tulemuseks saime sobivamad ajad ja töökorras oleva kõrvuti. Kuigi nagu nähtub peamisest replikatsioonist rääkivast kõige veenvamast graafikust, on olukord ikka veel kaugel ideaalist:

Teistest puudustest tasub märkida peaaegu võimatut Thin LVM-i aluse jälgimist: peale süsteemi standardsete iostat funktsioonide pole võimalik määrata, näiteks, milline aluse element hetkel esitab suurimat koormust failisüsteemile.

Eraldi tasub märkida ühte suurt puudust, mis on seotud eespool kirja pandud optimeerimisega: saime YOLO-keskkonna. Umbes kord kuus või kahe kuu jooksul ext4 ei pidanud selliseid ülekohut taluma ja purunes pöördumatult, nõudes ümberformaatimist ja replikatsiooni uuesti. Kiirusest võitnud, hävitasime lootusetult stabiilsuse.

Milliste mõõdikute järgi jälgida Thin LVM-i kasutamise ajal:

• Thin pool andmete %
• Thin pool metaandmete %

Kui meie keskkond suudab andmete lõppemise över elada (piisab ketaste puhastamisest), siis metaandmete lõppemine toob kaasa kogu aluse kokkuvarisemise ja vajaduse see nullist uuesti luua.

Failisüsteem all pool aja jooksul väga palju fragmenteerub. Soovitame igal päeval käivitada krooniga käsu fstrim -v /var/lib/mysql.

Vahekokkuvõtted:

• Tehnoloogia rakendamine on lihtne, nagu ka LVM ise, ning ei nõua insenerilt erilisi oskusi.
• See sobib hästi väikeste andmebaaside ja mitte liiga koormatud süsteemide jaoks. Mida väiksem on andmebaas, seda vähem tükke liigub failisüsteemis all pool ja seda madalam on koormus ketastele.
• Meie ülesande jaoks hakkasime otsima teisi lahendusi, millest juttu tuleb järgmises jaotises.

Teine keskkond, tehnoloogia ZFS

Kaua aega tagasi olin ma kokku puutunud ZFS-failisüsteemiga, kuid siis töötas ZFS oma koduoperatsioonisüsteemis Solaris tõeliselt hästi. Eksisteeris FreeBSD-le portitud versioon, millel oli piisavalt hea rakendamine. Samuti oli olemas poolik port Linuxile, mida vähesed kasutasid. Andmete salvestamise struktuuri tõttu B-tree (tõsi, sama salvestamisstruktuur on ka InnoDB MySQL-is) ei näidanud ZFS end väga hästi installatsioonides, kus oli tohutult faile. Kõik see koos vajadusega enne kasutamist materjal tundma õppida oli põhjus, miks see failisüsteem pikka aega minu praktikas kõrvale jäi. Ilmnesid ext4 ja xfs, mis muutusid standardiks. Kuid arvestades, et ZFS sobib meie ülesande jaoks rohkem kui hästi ja Linuxi versioon, nagu tagasisidet arvestades, on muutunud täiesti korralikuks tooteks (kuigi mitte täis toetusega, mistõttu ZFS-ile süsteemi paigaldamine algusest peale on võimalik vaid erinevate trikkide abil), otsustasime seda proovida.

Mõistetavatel põhjustel valisime sarnase konfiguratsiooni (välja arvatud RAID-kontroller). Paigaldasime kaheksa 1920 GB SSD-d. Ei olnud soovi kirjutada oma võrgu pilti, et installida server tühjale ZFS-ile, seetõttu võtsime igast kettast 50 GB ja tegime nendele MD RAID-10 süsteemi jaoks. Ülejäänud 1950 GB igal kettal ühendasime ZFS analoog RAID-10-ga:

zpool create zpool mirror /dev/sda2 /dev/sdb2 mirror /dev/sdc2 /dev/sdd2 mirror /dev/sde2 /dev/sdf2 mirror /dev/sdg2 /dev/sdh2

Loomise jaoks lõime osad MySQL-i jaoks:

zfs create zpool/mysql
zfs set compression=gzip zpool/mysql
zfs set recordsize=128k zpool/mysql
zfs set atime=off zpool/mysql
zfs create zpool/mysql/data
zfs set recordsize=16k zpool/mysql/data
zfs set primarycache=metadata zpool/mysql/data
zfs set mountpoint=/var/lib/mysql zpool/mysql/data

Pange tähele, et oleme lülitanud sisse vaikimisi gzip-andmete kokkusurumise. Meil on serveris palju protsessorivõimsust ja see ei ole täielikult kasutusel. Tulemuseks on see, et 3 TB meie andmebaasist muutus 1,6 TB-ks ja kuna nõrk lüli, nagu eelmisel korral, on maksimaalne ketta tootlikkus, siis mida vähem andmeid, seda parem. Saame alguses ZFS-ilt suurepärase boonuse! Tipptunnil full-loadi ajal kulub gzip’i töötluseks kuni 4 tuuma, kuid meil ei ole seda kahju.

Edasi liikudes läks rakendamine kiiremini. Kopeerisime LVM-seisundist MySQL repliiki seaded. Pidi kulutama aega skriptide ümberkirjutamiseks ZFS-i käskudeks, kuid üldiselt jäid algoritmid endiseks. Näide jäädvustamise loomisest:

zfs set snapdir=visible zpool/mysql/data
zfs create zpool/stage_3307
zfs clone zpool/mysql/data@snapmain zpool/stage_3307/data
zfs set mountpoint=/mnt/stage_3307 zpool/stage_3307/data

Lisaks täiendavalt häälestamisest: tõstsime mällu ZFS-i jaotised, kus on metaandmed ja logid l2arc ja zil. Meie ülesande jaoks osutus see hiljem liigseks, kuid seni oleme selle optimeeringu säilitanud, seda on lihtne hiljem muuta. Negatiivsete mõjude seas on see, et pärast serveri taaskäivitamist tuleb vastavad mälu piirkonnad uuesti luua. Andmeid seejuures ei kaotata. Väljavõte zpool status:

logs
      /dev/shm/zil_slog.img  ONLINE       0     0     0
cache
      /dev/shm/l2arc.img     ONLINE       0     0     0

Sellises konfiguratsioonis hakkasime testima seadet ja saime suurepäraseid tulemusi: kahe samal ajal töötava andmebaasi eksemplari (ja aktiivse peamise replikaga) snäpšottide peal saavutasime diskide koormuse 50-60%.

Oleme vabanenud oma peamisest probleemist, mida on näha replikatsiooni viivituse graafikult (võrrelge eelmise graafikuga jaotises Thin LVM):

Lisaks ja tänu sellele kiirenesime kõigis operatsioonides: täielik snäpšoti loomine replika peatamise ja käivitamisega kestab kuni 40 sekundit, snäpšotist uue MySQL eksemplari käivitamine kestab kuni 20 sekundit. See rahuldab rohkem kui meid ning meie tarkvarakoodi testid.

Vahekokkuvõtted:

• Tulemused rahuldasid täielikult meie vajadust saada koopia tootmisandmebaasist koodi testimiseks.
• Tehnoloogia nõuab sissejuhatust: tuleb mõista, mis on ZFS ja kuidas sellega töötada.
• Me ei ole kontrollinud ZFS-i praegust tööolekut suure arvu (üle 1 miljoni) väikese faili korral. Kuid eeldame, et probleem püsib, seega ei soovitaks ma seda failisüsteemi mingiks failide hoidmiseks.

Mis edasi?

Standi raames ei teinud me rohkem midagi, tulemus meid rahuldab. Tulevikus võime lisada replikatsiooni seadmestikku tabelite erandeid, mis ei ole testimiseks vajalikud, see vähendaks veelgi andmebaasi mahtu. Me ei ole testinud BTRFS süsteemi ja selle rakendust õhukeste varundamisvõtete tehnoloogiale. Kuid sellist eesmärki ei ole enam, kuna põhieesmärk on saavutatud. Üldiselt tahaksime loomulikult sellel eelnevalt kirjeldatud lähenemisviisilt loobuda — teostada tööalised andmebaasi migratsioonid testkeskkonda, luua eraldi testkontuur andmebaasile, tegeleda peamise andmebaasi shardimisega. Paljusid neist me juba ellu viime, millest kindlasti räägime tulevastes artiklites.

Summary

Algne ülesanne oli lahendatud, kuigi ebatavalisel viisil. Vaheanalüüsides on kirjeldatud iga rakendatud tehnoloogia plusse ja miinuseid, seega otsustame, millist tehnoloogiat ja millal kasutada:

• Thin LVM — väikeste andmebaaside puhul ja kui ei soovi või ei ole aega ZFS-i uurimiseks.
• ZFS — kui on kogemusi selle kasutamisel või võimalust kulutada aega uurimisele igas olukorras.

Kohandatud tasemel on see artikkel — mitte lihtsalt kahe failisüsteemi tehnoloogia võrdlemine. Peamine idee, mida soovin edastada ja kinnitada, on see, et ei tohiks karta mõelda ebatraditsiooniliselt olukordades, mis on kriitilised äri jaoks, ja võtta ainult valmis retsepte. Kunagi võisime kogu tehnilise osakonnaga pead raputada ja öelda, et kolm terabaiti andmebaasi koopia loomine vähem kui minutiga on teostamatu ning me ei vaja riskantseid tehnoloogiaid, teeme, nagu peab. See oleks olnud võimalik, kuid oleksime kaotanud umbes kuus kuud- aasta ja palju kliendireise (reisid on meie peamine äritulemus) ilma testideta ja rakendamise ajal. Ebatraditsiooniliselt tegutsedes kaotasime rakendamisele mitte nii palju aega, saime kogemusi uute ja unustatud vanade tehnoloogiate kohta ning pakkusime testimise just siis, kui me seda väga vajasime. Ilmselgelt avaldas see positiivset mõju kõikidele meie näitajatele. Valik on alati teie, ja meie jätkame oma blogis huvitavate praeguste ja tulevaste saavutuste jagamist.

Allikas: habr.com