Desenvolupadors de Cloudflare sobre la realització de treballs per optimitzar el rendiment del xifratge de disc al nucli Linux. Com a resultat, es van preparar per al subsistema i Crypto API, que va permetre més que duplicar el rendiment de lectura i escriptura a la prova sintètica, així com reduir a la meitat la latència. Quan es va provar amb maquinari real, la sobrecàrrega de xifratge es va reduir gairebé al nivell observat quan es treballava amb un disc sense xifratge de dades.
Cloudflare utilitza dm-crypt per xifrar dades en dispositius d'emmagatzematge que s'utilitzen per emmagatzemar contingut a la memòria cau a la CDN. Dm-crypt funciona a nivell de dispositiu de bloc i xifra les sol·licituds d'E/S d'escriptura i desxifra les sol·licituds de lectura, actuant com a capa entre el dispositiu de bloc i el controlador del sistema de fitxers.
Per avaluar el rendiment de dm-crypt mitjançant el paquet Hem mesurat la velocitat de treball amb particions xifrades i no xifrades en un disc RAM situat a RAM per eliminar les fluctuacions en el rendiment del disc i centrar-nos en el rendiment del codi. Per a les particions no xifrades, el rendiment de lectura i escriptura es va mantenir en 1126 MB/s, però la velocitat va disminuir quan es va activar el xifratge. 7 vegades i va ascendir a 147 MB/s.
Al principi, va sorgir la sospita sobre l'ús d'algoritmes ineficients al sistema criptogràfic del nucli. Però les proves van utilitzar l'algorisme més ràpid, aes-xts, amb 256 claus de xifratge, el rendiment de les quals quan s'executa el "punt de referència de criptografia" és més del doble que el resultat obtingut en provar un disc RAM. Els experiments amb senyaladors dm-crypt per a l'ajust del rendiment no van donar resultats: quan s'utilitzava el senyalador "--perf-same_cpu_crypt", el rendiment fins i tot va disminuir a 136 MB/s, i quan s'especificava el senyalador "--perf-submit_from_crypt_cpus" només augmentava fins a 166 MB/s.
Una anàlisi més profunda de la lògica operativa va demostrar que dm-crypt no és tan senzill com sembla: quan arriba una sol·licitud d'escriptura del controlador FS, dm-crypt no la processa immediatament, sinó que la col·loca a la cua "kcryptd", que no s'analitza immediatament, sinó quan és convenient. Des de la cua, la sol·licitud s'envia a l'API Linux Crypto per realitzar el xifratge. Però com que l'API Crypto utilitza un model d'execució asíncron, el xifratge tampoc es realitza immediatament, sinó que passa per alt una altra cua. Un cop finalitzat el xifratge, dm-crypt pot intentar ordenar les sol·licituds d'escriptura pendents mitjançant un arbre de cerca . Al final, un altre fil del nucli separat, amb un cert retard, recull les sol·licituds d'E/S acumulades i les envia a la pila de dispositius de bloc.
En llegir, dm-crypt primer afegeix una sol·licitud a la cua "kcryptd_io" per rebre dades de la unitat. Després d'un temps, les dades estan disponibles i es col·loquen a la cua "kcryptd" per desxifrar-les.
Kcryptd envia una sol·licitud a l'API Linux Crypto, que desxifra la informació de manera asíncrona. Les sol·licituds no sempre passen per totes les cues, però en el pitjor dels casos, una sol·licitud d'escriptura acaba a les cues fins a 4 vegades i una sol·licitud de lectura fins a 3 vegades. Cada cop a la cua provoca retards, que són la raó clau de la disminució significativa del rendiment dm-crypt.
L'ús de cues es deu a la necessitat de treballar en condicions on es produeixen interrupcions. El 2005, quan es va implementar el model operatiu actual basat en cues de dm-crypt, l'API Crypto encara no era asíncrona. Després de transferir l'API Crypto a un model d'execució asíncron, es va començar a utilitzar essencialment una doble protecció. També es van introduir cues per estalviar el consum de la pila del nucli, però després del seu augment el 2014, aquestes optimitzacions van perdre la seva rellevància. Es va introduir una cua addicional "kcryptd_io" per superar el coll d'ampolla que provocava l'espera de l'assignació de memòria quan arriba un gran nombre de peticions. L'any 2015 es va introduir una fase d'ordenació addicional, ja que les sol·licituds de xifratge en sistemes multiprocessador es podien completar fora d'ordre (en comptes d'accés seqüencial al disc, l'accés es va fer en un ordre aleatori i el programador CFQ no funcionava de manera eficient). Actualment, quan s'utilitzen unitats SSD, l'ordenació ha perdut el seu significat i el programador CFQ ja no s'utilitza al nucli.
Tenint en compte que les unitats modernes s'han tornat més ràpides i intel·ligents, s'ha revisat el sistema de distribució de recursos al nucli de Linux i s'han redissenyat alguns subsistemes, els enginyers de Cloudflare dm-crypt té un nou mode de funcionament que elimina l'ús de cues innecessàries i trucades asíncrones. El mode s'habilita mitjançant una marca independent "force_inline" i porta dm-crypt a la forma d'un proxy simple que xifra i desxifra les sol·licituds entrants. La interacció amb l'API Crypto s'ha optimitzat escollint de manera explícita algorismes de xifratge que operen en mode síncron i no utilitzen cues de sol·licitud. Per treballar de forma sincrònica amb l'API Crypto hi havia un mòdul que permet utilitzar FPU/AES-NI per accelerar i reenviar directament les sol·licituds de xifratge i desxifrat.
Com a resultat, en provar un disc RAM, va ser possible més del doble del rendiment de dm-crypt: el rendiment va augmentar de 294 MB/s (2 x 147 MB/s) a 640 MB/s, que és molt proper a el rendiment del xifratge nu (696 MB/s).
Quan es va provar la càrrega en servidors reals, la nova implementació va mostrar un rendiment molt proper a la configuració que s'executava sense xifratge, i habilitar el xifratge en servidors amb memòria cau de Cloudflare no va tenir cap efecte en la velocitat de resposta. En el futur, Cloudflare té previst transferir els pedaços preparats al nucli principal de Linux, però abans caldrà reelaborar-los, ja que estan optimitzats per a una càrrega específica i no cobreixen totes les àrees d'aplicació, per exemple, el xifratge en baixa. -Dispositius integrats d'alimentació.
Font: opennet.ru