🥇Wéi kontrolléiert d'Disks mat fio fir genuch Leeschtung fir etcd

Note. iwwersat.: Dësen Artikel ass d'Resultat vun enger Mini-Fuerschung duerchgefouert vun IBM Cloud Ingenieuren op der Sich no enger Léisung fir e reelle Problem am Zesummenhang mat der Operatioun vun der etcd Datebank. Eng ähnlech Aufgab war fir eis relevant, awer de Verlaf vun de Reflexiounen an Handlungen vun den Auteuren kann an engem méi breede Kontext interessant sinn.

Kuerz Resumé vum ganzen Artikel: fio an etc

D'Performance vun engem etcd Stärekoup ass héich ofhängeg vun der Geschwindegkeet vun der Basislagerung. etcd exportéiert verschidde Prometheus Metriken fir d'Leeschtung ze iwwerwaachen. Ee vun hinnen ass wal_fsync_duration_seconds. An der Dokumentatioun fir etcd et seetdatt d'Späichere séier genuch ugesi ka ginn wann den 99. Percentil vun dëser Metrik net méi wéi 10 ms ass ...

Wann Dir drun denkt en etcd Cluster op Linux Maschinnen opzestellen a wëllt iwwerpréiwen ob Drive (wéi SSDs) séier genuch sinn, empfeelen mir de populäre I/O Tester genannt fio. Et ass genuch fir de folgende Kommando (Verzeichnis test-data muss an der montéierter Partition vum getestten Drive lokaliséiert sinn):

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

Et bleift just fir d'Ausgab ze kucken a kucken ob den 99. Prozentsaz passt fdatasync op 10 ms. Wann jo, da funktionnéiert Ären Drive séier genuch. Hei ass e Beispill Ausgang:

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]

E puer Notizen:

Am uewe genannte Beispill hu mir d'Parameteren ugepasst --size и --bs fir e spezifesche Fall. Fir e sënnvoll Resultat vun fio, spezifizéiert Wäerter passend fir Äre Gebrauchsfall. Wéi Dir se auswielen wäert ënnert diskutéiert ginn.
Nëmme während dem Test fio lued den Disk Subsystem. Am richtege Liewen ass et méiglech datt aner Prozesser op Disk schreiwen (ausser deenen am Zesummenhang mat wal_fsync_duration_seconds). Dës zousätzlech Belaaschtung kann eropgoen wal_fsync_duration_seconds. An anere Wierder, wann der 99. percentile aus Testen mat fio, nëmme liicht manner wéi 10 ms, ass et eng gutt Chance datt d'Späicherleistung net genuch ass.
Fir den Test braucht Dir d'Versioun fio net manner wéi 3.5, well méi al Versioune keng Resultater aggregéieren fdatasync a Form vu Prozenter.
Déi uewe genannte Conclusioun ass nëmmen e klengen Auszuch aus der allgemenger Conclusioun fio.

Méi iwwer fio an etcd

E puer Wierder iwwer WALs etcd

Allgemeng benotzen Datenbanken proaktiv Logged (Write-ahead Logging, WAL). etcd ass och betraff. Eng Diskussioun iwwer WAL ass iwwer den Ëmfang vun dësem Artikel, awer fir eis Zwecker, wat Dir wësse musst ass datt all etcd Cluster Member WAL a persistent Späichere späichert. etcd schreift e puer Schlësselwäert Späicheroperatiounen (wéi Updates) op WAL ier se ausgefouert ginn. Wann e Knuet kraazt an nei opstinn tëscht Snapshots, etcd kann Transaktiounen zanter dem fréiere Snapshot recuperéieren baséiert op den Inhalt vun der WAL.

Also, all Kéier wann e Client e Schlëssel zum KV Store bäidréit oder de Wäert vun engem existente Schlëssel aktualiséiert, etcd d'Beschreiwung vun der Operatioun op d'WAL bäidréit, wat eng regulär Datei am persistent Store ass. etcd MUSS 100% sécher sinn datt d'WAL Entrée tatsächlech gespäichert gouf ier Dir weidergeet. Fir dëst op Linux z'erreechen, ass et net genuch fir de Systemruff ze benotzen write, well d'Schreifoperatioun selwer op déi kierperlech Medien kann verspéit ginn. Zum Beispill, Linux kann eng WAL Entrée an engem In-Memory Kernel Cache (zB am Säit Cache) fir eng Zäit halen. Fir sécherzestellen datt d'Donnéeën an d'Medien geschriwwe ginn, muss e Systemruff nom Schreiwen opgeruff ginn fdatasync - dat ass genau wat etcd mécht (wéi Dir kënnt an der folgender Ausgab gesinn strace; Hei 8 - WAL Dateibeschreiwung):

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>

