Rövid történet a fio-ról és az etcd-ről
A klaszter teljesítménye nagymértékben függ a tároló teljesítményétől. Az etcd néhány metrikát exportál , hogy a tároló teljesítményéről szükséges információkat nyújtson. Például a wal_fsync_duration_seconds metrikát. : a tároló akkor tekinthető elég gyorsnak, ha a 99. percentilis ennek a metrikának kevesebb mint 10 ms. Ha etcd klasztert kíván futtatni Linux gépeken és szeretné felmérni, hogy a tárolója eléggé gyors-e (például SSD), használhatja — egy népszerű eszköz a bemeneti/kimeneti műveletek tesztelésére. Futassa a következő parancsot, ahol a test-data a tároló csatlakozási pontjának könyvtára:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestCsak meg kell nézni az eredményeket, és ellenőrizni, hogy a 99. percentilis időtartama kevesebb mint 10 ms. Ha igen, a tárolója elég gyors. Íme egy példa az eredményekre:
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
sync percentilisek (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]Megjegyzések
- Mi beállítottuk az —size és —bs paraméterek értékeit a saját forgatókönyvünkhöz. Ahhoz, hogy a fio hasznos eredményt adjon, adja meg a saját értékeit. Hol találhatók ezek? Olvassa el, .
- A tesztelés során az összes bemeneti/kimeneti terhelés a fio-tól származik. Valós forgatókönyvben valószínűleg egyéb írási kérelmek is érkeznek a tárolóhoz, nemcsak a wal_fsync_duration_seconds-hez kapcsolódóak. A további terhelés megnöveli a wal_fsync_duration_seconds értékét. Tehát ha a 99. percentilis közel van a 10 ms-hez, a tárolója nem elég gyors.
- Használja a verziót nem lehet kevesebb, mint 3,5 (a korábbiak nem mutatják a fdatasync időtartamának percentiljeit).
- Fent csak a fio törzs eredményeinek egy részét mutattuk be.
Hosszú történet a fio-ról és az etcd-ről
Mi az a WAL az etcd-ben
Általában az adatbázisok használják ; az etcd is használja. Itt nem fogunk részletesen foglalkozni az előzetes naplóbejegyzésekkel (write-ahead log, WAL). Elég annyit tudnunk, hogy az etcd klaszter minden tagja a tartós tárolóban vezeti ezeket. Az etcd minden kulcs-érték pár műveletét (például frissítést) a WAL-ba jegyzi, mielőtt alkalmazná őket a tárolóban. Ha a pillanatképek között a tároló egyik tagja ütközés miatt leáll és újraindul, lokálisan helyreállíthatja a tranzakciókat az utolsó pillanatképtől kezdve a WAL tartalma alapján.
Amikor egy ügyfél kulcsot ad hozzá a kulcs-érték tárolóhoz, vagy frissít egy meglévő kulcs értékét, az etcd rögzíti ezt a műveletet a WAL-ba, amely egy szokásos fájl a tartós tárolóban. Az etcd-nak TELJESEN biztosnak kell lennie abban, hogy a WAL-ba való rögzítés valóban megtörtént, mielőtt folytatná a feldolgozást. Linux alatt egyetlen rendszerhívás nem elegendő ehhez. , mivel a tényleges rögzítés a fizikai tárolóba késlekedhet. Például a Linux egy ideig tárolhatja a WAL bejegyzést az kernel memóriájának gyorsítótárában (például az oldal gyorsítótárban). Ahhoz, hogy az adatok biztosan a tartós tárolóba kerüljenek, szükséges a fdatasync rendszerhívás a rögzítés után, és az etcd éppen ezt használja (ahogy az a kimenetből is látható, , ahol a 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) = 0Sajnos a tartós tárolóba való írás nem történik meg azonnal. Ha a fdatasync hívás lassan működik, az etcd rendszer teljesítménye csökken. , a tároló kellően gyorsnak számít, ha a 99. percentilis fdatasync hívásai a WAL fájlba íráskor kevesebb mint 10 ms-ot vesznek igénybe. Van más hasznos metrika is a tárolóra vonatkozóan, de ebben a bejegyzésben csak erről a metrikáról beszélünk.
A tároló értékelése fio használatával
Ha szeretné értékelni, hogy a tárolója megfelelő-e az etcd számára, használja a fio-t — ez egy nagyon népszerű I/O terhelés tesztelő eszköz. Ne felejtse el, hogy a lemezműveletek különbözőek lehetnek: szinkron és aszinkron, különböző rendszervcall-osztályok stb. Ennek következtében a fio használata meglehetősen bonyolult. Sok paramétere van, és azok különböző kombinációi teljesen eltérő I/O terheléseket eredményeznek. A pontos számok megállapításához az etcd számára biztosítani kell, hogy a fio írási tesztterhelése a lehető legközelebb álljon az etcd valós fájl WAl írási terheléséhez.
Ezért a fionak legalább egy sor következő írási műveletet kell generálnia egy fájlban, ahol minden írás egy rendszervcall-t fog tartalmazni. , amelyet egy fdatasync rendszervcall követ. A soros írási műveletekhez a fio-nak szüksége van a —rw=write paraméterre. Ahhoz, hogy a fio írja a write rendszervcall-t íráskor, nem pedig , érdemes a —ioengine=sync paramétert megadni. Végül, hogy minden írás után a fdatasync hívásra kerüljön, hozzá kell adni a —fdatasync=1 paramétert. Két másik paraméter ebben a példában (—size és —bs) az adott forgatókönyvtől függ. A következő részben bemutatjuk, hogyan lehet ezeket beállítani.
Miért a fio, és hogyan tanultuk meg beállítani
Ebben a bejegyzésben egy valós esetet írunk le. Volt egy klaszterünk v1.13, amelyet a Prometheus segítségével figyeltünk. Az etcd v3.2.24 SSD-n helyezkedett el. Az etcd statisztikák túl magas késlekedéseket mutattak a fdatasync esetében, még akkor is, amikor a klaszter semmit sem csinált. A metrikák furcsák voltak, és nem igazán tudtuk, mit is jelentenek. A klaszter virtuális gépekből állt, és meg kellett értenünk, hogy a probléma a fizikai SSD-ben vagy a virtualizációs rétegben rejlik. Ráadásul gyakran módosítottuk a hardver és szoftver konfigurációt, és szükségünk volt egy módszerre, hogy értékeljük az eredményeket. Futtathattuk az etcd-t minden konfigurációban, és figyelhettük a Prometheus metrikáit, de ez túl munkaigényes volt. Olyan egyszerű módot kerestünk, amely lehetővé tette a konkrét konfiguráció értékelését. Ellenőrizni akartuk, hogy helyesen értjük-e az etcd Prometheus metrikáit.
De ezeket a két problémát meg kellett oldani. Először is, milyen bemeneti-kimeneti terhelést generál az etcd a WAL-ba való íráskor? Milyen rendszerhívásokat használnak? Mekkora a rekordok mérete? Másodszor, ha válaszolunk ezekre a kérdésekre, hogyan reprodukálhatunk egy hasonló munkaterhelést a fio segítségével? Ne feledkezzünk meg arról, hogy a fio egy nagyon rugalmas eszköz számos paraméterrel. Mindkét problémát egyetlen megközelítéssel oldottuk meg — parancsok segítségével. és . Az lsof megmutatja az összes fájl- észlelődeszkát, amelyet a folyamat használ, valamint a hozzájuk kapcsolódó fájlokat. A strace segítségével már futó folyamatot is tanulmányozhatunk, vagy elindíthatunk egy folyamatot, és megvizsgálhatjuk. A strace megjeleníti az összes rendszerhívást a vizsgált folyamattól (és annak gyermekeitől). Ez utóbbi nagyon fontos, mivel az etcd éppen ilyen megközelítést alkalmaz.
Első lépésként a strace-t használtuk az etcd Kubernetes szerverének vizsgálatára, amikor a klaszterre nem volt terhelés. Láttuk, hogy szinte minden WAL-rekord hasonló méretű volt: 2200–2400 bájt. Ezért a bejegyzés elején a csapatban megadtuk a -bs=2300 paramétert (a bs a fio rekordszámának bájtban kifejezett mérete). Vegye figyelembe, hogy az etcd rekordok mérete az etcd verziójától, a szállítástól, a paraméterek értékeitől stb. függ, és hatással van a fdatasync időtartamára. Ha hasonló szcenáriód van, tanulmányozd az etcd folyamataidat strace segítségével, hogy pontos számokat találj.
Ezután, hogy jól ábrázoljuk az etcd fájlrendszerbeli működését, elindítottuk a strace-t az -ffttT paraméterekkel. Ily módon próbáltuk tanulmányozni a gyermekfolyamatokat, és az egyes kimeneteket külön fájlba menteni, valamint részletes jelentéseket kapni minden rendszerhívás kezdetéről és időtartamáról. Az lsof-t használtuk az strace kimenetünkből származó elemzés megerősítésére, hogy lássuk, mely fájl-észlelődeszkát milyen célokra használták. Így az strace segítségével kaptuk az itt bemutatott eredményeket. A szinkronizálási idő statisztikái megerősítették, hogy az etcd wal_fsync_duration_seconds értéke megfelel a wal fdatasync hívásainak vonatkozó fájl-észlelődeszkákkal.
Tanulmányoztuk a fio dokumentációját, és kiválasztottuk a paramétereket a szcenáriónkhoz, hogy a fio hasonló terhelést generáljon, mint az etcd. Ezenkívül a rendszerhívásokat és azok időtartamát is megvizsgáltuk, amikor a fio-t strace-ből indítottuk, az etcd-hez hasonlóan.
Gondosan választottuk ki a -size paraméter jelentését, amely a fio által generált teljes bemeneti-kimeneti terhelést képviseli. Ebben az esetben ez a tárolóba írt bájtok összesített száma. Ez közvetlen arányban áll a write (és fdatasync) rendszerhívások számával. Egy adott bs érték esetén a fdatasync hívások száma = size/bs. Mivel minket a percentilis érdekelt, elegendő mintára volt szükségünk a megbízhatósághoz, és úgy számoltuk, hogy elegendő lesz a 10^4 (ami 22 mebibájt). Ha a -size kisebb, kiugró értékek léphetnek fel (például néhány fdatasync hívás tovább tart a megszokott időnél, ami befolyásolja a 99. percentilist).
Próbáld ki magad
Megmutattuk, hogyan használhatjuk a fiot, és hogyan ellenőrizhetjük, hogy a tárolónak elegendő sebessége van-e az etcd magas teljesítményéhez. Most ezt kipróbálhatja önállóan, például SSD tárolós virtuális gépeken. .
Forrás: habr.com
