Datblygwyr o Cloudflare am wneud gwaith i optimeiddio perfformiad amgryptio disg yn y cnewyllyn Linux. O ganlyniad, cawsant eu paratoi ar gyfer is-system a Crypto API, a oedd yn ei gwneud hi'n bosibl mwy na dyblu'r trwybwn darllen ac ysgrifennu yn y prawf synthetig, yn ogystal â haneru hwyrni. Pan gafodd ei brofi ar galedwedd go iawn, gostyngwyd gorbenion amgryptio i bron y lefel a arsylwyd wrth weithio gyda disg heb amgryptio data.
Mae Cloudflare yn defnyddio dm-crypt i amgryptio data ar ddyfeisiau storio a ddefnyddir i storio cynnwys ar y CDN. Mae Dm-crypt yn gweithredu ar lefel dyfais bloc ac mae amgryptio yn ysgrifennu ceisiadau I/O ac yn dadgryptio ceisiadau darllen, gan weithredu fel haen rhwng y ddyfais bloc a gyrrwr y system ffeiliau.
I werthuso perfformiad dm-crypt gan ddefnyddio'r pecyn Fe wnaethom fesur cyflymder gweithio gyda rhaniadau wedi'u hamgryptio a heb eu hamgryptio ar ddisg RAM sydd wedi'i lleoli yn RAM i ddileu amrywiadau mewn perfformiad disg a chanolbwyntio ar berfformiad cod. Ar gyfer rhaniadau heb eu hamgryptio, arhosodd perfformiad darllen ac ysgrifennu ar 1126 MB/s, ond gostyngodd y cyflymder pan alluogwyd amgryptio 7 mewn amser ac roedd yn dod i 147 MB/s.
Ar y dechrau, cododd amheuaeth ynghylch y defnydd o algorithmau aneffeithlon yn y system crypto cnewyllyn. Ond defnyddiodd y profion yr algorithm cyflymaf, aes-xts, gyda 256 o allweddi amgryptio, y mae eu perfformiad wrth redeg y “meincnod cryptsetup” fwy na dwywaith yn uwch na'r canlyniad a gafwyd wrth brofi disg RAM. Ni roddodd arbrofion gyda baneri dm-crypt ar gyfer tiwnio perfformiad ganlyniadau: wrth ddefnyddio'r faner “--perf-same_cpu_crypt”, gostyngodd perfformiad hyd yn oed i 136 MB/s, ac wrth nodi'r faner “--perf-submit_from_crypt_cpus” fe gynyddodd yn unig i 166 MB/s.
Dangosodd dadansoddiad dyfnach o'r rhesymeg weithredu nad yw dm-crypt mor syml ag y mae'n ymddangos - pan fydd cais ysgrifennu yn cyrraedd gan y gyrrwr FS, nid yw dm-crypt yn ei brosesu ar unwaith, ond yn ei osod yn y ciw “kcryptd”, sy'n nid yw'n cael ei ddosrannu ar unwaith, ond pan fo'n gyfleus. O'r ciw, anfonir y cais at API Linux Crypto i berfformio amgryptio. Ond gan fod yr API Crypto yn defnyddio model gweithredu asyncronaidd, nid yw amgryptio hefyd yn cael ei berfformio ar unwaith, ond yn osgoi ciw arall. Ar ôl i'r amgryptio gael ei gwblhau, gall dm-crypt geisio didoli ceisiadau ysgrifennu sydd ar y gweill gan ddefnyddio coeden chwilio . Ar y diwedd, mae edau cnewyllyn ar wahân eto, gydag oedi penodol, yn codi'r ceisiadau I / O cronedig ac yn eu hanfon at y pentwr dyfais bloc.
Wrth ddarllen, mae dm-crypt yn gyntaf yn ychwanegu cais at y ciw “kcryptd_io” i dderbyn data o'r gyriant. Ar ôl peth amser, daw'r data ar gael a chaiff ei roi yn y ciw “kcryptd” ar gyfer dadgryptio.
Mae Kcryptd yn anfon cais i'r Linux Crypto API, sy'n dadgryptio'r wybodaeth yn anghydamserol. Nid yw ceisiadau bob amser yn mynd trwy'r holl giwiau, ond yn y senario waethaf, mae cais ysgrifennu yn dod i ben mewn ciwiau hyd at 4 gwaith, a chais darllen hyd at 3 gwaith. Mae pob ergyd i'r ciw yn achosi oedi, sef y prif reswm dros y gostyngiad sylweddol mewn perfformiad dm-crypt.
Mae'r defnydd o giwiau oherwydd yr angen i weithio mewn amodau lle mae ymyriadau'n digwydd. Yn 2005, pan weithredwyd model gweithredu cyfredol yn seiliedig ar giw dm-crypt, nid oedd yr API Crypto yn asyncronaidd eto. Ar ôl i'r API Crypto gael ei drosglwyddo i fodel gweithredu asyncronig, dechreuwyd defnyddio amddiffyniad dwbl yn y bôn. Cyflwynwyd ciwiau hefyd i arbed defnydd o staciau cnewyllyn, ond ar ôl ei gynnydd yn 2014, collodd yr optimeiddiadau hyn eu perthnasedd. Cyflwynwyd ciw ychwanegol "kcryptd_io" i oresgyn y dagfa gan arwain at aros am ddyraniad cof pan fydd nifer fawr o geisiadau yn cyrraedd. Yn 2015, cyflwynwyd cam didoli ychwanegol, gan y gellid cwblhau ceisiadau amgryptio ar systemau amlbrosesydd allan o drefn (yn lle mynediad dilyniannol i'r ddisg, cynhaliwyd mynediad mewn trefn ar hap, ac ni weithiodd yr amserlennydd CFQ yn effeithlon). Ar hyn o bryd, wrth ddefnyddio gyriannau SSD, mae didoli wedi colli ei ystyr, ac nid yw'r amserlennydd CFQ bellach yn cael ei ddefnyddio yn y cnewyllyn.
O ystyried bod gyriannau modern wedi dod yn gyflymach ac yn ddoethach, mae'r system dosbarthu adnoddau yn y cnewyllyn Linux wedi'i diwygio ac mae rhai is-systemau wedi'u hailgynllunio, peirianwyr Cloudflare Mae gan dm-crypt fodd gweithredu newydd sy'n dileu'r defnydd o giwiau diangen a galwadau anghydamserol. Mae'r modd wedi'i alluogi gan faner ar wahân “force_inline” ac mae'n dod â dm-crypt i ffurf dirprwy syml sy'n amgryptio a dadgryptio ceisiadau sy'n dod i mewn. Mae rhyngweithio â'r API Crypto wedi'i optimeiddio trwy ddewis yn benodol algorithmau amgryptio sy'n gweithredu mewn modd cydamserol ac nad ydynt yn defnyddio ciwiau cais. Er mwyn gweithio'n gydamserol â'r API Crypto roedd yna modiwl sy'n eich galluogi i ddefnyddio FPU/AES-NI ar gyfer cyflymu ac sy'n anfon ceisiadau amgryptio a dadgryptio ymlaen yn uniongyrchol.
O ganlyniad, wrth brofi disg RAM, roedd yn bosibl mwy na dyblu perfformiad dm-crypt - cynyddodd perfformiad o 294 MB/s (2 x 147 MB/s) i 640 MB/s, sy'n agos iawn at perfformiad amgryptio noeth (696 MB / s).
Wrth brofi llwyth ar weinyddion go iawn, dangosodd y gweithrediad newydd berfformiad yn agos iawn at y cyfluniad yn rhedeg heb amgryptio, ac nid oedd galluogi amgryptio ar weinyddion gyda storfa Cloudflare yn cael unrhyw effaith ar gyflymder ymateb. Yn y dyfodol, mae Cloudflare yn bwriadu trosglwyddo'r clytiau parod i'r prif gnewyllyn Linux, ond cyn hynny bydd angen eu hailweithio, gan eu bod wedi'u optimeiddio ar gyfer llwyth penodol ac nad ydynt yn cwmpasu pob maes cais, er enghraifft, amgryptio ar isel. -power dyfeisiau gwreiddio.
Ffynhonnell: opennet.ru