🥇Jak zkontrolovat disky s fio na dostatečný výkon pro atdd

Poznámka. přel.: Tento článek je výsledkem minivýzkumu, který provedli inženýři IBM Cloud při hledání řešení skutečného problému souvisejícího s provozem databáze etcd. Obdobný úkol byl pro nás aktuální, nicméně průběh úvah a jednání autorů může být zajímavý v širším kontextu.

Stručné shrnutí celého článku: fio a etcd

Výkon clusteru etcd je velmi závislý na rychlosti základního úložiště. etcd exportuje různé metriky Prometheus pro sledování výkonu. Jedním z nich je wal_fsync_duration_seconds. V dokumentaci pro etcd říkáže úložiště lze považovat za dostatečně rychlé, pokud 99. percentil této metriky nepřesáhne 10 ms…

Pokud uvažujete o nastavení clusteru etcd na linuxových strojích a chcete otestovat, zda jsou disky (např. SSD) dostatečně rychlé, doporučujeme použít oblíbený I/O tester tzv. Fio. Stačí spustit následující příkaz (adresář test-data musí být umístěn v připojeném oddílu testovaného disku):

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

Zbývá se pouze podívat na výstup a zkontrolovat, zda vyhovuje 99. percentil fdatasync za 10 ms. Pokud ano, pak váš disk funguje dostatečně rychle. Zde je příklad výstupu:

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]

Pár poznámek:

Ve výše uvedeném příkladu jsme upravili parametry --size и --bs pro konkrétní případ. Abychom získali smysluplný výsledek fio, zadejte hodnoty vhodné pro váš případ použití. Jak je vybrat, bude diskutováno níže.
Pouze během testování fio načte diskový subsystém. V reálném životě je pravděpodobné, že na disk budou zapisovat jiné procesy (kromě těch, které se týkají wal_fsync_duration_seconds). Toto dodatečné zatížení se může zvýšit wal_fsync_duration_seconds. Jinými slovy, pokud 99. percentil z testování s fio, jen o něco méně než 10 ms, existuje velká šance, že výkon úložiště není dostatečný.
Pro test budete potřebovat verzi fio ne méně než 3.5, protože starší verze výsledky neshromažďují fdatasync ve formě percentilů.
Výše uvedený závěr je pouze malým úryvkem z obecného závěru fio.

Více o fio a atd

Pár slov o WAL atd

Obecně se používají databáze proaktivní protokolování (logování napřed, WAL). etcd je také ovlivněna. Diskuse o WAL je nad rámec tohoto článku, ale pro naše účely potřebujete vědět, že každý člen klastru etcd ukládá WAL do trvalého úložiště. etcd zapisuje některé operace úložiště klíč-hodnota (jako jsou aktualizace) do WAL před jejich provedením. Pokud se uzel zhroutí a restartuje mezi snímky, etcd bude moci obnovit transakce od předchozího snímku na základě obsahu WAL.

Pokaždé, když klient přidá klíč do úložiště KV nebo aktualizuje hodnotu existujícího klíče, etcd přidá popis operace do WAL, což je běžný soubor v trvalém úložišti. etcd MUSÍ mít 100% jistotu, že záznam WAL byl skutečně uložen, než budete pokračovat. K dosažení tohoto cíle v Linuxu nestačí použít systémové volání write, protože samotná operace zápisu na fyzické médium může být zpožděna. Například Linux může nějakou dobu uchovávat záznam WAL v mezipaměti jádra (např. v mezipaměti stránek). Aby bylo zajištěno, že data budou zapsána na médium, musí být po zápisu vyvoláno systémové volání fdatasync - to je přesně to, co dělá etcd (jak můžete vidět v následujícím výstupu strace; Tady 8 - deskriptor souboru WAL):

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>

Bohužel zápis do trvalého úložiště nějakou dobu trvá. Prodloužené provádění volání fdatasync může ovlivnit výkon etcd. V dokumentaci úložiště uvedeno, že pro dostatečný výkon je nutné, aby 99. percentil doby trvání všech hovorů fdatasync při zápisu do souboru WAL byl kratší než 10 ms. Existují další metriky související s úložištěm, ale tento článek se zaměří na tuto.

Ocenění skladu s fio

Pomocí utility můžete vyhodnotit, zda je určité úložiště vhodné pro použití s etcd Fio — populární I/O tester. Mějte na paměti, že diskový vstup/výstup může probíhat mnoha různými způsoby: synchronizace/asynchronizace, mnoho různých tříd systémového volání a tak dále. Druhá strana mince je taková fio extrémně obtížné použití. Nástroj má mnoho parametrů a různé kombinace jejich hodnot vedou ke zcela odlišným výsledkům. Abyste získali přiměřený odhad pro etcd, musíte se ujistit, že zatížení zápisu generované fio je co nejblíže zatížení zápisu souboru WAL etcd:

To znamená, že vygenerovaný fio zatížení by mělo být alespoň série po sobě jdoucích zápisů do souboru, kde každý zápis sestává ze systémového volání writenásledován fdatasync.
Chcete-li povolit sekvenční zápis, musíte zadat příznak --rw=write.
Že fio psal pomocí hovorů write (spíše než jiná systémová volání – např. pwrite), použijte vlajku --ioengine=sync.
Konečně vlajka --fdatasync=1 zajišťuje, že každý write by fdatasync.
Další dva parametry v našem příkladu jsou: --size и --bs - může se lišit v závislosti na konkrétním případu použití. V další části bude popsána jejich konfigurace.

