E / S de disco lento no KVM com LVM e md raid5

Question

Eu tenho lutado com uma configuração do kvm no debian por duas semanas, especificamente com o desempenho de disco de E / S de convidados.

O sistema:

-Supermicro 1018d-73mtf (X10SL7-F motherboard)
-16GB ECC/UB
-Intel Xeon E3-1240v3
-6xWD Red 750GB 6Gb/s

Neste eu estou executando um Debian Wheezy em dois discos, os outros quatro discos são configurados com md para o raid5 com o LVM no topo para o armazenamento convidado. O desempenho diretamente no raid5 (medido criando um LV e montando-o e executando bonnie ++ e dd tests) é bom, me dando ~ 220 / 170MB / s de leitura / gravação, mas em convidados recebo leituras decentes e gravações de 40-50MB / s , testado em Windows (Server 2012) e Linux (Debian). Eu li sobre o alinhamento de discos e partições e recriou a configuração raid e lvm pelo livro, mas não recebi nenhum aumento de desempenho.

Ao medir cargas no topo durante gravações diretamente do host, posso ver que os discos e lvm estão recebendo cargas altas, mas medir enquanto um convidado está escrevendo mostra os discos em ~ 20-30% e lvm ficando "vermelho" ( 100%).

Os ajustes normais do sistema KVM / host foram feitos, definindo o agendador para o prazo, definindo caches de distribuição para o raid, cache = none nos convidados, reflashing o cartão controlador SAS para o modo IT (LSI 2308) e eu sou Sem ideias, aqui está uma pasta com informações relevantes sobre a configuração, na esperança de que alguém perceba algo que eu fiz de errado link .

Se precisar de mais alguma coisa, cole-o.

Edições:

Isso é basicamente como as unidades, md e lvm são configuradas, com algumas alterações, porque eu estou executando 3 discos + sobressalentes. link

Screenshots de atop durante os writetests de host e guest (bonnie ++)

Anfitrião: link

Convidado: link

    

Answer 1

Não tenho certeza de que minha anotação cobre todo o problema, mas com essa configuração de armazenamento você não conseguiu um alinhamento adequado.

Vamos ver,

• Você pode alinhar limites de partição de acordo com o tamanho da faixa RAID, está tudo bem.

• Você pode definir os parâmetros de otimização do sistema de arquivos de acordo, também está OK.

• Mas para alinhar o LVM corretamente, você precisa das faixas de RAID para se adequar à extensão do LVM.

O tamanho da extensão do LVM é sempre a potência de 2. Assim, o tamanho da faixa do RAID precisa ser de potência de 2. Para obtê-lo, você precisa de um número de discos no RAID5 para ser igual a 2 ^ N + 1 = 3, 5, 9 ...

Com 4 discos no RAID5, é impossível.

Como o software RAID5 não tem cache de write-back protegido, ele pode ser significativamente vulnerável "penalidade de gravação de faixa parcial".

Pode ser que você também tenha outras causas restringindo o desempenho de gravação, mas o primeiro que eu teria feito - a migração para o RAID10. Com o RAID10 em todos os 6 discos, você consegue obter desempenho de leitura e capacidade de armazenamento de convidados comparável à sua configuração inicial ... e sem dor de cabeça com alinhamento;).

    

Answer 2

Não use cache com o seu convidado kvm, se o convidado der um pedido de gravação e o pedido for para o cache do host (os dados do cache estão na memória do host físico) e o seu host falhar e o pedido não for gravado no host disco virtual convidado, talvez você receba um problema no sistema de arquivos do seu convidado

    

Answer 3

Se você pesquisar no google kvm disk io, há um incrível número de acessos. Então eu vou ficar com XEN. ; -)

Portanto, este parece ser um problema geral com o KVM.

A linha principal comum é usar o virtio-driver correto.

Depois, há duas linhas:

• use o cache em o servidor KVM

• não use o cache nos clientes em um KVM-server se o hostOS já estiver fazendo cache de disco. Isso se aplica também ao Xen e aos outros hipervisores.

Ambos parecem funcionar - mas ambos dizem que os padrões são terríveis.

    

Answer 4

Eu fiz testes extensivos sobre o KVM e o desempenho do cache (você pode ler http://www.ilsistemista.net/index.php/virtualization/43-kvm-scalability-and-consolidation-ratio -cache-none-vs-cache-writeback.html "> aqui , aqui e aqui ) e muitas das recomendações que você encontra na Internet são completamente erradas. Mas vamos prosseguir um passo de cada vez ...

1. O RAID5 precisa de um tamanho de bloco muito menor (na ordem de 32-64K) do que o seu (512K, visto de pastebin) e uma BBU (para cache de write-back) ser viável para qualquer coisa diferente dos padrões de leitura / gravação sequencial.
2. Evite o RAID5 para qualquer carga de trabalho que precise de IOPS e / ou emita uma parte significativa das gravações aleatórias. Isso é EXATAMENTE o que um sistema operacional convidado precisa (IOPS e velocidade de gravação aleatória), portanto a escolha do RAID5 (sem e a BBU de hardware para habilitar o cache de write-back de toda a matriz) é a errada. Use o RAID10.
3. Ative o cache = writeback para seus convidados. Cache = nenhum é um pouco melhor apenas em leituras / gravações sequenciais ou padrões absolutamente irregulares e hostis ao cache.
4. Use os drivers do virtio dentro de seus convidados sempre que for possível.