L Deweloperzy Cloudflare wydali informacje o pracy, jaką wykonują, aby zoptymalizować wydajność szyfrowania dysku w jądrze Linuksa, o której wspominają, że przygotowali poprawki dla podsystemów dm-crypt i Crypto API.
Z tym test syntetyczny pozwolił podwoić przepustowość do czytania i pisania, jak również zmniejszyć opóźnienie o połowę. Podczas testowania na prawdziwych maszynach narzut związany z szyfrowaniem został zredukowany do prawie poziomu obserwowanego podczas pracy z dyskiem bez szyfrowania danych.
Zainteresowanie ulepszeniem szyfrowania dane na dysku to dlatego, że Cloudflare używa dm-crypt do szyfrowania danych na dyskach używanych do buforowania zawartości w sieci CDN. Dm-crypt działa na poziomie urządzenia blokowego i szyfruje żądania I / O do zapisu i odszyfrowania żądań odczytu, działając jako warstwa między urządzeniem blokowym a sterownikiem systemu plików.
Ocena wydajności dm-crypt przy użyciu elastycznego pakietu testowego I / O, sZmierzyliśmy szybkość pracy z zaszyfrowanymi partycjami i niezaszyfrowane na dysku RAM znajdującym się w pamięci RAM, aby wyeliminować wahania wydajności dysku.
W przypadku niezaszyfrowanych partycji wydajność odczytu i zapisu pozostała na poziomie 1126 MB / s, ale po włączeniu szyfrowania prędkość spadła 7 razy do 147 MB / s.
Najpierw, podejrzewano użycie nieefektywnych algorytmów w systemie kryptograficznym jądra. Jednak testy wykorzystywały szybszy algorytm aes-xts z 256 kluczami szyfrującymi, którego wydajność podczas uruchamiania „testu porównawczego cryptsetup” jest ponad dwukrotnie wyższa niż wynik uzyskany podczas testowania dysku RAM.
Eksperymenty z flagami dm-crypt dostosowanie wydajności nie działa: Gdy użyto flagi –perf-same_cpu_crypt, wydajność spadła nawet do 136 MB / s, a gdy użyto flagi –perf-submit_from_crypt_cpus, wzrosła tylko do 166 MB / s.
Głębsza analiza logiki pracy pokazał, że dm-crypt nie jest takie proste jak się wydaje.
Gdy żądanie zapisu jest odbierane od kontrolera FS, dm-crypt nie przetwarza go natychmiast, ale zamiast tego umieszcza je w kolejce "kcryptd", co nie jest natychmiast zrozumiałe, ale gdy nadejdzie odpowiedni czas. Z kolejki żądanie jest wysyłane do Linux Crypto API w celu zaszyfrowania.
Podczas pierwszego odczytu kolejki dm-crypt „kcryptd_io” żądanie odbioru danych z jednostki. Po z czasem dane są dostępne i są umieszczane w kolejce "kcryptd" do odszyfrowania.
Kcryptd wysyła żądanie do interfejsu API szyfrowania systemu Linux, który odszyfrowuje informacje asynchronicznie. Żądania nie zawsze przechodzą przez wszystkie kolejki, ale w najgorszym przypadku żądanie zapisu jest ustawiane w kolejkach do 4 razy i żądanie odczytu do 3 razy. Każde trafienie w kolejce prowadzi do opóźnień, które są głównym powodem znacznego spadku wydajności dm-crypt.
Biorąc pod uwagę, że nowoczesne dyski stały się szybsze i inteligentniejsze, system alokacji zasobów w jądrze Linuksa został poprawiony i niektóre podsystemy zostały przeprojektowane, Inżynierowie Cloudflare dodali nowy tryb pracy do dm-crypt, eliminując użycie dodatkowych kolejek i wywołań asynchronicznych.
Tryb ten jest włączany przez osobną flagę „force_inline” i przyjmuje dm-crypt do postaci prostego proxy, które szyfruje i odszyfrowuje przychodzące żądania. Interakcja z Crypto API została zoptymalizowana poprzez wyraźny wybór algorytmów szyfrowania Działają w trybie synchronicznym i nie używają kolejek żądań.
Podczas testowania obciążenia na prawdziwych serwerach nowa implementacja wykazała wydajność bardzo zbliżoną do konfiguracji, która działa bez szyfrowania, a włączenie szyfrowania na serwerach z pamięcią podręczną Cloudflare nie wpłynęło na szybkość odpowiedzi.
W przyszłości, Cloudflare planuje przenieść przygotowane poprawki do głównego jądra Linuksa, ale wcześniej będą musiały zostać zmodyfikowane, ponieważ są zoptymalizowane dla określonego obciążenia i nie obejmują wszystkich obszarów zastosowań.
źródło: https://blog.cloudflare.com