Rýchlosť úložiska vhodná pre atď. Opýtajme sa fio

Krátky príbeh o fio a pod

Výkon klastra atď do značnej miery závisí od výkonu jeho úložiska. etcd exportuje niektoré metriky do Prometheusposkytnúť požadované informácie o výkone úložiska. Napríklad metrika wal_fsync_duration_seconds. Dokumentácia pre etcd hovorí: Aby bolo ukladanie považované za dostatočne rýchle, 99. percentil tejto metriky musí byť menší ako 10 ms. Ak plánujete spustiť klaster etcd na počítačoch so systémom Linux a chcete zhodnotiť, či je vaše úložisko dostatočne rýchle (napr. SSD), môžete použiť Fio je populárny nástroj na testovanie I/O operácií. Spustite nasledujúci príkaz, kde test-data je adresár pod bodom pripojenia úložiska:

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

Stačí sa pozrieť na výsledky a skontrolovať, či je 99. percentil trvania fdatasync menej ako 10 ms. Ak áno, máte k dispozícii primerane rýchle úložisko. Tu je príklad výsledkov:

  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

• Prispôsobili sme možnosti --size a --bs pre náš konkrétny scenár. Ak chcete získať užitočný výsledok z fio, uveďte svoje vlastné hodnoty. Kde ich zohnať? Čítať ako sme sa naučili konfigurovať fio.
• Počas testovania prichádza všetka I/O záťaž z fio. V skutočnom scenári budú pravdepodobne do úložiska prichádzať ďalšie požiadavky na zápis okrem tých, ktoré súvisia s wal_fsync_duration_seconds. Dodatočné zaťaženie zvýši hodnotu wal_fsync_duration_seconds. Ak sa teda 99. percentil blíži k 10 ms, vášmu úložisku dochádza rýchlosť.
• Vezmite verziu Fio nie nižší ako 3.5 (predchádzajúce nezobrazujú percentily trvania fdatasync).
• Vyššie je len úryvok výsledkov z fio.

Dlhý príbeh o fio a atď

Čo je WAL v etcd

Zvyčajne používajú databázy zápis vopred; etcd to tiež používa. Nebudeme tu podrobne rozoberať protokol o zápise vopred (WAL). Stačí nám vedieť, že každý člen klastra etcd ho udržiava v perzistentnom úložisku. etcd zapíše každú operáciu kľúč-hodnota (napríklad aktualizáciu) do WAL predtým, ako ju použije v obchode. Ak jeden z členov úložného priestoru medzi snímkami zlyhá a reštartuje sa, môže lokálne obnoviť transakcie od poslednej snímky podľa obsahu WAL.

