🥇Hogyan ellenőrizhető a lemezek fio-val megfelelő teljesítménye az etcd

Jegyzet. ford.: Ez a cikk egy mini-kutatás eredménye, amelyet az IBM Cloud mérnökei végeztek, hogy megoldást keressenek az etcd adatbázis működésével kapcsolatos valós problémára. Hasonló feladat volt számunkra is aktuális, azonban a szerzők reflexióinak, akcióinak menete tágabb kontextusban is érdekes lehet.

A teljes cikk rövid összefoglalása: fio és stb

Az etcd-fürt teljesítménye nagymértékben függ az alapul szolgáló tároló sebességétől. Az etcd különféle Prometheus-metrikákat exportál a teljesítmény monitorozására. Az egyik az wal_fsync_duration_seconds. Az etcd dokumentációjában azt mondjahogy a tárolás akkor tekinthető elég gyorsnak, ha ennek a mutatónak a 99. percentilise nem haladja meg a 10 ms-t…

Ha egy etcd-fürt létrehozását fontolgatja Linuxos gépeken, és szeretné ellenőrizni, hogy a meghajtók (például az SSD-k) elég gyorsak-e, javasoljuk a népszerű I/O-tesztelő, az ún. Fio. Elég a következő parancsot futtatni (könyvtár test-data a tesztelt meghajtó csatlakoztatott partícióján kell elhelyezkednie):

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

Csak meg kell nézni a kimenetet, és ellenőrizni kell, hogy a 99. percentilis illeszkedik-e fdatasync 10 ms alatt. Ha igen, akkor a meghajtó elég gyorsan működik. Íme egy példa kimenet:

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 beállítottuk a paramétereket --size и --bs konkrét esetre. Ahhoz, hogy értelmes eredményt kapjunk fio, adja meg az Ön használati esetének megfelelő értékeket. Hogyan válasszuk ki őket, az alábbiakban lesz szó.
Csak a tesztelés alatt fio betölti a lemez alrendszert. A való életben valószínű, hogy más folyamatok is írnak a lemezre (azokon kívül, amelyek a wal_fsync_duration_seconds). Ez a többletterhelés növekedhet wal_fsync_duration_seconds. Más szóval, ha a 99. percentilis a tesztelésből fio, csak valamivel kevesebb, mint 10 ms, jó eséllyel a tárolási teljesítmény nem elegendő.
A teszthez szüksége lesz a verzióra fio nem kevesebb, mint 3.5, mert a régebbi verziók nem összesítik az eredményeket fdatasync százalékosok formájában.
A fenti következtetés csak egy kis kivonat az általános következtetésből fio.

Bővebben a fio-ról és stb

Néhány szó a WAL-okról stb

Általában adatbázisokat használnak proaktív naplózás (előre írásos naplózás, WAL). etcd is érintett. A WAL tárgyalása túlmutat ennek a cikknek a hatókörén, de a mi célunkhoz tudnod kell, hogy minden etcd-fürttag állandó tárhelyen tárolja a WAL-t. Az etcd néhány kulcsérték tárolási műveletet (például frissítéseket) ír a WAL-ba, mielőtt végrehajtaná azokat. Ha egy csomópont összeomlik és újraindul a pillanatképek között, az etcd a WAL tartalma alapján helyreállíthatja az előző pillanatkép óta végrehajtott tranzakciókat.

Így minden alkalommal, amikor egy kliens kulcsot ad a KV tárolóhoz, vagy frissíti egy meglévő kulcs értékét, az etcd hozzáadja a művelet leírását a WAL-hoz, amely egy normál fájl az állandó tárolóban. etcd 100%-ig biztosnak kell lennie abban, hogy a WAL bejegyzés valóban el lett mentve a folytatás előtt. Ennek eléréséhez Linuxon nem elég a rendszerhívás használata write, mivel maga a fizikai adathordozóra történő írási művelet késhet. Például a Linux egy WAL-bejegyzést egy ideig a memórián belüli kernel-gyorsítótárban tarthat (pl. az oldal gyorsítótárában). Az adatok adathordozóra való írásának biztosításához az írás után rendszerhívást kell meghívni fdatasync - pontosan ezt csinálja az etcd (amint az a következő kimeneten látható strace; Itt 8 - WAL fájlleíró):

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>

