Geymsluhraði hentugur fyrir etcd? Spyrjum fio

Smá saga um fio og etcd

Frammistaða klasa osfrv fer að miklu leyti eftir afköstum geymslu þess. etcd flytur út nokkrar mælitölur til Prometheustil að veita æskilegar upplýsingar um geymslugetu. Til dæmis mæligildið wal_fsync_duration_seconds. Í skjölunum fyrir etcd segir: Til að geymsla teljist nógu hröð verður 99. hundraðshluti þessa mælikvarða að vera minna en 10ms. Ef þú ætlar að keyra etcd þyrping á Linux vélum og vilt meta hvort geymslan þín sé nógu hröð (t.d. SSD), geturðu notað fio er vinsælt tæki til að prófa I/O aðgerðir. Keyrðu eftirfarandi skipun, þar sem test-data er skráin undir geymslustaðnum:

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

Þú þarft bara að skoða niðurstöðurnar og athuga hvort 99. hundraðshluti lengdarinnar fdatasync minna en 10 ms. Ef svo er, þá ertu með nokkuð hraðvirka geymslu. Hér er dæmi um niðurstöðurnar:

  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]

Skýringar

• Við höfum sérsniðið --stærð og --bs valkostina fyrir tiltekna atburðarás okkar. Til að fá gagnlega niðurstöðu frá fio, gefðu upp þín eigin gildi. Hvar á að fá þá? Lestu hvernig við lærðum að stilla fio.
• Á meðan á prófun stendur kemur allt I/O álag frá fio. Í raunverulegri atburðarás munu líklega aðrar skrifbeiðnir koma inn í geymsluna fyrir utan þær sem tengjast wal_fsync_duration_seconds. Aukaálagið mun auka gildi wal_fsync_duration_seconds. Þannig að ef 99. hundraðshlutinn er nálægt 10ms, þá er geymslurýmið þitt að klárast.
• Taktu útgáfuna fio ekki lægra en 3.5 (þau fyrri sýna ekki fdatasync duration hundraðshluti).
• Hér að ofan er aðeins brot af niðurstöðunum frá fio.

Löng saga um fio og etcd

Hvað er WAL í etcd

Venjulega nota gagnagrunnar skrifa fram í tímann; etcd notar það líka. Við munum ekki fjalla ítarlega um WAL-skrána. Það er nóg fyrir okkur að vita að hver meðlimur etcd klasans geymir það í viðvarandi geymslu. etcd skrifar hverja lykilgildisaðgerð (eins og uppfærslu) í WAL áður en hún er notuð í verslunina. Ef einn af geymslumeðlimunum hrynur og endurræsir sig á milli skyndimynda, getur hann endurheimt viðskipti á staðnum frá síðustu skyndimynd af WAL efni.

Þegar viðskiptavinur bætir lykli við lykilgildisgeymsluna eða uppfærir gildi núverandi lykils, skráir etcd aðgerðina í WAL, sem er venjuleg skrá í viðvarandi geymslu. etcd VERÐUR að vera alveg viss um að WAL færslan hafi raunverulega átt sér stað áður en haldið er áfram með vinnslu. Á Linux dugar eitt kerfiskall ekki fyrir þetta. skrifa, þar sem raunveruleg ritun á líkamlega geymslu gæti verið seinkuð. Til dæmis gæti Linux geymt WAL færslu í skyndiminni í kjarnaminni (svo sem skyndiminni síðu) í nokkurn tíma. Og til þess að gögnin séu nákvæmlega skrifuð í viðvarandi geymslu, þarf fdatasync kerfiskallið eftir ritunina, og etcd notar það bara (eins og þú sérð í niðurstöðu vinnunnar strá, þar sem 8 er WAL skráarlýsingin):

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>

Því miður gerist skrif í viðvarandi geymslu ekki samstundis. Ef fdatasync símtalið er hægt mun afköst etcd kerfisins verða fyrir skaða. Í skjölunum fyrir etcd segirað geymslan teljist nógu hröð ef, í 99. hundraðshluta, taka fdatasync símtöl minna en 10ms að skrifa í WAL skrána. Það eru aðrar gagnlegar mælikvarðar fyrir geymslu, en í þessari færslu erum við aðeins að tala um þetta mæligildi.

Áætla geymslu með fio

Ef þú þarft að meta hvort geymslan þín henti fyrir etcd, notaðu fio, mjög vinsælt I/O álagsprófunartæki. Það ætti að hafa í huga að diskaðgerðir geta verið mjög mismunandi: samstilltur og ósamstilltur, margir flokkar kerfiskalla osfrv. Þess vegna er fio frekar erfitt í notkun. Það hefur margar breytur og mismunandi samsetningar af gildum þeirra framleiða mjög mismunandi I/O vinnuálag. Til að fá fullnægjandi tölur fyrir etcd, ættir þú að ganga úr skugga um að prófunarálag frá fio sé sem næst raunverulegu álagi frá etcd þegar WAL skrár eru skrifaðar.

