Linuxi failisüsteemide õrn varundamine. Kuidas luua kolm terabyte MySQL andmebaasi varukoopiaid 20 sekundi jooksul

Minu nimi on Jüri, olen süsteemiadministreerimise grupi juht SitiMobilis. Täna jagan oma kogemusi Linuxi failisüsteemide õhukese varustamise (thin provisioning) tehnoloogia kasutamisest ning räägin, kuidas seda rakendada ettevõtte tehnoloogilistes CI/CD-protsessides. Arutame olukorda, kus automaatse koodi testimise tarbeks vajame tootmisse toimetamisel nii kiiresti kui võimalik MySQL andmebaasi koopiaid, mis on maksimaalselt lähedased "tootmis" versioonile ja on lugemis- ja kirjutamisvõimelised.

Sissejuhatus: miks anda halbu nõuandeid?

Mõistlik küsimus, kuna on olemas välja töötatud andmebaaside skeemide migreerimise mehhanismid testimiskeskkondadesse. Miks raisata keskset mittešarditud andmebaasi sellistele mahtudele? Ja testimiseks ei ole kõik andmed vajalikud. Püüan selgitada.

Umbes aasta tagasi, meie taksikogujate aktiivse kasvu taustal (2018. aastal kasvasime lõpetatud sõitude osas umbes 15 korda), suurenes andmemaht, serverite koormus ja väljalaske sagedus. Sattusime järgmistesse olukordadesse:

• Peamine MySQL andmebaas suurenes umbes 1000 tabelini, üldmahuga 2,5 TB, ja jätkas kasvamist.
• Ei olnud võimalik kiiresti jaguneda ja andmebaasi laiali panna. Seda ei lubanud vana lähenemine "kirjutan andmebaasi, mida soovin ja kuidas soovin", hulk JOIN-e ja tabelite sise sõltuvusi.
• Ei olnud andmebaasi skeemide migratsioonide mehhanismi testkeskkondadesse.
• Ei olnud automaatset koodi testimist, kui see oli tootmisesse väljatöötamisel.

Viimast probleemi soovisime lahendada võimalikult kiiresti. Olid juba kirjutatud Postmani testid peamise PHP-monoliidi kontrollimiseks, kuid puudus ajakohane andmebaas. Samal ajal ei saanud me öösel koopiat luua, muuta selle peamiseks ja anda öösel katse jaoks: väga suur väljutuste ja muudatuste hulk, sealhulgas andmetes ja andmebaasi skeemis, muudaks stendi juba päeva keskpaiku mittetoimivaks. Ja piirduda väljutustega ainult tööpäeva jooksul oleks olnud ebaefektiivne.

Siiski täideti ülesanne: esimene töökindel stend saime juba kahe nädala pärast. Möödunud aasta jooksul on see läbinud palju muudatusi ja jätkab kasutamist.

Edasi kirjeldan kõiki samme ja meie lahenduse arendamise etappe. Veendute, et see meetod väärtustab oma eksisteerimise õigust.

Mis on "õhuke varundamine"?
See on riist- või tarkvaratehnoloogia (teine nimi — õhukesed mahud), mis võimaldab eraldada rohkem vajalikke ressursse, kui need tegelikult saadaval on. Erakond peab vastama just-enough (nii palju, kui vaja) ja just-in-time (vajaliku aja jooksul) kriteeriumidele. Peamiselt kasutatakse õhukest reserveerimist erinevates andmesalvestussüsteemides, et pakkuda vajalikke kettaruume, mis ületavad tegelikult saadavail olevaid. Tehnoloogiat toetavad erinevad failisüsteemid, näiteks LVM2, ZFS, BTRFS. Seda kasutatakse laialdaselt virtualiseerimis hüperviisorites. Meie jaoks võimaldas õhuke reserveerimine kiiresti luua põhiosast andmetest nii palju koopiaid, kui me vajame (MySQL andmebaasi data-kataloog).

Esimene stend, tehnoloogia Thin LVM

