Tallennusnopeus sopii etcd: lle? Kysytään fio

Lyhyt tarina fiosta ja jne

Klusterin suorituskyky jne riippuu pitkälti sen varastoinnin suorituskyvystä. etcd vie joitain mittareita kohteeseen Prometheustarjotaksesi halutut tallennussuorituskykytiedot. Esimerkiksi wal_fsync_duration_seconds-mittari. etcd:n dokumentaatiossa lukee: Jotta tallennus voidaan katsoa riittävän nopeaksi, tämän mittarin 99. prosenttipisteen on oltava alle 10 ms. Jos aiot ajaa etcd-klusterin Linux-koneissa ja haluat arvioida, onko tallennustilanne riittävän nopea (esim. SSD), voit käyttää FIO on suosittu työkalu I/O-toimintojen testaamiseen. Suorita seuraava komento, jossa test-data on tallennuspaikan liitoskohdan alla oleva hakemisto:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Sinun tarvitsee vain katsoa tuloksia ja tarkistaa, että keston 99. prosenttipiste fdatasync alle 10 ms. Jos näin on, sinulla on kohtuullisen nopea tallennustila. Tässä on esimerkki tuloksista:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Huomautuksia

• Olemme mukauttaneet --size- ja --bs-vaihtoehdot erityistä skenaariota varten. Saadaksesi hyödyllisen tuloksen fiosta, anna omat arvosi. Mistä niitä saa? Lukea kuinka opimme määrittämään fio.
• Testauksen aikana kaikki I/O-kuorma tulee fiolta. Tosielämän skenaariossa tallennustilaan tulee todennäköisesti muita kirjoituspyyntöjä kuin wal_fsync_duration_seconds. Ylimääräinen kuormitus lisää parametrin wal_fsync_duration_seconds arvoa. Joten jos 99. prosenttipiste on lähellä 10 ms, tallennustilasi on loppumassa.
• Ota versio FIO vähintään 3.5 (edelliset eivät näytä fdatasync-keston prosenttipisteitä).
• Yllä on vain katkelma fion tuloksista.

Pitkä tarina fiosta yms

Mikä on WAL in etcd

Yleensä tietokannat käyttävät eteenpäin kirjoitettava loki; etcd käyttää sitä myös. Emme käsittele kirjoituslokia (WAL) tässä yksityiskohtaisesti. Riittää, kun tiedämme, että jokainen etcd-klusterin jäsen pitää sitä jatkuvassa muistissa. etcd kirjoittaa jokaisen avainarvooperaation (kuten päivityksen) WAL:iin ennen sen soveltamista varastoon. Jos yksi tallennusjäsenistä kaatuu ja käynnistyy uudelleen tilannevedosten välillä, se voi palauttaa tapahtumat paikallisesti viimeisen WAL-sisällön tilannevedoksen jälkeen.

Kun asiakas lisää avaimen avainarvovarastoon tai päivittää olemassa olevan avaimen arvon, etcd tallentaa toiminnon WAL:iin, joka on tavallinen tiedosto pysyvässä tallennustilassa. etcd TÄYTYY olla täysin varma, että WAL-merkintä todella tapahtui ennen kuin jatkat käsittelyä. Linuxissa yksi järjestelmäkutsu ei riitä tähän. kirjoittaa, koska varsinainen fyysiseen tallennustilaan kirjoittaminen saattaa viivästyä. Esimerkiksi Linux voi tallentaa WAL-merkinnän ytimen välimuistiin (kuten sivun välimuistiin) jonkin aikaa. Ja jotta tiedot kirjoitettaisiin tarkasti pysyvään tallennustilaan, fdatasync-järjestelmäkutsu tarvitaan kirjoittamisen jälkeen, ja etcd vain käyttää sitä (kuten työn tuloksesta näkyy ytsakki, jossa 8 on WAL-tiedoston kuvaus):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Valitettavasti pysyvään tallennustilaan kirjoittaminen ei tapahdu hetkessä. Jos fdatasync-kutsu on hidas, etcd-järjestelmän suorituskyky kärsii. etcd:n dokumentaatiossa lukeeettä tallennusta pidetään riittävän nopeana, jos 99. prosenttipisteessä fdatasync-kutsujen kirjoittaminen WAL-tiedostoon kestää alle 10 ms. Tallennukseen on muita hyödyllisiä mittareita, mutta tässä viestissä puhumme vain tästä mittarista.

Tallennustilan arvioiminen fion avulla

Jos sinun on arvioitava, sopiiko tallennustila etcd:lle, käytä fio:a, erittäin suosittua I/O-kuormitustestaustyökalua. On syytä muistaa, että levytoiminnot voivat olla hyvin erilaisia: synkronisia ja asynkronisia, monia järjestelmäkutsujen luokkia jne. Tämän seurauksena fio on melko vaikea käyttää. Siinä on monia parametreja, ja niiden arvojen erilaiset yhdistelmät tuottavat hyvin erilaisia ​​I/O-työkuormia. Saadaksesi riittävät luvut etcd:lle, sinun tulee varmistaa, että fio:n testikirjoituskuorma on mahdollisimman lähellä todellista etcd:n kuormaa WAL-tiedostoja kirjoitettaessa.

Siksi fion tulisi vähintään luoda sarja peräkkäisiä kirjoituksia tiedostoon, jokainen kirjoitus koostuu järjestelmäkutsusta kirjoittaajota seuraa fdatasync-järjestelmäkutsu. Jaksottaiset kirjoitukset fioon vaativat --rw=write-vaihtoehdon. Jotta fio käyttää kirjoitusjärjestelmäkutsua kirjoittaessaan sen sijaan kirjoittaa, sinun tulee määrittää parametri --ioengine=sync. Lopuksi, jotta fdatasync voidaan kutsua jokaisen kirjoittamisen jälkeen, sinun on lisättävä parametri --fdatasync=1. Tämän esimerkin kaksi muuta vaihtoehtoa (--size ja -bs) ovat komentosarjakohtaisia. Seuraavassa osiossa näytämme, kuinka ne määritetään.

