🥇Kaip patikrinti, ar diskai su fio pakankamai veikia etcd

Pastaba. vert.: Šis straipsnis yra nedidelio tyrimo, kurį atliko IBM Cloud inžinieriai, ieškant sprendimo, kaip išspręsti tikrą problemą, susijusią su etcd duomenų bazės veikimu, rezultatai. Panaši užduotis buvo aktuali ir mums, tačiau autorių minčių ir veiksmų eiga gali būti įdomi platesniame kontekste.

Trumpa viso straipsnio santrauka: fio ir kt

etcd klasterio našumas labai priklauso nuo pagrindinės saugyklos greičio. Norėdami stebėti našumą, etcd eksportuoja įvairias Prometheus metrikas. Vienas iš jų yra wal_fsync_duration_seconds. etcd dokumentacijoje tai sako, ta saugykla gali būti laikoma pakankamai greita, jei šios metrikos 99 procentilis neviršija 10 ms...

Jei ketinate sukurti etcd klasterį „Linux“ įrenginiuose ir norite patikrinti, ar saugojimo įrenginiai (pvz., SSD) yra pakankamai greiti, rekomenduojame naudoti populiarų įvesties / išvesties testerį, vadinamą fio. Tiesiog paleiskite šią komandą (katalogas test-data turi būti sumontuotoje bandomojo disko skirsnyje):

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

Belieka pažvelgti į išvestį ir patikrinti, ar ji atitinka 99 procentilį fdatasync per 10 ms. Jei taip, tada jūsų važiavimas yra pakankamai greitas. Čia yra išvesties pavyzdys:

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]

Keletas pastabų:

Aukščiau pateiktame pavyzdyje mes pakoregavome parametrus --size и --bs konkrečiam atvejui. Norėdami gauti reikšmingų rezultatų iš fio, nurodykite reikšmes, kurios tinka jūsų naudojimo atvejui. Kaip juos pasirinkti, bus aptarta toliau.
Tik bandymo metu fio įkelia disko posistemį. Realiame gyvenime tikėtina, kad kiti procesai (be tų, kurie susiję su wal_fsync_duration_seconds). Tokia papildoma apkrova gali padidinti wal_fsync_duration_seconds. Kitaip tariant, jei 99 procentilis gautas išbandžius su fio, tik šiek tiek mažiau nei 10 ms, yra didelė tikimybė, kad saugojimo našumas yra nepakankamas.
Testui jums reikės versijos fio ne mažiau kaip 3.5, nes senesnėse versijose rezultatai neapibendrinami fdatasync procentilių pavidalu.
Pirmiau pateikta išvada yra tik nedidelė bendros išvados ištrauka fio.

Išsami informacija apie fio ir kt

Keletas žodžių apie WAL ir kt

Paprastai naudojamos duomenų bazės aktyvus medienos ruoša (išankstinis registravimas, WAL). etcd tai taip pat taikoma. WAL aptarimas nepatenka į šio straipsnio taikymo sritį, tačiau mūsų tikslams reikia žinoti, ką reikia žinoti: Kiekvienas etcd klasterio narys WAL saugo nuolatinėje saugykloje. etcd į WAL įrašo kai kurias raktų verčių saugojimo operacijas (pvz., atnaujinimus), prieš jas vykdydamas. Jei mazgas sugenda ir paleidžiamas iš naujo tarp momentinių vaizdų, etcd gali atkurti operacijas, atliktas nuo ankstesnės momentinės nuotraukos, remiantis WAL turiniu.

Taigi kiekvieną kartą, kai klientas prideda raktą į KV saugyklą arba atnaujina esamo rakto vertę, etcd prideda operacijos aprašymą prie WAL, kuris yra įprastas failas nuolatinėje saugykloje. etcd PRIVALO būti 100% įsitikinęs, kad WAL įrašas iš tikrųjų išsaugotas prieš tęsiant. Norint tai pasiekti Linux sistemoje, neužtenka naudoti sistemos skambučio write, nes pati įrašymo į fizinę laikmeną operacija gali būti atidėta. Pavyzdžiui, Linux gali kurį laiką laikyti WAL įrašą branduolio talpykloje atmintyje (pvz., puslapio talpykloje). Siekiant užtikrinti, kad duomenys būtų įrašyti į laikmeną, po įrašymo turi būti iškviestas sistemos iškvietimas fdatasync - kaip tik tai daro etcd (kaip matyti toliau pateiktoje išvestyje strace; Čia 8 - WAL failų rankena):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Deja, rašymas į nuolatinę saugyklą užtrunka šiek tiek laiko. Ilgai trunkantis fdatasync skambutis gali turėti įtakos etcd našumui. Saugyklos dokumentacijoje nurodytaskad pakankamam našumui būtina, kad visų skambučių trukmės 99 procentilė fdatasync rašant į failą WAL buvo mažiau nei 10 ms. Yra ir kitų su saugykla susijusių metrikų, tačiau šiame straipsnyje daugiausia dėmesio bus skiriama šiam.

