🥇Vyhovuje rychlost úložiště pro etcd? Zeptejte se fio

Krátký příběh o fio a etcd

Výkon klastru etcd do značné míry závisí na výkonu jeho úložiště. etcd exportuje některé metriky do Prometheus, aby poskytlo potřebné informace o výkonu úložiště. Například metrika wal_fsync_duration_seconds. V dokumentaci k etcd se uvádí: aby bylo úložiště považováno za dostatečně rychlé, 99. percentil této metriky by měl být menší než 10 ms. Pokud plánujete spustit klastr etcd na strojích Linux a chcete posoudit, zda je vaše úložiště (například SSD) dostatečně rychlé, můžete použít fio — populární nástroj pro testování vstupně-výstupních operací. Spusťte následující příkaz, kde test-data je adresář pod bodem připojení úložiště:

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

Stačí se podívat na výsledky a zkontrolovat, že 99. percentil trvání fdatasync je menší než 10 ms. Pokud ano, máte dostatečně rychlé úložiště. Zde je příklad výsledků:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentily (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]

Poznámky

Nastavili jsme hodnoty parametrů —size a —bs pro naši konkrétní situaci. Chcete-li od fio získat užitečný výsledek, zadejte své hodnoty. Kde je získat? Čtěte, jak jsme se naučili nastavovat fio.
Během testování je veškeré vstupně-výstupní zatížení od fio. V reálném scénáři pravděpodobně budou do úložiště přicházet i další zápisové požadavky kromě těch, které souvisejí s wal_fsync_duration_seconds. Další zatížení zvýší hodnotu wal_fsync_duration_seconds. Pokud se tedy 99. percentil téměř blíží 10 ms, vašemu úložišti nebude rychlost stačit.
Vezměte verzi fio nejméně 3.5 (předchozí nezobrazují percentily trvání fdatasync).
Výše je uveden pouze úryvek výsledků z fio.

Dlouhý příběh o fio a etcd

Co je WAL v etcd

Obvykle databáze používají žurnal předběžného zápisu; etcd jej také využívá. Zde nebudeme podrobně diskutovat o žurnálu pro předběžné zápisy (write-ahead log, WAL). Stačí vědět, že každý člen clusteru etcd jej uchovává v trvalém úložišti. etcd zapíše každou operaci s páry klíč-hodnota (například aktualizaci) do WAL, než je aplikuje do úložiště. Pokud mezi snímky některý člen úložiště havaruje a restartuje se, může lokálně obnovit transakce od posledního snímku na základě obsahu WAL.

