Alta latência de I / O com RAID por software, LUKS criptografado e configuração KVM particionada por LVM

Question

Descobri problemas de desempenho com um servidor Mumble, que eu descrevi em uma pergunta anterior causada por um I / O problema de latência de origem desconhecida. Como não tenho ideia do que está causando isso e de como depurá-lo ainda mais, estou pedindo suas ideias sobre o assunto.

Estou executando um servidor raiz Hetzner EX4S como hypervisor KVM. O servidor está rodando Debian Wheezy Beta 4 e a virtualização KVM é utilizada através do LibVirt.

O servidor tem dois discos rígidos de 3 TB diferentes, já que um dos discos rígidos foi substituído após o S.M.A.R.T. erros foram relatados. O primeiro disco rígido é um Seagate Barracuda XT ST33000651AS (512 bytes lógicos, 4096 bytes de tamanho de setor físico), o outro é um Seagate Barracuda 7200.14 (AF) ST3000DM001-9YN166 (512 bytes de tamanho de setor físico e lógico). Existem dois dispositivos RAID1 de software Linux. Um para a partição de inicialização não criptografada e um como contêiner para o restante criptografado, usando os dois discos rígidos.

Dentro do último dispositivo RAID está um contêiner LUKS criptografado AES. Dentro do contêiner LUKS há um volume físico LVM. O VFS do hipervisor é dividido em três volumes lógicos no volume físico LVM descrito: um para /, um para / home e um para swap.

Aqui está um diagrama da pilha de configuração de dispositivos de bloco:

sda (Physical HDD)
- md0 (RAID1)
- md1 (RAID1)

sdb (Physical HDD)
- md0 (RAID1)
- md1 (RAID1)

md0 (Boot RAID)
- ext4 (/boot)

md1 (Data RAID)
- LUKS container
  - LVM Physical volume
    - LVM volume hypervisor-root
    - LVM volume hypervisor-home
    - LVM volume hypervisor-swap
    - … (Virtual machine volumes)

Os sistemas convidados (máquinas virtuais) estão na maior parte executando o Debian Wheezy Beta 4 também. Nós temos uma instância adicional do Ubuntu Precise. Eles também obtêm seus dispositivos de bloco do volume físico do LVM. Os volumes são acessados por meio dos drivers do Virtio no modo de gravação nativa. O escalonador de E / S (elevador) no hypervisor e no sistema convidado é definido como deadline em vez do padrão cfs , já que foi a configuração com melhor desempenho de acordo com nossa série de testes bonnie ++.

O problema de latência de E / S é experimentado não apenas dentro dos sistemas guest, mas também está afetando os serviços em execução no próprio sistema hypervisor. A configuração parece complexa, mas tenho certeza de que a estrutura básica não causa os problemas de latência, já que meu servidor anterior executou quatro anos com quase a mesma configuração básica, sem nenhum dos problemas de desempenho.

Na configuração antiga, as seguintes coisas eram diferentes:

• O Debian Lenny foi o sistema operacional para o hipervisor e quase todos os convidados
• Virtualização de software Xen (portanto, não Virtio, também)
• sem gerenciamento do LibVirt
• Diferentes discos rígidos, cada um com 1,5 TB de tamanho (um deles era um Seagate Barracuda 7200.11 ST31500341AS, o outro que eu não posso mais dizer)
• Não tivemos conectividade IPv6
• Nem no hypervisor nem nos convidados, tivemos problemas de latência de E / S notáveis

De acordo com as folhas de dados, os discos rígidos atuais e o da máquina antiga têm uma latência média de 4,12ms.

    

Answer 1

Uma unidade SATA de 7200 RPM não consegue fazer uma latência de 4,12 ms, o que permitiria fazer 1 / 4,12ms (aproximadamente 240) IOs por segundo, o que não é realista.

A fórmula adequada para calcular IOPS para um único disco é 1 / (avg_seek_time + avg_rotational_latency), que para unidades de 7200 RPM é igual a aproximadamente 75 IOPS. Se você tem uma folha de especificações para o disco, então você teria duas latências, pois as unidades podem absorver gravações e leituras com diferentes latências, mas elas estão dentro de + -10%.

Você pode esperar uma latência de 13-15ms por IO de um disco SATA enquanto a profundidade da sua fila não é muito alta. Tudo entre 10 e 15ms seria considerado OK; 20ms sugeriria problemas de latência por filas profundas (ou tamanhos muito grandes de solicitações de E / S) e 30ms ou mais apontariam para algo patológico. Teoricamente falando, seu 95º percentil deveria estar abaixo de 15 ms e o sistema se comportaria "normalmente".

Você pode fornecer uma medida do tempo médio de atendimento do host e do convidado enquanto executa sua carga de trabalho de produção? Você pode adquirir esse valor observando a saída de iostat na coluna "aguardar".

Além disso, eu diria que sua configuração tem a máxima latência de abstração possível - desde que você coloque bastante coisa do sistema de arquivos virtual nos blocos físicos do dispositivo.

Além disso, você pode verificar se o seu HBA tem um BBWC (ou se há caches de gravação de disco ativados) e o sistema de arquivos no hipervisor e dentro do convidado não estão usando barreiras?