Proč jsme si vybrali fio a jak jsme se ho naučili nastavit

Tato poznámka pochází ze skutečného případu, se kterým jsme se setkali. Měli jsme cluster na Kubernetes v1.13 s monitorováním na Prometheus. SSD byly použity jako úložiště pro etcd v3.2.24. Metriky Etcd vykazovaly příliš vysoké latence fdatasync, i když byl cluster nečinný. Nám se tyto metriky zdály velmi pochybné a nebyli jsme si jisti, co přesně představují. Cluster se navíc skládal z virtuálních strojů, takže se nedalo říct, zda je zpoždění způsobeno virtualizací, nebo je na vině SSD.

Kromě toho jsme zvažovali různé změny v konfiguraci hardwaru a softwaru, takže jsme potřebovali způsob, jak je vyhodnotit. Samozřejmě by bylo možné spustit etcd v každé konfiguraci a podívat se na odpovídající metriky Prometheus, ale to by vyžadovalo značné úsilí. Potřebovali jsme jednoduchý způsob, jak vyhodnotit konkrétní konfiguraci. Chtěli jsme otestovat, jak rozumíme metrikám Prometheus pocházejícím z etcd.

To vyžadovalo vyřešení dvou problémů:

Za prvé, jak vypadá I/O zátěž generovaná etcd při zápisu do WAL souborů? Jaká systémová volání se používají? Jaká je velikost záznamových bloků?
Za druhé, řekněme, že máme odpovědi na výše uvedené otázky. Jak reprodukovat odpovídající zátěž s fio? Po všem fio — extrémně flexibilní užitné vlastnosti s množstvím parametrů (to lze snadno ověřit např. zde - Cca. překlad.).

Oba problémy jsme vyřešili stejným přístupem založeným na příkazech lsof и strace:

S lsof můžete zobrazit všechny deskriptory souborů používané procesem a také soubory, na které odkazují.
S strace můžete analyzovat již běžící proces nebo spustit proces a sledovat jej. Příkaz zobrazí všechna systémová volání provedená tímto procesem a v případě potřeby i jeho potomky. To druhé je důležité pro procesy, které se rozvětvují, a etcd je jedním z takových procesů.

První věc, kterou jsme udělali, bylo použití strace prozkoumat server etcd v clusteru Kubernetes, když byl nečinný.

Bylo tedy zjištěno, že bloky záznamů WAL jsou velmi hustě seskupeny, velikost většiny byla v rozmezí 2200-2400 bajtů. Proto příkaz na začátku tohoto článku používá příznak --bs=2300 (bs je velikost každého bloku zápisu v bajtech fio).

Vezměte prosím na vědomí, že velikost bloků zápisu etcd se může lišit v závislosti na verzi, nasazení, hodnotách parametrů atd. - ovlivňuje dobu trvání fdatasync. Pokud máte podobný případ použití, analyzujte s strace vaše procesy etcd, abyste získali aktuální hodnoty.

Poté, abychom získali jasnou a komplexní představu o tom, jak etcd funguje se souborovým systémem, začali jsme to zdola strace s vlajkami -ffttT. To umožnilo zachytit podřízené procesy a zapsat výstup každého do samostatného souboru. Kromě toho byly získány podrobné informace o čase zahájení a trvání každého systémového volání.

Použili jsme také příkaz lsofabyste potvrdili, že rozumíte výstupu strace z hlediska toho, který deskriptor souboru byl použit pro jaký účel. Došel jsem k závěru strace, podobný tomu výše. Statistické manipulace s časy synchronizace potvrdily, že metrika wal_fsync_duration_seconds z etcd odpovídá hovorům fdatasync s deskriptory souborů WAL.

Chcete-li generovat pomocí fio pracovní zátěž podobnou té z etcd, byla prostudována dokumentace utility a vybrány parametry vhodné pro náš úkol. Ověřili jsme, že probíhají správná systémová volání, a jejich trvání jsme potvrdili spuštěním fio z strace (jako tomu bylo v případě etcd).

Zvláštní pozornost byla věnována stanovení hodnoty parametru --size. Představuje celkové zatížení I/O generované obslužným programem fio. V našem případě se jedná o celkový počet bajtů zapsaných na médium. Je přímo úměrná počtu hovorů write (a fdatasync). Pro konkrétní bs počet hovorů fdatasync rovná se size / bs.

Jelikož nás zajímal percentil, chtěli jsme, aby počet vzorků byl dostatečně velký, aby byl statisticky významný. A rozhodlo to 10^4 (což odpovídá velikosti 22 MB) postačí. Menší hodnoty parametrů --size vydávaly výraznější hluk (například hovory fdatasync, které trvají mnohem déle než obvykle a ovlivňují 99. percentil).

Je to na tobě

Článek ukazuje, jak používat fio lze posoudit, zda jsou média určená pro použití s etcd dostatečně rychlá. Teď je to na vás! Ve službě můžete prozkoumat virtuální počítače s úložištěm na bázi SSD IBM Cloud.

PS od překladatele

S hotovými případy použití fio Další úkoly viz dokumentace nebo přímo na projektová úložiště (je jich mnohem více, než je uvedeno v dokumentaci).

PPS z překladače

Přečtěte si také na našem blogu:

Zdroj: www.habr.com

Jak zkontrolovat disky s fio na dostatečný výkon pro etcd