Keď klient pridá kľúč do úložiska kľúč-hodnota alebo aktualizuje hodnotu existujúceho kľúča, etcd zaznamená operáciu vo WAL, čo je bežný súbor v trvalom úložisku. etcd MUSÍ byť úplne istí, že záznam WAL sa skutočne vyskytol pred pokračovaním v spracovaní. Na Linuxe na to nestačí jedno systémové volanie. písať, pretože skutočný zápis do fyzického úložiska môže byť oneskorený. Napríklad Linux môže na nejaký čas uložiť položku WAL do vyrovnávacej pamäte v pamäti jadra (ako je vyrovnávacia pamäť stránok). A aby sa dáta presne zapísali do perzistentného úložiska, je po zápise potrebné systémové volanie fdatasync a etcd ho len použije (ako môžete vidieť na výsledku práce strace, kde 8 je deskriptor súboru 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žiaľ, zápis do trvalého úložiska neprebehne okamžite. Ak je volanie fdatasync pomalé, utrpí to výkon systému etcd. Dokumentácia pre etcd hovoríže úložisko sa považuje za dostatočne rýchle, ak v 99. percentile trvá volaniam fdatasync menej ako 10 ms na zápis do súboru WAL. Existujú aj ďalšie užitočné metriky pre ukladanie, ale v tomto príspevku hovoríme len o tejto metrike.

Odhad skladovania s fio

Ak potrebujete zhodnotiť, či je vaše úložisko vhodné pre etcd, použite fio, veľmi populárny nástroj na testovanie záťaže I/O. Malo by sa pamätať na to, že diskové operácie môžu byť veľmi odlišné: synchrónne a asynchrónne, mnoho tried systémových volaní atď. Výsledkom je, že použitie fio je dosť ťažké. Má veľa parametrov a rôzne kombinácie ich hodnôt vytvárajú veľmi odlišné I/O pracovné zaťaženia. Ak chcete získať adekvátne hodnoty pre etcd, mali by ste sa uistiť, že zaťaženie testovacieho zápisu z fio je čo najbližšie k skutočnému zaťaženiu z etcd pri zapisovaní súborov WAL.

Preto by fio mal minimálne vytvoriť záťaž vo forme série po sebe idúcich zápisov do súboru, pričom každý zápis bude pozostávať zo systémového volania písaťnasleduje systémové volanie fdatasync. Sekvenčné zápisy do fio vyžadujú voľbu --rw=write. Pre fio použiť namiesto zápisu systémové volanie zápisu písať, mali by ste zadať parameter --ioengine=sync. Nakoniec, ak chcete volať fdatasync po každom zápise, musíte pridať parameter --fdatasync=1. Ďalšie dve možnosti v tomto príklade (--size a -bs) sú špecifické pre skript. V ďalšej časti vám ukážeme, ako ich nastaviť.

Prečo práve fio a ako sme sa to naučili nastavovať

V tomto príspevku popisujeme skutočný prípad. Máme klaster Kubernetes v1.13, ktorý sme monitorovali pomocou Prometheus. etcd v3.2.24 bol hosťovaný na SSD. Metriky Etcd ukázali príliš vysoké latencie fdatasync, aj keď klaster nič nerobil. Metriky boli zvláštne a my sme vlastne nevedeli, čo znamenajú. Klaster pozostával z virtuálnych strojov, bolo potrebné pochopiť, v čom bol problém: vo fyzických SSD diskoch alebo vo virtualizačnej vrstve. Okrem toho sme často robili zmeny v konfigurácii hardvéru a softvéru a potrebovali sme spôsob, ako vyhodnotiť ich výsledky. Mohli by sme spustiť etcd v každej konfigurácii a pozrieť sa na metriky Prometheus, ale to je príliš veľa problémov. Hľadali sme celkom jednoduchý spôsob, ako vyhodnotiť konkrétnu konfiguráciu. Chceli sme si overiť, či správne rozumieme metrikám Prometheus z etcd.

Na to však bolo potrebné vyriešiť dva problémy. Po prvé, ako vyzerá I/O zaťaženie, ktoré etcd vytvorí pri zápise do WAL? Aké systémové volania sa používajú? Aká je veľkosť záznamov? Po druhé, ak odpovieme na tieto otázky, ako reprodukujeme podobné pracovné zaťaženie s fio? Nezabudnite, že fio je veľmi flexibilný nástroj s mnohými možnosťami. Oba problémy sme vyriešili jedným prístupom - pomocou príkazov tiež и strace. lsof uvádza všetky deskriptory súborov používané procesom a ich pridružené súbory. A pomocou strace môžete preskúmať už spustený proces alebo spustiť proces a preskúmať ho. strace vypíše všetky systémové volania skúmaného procesu (a jeho podriadených procesov). To druhé je veľmi dôležité, pretože etcd má podobný prístup.

Prvýkrát sme použili strace na preskúmanie servera etcd pre Kubernetes, keď nebolo zaťaženie klastra. Videli sme, že takmer všetky záznamy WAL mali približne rovnakú veľkosť: 2200–2400 bajtov. Preto sme v príkaze na začiatku príspevku uviedli parameter -bs=2300 (bs znamená veľkosť v bajtoch pre každý fio záznam). Všimnite si, že veľkosť položky etcd závisí od verzie etcd, distribúcie, hodnôt parametrov atď. a ovplyvňuje trvanie fdatasync. Ak máte podobný scenár, preskúmajte svoje procesy etcd pomocou strace, aby ste zistili presné čísla.

Potom, aby sme získali dobrú predstavu o tom, čo robí súborový systém etcd, sme ho spustili pomocou strace a možností -ffttT. Pokúsili sme sa teda preskúmať podradené procesy a zaznamenať výstup každého z nich do samostatného súboru a tiež získať podrobné správy o začiatku a trvaní každého systémového volania. Použili sme lsof na potvrdenie našej analýzy výstupu strace a na zistenie, ktorý deskriptor súboru bol použitý na aký účel. Takže s pomocou strace boli získané výsledky uvedené vyššie. Štatistika času synchronizácie potvrdila, že wal_fsync_duration_seconds z etcd je v súlade s volaniami fdatasync s deskriptormi súborov WAL.

Prešli sme si dokumentáciu pre fio a vybrali možnosti pre náš skript, aby fio generovalo zaťaženie podobné etcd. Kontrolovali sme aj systémové volania a ich trvanie spustením fio zo strace, podobne ako etcd.

Starostlivo sme zvolili hodnotu parametra --size, aby reprezentovala celú I/O záťaž z fio. V našom prípade ide o celkový počet bajtov zapísaných do úložiska. Ukázalo sa, že je to priamo úmerné počtu systémových volaní zápisu (a fdatasync). Pre určitú hodnotu bs je počet volaní fdatasync = veľkosť/bs. Keďže nás zaujímal percentil, pre istotu sme museli mať dostatok vzoriek a vypočítali sme, že nám bude stačiť 10^4 (to je 22 mebibajtov). Ak je --size menšia, môžu sa vyskytnúť odľahlé hodnoty (napríklad niekoľko volaní fdatasync trvá dlhšie ako zvyčajne a ovplyvňuje 99. percentil).

Vyskúšajte si to sami

Ukázali sme vám, ako používať fio a zistiť, či je úložisko dostatočne rýchle na to, aby etcd fungovalo dobre. Teraz si to môžete sami vyskúšať napríklad na virtuálnych strojoch s úložiskom SSD IBM Cloud.

Zdroj: hab.com