Þess vegna ætti fio að lágmarki að búa til álag af röð af raðskrifum í skrána, hver skrif mun samanstanda af kerfiskalli skrifafylgt eftir með fdatasync kerfiskallinu. Raðbundin skrif til fio krefjast --rw=write valmöguleikans. Fyrir fio að nota skrifkerfið kalla þegar þú skrifar, frekar en skrifa, þú ættir að tilgreina --ioengine=sync færibreytuna. Að lokum, til að hringja í fdatasync eftir hverja skrif, þarftu að bæta við --fdatasync=1 færibreytunni. Hinir tveir valkostirnir í þessu dæmi (--stærð og -bs) eru handritssértækar. Í næsta kafla munum við sýna þér hvernig á að setja þau upp.

Hvers vegna fio og hvernig við lærðum að setja það upp

Í þessari færslu lýsum við raunverulegu máli. Við erum með klasa Kubernetes v1.13 sem við fylgdumst með með Prometheus. etcd v3.2.24 var hýst á SSD. Etcd mælingar sýndu of háa fdatasync töf, jafnvel þegar þyrpingin var að gera ekkert. Mælingarnar voru skrítnar og við vissum ekki alveg hvað þær þýddu. Þyrpingin samanstóð af sýndarvélum, það var nauðsynlegt að skilja hvað vandamálið var: í líkamlegum SSD diskum eða í sýndarvæðingarlaginu. Auk þess gerðum við oft breytingar á uppsetningu vélbúnaðar og hugbúnaðar og við þurftum leið til að meta árangur þeirra. Við gætum keyrt etcd í hverri uppsetningu og skoðað Prometheus mæligildi, en það er of mikið vesen. Við vorum að leita að frekar einfaldri leið til að meta ákveðna uppsetningu. Við vildum athuga hvort við skiljum Prometheus mæligildi frá etcd rétt.

En til þess þurfti að leysa tvö vandamál. Í fyrsta lagi, hvernig lítur I/O hleðslan út sem etcd skapar þegar skrifað er í WAL? Hvaða kerfissímtöl eru notuð? Hver er stærð skjala? Í öðru lagi, ef við svörum þessum spurningum, hvernig endurskapum við svipað vinnuálag með fio? Ekki gleyma því að fio er mjög sveigjanlegt tól með marga möguleika. Við leystum bæði vandamálin með einni nálgun - með því að nota skipanirnar LSOF и strá. lsof listar allar skráarlýsingar sem ferlið notar og tengdar skrár þeirra. Og með strace geturðu skoðað ferli sem þegar er í gangi, eða byrjað ferli og skoðað það. strace prentar út öll kerfissímtöl frá ferlinu sem verið er að skoða (og undirferli þess). Hið síðarnefnda er mjög mikilvægt, þar sem etcd er bara að taka svipaða nálgun.

Við notuðum strace fyrst til að kanna etcd netþjóninn fyrir Kubernetes þegar ekkert álag var á þyrpinguna. Við sáum að næstum allar WAL færslur voru um það bil sömu stærð: 2200–2400 bæti. Þess vegna, í skipuninni í upphafi færslunnar, tilgreindum við færibreytuna -bs=2300 (bs þýðir stærðin í bætum fyrir hverja fio færslu). Athugaðu að stærð etcd færslunnar fer eftir etcd útgáfunni, dreifingu, breytugildum osfrv., og hefur áhrif á lengd fdatasync. Ef þú ert með svipaða atburðarás skaltu skoða etcd ferla þína með strace til að finna út nákvæmar tölur.

Síðan, til að fá góða hugmynd um hvað etcd skráarkerfið er að gera, byrjuðum við það með strace og -ffttT valkostinum. Við reyndum því að skoða barnaferlana og skrá úttak hvers þeirra í sérstakri skrá og einnig fá nákvæmar skýrslur um upphaf og lengd hvers kerfissímtals. Við notuðum lsof til að staðfesta greiningu okkar á strace úttakinu og sjá hvaða skráarlýsing var notuð í hvaða tilgangi. Þannig að með hjálp strace fengust niðurstöðurnar sem sýndar eru hér að ofan. Tölfræði um samstillingartíma staðfesti að wal_fsync_duration_seconds frá etcd er í samræmi við fdatasync símtöl með WAL skráarlýsingum.

Við fórum í gegnum skjölin fyrir fio og völdum valkosti fyrir handritið okkar þannig að fio myndi búa til svipað álag og etcd. Við athuguðum líka kerfissímtöl og lengd þeirra með því að keyra fio frá strace, svipað og etcd.

Við höfum vandlega valið gildi --size færibreytunnar til að tákna allt I/O álag frá fio. Í okkar tilviki er þetta heildarfjöldi bæta sem skrifaður er í geymsluna. Það reyndist vera í réttu hlutfalli við fjölda skrifa (og fdatasync) kerfiskalla. Fyrir ákveðið gildi bs er fjöldi fdatasync kalla = stærð/bs. Þar sem við höfðum áhuga á hundraðshlutanum urðum við að hafa næg sýni til að vera viss og við reiknuðum út að 10^4 væri nóg fyrir okkur (það er 22 mebibæti). Ef --stærð er minni, geta útlínur komið fram (til dæmis taka nokkur fdatasync símtöl lengri tíma en venjulega og hafa áhrif á 99. hundraðshlutann).

Prófaðu það sjálfur

Við sýndum þér hvernig á að nota fio og athugaðu hvort geymslan sé nógu hröð til að etcd skili góðum árangri. Nú geturðu prófað það sjálfur með því að nota til dæmis sýndarvélar með SSD geymslu IBM Cloud.

Heimild: www.habr.com