🥇Kuidas fio abil kontrollida, kas kõvaketaste jõudlus on piisav etcd jaoks

Märkus tõlke kohta.: see artikkel on IBM Cloudi inseneride läbi viidud mini-uuringu tulemused, mille eesmärgiks oli leida lahendusi tõeliseks probleemiks, mis on seotud etcd andmebaasi haldamisega. Meile oli oluline sarnane ülesanne, kuid autorite mõtlemise ja tegutsemise käik võib olla huvitav ka laiemas kontekstis.

Kogu artikli lühike kokkuvõte: fio ja etcd

etcd klastrite jõudlus sõltub tugevalt põhihoiustamise kiirusest. Etcd eksportib erinevaid Prometheuse mõõdikuid jõudluse jälgimiseks. Üks neist on wal_fsync_duration_seconds. Etcd dokumentatsioonis öeldakse, et hoiust saab pidada piisavalt kiireks, kui selle mõõdiku 99. protsentiil ei ületa 10 ms…

Kui kaalute etcd klastri loomist Linuxi masinates ja soovite kontrollida, kas teie salvestid (nt SSD-d) on piisavalt kiired, soovitame kasutada populaarset I/O testimistööriista nimelt fio. Piisab, kui käivitate järgmise käsu (kaust test-data peab asuma testitava salvesti mountitud jaotises):

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

Jääb vaid vaadata väljundit ja kontrollida, kas 99. protsentiil fdatasync on 10 ms piires. Kui jah, siis toimib teie salvesti piisavalt kiiresti. Siin on näide väljundist:

fsync/fdatasync/sync_file_range:
  sync (mikrosekundites): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync protsentiilid (mikrosekundites):
   | 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õned märkused:

Ülaltoodud näites oleme seadistanud parameetrid --size ja --bs konkreetse juhtumi jaoks. Et saada sisutihedat tulemust fio, märkige väärtused, mis sobivad teie kasutusstsenaariumi jaoks. Kuidas neid valida, selgitatakse allpool.
Testimise ajal ainult fio koormab kettaalustust. Tegelikkuses on täiesti tõenäoline, et ketta kirjutavad ka muud protsessid (peale nende, mis on seotud wal_fsync_duration_seconds). Selline täiendav koormus võib põhjustada suurenenud wal_fsync_duration_seconds. Teisisõnu, kui 99. protsentiil, mis saadakse testimise tulemusena, on ainult veidi alla 10 ms, on tõenäosus, et salvesti jõudlus on ebapiisav. fioTestimiseks vajate versiooni
Testimiseks on teil vaja versiooni fio vähemalt 3.5, kuna varasemad versioonid ei kogu tulemusi fdatasync protsentides.
Ülaltoodud väljund on vaid väike osa kogu väljundist fio.

Üksikasjalikult fio ja etcd kohta

Mõned sõnad etcd WAL-ide kohta

Tavaliselt kasutavad andmebaasid ettejõudmist logimist (write-ahead logging, WAL). See kehtib ka etcd kohta. WAL-i arutelu ületab käesoleva artikli piirid, kuid meie eesmärkide jaoks on oluline teada, et iga etcd klastriliige salvestab WAL-i püsivasse mällu. etcd registreerib mõned toimingud key-value salvestuses (nt uuendused) WAL-is enne nende täitmist. Kui sõlm langeb ja taaskäivitub snapshotside vahel, suudab etcd taastada tehingud, mis on toimunud eelmisest snapshot'ist alates, tuginedes WAL-i sisule.

