Note: this article summarizes a mini-research conducted by IBM Cloud engineers in search of solutions to a real problem related to the operation of the etcd database.

Pozn. prekl.: tento článok je zhrnutím mini-štúdie, ktorú vykonali inžinieri IBM Cloud pri hľadaní riešenia reálneho problému súvisiaceho s prevádzkou databázy etcd. Zaujímala nás podobná úloha, avšak proces uvažovania a činnosti autorov môže byť zaujímavý aj v širšom kontexte.

Krátke zhrnutie celého článku: fio a etcd

Výkonnosť klastru etcd silne závisí od rýchlosti úložiska, na ktorom spočíva. Na sledovanie výkonnosti etcd exportuje rôzne metriky Prometheus. Jednou z nich je wal_fsync_duration_seconds. V dokumentácii k etcd sa uvádza, že úložisko možno považovať za dostatočne rýchle, ak 99. percentil tejto metriky nepresahuje 10 ms…

Ak uvažujete o organizácii klastru etcd na strojoch s operačným systémom Linux a chcete skontrolovať, či sú úložiská dostatočne rýchle (napríklad SSD), odporúčame využiť populárny tester I/O s názvom fio. Stačí spustiť nasledujúci príkaz (adresár test-data by mal byť umiestnený vo pripojenom oddiele testovaného úložiska):

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

Ostáva len pozrieť sa na výstup a skontrolovať, či sa 99. percentil fdatasync zmestí do 10 ms. Ak áno, znamená to, že vaše úložisko pracuje 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]

Niekoľko poznámok:

Vo vyššie uvedenom príklade sme prispôsobili parametre --size a --bs na konkrétny prípad. Aby ste získali relevantný výsledok z fio, uvádzajte hodnoty, ktoré sú vhodné pre váš scénar použitia. O tom, ako ich vybrať, bude hovorené nižšie.
Počas testovania iba fio zaťažuje diskový subsystém. V skutočnom živote je veľmi pravdepodobné, že na disk budú písať aj iné procesy (okrem tých, ktoré súvisia s wal_fsync_duration_seconds). Takéto dodatočné zaťaženie môže viesť k zvýšeniu wal_fsync_duration_seconds. Inými slovami, ak percentil 99, získaný na základe testovania fio, je iba mierne pod 10 ms, je pravdepodobné, že výkon úložiska je nedostatočný.
Na test potrebujete verziu fio najmenej 3.5, keďže staršie verzie nezhromažďujú výsledky fdatasync vo forme percentilov.
Uvedený výstup je len malým úryvkom z celkového výstupu fio.

Podrobnejšie o fio a etcd

Niekoľko slov o WAL-och etcd

Spravidla databázy používajú predbežné zaznamenávanie (write-ahead logging, WAL). Týka sa to aj etcd. Diskusia o WAL presahuje rámec tohto článku, avšak pre naše účely je potrebné vedieť nasledovné: každý člen klastru etcd uchováva WAL v trvalom úložisku. etcd zaznamenáva niektoré operácie s kľúčovo-hodnotovými úložiskami (napríklad aktualizácie) do WAL pred ich vykonaním. Ak uzol spadne a reštartuje sa v intervale medzi snapshotmi, etcd môže obnoviť transakcie vykonané od predchádzajúceho snapshotu s ohľadom na obsah WAL.

