Vývojári z Cloudflare
Cloudflare používa dm-crypt na šifrovanie údajov na úložných zariadeniach používaných na ukladanie obsahu do vyrovnávacej pamäte na CDN. Dm-crypt funguje na úrovni blokového zariadenia a šifruje požiadavky na zápis I/O a dešifruje požiadavky na čítanie, pričom funguje ako vrstva medzi blokovým zariadením a ovládačom súborového systému.
Na vyhodnotenie výkonu dm-crypt pomocou balíka
Najprv sa objavilo podozrenie na použitie neefektívnych algoritmov v kryptosystéme jadra. Testy však používali najrýchlejší algoritmus, aes-xts, s 256 šifrovacími kľúčmi, ktorých výkon pri spustení „benchmarku kryptovania“ je viac ako dvakrát vyšší ako výsledok získaný pri testovaní RAM disku. Experimenty s príznakmi dm-crypt na ladenie výkonu nepriniesli výsledky: pri použití príznaku „--perf-same_cpu_crypt“ sa výkon dokonca znížil na 136 MB/s a pri zadaní príznaku „--perf-submit_from_crypt_cpus“ sa zvýšil iba až 166 MB/s.
Hlbšia analýza operačnej logiky ukázala, že dm-crypt nie je taký jednoduchý, ako sa zdá - keď príde požiadavka na zápis z ovládača FS, dm-crypt ju nespracuje okamžite, ale zaradí ju do frontu „kcryptd“, čo nie je analyzovaný okamžite, ale vo vhodnom momente. Z frontu sa požiadavka odošle do Linux Crypto API na vykonanie šifrovania. Ale keďže Crypto API používa asynchrónny model vykonávania, šifrovanie sa tiež nevykonáva okamžite, ale obchádza ďalší front. Po dokončení šifrovania sa môže dm-crypt pokúsiť zoradiť čakajúce požiadavky na zápis pomocou vyhľadávacieho stromu
Pri čítaní dm-crypt najskôr pridá požiadavku do frontu „kcryptd_io“ na prijatie údajov z disku. Po určitom čase sa údaje sprístupnia a umiestnia sa do frontu „kcryptd“ na dešifrovanie.
Kcryptd odošle požiadavku do Linux Crypto API, ktoré dešifruje informácie asynchrónne. Požiadavky nie vždy prejdú cez všetky fronty, ale v najhoršom prípade žiadosť o zápis skončí vo frontoch až 4-krát a žiadosť o čítanie až 3-krát. Každý zásah do frontu spôsobuje oneskorenia, ktoré sú hlavným dôvodom výrazného poklesu výkonu dm-crypt.
Použitie radov je spôsobené potrebou pracovať v podmienkach, kde dochádza k prerušeniam. V roku 2005, keď bol implementovaný súčasný operačný model dm-crypt založený na fronte, Crypto API ešte nebolo asynchrónne. Po prenesení Crypto API na asynchrónny model vykonávania sa začala používať v podstate dvojitá ochrana. Zaviedli sa aj fronty, aby sa ušetrila spotreba zásobníka jadra, ale po jeho zvýšení v roku 2014 tieto optimalizácie stratili svoj význam. Bol zavedený ďalší front „kcryptd_io“, aby sa prekonalo úzke miesto, ktoré malo za následok čakanie na pridelenie pamäte, keď príde veľký počet požiadaviek. V roku 2015 bola zavedená ďalšia fáza triedenia, pretože požiadavky na šifrovanie na viacprocesorových systémoch bolo možné dokončiť mimo poradia (namiesto postupného prístupu na disk sa prístup vykonával v náhodnom poradí a plánovač CFQ nefungoval efektívne). V súčasnosti pri používaní SSD diskov triedenie stratilo zmysel a v jadre sa už nepoužíva plánovač CFQ.
Vzhľadom na to, že moderné disky sa stali rýchlejšími a inteligentnejšími, systém distribúcie zdrojov v jadre Linuxu bol revidovaný a niektoré podsystémy boli prepracované, inžinieri Cloudflare
Výsledkom bolo, že pri testovaní RAM disku bolo možné viac ako zdvojnásobiť výkon dm-crypt – výkon vzrástol z 294 MB/s (2 x 147 MB/s) na 640 MB/s, čo je veľmi blízko k výkon holého šifrovania (696 MB/s).
Pri testovaní záťaže na reálnych serveroch nová implementácia ukázala výkon veľmi blízky konfigurácii spustenej bez šifrovania a povolenie šifrovania na serveroch s vyrovnávacou pamäťou Cloudflare nemalo žiadny vplyv na rýchlosť odozvy. Cloudflare plánuje v budúcnosti preniesť pripravené záplaty do hlavného linuxového jadra, no predtým ich bude potrebné prepracovať, keďže sú optimalizované pre konkrétnu záťaž a nepokrývajú všetky oblasti aplikácie, napríklad šifrovanie na nízkej úrovni. -napájanie vstavaných zariadení.
Zdroj: opennet.ru