🥇Jak zjistit pomocí fio, zda disky mají dostatečný výkon pro etcd

Pozn. přek.: Tento článek shrnuje výsledky mini-výzkumu, který provedli inženýři IBM Cloud, aby našli řešení skutečného problému spojeného s provozem databáze etcd. Pro nás byla relevantní podobná úloha, nicméně myšlenkový a akční postup autorů může být zajímavý i v širším kontextu.

Shrnutí celého článku: fio a etcd

Výkon clustera etcd silně závisí na rychlosti úložiště, na kterém běží. Pro monitorování výkonu etcd exportuje různé metriky Prometheus. Jednou z nich je wal_fsync_duration_seconds. V dokumentaci k etcd se uvádí, že úložiště lze považovat za dostatečně rychlé, pokud 99. percentil této metriky nepřesahuje 10 ms...

Pokud zvažujete možnost vytvoření clusteru etcd na strojích běžících na Linuxu a chcete zjistit, zda jsou úložiště dostatečně rychlá (například SSD), doporučujeme použít populární I/O tester s názvem fio. Stačí spustit následující příkaz (adresář test-data by měl být umístěn ve připojené části testovaného úložiště):

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

Nyní stačí podívat se na výstup a zkontrolovat, zda se 99. percentil fdatasync vejde do 10 ms. Pokud ano, vaše úložiště pracuje 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]

Několik poznámek:

V uvedeném příkladu jsme přizpůsobili parametry --size a --bs pro konkrétní případ. Abyste získali smysluplný výsledek od fio, uveďte hodnoty vhodné pro váš scénář použití. O tom, jak je vybrat, se dozvíte níže.
Během testování pouze fio zatěžuje diskový subsystém. V reálném životě je pravděpodobné, že na disk budou zapisovat i jiné procesy (kromě těch, které souvisejí s wal_fsync_duration_seconds). Taková dodatečná zátěž může vést ke zvýšení wal_fsync_duration_seconds. Jinými slovy, pokud 99. percentil získaný testováním s fio, je jen mírně pod 10 ms, je pravděpodobné, že výkon úložiště není dostatečný.
Pro test budete potřebovat verzi fio nejméně 3.5, protože starší verze neagregují výsledky fdatasync ve formě percentilů.
Výše uvedený výstup představuje pouze malý úryvek celkového výstupu fio.

Podrobnosti o fio a etcd

Několik slov o WAL atd.

Obecně platí, že databáze používají předregistraci do logu (write-ahead logging, WAL). Toto se vztahuje také na etcd. Diskuse o WAL přesahuje rámec tohoto článku, ale pro naše účely potřebujeme vědět následující: každý člen clusteru etcd uchovává WAL v trvalém úložišti. etcd zapisuje některé operace s key-value úložištěm (například aktualizace) do WAL, než je provede. Pokud uzel selže a restartuje se mezi snapshoty, může etcd obnovit transakce provedené od předchozího snapshotu na základě obsahu WAL.

Takže pokaždé, když klient přidá klíč do KV úložiště nebo aktualizuje hodnotu existujícího klíče, etcd přidá popis operace do WAL, který je běžným souborem v trvalém úložišti. Před pokračováním musí být etcd stoprocentně přesvědčena, že zápis do WAL byl skutečně zachován. Aby toho bylo dosaženo v systému Linux, 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 držet zápis WAL v jádrovém cache v paměti po určitou dobu (například v cache stránky). Aby bylo zajištěno, že data jsou zapsána na médium, je nutné po zápisu provést systémové volání fdatasync — to je to, co dělá etcd (jak je vidět na příkladu následujícího výstupu strace; zde 8 — popisovač souboru WAL):

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)            = 0

Bohužel, zápis do trvalého úložiště trvá nějaký čas. Zpoždění volání fdatasync může ovlivnit výkon etcd. V dokumentaci k úložišti je uvedeno, že pro dostatečný výkon je nutné, aby 99. percentil délky všech volání fdatasync při zápisu do souboru WAL byl menší než 10 ms. Existují i další metriky související s úložištěm, ale v tomto článku se budeme zabývat pouze tímto.

Hodnocení úložiště pomocí fio

K ověření, zda je nějaké úložiště vhodné pro použití s etcd, lze použít utilitu fio — populárního I/O testera. Mějte na paměti, že diskový vstup-výstup může probíhat různými způsoby: sync/async, různé třídy systémových volání atd. Druhá strana mince je, že fio je extrémně složitá na použití. Nástroj má mnoho parametrů a různé kombinace jejich hodnot vedou k zcela odlišným výsledkům. Abyste získali rozumné hodnocení v případě etcd, musíte se ujistit, že zátěž pro zápis generovaná fio co nejvíce odpovídá zátěži etcd při zápisu do WAL souborů:

To znamená, že generovaná fio zátěž musí představovat alespoň řadu sekvenčních zápisů do souboru, kde každý zápis se skládá ze systémového volání write, za nímž následuje fdatasync.
Aby bylo možné zahrnout sekvenční zápis, je třeba používat příznak --rw=write.
Aby fio psal pomocí volání write (a ne jiných systémových volání — například, pwrite), použijte příznak --ioengine=sync.
Nakonec příznak --fdatasync=1 zaručuje, že za každým write by mělo fdatasync.
Další dvě parametry v našem příkladu: --size a --bs — mohou se měnit v závislosti na konkrétním scénáři použití. V následující části bude popsáno jejich nastavení.

