BTRFS dentro de uma KVM-VM em uma imagem formatada em qcow2

2

Eu tenho um aplicativo de aplicação Ubuntu 14.04 que faz uso pesado de snapshots BTRFS. O aplicativo deve ser independente de hipervisor e os snapshots precisam ser armazenados com a imagem da máquina virtual, caso precisemos solucionar um problema. Usar os hypervisors construídos em métodos de snapshot ao invés de snapshots BTRFS seria mais trabalho do que vale, já que exigiria acesso da API ao hypervisor da VM que não queremos por razões de segurança. Eu também posso acessar remotamente os subvolumes do sistema de arquivos instantâneo BTRFS diretamente da linha de comando do appliance via ssh sem ter que desligar a máquina ou acessar uma API do hipervisor.

No passado, eu só tive que lidar com a implantação desse aplicativo em hipervisores baseados em vmware. Eu sempre usei thin provisioning em meus discos vmware e nunca notei nenhum problema de desempenho. Eu uso o provisionamento thin porque faço uma grande quantidade de testes neste appliance e tenho a tendência de implantar muitos appliances de uma vez para executar testes diferentes em paralelo.

Tenho muito cuidado ao não comprometer o armazenamento usando scripts que garantem que o crescimento do disco não fique fora de controle. O mergulho de E / S que acontece quando o disco provisionado thin precisa crescer também não é tão notável.

Agora eu preciso dar suporte ao KVM e gostaria muito de manter o Thin / sparse provisionando meus discos, no entanto li algumas coisas que misturam um sistema de arquivos CoW com outro sistema de arquivos CoW é uma má idéia devido ao excesso de redundância escreve e fragmentação de disco entre outras coisas. O exemplo comum dado era executar uma VM com um disco formatado em qcow2 armazenado em um volume formatado em BTRFS. Minha situação seria o oposto. Eu quero ter um sistema de arquivos formatado BTRFS em uma VM em execução a partir de uma imagem qcow2. Eu não encontrei muito sobre as particularidades do impacto no desempenho de snapshots BTRFS sobre uma imagem qcow2.

Pergunta: Existem outros formatos de arquivos esparsos que crescem com o tamanho do disco que o KVM gosta de usar?

Eu explorei com o uso de arquivos brutos esparsos, mas não consigo fazer com que fiquem esparsos através de um cp, baixe untar / gunzip, ect. Parece que, se você quiser usar um arquivo bruto esparso, não será possível movê-lo, o que tornaria a distribuição uma dor no rabo.

    
por Alex Vanino 17.02.2017 / 19:09

2 respostas

0

Minha experiência pessoal é que você pode trabalhar com arquivos brutos em um sistema de arquivos host com capacidade de dispersão.

Eu tenho arquivos raw em um sistema de arquivos do host ext4. Com o vm desligado eu posso usar "zerofree" nos arquivos raw (montado como dispositivo de loop) e usando cp --sparse = sempre oldfile newfile eu recebo tamanhos de arquivo reduzidos. Eu não sei se os arquivos ficam esparsos durante o uso, pois eu só uso esse método para "arquivar" imagens de sistemas de teste.

BTW, o btrfs com snapshot pesado parece ser uma má ideia: link

    
por 04.06.2017 / 19:53
0

O problema é que o KVM não suporta imagens de disco. Ao contrário do VMware, que é um tipo de solução tudo-em-um, o KVM somente fornece os recursos de virtualização, sobre os quais uma solução de virtualização pode ser construída.

...It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor specific module, kvm-intel.ko or kvm-amd.ko. - http://www.linux-kvm.org/page/Main%5FPage

Normalmente, uma solução baseada em KVM envolve a combinação de:

QEMU

O QEMU suporta dois formatos de disco native (existem outros formatos, como VDI):

Raw

Raw disk image format (default). This format has the advantage of
being simple and easily exportable to all other emulators. If your
file system supports holes (for example in ext2 or ext3 on Linux or NTFS on Windows), then only the written sectors will reserve space. - man qemu-img

Qcow / 2

QEMU image format, the most versatile format. Use it to have
smaller images (useful if your filesystem does not supports holes,
for example on Windows), optional AES encryption, zlib based
compression and support of multiple VM snapshots. - man qemu-img

libvirt

O libvirt fornece várias maneiras de armazenar imagens de disco:

  • Diretório back-end
  • back-end do sistema de arquivos local
  • back-end do sistema de arquivos de rede
  • Back-end lógico - LVM, mas sem thin-provisioning: (
  • Disk backend
  • backend do iSCSI
  • back end SCSI
  • backend do Multipath
  • backend RBD (Dispositivo de Bloqueio RADOS)
  • backend Sheepdog
  • back-end de Gluster
  • back end do ZFS
  • back-end de armazenamento do Virtuozzo

Dê uma olhada naqueles e veja quais deles, se houver, atendem aos seus requisitos. Veja o link e, melhor ainda, link

    
por 04.06.2017 / 22:32