Hvernig á að athuga diska með fio fyrir nægilega frammistöðu fyrir etcd

Athugið. þýð.: Þessi grein er afrakstur lítillar rannsóknar sem framkvæmdar voru af IBM Cloud verkfræðingum í leit að lausn á raunverulegu vandamáli sem tengist rekstri etcd gagnagrunnsins. Svipað verkefni átti við fyrir okkur, hins vegar getur framgangur hugleiðinga og athafna höfunda verið áhugaverður í víðara samhengi.

Stutt samantekt á allri greininni: fio og etcd

Afköst etcd klasa er mjög háð hraða undirliggjandi geymslu. etcd flytur út ýmsar Prometheus mælikvarða til að fylgjast með frammistöðu. Einn þeirra er wal_fsync_duration_seconds. Í skjölum fyrir frv það segirað geymsla geti talist nógu hröð ef 99. hundraðshluti þessa mælikvarða fer ekki yfir 10 ms...

Ef þú ert að íhuga að setja upp etcd þyrping á Linux vélum og vilt prófa hvort drif (eins og SSD) séu nógu hröð, mælum við með því að nota vinsæla I/O prófunartækið sem kallast fio. Það er nóg að keyra eftirfarandi skipun (map test-data verður að vera staðsett í uppsettu skiptingunni á prófuðu drifinu):

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

Það er aðeins eftir að skoða úttakið og athuga hvort 99. hundraðshlutinn passi fdatasync eftir 10 ms. Ef svo er, þá virkar drifið þitt nógu hratt. Hér er dæmi um úttak:

fsync/fdatasync/sync_file_range:
  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]

Nokkrar athugasemdir:

1. Í dæminu hér að ofan höfum við breytt breytunum --size и --bs fyrir tiltekið mál. Til að fá marktæka niðurstöðu frá fio, tilgreindu gildi sem hæfa notkunartilvikinu þínu. Hvernig á að velja þá verður fjallað hér að neðan.
2. Aðeins meðan á prófun stendur fio hleður undirkerfi disksins. Í raunveruleikanum er líklegt að önnur ferli muni skrifa á disk (fyrir utan þau sem tengjast wal_fsync_duration_seconds). Þetta viðbótarálag getur aukist wal_fsync_duration_seconds. Með öðrum orðum, ef 99. hundraðshluti frá prófun með fio, aðeins minna en 10 ms, það eru góðar líkur á að geymsluafköst séu ekki nægjanleg.
3. Fyrir prófið þarftu útgáfuna fio ekki lægra en 3.5, vegna þess að eldri útgáfur safna ekki saman niðurstöðum fdatasync í formi hundraðshluta.
4. Ofangreind niðurstaða er aðeins lítill útdráttur úr almennri niðurstöðu fio.

Meira um fio og etcd

Nokkur orð um WALs etcd

Almennt nota gagnagrunnar fyrirbyggjandi skógarhögg (Write-ahead skógarhögg, WAL). etcd hefur einnig áhrif. Umfjöllun um WAL er utan gildissviðs þessarar greinar, en í okkar tilgangi, það sem þú þarft að vita er að hver meðlimur etcd klasa geymir WAL í viðvarandi geymslu. etcd skrifar nokkrar lykilgildi geymsluaðgerðir (eins og uppfærslur) í WAL áður en þær eru framkvæmdar. Ef hnútur hrynur og endurræsist á milli skyndimynda, mun etcd geta endurheimt viðskipti frá fyrri skyndimynd byggt á innihaldi WAL.

Þannig að í hvert skipti sem viðskiptavinur bætir lykli við KV geymsluna eða uppfærir gildi núverandi lykils, etcd bætir lýsingu á aðgerðinni við WAL, sem er venjuleg skrá í viðvarandi geymslunni. etcd VERÐUR að vera 100% viss um að WAL færslan hafi í raun verið vistuð áður en haldið er áfram. Til að ná þessu á Linux er ekki nóg að nota kerfiskallið write, þar sem skrifaðgerðin sjálf á efnismiðla getur tafist. Til dæmis gæti Linux geymt WAL færslu í skyndiminni í kjarna í minni (td í skyndiminni síðunnar) í nokkurn tíma. Til að tryggja að gögnin séu skrifuð á fjölmiðla þarf að kalla fram kerfiskall eftir ritunina fdatasync - þetta er nákvæmlega það sem etcd gerir (eins og þú sérð í eftirfarandi úttak strace; Hérna 8 - WAL skráarlýsing):

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

