🥇Kuidas kontrollida ketaste piisavat jõudlust etcd jaoks fio abil

Märge. tõlgeSee artikkel on IBM Cloudi inseneride läbiviidud mini-uuringu tulemus, mille eesmärk oli leida lahendus etcd andmebaasi toimimisega seotud tegelikule probleemile. Meie jaoks oli sarnane ülesanne asjakohane, kuid autorite mõttekäik ja tegevused võivad olla huvitavad laiemas kontekstis.

Kogu artikli lühikokkuvõte: fio ja jned

Etcd klastri jõudlus sõltub suuresti aluseks oleva salvestusruumi kiirusest. Jõudluse jälgimiseks ekspordib etcd mitmesuguseid Prometheuse mõõdikuid. Üks neist on wal_fsync_duration_secondsEtcd dokumentatsioonis see ütleb, seda salvestust võib pidada piisavalt kiireks, kui selle mõõdiku 99. protsentiil ei ületa 10 ms…

Kui kaalute etcd-klastri seadistamist Linuxi masinatele ja soovite kontrollida, kas teie salvestusseadmed (nt SSD-d) on piisavalt kiired, soovitame kasutada populaarset I/O-testrit nimega FiOPiisab järgmise käsu käivitamisest (kataloog test-data peab asuma testitava draivi paigaldatud partitsioonis):

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

Jääb üle vaid vaadata väljundit ja kontrollida, kas see vastab 99. protsentiilile. fdatasync 10 ms jooksul. Sellisel juhul on teie draiv piisavalt kiire. Siin on näide väljundist:

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]

Paar märkust:

Ülaltoodud näites oleme parameetreid kohandanud --size и --bs konkreetse juhtumi jaoks. Mõistliku tulemuse saamiseks fio, määrake oma kasutusjuhtumi jaoks sobivad väärtused. Nende valimist arutatakse allpool.
Ainult testimise ajal fio laadib ketta alamsüsteemi. Tegelikkuses on üsna tõenäoline, et kettale kirjutavad ka teised protsessid (lisaks neile, mis on seotud wal_fsync_duration_seconds). Selline lisakoormus võib suurendada wal_fsync_duration_secondsTeisisõnu, kui 99. protsentiil, mis saadi testimisel fio, vaid veidi alla 10 ms, on suur tõenäosus, et salvestusjõudlus on ebapiisav.
Testi jaoks vajate versiooni fio vähemalt 3.5, kuna vanemad versioonid ei koonda tulemusi fdatasync protsentiilide kujul.
Eelnev järeldus on vaid väike väljavõte üldisest järeldusest. fio.

Üksikasjad fio ja etcd kohta

Mõned sõnad etcd WAL-ide kohta

Tavaliselt kasutavad andmebaasid ennustav logimine (kirjutamise ettelogimine, WAL). See mõjutab ka etcd-d. WAL-i arutelu jääb selle artikli raamidest välja, kuid meie eesmärkide saavutamiseks peame teadma järgmist: iga etcd klastri liige salvestab WAL-i püsivasse mällu. etcd kirjutab mõned võtme-väärtuse salvest toimingud (näiteks värskendused) enne nende teostamist WAL-i. Kui sõlm jookseb kokku ja taaskäivitub hetktõmmiste vahel, saab etcd eelmisest hetktõmmisest alates tehtud tehingud WAL-i sisu põhjal rekonstrueerida.

Seega iga kord, kui klient lisab KV-salvestusse võtme või uuendab olemasoleva võtme väärtust, lisab etcd toimingu kirjelduse WAL-i, mis on püsisalvestuses tavaline fail. Enne jätkamist PEAB etcd olema 100% kindel, et WAL-i kirje tegelikult kirjutati. Selle saavutamiseks Linuxis ei piisa ainult funktsiooni kasutamisest. write, kuna tegelik kirjutamisoperatsioon füüsilisse salvestusruumi võib viibida. Näiteks võib Linux WAL-kirjet mõnda aega hoida kerneli vahemälus mälus (nt lehe vahemälus). Andmete salvestusruumi kirjutamise tagamiseks kasutab süsteemikutse fdatasync — just seda teebki etcd (nagu on näha järgmisest väljundist) straceSiin 8 — WAL-faili deskriptor):

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>