Miksi fio ja kuinka opimme asettamaan sen

Tässä viestissä kuvaamme todellista tapausta. Meillä on klusteri Kubernetes v1.13, jota seurasimme Prometheuksen kanssa. etcd v3.2.24 isännöi SSD:llä. Etcd-mittarit osoittivat fdatasync-viiveet liian korkeiksi, vaikka klusteri ei tehnyt mitään. Mittarit olivat outoja, emmekä tienneet, mitä ne tarkoittivat. Klusteri koostui virtuaalikoneita, oli tarpeen ymmärtää, mikä ongelma oli: fyysisissä SSD-levyissä vai virtualisointikerroksessa. Lisäksi teimme usein muutoksia laitteisto- ja ohjelmistokokoonpanoon, ja tarvitsimme tavan arvioida niiden tuloksia. Voisimme ajaa etcd:tä kaikissa kokoonpanoissa ja tarkastella Prometheus-mittareita, mutta se on liikaa vaivaa. Etsimme melko yksinkertaista tapaa arvioida tiettyä kokoonpanoa. Halusimme tarkistaa, ymmärrämmekö Prometheus-mittarit oikein etcd:stä.

Mutta tätä varten oli ratkaistava kaksi ongelmaa. Ensinnäkin, miltä I/O-kuorma, jonka etcd luo WAL:iin kirjoitettaessa, näyttää? Mitä järjestelmäkutsuja käytetään? Mikä on tietueiden koko? Toiseksi, jos vastaamme näihin kysymyksiin, kuinka voimme toistaa samanlaisen työmäärän fion kanssa? Älä unohda, että fio on erittäin joustava työkalu, jossa on monia vaihtoehtoja. Ratkaisimme molemmat ongelmat yhdellä lähestymistavalla - komentojen avulla lof и ytsakki. lsof listaa kaikki prosessin käyttämät tiedostokuvaajat ja niihin liittyvät tiedostot. Ja stracen avulla voit tutkia jo käynnissä olevaa prosessia tai aloittaa prosessin ja tutkia sitä. strace tulostaa kaikki järjestelmäkutsut tutkittavasta prosessista (ja sen aliprosesseista). Jälkimmäinen on erittäin tärkeä, koska etcd on juuri noudattamassa samanlaista lähestymistapaa.

Käytimme ensin stracea tutkiaksemme Kubernetesin etcd-palvelinta, kun klusteria ei kuormitettu. Näimme, että lähes kaikki WAL-tietueet olivat suunnilleen samankokoisia: 2200–2400 tavua. Siksi määritimme viestin alussa olevassa komennossa parametrin -bs=2300 (bs tarkoittaa kunkin fio-merkinnän kokoa tavuina). Huomaa, että etcd-merkinnän koko riippuu etcd-versiosta, jakelusta, parametriarvoista jne. ja vaikuttaa fdatasyncin kestoon. Jos sinulla on samanlainen skenaario, tutki etcd-prosessejasi stracella saadaksesi tarkat luvut.

Sitten saadaksemme hyvän käsityksen etcd-tiedostojärjestelmän toiminnasta aloitimme sen strace- ja -ffttT-vaihtoehdoilla. Joten yritimme tutkia aliprosesseja ja tallentaa kunkin tulosteen erilliseen tiedostoon ja saada myös yksityiskohtaiset raportit kunkin järjestelmäkutsun alkamisesta ja kestosta. Käytimme lsofia vahvistaaksemme strace-tulosteen analyysimme ja katsomme, mitä tiedostokuvaajaa käytettiin mihinkin tarkoitukseen. Joten stracen avulla saatiin yllä esitetyt tulokset. Synkronointiaikatilastot vahvistivat, että wal_fsync_duration_seconds from etcd on yhdenmukainen fdatasync-kutsujen kanssa WAL-tiedostokuvaajilla.

Kävimme fio-dokumentaation läpi ja valitsimme skriptimme vaihtoehdot, jotta fio generoisi etcd:n kaltaisen kuorman. Tarkistimme myös järjestelmäkutsut ja niiden keston ajamalla fio stracesta, kuten etcd.

Olemme valinneet huolellisesti parametrin --size arvon edustamaan koko I/O-kuormaa fiosta. Meidän tapauksessamme tämä on tallennustilaan kirjoitettujen tavujen kokonaismäärä. Se osoittautui suoraan verrannolliseksi kirjoitus- (ja fdatasync-) järjestelmäkutsujen määrään. Tietylle bs:n arvolle fdatasync-kutsujen määrä = koko/bs. Koska olimme kiinnostuneita prosenttipisteestä, meillä oli oltava tarpeeksi näytteitä ollaksemme varmoja, ja laskimme, että 10^4 riittäisi meille (eli 22 mebitavua). Jos --size on pienempi, poikkeavuuksia voi esiintyä (esimerkiksi useat fdatasync-kutsut kestävät tavallista kauemmin ja vaikuttavat 99. prosenttipisteeseen).

Kokeile itse

Näitimme sinulle, kuinka käytät fioa ja katsomme, onko tallennus tarpeeksi nopea, jotta etcd toimii hyvin. Nyt voit kokeilla sitä itse esimerkiksi virtuaalikoneilla, joissa on SSD-tallennustila IBM Cloud.

Lähde: will.com