Kas salvestuskiirus sobib etcd jaoks? Küsime fio.

Lühike lugu fio-st ja etcd-st

Klastri jõudlus etcd sõltub suuresti selle salvestusruumi jõudlusest. etcd ekspordib mõned mõõdikud Prometheus, et pakkuda vajalikke andmeid salvestusruumi jõudluse kohta. Näiteks mõõdik wal_fsync_duration_seconds. Dokumendis, mis käsitleb etcd-d, on öeldud: et salvestusruum oleks piisavalt kiire, peab selle mõõdiku 99. protsentiil olema väiksem kui 10 ms. Kui kavatsete käivitada etcd klastri Linuxi masinatel ja soovite hinnata, kas teie salvestusruum (nt SSD) on piisavalt kiire, võite kasutada fio — populaarne tööriist sisend-/väljundoperatsioonide testimiseks. Käitage järgmine käsk, kus test-data on salvestusruumi mount-punkti kataloog:

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

Peate lihtsalt vaatama tulemusi ja kontrollima, et 99. protsentiil kestusest fdatasync on väiksem kui 10 ms. Kui jah, siis on teie salvestusruum piisavalt kiire. Siin on tulemuste näide:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync protsentiilid (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]

Märkus

• Oleme seadistanud parameetrite väärtused —size ja —bs oma konkreetse stsenaariumi jaoks. Fio-st kasuliku tulemuse saamiseks esitage oma väärtused. Kust neid saada? Loe edasi, kuidas me õppisime fio-d seadistama.
• Testimise ajal tuleb kogu sisendi/väljundi koormus fio-st. Reaalsetes stsenaariumites võivad salvestusruumi jõuda ka muud kirjutamislood, peale wal_fsync_duration_seconds-seose. Lisakoormus suurendab wal_fsync_duration_seconds väärtust. Nii et kui 99. protsentiil on peaaegu 10 ms, siis ei ole teie salvestusruum piisavalt kiire.
• Kasutage versiooni fio vähemalt 3.5 (eelnevad ei näita fdatasync-i kestvuse protsentiile).
• Ülaltoodud on vaid paljude tulemuste fragment fio-st.

Pikk lugu fio-st ja etcd-st

Mis on WAL etcd-s

Tavaliselt kasutavad andmebaasid ennustava kirjutamise žurnali; etcd kasutab seda samuti. Siin me ei aruta süvitsi ette kirjutamise päeva (write-ahead log, WAL). Meie jaoks on oluline teada, et iga etcd klastri liige salvestab selle püsivasse salvestusse. etcd salvestab iga operatsiooni võtme-väärtuse paaridega (näiteks uuendamine) WAL-i, enne kui rakendab need salvestusse. Kui mõni salvestuse liikmest katkeb ja taaskäivitatakse, saab ta kohaliku taastamise teostada viimasest salvestusest WAL sisu põhjal.

Kui klient lisab võtme võtme-väärtuse salvestusse või uuendab olemasoleva võtme väärtust, siis etcd kannab selle operatsiooni WAL-i, mis on tavaline fail püsivas salvestuses. Enne töötlemise jätkamist peab etcd olema täiesti veendunud, et WAL-i sissekanne on tõeliselt toimunud. Linuxis ei piisa selleks ühest süsteemi kõnest. kirjutama, kuna tegelikult võib fisikaline kirjutamine salvestusse olla viivitusega. Näiteks võib Linux hoida WAL-i sissekannet seni mälus, kuni see on tuvastatud (näiteks lehekülje vahemälu). Ja selleks, et andmed kindlalt püsivasse salvestusse kirjutada, on vajalik süsteemi kõne fdatasync pärast kirjutamist, ja just seda kasutab etcd (nagu näha käituse tulemusest strace, kus 8 on WAL-i failide descriptor):

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

Kahjuks ei toimu püsivasse salvestusse kirjutamine kohe. Kui fdatasync kõne toimub aeglaselt, siis etcd süsteemi jõudlus langeb. Dokumentatsioonis, millega tegeleb etcd, öeldakse, et salvestust peetakse piisavalt kiireks, kui 99. protsendil fdatasync kõnedest võtme WAL-i kirjutamisel kulub vähem aega kui 10 ms. On ka teisi kasulikke salvestusmeetmeid, kuid selles postituses räägime ainult sellest näitajast.

Salvestuse hindamine fio abil

Kui soovite hinnata, kas teie salvestusruum sobib etcd-le, kasutage fio-d - väga populaarset sisendi-väljundi koormustestimise tööriista. Tuleb meeles pidada, et kettaoperatsioonid võivad olla väga erinevad: sünkroonsed ja asünkroonsed, erinevad süsteemikutsed jne. Selle tulemusena on fio kasutamine piisavalt keeruline. Sellel on palju parameetreid ja erinevad kombinatsioonid nende väärtustest annavad täiesti erinevaid sisendi-väljundi koormusi. Et saada sobivaid numbreid etcd jaoks, tuleb veenduda, et fio kirjutamiskoormus on maksimaalselt lähedane reaalsele koormusele, mida etcd genereerib WAL-failide kirjutamisel.