Leider hëlt d'Schreiwen op persistent Späichere e bëssen Zäit. Verlängert Ausféierung vu fdatasync Uriff kann d'Leeschtung vun etcd beaflossen. An der Dokumentatioun vum Repository uginn, datt fir genuch Leeschtung et néideg ass, datt den 99. percentile vun der Dauer vun all Uruff fdatasync beim Schreiwen op eng WAL Datei war manner wéi 10 ms. Et ginn aner Späicherbezunnen Metriken, awer dësen Artikel konzentréiert sech op déi.

Wäerter Lagerung mat Fio

Dir kënnt evaluéieren ob eng gewësse Späichere gëeegent ass fir mat etcd ze benotzen mat dem Utility fio - e populäre I/O Tester. Denkt drun datt Disk I / O op vill verschidde Weeër ka geschéien: Synchroniséierung / Async, vill verschidde Syscall Klassen, etc. Déi aner Säit vun der Mënz ass dat fio extrem schwéier ze benotzen. D'Utility huet vill Parameteren, a verschidde Kombinatioune vun hire Wäerter féieren zu komplett aner Resultater. Fir eng raisonnabel Schätzung fir etcd ze kréien, musst Dir sécher sinn datt d'Schreiflaascht generéiert vu fio sou no wéi méiglech un etcd's WAL Datei Schreiflast ass:

Dat heescht, datt déi generéiert fio d'Laascht soll op d'mannst eng Serie vu konsekutiv Schreiwen op d'Datei sinn, wou all Schreiwen aus engem Systemruff besteet writegefollegt vun fdatasync.
Fir sequenziell Schreiwen z'aktivéieren, musst Dir de Fändel uginn --rw=write.
datt fio geschriwwen mat Uriff write (anstatt aner Systemruffen - z.B. pwrite), benotzt de Fändel --ioengine=sync.
Endlech, de Fändel --fdatasync=1 garantéiert datt all write muss fdatasync.
Déi aner zwee Parameteren an eisem Beispill sinn: --size и --bs - kann ofhängeg vum spezifesche Gebrauchsfall variéieren. Déi nächst Sektioun wäert hir Konfiguratioun beschreiwen.

Firwat hu mir de Fio gewielt a wéi mir geléiert hunn wéi et opgestallt gëtt

Dës Notiz kënnt aus engem richtege Fall dee mir begéint hunn. Mir haten e Cluster op Kubernetes v1.13 mat Iwwerwaachung op Prometheus. SSDs goufen als Stockage fir etcd v3.2.24 benotzt. Etcd Metriken hunn ze héich latencies gewisen fdatasync, och wann de Stärekoup Idle war. Fir eis schéngen dës Metriken ganz zweifelhaft, a mir waren net sécher wat se genau representéiert hunn. Ausserdeem bestoung de Cluster aus virtuelle Maschinnen, sou datt et net méiglech war ze soen ob d'Verzögerung wéinst der Virtualiséierung oder der SSD d'Schold war.

Zousätzlech hu mir verschidde Hardware- a Softwarekonfiguratiounsännerunge berücksichtegt, also brauche mir e Wee fir se ze evaluéieren. Natierlech wier et méiglech, etcd an all Konfiguratioun ze lafen an déi entspriechend Prometheus Metriken ze kucken, awer dat wäert bedeitend Effort erfuerderen. Wat mir gebraucht hunn, war en einfache Wee fir eng spezifesch Konfiguratioun ze evaluéieren. Mir wollten eist Verständnis vun de Prometheus Metriken testen, déi aus etcd kommen.

Dëst erfuerdert zwee Probleemer ze léisen:

Als éischt, wéi gesäit d'I/O-Laascht aus, generéiert vun etcd beim Schreiwen op WAL Dateien? Wat System Appellen ginn benotzt? Wat ass d'Gréisst vun de Rekordblocken?
Zweetens, loosst eis soen datt mir Äntwerten op déi uewe genannte Froen hunn. Wéi reproduzéieren déi entspriechend Laascht mat fio? Schliisslech fio - extrem flexibel Utility mat enger Iwwerfloss vu Parameteren (dëst ass einfach ze verifizéieren, z.B. hei - ca. Iwwersetzung).

Mir geléist béid Problemer mat der selwechter Kommando-baséiert Approche lsof и strace:

