🥇Tiedostojärjestelmien ohut provisiointi LinuxKuinka luoda työkopioita kolmen teratavun MySQL-tietokannasta 20 sekunnissa

Nimeni on Yuri, ja olen Citymobilin järjestelmänhallintatiimin johtaja. Tänään jaan kokemuksiani tiedostojärjestelmien ohuen provisiointiteknologian parissa työskentelystä. Linux Selitän, miten sitä voidaan soveltaa yrityksen CI/CD-prosesseissa. Tarkastelemme tilannetta, jossa koodin automaattiseen testaamiseen tuotantoon toimitettaessa tarvitsemme MySQL-tietokannan luku- ja kirjoituskopioita, jotka ovat mahdollisimman lähellä tuotantoversiota.

Johdanto: Miksi antaa huonoja neuvoja?

Looginen kysymys, koska on olemassa todistettuja mekanismeja tietokantaskeemojen siirtämiseen testiympäristöihin. Miksi edes laajentaa pääasiallista sirpaloitumatonta DBMS:ää tällaisiin määriin? Eikä kaikkia tietoja tarvita testaukseen. Yritän selittää.

Noin vuosi sitten taksiaggregaattorimme aktiivisen kasvun taustalla (vuonna 2018 suoritetut matkat kasvoivat noin 15-kertaiseksi) datamäärä, palvelimien kuormitus ja käyttöönottotiheys kasvoivat. Löysimme itsemme seuraavanlaisesta tilanteesta:

MySQL-päätietokanta kasvoi noin 1000 taulukkoon, yhteensä 2,5 TB, ja jatkoi kasvuaan.
Ei ollut mitään keinoa nopeasti murtua ja tuhota tukikohtaa. Tätä ei sallinut vanha lähestymistapa "kirjoitan tietokantaan mitä haluan ja miten haluan", joukko JOINeja ja sisäisiä taulukkoriippuvuuksia.
Ei ollut mekanismia tietokantaskeeman siirtämiseksi testiympäristöihin.
Koodia ei testattu automaattisesti käyttöönoton aikana.

Halusin ratkaista viimeisen ongelman mahdollisimman nopeasti. Postimiestestit oli jo kirjoitettu PHP:n päämonoliitin testaamiseksi, mutta niistä puuttui ajan tasalla oleva tietokanta. Samanaikaisesti emme voineet luoda kopiota yöllä, tehdä siitä isäntänä ja jättää sitä repimään palasiksi päivän aikana: erittäin suuri määrä käyttöönottoja ja muutoksia, mukaan lukien tieto- ja tietokantaskeema, olisi aiheuttanut jalusta ei ole toiminnassa keskellä päivää. Ja käyttöönoton rajoittaminen vain työpäivään olisi tehotonta.

Tehtävä kuitenkin suoritettiin: saimme ensimmäisen työtelineen kahden viikon sisällä. Se on käynyt läpi monia muutoksia kuluneen vuoden aikana ja on edelleen käytössä.

Seuraavaksi kuvailen yksityiskohtaisesti kaikki ratkaisumme vaiheet ja kehitysvaiheet. Tulet huomaamaan, että tämä menetelmä ansaitsee oikeuden olemassaoloon.

Mitä on "ohut redundanssi"?
Tämä on laitteisto- tai ohjelmistotekniikka (toinen nimi on harvat volyymit), jonka avulla voit varata enemmän tarvittavaa resurssia kuin on käytettävissä. Tässä tapauksessa jaetun volyymin on täytettävä kriteerit juuri tarpeeksi (tarvittaessa) ja just-in-time (tarvittavan ajan). Pohjimmiltaan ohutta varausta käytetään erilaisissa tallennusjärjestelmissä levytilan saamiseksi vaadituissa määrissä, jotka ylittävät todellisuudessa käytettävissä olevat volyymit. Teknologiaa tukevat useat tiedostojärjestelmät, esimerkiksi LVM2, ZFS, BTRFS. Sitä käytetään laajalti virtualisoinnin hypervisoreissa. Ohut varmuuskopiointi antoi meille mahdollisuuden luoda nopeasti pääosan tilannekuvista tiedoilla niin monta kopiota kuin tarvitsimme (MySQL DBMS:n tietohakemisto).

Ensimmäinen teline, Thin LVM -tekniikka