Kahjuks võtab püsimällu kirjutamine aega. Pikk fdatasync-kutse võib mõjutada etcd jõudlust. Salvestusruumi dokumentatsioon näidatud, et piisava jõudluse saavutamiseks on vajalik, et kõigi kõnede kestuse 99. protsentiil fdatasync WAL-faili kirjutamisel oli aeg alla 10 ms. Salvestusruumiga seotud näitajaid on ka teisi, kuid sellest me selles artiklis räägimegi.

Salvestusruumi hindamine fio abil

Saate hinnata, kas teatud salvestusruum sobib etcd-ga kasutamiseks, kasutades utiliiti FiO — populaarne I/O tester. Pea meeles, et ketta I/O saab toimuda erineval viisil: sünkroniseeritult/asünkroonselt, paljude erinevate süsteemikõnede klasside kaudu jne. Negatiivne külg on see, et fio on äärmiselt keeruline kasutada. Utiliidil on palju parameetreid ja nende väärtuste erinevad kombinatsioonid viivad täiesti erinevate tulemusteni. Mõistliku hinnangu saamiseks etcd puhul peaksite veenduma, et fio genereeritud kirjutuskoormus on WAL-failidesse kirjutamisel võimalikult lähedal etcd koormusele:

See tähendab, et genereeritud fio töökoormus peab olema vähemalt faili järjestikuste kirjutamiste seeria, kus iga kirjutamisoperatsioon koosneb süsteemikõnest writemillele järgnes fdatasync.
Järjestikuse kirjutamise lubamiseks peate määrama lipu --rw=write.
Et fio kirjutas kõnede abil write (ja mitte muud süsteemikõned - näiteks pwrite), kasutage lippu --ioengine=sync.
Lõpuks ometi lipp --fdatasync=1 tagab, et igaühe taga write peab olema fdatasync.
Meie näites on kaks ülejäänud parameetrit: --size и --bs — võivad olenevalt konkreetsest kasutusjuhtumist erineda. Järgmises osas kirjeldatakse nende konfigureerimist.

Miks me valisime fio ja kuidas me õppisime seda seadistama

See postitus pärineb reaalsest juhtumist, millega me kokku puutusime. Meil oli klaster Kubernetes v1.13 peal Prometheuse jälgimisega. SSD-sid kasutati etcd v3.2.24 salvestusruumina. Etcd mõõdikud näitasid liiga kõrgeid latentsusaegu. fdatasyncisegi siis, kui klaster oli jõudeolekus. Leidsime, et need mõõdikud olid üsna küsitavad ja me polnud kindlad, mida need esindasid. Lisaks koosnes klaster virtuaalmasinatest, seega ei saanud me öelda, kas latentsus oli tingitud virtualiseerimisest või olid süüdi SSD-d.

Samuti uurisime mitmesuguseid riist- ja tarkvarakonfiguratsioonide muudatusi, seega vajasime viisi nende hindamiseks. Muidugi saaksime iga konfiguratsiooni jaoks käivitada etcd ja vaadata vastavaid Prometheuse mõõdikuid, kuid see nõuaks palju pingutust. Vajasime lihtsat viisi konkreetse konfiguratsiooni hindamiseks. Tahtsime testida oma arusaama etcd-st pärinevatest Prometheuse mõõdikutest.

Selleks tuli lahendada kaks probleemi:

Esiteks, milline näeb välja etcd poolt genereeritud I/O koormus WAL-failidesse kirjutamisel? Milliseid süsteemikõnesid kasutatakse? Kui suured on kirjutamisplokid?
Teiseks, oletame, et meil on vastused ülaltoodud küsimustele. Kuidas vastavat koormust taasesitada fioLõppude lõpuks fio — äärmiselt paindlik ja paljude valikuvõimalustega utiliit (Seda saab kergesti kontrollida näiteks... siin - u. tõlge.).

