Deweloperzy z firmy Cloudflare przeprowadzili prace nad optymalizacją wydajności szyfrowania dysków w jądrze Linux. W wyniku przygotowano dla podsystemu i Crypto API, co pozwoliło w teście syntetycznym zwiększyć przepustowość przy odczycie i zapisie ponad dwukrotnie oraz dwukrotnie zmniejszyć opóźnienia. Testując na rzeczywistym sprzęcie, udało się zredukować narzuty związane z szyfrowaniem praktycznie do poziomu obserwowanego przy pracy z dyskiem bez zastosowania szyfrowania danych.
Cloudflare używa dm-crypt do szyfrowania danych na nośnikach wykorzystywanych do buforowania treści w sieci CDN. Dm-crypt działa na poziomie urządzenia blokowego i przeprowadza szyfrowanie żądań wejścia/wyjścia przy zapisie oraz deszyfrowanie żądań przy odczycie, pełniąc rolę warstwy pomiędzy urządzeniem blokowym a sterownikiem systemu plików.
Aby ocenić wydajność dm-crypt, użyto pakietu przeprowadzono pomiar prędkości pracy z szyfrowanymi i nieszyfrowanymi partycjami na dysku RAM, umieszczonym w pamięci RAM w celu wyeliminowania wahań wydajności dysków i skoncentrować się na wydajności kodu. W przypadku nieszyfrowanych partycji wydajność odczytu i zapisu utrzymywała się na poziomie 1126 MB/s, ale po włączeniu szyfrowania prędkość spadła w 7 razy i wyniosła 147 MB/s.
Początkowo pojawiły się podejrzenia co do użycia nieefektywnych algorytmów w systemie kryptograficznym jądra. Jednak w testach zastosowano najszybszy algorytm aes-xts z 256-bitowym kluczem szyfrowania, którego wydajność przy uruchomionym „cryptsetup benchmark” była ponad dwa razy wyższa niż uzyskany wynik w teście dysku RAM. Eksperymenty z flagami dm-crypt w celu tuningu wydajności nie przyniosły rezultatów: przy użyciu flagi „—perf-same_cpu_crypt” wydajność nawet zmniejszyła się do 136 MB/s, a przy wskazaniu flagi „—perf-submit_from_crypt_cpus” wzrosła jedynie do 166 MB/s.
Głębsza analiza logiki działania pokazała, że dm-crypt nie jest tak prosty, jak się wydaje — gdy sterownik FS wysyła żądanie zapisu, dm-crypt nie przetwarza go od razu, lecz umieszcza w kolejce „kcryptd”, która jest przetwarzana nie od razu, a w dogodnym momencie. Z kolejki żądanie jest przesyłane do Linux Crypto API w celu wykonania szyfrowania. Jednak ponieważ Crypto API korzysta z asynchronicznego modelu wykonania, szyfrowanie również jest realizowane nie od razu, przechodząc przez jeszcze jedną kolejkę. Po zakończeniu szyfrowania dm-crypt może próbować wykonać sortowanie oczekujących żądań zapisu, używając drzewa wyszukiwania. . Na końcu oddzielny wątek jądra ponownie po pewnym opóźnieniu przejmuje zgromadzone żądania wejścia/wyjścia i przesyła je do stosu urządzenia blokowego.
Podczas odczytu dm-crypt najpierw dodaje do kolejki „kcryptd_io” żądanie pobrania danych z nośnika. Po pewnym czasie dane stają się dostępne i są umieszczane w kolejce „kcryptd” w celu deszyfrowania.
Kcryptd wysyła żądanie do Linux Crypto API, które deszyfruje informacje w trybie asynchronicznym. Żądania nie zawsze przechodzą przez wszystkie kolejki, jednak w najgorszym scenariuszu żądanie zapisu utknie w kolejkach do 4 razy, a żądanie odczytu do 3 razy. Każde trafienie do kolejki prowadzi do wystąpienia opóźnień, które są kluczową przyczyną znacznego spadku wydajności dm-crypt.
Zastosowanie kolejek wynika z konieczności pracy w warunkach występowania przerwań. W 2005 roku, gdy zrealizowano obecną model pracy dm-crypt oparty na kolejkach, Crypto API nie był jeszcze asynchroniczny. Po wprowadzeniu Crypto API do modelu asynchronicznego zaczęto stosować w zasadzie podwójne zabezpieczenie. Kolejki wprowadzono również w celu oszczędności zasilania stosu jądra, jednak po jego zwiększeniu w 2014 roku dane optymalizacje straciły na znaczeniu. Dodatkowa kolejka „kcryptd_io” została wprowadzona, aby przezwyciężyć wąskie gardło, prowadzące do oczekiwania na przydział pamięci przy dużej liczbie żądań. W 2015 roku dodatkowo wprowadzono fazę sortowania, ponieważ żądania szyfrowania na systemach wieloprocesorowych mogły kończyć się bez zachowania kolejności wysyłania (zamiast sekwencyjnego dostępu do dysku, używano dostępu losowego, planista CFQ nie działał efektywnie). Obecnie, przy użyciu dysków SSD, sortowanie straciło sens, a planista CFQ nie jest już stosowany w jądrze.
Biorąc pod uwagę, że nowoczesne nośniki stały się szybsze i mądrzejsze, system przydzielania zasobów w jądrze Linux został przemyślany, a niektóre podsystemy przebudowane przez inżynierów Cloudflare. W dm-crypt nowy tryb pracy, pozbawiony użycia zbędnych kolejek i asynchronicznych wywołań. Tryb włącza się osobnym flagiem „force_inline” i przekształca dm-crypt w prosty proxy, szyfrujący i deszyfrujący nadchodzące żądania. Interakcja z Crypto API została zoptymalizowana poprzez wyraźny wybór algorytmów szyfrowania, działających w trybie synchronicznym i nie używających kolejek żądań. Dla synchronicznej pracy z Crypto API był moduł, który pozwala na wykorzystanie FPU/AES-NI do przyspieszenia i bezpośredniego przekazywania żądań szyfrowania i deszyfrowania.
W efekcie podczas testów z pamięcią RAM udało się więcej niż dwukrotnie zwiększyć wydajność dm-crypt — wydajność wzrosła z 294 MB/s (2 x 147 MB/s) do 640 MB/s, co jest bardzo bliskie wydajności gołego szyfrowania (696 MB/s).
Podczas testów obciążeniowych na rzeczywistych serwerach nowa implementacja wykazała wydajność bardzo zbliżoną do konfiguracji działającej bez szyfrowania, a włączenie szyfrowania na serwerach z pamięcią podręczną Cloudflare w żaden sposób nie wpłynęło na czas odpowiedzi. W przyszłości Cloudflare planuje przekazać przygotowane poprawki do głównego jądra Linuksa, ale przed tym trzeba je przerobić, ponieważ są zoptymalizowane dla określonego obciążenia i nie obejmują wszystkich obszarów zastosowań, na przykład szyfrowania w mało wydajnych urządzeniach wbudowanych.
Źródło: opennet.ru
