Desarrolladores de Cloudflare sobre la realización de trabajos para optimizar el rendimiento del cifrado de disco en el kernel de Linux. Como resultado, estaban preparados. para subsistema y Crypto API, que hizo posible duplicar con creces el rendimiento de lectura y escritura en la prueba sintética, así como reducir a la mitad la latencia. Cuando se probó en hardware real, la sobrecarga de cifrado se redujo casi al nivel observado cuando se trabaja con un disco sin cifrado de datos.
Cloudflare utiliza dm-crypt para cifrar datos en dispositivos de almacenamiento utilizados para almacenar en caché el contenido en la CDN. Dm-crypt opera a nivel de dispositivo de bloque y cifra solicitudes de E/S de escritura y descifra solicitudes de lectura, actuando como una capa entre el dispositivo de bloque y el controlador del sistema de archivos.
Para evaluar el rendimiento de dm-crypt usando el paquete Medimos la velocidad de trabajar con particiones cifradas y no cifradas en un disco RAM ubicado en la RAM para eliminar las fluctuaciones en el rendimiento del disco y centrarnos en el rendimiento del código. Para particiones no cifradas, el rendimiento de lectura y escritura se mantuvo en 1126 MB/s, pero la velocidad disminuyó cuando se habilitó el cifrado. 7 en el tiempo y ascendió a 147 MB/s.
Al principio surgieron sospechas sobre el uso de algoritmos ineficientes en el criptosistema del núcleo. Pero las pruebas utilizaron el algoritmo más rápido, aes-xts, con 256 claves de cifrado, cuyo rendimiento al ejecutar el "punto de referencia cryptsetup" es más del doble que el resultado obtenido al probar un disco RAM. Los experimentos con indicadores dm-crypt para ajustar el rendimiento no dieron resultados: cuando se usó el indicador “--perf-same_cpu_crypt”, el rendimiento incluso disminuyó a 136 MB/s, y al especificar el indicador “--perf-submit_from_crypt_cpus” solo aumentó a 166 MB/s.
Un análisis más profundo de la lógica operativa mostró que dm-crypt no es tan simple como parece: cuando llega una solicitud de escritura del controlador FS, dm-crypt no la procesa inmediatamente, sino que la coloca en la cola "kcryptd", que No se analiza inmediatamente, sino en el momento conveniente. Desde la cola, la solicitud se envía a Linux Crypto API para realizar el cifrado. Pero dado que Crypto API utiliza un modelo de ejecución asincrónico, el cifrado tampoco se realiza de inmediato, sino que pasa por alto otra cola. Una vez completado el cifrado, dm-crypt puede intentar ordenar las solicitudes de escritura pendientes utilizando un árbol de búsqueda. . Al final, un subproceso del kernel separado nuevamente, con un cierto retraso, recoge las solicitudes de E/S acumuladas y las envía a la pila de dispositivos de bloque.
Al leer, dm-crypt primero agrega una solicitud a la cola "kcryptd_io" para recibir datos de la unidad. Después de un tiempo, los datos están disponibles y se colocan en la cola "kcryptd" para su descifrado.
Kcryptd envía una solicitud a Linux Crypto API, que descifra la información de forma asincrónica. Las solicitudes no siempre pasan por todas las colas, pero en el peor de los casos, una solicitud de escritura termina en colas hasta 4 veces y una solicitud de lectura hasta 3 veces. Cada acceso a la cola provoca retrasos, que son la razón clave de la disminución significativa en el rendimiento de dm-crypt.
El uso de colas se debe a la necesidad de trabajar en condiciones donde se producen interrupciones. En 2005, cuando se implementó el modelo operativo actual basado en colas de dm-crypt, la API Crypto aún no era asincrónica. Después de que la API Crypto se transfirió a un modelo de ejecución asincrónica, se comenzó a utilizar esencialmente una doble protección. También se introdujeron colas para ahorrar consumo de la pila del kernel, pero después de su aumento en 2014, estas optimizaciones perdieron su relevancia. Se introdujo una cola adicional "kcryptd_io" para superar el cuello de botella que provoca la espera de la asignación de memoria cuando llega una gran cantidad de solicitudes. En 2015, se introdujo una fase de clasificación adicional, ya que las solicitudes de cifrado en sistemas multiprocesador podían completarse desordenadamente (en lugar de un acceso secuencial al disco, el acceso se realizaba en orden aleatorio y el programador CFQ no funcionaba de manera eficiente). Actualmente, cuando se utilizan unidades SSD, la clasificación ha perdido su significado y el programador CFQ ya no se utiliza en el kernel.
Teniendo en cuenta que los discos modernos se han vuelto más rápidos e inteligentes, se revisó el sistema de distribución de recursos en el kernel de Linux y se rediseñaron algunos subsistemas, afirman los ingenieros de Cloudflare dm-crypt tiene un nuevo modo operativo que elimina el uso de colas innecesarias y llamadas asincrónicas. El modo se habilita mediante una bandera separada “force_inline” y trae dm-crypt a la forma de un proxy simple que cifra y descifra las solicitudes entrantes. La interacción con Crypto API se ha optimizado eligiendo explícitamente algoritmos de cifrado que funcionan en modo síncrono y no utilizan colas de solicitudes. Para trabajar sincrónicamente con la Crypto API había un módulo que le permite utilizar FPU/AES-NI para aceleración y reenvía directamente solicitudes de cifrado y descifrado.
Como resultado, al probar un disco RAM, fue posible duplicar con creces el rendimiento de dm-crypt: el rendimiento aumentó de 294 MB/s (2 x 147 MB/s) a 640 MB/s, lo que está muy cerca de el rendimiento del cifrado simple (696 MB/s).
Al probar la carga en servidores reales, la nueva implementación mostró un rendimiento muy cercano a la configuración ejecutándose sin cifrado, y habilitar el cifrado en servidores con caché de Cloudflare no tuvo ningún efecto en la velocidad de respuesta. En el futuro, Cloudflare planea transferir los parches preparados al kernel principal de Linux, pero antes será necesario reelaborarlos, ya que están optimizados para una carga específica y no cubren todas las áreas de aplicación, por ejemplo, cifrado en baja -Dispositivos integrados de alimentación.
Fuente: opennet.ru