In koart ferhaal oer fio en ensfh
Cluster prestaasjes foar in grut part hinget ôf fan de prestaasjes fan syn opslach. etcd eksportearret guon metriken nei om de ynformaasje oer opslachprestaasjes te leverjen dy't jo nedich binne. Bygelyks, de metrike wal_fsync_duration_seconds. : Om opslach rap genôch te beskôgjen, moat it 99e percentile fan dizze metrike minder wêze as 10 ms. As jo fan plan binne in etcd-kluster op Linux-masines út te fieren en wolle evaluearje oft jo opslach (lykas in SSD) rap genôch is, kinne jo brûke is in populêr ark foar it testen fan I / O-operaasjes. Rin it folgjende kommando út, wêrby't testgegevens de map is ûnder it opslachpunt:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestJo moatte gewoan nei de resultaten sjen en kontrolearje dat de 99e percentile fan 'e doer minder as 10 ms. As ja, jo hawwe fluch genôch opslach. Hjir is in foarbyld fan de resultaten:
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]Notysjes
- Wy hawwe de wearden fan 'e parameters -size en -bs oanpast foar ús spesifike senario. Fio jo wearden yn om nuttige resultaten fan fio te krijen. Wêr kin ik se krije? Lêze, .
- Tidens testen komt alle I/O-load fan fio. Yn in real-life senario sille d'r wierskynlik oare skriuwfersiken yn 'e opslach komme dan dy ferbûn mei wal_fsync_duration_seconds. Ekstra lading sil de wal_fsync_duration_seconds wearde ferheegje. Dus as it 99e percentile hast 10ms is, is jo opslach net rap genôch.
- Nim de ferzje net minder as 3.5 (de foargeande litte gjin fdatasync-doerpersentilen sjen).
- Hjirboppe is mar in stikje resultaten fan fio.
Lang ferhaal oer fio en ensfh
Wat is WAL yn etcd
Typysk wurde databases brûkt ; etcd brûkt it ek. Wy sille hjir net yn detail it skriuwen-foarút-log (WAL) besprekke. It is genôch foar ús om te witten dat elk lid fan 'e etcd-kluster it ûnderhâldt yn oanhâldende opslach. etcd skriuwt elke operaasje op kaai-wearde-pearen (lykas update) nei WAL foardat se tapast wurde op 'e winkel. As ien fan 'e opslachleden crasht en opnij begjint tusken snapshots, kin it lokaal transaksjes fan' e lêste momintopname weromsette mei de ynhâld fan 'e WAL.
As in kliïnt in kaai taheakket oan in kaai-wearde-winkel of de wearde fan in besteande kaai bywurket, skriuwt etcd in rekord fan dizze operaasje nei WAL, dat is in gewoane triem yn persistente opslach. etcd MOET folslein wis wêze dat it WAL-skriuwen wirklik barde foardat it ferwurkjen trochgiet. Yn Linux is ien systeemoprop hjir net genôch foar , om't it feitlik skriuwen nei de fysike opslach kin wurde fertrage. Linux kin bygelyks in WAL-yngong tydlik opslaan yn in cache yn kernelûnthâld (lykas de side-cache). En om de gegevens krekt te skriuwen nei persistente opslach, is de fdatasync-systeemoprop nedich nei opname, en etcd brûkt it gewoan (lykas kin wurde sjoen as gefolch fan it wurk , wêr't 8 in WAL-beskriuwing is):
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>Spitigernôch is skriuwen nei persistente opslach net daliks. As de fdatasync-oprop traach is, sil etcd-systeemprestaasjes degradearje. dat de opslach rap genôch wurdt beskôge as it 99e percentile fan fdatasync-oproppen minder dan 10 ms nimt om nei it WAL-bestân te skriuwen. D'r binne oare nuttige opslachmetriken, mar dit is de ienige metrik wêr't wy it oer hawwe yn dizze post.
Opslach evaluaasje mei help fan fio
As jo moatte evaluearje oft jo opslach is geskikt foar etcd, brûk fio, in hiel populêr I / O load testing ark. It moat betocht wurde dat skiif operaasjes kinne hiel oars: syngroane en asynchronous, in protte klassen fan systeem calls, ensfh As gefolch, fio is frij lestich te brûken. It hat in protte parameters, en ferskate kombinaasjes fan har wearden produsearje heul ferskillende I / O-workloads. Om adekwate sifers foar etcd te krijen, moatte jo derfoar soargje dat de testskriuwlast fan fio sa ticht mooglik is by de werklike lading fan etcd by it skriuwen fan WAL-bestannen.
Dêrom moat fio op syn minst in lading generearje fan in oantal opienfolgjende skriuwwizen nei it bestân, elk skriuw dat bestiet út in systeemoprop folge troch de fdatasync-systeemoprop. Foar sekwinsjele fio-skriuwt is de --rw=skriuwopsje fereaske. Dat fio brûkt de skriuwsysteemoprop by it skriuwen, ynstee fan , is it wurdich om de parameter -ioengine=sync. Uteinlik, om fdatasync nei elk skriuwen op te roppen, moatte jo de opsje --fdatasync=1 taheakje. De oare twa opsjes yn dit foarbyld (--grutte en -bs) binne senario-spesifyk. Yn 'e folgjende seksje sille wy jo sjen litte hoe't jo se ynstelle.
Wêrom fio en hoe't wy learden it te konfigurearjen
Yn dizze post beskriuwe wy in echte saak. Wy hiene in kluster v1.13, dy't wy kontroleare mei Prometheus. etcd v3.2.24 waard hosted op in SSD. Etcd-metriken lieten te hege latency sjen foar fdatasync, sels as it kluster neat die. De metriken wiene frjemd en wy wisten net echt wat se betsjutte. It kluster bestie út firtuele masines, it wie nedich om te begripen wat it probleem wie: yn 'e fysike SSD's of yn' e virtualisaasjelaach. Derneist hawwe wy faak wizigingen makke oan hardware- en softwarekonfiguraasjes, en wy hiene in manier nedich om har resultaten te evaluearjen. Wy koenen rinne etcd yn elke konfiguraasje en sjoch nei de Prometheus-metriken, mar dit is te folle fan in gedoe. Wy sochten in frij ienfâldige manier om in spesifike konfiguraasje te evaluearjen. Wy woenen kontrolearje oft wy de Prometheus-metriken fan etcd goed begripe.
Mar dêrfoar wie it nedich om twa problemen op te lossen. Earst, wat is de I/O-lading dy't etcd makket by it skriuwen nei WAL? Hokker systeemoproppen wurde brûkt? Hokker grutte binne de berjochten? As twadde, as wy dizze fragen beäntwurdzje, hoe kinne wy dan in ferlykbere wurkdruk reprodusearje mei fio? Ferjit net dat fio in heul fleksibel ark is mei in protte opsjes. Wy hawwe beide problemen oplost mei ien oanpak - gebrûk fan kommando's и . lsof toant alle triembeskriuwings dy't brûkt wurde troch in proses en de byhearrende bestannen. En mei strace kinne jo in al rinnend proses studearje of in proses begjinne en it studearje. strace printsje alle systeemoproppen út it proses dat wurdt bestudearre (en har bernprosessen). Dat lêste is tige wichtich, om't etcd in ferlykbere oanpak nimt.
It earste ding dat wy diene wie strace te brûken om de etcd-tsjinner foar Kubernetes te studearjen as d'r gjin lêst wie op it kluster. Wy seagen dat hast alle WAL-records sawat deselde grutte wiene: 2200–2400 bytes. Dêrom hawwe wy yn it kommando oan it begjin fan 'e post de parameter -bs=2300 opjûn (bs betsjut de grutte yn bytes foar elke fio-yngong). Tink derom dat de grutte fan 'e etcd-yngong hinget ôf fan' e etcd-ferzje, skipfeart, parameterwearden, ensfh.. en beynfloedet de doer fan fdatasync. As jo in ferlykber senario hawwe, ûndersiikje jo etcd-prosessen mei strace om de krekte nûmers út te finen.
Dan, om in goed idee te krijen fan wat it etcd-bestânsysteem docht, rûnen wy it mei strace en de -ffttT-opsjes. Sa hawwe wy besocht de bernprosessen te studearjen en de útfier fan elk fan har op te nimmen yn in apart bestân, en ek detaillearre rapporten te krijen oer it begjin en de doer fan elke systeemoprop. Wy brûkten lsof om ús analyze fan 'e strace-útfier te befêstigjen en te sjen hokker bestânbeskriuwing foar hokker doelen waard brûkt. Dat, mei strace, krigen wy de hjirboppe werjûn resultaten. Syngronisaasjetiidstatistiken befêstige dat de wal_fsync_duration_seconds metryske fan etcd oerienkomt mei fdatasync-oproppen mei WAL-beskriuwers.
Wy seagen nei de fio dokumintaasje en keas de parameters foar ús skript sadat fio soe generearje in lading fergelykber mei etcd. Wy hawwe ek kontrolearre systeem oproppen en harren doer troch rinne fio út strace, fergelykber mei etcd.
Wy selekteare soarchfâldich de wearde fan 'e parameter --size, dy't de folsleine I/O-lading fan 'e fio fertsjintwurdiget. Yn ús gefal is dit it totale oantal bytes skreaun nei de opslach. It die bliken direkt evenredich te wêzen mei it oantal skriuw (en fdatasync) systeemoproppen. Foar in bepaalde wearde fan bs is it oantal oproppen nei fdatasync = grutte/bs. Sûnt wy wiene ynteressearre yn de percentile, wy moatte hawwe genôch samples te wêzen betrouber, en wy berekkene dat 10 ^ 4 soe wêze genôch foar ús (dat is 22 mebibytes). As --size lytser is, kinne outliers foarkomme (bygelyks ferskate fdatasync-oanroppen nimme langer dan gewoanlik en beynfloedzje it 99e percentile).
Besykje it sels
Wy lieten sjen hoe't jo fio brûke en útfine as de opslach fluch genôch is foar etcd om goed te prestearjen. No kinne jo dit sels yn 'e praktyk besykje, mei bygelyks firtuele masines mei SSD-opslach yn .
Boarne: www.habr.com