Ontwikkelaars van Cloudflare oor die uitvoering van werk om die werkverrigting van skyfkodering in die Linux-kern te optimaliseer. Gevolglik was hulle voorbereid vir substelsel en Crypto API, wat dit moontlik gemaak het om die lees- en skryfdeurset in die sintetiese toets meer as te verdubbel, sowel as om latensie te halveer. Wanneer dit op regte hardeware getoets is, is enkripsiebokoste verminder tot byna die vlak wat waargeneem word wanneer met 'n skyf sonder data-enkripsie gewerk word.
Cloudflare gebruik dm-crypt om data te enkripteer op stoortoestelle wat gebruik word om inhoud op die CDN te kas. Dm-crypt werk op die blok toestel vlak en enkripteer skryf I/O versoeke en dekripteer lees versoeke, wat optree as 'n laag tussen die blok toestel en die lêer stelsel bestuurder.
Om die prestasie van dm-crypt met behulp van die pakket te evalueer Ons het die spoed gemeet om met geënkripteerde en ongeënkripteerde partisies te werk op 'n RAM-skyf wat in RAM geleë is om fluktuasies in skyfwerkverrigting uit te skakel en op kodewerkverrigting te fokus. Vir ongeënkripteerde partisies het lees- en skryfwerkverrigting op 1126 MB/s gebly, maar die spoed het afgeneem toe enkripsie geaktiveer is 7 keer en beloop 147 MB/s.
Aanvanklik het vermoede ontstaan oor die gebruik van ondoeltreffende algoritmes in die kernkriptosisteem. Maar die toetse het die vinnigste algoritme, aes-xts, gebruik met 256 enkripsiesleutels, waarvan die werkverrigting wanneer die "cryptsetup benchmark" uitgevoer word, meer as twee keer so hoog is as die resultaat wat verkry word wanneer 'n RAM-skyf getoets word. Eksperimente met dm-crypt-vlae vir prestasie-instelling het nie resultate opgelewer nie: wanneer die “--perf-same_cpu_crypt”-vlag gebruik word, het werkverrigting selfs tot 136 MB/s afgeneem, en wanneer die “--perf-submit_from_crypt_cpus”-vlag gespesifiseer is, het dit net toegeneem tot 166 MB/s.
'n Dieper ontleding van die bedryfslogika het getoon dat dm-crypt nie so eenvoudig is soos dit lyk nie - wanneer 'n skryfversoek van die FS-bestuurder af kom, verwerk dm-crypt dit nie dadelik nie, maar plaas dit in die "kcryptd" tou, wat word nie onmiddellik ontleed nie, maar wanneer dit gerieflik is. Vanuit die tou word die versoek na die Linux Crypto API gestuur om enkripsie uit te voer. Maar aangesien die Crypto API 'n asynchrone uitvoeringsmodel gebruik, word enkripsie ook nie onmiddellik uitgevoer nie, maar 'n ander tou omseil. Nadat enkripsie voltooi is, kan dm-crypt probeer om hangende skryfversoeke te sorteer met behulp van 'n soekboom . Aan die einde tel 'n aparte kerndraad weer, met 'n sekere vertraging, die opgehoopte I/O-versoeke op en stuur dit na die bloktoestelstapel.
Wanneer jy lees, voeg dm-crypt eers 'n versoek by die "kcryptd_io" tou om data van die skyf te ontvang. Na 'n geruime tyd word die data beskikbaar en word dit in die "kcryptd" tou vir dekripsie geplaas.
Kcryptd stuur 'n versoek na die Linux Crypto API, wat die inligting asynchronies dekripteer. Versoeke gaan nie altyd deur al die toue nie, maar in die ergste geval beland 'n skryfversoek tot 4 keer in rye, en 'n leesversoek tot 3 keer. Elke treffer in die tou veroorsaak vertragings, wat die belangrikste rede is vir die aansienlike afname in dm-crypt-prestasie.
Die gebruik van toue is as gevolg van die behoefte om te werk in toestande waar onderbrekings voorkom. In 2005, toe dm-crypt se huidige tou-gebaseerde bedryfsmodel geïmplementeer is, was die Crypto API nog nie asynchroon nie. Nadat die Crypto API na 'n asynchrone uitvoeringsmodel oorgedra is, het in wese dubbele beskerming begin gebruik word. Toue is ook ingestel om verbruik van die kernstapel te bespaar, maar ná die toename in 2014 het hierdie optimaliserings hul relevansie verloor. 'n Bykomende tou "kcryptd_io" is ingestel om die bottelnek te oorkom wat gelei het tot die wag vir geheuetoewysing wanneer 'n groot aantal versoeke arriveer. In 2015 is 'n bykomende sorteerfase ingestel, aangesien enkripsieversoeke op multiverwerkerstelsels buite werking voltooi kon word (in plaas van opeenvolgende toegang tot die skyf, is toegang in ewekansige volgorde uitgevoer, en die CFQ-skeduleerder het nie doeltreffend gewerk nie). Tans, wanneer SSD-aandrywers gebruik word, het sortering sy betekenis verloor, en die CFQ-skeduleerder word nie meer in die kern gebruik nie.
Aangesien moderne aandrywers vinniger en slimmer geword het, is die hulpbronverspreidingstelsel in die Linux-kern hersien en sommige substelsels is herontwerp, het Cloudflare-ingenieurs dm-crypt het 'n nuwe bedryfsmodus wat die gebruik van onnodige toue en asynchrone oproepe uitskakel. Die modus word geaktiveer deur 'n aparte vlag "force_inline" en bring dm-crypt in die vorm van 'n eenvoudige instaanbediener wat inkomende versoeke enkripteer en dekripteer. Interaksie met die Crypto API is geoptimaliseer deur eksplisiet enkripsiealgoritmes te kies wat in sinchroniese modus werk en nie versoekrye gebruik nie. Om sinchroon te werk met die Crypto API was daar 'n module wat jou toelaat om FPU/AES-NI te gebruik vir versnelling en enkripsie- en dekripsieversoeke direk aanstuur.
As gevolg hiervan, wanneer 'n RAM-skyf getoets word, was dit moontlik om die werkverrigting van dm-crypt meer as te verdubbel - werkverrigting het toegeneem van 294 MB/s (2 x 147 MB/s) tot 640 MB/s, wat baie naby aan die prestasie van blote enkripsie (696 MB /s).
Wanneer las op regte bedieners getoets is, het die nuwe implementering prestasie baie naby aan die konfigurasie getoon wat sonder enkripsie loop, en die aktivering van enkripsie op bedieners met Cloudflare-kas het geen effek op reaksiespoed gehad nie. In die toekoms beplan Cloudflare om die voorbereide pleisters na die hoof Linux-kern oor te dra, maar voor dit sal hulle herwerk moet word, aangesien dit geoptimaliseer is vir 'n spesifieke vrag en nie alle toepassingsareas dek nie, byvoorbeeld enkripsie op lae -krag ingebedde toestelle.
Bron: opennet.ru