Rychlost úložiště vhodná pro etcd? Zeptejme se fio

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

Výkon klastru atd do značné míry závisí na výkonu jeho úložiště. etcd exportuje některé metriky do Prometheusposkytnout požadované informace o výkonu úložiště. Například metrika wal_fsync_duration_seconds. Dokumentace pro etcd říká: Aby bylo úložiště považováno za dostatečně rychlé, musí být 99. percentil této metriky menší než 10 ms. Pokud plánujete provozovat cluster etcd na počítačích se systémem Linux a chcete vyhodnotit, zda je vaše úložiště dostatečně rychlé (například SSD), můžete použít Fio je oblíbený nástroj pro testování I/O 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 méně než 10 ms. Pokud ano, máte přiměřeně rychlé úložiště. Zde je příklad výsledků:

  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]

Poznámky

• Přizpůsobili jsme možnosti --size a --bs pro náš konkrétní scénář. Chcete-li získat užitečný výsledek z fio, zadejte své vlastní hodnoty. Kde je získat? Číst jak jsme se naučili konfigurovat fio.
• Během testování pochází veškerá I/O zátěž z fio. V reálném scénáři budou pravděpodobně do úložiště přicházet další požadavky na zápis kromě těch, které se týkají wal_fsync_duration_seconds. Další zatížení zvýší hodnotu wal_fsync_duration_seconds. Pokud se tedy 99. percentil blíží 10 ms, vašemu úložišti dochází rychlost.
• Vezměte verzi Fio ne méně než 3.5 (předchozí nezobrazují percentily trvání fdatasync).
• Výše je jen úryvek výsledků z fio.

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

Co je WAL v etcd

Obvykle používají databáze zápis dopředu; etcd to také používá. Nebudeme zde podrobně rozebírat protokol pro zápis napřed (WAL). Stačí nám vědět, že každý člen clusteru etcd jej udržuje v trvalém úložišti. etcd zapíše každou operaci páru klíč–hodnota (jako je aktualizace) do WAL, než ji aplikuje na úložiště. Pokud některý z členů úložiště selže a restartuje se mezi snímky, může lokálně obnovit transakce od posledního snímku podle obsahu WAL.

Když klient přidá klíč do úložiště klíč-hodnota nebo aktualizuje hodnotu existujícího klíče, etcd zaznamená operaci do WAL, což je běžný soubor v trvalém úložišti. etcd si MUSÍ být před pokračováním ve zpracování zcela jisti, že k záznamu WAL skutečně došlo. V Linuxu na to nestačí jedno systémové volání. zapsat, protože skutečný zápis do fyzického úložiště může být zpožděn. Linux může například nějakou dobu ukládat záznam WAL do mezipaměti v paměti jádra (jako je mezipaměť stránek). A aby byla data přesně zapsána do perzistentního úložiště, je po zápisu potřeba systémové volání fdatasync a etcd ho prostě použije (jak můžete vidět na výsledku práce obejmout, kde 8 je deskriptor souboru WAL):

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>

Bohužel zápis do trvalého úložiště neproběhne okamžitě. Pokud je volání fdatasync pomalé, utrpí výkon systému etcd. Dokumentace pro etcd říkáže úložiště je považováno za dostatečně rychlé, pokud v 99. percentilu trvá volání fdatasync zápis do souboru WAL méně než 10 ms. Existují další užitečné metriky pro ukládání, ale v tomto příspěvku mluvíme pouze o této metrice.

Odhad úložiště s fio

Pokud potřebujete vyhodnotit, zda je vaše úložiště vhodné pro etcd, použijte fio, velmi oblíbený nástroj pro testování zátěže I/O. Je třeba si uvědomit, že diskové operace mohou být velmi odlišné: synchronní a asynchronní, mnoho tříd systémových volání atd. V důsledku toho je použití fio poměrně obtížné. Má mnoho parametrů a různé kombinace jejich hodnot vytvářejí velmi rozdílné I/O zátěže. Chcete-li získat adekvátní hodnoty pro etcd, měli byste se ujistit, že zatížení testovacího zápisu z fio je co nejblíže skutečnému zatížení z etcd při zápisu souborů WAL.

