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

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

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

За да оцените производителността на dm-crypt с помощта на пакета Гъвкав I/O тестер Измерихме скоростта на работа с криптирани и некриптирани дялове на RAM диск, разположен в RAM, за да елиминираме колебанията в производителността на диска и да се съсредоточим върху производителността на кода. За некриптирани дялове, производителността при четене и запис остава на 1126 MB/s, но скоростта намалява, когато криптирането е активирано 7 във времето и възлиза на 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 не е толкова просто, колкото изглежда - когато пристигне заявка за запис от FS драйвера, dm-crypt не я обработва веднага, а я поставя в опашката „kcryptd“, което не се анализира веднага, а когато е удобен момент. От опашката заявката се изпраща до Linux Crypto API за извършване на криптиране. Но тъй като Crypto API използва асинхронен модел на изпълнение, криптирането също не се извършва веднага, а заобикаляйки друга опашка. След като криптирането приключи, dm-crypt може да се опита да сортира чакащи заявки за запис, като използва дърво за търсене червено-черно. Накрая отделна нишка на ядрото отново, с известно забавяне, взима натрупаните I/O заявки и ги изпраща към стека на блоковото устройство.

При четене 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