🥇Hogyan használjuk a fio-t a diszkek teljesítményének ellenőrzésére az etcd-hez

Megjegyzés fordítás.: ez a cikk az IBM Cloud mérnökei által végzett kis kutatás összegzése, amely egy valós probléma megoldását kereste, amely az etcd adatbázis üzemeltetésével kapcsolatos. Számunkra is aktuális volt egy hasonló feladat, de a szerzők gondolatmenete és cselekedetei más tágabb összefüggésben is érdekesek lehetnek.

A cikk összefoglalója: fio és etcd

Az etcd klaszter teljesítménye jelentősen függ az alapjául szolgáló tároló sebességétől. Az etcd különböző Prometheus metrikákat exportál a teljesítmény ellenőrzésére. Az egyik ezek közül a wal_fsync_duration_seconds. Az etcd dokumentációjában az áll, hogy a tároló akkor tekinthető elég gyorsnak, ha ennek a metrikának a 99. percentilje nem haladja meg a 10 ms-t…

Ha fontolóra veszi egy etcd klaszter létrehozását Linuxot futtató gépeken, és szeretné ellenőrizni, hogy elegendően gyorsak-e a tárolók (például SSD), akkor ajánljuk a népszerű I/O tesztelő programot, amelyet fio. Csak annyit kell tennie, hogy futtatja a következő parancsot (a test-data közvetlenül a tesztelt tároló csatolt mappájában kell elhelyezkednie):

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

Most már csak a kimenetet kell megnézni, és ellenőrizni, hogy a 99. percentilje fdatasync 10 ms-en belül van-e. Ha igen, akkor a tárolója elég gyorsan működik. Íme egy példakimenet:

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]

Néhány megjegyzés:

A fenti példában a paramétereket --size és --bs az adott esetre állítottuk be. Ahhoz, hogy tartalmas eredményt kapjunk, a fio, meg kell adnia olyan értékeket, amelyek megfelelnek az ön felhasználási forgatókönyvének. Arról, hogyan válassza ki őket, lentebb beszélünk.
A tesztelés során csak fio terheli a tárolórendszert. A valóságban valószínű, hogy a lemezre más folyamatok is írnak (a wal_fsync_duration_secondskivételével). Az ilyen extra terhelés növelheti a wal_fsync_duration_seconds. Más szóval, ha a tesztelési eredmények szerint a 99. percentilja a fiocsak egy kicsivel kevesebb, mint 10 ms, akkor nagy a valószínűsége, hogy a tároló teljesítménye nem elegendő.
A teszteléshez szüksége lesz egy verzióra fio nem lehet kevesebb, mint 3,5, mivel a régebbi verziók nem aggregálják az eredményeket fdatasync százalékos értékek formájában.
A fenti kimenet csupán egy kis részlete az összes kimenetnek fio.

Részletesen a fio-ról és az etcd-ről

Néhány szó az etcd WAL-járól

Általában az adatbázisok használják előrejelző naplózást (write-ahead logging, WAL). Az etcd-re is vonatkozik. A WAL-ról való vitát meghaladja ennek a cikknek a kerete, de a mi céljainkhoz elegendő tudni, hogy az etcd klaszter minden tagja WAL-t tárol egy tartós tárolóban. Az etcd néhány műveletet (pl. frissítéseket) naplóz a WAL-ba, mielőtt végrehajtaná őket. Ha egy csomópont lezuhan és újraindul a snapshotok között, az etcd képes visszaállítani a korábbi snapshot óta végrehajtott tranzakciókat a WAL tartalmának alapján.

Tehát minden alkalommal, amikor a kliens egy kulcsot ad hozzá a KV-tárolóhoz vagy frissíti egy meglévő kulcs értékét, az etcd egy műveleti leírást ad hozzá a WAL-hoz, amely egy normál fájl a tartós tárolóban. Az etcd-nek 100%-ig biztosnak kell lennie abban, hogy a WAL-ba való írás valóban megtörtént. Ehhez Linux alatt nem elegendő egyszerűen a rendszerhívás használata write, mivel a fizikai tárolóra való írás művelete késlekedhet. Például a Linux egy ideig a WAL írást a kernel memóriájában képes tartani (pl. a lapcache-ben). Annak biztosításához, hogy az adatok ténylegesen a tárolón vannak, írás után rendszerhívást kell végrehajtani fdatasync — pontosan így jár el az etcd (ahogy a következő kimenet példája is mutatja strace; itt 8 — a WAL fájl leírója):

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