Því miður tekur það nokkurn tíma að skrifa í viðvarandi geymslu. Langvarandi framkvæmd fdatasync kalla getur haft áhrif á frammistöðu etcd. Í gagnageymslunni gefið til kynna, að fyrir nægjanlegan árangur sé nauðsynlegt að 99. hundraðshluti lengdar allra símtala fdatasync þegar skrifað var í WAL skrá var minna en 10 ms. Það eru aðrar geymslutengdar mælingar, en þessi grein mun einbeita sér að því.

Verðmæt geymsla með fio

Þú getur metið hvort tiltekin geymsla henti til notkunar með etcd með því að nota tólið fio — vinsæll I/O prófari. Hafðu í huga að I/O disks getur gerst á marga mismunandi vegu: samstillingu/ósamstillingu, marga mismunandi kerfiskerfisflokka og svo framvegis. Hin hliðin á peningnum er sú fio mjög erfitt í notkun. Tækið hefur margar breytur og mismunandi samsetningar á gildum þeirra leiða til gjörólíkra niðurstaðna. Til þess að fá sanngjarnt mat fyrir etcd þarftu að ganga úr skugga um að skrifálagið sem fio myndar sé eins nálægt WAL skráarálagi etcd og mögulegt er:

• Þetta þýðir að mynda fio álagið ætti að minnsta kosti að vera röð af samfelldum skrifum á skrána, þar sem hver skrifaaðgerð samanstendur af kerfiskalli writefylgt af fdatasync.
• Til að virkja raðritun verður þú að tilgreina fánann --rw=write.
• Það fio skrifaði með símtölum write (frekar en önnur kerfissímtöl - td. pwrite), notaðu fánann --ioengine=sync.
• Að lokum fáninn --fdatasync=1 tryggir að sérhver write ætti fdatasync.
• Hinar tvær breytur í dæminu okkar eru: --size и --bs - getur verið mismunandi eftir tilteknu notkunartilviki. Næsti hluti mun lýsa uppsetningu þeirra.

Hvers vegna við völdum fio og hvernig við lærðum hvernig á að setja það upp

Þessi athugasemd kemur frá raunverulegu tilviki sem við lentum í. Við vorum með þyrping á Kubernetes v1.13 með vöktun á Prometheus. SSD diskar voru notaðir sem geymsla fyrir etcd v3.2.24. Mælingar osfrv. sýndu of háa biðtíma fdatasync, jafnvel þegar þyrpingin var aðgerðalaus. Fyrir okkur virtust þessar mælingar mjög vafasamar og við vorum ekki viss um hvað þær táknuðu nákvæmlega. Að auki samanstóð þyrpingin af sýndarvélum og því var ekki hægt að segja til um hvort seinkunin væri vegna sýndarvæðingar eða SSD um að kenna.

Að auki skoðuðum við ýmsar breytingar á uppsetningu vélbúnaðar og hugbúnaðar, svo við þurftum leið til að meta þær. Auðvitað væri hægt að keyra etcd í hverri uppsetningu og skoða samsvarandi Prometheus mæligildi, en það myndi krefjast verulegrar fyrirhafnar. Það sem við þurftum var einföld leið til að meta ákveðna uppsetningu. Okkur langaði að prófa skilning okkar á Prometheus mæligildum sem koma frá etcd.

Til þess þurfti að leysa tvö vandamál:

• Í fyrsta lagi, hvernig lítur I/O álagið sem myndast af etcd út þegar skrifað er í WAL skrár? Hvaða kerfissímtöl eru notuð? Hver er stærð plötublokkanna?
• Í öðru lagi skulum við segja að við höfum svör við ofangreindum spurningum. Hvernig á að endurskapa samsvarandi álag með fio? Eftir allt fio — afar sveigjanlegt gagnsemi með gnægð af breytum (þetta er auðvelt að sannreyna, td. hér - ca. þýðing.).

Við leystum bæði vandamálin með sömu stjórnunaraðferðinni lsof и strace:

• Með lsof þú getur skoðað allar skráarlýsingar sem ferlið notar, sem og skrárnar sem þær vísa til.
• Með strace þú getur greint ferli sem þegar er í gangi eða keyrt ferli og horft á það. Skipunin sýnir öll kerfissímtöl sem þetta ferli hringir og, ef nauðsyn krefur, afkomendur þess. Hið síðarnefnda er mikilvægt fyrir ferla sem eru að gafla, og etcd er eitt slíkt ferli.

Það fyrsta sem við gerðum var að nota strace til að skoða etcd netþjóninn í Kubernetes klasanum á meðan hann var aðgerðalaus.

Svo kom í ljós að WAL færslublokkir eru mjög þéttar flokkaðar, stærð meirihlutans var á bilinu 2200-2400 bæti. Þess vegna notar skipunin í upphafi þessarar greinar fánann --bs=2300 (bs er stærðin í bætum á hverri skrifblokk í fio).

Vinsamlegast athugaðu að stærð etcd skrifblokka getur verið mismunandi eftir útgáfu, uppsetningu, breytugildum osfrv. - það hefur áhrif á lengdina fdatasync. Ef þú ert með svipað notkunartilvik skaltu greina með strace etcd ferli til að fá uppfærð gildi.

Síðan, til að fá skýra og yfirgripsmikla hugmynd um hvernig etcd virkar með skráarkerfinu, byrjuðum við það frá undir strace með fánum -ffttT. Þetta gerði það mögulegt að fanga undirferli og skrifa úttak hvers og eins í sérstaka skrá. Auk þess fengust ítarlegar upplýsingar um upphafstíma og lengd hvers kerfissímtals.

Við notuðum líka skipunina lsoftil að staðfesta skilning þinn á úttakinu strace með tilliti til þess hvaða skráarlýsing var notuð í hvaða tilgangi. Ég fékk niðurstöðuna strace, svipað og hér að ofan. Tölfræðilegar meðferðir með samstillingartíma staðfestu að mælikvarðinn wal_fsync_duration_seconds frá etcd samsvarar símtölum fdatasync með WAL skráarlýsingum.

Til að búa til með fio svipað vinnuálag og frá etcd, skjölin um veituna voru rannsökuð og færibreytur sem henta fyrir verkefni okkar valdar. Við höfum staðfest að rétt kerfissímtöl séu í gangi og staðfest lengd þeirra með því að keyra fio á strace (eins og það var gert ef um er að ræða etcd).

Sérstaklega var hugað að því að ákvarða gildi stikunnar --size. Það táknar heildar I/O álag sem myndast af fio tólinu. Í okkar tilviki er þetta heildarfjöldi bæta sem skrifaður er til fjölmiðla. Það er í beinu hlutfalli við fjölda símtala write (og fdatasync). Fyrir ákveðinn bs fjölda símtala fdatasync jafngildir size / bs.

Þar sem við höfðum áhuga á hundraðshlutanum vildum við að fjöldi sýna væri nógu stór til að vera tölfræðilega marktækur. Og ákvað það 10^4 (sem samsvarar 22 MB stærð) dugar. Minni færibreytugildi --size gaf áberandi hávaða (til dæmis símtöl fdatasync, sem taka mun lengri tíma en venjulega og hafa áhrif á 99. hundraðshluta).

Þú ræður

Greinin sýnir hvernig á að nota fio má dæma um hvort miðillinn sem ætlaður er til notkunar með etcd sé nógu hraður. Nú er það undir þér komið! Þú getur skoðað sýndarvélar með SSD geymslu í þjónustunni IBM Cloud.

PS frá þýðanda

Með tilbúnum notkunarmálum fio Fyrir önnur verkefni, sjá skjöl eða beint til verkefnageymslur (þeir eru miklu fleiri en nefndir eru í skjölunum).

PPS frá þýðanda

Lestu líka á blogginu okkar:

• «etcd 3.4.3: geymsluáreiðanleiki og öryggisrannsókn»;
• «Reynsla okkar af gögnum í etcd Kubernetes klasa beint (án K8s API)»;
• «6 skemmtilegar kerfisvillur í rekstri Kubernetes [og lausn þeirra]'.

Heimild: www.habr.com