Tätä lukua voidaan kutsua myös nimellä "Kuinka tehdä nopeimpia tilannekuvia suurista tietomääristä käyttämällä Ohut LVM, mikä vähentää tiedostojärjestelmän ja MySQL DBMS:n vakauden säädyttömälle tasolle."

Koska käytimme jo LVM:ää tärkeimpien käyttöjärjestelmän osioiden rakentamiseen, päätimme aloittaa siitä. Aluksi tarvitsimme erillisen fyysisen koneen - pääasiallisen MySQL-tietokannan replikan, jolle pystyimme pyynnöstä luomaan tilannekuvan replikasta ja nostamaan sen erillisen MySQL-instanssin viereen. Testauksen aikana sallimme modifiointitoimintojen käytön tässä ilmentymässä, ja testien päätyttyä poistimme sen turvallisesti. Palvelimen kokoonpano oli seuraavanlainen:

2 x Intel Silver 4114 (10x2,2 GHz HT)
8x32GB DDR4
8 x 1920 Gt Intel SSD Adaptec RAID -ohjaimessa RAID-10:ssä

Voit kirjoittaa erillisen artikkelin aiheesta RAID-ohjaimen ja ohjelmisto-RAID MD:n valinta. Sanon vain, että valintaamme vaikutti kaksi tekijää:

Kun ongelma muotoiltiin, asensimme kaikki DBMS:t RAID-ohjaimiin, joten voimme sanoa, että tämä tapahtui historiallisesti.
Ero suorituskyvyssä synteettisten tiedostojärjestelmätestien ja eri MySQL-toimintoja sisältävien testien välillä oli minimaalinen.

Jaoimme tuloksena saadun RAID-10:n: teimme yhden Volume Groupin (VG) koko taltiolle (ylimääräinen noin 6,7 Gt) ja loimme loogisen osion (Logical Volume, LV) 50 Gt:n järjestelmälle. Normaalitilanteessa määrittelemme loput tilasta MySQL-osioiksi. Mutta tarvitsimme ohuen varmuuskopion, joten loimme ensin ns. poolin, jonka sisälle loimme osion /var/lib/mysql:lle 3,5 TB (arvioitujen tietokantamäärien perusteella):

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

Alustamme osion ext4:ssä, asensimme sen, äänitimme replikan ja saimme alkuperäisen jalustan. Sitten teimme sidoksen API:n muodossa, jonka pitäisi luoda tilannekuvia, nostaa MySQL-tietokannan ilmentymä tietylle portille ja poistaa luotu ilmentymä. Koska tämä käyttää yksinomaan järjestelmäkutsuja, valitsimme komentosarjakieleksi tavallisen bashin ja otimme käyttöön avoimen lähdekoodin ratkaisun yhdistämään HTTP → bash API. mene paljastamaan, kirjoitettu Go.

Jonakin päivänä julkaisemme bash-skriptimme avoimeen lähdekoodiin, mutta toistaiseksi kuvailen vain pääalgoritmia:

Päätilanteen snapmainin luominen:

Pääkopion pysäyttäminen.
Estämme toiminnot snapmain-tilannevedolla.
Luo uusi tilannekuvan snapmain.
Käynnistä MySQL ja poista lukitus.

Tietokannan luominen mielivaltaiseen porttiin snapmainista:

Lukitsemme tietyn tietokannan esiintymän (portin).
Tarkistamme, onko päätilanteen luominen estetty. Jos se on siellä, odotamme ja tarkistamme uudelleen 5 sekunnin välein.
Tarkistamme, onko ilmentymässä vanhaa LV-osaa.
3.1 Jos on, pysäytä MySQL-ilmentymä ja poista LV-osio painamalla kill -9.
Luomme uuden esiintymän snapmainista.
Valmistelemme ja liitämme hakemistoja tätä tapausta varten.
Poistamme orjan attribuutit (tiedostot) ja käynnistämme MySQL-instanssin.
Tehdään hänestä mestari.
Poistamme eston.

Tietokannan poistaminen satunnaisessa portissa:

Lukitsemme tietyn tietokannan esiintymän (portin).
Tapa MySQL-ilmentymä käyttämällä kill -9:ää.
Irrotetaan hakemistot.
Poistamme LV-osion ja poistamme lukon.

Esimerkkikomennot uuden tietokantailmentymän osioiden kloonaamiseen:

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