Saugyklos įvertinimas naudojant fio

Galite įvertinti, ar tam tikra saugykla tinkama naudoti su etcd, naudodamiesi programa fio - populiarus I/O testeris. Atminkite, kad disko įvestis / išvestis gali vykti įvairiais būdais: sinchronizavimas / asinchronizavimas, daugybė skirtingų sistemos skambučių klasių ir kt. Kita medalio pusė yra ta fio itin sunku naudoti. Naudingumas turi daug parametrų, o skirtingi jų verčių deriniai duoda visiškai skirtingus rezultatus. Norėdami gauti pagrįstą etcd įvertinimą, turite užtikrinti, kad fio sugeneruota rašymo apkrova būtų kuo panašesnė į etcd įrašymo apkrovą į WAL failus:

Tai reiškia, kad sukurta fio darbo krūvis turi būti bent jau eilė nuoseklių įrašų į failą, kur kiekviena rašymo operacija susideda iš sistemos iškvietimo writesekė fdatasync.
Norėdami įjungti nuoseklų įrašymą, turite nurodyti vėliavėlę --rw=write.
Kad fio rašė skambučiais write (o ne kiti sistemos iškvietimai, pvz., pwrite), naudokite vėliavėlę --ioengine=sync.
Galiausiai vėliava --fdatasync=1 garantuoja, kad už kiekvieną write turėtų fdatasync.
Du kiti parametrai mūsų pavyzdyje: --size и --bs - gali skirtis priklausomai nuo konkretaus naudojimo atvejo. Kitame skyriuje bus aprašyta, kaip juos konfigūruoti.

Kodėl pasirinkome fio ir kaip išmokome jį nustatyti

Ši pastaba kilusi iš tikro atvejo, su kuriuo susidūrėme. Turėjome Kubernetes v1.13 klasterį su stebėjimu Prometheus. Kietojo kūno diskai buvo naudojami kaip etcd v3.2.24 saugykla. etcd metrika parodė per didelę delsą fdatasync, net kai grupė buvo neaktyvi. Mes nustatėme, kad šios metrikos yra labai abejotinos ir nebuvome tikri, ką jie reiškia. Be to, klasterį sudarė virtualios mašinos, todėl nebuvo įmanoma pasakyti, ar vėlavimas įvyko dėl virtualizacijos, ar dėl to kalti SSD.

Be to, ieškojome įvairių techninės ir programinės įrangos konfigūracijų pakeitimų, todėl mums reikėjo būdo juos įvertinti. Žinoma, kiekvienoje konfigūracijoje būtų galima paleisti etcd ir pažiūrėti atitinkamas Prometheus metrikas, tačiau tam reikėtų didelių pastangų. Mums reikėjo paprasto būdo įvertinti konkrečią konfigūraciją. Norėjome patikrinti savo supratimą apie Prometheus metriką, gaunamą iš etcd.

Norint tai padaryti, reikėjo išspręsti dvi problemas:

Pirma, kaip atrodo įvesties / išvesties apkrova, kurią etcd generuoja rašant į WAL failus? Kokie sistemos skambučiai naudojami? Koks yra rašymo bloko dydis?
Antra, tarkime, kad turime atsakymus į aukščiau pateiktus klausimus. Kaip atkurti atitinkamą apkrovą su fio? Po visko fio - ypač lankstus įrankis su daugybe parametrų (tai nesunku patikrinti, pvz. čia - apytiksliai vertimas.).

Abi problemas išsprendėme naudodami tą patį komandomis pagrįstą metodą lsof и strace:

naudojant lsof Galite peržiūrėti visus proceso naudojamus failų aprašus, taip pat failus, į kuriuos jie nurodo.
naudojant strace galite analizuoti jau vykdomą procesą arba paleisti procesą ir jį stebėti. Komanda rodo visus šio proceso atliktus sistemos iškvietimus ir, pasirinktinai, jo palikuonis. Pastarasis yra svarbus procesams, kurie yra išsišakoję, o etcd yra vienas iš tokių procesų.

Pirmas dalykas, kurį padarėme, buvo naudoti strace ištirti etcd serverį Kubernetes klasteryje, kai jis buvo neaktyvus.

Taigi buvo nustatyta, kad WAL rašymo blokai yra labai tankiai sugrupuoti, dauguma jų yra 2200–2400 baitų diapazone. Štai kodėl šio straipsnio pradžioje esanti komanda naudoja vėliavėlę --bs=2300 (bs — kiekvieno įrašymo bloko dydis baitais fio).

Atminkite, kad etcd rašymo blokų dydžiai gali skirtis priklausomai nuo versijos, diegimo, parametrų reikšmių ir kt. - tai turi įtakos trukmei fdatasync. Jei turite panašų naudojimo atvejį, analizuokite su strace savo etcd procesus, kad gautumėte naujausias reikšmes.

Tada, norėdami aiškiai ir visapusiškai suprasti, kaip etcd veikia su failų sistema, paleidome ją iš apačios strace su vėliavėlėmis -ffttT. Tai leido užfiksuoti antrinius procesus ir įrašyti kiekvieno išvestį į atskirą failą. Be to, buvo gauta išsami informacija apie kiekvieno sistemos skambučio pradžios momentą ir trukmę.

Mes taip pat naudojome komandą lsofkad patvirtintumėte savo supratimą apie išvestį strace pagal tai, koks failo deskriptorius kokiu tikslu buvo naudojamas. Rezultatas buvo strace, panašus į aukščiau pateiktą. Statistinės manipuliacijos su sinchronizacijos laikais patvirtino, kad metrika wal_fsync_duration_seconds iš etcd atitinka skambučius fdatasync su WAL failų deskriptoriais.

Norėdami sukurti naudojant fio darbo krūvis panašus į krūvį iš etcd, buvo išnagrinėta komunalinių paslaugų dokumentacija ir parinkti mūsų užduočiai tinkami parametrai. Įsitikinome, kad buvo įtraukti teisingi sistemos skambučiai ir patvirtinome jų trukmę paleisdami fio iš strace (kaip buvo padaryta etcd atveju).

Ypatingas dėmesys buvo skiriamas parametro reikšmės nustatymui --size. Tai rodo bendrą įvesties / išvesties apkrovą, sugeneruotą fio paslaugų programos. Mūsų atveju tai yra bendras į laikmeną įrašytų baitų skaičius. Jis yra tiesiogiai proporcingas skambučių skaičiui write (ir fdatasync). Tam tikram bs skambučių skaičius fdatasync lygus size / bs.

Kadangi mus domino procentilis, siekėme užtikrinti, kad imčių skaičius būtų pakankamai didelis statistiniam reikšmingumui. Ir jie taip nusprendė 10^4 (kuris atitinka 22 MB dydį) pakaks. Mažesnės parametrų reikšmės --size sukėlė ryškesnį triukšmą (pavyzdžiui, skambučius). fdatasync, kurie užtrunka daug ilgiau nei įprastai ir turi įtakos 99 procentiliui).

Viskas priklauso nuo tavęs

Straipsnyje parodyta, kaip naudoti fio galite įvertinti, ar laikmena, skirta naudoti su etcd, yra pakankamai greita. Dabar tai priklauso nuo jūsų! Paslaugoje galite naršyti virtualias mašinas su SSD saugykla "IBM Cloud".

PS iš vertėjo

Su paruoštais naudojimo pavyzdžiais fio Norėdami išspręsti kitas problemas, galite rasti dokumentacija arba tiesiai į projektų saugyklos (jų ten daug daugiau, nei nurodyta dokumentacijoje).

PPS iš vertėjo

Taip pat skaitykite mūsų tinklaraštyje:

Šaltinis: www.habr.com

Kaip patikrinti, ar diskai su fio yra pakankami etcd