🥇Kuidas fio abil kontrollida, kas kettad on piisava jõudlusega etcd jaoks

Märk. tõlge.: see artikkel on IBM Cloudi inseneride mini-uuringute kokkuvõte, mille eesmärk oli leida tegelik lahendus, mis on seotud etcd andmebaasi haldamise probleemidega. Meil oli sarnane ülesanne, kuid autorite mõtlemisprotsess ja tegevused võivad olla huvitavad laiemas kontekstis.

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

etcd klastrite jõudlus sõltub tugevalt nende aluseks oleva salvestusruumi kiirusest. etcd jälgib oma jõudlust, eksportides erinevaid Prometheuse meetrikaid. Üks neist on wal_fsync_duration_seconds. etcd dokumentatsioonis ütleb, et salvestusruumi võib pidada piisavalt kiireks, kui selle meetrika 99. protsentiil ei ületa 10 ms…

Kui mõtlete etcd klastri korraldamisele Linuxiga masinatel ja soovite kontrollida, kas salvestid on piisavalt kiired (nt SSD), soovitame kasutada populaarsest I/O testijast nimega fio. Piisab, kui käivitate järgmise käsu (kaust test-data peab olema paigaldatud testitava salvesti jaotises):

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

Jäänud on vaid vaadata väljundit ja kontrollida, kas 99. persentiil mahub 10 ms sisse. fdatasync Kui jah, siis tähendab see, et teie salvestusseade töötab piisavalt kiiresti. Siin on väljundi näide:

fsync/fdatasync/sync_file_range:
  sync (mikrosekundites): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync persentiilid (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 kohandasime parameetreid --size ja --bs konkreetse juhtumi jaoks. Et saada sisukat tulemust fio, määrake väärtused, mis sobivad teie kasutusstsenaariumile. Kuidas neid valida, selgitatakse allpool.
Testimise ajal fio koormab ainult kettaalajärje. Reaalses elus on tõenäoline, et ketast kirjutavad ka teised protsessid (välja arvatud need, mis on seotud wal_fsync_duration_seconds). Tüüpiline lisakoormus võib põhjustada kasvu wal_fsync_duration_seconds. Teisisõnu, kui 99. persentiil, mis saadi testi tulemusena fio, on vaid veidi alla 10 ms, on suur tõenäosus, et andmete salvestamise jõudlus on ebapiisav.
Testimiseks on vajalik versioon fio vähemalt 3.5, kuna vanemad versioonid ei koonda tulemusi fdatasync protsentiilide kujul.
Ülaltoodud väljund on vaid väike osa kogu väljundist fio.

Rohkem infot fio ja etcd kohta

Mõned sõnad etcd WAL-ide kohta

Tavaliselt kasutavad andmebaasid ettejõudvat logimist (write-ahead logging, WAL). See kehtib ka etcd kohta. WAL-i arutelu ületab selle artikli raamid, kuid meie eesmärkide jaoks on oluline teada järgmist: iga etcd-klastri liige salvestab WAL-i püsivasse salvestusse. etcd registreerib teatud operatsioonid võtme-väärtuse salvestuses (nt uuendused) WAL-is enne nende täitmist. Kui sõlm ebaõnnestub ja taaskäivitub snapshot’ide vahel, suudab etcd taastada tehingud, mis tehti alates eelmisest snapshot'ist, tuginedes WAL-sisaldusele.

Seega, iga kord, kui klient lisab võtme KV-hoidmisse või uuendab olemasoleva võtme väärtust, lisab etcd operatsiooni kirjelduse WAL-i, mis on tavaline fail püsivas salvestuses. Enne jätkamist peab etcd olema 100% kindel, et kirje WAL-i on tõeliselt salvestatud. Selle saavutamiseks Linuxis ei piisa süsteemi kutsest. write, kuna füüsilise meedia kirjutamise operatsioon võib olla edasi lükatud. Näiteks võib Linux mõneks ajaks hoida WAL-i kirje tuuma mälus (nt leheküljekus). Andmete salvestamise tagamiseks tuleb pärast kirjutamist kasutada süsteemikutsest. fdatasync — just nii käitub etcd (nagu näha järgmise väljundi näitel strace; siin 8 — WAL-i failihalduri 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 salvestusse kirjutamine aega. Veniv fdatasynci kutsumine võib mõjutada etcd jõudlust. Hoiustamise dokumentatsioonis näidatakse, et see, et piisava jõudluse tagamiseks peab kõikide kutsungite kestuse 99. protsent olema fdatasync WAL-faili kirjutamisel vähem kui 10 ms. On ka teisi salvestusseotud mõõdikuid, kuid selles artiklis räägime täpselt sellest.

Hindame salvestust kasutades fio

Salvestuse sobivuse hindamiseks etcd-ga saab kasutada utiliiti fio — populaarne I/O testija. Pidage meeles, et kettasisend- ja -väljund võib töötada erinevalt: sync/async, suur hulk erinevaid süsteemi kutsungeid jne. Mündi teine külg on see, et fio see on äärmiselt raske kasutada. Utiliidil on palju parameetreid ja erinevad nende väärtuste kombinatsioonid toovad kaasa täiesti erinevad tulemused. Et saada mõistlikku hinnangut etcd puhul, peate veenduma, et fio genereeritav kirjutuskoormus sarnaneb maksimaalselt etcd koormusega WAL-failide kirjutamisel:

See tähendab, et genereeritud fio koormus peab vähemalt koosnema järjestikuste kirjetest failis, kus iga kirjutamistoiming koosneb süsteemi kutsungist write, millele järgneb fdatasync.
Järjestelmäkirjoituksen aktivoimiseksi on osoitettava lippu --rw=write.
Et fio kirjoitti kutsujen avulla write (eikä muiden järjestelmäkutsujen — esimerkiksi pwrite), käytä lippua --ioengine=sync.
Lopuksi, lippu --fdatasync=1 takaa, että jokaisen write tuleks fdatasync.
Kaksi muuta parametreista esimerkissämme: --size ja --bs — voivat vaihdella riippuen käytön erityistä skenaariota. Seuraavassa osiossa käsitellään niiden konfigurointia.

Miksi valitsimme fion ja mistä oppimme sen konfiguroimaan

Tämä muistiinpano syntyi todellisesta tapauksesta, jonka kanssa kohtasimme. Meillä oli klusteri Kubernetes v1.13:ssa, jossa monitorointi tapahtui Prometheuksen avulla. Varastona toimi SSD:t etcd v3.2.24:lle. etcd-metriikat näyttivät liian suuria viiveitä fdatasync, vaikka klusteri oli passiivinen. Meidän mielestämme nämä mittarit olivat varsin kyseenalaisia, emmekä olleet varmoja siitä, mitä ne todellisuudessa edustavat. Lisäksi klusteri koostui virtuaalikoneista, joten ei ollut selvää, oliko viive virtuaalisoinnin syytä vai oliko SSD:llä osuutensa.

Lisaks sellele arutasime erinevaid riist- ja tarkvarakonfiguratsiooni muutusi, seega oli vajalik nende hindamise meetod. Loomulikult oleks võinud käivitada etcd iga konfiguratsiooni puhul ja vaadata vastavaid Prometheuse mõõdikuid, kuid see tooks endaga kaasa märkimisväärseid jõupingutusi. Meile oli vajalik lihtne meetod, mis võimaldaks hinnata konkreetset konfiguratsiooni. Soovisime kontrollida oma arusaamist Prometheuse mõõdikest, mis pärinevad etcd-st.

Selleks tuli lahendada kaks probleemi:

Esiteks, millisena näeb välja I/O-koormus, mida etcd genereerib WAL-failide kirjutamise ajal? Milliseid süsteemikõnesid kasutatakse? Mis on kirjutamiste blokkide suurus?
Teiseks, oletame, et meil on vastused eeltoodud küsimustele. Kuidas reproduktsiooni vastava koormusega fio? Ведь fio — äärmiselt paindlik utiliit, millel on palju parameetreid (seda on lihtne veenduda, näiteks siit — tõlke märk.).

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

Käesoleva abil lsof saab vaadata kõiki failideskirid, mida protsess kasutab, ning faile, millega nad on seotud.
Käesoleva abil strace saab analüüsida juba käimasolevat protsessi või alustada protsessi ja jälgida seda. Käsk printsib välja kõik süsteemi kõned, mis on tehtud antud protsessi ja vajadusel tema järeltulijate poolt. Viimane on oluline protsesside jaoks, mis forkivad, ja etcd on üks selline protsess.

Esimene asi, mida me tegime, oli kasutada strace et uurida etcd serverit Kubernetes klastris, kui see seisis.

Nii avastasime, et WAL-i kirjutamisplokid on väga tihedalt grupeeritud, enamik nende suurust oli vahemikus 2200-2400 baiti. Just seetõttu kasutame käskudes selle artikli alguses lippu --bs=2300 (bs - on iga kirjutamisploki suurus baitides fio).

Pange tähele, et etcd kirjutamisplokkide suurus võib varieeruda sõltuvalt versioonist, juurutamisest, parameetrite väärtustest jne - see mõjutab kestvust fdatasync. Kui teil on sarnane kasutusstsenaarium, analüüsige läbi strace oma etcd protsessid, et saada ajakohaseid väärtusi.

Seejärel, et saada selget ja põhjalikku ülevaadet etcd toimimisest failisüsteemiga, käivitasime selle strace lipu -ffttT. See võimaldas hõlmata alamprotsesse ja salvestada igaühe väljundi eraldi faili. Samuti saadi üksikasjalikud andmed iga süsteemikõne algushetke ja kestuse kohta.

Kasutasime ka käsku lsof, et kinnitada oma arusaama väljundist strace selle osas, milline failikirjeldaja milliseks otstarbeks kasutati. Tulemuseks oli väljund strace, mis sarnanes eespool toodud omaga. Statistilised manipulatsioonid sünkroniseerimisajaga kinnitasid, et wal_fsync_duration_seconds etcd metrika vastab fdatasync WAL failikirjeldajatele.

Selleks, et genereerida fio töökoormus, mis sarnaneb etcd töökoormusega, uuriti utiliidi dokumentatsiooni ja valiti meie ülesandele sobivad parameetrid. Veendusime, et vajalikud süsteemikõned on kaasatud ja kinnitasime nende kestvuse, käivitades fio kohast strace (nagu see tehti etcd puhul).

Eriti tähelepanu pöörati parameetri väärtuse määramisele --size. See tähistab utiliidi fio genereeritud kogulaste I/O koormust. Meie puhul on see baithulk, mis on salvestatud kõvakettale. See on otseselt proportsionaalne kõnede arvuga write (ja fdatasync). Teatud bs kõnede arv fdatasync on võrdne suurus / bs.

Kuna meid huvitas protsentiil, soovisime, et proovide arv oleks piisavalt suur statistilise tähtsuse saavutamiseks. Ja otsustasime, et 10^4 (mis vastab suurusele 22 MB) on piisav. Väiksemad väärtused parameetrile --size andis rohkem väljendunud müra (näiteks kõned fdatasync, mis võtavad tavaliselt palju rohkem aega ja mõjutavad 99. protsentiili).

Otsus on sinu

Artiklis näidatakse, kuidas abil fio saab hinnata, kas salvestus, mis on mõeldud kasutamiseks etcd-ga, on piisavalt kiire. Nüüd on sinu kord! Uurige SSD-põhiste salvestustega virtuaalmasinaid teenuses IBM Cloud.

P.S. tõlkija märkused

Valmis kasutamise näidistega fio võib tutvuda muude ülesannete lahendamiseks dokumentatsioonis või otse projekti repos (seal on neid palju rohkem, kui dokumentatsioonis mainitakse).