Když klient přidá klíč do úložiště párů klíč-hodnota nebo aktualizuje hodnotu existujícího klíče, etcd zaznamená tuto operaci do WAL, což je běžný soubor v trvalém úložišti. Než může pokračovat v zpracování, musí být etcd zcela přesvědčen, že zápis do WAL opravdu proběhl. V systému Linux nestačí k tomu jeden systémový volání write, protože skutečný zápis do fyzického úložiště může být odložen. Například Linux může uchovávat zápis WAL nějakou dobu v cache v paměti jádra (například v cache stránky). A pro to, aby se data správně zapsala do trvalého úložiště, je potřeba systémový volání fdatasync po zápisu, a etcd ho právě používá (jak je vidět ve výsledku strace, kde 8 je deskriptor 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ě neprobíhá okamžitě. Pokud volání fdatasync probíhá pomalu, výkonnost systému etcd klesá. V dokumentaci k etcd se uvádí, že úložiště se považuje za dostatečně rychlé, pokud v 99. percentilech volání fdatasync při zápisu do souboru WAL trvá méně než 10 ms. Existují i další užitečné metriky pro úložiště, ale v tomto příspěvku mluvíme pouze o této metrice.

Ocenění úložiště pomocí fio

Pokud potřebujete zjistit, zda je vaše úložiště vhodné pro etcd, použijte fio - velmi populární nástroj pro testování zátěže vstupu a výstupu. Je třeba mít na paměti, že diskové operace mohou být různorodé: synchronní a asynchronní, různé třídy systémových volání atd. V důsledku toho je fio poměrně složité používat. Má mnoho parametrů a různé kombinace jejich hodnot produkují zcela odlišné zátěže vstupu a výstupu. Pro získání adekvátních čísel pro etcd je třeba zajistit, aby byla zátěž zápisu z fio co nejblíže skutečné zátěži při zápisu souborů WAL.

Fio by tedy měl minimálně vytvářet zátěž ve formě řady sekvenčních operací zápisu do souboru, přičemž každý zápis bude sestávat ze systémového volání write, po kterém následuje systémové volání fdatasync. Pro sekvenční operace zápisu potřebuje fio parametr —rw=write. Aby fio při zápisu používalo systémové volání write, a ne pwrite, je třeba udávat parametr —ioengine=sync. Nakonec, aby se po každém zápisu vyvolal fdatasync, je nutné přidat parametr —fdatasync=1. Dvě další parametry v tomto příkladu (—size a —bs) závisí na konkrétním scénáři. V následující části vysvětlíme, jak je nastavit.

Proč právě fio a jak jsme se ho naučili nastavit

V tomto příspěvku popisujeme skutečný případ. Měli jsme cluster Kubernetes v1.13, který jsme monitorovali pomocí Prometheus. etcd v3.2.24 byl umístěn na SSD. Metričky pro etcd ukazovaly příliš vysoké zpoždění pro fdatasync, i když cluster nic nedělal. Metričky byly podivné a vlastně jsme nevěděli, co znamenají. Cluster se skládal z virtuálních strojů, bylo třeba pochopit, kde je problém: v fyzických SSD nebo v vrstvě virtualizace. Navíc jsme často měnili konfiguraci hardwaru a softwaru a potřebovali jsme způsob, jak hodnotit jejich výsledky. Mohli jsme spustit etcd v každé konfiguraci a sledovat metriky Prometheus, ale to bylo příliš obtížné. Hledali jsme dostatečně jednoduchý způsob, jak hodnotit konkrétní konfiguraci. Chtěli jsme zjistit, zda správně chápeme metriky Prometheus od etcd.

Ale k tomu bylo třeba vyřešit dva problémy. Za prvé, jak vypadá zatížení vstupu a výstupu, které etcd vytváří při zápisu do WAL? Jaké systémové volání se používají? Jaká je velikost záznamů? Za druhé, pokud odpovíme na tyto otázky, jak reprodukovat podobné pracovní zatížení pomocí fio? Nezapomeňte, že fio je velmi flexibilní nástroj s mnoha parametry. Obě problémy jsme vyřešili jedním přístupem – pomocí příkazů. lsof a strace. lsof zobrazuje všechny deskriptory souborů používané procesem a související soubory. A pomocí strace lze zkoumat již spuštěný proces nebo spustit proces a prozkoumat jej. strace vypisuje všechna systémová volání zkoumaného procesu (a jeho potomků). To poslední je velmi důležité, protože etcd přistupuje přesně tímto způsobem.

Nejprve jsme použili strace k analýze serveru etcd pro Kubernetes, když na kluster nebylo zatížení. Viděli jsme, že téměř všechny záznamy WAL byly přibližně stejné velikosti: 2200–2400 bajtů. Proto jsme v příkazu na začátku příspěvku uvedli parametr –bs=2300 (bs znamená velikost v bajtech pro každý záznam fio). Všimněte si, že velikost záznamu etcd závisí na verzi etcd, dodávce, hodnotách parametrů atd. a ovlivňuje dobu trvání fdatasync. Pokud máte podobný scénář, prozkoumejte své procesy etcd pomocí strace, abyste zjistili přesná čísla.

Poté, abychom si dobře představili akce v souborovém systému etcd, spustili jsme ji se strace a s parametry -ffttT. Tak jsme se pokusili prozkoumat potomky a zaznamenat výstupy každého z nich do samostatného souboru a také získat podrobné zprávy o začátku a trvání každého systémového volání. Použili jsme lsof k potvrzení naší analýzy výstupů strace a k zjištění, který deskriptor souboru se pro jaké účely používal. Takto jsme se pomocí strace dostali k výše uvedeným výsledkům. Statistika ohledně doby synchronizace potvrdila, že údaj wal_fsync_duration_seconds z etcd odpovídá voláním fdatasync s deskriptory souborů WAL.

Prozkoumali jsme dokumentaci k fio a vybrali parametry pro náš scénář, aby fio vygeneroval zatížení podobné etcd. Také jsme zkontrolovali systémová volání a jejich délku tím, že jsme spustili fio z strace, obdobně jako s etcd.

Pečlivě jsme vybrali hodnotu parametru —size, který představuje celkové zatížení vstupem a výstupem od fio. V našem případě se jedná o celkový počet bajtů zapsaných do úložiště. Ten se ukázal jako přímo úměrný počtu systémových volání write (a fdatasync). Pro určitou hodnotu bs je počet volání fdatasync = size/bs. Jelikož nás zajímal percentil, potřebovali jsme mít dostatek vzorků pro spolehlivost a spočítali jsme, že nám bude stačit 10^4 (to vychází na 22 mebibajtů). Pokud je —size menší, mohou se objevit výkyvy (například několik volání fdatasync trvá déle než obvykle a ovlivňuje 99. percentil).

Vyzkoušejte sami

Ukázali jsme, jak používat fio a zjistit, zda úložiště má rychlost potřebnou pro vysoký výkon etcd. Nyní si to můžete vyzkoušet v praxi sami, například použitím virtuálních strojů s úložištěm SSD v IBM Cloud.

Zdroj: habr.com