Компанията Cloudflare подготви пачове, които радикално ускоряват дисковото криптиране в Linux

Разработчиците от компанията Cloudflare разказахме за извършването на работа по оптимизация на производителността на дисковото криптиране в ядрото на Linux. В резултат бяха подготвени патчове за подсистемата dm-crypt и Crypto API, които в синтетичен тест повишиха пропускната способност при четене и запис на повече от два пъти, както и намалиха закъсненията два пъти. При тестване на реално оборудване разходите от криптиране бяха сведени почти до нивото, наблюдавано при работа с диск без криптиране на данни.

Cloudflare използва dm-crypt за криптиране на данни на носители, използвани за кеширане на съдържание в CDN мрежата. Dm-crypt работи на ниво блоково устройство и криптира входно/изходни заявки за запис и дешифрира заявки за четене, действайки като междинен слой между блоковото устройство и драйвера на файловата система.

За оценка на производителността на dm-crypt с помощта на пакета Flexible I/O tester бяха извършени измервания на скоростта на работа с криптирани и некриптирани дялове на RAM-диск, разположен в оперативната памет, за да се изключат колебанията в производителността на дисковете и да се фокусира върху производителността на кода. За некриптираните дялове производителността на четене и запис беше на ниво 1126 MB/s, но при включване на криптиране скоростта намаля седем пъти и стана 147 MB/s.

Първоначално имаше подозрения за използване на неефективни алгоритми в криптосистемата на ядрото. Но в тестовете беше използван най-бързият алгоритъм aes-xts с 256-битов ключ за криптиране, чието представяне при извършване на 'cryptsetup benchmark' е повече от два пъти по-високо от полученото при тестване на RAM-диск резултат. Експериментите с флаговете на dm-crypt за оптимизиране на производителността не доведоха до резултати: при използване на флага '—perf-same_cpu_crypt' производителността дори намаля до 136 MB/s, а при задаване на флага '—perf-submit_from_crypt_cpus' нарасна само до 166 MB/s.

По-дълбокият анализ на логиката на работа показа, че dm-crypt не е толкова прост, колкото изглежда — при получаване на заявка за запис от драйвера на файловата система, 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