Takže zakaždým, keď klient pridá kľúč do KV-úložiska alebo aktualizuje hodnotu existujúceho kľúča, etcd pridá popis operácie do WAL, ktorý je obyčajným súborom v trvalom úložisku. Predtým, než pokračuje v činnosti, musí byť etcd na 100 % presvedčené, že zápis do WAL bol skutočne uložený. Aby to dosiahli 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 niekoľko momentov udržiavať zápis WAL v pamäti jadra (napríklad v stránkovom cache). Aby sa zabezpečilo, že dáta sú zapísané na médium, po zápise je potrebné aktivovať systémové volanie fdatasync — práve tak postupuje etcd (ako je vidieť na príklade nasledujúceho výstupu strace; tu 8 — deskriptor súboru 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žiaľ, zápis do trvalého úložiska trvá nejaký čas. Dlhé vykonávanie volania fdatasync môže mať vplyv na výkon etcd. V dokumentácii k úložisku sa uvádza, že pre dostatočný výkon je potrebné, aby 99. percentil trvania všetkých volaní fdatasync pri zápise do súboru WAL bol menší ako 10 ms. Existujú aj ďalšie metriky týkajúce sa úložiska, ale tento článok sa zameriava práve na túto.

Hodnotenie úložiska pomocou fio

Na posúdenie, či je určité úložisko vhodné pre použitie s etcd, môžete využiť nástroj fio — populárny I/O tester. Berte do úvahy, že diskové I/O môže prebiehať rôznymi spôsobmi: sync/async, množstvo rôznych tried systémových volaní atď. Druhá strana mince je, že fio je mimoriadne zložitá na používanie. Nástroj má množstvo parametrov a rôzne kombinácie ich hodnôt vedú k úplne iným výsledkom. Aby ste získali zmysluplné hodnotenie v prípade etcd, musíte sa uistiť, že záťaž na zápis generovaná fio sa čo najviac podobá záťaži etcd pri zápise do WAL súborov:

To znamená, že generovaná fio záťaž by mala minimálne pozostávať zo série sekvenčných zápisov do súboru, kde každá operácia zápisu pozostáva zo systémového volania write, nasledovaného fdatasync.
Aby ste aktivovali sekvenčný zápis, musíte zadať parameter --rw=write.
Aby fio ktorý píše pomocou volaní write (a nie iných systémových volaní — napríklad pwrite), použite parameter --ioengine=sync.
Nakoniec parameter --fdatasync=1 zabezpečuje, že za každým write použiť fdatasync.
Ďalšie dva parametre v našom príklade: --size a --bs — sa môžu líšiť v závislosti od konkrétneho scénara použitia. V nasledujúcej časti bude popísané ich nastavenie.

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

Táto poznámka vznikla z reálneho prípadu, s ktorým sme sa stretli. Mali sme klaster na Kubernetes v1.13 so sledovaním na Prometheus. Ako úložisko pre etcd v3.2.24 slúžili SSD. Metriky etcd ukazovali príliš vysoké latencie fdatasync, aj keď bol klaster nečinný. Tieto metriky sa nám zdali veľmi pochybné a neboli sme si istí, čo presne predstavujú. Okrem toho sa klaster skladal z virtuálnych strojov, takže sme nemohli povedať, či latencia súvisela s virtualizáciou alebo za všetkým stál SSD.

Okrem toho sme zvažovali rôzne zmeny v konfigurácii hardvéru a softvéru, a preto sme potrebovali spôsob, ako ich vyhodnotiť. Samozrejme, mohli by sme spustiť etcd v každej konfigurácii a pozrieť sa na príslušné metriky Prometheus, no to by si vyžadovalo značné úsilie. Nám však bol potrebný jednoduchý spôsob, ktorý by umožnil ohodnotiť konkrétnu konfiguráciu. Chceli sme overiť naše pochopenie metriky Prometheus, prichádzajúcej z etcd.

Na to bolo potrebné vyriešiť dva problémy:

Po prvé, ako vyzerá I/O záťaž generovaná etcd pri zapisovaní do súborov WAL? Aké systémové volania sú použité? Aká je veľkosť blokov zápisu?
Po druhé, predpokladajme, že na vyššie uvedené otázky máme odpovede. Ako reprodukovať príslušnú záťaž s fio? Ведь fio — extrémne flexibilný nástroj s množstvom parametrov (o čom sa môžete presvedčiť, napríklad, tu — pozn. prekl.).

Obe problémy sme vyriešili pomocou rovnakého prístupu založeného na príkazoch lsof a strace:

S pomocou lsof je možné zobraziť všetky súborové deskriptory používané procesom, ako aj súbory, ktorým sa týkajú.
S pomocou strace je možné analyzovať už bežiaci proces alebo spustiť proces a sledovať ho. Príkaz zobrazuje všetky systémové volania uskutočnené týmto procesom a, ak je to potrebné, aj jeho potomkami. Posledné je dôležité pre procesy, ktoré sa forkli, a etcd je jedným z takýchto procesov.

Prvé, čo sme urobili, bolo použiť strace na skúmanie servera etcd v klastri Kubernetes, keď bol nečinný.

Tak sa zistilo, že bloky zápisov do WAL sú veľmi tesne zoskupené, pričom veľkosť väčšiny sa pohybovala v rozmedzí 2200-2400 bajtov. Preto v príkaze na začiatku tohto článku používame flag --bs=2300 (bs — veľkosť v bajtoch každého bloku zápisu v fio).

Vezmite na vedomie, že veľkosť blokov zápisu etcd sa môže líšiť v závislosti od verzie, nasadenia, hodnôt parametrov a podobne — to ovplyvňuje trvanie fdatasync. Ak máte podobný scenár využitia, analyzujte pomocou strace svoje procesy etcd, aby ste získali aktuálne hodnoty.

Potom, aby sme získali jasný a komplexný pohľad na fungovanie etcd so súborovým systémom, spustili sme ho z strace s flagmi -ffttT. To allow coverage of child processes and record the output of each into a separate file. Additionally, detailed information was obtained about the start time and duration of each system call.

We also utilized the command lsof, to confirm our understanding of the output strace in terms of which file descriptor was used for which purpose. The output was strace, similar to that presented above. Statistical manipulations with synchronization times confirmed that the metric wal_fsync_duration_seconds from etcd corresponds to the calls fdatasync with WAL file descriptors.

To generate a workload similar to the one from etcd, the utility's documentation was studied and parameters suitable for our task were chosen. We ensured that the required system calls were utilized and confirmed their duration by running fio (as was done in the case of etcd). fio z strace Particular attention was paid to determining the value of the parameter

. It represents the overall I/O load generated by the fio utility. In our case, this is the total number of bytes written to the storage. It is directly proportional to the number of calls --size). For a specific write (a fdatasyncnumber of calls bs is equal to fdatasync size / bs Since we were interested in the percentile, we aimed for the sample size to be large enough for statistical significance. We decided that.

(which corresponds to a size of 22 MB) would be sufficient. Smaller values of the parameter 10^4 produced more pronounced noise (for example, calls --size , which take much longer than usual and affect the 99th percentile). fdatasyncThe choice is yours

The article demonstrates how to assess whether a storage device intended for use with etcd is fast enough. Now it's up to you! You can explore virtual machines with SSD-based storage on the

IBM Cloud fio With ready-to-use examples for solving other tasks available in or directly in.

P.S. od prekladateľa

(where many more are presented than mentioned in the documentation). fio etcd 3.4.3: exploring the reliability and security of the storage dokumenácie Note: this article summarizes a mini-research conducted by IBM Cloud engineers in search of solutions to a real problem related to the operation of the etcd database. repozitári projektu 🥇How to check disks for adequate performance for etcd using fio | ProHoster