Proto by fio měl minimálně vytvořit zatížení série sekvenčních zápisů do souboru, každý zápis bude sestávat ze systémového volání zapsatnásleduje systémové volání fdatasync. Sekvenční zápisy do fio vyžadují volbu --rw=write. Pro fio použít při zápisu systémové volání write, nikoli napsat, měli byste zadat parametr --ioengine=sync. A konečně, abyste mohli volat fdatasync po každém zápisu, musíte přidat parametr --fdatasync=1. Další dvě možnosti v tomto příkladu (--size a -bs) jsou specifické pro skript. V další části si ukážeme, jak je nastavit.

Proč fio a jak jsme se to naučili nastavovat

V tomto příspěvku popisujeme skutečný případ. Máme klastr Kubernetes v1.13, kterou jsme monitorovali pomocí Prometheus. etcd v3.2.24 byl hostován na SSD. Metriky Etcd ukázaly příliš vysoké latence fdatasync, i když cluster nic nedělal. Metriky byly divné a my jsme vlastně nevěděli, co znamenají. Cluster se skládal z virtuálních strojů, bylo nutné pochopit, v čem je problém: ve fyzických SSD nebo ve virtualizační vrstvě. Kromě toho jsme často prováděli změny v konfiguraci hardwaru a softwaru a potřebovali jsme způsob, jak jejich výsledky vyhodnotit. Mohli bychom spustit etcd v každé konfiguraci a podívat se na metriky Prometheus, ale to je příliš velký problém. Hledali jsme celkem jednoduchý způsob, jak vyhodnotit konkrétní konfiguraci. Chtěli jsme si ověřit, zda správně rozumíme metrikám Prometheus z etcd.

K tomu však musely být vyřešeny dva problémy. Za prvé, jak vypadá I/O zatížení, které etcd vytvoří při zápisu do WAL? Jaká systémová volání se používají? Jaká je velikost záznamů? Za druhé, odpovíme-li na tyto otázky, jak reprodukujeme podobnou pracovní zátěž s fio? Nezapomeňte, že fio je velmi flexibilní nástroj s mnoha možnostmi. Oba problémy jsme vyřešili jedním přístupem – pomocí příkazů také и obejmout. lsof uvádí všechny deskriptory souborů používané procesem a jejich přidružené soubory. A pomocí strace můžete prozkoumat již běžící proces nebo spustit proces a prozkoumat ho. strace vypíše všechna systémová volání ze zkoumaného procesu (a jeho podřízených procesů). To druhé je velmi důležité, protože etcd zaujímá podobný přístup.

Nejprve jsme použili strace k prozkoumání serveru etcd pro Kubernetes, když nebylo zatížení clusteru. 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 položky etcd závisí na verzi etcd, distribuci, 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 získali dobrou představu o tom, co souborový systém etcd dělá, spustili jsme jej pomocí strace a možností -ffttT. Pokusili jsme se tedy prozkoumat podřízené procesy a zaznamenat výstup každého z nich do samostatného souboru a také získat podrobné zprávy o zahájení a trvání každého systémového volání. Použili jsme lsof, abychom potvrdili naši analýzu výstupu strace a zjistili, který deskriptor souboru byl použit pro jaký účel. Takže s pomocí strace byly získány výše uvedené výsledky. Statistika času synchronizace potvrdila, že wal_fsync_duration_seconds z etcd je konzistentní s voláním fdatasync s deskriptory souborů WAL.

Prošli jsme dokumentaci pro fio a vybrali možnosti pro náš skript, aby fio generovalo zatížení podobné etcd. Zkontrolovali jsme také systémová volání a jejich trvání spuštěním fio ze strace, podobně jako etcd.

Pečlivě jsme zvolili hodnotu parametru --size, aby reprezentovala celou I/O zátěž z fio. V našem případě se jedná o celkový počet bajtů zapsaných do úložiště. Ukázalo se, že je přímo úměrná počtu systémových volání zápisu (a fdatasync). Pro určitou hodnotu bs je počet volání fdatasync = velikost/bs. Jelikož nás zajímal percentil, museli jsme mít pro jistotu dostatek vzorků a spočítali jsme, že nám bude stačit 10^4 (to je 22 mebibajtů). Pokud je --size menší, mohou se objevit odlehlé hodnoty (například několik volání fdatasync trvá déle než obvykle a ovlivňuje 99. percentil).

Vyzkoušejte to sami

Ukázali jsme vám, jak používat fio a zjistit, zda je úložiště dostatečně rychlé, aby etcd dobře fungovalo. Nyní si to můžete sami vyzkoušet například pomocí virtuálních strojů s SSD úložištěm IBM Cloud.

Zdroj: www.habr.com