Desenvolvedores de Cloudflare sobre a realización de traballos para optimizar o rendemento do cifrado do disco no núcleo de Linux. Como resultado, foron preparados para o subsistema e Crypto API, que permitiu duplicar o rendemento de lectura e escritura na proba sintética, así como reducir á metade a latencia. Cando se probou en hardware real, a sobrecarga de cifrado reduciuse a case o nivel observado cando se traballa cun disco sen cifrado de datos.
Cloudflare usa dm-crypt para cifrar datos en dispositivos de almacenamento utilizados para almacenar na caché o contido da CDN. Dm-crypt opera a nivel de dispositivo de bloque e cifra as solicitudes de E/S de escritura e descifra as solicitudes de lectura, actuando como unha capa entre o dispositivo de bloque e o controlador do sistema de ficheiros.
Para avaliar o rendemento de dm-crypt usando o paquete Medimos a velocidade de traballar con particións cifradas e sen cifrar nun disco RAM situado na RAM para eliminar as flutuacións no rendemento do disco e centrarnos no rendemento do código. Para particións sen cifrar, o rendemento de lectura e escritura mantívose en 1126 MB/s, pero a velocidade diminuíu cando se habilitou o cifrado 7 veces e ascendeu a 147 MB/s.
Nun primeiro momento, xurdiu a sospeita sobre o uso de algoritmos ineficientes no sistema criptográfico do núcleo. Pero as probas utilizaron o algoritmo máis rápido, aes-xts, con 256 claves de cifrado, cuxo rendemento ao executar o "punto de referencia cryptosetup" é máis do dobre que o resultado obtido ao probar un disco RAM. Os experimentos con marcas dm-crypt para axustar o rendemento non deron resultados: ao usar a marca "--perf-same_cpu_crypt", o rendemento incluso diminuíu a 136 MB/s, e ao especificar a marca "--perf-submit_from_crypt_cpus" só aumentou ata 166 MB/s.
Unha análise máis profunda da lóxica de funcionamento mostrou que dm-crypt non é tan sinxelo como parece: cando chega unha solicitude de escritura do controlador FS, dm-crypt non a procesa inmediatamente, senón que a coloca na cola "kcryptd", que non se analiza inmediatamente, pero cando é conveniente. Desde a cola, a solicitude envíase á API Linux Crypto para realizar o cifrado. Pero dado que a API Crypto usa un modelo de execución asíncrona, o cifrado tampouco se realiza inmediatamente, senón que se evita outra cola. Despois de completar o cifrado, dm-crypt pode tentar ordenar as solicitudes de escritura pendentes mediante unha árbore de busca . Ao final, un fío do núcleo separado de novo, con certo atraso, recolle as solicitudes de E/S acumuladas e envíaas á pila de dispositivos de bloque.
Ao ler, dm-crypt engade primeiro unha solicitude á cola "kcryptd_io" para recibir datos da unidade. Despois dun tempo, os datos están dispoñibles e colócanse na cola "kcryptd" para o descifrado.
Kcryptd envía unha solicitude á API Linux Crypto, que descifra a información de forma asíncrona. As solicitudes non sempre pasan por todas as colas, pero no peor dos casos, unha solicitude de escritura acaba en colas ata 4 veces e unha solicitude de lectura ata 3 veces. Cada acceso á cola provoca atrasos, que son o principal motivo da diminución significativa do rendemento de dm-crypt.
O uso das colas débese á necesidade de traballar en condicións nas que se producen interrupcións. En 2005, cando se implementou o actual modelo operativo baseado en filas de dm-crypt, a API Crypto aínda non era asíncrona. Despois de que a API Crypto fose transferida a un modelo de execución asíncrona, comezou a utilizarse esencialmente a dobre protección. Tamén se introduciron colas para aforrar consumo da pila do núcleo, pero tras o seu aumento en 2014, estas optimizacións perderon a súa relevancia. Introduciuse unha cola adicional "kcryptd_io" para superar o pescozo de botella que provoca a espera da asignación de memoria cando chega un gran número de solicitudes. En 2015, introduciuse unha fase de clasificación adicional, xa que as solicitudes de cifrado en sistemas multiprocesador podían completarse sen orde (en lugar de acceder secuencialmente ao disco, o acceso realizouse en orde aleatoria e o programador CFQ non funcionaba de forma eficiente). Actualmente, ao usar unidades SSD, a clasificación perdeu o seu significado e o programador CFQ xa non se usa no núcleo.
Tendo en conta que as unidades modernas volvéronse máis rápidas e intelixentes, o sistema de distribución de recursos no núcleo de Linux foi revisado e algúns subsistemas foron redeseñados, os enxeñeiros de Cloudflare dm-crypt ten un novo modo de funcionamento que elimina o uso de colas innecesarias e chamadas asíncronas. O modo está habilitado por unha marca separada "force_inline" e trae dm-crypt a forma dun simple proxy que cifra e descifra as solicitudes entrantes. Optimizouse a interacción coa API Crypto escollendo de forma explícita algoritmos de cifrado que funcionan en modo síncrono e non usan colas de solicitudes. Para traballar de forma sincronizada coa API Crypto houbo un módulo que permite usar FPU/AES-NI para acelerar e reenviar directamente solicitudes de cifrado e descifrado.
Como resultado, ao probar un disco RAM, foi posible duplicar o rendemento de dm-crypt: o rendemento aumentou de 294 MB/s (2 x 147 MB/s) a 640 MB/s, o que é moi próximo ao o rendemento do cifrado simple (696 MB/s).
Ao probar a carga en servidores reais, a nova implementación mostrou un rendemento moi próximo á configuración que se executa sen cifrado, e habilitar o cifrado en servidores con caché de Cloudflare non tivo ningún efecto na velocidade de resposta. No futuro, Cloudflare planea transferir os parches preparados ao núcleo principal de Linux, pero antes terán que ser reelaborados, xa que están optimizados para unha carga específica e non abarcan todas as áreas de aplicación, por exemplo, o cifrado en baixos. -Dispositivos integrados de alimentación.
Fonte: opennet.ru