Mau desempenho com o software Linux RAID5 e a criptografia LUKS

Question

Eu configurei um software Linux RAID5 em três discos rígidos e quero criptografá-lo com cryptsetup / LUKS. Meus testes mostraram que a criptografia leva a uma queda massiva de desempenho que não consigo explicar.

O RAID5 é capaz de escrever 187 MB / s [1] sem criptografia. Com a criptografia em cima, a velocidade de gravação diminui para cerca de 40 MB / s.

O RAID tem um tamanho de bloco de 512K e um bitmap de intenção de gravação. Eu usei -c aes-xts-plain -s 512 --align-payload=2048 como os parâmetros para cryptsetup luksFormat , então a carga útil deve ser alinhada a 2048 blocos de 512 bytes (ou seja, 1MB). cryptsetup luksDump mostra um deslocamento de carga útil de 4096. Então, acho que o alinhamento está correto e se encaixa no tamanho do bloco de RAID.

A CPU não é o gargalo, pois tem suporte de hardware para AES (aesni_intel). Se eu escrever em outra unidade (um SSD com LVM) que também é criptografado, eu tenho uma velocidade de gravação de 150 MB / s. top mostra que o uso da CPU é de fato muito baixo, somente o RAID5 xor leva 14%.

Eu também tentei colocar um sistema de arquivos (ext4) diretamente no RAID não criptografado, para ver se a camada é um problema. O sistema de arquivos diminui o desempenho um pouco como esperado, mas de longe não muito (a velocidade de gravação varia, mas > 100 MB / s).

Resumo:
Discos + RAID5: boa notícia Discos + RAID5 + ext4: boa notícia Discos + criptografia RAID5 +: bad SSD + criptografia + LVM + ext4: bom

O desempenho de leitura não é afetado pela criptografia, é de 207 MB / s sem e de 205 MB / s com criptografia (mostrando também que a energia da CPU não é o problema).

O que posso fazer para melhorar o desempenho de gravação do RAID criptografado?

[1] Todas as medições de velocidade foram feitas com várias execuções de dd if=/dev/zero of=DEV bs=100M count=100 (ou seja, escrevendo 10G em blocos de 100M).

Editar: Se isso ajudar: Estou usando o Ubuntu 11.04 64bit com o Linux 2.6.38.

Edit2: O desempenho permanece aproximadamente o mesmo se eu passar um tamanho de bloco de 4KB, 1MB ou 10MB para dd .

    

Answer 1

A solução é definir o recurso stripe_cache_size para md raids.

Por padrão, é definido como 256, mas pode ser aumentado para 32768.

Isso é feito escrevendo o tamanho desejado em /sys/block/md0/md/stripe_cache_size (se o raid for md0 ). No Ask Ubuntu há uma solução para definir o valor permanentemente .

Testei exatamente o mesmo RAID da pergunta e obtive os seguintes números:

size   256: 50 MB/s
size  4096: 123 MB/s
size  8192: 142 MB/s
size 16384: 140 MB/s
size 32768: 142 MB/s

Estes testes foram conduzidos com o Ubuntu 12.04 (Linux 3.2) escrevendo 10 GB em um arquivo com blocos de 1 MB.

Background: O cache de stripe armazena blocos gravados recentemente. Se os dados forem gravados continuamente, pode acontecer que, durante uma primeira gravação, apenas uma parte de uma faixa seja gravada. Isso significa que o código RAID deve ler a faixa completa do disco, atualizá-lo e gravá-lo completamente de novo. Se uma segunda gravação chegar em outra parte da mesma faixa, tudo isso teria que ser feito novamente. Agora, se o cache for usado e ainda contiver os dados gravados pela primeira gravação, a leitura necessária antes da segunda gravação poderá ser omitida.

Normalmente, um tamanho de bloco grande ao escrever evitaria o problema (porque as faixas completas são escritas de uma só vez e, portanto, nenhuma leitura é necessária). No entanto, parece que a criptografia usa apenas pequenos blocos ao gravar no dispositivo subjacente e, assim, aumentar o cache tem um efeito positivo.

    

Answer 2

O LUKS tem um botleneck, isto é, ele gera apenas um thread por dispositivo de bloco.

Você está colocando a criptografia na parte superior do RAID 5? Então, do ponto de vista do seu SO, você só tem um dispositivo, então ele está usando apenas um thread para todos esses discos, o que significa que os discos estão funcionando de maneira serial, em vez de paralela.

Você está colocando o LVM sobre os dispositivos criptografados? Então você está gerando um thread por dispositivo, permitindo que eles trabalhem em paralelo.

Uma solução para isso? Se você estiver usando o Linux, independentemente da velocidade da CPU, da energia ou do número do núcleo, use a invasão de software e crie os volumes sobre os discos criptografados. Dessa forma, seu sistema operacional verá vários dispositivos e gerará um thread para cada um deles.

A desvantagem é ter que digitar a chave de acesso muitas vezes, mas para evitar que você possa ir para essa configuração. Um disco ou parte de um disco tem as partições de inicialização e raiz, a inicialização não é criptografada, a raiz é criptografada e contém um arquivo-chave, esse arquivo-chave é usado para descriptografar os outros dispositivos (talvez o restante do mesmo disco).

Eu encontrei este problema não usando RAID, mas lidando com uma máquina virtual que estava desacelerando o sistema operacional host, até que eu percebi que o OS estava monopolizando o thread luks eu decidi criar partições diferentes no mesmo dispositivo e usar uma partição para os discos virtuais, eles não podem monopolizar o encadeamento e o desempenho de ambos os sistemas operacionais melhorou muito.

Eu acho que você também pode se beneficiar do uso de software RAID, você não terminaria dependente do seu hardware.