🥇Kas salvestusruumi kiirus sobib etcd-le? Uurime fio abil

Lühike lugu fio ja etcd-st

Klastri jõudlus etcd sõltub suuresti salvestuse jõudlusest. etcd ekspordib mõned mõõdikud Prometheus, et anda vajalikku teavet salvestuse jõudluse kohta. Näiteks mõõdikut wal_fsync_duration_seconds. etcd dokumentatsioonis on öeldud: et salvestust peetakse piisavalt kiireks, peab selle mõõdiku 99. protsent olla alla 10 ms. Kui plaanite käivitada etcd klastrit Linuxi masinatel ja soovite hinnata, kas teie salvestus on piisavalt kiire (nt SSD), saate kasutada fio — populaarne tööriist sisendi-ja-väljundi operatsioonide testimiseks. Käivitage järgmine käsk, kus test-data on salvestuse ühenduspunkti kaust:

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

Peab lihtsalt vaatama tulemusi ja kontrollima, et 99. protsent mõõtmisest fdatasync on alla 10 ms. Kui jah, on teil piisavalt kiire salvestus. Siin on tulemuste näide:

  sünk (µs): min=534, max=15766, avg=1273,08, stdev=1084,70
  sünk protsentaažid (µs):
   | 1,00. [ 553], 5,00. [ 578], 10,00. [ 594], 20,00. [ 627],
   | 30,00. [ 709], 40,00. [ 750], 50,00. [ 783], 60,00. [ 1549],
   | 70,00. [ 1729], 80,00. [ 1991], 90,00. [ 2180], 95,00. [ 2278],
   | 99,00. [ 2376], 99,50. [ 9634], 99,90. [15795], 99,95. [15795],
   | 99,99. [15795]

Märkused

Me oleme seadistanud -size ja -bs väärtused meie konkreetse stsenaariumi jaoks. Fio kasulikku tulemust saamiseks märkige oma väärtused. Kust neid võtta? Loe edasi, kuidas me õppisime fio seadistama.
Testimise ajal tuleb kogu I/O koormus fio-st. Reaalses stsenaariumis saab ladustamisele tõenäoliselt ka muid kirjutamis-ehk päringute, välja arvatud need, mis on seotud wal_fsync_duration_seconds. Täiendav koormus suurendab wal_fsync_duration_seconds väärtust. Seega, kui 99. protsentili kohale peaaegu ulatub 10 ms, ei ole teie ladustamisel piisavalt kiirus.
Võtke versioon fio vähemalt 3.5 (eelnevad ei näita fdatasynci kestvuse protsente).
Ülaltoodud on ainult osa fio tulemustest.

Pikk lugu fio-st ja etcd-st

Mis on WAL etcd-s

Tavaliselt kasutavad andmebaasid eelmise kirje päevik; etcd kasutab ka seda. Siin ei aruta me kirjutamise etteheitevõtte (write-ahead log, WAL) päevikut üksikasjalikult. Meie jaoks on piisav teada, et iga etcd klastriliige salvestab seda püsivasse salvestusse. etcd salvestab iga võtme-väärtuse paari operatsiooni (näiteks värskenduse) WAL-i, enne kui rakendab need salvestuses. Kui ühe salvestuse liige ebaõnnestub ja taaskäivitub, saab ta WAL-i sisu järgi taastada tehingud alates viimase salvestuse hetkest.

Kui klient lisab võtme võtme-väärtuse salvestusse või värskendab olemasoleva võtme väärtust, teeb etcd selle toimingu WAL-i kirje, mis on tavaline fail püsivõttena. Enne töötlemise jätkumist peab etcd täielikult kinnitama, et WAL-i kirje tõesti toimus. Linuxis ei piisa selleks ühest süsteemikutsest. write, kuna tegelikult võib andmete kirjutamine füüsilisse salvestusse edasi lükata. Näiteks võib Linux mõnda aega hoida WAL-i kirjeid tuuma mälu (nt lehekülje vahemuudatuses) vahemäesis. Andmete kindel kirjutamine püsivasse salvestusse nõuab süsteemikutsungit fdatasync pärast kirjutamist, ja just seda kasutab etcd (nagu on näha tulemuste töötlemisel. strace, kus 8 — see on WAL-i failikuvandi deskriptor):

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 ei toimu andmete kirjutamine püsivasse salvestusse koheselt. Kui fdatasynci kutse töötab aeglaselt, väheneb süsteemi etcd jõudlus. Dokumendis etcd kohta öeldakse, et salvestust peetakse piisavalt kiireks, kui 99. protsendil fdatasynci kutsetest kirje tegemisel WAL-i failis kestab vähem kui 10 ms. On ka teisi kasulikke meetrikaid salvestuse jaoks, kuid selles postituses räägime ainult sellest meetrist.

Salvestuse hindamine fio abil

Kui peate hindama, kas teie salvestus sobib etcd-le, kasutage fio-t — väga populaarset sisend-väljund koormuse testimise tööriista. Tuleb meeles pidada, et kettaoperatsioonid võivad olla väga varieeruvad: sünkroonsed ja asünkroonsed, mitmesugused süsteemikutsed jne. Seetõttu on fio kasutamine üsna keeruline. Sellel on palju parameetreid, ja erinevad nende väärtuste kombinatsioonid annavad täiesti erinevaid sisend-väljundi koormusi. Adekaatsete numbrite saamiseks etcd-le tuleb veenduda, et fio kirjutamise testkoormus on võimalikult lähedane tegelikule koormusele jne kirjutamisel.

