Egy rövid történet fio-ról stb
Klaszter teljesítménye nagyban függ a tárolás teljesítményétől. Az etcd néhány mérőszámot ide exportál hogy megadja a kívánt tárolási teljesítményinformációkat. Például a wal_fsync_duration_seconds metrika. : Ahhoz, hogy a tárolást elég gyorsnak lehessen tekinteni, ennek a mutatónak a 99. percentilisének 10 ms-nál rövidebbnek kell lennie. Ha egy etcd-fürtöt tervez futtatni Linux gépeken, és szeretné kiértékelni, hogy elég gyors-e a tárhely (pl. SSD), használhatja egy népszerű eszköz az I/O műveletek tesztelésére. Futtassa a következő parancsot, ahol a test-data a tárolási csatlakozási pont alatti könyvtár:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestCsak meg kell néznie az eredményeket, és ellenőriznie kell, hogy az időtartam 99. százaléka kevesebb, mint 10 ms. Ha igen, akkor ésszerűen gyors tárhelye van. Íme egy példa az eredményekre:
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]Megjegyzések
- A --size és --bs beállításokat az adott forgatókönyvünkhöz szabtuk. Ha hasznos eredményt szeretne elérni a fio-ból, adja meg saját értékeit. Hol lehet kapni? Olvas .
- A tesztelés során minden I/O terhelés a fio-tól származik. Valós forgatókönyv esetén a wal_fsync_duration_seconds-hoz kapcsolódóakon kívül valószínűleg más írási kérések is érkeznek a tárolóba. Az extra terhelés növeli a wal_fsync_duration_seconds értékét. Tehát ha a 99. percentilis közel van 10 ms-hoz, akkor a tárhelye kifogy.
- Vegyük a verziót nem kevesebb, mint 3.5 (az előzőek nem mutatják az fdatasync időtartamának százalékpontját).
- Fent csak egy részlet a fio eredményeiből.
Hosszú történet fio-ról és stb
Mi a WAL az etcd-ben
Általában adatbázisok használják ; az etcd is ezt használja. Az előreírási naplót (WAL) itt nem tárgyaljuk részletesen. Elég, ha tudjuk, hogy az etcd fürt minden tagja állandó tárhelyen tartja azt. Az etcd minden kulcsérték-műveletet (például frissítést) ír a WAL-ba, mielőtt alkalmazná a tárolóban. Ha az egyik tárolótag összeomlik és újraindul a pillanatképek között, helyileg vissza tudja állítani a tranzakciókat a legutóbbi WAL-tartalom pillanatfelvétele óta.
Amikor egy ügyfél kulcsot ad a kulcsérték tárolóhoz, vagy frissíti egy meglévő kulcs értékét, az etcd rögzíti a műveletet a WAL-ban, amely egy normál fájl az állandó tárolóban. etcd A feldolgozás folytatása előtt teljesen biztosnak kell lennie abban, hogy a WAL bejegyzés valóban megtörtént. Linuxon ehhez nem elég egy rendszerhívás. , mivel a tényleges írás a fizikai tárhelyre késhet. Például a Linux egy WAL-bejegyzést tárolhat a kernelmemória gyorsítótárában (például egy oldalgyorsítótárban) egy ideig. És ahhoz, hogy az adatok pontosan ki legyenek írva a perzisztens tárhelyre, az írás után szükség van az fdatasync rendszerhívásra, és az etcd csak azt használja (ahogy a munka eredményén látható , ahol a 8 a WAL-fájl leírója):
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8) = 0 <0.008314>Sajnos az állandó tárhelyre írás nem történik meg azonnal. Ha az fdatasync hívás lassú, az etcd rendszer teljesítménye csökken. hogy a tárhely elég gyorsnak tekinthető, ha a 99. percentilisben az fdatasync hívások 10 ms-nál rövidebb idő alatt íródnak a WAL-fájlba. Vannak más hasznos mérőszámok a tároláshoz, de ebben a bejegyzésben csak erről a mérőszámról beszélünk.
Tárhely becslése fio-val
Ha értékelnie kell, hogy a tárolója alkalmas-e az etcd-re, használja a fio-t, egy nagyon népszerű I/O terhelést vizsgáló eszközt. Emlékeztetni kell arra, hogy a lemezműveletek nagyon különbözőek lehetnek: szinkron és aszinkron, számos rendszerhívási osztály stb. Ennek eredményeként a fio használata meglehetősen nehéz. Számos paraméterrel rendelkezik, és értékük különböző kombinációi nagyon eltérő I/O munkaterhelést eredményeznek. Ahhoz, hogy megfelelő számadatokat kapjon az etcd-re vonatkozóan, győződjön meg arról, hogy a fio-ból származó tesztírási terhelés a lehető legközelebb van az etcd-ből származó tényleges terheléshez, amikor WAL-fájlokat ír.
Ezért a fio-nak legalább egy sor szekvenciális írást kell létrehoznia a fájlba, minden írás egy rendszerhívásból áll. ezt követi az fdatasync rendszerhívás. A fio szekvenciális írásához az --rw=write opció szükséges. Ahhoz, hogy a fio inkább az írási rendszerhívást használja íráskor , meg kell adnia a --ioengine=sync paramétert. Végül az fdatasync minden írás utáni meghívásához hozzá kell adni a --fdatasync=1 paramétert. A példa másik két opciója (--size és -bs) szkript-specifikus. A következő részben bemutatjuk, hogyan kell beállítani őket.
Miért pont fio és hogyan tanultuk meg beállítani
Ebben a bejegyzésben egy valós esetet írunk le. Van egy klaszterünk v1.13, amelyet a Prometheusszal figyeltünk meg. Az etcd v3.2.24 SSD-n volt tárolva. Az Etcd metrikák túl magas fdatasync késést mutattak, még akkor is, ha a fürt nem csinált semmit. A mérőszámok furcsák voltak, és nem igazán tudtuk, mit jelentenek. A klaszter virtuális gépekből állt, meg kellett érteni, mi a probléma: a fizikai SSD-kben vagy a virtualizációs rétegben. Ezenkívül gyakran változtattunk a hardver- és szoftverkonfiguráción, és szükségünk volt egy módra az eredmények értékelésére. Minden konfigurációban futtathatnánk az etcd-t, és megnézhetnénk a Prometheus mérőszámait, de ez túl sok gondot okoz. Meglehetősen egyszerű módszert kerestünk egy adott konfiguráció értékelésére. Azt akartuk ellenőrizni, hogy jól értelmezzük-e az etcd Prometheus mérőszámait.
Ehhez azonban két problémát kellett megoldani. Először is, hogy néz ki az I/O terhelés, amit az etcd létrehoz, amikor WAL-ba ír? Milyen rendszerhívásokat használnak? Mekkora a rekordok mérete? Másodszor, ha válaszolunk ezekre a kérdésekre, hogyan reprodukálhatunk hasonló munkaterhelést a fio-val? Ne felejtsük el, hogy a fio egy nagyon rugalmas eszköz, számos lehetőséggel. Mindkét problémát egyetlen megközelítéssel – a parancsok használatával – oldottuk meg и . Az lsof felsorolja a folyamat által használt összes fájlleírót és a hozzájuk tartozó fájlokat. A strace segítségével pedig megvizsgálhat egy már futó folyamatot, vagy elindíthat egy folyamatot és megvizsgálhatja azt. A strace kiírja a vizsgált folyamatból (és annak gyermekfolyamataiból) származó összes rendszerhívást. Ez utóbbi nagyon fontos, mivel az etcd éppen hasonló megközelítést alkalmaz.
Először a strace-t használtuk a Kubernetes etcd-kiszolgálójának felfedezésére, amikor nem volt terhelés a fürtön. Láttuk, hogy szinte az összes WAL rekord körülbelül azonos méretű: 2200–2400 bájt. Ezért a bejegyzés elején a parancsban a -bs=2300 paramétert adtuk meg (a bs az egyes fio bejegyzések méretét jelenti bájtban). Vegye figyelembe, hogy az etcd bejegyzés mérete függ az etcd verziójától, elosztásától, paraméterértékeitől stb., és befolyásolja az fdatasync időtartamát. Ha hasonló forgatókönyvvel rendelkezik, vizsgálja meg etcd folyamatait strace segítségével, hogy megtudja a pontos számokat.
Ezután, hogy jó képet kapjunk arról, hogy mit csinál az etcd fájlrendszer, elindítottuk a strace és a -ffttT opciókkal. Igyekeztünk tehát megvizsgálni az utódfolyamatokat, és mindegyik kimenetét külön fájlban rögzíteni, valamint részletes jelentéseket kapni az egyes rendszerhívások kezdetéről és időtartamáról. Az lsof segítségével megerősítettük a strace kimenet elemzését, és megnéztük, hogy melyik fájlleírót milyen célra használjuk. Tehát a strace segítségével a fent látható eredményeket kaptuk. A szinkronizálási idő statisztikái megerősítették, hogy az etcd wal_fsync_duration_seconds értéke összhangban van a WAL fájlleírókkal rendelkező fdatasync hívásokkal.
Átnéztük a fio dokumentációját, és kiválasztottuk a szkriptünk beállításait, hogy a fio az etcd-hez hasonló terhelést generáljon. A rendszerhívásokat és azok időtartamát is ellenőriztük a fio futtatásával a strace-ből, hasonlóan az etcd-hez.
Gondosan választottuk meg a --size paraméter értékét, hogy a fio teljes I/O terhelését reprezentálja. Esetünkben ez a tárolóba írt bájtok teljes száma. Kiderült, hogy egyenesen arányos az írási (és fdatasync) rendszerhívások számával. Egy adott bs érték esetén az fdatasync hívások száma = size/bs. Mivel minket a percentilis érdekelt, elegendő mintával kellett rendelkeznünk, hogy biztosak lehessünk benne, és kiszámoltuk, hogy 10^4 elég lesz nekünk (ez 22 mebibyte). Ha a --size kisebb, kiugró értékek fordulhatnak elő (például több fdatasync hívás a szokásosnál tovább tart, és befolyásolja a 99. százalékot).
Próbáld ki magad
Megmutattuk, hogyan kell használni a fio-t, és nézd meg, hogy a tárhely elég gyors-e ahhoz, hogy az etcd jól működjön. Most már saját kezűleg is kipróbálhatja például SSD-tárhellyel rendelkező virtuális gépek használatával .
Forrás: will.com