Sajnos a tartós tárolóra való írás időt vesz igénybe. A fdatasync hívásának elhúzódása befolyásolhatja az etcd teljesítményét. A tároló dokumentációja szerint meg van határozva, ahhoz, hogy elegendő teljesítményű legyen, a WAL fájlba való írás minden hívásának 99. percentilje kevesebb legyen, mint 10 ms. Vannak más métrikák is, amelyek a tárolóhoz kapcsolódnak, de ebben a cikkben ez lesz a téma. fdatasync A tároló értékelése a fio segítségével

Megállapítani, hogy egy adott tároló alkalmas-e az etcd-vel való használatra, a következő segédprogram segítségével lehet

Egy tároló alkalmas-e az etcd-vel való használatra, azt a segédeszköz segítségével lehet értékelni fio — népszerű I/O teszter. Figyelembe kell venni, hogy a lemez bemeneti-kimeneti műveletei különböző módokon történhetnek: szinkron/aszinkron, a rendszerhívások különféle osztályai stb. A dolog másik oldala az, hogy fio extrém nehéz használni. Az eszköz számos paramétert tartalmaz, és az értékeik különböző kombinációi teljesen eltérő eredményeket adnak. Ahhoz, hogy ésszerű értékelést kapjunk az etcd esetében, meg kell győződnünk arról, hogy a fio által generált írási terhelés maximálisan hasonlít az etcd WAL-fájlokba történő írásának terhelésére:

Ez azt jelenti, hogy a generált fio terhelésnek legalább egy sorozatos írást kell tartalmaznia egy fájlba, ahol minden írási művelet egy rendszerhívásból áll write, amelyet fdatasync.
A sorozatos írás engedélyezéséhez meg kell adni a zászlót --rw=write.
Ahhoz, hogy fio írás közben rendszerhívások alkalmazásával write (nem más rendszerhívások — például pwrite), a zászlót kell használni --ioengine=sync.
Végül a zászló --fdatasync=1 garantálja, hogy minden egyes write kell fdatasync.
A mi példánkban két további paraméter van: --size és --bs — ezek a konkrét felhasználási forgatókönyvtől függően változhatnak. A következő részben bemutatjuk a beállításukat.

Miért választottuk a fio-t és honnan tudtuk, hogyan állítsuk be

Ez a megjegyzés egy valódi esettől származik, amivel találkoztunk. Volt egy Kubernetes v1.13 klaszterünk Prometheus figyeléssel. Az etcd v3.2.24-hez a tároló SSD-k szolgáltak. Az etcd metrikák túl magas késleltetést mutattak fdatasync, még akkor is, amikor a klaszter tétlen volt. Ezek a metrikák nagyon gyanúsak voltak számunkra, és nem voltunk biztosak abban, hogy pontosan mit is jelentenek. Ráadásul a klaszter virtuális gépekből állt, így nem tudtuk megmondani, hogy a késleltetés a virtualizációval vagy az SSD-kkel volt-e kapcsolatos.

Ezenkívül különböző hardver- és szoftverkonfigurációs változtatásokat is figyelembe vettünk, ezért szükség volt egy módra ezek értékelésére. Természetesen futtathattuk volna az etcd-t minden konfigurációban, és megnézhettük volna a megfelelő Prometheus metrikákat, de ez jelentős erőfeszítést igényelt volna. Nekünk egy egyszerű módszerre volt szükségünk, amely lehetővé tette egy adott konfiguráció értékelését. Meg akartuk vizsgálni a Prometheus által az etcd-től érkező metrikák megértését.

Ehhez két problémát kellett megoldani:

Először is, hogyan néz ki az I/O-terhelés, amelyet az etcd generál a WAL-fájlok írásakor? Milyen rendszerhívásokat használnak? Mekkora az írási blokkok mérete?
Másodszor, tételezzük fel, hogy megvannak a válaszok a fenti kérdésekre. Hogyan lehet reprodukálni a megfelelő terhelést fio? Ведь fio — rendkívül rugalmas segédeszköz számos paraméterrel (ezt könnyen ellenőrizheti például, itt — a fordító megjegyzése).