Seda peatükki võib nimetada ka "Kuidas teha maksimaalselt kiireid snapshots suuri andmemahtude jaoks" Thin LVM, vähendades failisüsteemi ja MySQL andmebaasi stabiilsust vastuvõetamatule tasemele."

Kuna oleme juba kasutanud LVM-i operatsioonisüsteemi põhiosade loomisel, otsustasime alustada just sellest. Esmalt vajasime eraldi füüsilist masinat – meie MySQL põhivara koopia, mille peal saaksime nõudmise korral luua koopia sisendi ja tõsta selle kõrvale eraldi MySQL eksemplariks. Testimise ajaks lubasime sellel eksemplaril teha muutvaid operatsioone, ja testide lõppedes eemaldasime 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-kontroller Adapteci RAID-10 puhul

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

• Probleemi püstitamise ajal paigaldasime kõik andmebaasihaldurid RAID-kontrolleritele, seega võib öelda, et see on ajalooliselt selline olnud.
• Tootlikkuse erinevus sünteetilistes failisüsteemi testides ja erinevate operatsioonidega MySQL testides oli minimaalne.

Oleme jaganud RAID-10: kokkupanekuks on loodud üks Volume Group (VG) kogu maht (ligikaudu 6,7 GB halduskuludega) ning loonud olekuosa (Logical Volume, LV) süsteemile suurusega 50 GB. Tavalistes olukordades määrame kogu ülejäänud ruumi MySQL jao jaoks. Kuid meil oli vaja dünaamilist varundamist, seega loodi kõigepealt nn pool, mille sees loodi jao /var/lib/mysql jaoks suurusega 3,5 TB (eeldatavate andmebaaside mahtude põhjal):

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

Formatime jao ext4 formaatides, monteerime selle, salvestame koopia ja saame algse seista. Seejärel loome API, mis peaks looma salvestused, tõstma MySQL andmebaasi eksemplari määratud pordil ja kustutama loodud eksemplari. Kuna kasutatakse ainult süsteemi kutseid, valisime skriptikeeleks tavapärase bash'i ning API sidumiseks HTTP → bash kasutame avatud lähtekoodiga lahendust. goexpose, kirjutatud Go keeles.

Millalgi avaldame oma bash-skripti avatud lähtekoodis, aga praegu kirjeldan lihtsalt põhialgoritmi:

Põhjaliku salvestuse loomine snapmain:

1. Peame põhikopia peatama.
2. Seame blokeering snapshot'i snapmain'i operatsioonidele.
3. Loome uue snapshot'i snapmain.
4. Käivitame MySQL ja eemaldame blokeeringu.

Andmebaasi loomine suvalisel pordil snapmain'ist:

1. Seame blokeeringu konkreetsele andmebaasi eksemplarile (port).
2. Kontrollime, kas peamise snapshot'i loomise blokeering on olemas. Kui see on olemas, siis ootame ja kontrollime uuesti iga 5 sekundi tagant.
3. Kontrollime, kas eksemplaril on vana LV-maht.
   3.1 Kui on, siis peatame MySQL eksemplari kill -9 abil ja eemaldame LV-mahu.
4. Loome snapmain'ist uue eksemplari.
5. Valmistame ja monteerime direktorid selle eksemplari jaoks.
6. Eemaldame slaavi märgid (failid) ja käivitame MySQL eksemplari.
7. Teeme temast master'i.
8. Eemaldame blokeeringu.

Andmebaasi eemaldamine suvalisel pordil:

1. Seame blokeeringu konkreetsele andmebaasi eksemplarile (port).
2. Tapame MySQL eksemplari kill -9 abil.
3. Eemaldame direktorid monteeringust.
4. Kustutame LV-mahu ja lõpetame blokeeringu.

Näidiskäsklused uue andmebaasi eksemplari osade kloonimiseks:

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äägin peamisest probleemist, millega me kokku puutusime õhukese varundamise kasutamisel. Sattusime SSD-diskide jõudluse piirangutesse. See juhtus Thin LVM-i omaduste tõttu: see opereerib madalama taseme seadme tasemel, kasutades vaikimisi 4 MB suuruseid lõike. Kuidas see välja nägi:

1. Loome snapsi peamisest jaotisest /var/lib/mysql.
2. Käivitame replikatsiooni, et jõuda meistrini.
3. Iga muudatus replikatsioonis tabelites sunnib salvestama vanad, muutmata andme lõigud snapsi jaotises.
4. Iga muudatus tõstetud testinstantsis sunnib salvestama vanad, muutmata andme lõigud kloonitud snapsi jaotises selle instantsi jaoks.
5. Saame 100% sisend-väljund operatsioonide koormuse seadmele, aeglustades igasuguseid toiminguid ja põhjustades aeglase replikatsiooni.
6. Tööpäeva lõpuks saame mitme tunni võrra maha jäänud keskkonna.

Kuidas me sellega võitlesime, et saada arvestatavaid tulemusi (peamised punktid):

RAID-kontroller:

• Kuidas me kõik vaikelülituse cache'id välja lülitasime.
• Seadsime writeback'i (kui andmed satuvad vahemällu, lõpetatakse kirjutamine enne, kui tegelik salvestamine kettale toimub).

Failisüsteem:

• Mäntsid jaotuses /var/lib/mysql noatime,nodiratime,data=writeback
• Välja lülitatud ext4 logimine käsuga tune2fs.

MySQL:

• Seadsime innodb_flush_method = O_DSYNC (suurendasime kirjutamise kiirus, vähendades seega usaldusväärsust).
• Lülitasime logimise välja, logid pole meile vajalikud.
• Seadsime innodb_buffer_pool_size = 4G (mida väiksem on InnoDB basaari suurus, seda kiiremini MySQL peatub, ja seda kiiremini saame luua snapshots'i).

See ei ole kaugel täielik nimekiri, eriti MySQL'i osas. Siiski, ülejäänud muudatused on väiksemad ja sageli mitte alati ja mitte täpselt rakendatavad. Näiteks, et vähendada ketaste koormust, viisime isegi innodb_parallel_doublewrite_path /dev/shm, mis mõnes olukorras, kui algatatud eksemplar ei olnud korrektselt lõpetatud, säästis meile kuni 5 sekundit.

Miks me peatame MySQL enne, kui teeme snapshot'i? Me võime selle teha töötava replikaga. See on tõsi, kuid snapshot'i alusel loodud uue andmebaasi eksemplar loetakse vaikimisi rikutuks ja käivitamisel nõuab see täielikku skaneerimist. Replikat peatada on kindlasti kiiremini, kuigi see on lõpuks kogu protsessi jaoks kõige pikem tegevus.

Kokkuvõttes saavutasime vastuvõetavamad ajad ja töövalmis keskkonna. Kuigi nagu näha peamise replikatsiooni viivituse kõige räägib graafik, on olukord veel kaugel ideaalist:

Teistest puudustest tasub märkida, et Thin LVM basseini jälgimine on praktiliselt võimatu: süsteemi standardsete funktsioonide iostat kõrval, on näiteks raske mõista, milline basseini komponent hetkel kasutab failisüsteemile kõige rohkem ressursse.

Üks suur puudus, mis on seotud eespool kirjeldatud optimeerimisega, väärib eraldi mainimist: me saime YOLO-seisundi. Umbes kord kuus või kahe kuu jooksul ei pidanud ext4 selliseid rünnakuid vastu ja purunes pöördumatult, nõudes ümbervormingut ja varukoopia taastamist. Kiirusest võitnud, hävitasime me lootusetult stabiilsuse.

Milliseid mõõdikuid jälgida Thin LVM-i kasutamisel:

• Õhuke mahuti andmete %
• Õhuke mahuti metaandmete %

Kui meie seisund suudab läbi elada andmete lõpuni jõudmise (piisab lihtsalt ketaste puhastamisest), siis metaandmete lõpuni jõudmine toob kaasa kogu mahuti kokku kukkumise ja selle nullist uuesti loomise vajaduse.

Failisüsteem mahutis fragmenteerub aja jooksul väga tugevalt. Soovitan igapäevaselt käivitada croniga käsku fstrim -v /var/lib/mysql.

Vahekokkuvõtted:

• Tehnoloogiat on lihtne rakendada, samuti ka LVM-i, ning see ei nõua insenerilt erilisi oskusi.
• See sobib hästi väikese ja mitte liiga koormatud andmebaasi jaoks. Mida väiksem on andmebaas, seda vähem osakesi liigub failisüsteemis mahuti sees, ja seda madalam on koormus kettale.
• Meie eesmärgiks oli leida teisi lahendusi, millest juttu tuleb järgmises jaos.

Teine keskkond, tehnoloogia ZFS

Aegade alguses olen tegelenud failisüsteemiga ZFS, kuid toona toimis ZFS tõeliselt hästi oma põhis operatsioonisüsteemidel Solaris. Postitamine FreeBSD-le oli piisavalt hea tasemega. Samuti oli olemas pooleliolev Linuxi port, mida kasutas vähe inimesi. Andmestruktuuri tõttu B-tree (ühtlasi selline struktuur nagu InnoDB MySQL-l) ei näidanud ZFS väga häid tulemusi installatsioonides, kus oli väga suur hulk faile. Kõik see koos vajadusega õppida tehnikat enne kasutamist tõrjus selle failisüsteemi pikaajaliselt minu praktikast välja. Ilmusid ext4 ja xfs, mis said standardiks. Arvestades, et ZFS sobib meie ülesande jaoks enam kui hästi, ja ka Linuxi versioon, lähtudes tagasisidest, on kasvanud täiesti arvestatavaks tooteks (kuigi mitte täieliku toe all, mistõttu süsteemi täielik paigaldamine ZFS-ile on võimalik ainult erinevate trikidega), otsustasime selle proovida.

Selge põhjusel valiti sarnase konfiguratsiooniga stend (välja arvatud RAID-kontroller). Paigaldasime kaheksa SSD-d 1920 Gb mahuga. Ei olnud soov kirjutada oma võrgupilti serveri paigaldamiseks puhtale ZFS-ile, seega võtsime igast kettast 50 Gb ja tegime neist MD RAID-10 süsteemi jaoks. Ülejäänud 1950 Gb igas kettas liideti ZFS analooge RAID-10:

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

Loomisel on osad MySQL 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 sisse lülitanud tavalise gzip andmete kokkusurumise. Meie serveris on palju protsessorivõimsust ja need ei ole täielikult kasutatud. Tulemuseks on 3 Tb meie andmebaasist muutusid 1,6 Tb-ks, ja kuna nõrk koht, nagu eelmisel korral, on diskide maksimaalne jõudlus, siis mida vähem andmeid, seda parem — me saame ZFS-ist algusest peale suurepärase boonuse! Tipptunnil, täielikul koormusel võib gzip toimimine nõuda kuni 4 tuuma, aga me ei kahetse.

Edasi läks rakendamine kiiremini. MySQL replika sätete kopeerimiseks viidi need LVM-stendilt. Kulutasime veidi aega skriptide ümberkirjutamiseks ZFS käskudeks, kuid üldiselt jäid algoritmid samaks. Näide snapshot’i loomise kohta:

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

Täiendavaks säätmiseks: viidi ZFS-osad koos metainformatsiooni ja logidega mällu l2arc ja zil. Meie ülesande jaoks, nagu hiljem selgus, osutus see üleliigseks, kuid oleme seni jätnud selle optimeerimise, vajadusel on lihtne muuta. Negatiivsete mõjude seas — pärast serveri taaskäimist tuleb vastavad mälualad uuesti luua. Andmed ei kao. Zpooli staatuse väljavõte:

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

Sellise konfiguratsiooniga hakkasime testima stendi ja saime suurepäraseid tulemusi: kahel korraga töötaval andmebaasi eksemplaril (ja aktiivse peamise replikaga) snapshot’idel nägime ketaste koormust 50-60%.

Me oleme lahti saanud oma peamisest probleemist, mis kajastub replikatsiooni viivituse graafikus (võrrelge varasema graafikuga Thin LVM jaotises):

Sellest hoolimata ja tänu sellele oleme kõigis tegevustes märgatavalt kiiruselt paranenud: täielik snapshot'i loomine koos replika peatamise ja taaskäivitamisega võtab kuni 40 sekundit, snapshot'ist uue MySQL instantsi juurutamine võtab kuni 20 sekundit. See on rohkem kui rahuldav nii meie kui ka meie tarkvaratesti jaoks.

Vahekokkuvõtted:

• Tulemused rahuldasid täielikult meie vajadust saada testimiskoodiks tööandmebaasi koopia.
• Tehnoloogia nõuab sisenemist: tuleb aru saada, mis on ZFS ja kuidas sellega töötada.
• Me ei ole kontrollinud ZFS praegust olekut suurte (üle 1 miljoni) väikese faili korral. Kuid arvame, et probleem püsib, seetõttu ei soovitaks ma seda failisüsteemi mingiteks failide salvestamiseks.

Mis edasi?

Stendi kontekstis ei ole me enam midagi muutnud, tulemus on meid rahuldanud. Tulevikus võib-olla lisame stendi replikatsiooni seadistusse tabelite erandeid, mis ei ole testimiseks vajalikud, mis veelgi vähendaks andmebaasi mahtu. Me ei ole testinud BTRFS süsteemi ning selle rakendust õhukese varundamise tehnoloogias. Siiski, see ülesanne ei seisa enam, kuna peamine eesmärk on saavutatud. Üldiselt on loomulikult soov kaugemale liikuda eelkirjeldatud lähenemisest — ellu viia töötavad andmebaasi migratsioonid testkeskkonda, luua eraldi testimise andmebaasi kontuur, tegeleda põhivaba jagamisega. Paljusid neist me juba ellu viime, millest räägime kindlasti tulevastes artiklites.

Kokkuvõte

Algne ülesanne on lahendatud, kuigi ebatavalisel viisil. Vahekokkuvõtetes on kirjeldatud iga rakendatud tehnoloogia eeliseid ja puudusi, seega otsustame, millist tehnikat ja millal on mõistlik kasutada:

• Õhuke LVM — väikeste andmebaaside puhul ja kui ei soovi või ei ole aega ZFS-i uurimiseks.
• ZFS — kui on kogemus selle kasutamisest või võimalus kulutada aega selle õppimisele igas olukorras.

Kõrgemal tasandil ei ole see artikkel mitte ainult kahe failisüsteemi tehnoloogia võrdlus. Peamine idee, mille ma tahan edastada ja kinnistada, on see, et ei ole mõtet karta ebatraditsiooniliselt mõelda äri kriitilistes olukordades ja võtta kasutusele ainult valmis retseptid. Kunagi võisime kogu tehnilise osakonna jõududega pead raputada ja öelda, et kolme terabaidi andmebaasi koopia loomine vähem kui minutiga on võimatu ning me ei vaja riskantseid tehnoloogiaid, teeme nagu peab. See oli võimalik, kuid oleksime kaotanud umbes kuus kuud kuni aasta ning palju kliendireise (reisid on meie peamine äritulemus) ilma katseteta ja rakendamise ajal. Erakordset lähenemist kasutades ei kulutanud me rakendamiseks nii palju aega, saime kogemusi uute ja unustatud vanade tehnoloogiate osas ning pakkusime testimist just siis, kui me seda tõeliselt vajasime. Kahtlemata avaldas see meie näitajatele positiivset mõju. Valik on alati teie, ja meie jätkame oma blogis huvitavate praeguste ja tulevaste saavutuste jagamist.

Allikas: habr.com