Sajnos a tartós tárhelyre írás némi időt vesz igénybe. Az fdatasync hívások hosszan tartó végrehajtása befolyásolhatja az etcd teljesítményét. Az adattár dokumentációjában jelzett, hogy a kellő teljesítményhez szükséges, hogy az összes hívás időtartamának 99. percentilis fdatasync amikor a WAL-fájlba írás 10 ms-nál rövidebb volt. Vannak más, tárolással kapcsolatos mutatók is, de ez a cikk erre összpontosít.

Tárolás megbecsülése fioval

A segédprogram segítségével kiértékelheti, hogy egy adott tároló alkalmas-e az etcd-vel való használatra Fio — népszerű I/O tesztelő. Ne feledje, hogy a lemez I/O sokféle módon történhet: szinkronizálás/aszinkron, sok különböző rendszerhívási osztály stb. Az érem másik oldala az fio rendkívül nehéz használni. A segédprogramnak számos paramétere van, és értékük különböző kombinációi teljesen eltérő eredményekhez vezetnek. Annak érdekében, hogy ésszerű becslést kapjon az etcd-re, meg kell győződnie arról, hogy a fio által generált írási terhelés a lehető legközelebb van az etcd WAL-fájl írási terheléséhez:

Ez azt jelenti, hogy a keletkezett fio a betöltésnek legalább egy sor egymást követő írásnak kell lennie a fájlba, ahol minden írás egy rendszerhívásból áll writeköveti fdatasync.
A szekvenciális írás engedélyezéséhez meg kell adni a zászlót --rw=write.
Hogy fio hívásokkal írt write (más rendszerhívások helyett - pl. pwrite), használja a zászlót --ioengine=sync.
Végül a zászló --fdatasync=1 biztosítja, hogy minden write kell, hogy legyen fdatasync.
Példánkban a másik két paraméter a következő: --size и --bs - az adott felhasználási esettől függően változhat. A következő rész a konfigurációjukat írja le.

Miért választottuk a fio-t, és hogyan tanultuk meg a beállítását

Ez a feljegyzés egy valós esetből származik, amellyel találkoztunk. Volt egy fürt a Kubernetes v1.13-as verzióján, és a Prometheuson is figyeltünk. SSD-ket használtak tárolóként az etcd v3.2.24-hez. Az Etcd metrikák túl magas késleltetést mutattak fdatasync, még akkor is, ha a fürt tétlen volt. Számunkra ezek a mutatók nagyon kétesnek tűntek, és nem voltunk biztosak abban, hogy pontosan mit is képviselnek. Ráadásul a fürt virtuális gépekből állt, így nem lehetett megmondani, hogy a késés a virtualizáció miatt, vagy az SSD okolható-e.

Emellett a hardver- és szoftverkonfigurációban is figyelembe vettünk különféle változtatásokat, így szükségünk volt egy módra ezek értékelésére. Természetesen minden konfigurációban le lehet futtatni az etcd-t, és megnézni a megfelelő Prometheus-metrikákat, de ez jelentős erőfeszítést igényel. Szükségünk volt egy egyszerű módszerre egy adott konfiguráció értékelésére. Azt akartuk tesztelni, hogy megértjük-e az etcd-ből származó Prometheus-metrikákat.

Ehhez két probléma megoldására volt szükség:

Először is, hogyan néz ki az etcd által generált I/O terhelés, amikor WAL-fájlokba írunk? Milyen rendszerhívásokat használnak? Mekkora a rekordblokkok mérete?
Másodszor, tegyük fel, hogy megvan a válaszunk a fenti kérdésekre. Hogyan lehet reprodukálni a megfelelő terhelést fio? Végül fio — rendkívül rugalmas segédprogram rengeteg paraméterrel (ezt könnyű ellenőrizni pl. itt - kb. fordítás.).

Mindkét problémát ugyanazzal a parancsalapú megközelítéssel oldottuk meg lsof и strace:

-Val lsof megtekintheti a folyamat által használt összes fájlleírót, valamint az általuk hivatkozott fájlokat.
-Val strace elemezhet egy már futó folyamatot, vagy futtathat egy folyamatot és megnézheti azt. A parancs megjeleníti az e folyamat által kezdeményezett összes rendszerhívást, és ha szükséges, a leszármazottait is. Ez utóbbi fontos a forking folyamatok számára, és az etcd az egyik ilyen folyamat.

Az első dolgunk az volt, hogy használjuk strace hogy megvizsgálja az etcd-kiszolgálót a Kubernetes-fürtben, miközben az tétlen volt.

Így kiderült, hogy a WAL rekordblokkok nagyon sűrűn vannak csoportosítva, a többség mérete 2200-2400 bájt tartományba esett. Ez az oka annak, hogy a cikk elején található parancs a zászlót használja --bs=2300 (bs az egyes írási blokkok mérete bájtban fio).

Kérjük, vegye figyelembe, hogy az etcd írási blokkok mérete változhat a verziótól, a telepítéstől, a paraméterértékektől stb. - befolyásolja az időtartamot fdatasync. Ha van hasonló használati esete, elemezze a következővel strace az etcd folyamatait, hogy naprakész értékeket kapjon.

Aztán annak érdekében, hogy világos és átfogó képet kapjunk arról, hogyan működik az etcd a fájlrendszerrel, alulról indítottuk el strace zászlókkal -ffttT. Ez lehetővé tette a gyermekfolyamatok rögzítését és mindegyik kimenetének külön fájlba írását. Ezenkívül részletes információkat kaptunk az egyes rendszerhívások kezdési idejéről és időtartamáról.

Használtuk a parancsot is lsofhogy megerősítse a kimenet megértését strace abból a szempontból, hogy melyik fájlleírót milyen célra használták. Megkaptam a következtetést strace, hasonló a fentihez. A szinkronizálási időkkel végzett statisztikai manipulációk megerősítették, hogy a metrika wal_fsync_duration_seconds az etcd-ből egyezik a hívásokkal fdatasync WAL fájlleírókkal.

Ezzel generálni fio az etcd-hez hasonló terhelést, áttanulmányoztuk a segédprogram dokumentációját és kiválasztottuk a feladatunknak megfelelő paramétereket. Ellenőriztük, hogy a megfelelő rendszerhívások vannak folyamatban, és futással megerősítettük azok időtartamát fio A strace (ahogyan az etcd esetében is történt).

Különös figyelmet fordítottak a paraméter értékének meghatározására --size. A fio segédprogram által generált teljes I/O terhelést jelenti. Esetünkben ez a médiára írt bájtok teljes száma. Ez egyenesen arányos a hívások számával write (és fdatasync). Egy konkrét bs hívások száma fdatasync jelentése size / bs.

Mivel minket a percentilis érdekelt, azt akartuk, hogy a minták száma elég nagy legyen ahhoz, hogy statisztikailag szignifikáns legyen. És úgy döntött 10^4 (ami 22 MB méretnek felel meg) elegendő lesz. Kisebb paraméterértékek --size kifejezettebb zajt adott (például hívások fdatasync, amelyek a szokásosnál sokkal tovább tartanak, és a 99. percentilist érintik).

Tőled függ

A cikk bemutatja, hogyan kell használni fio meg lehet ítélni, hogy az etcd-vel való használatra szánt adathordozó elég gyors-e. Most rajtad múlik! A szolgáltatásban SSD-alapú tárhellyel rendelkező virtuális gépeket fedezhet fel IBM Cloud.

PS a fordítótól

Kész használati tokkal fio Egyéb feladatokhoz lásd dokumentáció vagy közvetlenül projekttárak (sokkal több van belőlük, mint amennyi a dokumentációban szerepel).

PPS a fordítótól

Olvassa el blogunkon is:

Forrás: will.com

Hogyan lehet ellenőrizni a lemezeket a fio segítségével, hogy megfelelő-e a teljesítmény az etcd számára