Untwikkelders fan Cloudflare oer it útfieren fan wurk om de prestaasjes fan skiiffersifering yn 'e Linux-kernel te optimalisearjen. Dêrtroch waarden se taret foar subsysteem en Crypto API, dy't it mooglik makke om mear as ferdûbelje de lês- en skriuwsnelheid yn 'e syntetyske test, en ek halve latency. Wannear't testen op echte hardware, waard fersifering overhead ferlege ta hast it nivo waarnommen by it wurkjen mei in skiif sûnder gegevens fersifering.
Cloudflare brûkt dm-crypt om gegevens te fersiferjen op opslachapparaten dy't brûkt wurde om ynhâld op 'e CDN te cache. Dm-crypt wurket op it blok apparaat nivo en fersiferet skriuwen I / O fersiken en ûntsiferje lêzen fersiken, fungearret as in laach tusken it blok apparaat en de triem systeem bestjoerder.
Om de prestaasjes fan dm-crypt te evaluearjen mei it pakket Wy mjitten de snelheid fan it wurkjen mei fersifere en net-fersifere partysjes op in RAM-skiif dy't yn RAM leit om fluktuaasjes yn skiifprestaasjes te eliminearjen en te fokusjen op koadeprestaasjes. Foar net-fersifere partysjes bleau de lês- en skriuwprestaasjes op 1126 MB/s, mar de snelheid naam ôf doe't fersifering ynskeakele wie 7 kear en bedroech 147 MB / s.
Yn it earstoan ûntstie der fertinking oer it brûken fan ineffisjinte algoritmen yn it kernel-kryptosysteem. Mar de tests brûkten it fluchste algoritme, aes-xts, mei 256 fersiferingskaaien, wêrfan de prestaasje by it útfieren fan 'e "cryptsetup benchmark" mear as twa kear sa heech is as it resultaat krigen by it testen fan in RAM-skiif. Eksperiminten mei dm-crypt-flaggen foar it ôfstimmen fan prestaasjes levere gjin resultaten op: by it brûken fan de flagge "--perf-same_cpu_crypt" fermindere de prestaasjes sels nei 136 MB/s, en by it opjaan fan de flagge "--perf-submit_from_crypt_cpus" fergrutte it allinich oant 166 MB / s.
In djippere analyze fan 'e bestjoeringslogika liet sjen dat dm-crypt net sa ienfâldich is as it liket - as in skriuwfersyk komt fan 'e FS-bestjoerder, ferwurket dm-crypt it net direkt, mar pleatst it yn 'e "kcryptd"-wachtrige, wat wurdt net parsed fuortendaliks, mar wannear handige momint. Fanút de wachtrige wurdt it fersyk stjoerd nei de Linux Crypto API om fersifering út te fieren. Mar om't de Krypto-API in asynchronous útfieringsmodel brûkt, wurdt fersifering ek net fuortendaliks útfierd, mar in oare wachtrige omgean. Nei fersifering is foltôge, kin dm-crypt besykje te sortearjen yn ôfwachting fan skriuwfersiken mei in sykbeam . Oan 'e ein pakt in aparte kearntried wer, mei in bepaalde fertraging, de opboude I / O-oanfragen op en stjoert se nei it blokapparaatstapel.
By it lêzen foeget dm-crypt earst in fersyk ta oan 'e "kcryptd_io"-wachtrige om gegevens fan it stasjon te ûntfangen. Nei in skoftke wurde de gegevens beskikber en wurde pleatst yn 'e "kcryptd" wachtrige foar ûntsiferjen.
Kcryptd stjoert in fersyk nei de Linux Crypto API, dy't de ynformaasje asynchronous ûntsiferet. Fersiken geane net altyd troch alle wachtrijen, mar yn it slimste gefal komt in skriuwfersyk oant 4 kear yn wachtrige, en in lêsfersyk oant 3 kear. Elke hit nei de wachtrige feroarsaket fertragingen, dy't de wichtichste reden binne foar de signifikante fermindering fan dm-crypt-prestaasjes.
It brûken fan wachtrigen komt troch de needsaak om te wurkjen yn omstannichheden dêr't ûnderbrekkings foarkomme. Yn 2005, doe't dm-crypt's hjoeddeistige wachtrige-basearre bestjoeringsmodel waard ymplementearre, wie de Crypto API noch net asynchronous. Nei't de Krypto-API waard oerbrocht nei in asynchronous útfieringsmodel, begon yn wêzen dûbele beskerming te brûken. Wachtrige waarden ek yntrodusearre om konsumpsje fan 'e kernel-stapel te bewarjen, mar nei har ferheging yn 2014 ferlearen dizze optimisaasjes har relevânsje. In ekstra wachtrige "kcryptd_io" waard yntrodusearre om it knelpunt te oerwinnen, wat resulteart yn it wachtsjen op ûnthâldallokaasje as in grut oantal oanfragen oankomme. Yn 2015 waard in ekstra sortearingsfaze ynfierd, om't fersiferingsoanfragen op multiprocessor-systemen net foltôge wurde koene (ynstee fan opfolgjende tagong ta de skiif, waard tagong yn willekeurige folchoarder útfierd, en de CFQ-planner wurke net effisjint). Op it stuit, by it brûken fan SSD-skiven, hat sortearring syn betsjutting ferlern, en de CFQ-planner wurdt net mear brûkt yn 'e kearn.
Yn betinken nommen dat moderne skiven rapper en tûker wurden binne, is it boarne-distribúsjesysteem yn 'e Linux-kernel feroare en guon subsystemen binne opnij ûntwurpen, Cloudflare-yngenieurs dm-crypt hat in nije bestjoeringsmodus dy't it brûken fan ûnnedige wachtrijen en asynchrone oproppen elimineert. De modus is ynskeakele troch in aparte flagge "force_inline" en bringt dm-crypt yn 'e foarm fan in ienfâldige proxy dy't ynkommende fersiken fersiferet en ûntsiferet. Ynteraksje mei de Krypto-API is optimalisearre troch eksplisyt te kiezen foar fersiferingsalgoritmen dy't yn syngroane modus operearje en gjin fersykwachtrige brûke. Om syngroan te wurkjen mei de Krypto API wie d'r in module wêrmei jo te brûken FPU / AES-NI foar fersnelling en direkt foarút fersifering en ûntsiferje fersiken.
As gefolch, by it testen fan in RAM-skiif, wie it mooglik om mear as ferdûbelje de prestaasjes fan dm-crypt - prestaasjes ferhege fan 294 MB / s (2 x 147 MB / s) nei 640 MB / s, dat is hiel tichtby de prestaasjes fan bleate fersifering (696 MB / s).
By it testen fan lading op echte servers, toande de nije ymplemintaasje prestaasjes heul tichtby de konfiguraasje dy't sûnder fersifering rint, en it ynskeakeljen fan fersifering op servers mei Cloudflare-cache hie gjin effekt op antwurdsnelheid. Yn 'e takomst is Cloudflare fan plan om de tariede patches oer te bringen nei de haad Linux-kernel, mar dêrfoar moatte se opnij bewurke wurde, om't se binne optimalisearre foar in spesifike lading en net alle gebieten fan tapassing dekke, bygelyks fersifering op leech -power ynsletten apparaten.
Boarne: opennet.ru