🥇Ako skontrolovať disky s fio na dostatočný výkon pre etcd

Poznámka. preklad.: Tento článok je výsledkom minivýskumu, ktorý vykonali inžinieri IBM Cloud pri hľadaní riešenia skutočného problému súvisiaceho s prevádzkou databázy etcd. Podobná úloha bola pre nás aktuálna, avšak priebeh úvah a konania autorov môže byť zaujímavý v širšom kontexte.

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

Výkon klastra etcd veľmi závisí od rýchlosti základného úložiska. etcd exportuje rôzne metriky Prometheus na monitorovanie výkonu. Jedným z nich je wal_fsync_duration_seconds. V dokumentácii pre atď hovoríže ukladanie možno považovať za dostatočne rýchle, ak 99. percentil tejto metriky nepresiahne 10 ms…

Ak uvažujete nad nastavením klastra etcd na strojoch so systémom Linux a chcete otestovať, či sú disky (napríklad SSD) dostatočne rýchle, odporúčame použiť populárny I/O tester tzv. Fio. Stačí spustiť nasledujúci príkaz (adresár test-data musí byť umiestnený v pripojenej partícii testovaného disku):

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

Zostáva len pozrieť sa na výstup a skontrolovať, či vyhovuje 99. percentil fdatasync za 10 ms. Ak áno, potom váš disk funguje dostatočne rýchlo. Tu je prí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ámok:

Vo vyššie uvedenom príklade sme upravili parametre --size и --bs pre konkrétny prípad. Ak chcete získať zmysluplný výsledok fio, zadajte hodnoty vhodné pre váš prípad použitia. Ako si ich vybrať, bude diskutované nižšie.
Len počas testovania fio načíta diskový subsystém. V reálnom živote je pravdepodobné, že na disk budú zapisovať aj iné procesy (okrem tých, ktoré súvisia s wal_fsync_duration_seconds). Toto dodatočné zaťaženie sa môže zvýšiť wal_fsync_duration_seconds. Inými slovami, ak 99. percentil z testovania s fio, len o niečo menej ako 10 ms, existuje veľká šanca, že výkon úložiska nie je dostatočný.
Na test budete potrebovať verziu fio nie nižší ako 3.5, pretože staršie verzie nezhromažďujú výsledky fdatasync vo forme percentilov.
Vyššie uvedený záver je len malým úryvkom zo všeobecného záveru fio.

Viac o fio a atď

Pár slov o WAL atď

Vo všeobecnosti databázy používajú proaktívne protokolovanie (zápis vopred, WAL). etcd je tiež ovplyvnená. Diskusia o WAL presahuje rámec tohto článku, ale pre naše účely potrebujete vedieť, že každý člen klastra etcd ukladá WAL do trvalého úložiska. etcd zapíše niektoré operácie kľúč-hodnota úložiska (ako sú aktualizácie) do WAL pred ich vykonaním. Ak uzol zlyhá a reštartuje sa medzi snímkami, etcd bude môcť obnoviť transakcie od predchádzajúcej snímky na základe obsahu WAL.