Seega, iga kord, kui klient lisab võtme KV-salvestusse või uuendab olemasoleva võtme väärtust, lisab etcd toimingu kirjelduse WAL-i, mis on tavaline fail püsivates mäludes. Enne töö jätkamist peab etcd olema 100% kindel, et WAL-i kirje on tõeliselt salvestatud. Selle saavutamiseks Linuxis ei piisa ainult süsteemi kutsest kirjutama, kuna kirjete füüsilise salvestamise toiming võib olla edasi lükatud. Näiteks võib Linux hoida WAL-kirjet mõnda aega tuuma mälus (nt lehekülje vahekaartides). Andmete salvestamise tagamiseks tuleb pärast salvestamist rakendada süsteemi kõnet fdatasync — just nii toimib etcd (nagu näha järgmise väljundi puhul strace; siin 8 — WAL-faili 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 võtab püsivasse mällu kirjutamine mõnda aega. Fdatasync-i kutse viibimisega võib olla negatiivne mõju etcd jõudlusele. Andmehoidla dokumentatsioonis töötatakse välja, et piisava jõudluse saavutamiseks peab 99. protsent kõikidest fdatasync WAL-faili kirjutamise ajal töötavast kestusest olema vähem kui 10 ms. On ka muid salvestusega seotud mõõdikuid, kuid selles artiklis keskendume just sellele.

Hindame andmehoidlat fio abil

Hinnata, kas mõni salvestus on sobiv etcd kasutamiseks, saab utiliidi abi kaudu fio — populaarne I/O testimise tööriist. Arvestage, et kettasisene I/O võib toimuda erinevalt: süntaktiline/asisüntaktiline, erinevad süsteemikõnede klassid jne. Tagasilöögi külg on selles, et fio see on äärmiselt keeruline kasutada. Utiliidil on palju parameetreid ja nende erinevad kombinatsioonid toovad kaasa täiesti erinevaid tulemusi. Et saada mõistlik hinnang etcd jaoks, peate veenduma, et fio genereeritud kirjutuskoormus sarnaneb maksimaalselt etcd koormusele WAL-failide kirjutamisel:

See tähendab, et genereeritud fio koormus peab vähemalt koosnema järjestikustest kirjutamisest failisse, kus igas kirjutusoperatsioonis on süsteemikõne kirjutama, millele järgneb fdatasync.
K järjestikuse kirjutamise aktiveerimiseks tuleb määrata lipp --rw=write.
Et fio kasutas süsteemikõnesid kirjutama (mitte muid süsteemikõnesid — näiteks, pwrite), kasutage lippu --ioengine=sync.
Lõpuks, lipp --fdatasync=1 tagab, et iga kirjutama pärast fdatasync.
Kaks muud parameetrit meie näites: --size ja --bs — võivad sõltuda konkreetsest kasutusstsenaariumist. Järgmises jaotises tutvustame nende seadistamist.

Miks valisime fio ja kust me teadsime, kuidas seda seadistada

See märkus tekkis reaalsest juhtumist, millega me silmitsi seisime. Meil oli klastri Kubernetes v1.13-ga, mille jälgimiseks kasutati Prometheust. Etcd v3.2.24 salvestamiseks kasutati tahkis-mälusid. Etcd mõõdikud näitasid liiga kõrgeid viivitusi fdatasync, isegi kui klaster ootas. Need mõõdikud tundusid meile kahtlased ja me ei olnud kindlad, mida need täpselt esindavad. Lisaks, klaster koosnes virtuaalmasinatest, seega ei olnud võimalik öelda, kas viivitused olid seotud virtualiseerimisega või oli süüdi SSD.

Lisaks sellele oleme uurinud erinevaid riist- ja tarkvarakonfiguratsioonimuudatusi, seega oli vajalik nende hindamise viis. Muidugi oleks olnud võimalik käivitada etcd igas konfiguratsioonis ja vaadata vastavaid Prometheuse mõõdikuid, kuid see nõuaks märkimisväärseid jõupingutusi. Me vajame lihtsat viisi, et hinnata konkreetset konfiguratsiooni. Soovisime kontrollida oma arusaama Prometheuse mõõdikutest, mis tulenevad etcd-st.

Selleks oli vaja lahendada kaks probleemi:

Esiteks, milline on I/O-koormus, mida etcd genereerib WAL-failidesse kirjutamisel? Milliseid süsteemikõnesid kasutatakse? Mis on kirjutamise plokkide suurus?
Teiseks, oletame, et meil on vastused ülaltoodud küsimustele. Kuidas luua vastav koormus fio? Ведь fio — äärmiselt paindlik utiliit, millel on palju parameetreid (seda on lihtne kontrollida, näiteks, siin — tõlke märk.).

Lahendasime mõlemad probleemid sama lähenemisega, tuginedes käskudele lsof ja strace:

EL-i abil lsof saame vaadata kõiki faili descriptor’e, mida protsess kasutab, samuti faile, millega nad on seotud.
EL-i abil strace saame analüüsida juba töötavat protsessi või käivitada protsessi ja seda jälgida. Käsk toob välja kõik süsteemikõned, mida antud protsess on teinud ja vajadusel ka tema järglased. Viimane on oluline forkivate protsesside jaoks, mille hulka kuulub ka etcd.

Esimene asi, mida tegime, oli kasutada strace Kubernetesi klastris etcd serveri uurimiseks, samal ajal kui see seisis.

Nii avastati, et WAL-i kirjutamisplokid on väga tihedalt grupeeritud, enamik nende suurust oli vahemikus 2200–2400 baiti. Täpselt sellepärast kasutatakse käskude alguses artiklis lippu --bs=2300 (bs — iga kirjutamisploki suurus baitides fio).

Pange tähele, et etcd kirjutamisplokkide suurus võib erineda sõltuvalt versioonist, juurutamisest, parameetrite väärtustest jne. — see mõjutab kestust fdatasync. Kui teil on sarnane kasutusstsenaarium, analüüsige strace oma etcd protsesse, et saada ajakohaseid väärtusi.

Seejärel, et saada selget ja kõikehõlmavat arusaama etcd tööst failisüsteemiga, käivitasime selle strace lippudega -ffttT. See võimaldas ulatuda alamprotsessidesse ja talletada igaühe väljundi eraldi faili. Lisaks saadi üksikasjalikud andmed iga systeemkõne alguse hetke ja kestuse kohta.

Kasutame ka käsku lsof, et kinnitada oma arusaama väljundist strace , mis puudutab, milline failideskriptor oli millekski kasutatud. Saime väljundi strace, mis sarnanes ülaltooduga. Statistilised manipulatsioonid sünkroonimisaegadega kinnitasid, et mõõdik wal_fsync_duration_seconds etcd-lt vastab kõnedele fdatasync failide WAL deskriptoritega.

Koormuse genereerimiseks, mis on sarnane etcd koormusega, uuriti tööriista dokumentatsiooni ja valiti parameetrid, mis sobivad meie ülesande jaoks. Veendusime, et kaasatud on vajalikud systeemkõned, ja kinnitasime nende kestuse, käivitades fio (nagu tehti etcd puhul). fio API-s strace Erilist tähelepanu pöörati parameetri

määramisele. See on fio tööriista genereeritud üldine I/O koormus. Meie puhul on see valjude baitide kogus, mis on kirjutatud mälumeediasse. See on otseselt proportsionaalne kõnede arvuga --size). Kindla kirjutama (ja fdatasynckõnede arvu bs on fdatasync size / bs Kuna meid huvitas protsentil, püüdsime veenduda, et proovide arv oleks piisavalt suur statistilise olulisuse jaoks. Otsustasime, et.

(mis vastab 22 MB suurusele) on piisav. Väiksemad parameetri väärtused 10^4 tootsid rohkem müra (nt kõned --size , mis võtavad palju rohkem aega kui tavaliselt, ja mõjutavad 99. percentiili). fdatasyncNüüd olete teinud oma töö

Artiklis kuvatakse, kuidas

võib hinnata, kas taustand on piisavalt kiire, et seda saaks kasutada etcd jaoks. Nüüd on teie kord! Uurige SSD põhiste salvestustega virtuaalmasinaid fio IBM Cloud Valmis näidete kohta teiste ülesannete lahendamiseks saab tutvuda.

P.S. tõlkijalt

või otse fio (seal on neid palju rohkem kui dokumentatsioonis). dokumentatsioon Märkus: see artikkel on IBM Cloudi inseneride väikese uuringu tulemused, et leida lahendusi päris probleemile, mis on seotud etcd andmebaasi haldamisega. projekti hoidlas 🥇Kuidas kontrollida fio abil, kas ketas on piisavalt jõudlusega etcd jaoks | ProHoster