Nyt kerron sinulle pääongelmasta, jonka kohtasimme käytettäessä ohutta redundanssia. Olemme jumissa SSD-asemien suorituskyvyssä. Tämä johtui Thin LVM:n ominaisuuksista: se toimii periaatteessa laitetasolla matalan tason paloilla, joiden oletuskoko on 4 MB. Miltä se näytti:

Luo tilannekuva pääosiosta /var/lib/mysql.
Aloitamme replikoinnin saavuttaaksemme mestarin.
Kaikki replikataulukoiden muutokset pakottavat vanhat, muuttumattomat tietopalat tallentamaan tilannevedososioon.
Kaikki korotettuun testiinstanssiin tehdyt muutokset tallentavat vanhoja, muokkaamattomia tietopaloja kyseisen ilmentymän kloonatuun tilannekuvaosaan.
Saamme 100 %:n I/O-toimintojen kuormituksen laitteeseen, toimintojen hidastumisen ja replikan asteittaisen viiveen.
Työpäivän päätteeksi saamme useita tunteja jäljessä olevan telineen.

Miten käsittelimme tämän saadaksemme järkevämmän tuloksen (pääkohdat):

RAID-ohjain:

Kaikki välimuistityypit ovat oletusarvoisesti poissa käytöstä.
Aseta takaisinkirjoitus (kun tiedot tulevat puskuriin, kirjoitus valmistuu ennen varsinaista tallennusta levylle).

Tiedostojärjestelmä:

Kirjoitimme liitoskohtaan /var/lib/mysql noatime,nodiratime,data=writeback
Poistettu ext4-kirjaus tune2fs:llä.

MySQL:

Määrätty innodb_flush_method = O_DSYNC (lisätty tallennusnopeus, mikä heikentää luotettavuutta).
Kirjautuminen on poistettu käytöstä, emme tarvitse lokeja.
Määrätty innodb_buffer_pool_size = 4G (mitä pienempi InnoDB-poolin koko on, sitä nopeammin MySQL sammuu, kun se pysäytetään, ja sitä nopeammin luomme tilannevedoksen).

Tämä ei ole täydellinen luettelo, etenkään MySQL:n osalta. Jäljellä olevat muutokset ovat kuitenkin vähäisiä, eivätkä ne usein ole aina tai tarkasti sovellettavissa. Esimerkiksi yrittäessämme purkaa levyjä, otimme jopa pois innodb_parallel_doublewrite_path tiedostossa /dev/shm, mikä joissakin tapauksissa säästää jopa 5 sekuntia, kun käynnistettiin väärin lopetettu ilmentymä.

Miksi lopetamme MySQL:n ennen tilannekuvan ottamista? Loppujen lopuksi voimme poistaa sen toimivasta kopiosta. Se on oikein, mutta tämän tilannekuvan uusi tietokanta-ilmentymä katsotaan oletusarvoisesti vahingoittuneeksi, ja se vaatii täyden tarkistuksen käynnistyksen yhteydessä. Replikan pysäyttäminen on ehdottomasti nopeampaa, vaikka se onkin koko prosessin pisin toimenpide.

Tuloksena saimme hyväksyttävämmät ajoitukset ja käyttövalmiin telineen. Vaikka, kuten pääkopion replikointiviiveen kaunopuheimmasta kaaviosta voidaan nähdä, tilanne on edelleen kaukana ihanteellisesta:

Muiden puutteiden joukossa kannattaa huomioida Thin LVM -poolin käytännöllinen mahdottomuus: järjestelmän standardien iostat-toimintojen lisäksi on mahdotonta ymmärtää esimerkiksi mikä poolielementti kuormittaa tiedostojärjestelmää tällä hetkellä eniten.

Erikseen on syytä huomata yksi suuri haitta, joka liittyy yllä kuvattuun optimointiin: saimme YOLO-telineen. Noin kerran kahdessa kuukaudessa ext4 ei kestänyt tällaista väärinkäyttöä ja hajosi korjaamattomasti, mikä vaati replikan uudelleenalustamista ja uudelleenlatausta. Nopeudessa voitettuamme tuhosimme toivottomasti vakauden.

Mitä mittareita sinun tulee seurata Thin LVM:n käytön aikana:

Thin pool data %
Thin pool metadata %

Jos osastomme selviää datan tilan loppumisesta (levyjen puhdistaminen riittää), metatietojen tilan loppuminen johtaa poolin täydelliseen romahtamiseen ja tarpeeseen rakentaa se uudelleen tyhjästä.