Lahendasime mõlemad probleemid sama käsupõhise lähenemisviisi abil. lsof и strace:

Koos lsof Saate vaadata kõiki protsessi poolt kasutatavaid failikirjeldusi ja faile, millele need viitavad.
Koos strace Saate analüüsida juba töötavat protsessi või käivitada protsessi ja seda jälgida. Käsk prindib kõik protsessi tehtud süsteemikõned ja vajadusel ka selle järglased. Viimane on oluline protsesside jaoks, mis hargnevad, ja etcd on üks selline protsess.

Esimese asjana me kasutasime strace et uurida etcd serverit Kubernetes klastris selle jõudeoleku ajal.

Avastati, et WAL-kirjete plokid olid väga tihedalt rühmitatud, kusjuures enamik neist oli suuruses 2200–2400 baiti. Seetõttu kasutab selle artikli alguses olev käsk lippu --bs=2300 (bs — iga kirjeploki suurus baitides fio).

Pane tähele, et etcd kirjutusplokkide suurus võib varieeruda olenevalt versioonist, juurutusest, parameetrite väärtustest jne – see mõjutab kestust. fdatasyncKui teil on sarnane kasutusjuhtum, analüüsige seda strace teie etcd protsessid ajakohaste väärtuste saamiseks.

Seejärel, et saada selge ja terviklik pilt sellest, kuidas etcd failisüsteemiga töötab, käivitasime selle järgmiselt: strace lippudega -ffttTSee võimaldas meil jäädvustada tütarprotsessid ja kirjutada iga väljundi eraldi faili. Lisaks saadi üksikasjalikku teavet iga süsteemikõne algusaja ja kestuse kohta.

Kasutasime ka meeskonda lsofkinnitamaks oma arusaamist järeldusest strace selle järgi, millist failideskriptorit ja millisel eesmärgil kasutati. Väljund oli strace, sarnane ülaltoodule. Sünkroniseerimisaegade statistiline manipuleerimine kinnitas, et meetrika wal_fsync_duration_seconds etcd vastete kõned fdatasync WAL-failikirjeldajatega.

Genereerimiseks, kasutades fio töökoormuse tõttu, mis oli sarnane etcd-ga, uurisime utiliidi dokumentatsiooni ja valisime oma ülesande jaoks sobivad parameetrid. Veendusime, et vajalikud süsteemikõned olid kaasatud, ja kinnitasime nende kestuse käivitades fio kohta strace (nagu tehti jned puhul).

Erilist tähelepanu pöörati parameetri väärtuse määramisele --sizeSee esindab fio utiliidi tekitatud I/O kogukoormust. Meie puhul on see andmekandjale kirjutatud baitide koguarv. See on otseselt proportsionaalne kõnede arvuga. write (ja fdatasync). Teatud määral bs kõnede arv fdatasync võrdub size / bs.

Kuna meid huvitasid protsentiilid, tahtsime, et valimite arv oleks statistiliselt oluliseks piisavalt suur. Otsustasime, et 10^4 (mis vastab 22 MB suurusele) on piisav. Parameetri väiksemad väärtused --size tekitas selgemat müra (näiteks kõned fdatasync, mis võtavad tavapärasest palju kauem aega ja mõjutavad 99. protsentiili).

See on sinu teha

Artikkel näitab, kuidas kasutada fio saate hinnata, kas etcd-ga kasutamiseks mõeldud salvestusmeedia on piisavalt kiire. Nüüd on see teie otsustada! Teenuses saate uurida SSD-põhise salvestusruumiga virtuaalmasinaid. IBM Cloud.

PS tõlkijalt

Valmis kasutusnäidetega fio Teiste probleemide lahenduste kohta vaadake palun dokumentatsioon või otse projektihoidlad (neid on seal esitatud palju rohkem kui dokumentatsioonis mainitud).