Mindkét problémát ugyanazzal a megközelítéssel oldottuk meg, amely a parancsokra támaszkodik lsof és strace:

A segítségével lsof meg lehet nézni az összes fájldeszkriptort, amelyet a folyamat használ, valamint azokat a fájlokat, amelyekhez tartoznak.
A segítségével strace elemezheti a már futó folyamatot, vagy indíthat egy folyamatot, és figyelemmel kísérheti azt. A parancs megjeleníti az összes rendszerhívást, amelyet a folyamat végrehajtott, és szükség esetén a leszármazottait. Az utóbbi fontos a fork-olt folyamatok esetén, és az etcd az egyik ilyen folyamat.

Az első dolog, amit tettünk, az az, hogy használtuk strace az etcd szerver vizsgálatára a Kubernetes klaszterben, amíg az állt.

Ekkor derült ki, hogy a WAL írási blokkjai nagyon szorosan csoportosulnak, a többségük mérete 2200-2400 byte között volt. Ezért használják a cikk elején a parancsban a flag-et --bs=2300 (bs — az egyes írási blokkok mérete byte-ban a fio).

Ne feledje, hogy az etcd írási blokkjainak mérete változhat a verzió, a telepítés, a paraméterek értékei stb. függvényében — ez befolyásolja a tartósságot fdatasync. Ha hasonló használati forgatókönyve van, elemezze az strace az etcd folyamatait, hogy aktuális értékeket kapjon.

Ezután, hogy világos és átfogó képet kapjunk az etcd és a fájlrendszer kapcsolatáról, elindítottuk strace a flag-ekkel -ffttT. Ez lehetővé tette a leszármazott folyamatok lefedését, és minden egyes kimenetet külön fájlba írt. Ezen kívül részletes információt kaptunk a rendszerhívások kezdetéről és időtartamáról.

Azt is megvizsgáltuk, hogy a lsofparancs megerősítse a kimenet megértését strace azzal kapcsolatban, hogy mely fájl-deszkriptor mely célra volt használva. A kimenet stracehasonló lett ahhoz, amit fentebb bemutattunk. A szinkronizálási idők statisztikai manipulációi megerősítették, hogy az etcd metrikája megfelel a wal_fsync_duration_seconds WAL fájl-deszkriptorainak. fdatasync A generáláshoz használva

A generáláshoz használja fio A munkaterhelést, amely hasonló az etcd-től származó terheléshez, a segédeszköz dokumentációjának tanulmányozásával és az ehhez megfelelő paraméterek kiválasztásával elemeztük. Meggyőződtünk arról, hogy a szükséges rendszerhívások aktívak, és megerősítettük azok időtartamát, elindítva fio a strace (ahogy ez az etcd esetében történt).

Különös figyelmet fordítottunk a paraméter értékének meghatározására --size. Ez a fio segédeszköz által generált összes I/O terhelést képviseli. A mi esetünkben ez a háttértárra írt bájtok teljes száma. Arányos a hívások számával write (és fdatasync). Az adott bs hívások száma fdatasync egyenlő size / bs.

Mivel minket a percentilis érdekelt, arra törekedtünk, hogy a minták száma elegendően nagy legyen a statisztikai jelentőséghez. Így döntöttünk, hogy 10^4 (ami 22 MB méretnek felel meg) elegendő lesz. A kisebb paraméterértékek --size több zajt adtak (például a hívások fdatasync, amelyek sokkal hosszabb időt vesznek igénybe, mint általában, és befolyásolják a 99. percentilist).

Most önön a sor

A cikk bemutatja, hogy a fio segítségével hogyan lehet felmérni, hogy a statisztikailag elegendően gyors háttértár alkalmas-e az etcd használatára. Most önön a sor is! SSD alapú tárolással rendelkező virtuális gépeket az IBM Cloud.

Fejlesztési eszközök, amelyek Kubernetesben futnak

A kész példákat más feladatok megoldására a fio vagy közvetlenül a dokumentáció (ott sokkal többet talál, mint ami a dokumentációban említve van). projekt tárolójában P.P.S. a fordítótól