Altaan tiedostojärjestelmä pirstoutuu ajan myötä hyvin. Suosittelen cron-komennon suorittamista kerran päivässä fstrim -v /var/lib/mysql.

Välisummat:

Tekniikka on helppo soveltaa, aivan kuten LVM itse, eikä se vaadi erityistä insinööripätevyyttä.
Se sopii hyvin pieniin ja ei liian ladattuihin tietokantoihin. Mitä pienempi tietokanta on, sitä vähemmän paloja liikkuu tiedostojärjestelmässä poolissa ja sitä pienempi on levyjen kuormitus.
Tehtäväämme varten aloimme etsiä muita ratkaisuja, joista keskustellaan seuraavassa osiossa.

Toinen teline, ZFS-tekniikka

Työskentelin kauan sitten ZFS-tiedostojärjestelmän kanssa, mutta silloin ZFS toimi luotettavasti hyvin omalla Solaris-käyttöjärjestelmäperheellään. FreeBSD:hen tehtiin porttaus melko hyvällä toteutustasolla. Oli myös keskeneräinen porttaus... Linux, jota harvat käyttivät. B-puu-tiedontallennusrakenteensa vuoksi (muuten MySQL:n InnoDB:llä on sama tallennusrakenne) ZFS suoriutui huonosti asennuksissa, joissa oli erittäin suuri määrä tiedostoja. Tämä yhdistettynä tarpeeseen opetella käyttöohjeet ennen käyttöä johti siihen, että käytin tätä tiedostojärjestelmää pitkäaikaisesti. Ext4 ja xfs nousivat esiin ja niistä tuli standardi. Mutta koska ZFS on enemmän kuin sopiva tarpeisiimme, ja Linux-versio on arvostelujen perusteella kasvanut täysin järkeväksi tuotteeksi (vaikkakaan sitä ei täysin tueta, minkä vuoksi järjestelmän asentaminen ZFS:ään tyhjästä on mahdollista vain erilaisten voodoo-tekniikoiden avulla), päätimme kokeilla sitä.

Ilmeisistä syistä jalustalle valittiin samanlainen kokoonpano (poikkeuksena RAID-ohjain). Asensimme kahdeksan 1920 Gt:n SSD-asemaa. Ei ollut halua kirjoittaa omaa verkkokuvaamme palvelimen lataamiseksi paljaaseen ZFS:ään, joten purimme 50 Gt kaikista levyistä ja teimme niille MD RAID-10:n järjestelmää varten. Loput 1950 Gt jokaisella levyllä yhdistettiin RAID-10:n ZFS-analogiksi:

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

Loimme osiot MySQL:lle:

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

Huomaa, että olemme ottaneet käyttöön alkuperäisen gzip-tietojen pakkaamisen. Palvelimella on paljon prosessoriresursseja, eivätkä ne ole täysin käytössä. Tämän seurauksena 3 TB tietokannastamme muuttui 1,6 TB:ksi, ja koska heikko lenkki, kuten edellisessä tapauksessa, on levyn maksimi suorituskyky. vähemmän dataa sen parempi, saamme mahtavan bonuksen ZFS:ltä alusta alkaen! Ruuhka-aikoina täydellä kuormituksella gzipin pitäminen käynnissä vie jopa 4 ydintä, mutta se ei haittaa.

Sitten toteutus sujui nopeammin. MySQL-replica-asetukset siirrettiin LVM-telineestä kopioituna. Jouduin käyttämään jonkin aikaa skriptien uudelleenkirjoittamiseen ZFS-komennoilla, mutta yleisesti ottaen algoritmit pysyivät samoina. Esimerkki tilannekuvan luomisesta:

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

Lisävirityksestä: siirsimme ZFS-osiot metadatalla ja l2arc- ja zil-lokeilla muistiin. Tehtävämme kannalta, kuten myöhemmin kävi ilmi, tämä oli tarpeeton, mutta toistaiseksi jätimme tämän optimoinnin tarvittaessa helposti muutettavaksi. Yksi negatiivisista vaikutuksista on, että palvelimen uudelleenkäynnistyksen jälkeen sinun on luotava uudelleen vastaavat muistialueet. Tietoja ei menetetä. Zpoolin tilaleikkaus:

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

