Trumpa istorija apie fio ir kt
Klasterio našumas labai priklauso nuo jo saugojimo našumo. etcd eksportuoja kai kurias metrikas į kad pateiktumėte reikiamą saugyklos našumo informaciją. Pavyzdžiui, metrika wal_fsync_duration_seconds. : kad saugojimas būtų pakankamai greitas, šios metrikos 99 procentilis turi būti mažesnis nei 10 ms. Jei planuojate paleisti etcd klasterį Linux įrenginiuose ir norite įvertinti, ar jūsų saugykla (pvz., SSD) yra pakankamai greita, galite yra populiarus įrankis I/O operacijoms tikrinti. Vykdykite šią komandą, kur test-data yra katalogas po saugyklos prijungimo tašku:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestJums tereikia pažvelgti į rezultatus ir patikrinti, ar 99-oji trukmės procentilis mažiau nei 10 ms. Jei taip, turite pakankamai greitą saugyklą. Štai rezultatų pavyzdys:
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]Pažymi,
- Mes pritaikėme parametrų -size ir -bs reikšmes mūsų konkrečiam scenarijui. Norėdami gauti naudingų fio rezultatų, įveskite savo vertes. Kur galiu juos gauti? Skaityti, .
- Bandymo metu visa įvesties / išvesties apkrova gaunama iš fio. Realiame scenarijuje gali būti, kad į saugyklą pateks ir kitų rašymo užklausų, nei susietos su wal_fsync_duration_seconds. Papildoma apkrova padidins wal_fsync_duration_seconds reikšmę. Taigi, jei 99 procentilis yra beveik 10 ms, jūsų saugykla nėra pakankamai greita.
- Paimkite versiją ne mažiau kaip 3.5 (ankstesniuose nerodomi fdatasync trukmės procentiliai).
- Aukščiau yra tik fio rezultatų fragmentas.
Ilga istorija apie fio ir kt
Kas yra WAL programoje etcd
Paprastai naudojamos duomenų bazės ; etcd taip pat jį naudoja. Čia išsamiai neaptarsime išankstinio įrašymo žurnalo (WAL). Mums pakanka žinoti, kad kiekvienas etcd klasterio narys palaiko jį nuolatinėje saugykloje. etcd įrašo kiekvieną operaciją su rakto-reikšmių poromis (pvz., atnaujinimą) į WAL, prieš taikydamas jas parduotuvėje. Jei vienas iš saugyklos narių užstringa ir paleidžiamas iš naujo tarp momentinių vaizdų, jis gali vietoje atkurti operacijas iš paskutinės momentinės nuotraukos, naudodamas WAL turinį.
Kai klientas prideda raktą į raktų verčių saugyklą arba atnaujina esamo rakto vertę, etcd įrašo šios operacijos įrašą į WAL, kuris yra įprastas failas nuolatinėje saugykloje. etcd PRIVALO būti visiškai įsitikinęs, kad WAL įrašymas iš tikrųjų įvyko prieš tęsiant apdorojimą. Linux sistemoje tam neužtenka vieno sistemos skambučio , nes iš tikrųjų rašymas į fizinę saugyklą gali užtrukti. Pavyzdžiui, „Linux“ gali laikinai saugoti WAL įrašą branduolio atminties talpykloje (pvz., puslapio talpykloje). O kad duomenys būtų tiksliai įrašyti į nuolatinę saugyklą, po įrašymo reikalingas sistemos iškvietimas fdatasync, o etcd tiesiog jį naudoja (kaip matyti iš darbo rezultatas , kur 8 yra WAL failo aprašas):
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>Deja, įrašymas į nuolatinę saugyklą nėra akimirksniu. Jei fdatasync skambutis lėtas, etcd sistemos veikimas pablogės. kad saugykla laikoma pakankamai greita, jei fdatasync iškvietimų 99 procentilis įrašomas į WAL failą užtrunka mažiau nei 10 ms. Yra ir kitų naudingų saugojimo metrikų, tačiau tai yra vienintelė metrika, apie kurią kalbame šiame įraše.
Saugojimo įvertinimas naudojant fio
Jei reikia įvertinti, ar jūsų saugykla tinka etcd, naudokite fio – labai populiarų I/O apkrovos testavimo įrankį. Reikėtų prisiminti, kad disko operacijos gali būti labai skirtingos: sinchroninės ir asinchroninės, daugybė sistemos skambučių klasių ir tt Dėl to fio yra gana sunku naudoti. Jis turi daug parametrų, o skirtingi jų reikšmių deriniai sukuria labai skirtingus įvesties / išvesties krūvius. Norėdami gauti tinkamus etcd skaičius, turėtumėte įsitikinti, kad bandomoji rašymo apkrova iš fio yra kuo artimesnė faktinei etcd įkrovai, kai rašote WAL failus.
Todėl fio turi bent sugeneruoti daugybę nuoseklių įrašų į failą, kiekvienas įrašymas susideda iš sistemos iškvietimo po kurio seka fdatasync sistemos iškvietimas. Nuosekliam fio rašymui reikalinga parinktis --rw=write. Taigi, kad fio rašydamas naudoja rašymo sistemos iškvietimą, o ne , verta nurodyti parametrą –ioengine=sync. Galiausiai, norėdami iškviesti fdatasync po kiekvieno rašymo, turite pridėti parinktį --fdatasync=1. Kitos dvi šio pavyzdžio parinktys (--size ir -bs) priklauso nuo scenarijaus. Kitame skyriuje parodysime, kaip juos nustatyti.
Kodėl fio ir kaip mes išmokome jį konfigūruoti
Šiame įraše aprašome tikrą atvejį. Turėjome klasterį v1.13, kurią stebėjome naudodami Prometheus. etcd v3.2.24 buvo talpinama SSD diske. Etcd metrika rodė per didelę fdatasync delsą, net kai klasteris nieko nedarė. Metrikos buvo keistos ir mes nelabai žinojome, ką jos reiškia. Klasterį sudarė virtualios mašinos, reikėjo suprasti, kokia problema: fiziniuose SSD ar virtualizacijos sluoksniuose. Be to, dažnai keisdavome aparatinės ir programinės įrangos konfigūracijas, todėl mums reikėjo būdo įvertinti jų rezultatus. Galime paleisti etcd kiekvienoje konfigūracijoje ir pažvelgti į Prometheus metriką, bet tai yra per daug vargo. Ieškojome gana paprasto būdo įvertinti konkrečią konfigūraciją. Norėjome patikrinti, ar teisingai supratome etcd Prometėjo metriką.
Tačiau tam reikėjo išspręsti dvi problemas. Pirma, kokia yra įvesties / išvesties apkrova, kurią etcd sukuria rašant į WAL? Kokie sistemos skambučiai naudojami? Kokio dydžio stulpeliai? Antra, jei atsakysime į šiuos klausimus, kaip galime atkurti panašų darbo krūvį naudojant fio? Nepamirškite, kad fio yra labai lanksti priemonė, turinti daugybę galimybių. Abi problemas išsprendėme vienu būdu – naudodami komandas и . lsof rodo visus proceso naudojamus failų aprašus ir su jais susijusius failus. O su strace galite ištirti jau vykdomą procesą arba pradėti procesą ir jį ištirti. strace spausdina visus sistemos iškvietimus iš tiriamo proceso (ir jo antrinių procesų). Pastarasis yra labai svarbus, nes etcd laikosi panašaus požiūrio.
Pirmas dalykas, kurį padarėme, buvo naudoti strace, norėdami ištirti etcd serverį, skirtą Kubernetes, kai klasteryje nebuvo apkrovos. Pamatėme, kad beveik visi WAL įrašai buvo maždaug tokio paties dydžio: 2200–2400 baitų. Todėl komandoje įrašo pradžioje nurodėme parametrą -bs=2300 (bs reiškia kiekvieno fio įrašo dydį baitais). Atminkite, kad etcd įrašo dydis priklauso nuo etcd versijos, pristatymo, parametrų reikšmių ir kt. ir turi įtakos fdatasync trukmei. Jei turite panašų scenarijų, patikrinkite etcd procesus naudodami strace, kad sužinotumėte tikslius skaičius.
Tada, norėdami gerai suprasti, ką daro etcd failų sistema, paleidome ją naudodami strace ir -ffttT parinktis. Taigi bandėme ištirti antrinius procesus ir įrašyti kiekvieno iš jų išvestį į atskirą failą, taip pat gauti išsamias ataskaitas apie kiekvieno sistemos skambučio pradžią ir trukmę. Naudojome lsof, kad patvirtintume strace išvesties analizę ir pamatytume, kuris failo deskriptorius kokiais tikslais buvo naudojamas. Taigi, naudodami strace, gavome aukščiau pateiktus rezultatus. Sinchronizavimo laiko statistika patvirtino, kad wal_fsync_duration_seconds metrika iš etcd atitinka fdatasync iškvietimus su WAL failų deskriptoriais.
Peržiūrėjome fio dokumentaciją ir pasirinkome savo scenarijaus parametrus, kad fio generuotų apkrovą, panašią į etcd. Taip pat patikrinome sistemos skambučius ir jų trukmę paleisdami fio iš strace, panašiai kaip etcd.
Mes kruopščiai pasirinkome parametro --size reikšmę, kuri atspindi visą fio įvesties / išvesties apkrovą. Mūsų atveju tai yra bendras į saugyklą įrašytų baitų skaičius. Paaiškėjo, kad tai yra tiesiogiai proporcinga rašymo (ir fdatasync) sistemos skambučių skaičiui. Esant tam tikrai bs reikšmei, iškvietimų į fdatasync skaičius = dydis/bs. Kadangi mus domino procentilis, turėjome turėti pakankamai pavyzdžių, kad būtų patikimi, ir paskaičiavome, kad mums pakaks 10^4 (tai yra 22 mebibaitai). Jei --size yra mažesnis, gali atsirasti nuokrypių (pavyzdžiui, keli fdatasync iškvietimai užtrunka ilgiau nei įprastai ir turi įtakos 99-ajam procentiliui).
Išbandykite save
Parodėme, kaip naudoti fio, ir išsiaiškinome, ar saugykla pakankamai greita, kad etcd veiktų gerai. Dabar galite tai išbandyti praktiškai patys, naudodami, pavyzdžiui, virtualias mašinas su SSD atmintimi .
Šaltinis: www.habr.com