Kehittäjät Cloudflaresta Linux-ytimen levysalauksen suorituskyvyn optimoinnista. Tämän seurauksena he olivat valmiita alajärjestelmää varten ja Crypto API, joka mahdollisti yli kaksinkertaisen luku- ja kirjoitusnopeuden synteettisessä testissä sekä puolittamaan latenssin. Oikealla laitteistolla testattaessa salauksen ylimääräiset kustannukset pienenivät lähes tasolle, joka havaittiin työskenneltäessä levyllä ilman tietojen salausta.
Cloudflare käyttää dm-cryptia tietojen salaamiseen tallennuslaitteissa, joita käytetään CDN:n sisällön välimuistiin. Dm-crypt toimii lohkolaitetasolla ja salaa kirjoitus-I/O-pyynnöt ja purkaa lukupyynnöt, toimien kerroksena lohkolaitteen ja tiedostojärjestelmän ajurin välillä.
Arvioi dm-crypt:n suorituskyky paketin avulla Mittasimme salattujen ja salaamattomien osioiden kanssa työskentelyn nopeuden RAM-levyllä, joka sijaitsee RAM-muistissa, poistaaksemme levyn suorituskyvyn vaihtelut ja keskittyäksemme koodin suorituskykyyn. Salaamattomien osioiden luku- ja kirjoitussuorituskyky pysyi 1126 MB/s:ssa, mutta nopeus laski, kun salaus otettiin käyttöön 7 ajoissa ja oli 147 MB/s.
Aluksi heräsi epäilys tehottomien algoritmien käytöstä ytimen salausjärjestelmässä. Mutta testeissä käytettiin nopeinta algoritmia, aes-xts, 256 salausavainta, jonka suorituskyky "cryptsetup benchmark" ajettaessa on yli kaksi kertaa parempi kuin tulos, joka saatiin testattaessa RAM-levyä. Kokeet dm-crypt-lipuilla suorituskyvyn virittämiseksi eivät tuottaneet tuloksia: "--perf-same_cpu_crypt" -lippua käytettäessä suorituskyky jopa laski 136 MB/s:iin ja "--perf-submit_from_crypt_cpus" -lippua määritettäessä se kasvoi. vain 166 MB/s.
Toimintalogiikan syvällisempi analyysi osoitti, että dm-crypt ei ole niin yksinkertainen kuin miltä näyttää - kun kirjoituspyyntö saapuu FS-ajurista, dm-crypt ei käsittele sitä heti, vaan sijoittaa sen ”kcryptd”-jonoon, joka ei jäsenne heti, vaan sopivalla hetkellä. Jonosta pyyntö lähetetään Linux Crypto API:lle salauksen suorittamiseksi. Mutta koska Crypto API käyttää asynkronista suoritusmallia, salausta ei myöskään suoriteta välittömästi, vaan se ohittaa toisen jonon. Kun salaus on valmis, dm-crypt voi yrittää lajitella odottavia kirjoituspyyntöjä hakupuun avulla . Lopussa erillinen ydinsäie poimii jälleen tietyllä viiveellä kertyneet I/O-pyynnöt ja lähettää ne lohkolaitepinoon.
Lukeessaan dm-crypt lisää ensin "kcryptd_io"-jonoon pyynnön vastaanottaa tietoja asemalta. Jonkin ajan kuluttua tiedot tulevat saataville ja ne asetetaan "kcryptd"-jonoon salauksen purkamista varten.
Kcryptd lähettää pyynnön Linux Crypto API:lle, joka purkaa tietojen salauksen asynkronisesti. Pyynnöt eivät aina mene läpi kaikkia jonoja, mutta pahimmassa tapauksessa kirjoituspyyntö päätyy jonoihin jopa 4 kertaa ja lukupyyntö jopa 3 kertaa. Jokainen osuma jonoon aiheuttaa viiveitä, jotka ovat tärkein syy dm-crypt-suorituskyvyn merkittävään heikkenemiseen.
Jonojen käyttö johtuu tarpeesta työskennellä olosuhteissa, joissa esiintyy katkoksia. Vuonna 2005, kun dm-cryptin nykyinen jonopohjainen toimintamalli otettiin käyttöön, Crypto API ei ollut vielä asynkroninen. Sen jälkeen kun Crypto API oli siirretty asynkroniseen suoritusmalliin, alettiin käyttää olennaisesti kaksoissuojausta. Jonot otettiin käyttöön myös ydinpinon kulutuksen säästämiseksi, mutta sen kasvun jälkeen vuonna 2014 nämä optimoinnit menettivät merkityksensä. Lisäjono "kcryptd_io" otettiin käyttöön poistamaan pullonkaula, joka johti odottamaan muistin varaamista, kun suuri määrä pyyntöjä saapuu. Vuonna 2015 otettiin käyttöön ylimääräinen lajitteluvaihe, koska moniprosessorijärjestelmien salauspyynnöt voitiin suorittaa epäjärjestyksessä (levylle pääsyn peräkkäisen käytön sijaan pääsy tapahtui satunnaisessa järjestyksessä, eikä CFQ-aikataulu toiminut tehokkaasti). Tällä hetkellä SSD-asemia käytettäessä lajittelu on menettänyt merkityksensä, eikä CFQ-aikataulua enää käytetä ytimessä.
Ottaen huomioon, että nykyaikaisista asemista on tullut nopeampia ja älykkäämpiä, Linux-ytimen resurssien jakelujärjestelmää on tarkistettu ja joitain alijärjestelmiä on suunniteltu uudelleen, Cloudflaren insinöörit dm-crypt:ssä on uusi toimintatila, joka eliminoi tarpeettomat jonot ja asynkroniset puhelut. Tila otetaan käyttöön erillisellä lipulla "force_inline", ja se tuo dm-crypt yksinkertaisen välityspalvelimen muotoon, joka salaa ja purkaa saapuvat pyynnöt. Vuorovaikutus Crypto API:n kanssa on optimoitu valitsemalla nimenomaan salausalgoritmeja, jotka toimivat synkronisessa tilassa eivätkä käytä pyyntöjonoja. Synkroninen työskentely Crypto API:n kanssa oli olemassa moduuli, jonka avulla voit käyttää FPU/AES-NI:tä kiihdytykseen ja välittää suoraan salaus- ja salauksenpurkupyynnöt.
Tämän seurauksena RAM-levyä testattaessa oli mahdollista yli kaksinkertaistaa dm-cryptin suorituskyky - suorituskyky nousi 294 MB/s (2 x 147 MB/s) 640 MB/s, mikä on hyvin lähellä paljaan salauksen suorituskyky (696 MB/s).
Testattaessa kuormitusta oikeilla palvelimilla uusi toteutus osoitti suorituskykyä hyvin lähellä ilman salausta ajettua konfiguraatiota, eikä salauksen salliminen palvelimilla Cloudflare-välimuistilla vaikuttanut vastausnopeuteen. Jatkossa Cloudflare aikoo siirtää valmistetut korjaustiedostot Linuxin pääytimeen, mutta sitä ennen ne on työstettävä uudelleen, koska ne on optimoitu tietylle kuormitukselle eivätkä kata kaikkia käyttöalueita, esimerkiksi salausta matalalla. -teho sulautetut laitteet.
Lähde: opennet.ru