Програмери од Cloudflare за извршување на работа за оптимизирање на перформансите на шифрирањето на дискот во кернелот Линукс. Како резултат на тоа, тие беа подготвени за потсистем и Crypto API, што овозможи повеќе од двојно да се зголеми пропусната моќ за читање и запишување во синтетичкиот тест, како и да се преполови латентноста. Кога се тестираше на вистински хардвер, трошоците за шифрирање беа намалени на речиси нивото забележано при работа со диск без шифрирање на податоци.
Cloudflare користи dm-crypt за шифрирање на податоците на уредите за складирање што се користат за кеширање на содржината на CDN. Dm-crypt работи на ниво на блок уред и ги шифрира барањата за влез/излез за пишување и ги дешифрира барањата за читање, дејствувајќи како слој помеѓу блок-уредот и двигателот на датотечниот систем.
Да се оцени ефикасноста на dm-crypt користејќи го пакетот Ја измеривме брзината на работа со шифрирани и нешифрирани партиции на RAM-диск лоциран во RAM-от за да ги елиминираме флуктуациите во перформансите на дискот и да се фокусираме на перформансите на кодот. За нешифрирани партиции, перформансите за читање и пишување останаа на 1126 MB/s, но брзината се намали кога беше овозможено шифрирањето 7 во времето и изнесуваше 147 MB/s.
Отпрвин, се појави сомнеж за употребата на неефикасни алгоритми во криптосистемот на јадрото. Но, тестовите го користеа најбрзиот алгоритам, aes-xts, со 256 клучеви за шифрирање, чии перформанси при извршувањето на „реперот за cryptsetup“ се повеќе од двапати повисоки од резултатот добиен при тестирање на RAM-диск. Експериментите со знаменцата dm-crypt за подесување на перформансите не дадоа резултати: при користење на знамето „--perf-same_cpu_crypt“, перформансите дури се намалија на 136 MB/s, а при одредувањето на знамето „--perf-submit_from_crypt_cpus“ се зголемија само до 166 MB/s.
Подлабоката анализа на оперативната логика покажа дека dm-crypt не е толку едноставно како што изгледа - кога ќе пристигне барање за запишување од двигателот FS, dm-crypt не го обработува веднаш, туку го става во редот „kcryptd“, кој не се анализира веднаш, но кога е погоден момент. Од редот, барањето се испраќа до Linux Crypto API за да се изврши шифрирање. Но, бидејќи Crypto API користи асинхрон модел на извршување, шифрирањето исто така не се врши веднаш, туку се заобиколува друга редица. Откако ќе заврши шифрирањето, dm-crypt може да се обиде да ги сортира барањата за пишување што чекаат со помош на дрво за пребарување . На крајот, посебна нишка на кернелот повторно, со одредено задоцнување, ги зема акумулираните барања за влез/излез и ги испраќа до стекот на блок уреди.
Кога читате, dm-crypt прво додава барање во редот „kcryptd_io“ за примање податоци од дискот. По некое време, податоците стануваат достапни и се ставаат во редот „kcryptd“ за дешифрирање.
Kcryptd испраќа барање до Linux Crypto API, кој ги дешифрира информациите асинхроно. Барањата не секогаш поминуваат низ сите редици, но во најлошото сценарио, барањето за запишување завршува во редици до 4 пати, а барањето за читање до 3 пати. Секој удар во редот предизвикува одложувања, кои се клучната причина за значителното намалување на перформансите на dm-crypt.
Користењето на редици се должи на потребата да се работи во услови каде што има прекини. Во 2005 година, кога беше имплементиран тековниот оперативен модел на dm-crypt базиран на редици, Crypto API сè уште не беше асинхрон. Откако Crypto API беше префрлен на асинхрон модел на извршување, во суштина почна да се користи двојна заштита. Беа воведени и редици за да се заштеди потрошувачката на стекот на јадрото, но по неговото зголемување во 2014 година, овие оптимизации ја изгубија својата важност. Беше воведена дополнителна редица „kcryptd_io“ за да се надмине тесното грло што резултираше со чекање за распределба на меморијата кога ќе пристигнат голем број барања. Во 2015 година, беше воведена дополнителна фаза на сортирање, бидејќи барањата за шифрирање на повеќепроцесорски системи можеа да се завршат без ред (наместо секвенцијален пристап до дискот, пристапот беше извршен по случаен редослед, а распоредувачот CFQ не работеше ефикасно). Во моментов, при користење на SSD-дискови, сортирањето го изгуби своето значење, а распоредувачот CFQ повеќе не се користи во јадрото.
Имајќи предвид дека модерните дискови станаа побрзи и попаметни, системот за дистрибуција на ресурси во кернелот на Linux е ревидиран и некои потсистеми се редизајнирани, инженерите на Cloudflare dm-crypt има нов режим на работа кој ја елиминира употребата на непотребни редици и асинхрони повици. Режимот е овозможен со посебно знаменце „force_inline“ и ја носи dm-crypt во форма на едноставен прокси кој шифрира и дешифрира дојдовни барања. Интеракцијата со Crypto API е оптимизирана со експлицитен избор на алгоритми за шифрирање кои работат во синхрони режим и не користат редици за барање. За да работи синхроно со Crypto API имаше модул кој ви овозможува да користите FPU/AES-NI за забрзување и директно препраќање на барања за шифрирање и дешифрирање.
Како резултат на тоа, при тестирање на RAM-диск, беше можно повеќе од двојно да се удвојат перформансите на dm-crypt - перформансите се зголемија од 294 MB/s (2 x 147 MB/s) на 640 MB/s, што е многу блиску до перформансите на голо шифрирање (696 MB / s).
При тестирање на оптоварувањето на вистински сервери, новата имплементација покажа перформанси многу блиски до конфигурацијата што работи без шифрирање, а овозможувањето шифрирање на серверите со кешот на Cloudflare немаше ефект врз брзината на одговорот. Во иднина, Cloudflare планира да ги пренесе подготвените закрпи на главниот кернел на Linux, но пред тоа ќе треба да се преработат, бидејќи тие се оптимизирани за одредено оптоварување и не ги покриваат сите области на примена, на пример, шифрирање на ниско ниво. - вградени уреди за напојување.
Извор: opennet.ru