Zakaždým, keď klient pridá kľúč do úložiska KV alebo aktualizuje hodnotu existujúceho kľúča, etcd pridá popis operácie do WAL, čo je bežný súbor v trvalom úložisku. atď. Pred pokračovaním MUSÍ byť 100% istota, že záznam WAL bol skutočne uložený. Na dosiahnutie tohto cieľa v systéme Linux nestačí použiť systémové volanie write, pretože samotná operácia zápisu na fyzické médium môže byť oneskorená. Napríklad, Linux môže nejaký čas uchovávať záznam WAL vo vyrovnávacej pamäti jadra (napr. vo vyrovnávacej pamäti stránok). Aby sa zabezpečilo, že sa údaje zapíšu na médium, po zápise musí byť vyvolané systémové volanie fdatasync - presne toto robí etcd (ako môžete vidieť v nasledujúcom výstupe strace; Tu 8 - deskriptor súboru 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žiaľ, zápis do trvalého úložiska nejaký čas trvá. Predĺžené vykonávanie volaní fdatasync môže ovplyvniť výkon etcd. V dokumentácii k úložisku uvedené, že pre dostatočný výkon je potrebné, aby 99. percentil dĺžky trvania všetkých hovorov fdatasync pri zápise do súboru WAL bol kratší ako 10 ms. Existujú aj ďalšie metriky súvisiace s ukladaním, ale tento článok sa zameria na túto.

Ocenenie skladu s fio

Pomocou pomôcky môžete vyhodnotiť, či je určité úložisko vhodné na použitie s etcd Fio — populárny I/O tester. Majte na pamäti, že diskový vstup/výstup môže prebiehať mnohými rôznymi spôsobmi: synchronizácia/asynchronizácia, mnoho rôznych tried systémových volaní atď. Druhá strana mince je taká fio extrémne náročné na používanie. Nástroj má veľa parametrov a rôzne kombinácie ich hodnôt vedú k úplne odlišným výsledkom. Ak chcete získať primeraný odhad pre etcd, musíte sa uistiť, že zaťaženie zápisu generované fio je čo najbližšie k zaťaženiu zápisu súboru WAL etcd:

To znamená, že vygenerovaný fio zaťaženie by malo byť aspoň séria po sebe idúcich zápisov do súboru, kde každý zápis pozostáva zo systémového volania writenasledovaný fdatasync.
Ak chcete povoliť sekvenčný zápis, musíte zadať príznak --rw=write.
Že fio písal pomocou hovorov write (namiesto iných systémových volaní – napr. pwrite), použite vlajku --ioengine=sync.
Nakoniec vlajka --fdatasync=1 zabezpečuje, že každý write musí byť fdatasync.
Ďalšie dva parametre v našom príklade sú: --size и --bs - môže sa líšiť v závislosti od konkrétneho prípadu použitia. V ďalšej časti bude popísaná ich konfigurácia.

Prečo sme si vybrali fio a ako sme sa ho naučili nastaviť

Táto poznámka pochádza zo skutočného prípadu, s ktorým sme sa stretli. Mali sme klaster na Kubernetes v1.13 s monitorovaním na Prometheus. SSD boli použité ako úložisko pre etcd v3.2.24. Metriky Etcd vykazovali príliš vysoké latencie fdatasync, aj keď bol klaster nečinný. Nám sa tieto metriky zdali veľmi pochybné a neboli sme si istí, čo presne predstavujú. Cluster navyše pozostával z virtuálnych strojov, takže sa nedalo povedať, či je oneskorenie spôsobené virtualizáciou alebo je na vine SSD.

Okrem toho sme zvažovali rôzne zmeny v konfigurácii hardvéru a softvéru, takže sme potrebovali spôsob, ako ich vyhodnotiť. Samozrejme, bolo by možné spustiť etcd v každej konfigurácii a pozrieť sa na zodpovedajúce metriky Prometheus, ale to by si vyžadovalo značné úsilie. Potrebovali sme jednoduchý spôsob hodnotenia konkrétnej konfigurácie. Chceli sme otestovať naše chápanie metrík Prometheus pochádzajúcich z etcd.

To si vyžadovalo vyriešiť dva problémy:

Po prvé, ako vyzerá I/O zaťaženie generované etcd pri zápise do WAL súborov? Aké systémové volania sa používajú? Aká je veľkosť blokov záznamu?
Po druhé, povedzme, že máme odpovede na vyššie uvedené otázky. Ako reprodukovať zodpovedajúce zaťaženie s fio? Po všetkom fio — extrémne flexibilné využitie s množstvom parametrov (to sa dá ľahko overiť napr. tu - približne. preklad.).

Oba problémy sme vyriešili rovnakým prístupom založeným na príkazoch lsof и strace:

S lsof môžete zobraziť všetky deskriptory súborov používané procesom, ako aj súbory, na ktoré odkazujú.
S strace môžete analyzovať už spustený proces alebo spustiť proces a sledovať ho. Príkaz zobrazí všetky systémové volania uskutočnené týmto procesom a v prípade potreby aj jeho potomkov. Ten je dôležitý pre procesy, ktoré sa rozdeľujú, a etcd je jedným z takýchto procesov.

Prvá vec, ktorú sme urobili, bolo použitie strace na preskúmanie servera etcd v klastri Kubernetes, keď bol nečinný.

Zistilo sa teda, že bloky záznamov WAL sú veľmi husto zoskupené, veľkosť väčšiny bola v rozsahu 2200-2400 bajtov. Preto príkaz na začiatku tohto článku používa príznak --bs=2300 (bs je veľkosť každého bloku zápisu v bajtoch fio).

Upozorňujeme, že veľkosť blokov zápisu etcd sa môže líšiť v závislosti od verzie, nasadenia, hodnôt parametrov atď. - ovplyvňuje trvanie fdatasync. Ak máte podobný prípad použitia, analyzujte s strace vaše procesy atď., aby ste získali aktuálne hodnoty.

Potom, aby sme získali jasnú a komplexnú predstavu o tom, ako etcd funguje so súborovým systémom, začali sme to zdola strace s vlajkami -ffttT. To umožnilo zachytiť podradené procesy a zapísať výstup každého do samostatného súboru. Okrem toho boli získané podrobné informácie o čase spustenia a trvaní každého systémového volania.

Použili sme aj príkaz lsofaby ste potvrdili svoje pochopenie výstupu strace z hľadiska toho, ktorý deskriptor súboru bol použitý na aký účel. Dospel som k záveru strace, podobne ako vyššie. Štatistické manipulácie s časmi synchronizácie potvrdili, že metrika wal_fsync_duration_seconds z etcd zodpovedá hovorom fdatasync s deskriptormi súborov WAL.

Na generovanie pomocou fio záťaž podobná tej z etcd, bola preštudovaná dokumentácia utility a boli vybrané parametre vhodné pre našu úlohu. Overili sme, že prebiehajú správne systémové volania a potvrdili sme ich trvanie spustením fio z strace (ako to bolo urobené v prípade atď.).

Zvláštna pozornosť bola venovaná určovaniu hodnoty parametra --size. Predstavuje celkové I/O zaťaženie generované obslužným programom fio. V našom prípade ide o celkový počet bajtov zapísaných na médium. Je priamo úmerná počtu hovorov write (a fdatasync). Pre konkrétneho bs počet hovorov fdatasync je size / bs.

Keďže nás zaujímal percentil, chceli sme, aby bol počet vzoriek dostatočne veľký na to, aby bol štatisticky významný. A rozhodol tak 10^4 (čo zodpovedá veľkosti 22 MB) postačí. Menšie hodnoty parametrov --size vydávali výraznejší hluk (napríklad hovory fdatasync, ktoré trvajú oveľa dlhšie ako zvyčajne a ovplyvňujú 99. percentil).

Je to na tebe

Článok ukazuje, ako používať fio dá sa vyhodnotiť, či je médium určené na použitie s etcd dostatočne rýchle. Teraz je to na vás! V službe môžete preskúmať virtuálne stroje s úložiskom na báze SSD IBM Cloud.

PS od prekladateľa

S už pripravenými prípadmi použitia fio Ďalšie úlohy viď dokumentáciu alebo priamo na projektové úložiská (je ich oveľa viac, ako je uvedené v dokumentácii).

PPS od prekladača

Prečítajte si aj na našom blogu:

Zdroj: hab.com

Ako skontrolovať disky s fio na dostatočný výkon pre atď