Tässä kokoonpanossa aloitimme telineen testaamisen ja saimme erinomaisia tuloksia: kahdella samanaikaisesti käynnissä olevalla tietokanta-instanssilla (ja aktiivisella pääreplikalla) tilannekuvissa saimme 50-60 % levyn käyttöasteen.

Pääsimme eroon pääongelmastamme, kuten replikointiviivekaaviosta näkyy (vertaa edelliseen Thin LVM -osion kaavioon):

Tämän lisäksi ja sen ansiosta olemme nopeutuneet huomattavasti kaikkia toimintoja: tilannevedoksen täydellinen luominen pysäytyksellä ja replikan käynnistämisellä kestää jopa 40 sekuntia, uuden MySQL-ilmentymän käyttöönotto tilannevedosta kestää jopa 20 sekuntia. Mikä on enemmän kuin tyydyttävä sekä meille että ohjelmakooditesteillemme.

Välisummat:

Tulokset täyttivät täysin tarpeemme hankkia kopio tuotantotietokannasta koodin testaamista varten.
Tekniikka vaatii sisääntuloa: sinun on ymmärrettävä, mitä ZFS on ja kuinka työskennellä sen kanssa.
Emme ole tarkistaneet ZFS:n nykyistä tilaa suurella määrällä (yli miljoona) pieniä tiedostoja. Oletamme kuitenkin, että ongelma jatkuu, joten en suosittele tätä tiedostojärjestelmää mihinkään tiedostojen tallennustilaan.

Mitä seuraavaksi?

Osaston puitteissa ei ole muuta tekemistä, olemme tyytyväisiä tulokseen. Ehkä tulevaisuudessa lisäämme testaukseen tarpeettomien taulukoiden poissulkemista jalustan replikointiasetuksiin, mikä pienentää tietokannan kokoa entisestään. Emme ole testanneet BTRFS-järjestelmää ja sen ohuen redundanssitekniikan toteutusta. Tällainen tehtävä ei kuitenkaan ole enää sen arvoinen, koska päätavoite on saavutettu. Yleisesti ottaen haluaisin tietysti siirtyä pois yllä kuvatusta lähestymistavasta - toteuttaa toimiva tietokanta-migraatiot testiympäristöön, luoda erillinen testitietokantapiiri ja aloittaa päätietokannan sirpalointi. Käytämme tätä jo nyt paljon, mistä tulemme varmasti puhumaan tulevissa artikkeleissa.

Tulokset

Alkuperäinen ongelma ratkesi, vaikkakin epätavallisella tavalla. Välipäätelmissä kuvattiin kunkin käytetyn tekniikan edut ja haitat, joten päätetään, mitä tekniikkaa voidaan käyttää ja milloin:

Ohut LVM - pienille tietokantoille ja kun et halua tai sinulla ei ole aikaa oppia ZFS:ää.
ZFS - jos sinulla on kokemusta sen kanssa työskentelemisestä tai mahdollisuus viettää aikaa sen opiskeluun missä tahansa tilanteessa.

Korkeammalla tasolla tämä artikkeli ei ole vain kahden tiedostojärjestelmän tekniikan vertailu. Pääideana, jonka haluan välittää ja vahvistaa, on, että liiketoimintakriittisissä tilanteissa ei pidä pelätä ajatella laatikon ulkopuolella ja ottaa vain valmiita reseptejä. Olipa kerran teknisellä osastolla voitiin pudistella päätämme ja sanoa, että kolmen teratavun kopiot tietokannasta alle minuutissa on mahdoton, emmekä tarvitse riskialttiita teknologioita, tehdään oikein. Se oli mahdollista, mutta olisimme menettäneet noin kuudesta kuukaudesta vuoteen ja paljon asiakasmatkoja (matkailu on tärkein liiketoimintamme indikaattori) ilman testausta ja toteutusta. Toimimalla laatikon ulkopuolella emme menettäneet paljon aikaa käyttöönottoon, saimme kokemusta uusista ja unohdetuista vanhoista teknologioista ja tarjosimme testausta silloin, kun sitä todella tarvitsimme. Tällä oli epäilemättä positiivinen vaikutus kaikkiin indikaattoreihimme. Valinta on aina sinun, ja me omalta osaltamme jatkamme blogissamme puhumista mielenkiintoisista nykyisistä ja tulevista saavutuksista.

Lähde: will.com