Mat der Hëllef vun lsof Dir kënnt all Dateibeschreiwunge kucken, déi vum Prozess benotzt ginn, souwéi d'Dateien op déi se bezéien.
Mat der Hëllef vun strace Dir kënnt e scho lafende Prozess analyséieren oder e Prozess lafen a kucken. De Kommando weist all System Uruff, déi vun dësem Prozess gemaach goufen an, wann néideg, seng Nokommen. Déi lescht ass wichteg fir Prozesser déi forking sinn, an etcd ass ee sou Prozess.

Déi éischt Saach, déi mir gemaach hunn, war ze benotzen strace fir den etcd-Server am Kubernetes-Cluster z'iwwerpréiwen, während et idle war.

Also gouf festgestallt datt WAL Rekordblocken ganz dicht gruppéiert sinn, d'Gréisst vun der Majoritéit war am Beräich vun 2200-2400 Bytes. Dofir benotzt de Kommando am Ufank vun dësem Artikel de Fändel --bs=2300 (bs ass d'Gréisst an Bytes vun all Schreifblock an fio).

Notéiert w.e.g. datt d'Gréisst vun etcd Schreifblocken variéiere kënnen ofhängeg vun der Versioun, Ofbau, Parameterwäerter, etc. - et beaflosst d'Dauer fdatasync. Wann Dir eng ähnlech Benotzungsfall hutt, analyséiert mat strace Är etcd Prozesser fir aktuell Wäerter ze kréien.

Dann, fir eng kloer an ëmfaassend Iddi ze kréien wéi etcd mam Dateiesystem funktionnéiert, hu mir et vun ënnen ugefaangen strace mat Fändelen -ffttT. Dëst huet et méiglech gemaach Kannerprozesser z'erfaassen an d'Ausgab vun all eenzel op eng separat Datei ze schreiwen. Zousätzlech gouf detailléiert Informatiounen iwwer d'Startzäit an d'Dauer vun all Systemruff kritt.

Mir hunn och de Kommando benotzt lsoffir Äert Verständnis vun der Ausgab ze bestätegen strace a punkto wéi eng Dateideskriptor fir wéi en Zweck benotzt gouf. Ech krut d'Conclusioun strace, ähnlech wéi déi hei uewen. Statistesch Manipulatioune mat Synchroniséierungszäiten bestätegt datt d'Metrik wal_fsync_duration_seconds aus etcd Matcher rifft fdatasync mat WAL Datei Descriptoren.

Ze generéieren mat fio eng Aarbechtsbelaaschtung ähnlech wéi déi vun etcd, d'Dokumentatioun vum Utility gouf studéiert an d'Parameteren gëeegent fir eis Aufgab goufen ausgewielt. Mir hunn verifizéiert datt déi richteg Systemuriff amgaang sinn a bestätegt hir Dauer andeems se lafen fio aus strace (wéi et am Fall vun etcd gemaach gouf).

Besonnesch Opmierksamkeet gouf bezuelt fir de Wäert vum Parameter ze bestëmmen --size. Et representéiert déi total I/O Belaaschtung generéiert vum fio Utility. An eisem Fall ass dëst d'Gesamtzuel vun de Bytes, déi an d'Medien geschriwwe sinn. Et ass direkt proportional zu der Unzuel vun Uriff write (an fdatasync). Fir eng spezifesch bs Zuel vun Uriff fdatasync gläicht size / bs.

Well mir un de Prozentsaz interesséiert waren, wollte mir datt d'Zuel vun de Proben grouss genuch wier fir statistesch bedeitend ze sinn. An decidéiert dat 10^4 (wat enger Gréisst vun 22 MB entsprécht) wäert duergoen. Méi kleng Parameter Wäerter --size huet méi ausgeschwat Kaméidi (zum Beispill Uriff fdatasync, déi vill méi laang daueren wéi soss an den 99. Prozentsaz beaflossen).

Et hänkt un dir

Den Artikel weist wéi Dir benotzt fio ee kann beurteelen ob d'Medien, déi fir mat etcd benotzt gi sinn, séier genuch sinn. Elo ass et un Iech! Dir kënnt virtuell Maschinnen mat SSD-baséiert Späicheren am Service entdecken IBM Cloud.

PS vum Iwwersetzer

Mat prett-feieren Benotzung Fäll fio Fir aner Aufgaben, kuckt Dokumentatioun oder direkt un Projet Repositories (et gi vill méi vun hinnen wéi an der Dokumentatioun ernimmt).

PPS vum Iwwersetzer

Liest och op eisem Blog:

Source: will.com

Wéi kontrolléiert Disken mat fio fir genuch Leeschtung fir etcd