sok A Cloudflare fejlesztők kiadták információk a Linux kernelben a lemez titkosításának optimalizálása érdekében végzett munkáról, amelyről megemlítik, hogy elkészültek javítások a dm-crypt és a Crypto API alrendszerekhez.
Ezzel a szintetikus teszt megduplázta a sávszélességet az olvasáshoz és az íráshoz, valamint felére csökkenteni a késést. Valódi gépeken végzett tesztelésekor a titkosítási rezsicsökkentés majdnem arra a szintre csökkent, amelyet akkor láthattunk, amikor egy lemezzel dolgoztunk adat titkosítás nélkül.
Érdeklődés a titkosítás javítása iránt adatok a lemezen azért van, mert a Cloudflare dm-cryptot használ a CDN-n lévő tartalom gyorsítótárazására használt meghajtókon lévő adatok titkosításához. A Dm-crypt blokkeszköz-szinten működik, és titkosítja az I / O kéréseket az olvasási kérelmek írására és visszafejtésére, rétegként működve a blokkoló eszköz és a fájlrendszer-illesztőprogram között.
A teljesítmény értékeléséhez dm-crypt a rugalmas I / O tesztcsomaggal, smértük a titkosított partíciókkal végzett munka sebességét és nincs titkosítva a RAM-ban található RAM lemezen, hogy kiküszöbölje a lemez teljesítményének ingadozásait.
A titkosítatlan partíciók esetében az írási és olvasási teljesítmény 1126 MB / s maradt, de a titkosítás bekapcsolásakor a sebesség 7-szeresére esett, 147 MB / s-ra.
Először, nem hatékony algoritmusok használatát gyanították a kernel kriptográfiai rendszerében. De a tesztek a gyorsabb aes-xts algoritmust használták 256 titkosítási kulccsal, amelyek teljesítménye a "cryptsetup benchmark" futtatásakor több mint kétszerese a RAM-lemez tesztelésénél elért eredménynek.
A kísérletek dm-kriptás zászlókkal a teljesítmény beállításához nem működött: A –perf-same_cpu_crypt zászló használatakor a teljesítmény még 136 MB / s-ra is csökkent, és a –perf-submit_from_crypt_cpus zászló használatakor csak 166 MB / s-ra nőtt.
Mélyebb elemzés a munka logikája megmutatta, hogy a dm-kripta nem ilyen egyszerű mint amilyennek látszik.
Amikor írási kérést kap az FS vezérlőtől, a dm-crypt nem dolgozza fel azonnal, hanem a "kcryptd" sorba helyezi, amelyet nem azonnal értünk, de ha jó idő következik be. A várólistáról a kérést elküldik a Linux Crypto API számára titkosítás céljából.
Első olvasáskor a dm-crypt "kcryptd_io" várakozási sorok adatkérés kérése az egységtől. Után idővel az adatok rendelkezésre állnak és "kcryptd" sorban vannak a visszafejtéshez.
A Kcryptd kérést küld a Linux Encryption API-nak, amely aszinkron módon dekódolja az információkat. A kérések nem mindig mennek végig minden soron, de a legrosszabb esetben az írási kérelem legfeljebb négyszer van beállítva a várólistákra és az olvasási kérelem akár háromszor is. A sor minden találata késésekhez vezet, melyek a dm-crypt teljesítmény jelentős csökkenésének fő okai.
Tekintettel arra, hogy a modern meghajtók gyorsabbá és okosabbá váltak, a Linux kernel erőforrás-allokációs rendszerét átdolgozták és néhány alrendszert átalakítottakA Cloudflare mérnökei új üzemmódot adtak a dm-crypt-hez, kiküszöbölve a további várólisták és aszinkron hívások használatát.
A módot egy külön "force_inline" jelző engedélyezi, és a dm-crypt-ot egy egyszerű proxy formájában hozza létre, amely titkosítja és visszafejti a beérkező kéréseket. A Crypto API-val való interakciót a titkosítási algoritmusok kifejezett megválasztásával optimalizálták Szinkron módban működnek, és nem használnak kérési sorokat.
A valódi szerverek terhelésének tesztelésekor az új telepítés nagyon közel volt a titkosítás nélkül működő konfigurációhoz, és a Cloudflare gyorsítótárral rendelkező szerverekre történő titkosítás nem befolyásolta a válasz sebességét.
A jövőben, A Cloudflare azt tervezi, hogy az előkészített javításokat átviszi a fő Linux kernelbe, de előtte módosítani kell őket, mivel egy bizonyos terhelésre vannak optimalizálva, és nem fedik le az összes alkalmazási területet.
forrás: https://blog.cloudflare.com