Développeurs de Cloudflare sur la réalisation de travaux visant à optimiser les performances du chiffrement de disque dans le noyau Linux. En conséquence, ils étaient préparés pour sous-système et Crypto API, qui a permis de plus que doubler le débit de lecture et d'écriture dans le test synthétique, ainsi que de réduire de moitié la latence. Lors des tests sur du matériel réel, la surcharge de chiffrement a été réduite presque au niveau observé lors de l'utilisation d'un disque sans chiffrement de données.
Cloudflare utilise dm-crypt pour chiffrer les données sur les périphériques de stockage utilisés pour mettre en cache le contenu sur le CDN. Dm-crypt fonctionne au niveau du périphérique bloc et crypte les demandes d'E/S d'écriture et déchiffre les demandes de lecture, agissant comme une couche entre le périphérique bloc et le pilote du système de fichiers.
Pour évaluer les performances de dm-crypt à l'aide du package Nous avons mesuré la vitesse de travail avec des partitions cryptées et non cryptées sur un disque RAM situé dans la RAM pour éliminer les fluctuations des performances du disque et nous concentrer sur les performances du code. Pour les partitions non chiffrées, les performances de lecture et d'écriture sont restées à 1126 XNUMX Mo/s, mais la vitesse a diminué lorsque le chiffrement a été activé. 7 dans le temps et s'élevait à 147 Mo/s.
Au début, des soupçons ont émergé quant à l’utilisation d’algorithmes inefficaces dans le système cryptographique du noyau. Mais les tests ont utilisé l'algorithme le plus rapide, aes-xts, avec 256 clés de cryptage, dont les performances lors de l'exécution du « benchmark cryptsetup » sont plus de deux fois supérieures au résultat obtenu lors du test d'un disque RAM. Les expériences avec les indicateurs dm-crypt pour le réglage des performances n'ont pas donné de résultats : lors de l'utilisation de l'indicateur « --perf-same_cpu_crypt », les performances ont même diminué jusqu'à 136 Mo/s, et lors de la spécification de l'indicateur « --perf-submit_from_crypt_cpus », elles n'ont augmenté que à 166 Mo/s.
Une analyse plus approfondie de la logique de fonctionnement a montré que dm-crypt n'est pas aussi simple qu'il y paraît - lorsqu'une demande d'écriture arrive du pilote FS, dm-crypt ne la traite pas immédiatement, mais la place dans la file d'attente « kcryptd », qui n'est pas analysé immédiatement, mais au moment opportun. Depuis la file d'attente, la requête est envoyée à l'API Linux Crypto pour effectuer le chiffrement. Mais comme l'API Crypto utilise un modèle d'exécution asynchrone, le chiffrement n'est pas non plus effectué immédiatement, mais en contournant une autre file d'attente. Une fois le chiffrement terminé, dm-crypt peut tenter de trier les demandes d'écriture en attente à l'aide d'un arbre de recherche. . À la fin, un thread de noyau distinct récupère à nouveau, avec un certain délai, les requêtes d'E/S accumulées et les envoie à la pile de périphériques bloc.
Lors de la lecture, dm-crypt ajoute d'abord une requête à la file d'attente « kcryptd_io » pour recevoir les données du lecteur. Après un certain temps, les données deviennent disponibles et sont placées dans la file d'attente « kcryptd » pour être décryptées.
Kcryptd envoie une requête à l'API Linux Crypto, qui déchiffre les informations de manière asynchrone. Les requêtes ne parcourent pas toujours toutes les files d'attente, mais dans le pire des cas, une requête d'écriture se retrouve dans les files d'attente jusqu'à 4 fois, et une requête de lecture jusqu'à 3 fois. Chaque accès à la file d'attente entraîne des retards, qui sont la principale raison de la diminution significative des performances de dm-crypt.
L'utilisation de files d'attente est due à la nécessité de travailler dans des conditions d'interruption. En 2005, lorsque le modèle opérationnel actuel basé sur des files d'attente de dm-crypt a été implémenté, l'API Crypto n'était pas encore asynchrone. Après le transfert de l'API Crypto vers un modèle d'exécution asynchrone, une double protection a commencé à être utilisée. Des files d'attente ont également été introduites pour économiser la consommation de la pile du noyau, mais après son augmentation en 2014, ces optimisations ont perdu de leur pertinence. Une file d'attente supplémentaire "kcryptd_io" a été introduite pour surmonter le goulot d'étranglement résultant de l'attente de l'allocation de mémoire lorsqu'un grand nombre de requêtes arrivent. En 2015, une phase de tri supplémentaire a été introduite, puisque les demandes de chiffrement sur les systèmes multiprocesseurs pouvaient être exécutées dans le désordre (au lieu d'un accès séquentiel au disque, l'accès était effectué dans un ordre aléatoire et le planificateur CFQ ne fonctionnait pas efficacement). Actuellement, lors de l'utilisation de disques SSD, le tri a perdu son sens et le planificateur CFQ n'est plus utilisé dans le noyau.
Considérant que les disques modernes sont devenus plus rapides et plus intelligents, le système de distribution des ressources du noyau Linux a été révisé et certains sous-systèmes ont été repensés, ont déclaré les ingénieurs de Cloudflare. dm-crypt dispose d'un nouveau mode de fonctionnement qui élimine l'utilisation de files d'attente inutiles et d'appels asynchrones. Le mode est activé par un indicateur séparé « force_inline » et amène dm-crypt sous la forme d'un simple proxy qui crypte et déchiffre les requêtes entrantes. L'interaction avec l'API Crypto a été optimisée en choisissant explicitement des algorithmes de chiffrement qui fonctionnent en mode synchrone et n'utilisent pas de files d'attente de requêtes. Pour travailler de manière synchrone avec l'API Crypto, il y avait un module qui vous permet d'utiliser FPU/AES-NI pour l'accélération et de transmettre directement les demandes de cryptage et de décryptage.
En conséquence, lors du test d'un disque RAM, il a été possible de plus que doubler les performances de dm-crypt - les performances sont passées de 294 Mo/s (2 x 147 Mo/s) à 640 Mo/s, ce qui est très proche de les performances du cryptage nu (696 Mo/s).
Lors des tests de charge sur des serveurs réels, la nouvelle implémentation a montré des performances très proches de la configuration exécutée sans chiffrement, et l'activation du chiffrement sur les serveurs avec cache Cloudflare n'a eu aucun effet sur la vitesse de réponse. À l'avenir, Cloudflare prévoit de transférer les correctifs préparés vers le noyau Linux principal, mais avant cela, ils devront être retravaillés, car ils sont optimisés pour une charge spécifique et ne couvrent pas tous les domaines d'application, par exemple le cryptage à faible niveau. -alimenter les appareils embarqués.
Source: opennet.ru