Seetõttu peaks fio vähemalt genereerima koormust järjestikuste kirjutamisoperatsioonide seeria näol, kus iga kirjutamine koosneb süsteemikutsest write, mille järel järgneb süsteemikutse fdatasync. Järjestikute kirjutamisoperatsioonide jaoks on fio-l vajalik parameeter —rw=write. Et fio kirjutamist tehes kasutaks süsteemikutset write, mitte pwrite, tuleb määrata parameeter —ioengine=sync. Lõpuks, et iga kirjutamise järel kutsuda esile fdatasync, tuleb lisada parameeter —fdatasync=1. Kaks muud parameetrit selles näites (—size ja —bs) sõltuvad konkreetsest stsenaariumist. Järgmises jaos räägime sellest, kuidas neid seadistada.

Miks fio ja kuidas me õppisime seda seadistama

Selles postituses kirjeldame tegelikku juhtumit. Meil oli klaster Kubernetes v1.13, mida jälgisime Prometheuse abil. etcd v3.2.24 oli paigaldatud SSD-le. etcd metrikad näitasid fdatasynci jaoks liiga kõrgeid viivitusi, isegi kui klaster midagi ei teinud. Metrikad olid veidrad ja me ei teadnud täpselt, mida need tähendavad. Klaster koosnes virtuaalmasinatest, pidi välja selgitama, kus on probleem: füüsilistes SSD-des või virtualiseerimiskihis. Lisaks tegime me sageli riistvara ja tarkvara konfiguratsioonis muudatusi ning vajasime viisi nende tulemuste hindamiseks. Saime käivitada etcd igas konfiguratsioonis ja vaadata Prometheuse metrikat, kuid see on liiga tülikas. Otsisime piisavalt lihtsat viisi konkreetse konfiguratsiooni hindamiseks. Soovisime kontrollida, kas arusaame Prometheuse metrikatest etcd-st on õige.

Kuid selleks tuli lahendada kaks probleemi. Esiteks, milline on sisendi- ja väljundi koormus, mida etcd genereerib WAL-i kirjutamisel? Milliseid süsteemikõnesid kasutatakse? Mis on kirje suurus? Teiseks, kui me saadame nendele küsimustele vastused, kuidas siis luua sarnast töökoormust fio abil? Ärge unustage, et fio on väga paindlik tööriist paljude seadistustega. Lahendasime mõlemad probleemid ühe lähenemisega - kasutades käske. lsof ja strace. lsof kuvab kõik failide descriptorid, mida protsess kasutab, ja seotud failid. Ja strace'i abil saab uurida juba käimasolevat protsessi või alustada protsessi ja seda uurida. strace väljastab kõik süsteemikõned uuritavast protsessist (ja selle alaprotsessidest). Viimane on väga oluline, kuna etcd kasutab just sellist lähenemist.

Esimese asjana kasutasime strace'i Kubernetes'e etcd-serveri uurimiseks, kui klastril polnud koormust. Nägime, et peaaegu kõik WAL-kirjed olid ligikaudu sama suurusega: 2200–2400 baiti. Seetõttu märkisime postituse alguses parameetri —bs=2300 (bs tähistab iga fio-kirje suurust baitides). Pange tähele, et etcd-kirje suurus sõltub etcd versioonist, tarnest, parameetrite väärtustest jne ning mõjutab fdatasync'i kestust. Kui teil on sarnane stsenaarium, uurige oma etcd-protsesse strace'i abil, et saada täpsed numbrid.

See, et etsee toimingutest failisüsteemis on selgem ülevaade, kui käivitame selle strace'iga ja parameetritega -ffttT. Nii püüdsime uurida alamprotsesse ja salvestada igaühe väljunde erinevasse faili ning saada üksikasjalikke aruandeid iga süsteemikõne algusest ja kestusest. Kasutasime lsof-i, et kinnitada strace'i väljundi analüüsi ja näha, milline failihaldur milleks kasutati. Nii saime strace'i abil tulemused, nagu ülal näidatud. Sünkroonimise ajastatistika kinnitas, et etcd wal_fsync_duration_seconds vastab fdatasync-kõnedele WAL-i failihalduritega.

Uurisin fio dokumentatsiooni ja valisime meie stsenaariumi jaoks parameetrid, et fio genereeriks koormuse, mis sarnaneb etcd-le. Samuti kontrollisime süsteemikõnesid ja nende kestust, käivitades fio strace'ist, nagu etcd puhul.

Oleme hoolikalt valinud parameetri väärtuse —size, mis kujutab kogu I/O koormust fio-st. Meie puhul on see üldine baitide arv, mis salvestatakse mälusesse. See osutus otseselt proportsionaalseks süsteemi kutsungite write (ja fdatasync) arvuga. Kindla bs väärtuse puhul on kutsungite fdatasync arv = size/bs. Kuna meid huvitas protsentiil, pidime saama piisavalt näiteid usaldusväärsuse tagamiseks, ja arvutasime, et 10^4 on piisav (see teeb 22 mebibaiti). Kui —size on väiksem, võivad tekkida kõrvalekalded (näiteks mõned fdatasync kutsungid võivad kesta kauem kui tavaliselt ja mõjutada 99. protsentiili).

Proovige ise

Oleme näidanud, kuidas kasutada fio-d ja teada saada, kas salvestusel on piisavalt kiirus kõrge jõudluse jaoks etcd jaoks. Nüüd saate proovida seda ise, kasutades näiteks SSD mäluseadmetega virtuaalseid masinaid IBM Cloudis. IBM Cloud.

Allikas: habr.com