Seega peab fio vähemalt genereerima koormuse, mis koosneb järjestikustest kirjutamisoperatsioonidest faili, kus iga kirjeldus sisaldab süsteemikutsumist kirjutama, millele järgneb süsteemikutsumine fdatasync. Järjestikuste kirjutamisoperatsioonide jaoks vajab fio parameetrit —rw=write. Et fio kirjutamise ajal kasutaks süsteemikutsumist write, mitte pwrite, tuleks määrata parameeter —ioengine=sync. Lõpuks, et pärast iga kirjutamist kutsutaks esile fdatasync, tuleb lisada parameeter —fdatasync=1. Kaks muud parameetrit selles näites (—size ja —bs) sõltuvad konkreetsest stsenaariumist. Järgmises osas räägime sellest, kuidas neid seadistada.

Miks just fio ja kuidas me õppisime seda seadistama

Selles postituses kirjeldame tõelist juhtumit. Meil oli klaster Kubernetes v1.13, mida me jälgisime Prometheuse abil. etcd v3.2.24 oli paigutatud SSD-le. etcd sagedused näitasid liiga kõrgeid latentsusi fdatasync jaoks, isegi kui klaster ei teinud midagi. Metriikad olid kummalised ja me ei teadnud täpselt, mida need tähendavad. Klaster koosnes virtuaalsete masinate komplektist ja tuli aru saada, kus probleem seisneb: füüsilistes SSD-des või virtualiseerimise kihis. Samuti tegime sageli muudatusi riistvara ja tarkvara konfigureerimises ning vajasime viisi nende tulemuste hindamiseks. Me saime käivitada etcd igas konfigureerimises ja vaadata Prometheuse metriikad, kuid see oli liiga tülikas. Otsisime piisavalt lihtsat viisi konkreetse konfiguratsiooni hindamiseks. Soovisime kontrollida, kas me saame aru Prometheuse metriikad etcd-st õigesti.

Kuid selleks tuli lahendada kaks probleemi. Esiteks, milline on sisse-/väljundkoormus, mida etcd genereerib WAL-i kirjutamisel? Milliseid süsteemi kutseid kasutatakse? Kui suured on kirjed? Teiseks, kui me vastame nendele küsimustele, kuidas luua sarnast töökoormust fio abil? Ära unusta, et fio on väga paindlik tööriist, millel on palju parameetreid. Me lahendasime mõlemad probleemid ühe lähenemisega – käskude abil. lsof ja strace. lsof näitab kõiki failideskirjade kasutajaid protsessis ja nendega seotud faile. strace'i abil saab uurida juba käimasolevat protsessi või käivitada protsessi ja seda uurida. strace prindib kõik süsteemi kutsetest, mis tulenevad uuritavast protsessist (ja tema alamprotsessidest). Viimane on eriti oluline, kuna etcd rakendab just sellist lähenemist.

Esiteks kasutasime strace'i, et uurida etcd serverit Kubernetes'ile, kui klastril ei olnud koormust. Nägime, et peaaegu kõik WAL-i kirjed olid umbes sama suurusega: 2200–2400 baiti. Seetõttu määrasime postituse alguses meeskonnas parameetri —bs=2300 (bs tähistab iga fio kirje baiti). Pange tähele, et etcd kirje suurus sõltub etcd versioonist, tarnest, parameetrite väärtustest jne ning see mõjutab fdatasync'i kestvust. Kui teil on sarnane stsenaarium, uurige oma etcd protsesse strace'i abil, et teada saada täpseid näitajaid.

Seejärel, et paremini mõista etcd tegevusi failisüsteemis, käivitasime selle strace'i abil koos parameetritega -ffttT. Nii püüdsime uurida alamprotsesse ja salvestada igaühe väljund eraldi faili, samuti saada üksikasjalikke aruandeid iga süsteemikutse alguse ja kestuse kohta. Kasutasime lsof-i, et kinnitada oma strace'i väljundi analüüsi ja näha, millist failideskirja millega kasutatakse. Nii saime strace'i abil sellised tulemused nagu eespool. Sünkroniseerimise ajastatistika kinnitas, et etcd wal_fsync_duration_seconds vastab fdatasync'i kutsetele WAL failideskirjadega.

Uurisime fio dokumentatsiooni ja valisime parameetrid oma stsenaariumi jaoks, et fio genereeriks koormuse, mis oleks sarnane etcd-le. Kontrollisime ka süsteemi kutse ja nende kestvust, käivitades fio strace'ist, sarnaselt etcd-le.

Oleme hoolikalt valinud parameetri —size tähenduse, mis esindab kogu sisendi-output'i koormust fio-st. Meie puhul on see salvestusse kirjutatud baitide koguhulk. See osutus otse proportsionaalseks süsteemi süsteemikõnede kirjutamise (ja fdatasync) arvuga. Kindla bs väärtuse jaoks on fdatasync kõnede arv = size/bs. Kuna meid huvitas protsentil, pidi meil olema piisavalt näidiseid usaldusväärsuse tagamiseks, ja lugesime, et 10^4 (umbes 22 mebibaiti) peaks olema piisav. Kui —size on väiksem, võivad tekkida kõrvalekalded (näiteks võtab mõningate fdatasync kõnede töötlemine kauem aega ja mõjutab 99. protsentiili).

Proovige ise

Oleme näidanud, kuidas kasutada fio-d ja teada saada, kas salvestus on piisavalt kiire, et pakkuda kõrget jõudlust etcd jaoks. Nüüd saate seda ise praktikas proovida, kasutades näiteks SSD salvestustega virtuaalmasinaid. Valmis näidete kohta teiste ülesannete lahendamiseks saab tutvuda.

Allikas: habr.com