L Розробники Cloudflare випустили інформація про роботу, яку вони виконують для оптимізації продуктивності шифрування диска в ядрі Linux, про яку вони згадують, що вони підготували виправлення для підсистем dm-crypt та Crypto API.
З цим, синтетичному тесту дозволялося подвоїти пропускну здатність для читання та письма, а також зменшення затримки вдвічі. Під час тестування на реальних машинах накладні витрати на шифрування були зменшені майже до рівня, який спостерігається при роботі з диском без використання шифрування даних.
Інтерес до вдосконалення шифрування дані на диску це тому, що Cloudflare використовує dm-crypt для шифрування даних на дисках, що використовуються для кешування вмісту на CDN. Dm-crypt працює на рівні блокових пристроїв і шифрує запити вводу / виводу для запису та дешифрування запитів на читання, діючи як шар між блочним пристроєм і драйвером файлової системи.
Для оцінки ефективності dm-crypt з використанням гнучкого тестового пакета вводу-виводу, se вимірювали швидкість роботи із зашифрованими розділами і не зашифровані на диску оперативної пам'яті, який знаходиться в оперативній пам'яті, щоб усунути коливання продуктивності диска
Для незашифрованих розділів продуктивність читання та запису залишалася на рівні 1126 МБ / с, але коли було ввімкнено шифрування, швидкість впала в 7 разів до 147 МБ / с.
На початку підозрювались у використанні неефективних алгоритмів в криптографічній системі ядра. Але в тестах використовувався більш швидкий алгоритм aes-xts з 256 ключами шифрування, ефективність якого під час запуску "еталону cryptsetup" більш ніж у два рази перевищувала результат, отриманий при тестуванні диска RAM.
Експерименти з прапорами dm-crypt відрегулювати продуктивність не вийшло: При використанні прапора –perf-same_cpu_crypt продуктивність навіть знизилася до 136 МБ / с, а при використанні прапора –perf-submit_from_crypt_cpus вона зросла лише до 166 МБ / с.
Більш глибокий аналіз логіки роботи показав, що dm-склеп не такий простий як здається.
Коли запит на запис надійшов від контролера FS, dm-crypt не обробляє його відразу, а поміщає в чергу "kcryptd", що зрозуміло не відразу, але коли настає вдалий час. З черги запит надсилається до Linux Crypto API для шифрування.
При першому читанні dm-crypt ставить в чергу "kcryptd_io" запит на отримання даних від підрозділу. Після з часом дані доступні і вони потрапляють у чергу "kcryptd" для дешифрування.
Kcryptd надсилає запит до API шифрування Linux, який асинхронно розшифровує інформацію. Запити не завжди проходять усі черги, але в гіршому випадку, запит на запис встановлюється в чергах до 4 разів і запит на читання до 3 разів. Кожен удар у хвіст призводить до затримок, які є основною причиною значного зниження продуктивності dm-крипти.
Враховуючи, що сучасні диски стали швидшими та розумнішими, система розподілу ресурсів у ядрі Linux була переглянута і деякі підсистеми перероблені, Інженери Cloudflare додали новий режим роботи до dm-crypt, виключивши використання додаткових черг та асинхронних дзвінків.
Режим вмикається окремим прапором "force_inline" і приймає dm-crypt у вигляді простого проксі-сервера, який шифрує та дешифрує вхідні запити. Взаємодія з Crypto API була оптимізована завдяки чіткому вибору алгоритмів шифрування Вони працюють в синхронному режимі і не використовують черги запитів.
При тестуванні навантаження на реальні сервери, нова реалізація показала продуктивність, дуже близьку до конфігурації, яка працює без шифрування, а включення шифрування на сервери з кешем Cloudflare не вплинуло на швидкість відповіді.
В майбутньому, Cloudflare планує перенести підготовлені виправлення на основне ядро Linux, але перед цим їх доведеться модифікувати, оскільки вони оптимізовані для певного навантаження і не охоплюють усіх областей застосування.
Фуенте: https://blog.cloudflare.com