A Cloudflare fejlesztői a Linux kernel lemeztitkosítási teljesítményének optimalizálása érdekében végzett munkáról. Ennek eredményeként felkészültek alrendszerhez és Crypto API, amely lehetővé tette a szintetikus teszt olvasási és írási sebességének több mint kétszeresét, valamint a késleltetés felére csökkentését. Valódi hardveren tesztelve a titkosítási többlet szinte arra a szintre csökkent, amelyet adattitkosítás nélküli lemezzel végzett munka során tapasztaltak.
A Cloudflare a dm-crypt segítségével titkosítja az adatokat a CDN-n lévő tartalom gyorsítótárazására használt tárolóeszközökön. A Dm-crypt a blokkeszköz szintjén működik, és titkosítja az írási I/O kéréseket és visszafejti az olvasási kéréseket, rétegként működik a blokkeszköz és a fájlrendszer-illesztőprogram között.
A dm-crypt teljesítményének értékelése a csomag használatával Megmértük a RAM-ban található RAM-lemez titkosított és titkosítatlan partícióival végzett munka sebességét, hogy kiküszöböljük a lemez teljesítményének ingadozásait, és a kódteljesítményre összpontosítsunk. A titkosítatlan partíciók esetében az olvasási és írási teljesítmény 1126 MB/s maradt, de a sebesség csökkent a titkosítás engedélyezésekor 7-szor és 147 MB/s volt.
Eleinte felmerült a gyanú, hogy nem hatékony algoritmusokat használnak a kernel titkosítási rendszerében. A tesztek azonban a leggyorsabb algoritmust, az aes-xts-t használták 256 titkosítási kulccsal, amelynek teljesítménye a „cryptsetup benchmark” futtatásakor több mint kétszerese a RAM-lemez tesztelésekor kapott eredménynek. A teljesítményhangolást szolgáló dm-crypt flagekkel végzett kísérletek nem hoztak eredményt: a „--perf-same_cpu_crypt” jelző használatakor a teljesítmény még 136 MB/s-ra is csökkent, a „--perf-submit_from_crypt_cpus” jelző megadásakor pedig csak nőtt. 166 MB/s-ig.
A működési logika mélyebb elemzése megmutatta, hogy a dm-crypt nem olyan egyszerű, mint amilyennek látszik – amikor az FS meghajtóból írási kérés érkezik, a dm-crypt nem dolgozza fel azonnal, hanem a „kcryptd” sorba helyezi, ami A rendszer nem azonnal elemzi, hanem amikor megfelelő pillanatban. A várakozási sorból a kérés elküldésre kerül a Linux Crypto API-nak titkosítás végrehajtására. De mivel a Crypto API aszinkron végrehajtási modellt használ, a titkosítás sem azonnal, hanem egy másik sor megkerülésével történik. A titkosítás befejezése után a dm-crypt megpróbálhatja rendezni a függőben lévő írási kéréseket egy keresési fa segítségével . A végén ismét egy külön kernelszál, bizonyos késleltetéssel felveszi a felhalmozott I/O kéréseket, és elküldi a blokkeszköz-veremnek.
Olvasáskor a dm-crypt először egy kérést ad a „kcryptd_io” sorhoz, hogy adatokat fogadjon a meghajtóról. Egy idő után az adatok elérhetővé válnak, és a „kcryptd” sorba kerülnek a visszafejtéshez.
A Kcryptd kérést küld a Linux Crypto API-nak, amely aszinkron módon visszafejti az információkat. A kérések nem mindig mennek át az összes sorban, de a legrosszabb esetben egy írási kérés legfeljebb 4-szer, egy olvasási kérelem pedig legfeljebb 3-szor kerül sorba. A várólista minden egyes találata késéseket okoz, ami a fő oka a dm-crypt teljesítmény jelentős csökkenésének.
A sorok használata annak köszönhető, hogy olyan körülmények között kell dolgozni, ahol megszakítások fordulnak elő. 2005-ben, amikor a dm-crypt jelenlegi sor alapú működési modelljét implementálták, a Crypto API még nem volt aszinkron. Miután a Crypto API-t áthelyezték egy aszinkron végrehajtási modellre, lényegében kettős védelmet kezdtek alkalmazni. A sorokat is bevezették a kernelverem fogyasztásának csökkentése érdekében, de a 2014-es növekedés után ezek az optimalizálások elvesztették relevanciájukat. Egy további "kcryptd_io" sor került bevezetésre a szűk keresztmetszet leküzdésére, amely a memóriafoglalásra vár, amikor nagyszámú kérés érkezik. 2015-ben egy további rendezési fázist vezettek be, mivel a többprocesszoros rendszereken a titkosítási kérelmek soron kívül teljesíthetők (a lemezhez való szekvenciális hozzáférés helyett véletlenszerű sorrendben történt a hozzáférés, és a CFQ ütemező nem működött hatékonyan). Jelenleg az SSD meghajtók használatakor a rendezés értelmét vesztette, és a CFQ ütemezőt már nem használják a kernelben.
Tekintettel arra, hogy a modern meghajtók gyorsabbak és intelligensebbek lettek, a Linux kernel erőforrás-elosztási rendszerét felülvizsgálták, és néhány alrendszert újraterveztek, a Cloudflare mérnökei A dm-crypt új működési móddal rendelkezik, amely kiküszöböli a szükségtelen sorok és az aszinkron hívások használatát. A módot egy külön „force_inline” jelző engedélyezi, és a dm-cryptet egy egyszerű proxy formájába hozza, amely titkosítja és visszafejti a bejövő kéréseket. A Crypto API-val való interakciót úgy optimalizálták, hogy kifejezetten olyan titkosítási algoritmusokat választottak, amelyek szinkron módban működnek, és nem használnak kérési sorokat. A Crypto API-val szinkronban dolgozni kellett egy modul, amely lehetővé teszi az FPU/AES-NI használatát a gyorsításhoz, és közvetlenül továbbítja a titkosítási és visszafejtési kéréseket.
Ennek eredményeként egy RAM-lemez tesztelésekor több mint kétszeresére lehetett növelni a dm-crypt teljesítményét - a teljesítmény 294 MB/s-ról (2 x 147 MB/s) 640 MB/s-ra nőtt, ami nagyon közel áll a a csupasz titkosítás teljesítménye (696 MB/s).
A valós szerverek terhelésének tesztelésekor az új megvalósítás a titkosítás nélkül futó konfigurációhoz nagyon közeli teljesítményt mutatott, és a titkosítás engedélyezése a Cloudflare gyorsítótárral rendelkező szervereken nem volt hatással a válaszsebességre. A jövőben a Cloudflare azt tervezi, hogy az előkészített javításokat átviszi a fő Linux kernelre, de előtte át kell őket dolgozni, mivel adott terhelésre vannak optimalizálva, és nem fedik le az alkalmazás minden területét, például az alacsony szintű titkosítást. - tápellátású beágyazott eszközök.
Forrás: opennet.ru