Proč jsme zvolili fio a jak jsme se naučili jej konfigurovat

Tento poznámka vychází z reálného případu, se kterým jsme se setkali. Měli jsme cluster na Kubernetes v1.13 s monitoringem na Prometheus. Jako úložiště pro etcd v3.2.24 sloužily SSD disky. Metriky etcd ukazovaly příliš vysoké latence fdatasync, i když byl cluster nečinný. Přišly nám tyto metriky velmi podezřelé a nebyli jsme si sure, co přesně představují. Navíc byl cluster složen z virtuálních strojů, takže nebylo možné říci, zda latence byla spojena s virtualizací, nebo zda byly SSD na vině.

Kromě toho jsme zvažovali různé úpravy konfigurace hardwaru a softwaru, takže bylo potřeba způsob, jak je vyhodnotit. Samozřejmě bychom mohli spustit etcd v každé konfiguraci a podívat se na příslušné metriky Prometheus, ale to by vyžadovalo značné úsilí. Potřebovali jsme jednoduchý způsob, jak posoudit konkrétní konfiguraci. Chtěli jsme zkontrolovat naše chápání metrik Prometheus, pocházejících od etcd.

K tomu bylo nutné vyřešit dva problémy:

Za prvé, jak vypadá I/O zatížení generované etcd při zápisu do souborů WAL? Jaké systémové volání jsou použity? Jaká je velikost zapisovacích bloků?
Za druhé, předpokládejme, že máme odpovědi na výše uvedené otázky. Jak reprodukovat odpovídající zatížení s fio? Ведь fio — extrémně flexibilní nástroj s množstvím parametrů (to lze snadno ověřit, například, zde — pozn. překl.).

Obě problémy jsme vyřešili pomocí stejného přístupu, opírajícího se o příkazy lsof a strace:

Pomocí lsof můžeme zobrazit všechny souborové popisovače používané procesem, stejně jako soubory, ke kterým se vztahují.
Pomocí strace můžeme analyzovat již běžící proces nebo spustit proces a sledovat ho. Příkaz vrátí všechna systémová volání provedená tímto procesem a, pokud je to nutné, jeho potomky. To je důležité pro procesy, které fork, a etcd je jedním z těchto procesů.

První věc, kterou jsme udělali, — použili jsme strace k prozkoumání serveru etcd v klastru Kubernetes, zatímco byl nečinný.

Bylo zjištěno, že bloky zápisu do WAL jsou velmi těsně seskupeny, velikost většiny se pohybovala v rozmezí 2200-2400 bajtů. Z tohoto důvodu se v příkazu na začátku tohoto článku používá přepínač --bs=2300 (bs — velikost v bajtech každého zapisovacího bloku v fio).

Upozorňujeme, že velikost bloků zápisu etcd se může lišit v závislosti na verzi, nasazení, hodnotách parametrů atd. — to ovlivňuje trvání fdatasync. Pokud máte podobný scénář použití, analyzujte pomocí strace své procesy etcd, abyste získali aktuální hodnoty.

Pak, abychom získali jasný a komplexní přehled o fungování etcd se souborovým systémem, spustili jsme ho pomocí strace s přepínači -ffttT. To umožnilo pokrýt procesy-potomky a zaznamenat výstup každého do samostatného souboru. Kromě toho byly získány podrobné informace o čase spuštění a trvání každého systémového volání.

Také jsme využili příkaz lsof, abychom potvrdili naše porozumění výstupu strace pokud jde o to, který souborový popisovač byl použit pro jaký účel. Výstup byl strace, podobný tomu, který je uveden výše. Statistické manipulace s časy synchronizace potvrdily, že metrika wal_fsync_duration_seconds od etcd odpovídá voláním fdatasync se souborovými popisovači WAL.

Abychom vygenerovali pomocí fio Pracovní zátěž podobná zátěži z etcd byla prozkoumána dokumentace nástroje a vybrány parametry vhodné pro náš úkol. Ujistili jsme se, že jsou využity potřebné systémové volání, a potvrdili jejich trvání spuštěním fio z strace (jak bylo učiněno v případě etcd).

Zvláštní pozornost byla věnována určení hodnoty parametru --size. Představuje celkovou I/O zátěž generovanou nástrojem 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 volání write (a fdatasync). Pro určité bs počet volání fdatasync je rovno size / bs.

Jelikož nás zajímal percentil, usilovali jsme o to, aby bylo počet zkoušek dostatečně velké pro statistickou významnost. A rozhodli jsme se, že 10^4 (což odpovídá velikosti 22 MB) bude stačit. Menší hodnoty parametru --size vytvářely výraznější šum (například volání fdatasync, která trvají mnohem déle, než je obvyklé, a ovlivňují 99. percentil).

Teď je to na vás

V článku je popsáno, jak pomocí fio lze posoudit, zda je médium dostatečně rychlé pro použití s etcd. Teď je to na vás! Prozkoumat virtuální stroje s úložištěm založeným na SSD lze v službě IBM Cloud.

P.S. od překladatele

Se vzorovými příklady použití fio pro řešení dalších úloh se lze seznámit na dokumentaci nebo přímo na repozitáři projektu. (kde jich je mnohem více, než je zmíněno v dokumentaci).