Estou configurando um sistema Linux em KVM (QEMU) para testar o efeito de adicionar um cache LVM de write-back em um disco rápido na frente de um volume lógico que reside em um conjunto de discos muito lentos (um RAID1 LV). Isso é modelado em uma configuração física real que não quero tocar até saber como ela pode lidar com o cache adicionado.
O problema é que no KVM todos os discos funcionam na mesma velocidade, portanto o cache raramente é utilizado e não vejo nenhum benefício de desempenho. Idealmente, quero que o espelho RAID1 tenha dificuldades com E/S, permitindo-me observar o volume do cache sendo preenchido durante as gravações e gradativamente gradativamente no conjunto de espelhos.
Existe uma maneira de acelerar artificialmente a velocidade de um disco no KVM/QEMU?
Atualmente estou usando o Debian 12 como host para este experimento, com a máquina KVM rodando Alpine Linux (e também testando com o Debian 12). A configuração do KVM inclui uma imagem qcow2 principal (o disco rápido) e imagens qcow2 adicionais (o espelho RAID lento).
Qemu tem suporte nativo para Network Block Devices (NBD),
--drive file=nbd://<host>[:<port>]/[<export>]
. (você também pode usarnbd.ko
no próprio convidado).Isso é bastante útil, porque com o
nbdkit
, há uma implementação de servidor NBD que suporta plug-ins para simular distorções de serviço como filtros . Algo comonbdkit --filter=delay file /path/to/backing/storage rdelay=300ms wdelay=300ms
simularia um disco rígido com atraso de acesso atroz, usando odelay
filtro .Você provavelmente gostaria que o
spinning
filtro chegasse a algum lugar próximo ao comportamento dos pratos giratórios, combinado comrate
filter .Supondo que você não vá reutilizar os dados e esteja fazendo isso em uma máquina com bastante RAM, faria sentido usar o
memory
plugin (em vez dofile
plugin como no exemplo acima), para eliminar imperfeições reais de armazenamento. da imagem.O subsistema mapeador de dispositivos inclui
CONFIG_DM_DELAY
um destino mapeador de dispositivos que pode ser usado para adicionar atraso às operações de disco.O kernel padrão do Debian 12 o inclui como um módulo.
Por exemplo: create
/dev/mapper/delayed
, que será igual a/dev/sdX
, mas com um atraso de 500 ms adicionado:Mais informações: https://docs.kernel.org/next/admin-guide/device-mapper/delay.html
QEMU fornece suporte interno para limitar a largura de banda em bytes por segundo e taxas de IO com base em operações de IO por segundo (em ambos os casos com suporte para fazer isso de forma diferente para operações de leitura ou gravação).
Se invocar o QEMU diretamente, as opções adicionais relevantes no
-drive
sinalizador são:bps=x
,bps_rd=x
,bps_wr=x
: Para limitar a largura de banda global, de leitura e gravação emx
bytes por segundo, respectivamente.bps_max=x
,bps_rd_max=x
,bps_wr_max=x
: Semelhante, mas para permitir uma explosão temporária acima do limite regular.iops=x
,iops_rd=x
,iops_wr=x
: Para limitar operações globais, de leitura e gravação de IO por segundo aox
total de operações por segundo, respectivamente.iops_max=x
,iops_rd_max=x
,iops_wr_max=x
: Semelhante, mas para uma explosão temporária acima do limite regular.iops_size=y
: para tratar caday
byte de uma solicitação de IO como uma operação de IO separada para os limites acima (destinada a ajudar a limitar melhor o desempenho de IO).group=g
: para associar o dispositivo a um grupo de cotas chamadog
. Todos os dispositivos no mesmo grupo nomeado usarão a mesma largura de banda e configurações de IOPS e compartilharão seus limites.libvirt também suporta esta interface em seu formato XML de domínio, usando o
<iotune>
elemento (detalhes podem ser encontrados nesta seção dos documentos XML de domínio libvirt ), fornecendo todas as mesmas funcionalidades, mas com alguns botões extras para ajustar melhor as coisas .Se você precisar apenas de um teste rápido, esta é provavelmente a abordagem mais simples, pois é totalmente independente. Se o teste for uma configuração descartável, você também poderá colocar a imagem do disco em uma instância tmpfs no lado do host para limitar o impacto do subsistema de E/S do host.