Desenvolvedores da Cloudflare sobre a realização de trabalhos para otimizar o desempenho da criptografia de disco no kernel Linux. Como resultado, eles estavam preparados para subsistema e Crypto API, que possibilitou mais que dobrar o rendimento de leitura e gravação no teste sintético, bem como reduzir pela metade a latência. Quando testado em hardware real, a sobrecarga de criptografia foi reduzida quase ao nível observado ao trabalhar com um disco sem criptografia de dados.
A Cloudflare usa dm-crypt para criptografar dados em dispositivos de armazenamento usados para armazenar conteúdo em cache no CDN. Dm-crypt opera no nível do dispositivo de bloco e criptografa solicitações de E/S de gravação e descriptografa solicitações de leitura, agindo como uma camada entre o dispositivo de bloco e o driver do sistema de arquivos.
Para avaliar o desempenho do dm-crypt usando o pacote Medimos a velocidade de trabalho com partições criptografadas e não criptografadas em um disco RAM localizado na RAM para eliminar flutuações no desempenho do disco e focar no desempenho do código. Para partições não criptografadas, o desempenho de leitura e gravação permaneceu em 1126 MB/s, mas a velocidade diminuiu quando a criptografia foi habilitada 7 em vez e totalizou 147 MB/s.
A princípio, surgiram suspeitas sobre o uso de algoritmos ineficientes no criptossistema do kernel. Mas os testes utilizaram o algoritmo mais rápido, o aes-xts, com 256 chaves de criptografia, cujo desempenho ao executar o “benchmark cryptsetup” é mais que o dobro do resultado obtido ao testar um disco RAM. Experimentos com sinalizadores dm-crypt para ajuste de desempenho não produziram resultados: ao usar o sinalizador “--perf-same_cpu_crypt”, o desempenho até diminuiu para 136 MB/s, e ao especificar o sinalizador “--perf-submit_from_crypt_cpus” aumentou apenas a 166 MB/s.
Uma análise mais profunda da lógica operacional mostrou que o dm-crypt não é tão simples quanto parece - quando uma solicitação de gravação chega do driver FS, o dm-crypt não a processa imediatamente, mas a coloca na fila “kcryptd”, que não é analisado imediatamente, mas no momento conveniente. Da fila, a solicitação é enviada para a API Linux Crypto para realizar a criptografia. Mas como a Crypto API usa um modelo de execução assíncrona, a criptografia também não é realizada imediatamente, mas sim contornando outra fila. Após a conclusão da criptografia, o dm-crypt pode tentar classificar as solicitações de gravação pendentes usando uma árvore de pesquisa . No final, um thread de kernel separado novamente, com um certo atraso, coleta as solicitações de E/S acumuladas e as envia para a pilha de dispositivos de bloco.
Ao ler, o dm-crypt primeiro adiciona uma solicitação à fila “kcryptd_io” para receber dados da unidade. Depois de algum tempo, os dados ficam disponíveis e são colocados na fila “kcryptd” para descriptografia.
Kcryptd envia uma solicitação para a API Linux Crypto, que descriptografa as informações de forma assíncrona. As solicitações nem sempre passam por todas as filas, mas na pior das hipóteses, uma solicitação de gravação acaba em filas até 4 vezes e uma solicitação de leitura até 3 vezes. Cada acerto na fila causa atrasos, que são a principal razão para a diminuição significativa no desempenho do dm-crypt.
A utilização de filas se deve à necessidade de trabalhar em condições onde ocorrem interrupções. Em 2005, quando o atual modelo operacional baseado em fila do dm-crypt foi implementado, a API Crypto ainda não era assíncrona. Depois que a Crypto API foi transferida para um modelo de execução assíncrona, essencialmente a proteção dupla passou a ser utilizada. As filas também foram introduzidas para economizar o consumo da pilha do kernel, mas após seu aumento em 2014, essas otimizações perderam relevância. Uma fila adicional "kcryptd_io" foi introduzida para superar o gargalo que resulta na espera pela alocação de memória quando chega um grande número de solicitações. Em 2015, foi introduzida uma fase adicional de classificação, uma vez que as solicitações de criptografia em sistemas multiprocessadores podiam ser concluídas fora de ordem (em vez do acesso sequencial ao disco, o acesso era realizado em ordem aleatória e o agendador CFQ não funcionava de forma eficiente). Atualmente, ao usar unidades SSD, a classificação perdeu o significado e o agendador CFQ não é mais usado no kernel.
Considerando que as unidades modernas se tornaram mais rápidas e inteligentes, o sistema de distribuição de recursos no kernel Linux foi revisado e alguns subsistemas foram redesenhados, os engenheiros da Cloudflare dm-crypt possui um novo modo operacional que elimina o uso de filas desnecessárias e chamadas assíncronas. O modo é habilitado por um sinalizador separado “force_inline” e traz o dm-crypt para a forma de um proxy simples que criptografa e descriptografa as solicitações recebidas. A interação com a API Crypto foi otimizada pela escolha explícita de algoritmos de criptografia que operam em modo síncrono e não usam filas de solicitação. Para trabalhar de forma síncrona com a Crypto API houve um módulo que permite usar FPU/AES-NI para aceleração e encaminhar diretamente solicitações de criptografia e descriptografia.
Como resultado, ao testar um disco RAM, foi possível mais que dobrar o desempenho do dm-crypt - o desempenho aumentou de 294 MB/s (2 x 147 MB/s) para 640 MB/s, o que é muito próximo de o desempenho da criptografia simples (696 MB/s).
Ao testar a carga em servidores reais, a nova implementação apresentou desempenho muito próximo da configuração rodando sem criptografia, e habilitar a criptografia em servidores com cache Cloudflare não teve efeito na velocidade de resposta. No futuro, a Cloudflare planeja transferir os patches preparados para o kernel principal do Linux, mas antes eles precisarão ser retrabalhados, pois são otimizados para uma carga específica e não cobrem todas as áreas de aplicação, por exemplo, criptografia em baixo -dispositivos embarcados de energia.
Fonte: opennet.ru