Sistema de arquivos do Linux KVM Client (BTRFS?)

Question

em nossa empresa, temos muitos clientes kvm em vários servidores, a maioria dos clientes está executando o Ubuntu 16.04, bem como seus sistemas host.

O sistema de arquivos escolhido se tornou EXT4, para clientes e hosts. Recentemente eu usei alguns dos incríveis recursos de snapshot fornecidos pelo BTRFS para configurar um servidor de backup com backups incrementais.

Algumas pesquisas forneceram a pista de que nunca se usa o BTRFS para o host KVM, porque a fragmentação do FS retarda os clientes até que eles finalmente congelem.

Existe alguma recomendação / fazer / não para usar o BTRFS no cliente KVM?

Estamos reconsiderando nossas escolhas de FS para clientes e hosts, Há vantagens usando o XFS sobre EXT4 (cliente / host ou apenas um lado)?

    

Answer 1

No google você pode encontrar um monte de sites que falam sobre o desempenho de diferentes sistemas de arquivos com o KVM.

Dê uma olhada neste: ZFS, BTRFS, XFS, EXT4 e LVM com KVM - uma comparação de desempenho de armazenamento

Segundo o autor Gionatan Danti:

The tested scenarios are:

1) Qcow2 backend on top of XFS filesystem on top of a raw MD device. Both thin and partial (metadata only) preallocation modes were benchmarked;

2) Logical Volumes backend, both in classical LVM (fat preallocation) and thin (thin lvm target) modes. Moreover, thin lvm was analized with both zeroing on and off;

3) raw images on XFS and EXT4 on top of classical LVM, relaying on filesystem sparse-file support for thin provisioning;

4) raw images on XFS and EXT4 on top of thin LVM, relaying on thin lvm target for thin provisioning. In this case, LVM zeroing was disabled as the to-be-zero blocks are directly managed inside the filesystem structures;

5) raw images BTRFS on top of its mirror+stripe implementation (no MD here). I benchmarked BTRFS with CoW both enabled and disabled (nodatacow mount option)

6) raw images ZFS on top of its mirror+stripe implementation (no MD again)

Ele conclui por:

For VMs storage, stay well away from BTRFS: not only it is marked a “Tech Preview” from RedHat (read: not 100% production ready), but it is very slow when used as a VM images store.

Outro blog fala sobre o BTRFS, você pode ler em um monte de fóruns que o Copy On Write (COW) precisa ser desabilitado para obter melhores performances com o KVM.

Chris Irwin fala sobre os benefícios do BTRFS e fala sobre uma alternativa:

There are other tools, or you could roll your own cron-job. So what about ZFS? I thought ZFS did all these things?

Yes, it does Why not just use ZFS?

Go ahead

link: ao vivo com o btrfs

Outra maneira de saber se está tudo bem para o seu uso está testando por si mesmo se o desempenho é bom e se é confiável sem cópia na gravação.

Se o BTRFS não for o melhor para você, você pode tentar o ZFS. Você tem o mesmo fonctionality Backup e muitas outras melhorias, mas é um pouco complicado de implementar no linux.

    

Answer 2

Minha solução de orquestração KVM de escolha, oVirt, usa volumes LVM fornecidos como discos brutos para VMs para desempenho, escalabilidade e flexibilidade máximos. Você pode fazer os dois instantâneos qcow2 e LVM. Se você está construindo uma nova solução de armazenamento e quer tentar algo SDS-ish e fancy, você poderia ir com Ceph e RBD-access para volumes.

    

Answer 3

Dê uma olhada no site oficial do Btrfs Gotchas em seu próprio wiki: link

Especialmente neste ponto:

Fragmentation

Files with a lot of random writes can become heavily fragmented (10000+ extents) causing thrashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM. On servers and workstations this affects databases and virtual machine images. The nodatacow mount option may be of use here, with associated gotchas.

Então, sozon fala contra ele, qual é o uso de um sistema de arquivos COW se o único recurso para o qual você deseja usá-lo é não estar sendo usado com imagens de host virtual de maneira rápida? Se você quiser usar um sistema de arquivos COW, então utilize o ZFS.

Também tenha em mente que o Coreos se afastou do Btrfs para o EXT4 como sistema de arquivos padrão, porque ainda estava com muito bugs anos atrás.

link

Então, enquanto o Ext4 pode não ser tão chamativo e o Sr. Fancy Pants, é um cavalo de trabalho confiável e confiável. Se você está procurando por um sistema de arquivos além do Ext4 no Linux e não quer usar o ZOL / switching para o FreeBSD, talvez valha a pena dar uma chance ao XFS.

Por favor note que embora eu esteja usando o Btrfs no meu desktop doméstico com Gentoo e kernels bastante recentes, a cada poucos meses ainda há alguns soluços desagradáveis que tornam o sistema não inicializável e precisam ser reparados manualmente, o que leva tempo para investigar Google e usando julgamento e erro, e se não funcionar, um backup adequado.

A verdadeira questão que você deveria estar se perguntando é: por que devemos nos afastar do Ext4? Parece funcionar perfeitamente para o seu caso de uso. Só porque você leu algo sobre uma coisa nova e chamativa não significa que você realmente precisa. Pense nisso.

    

Answer 4

CentOS abandonou o suporte do btrfs ref: link Assim, para o CentOS, o btrfs não é uma escolha inteligente.

O btrfs é visto como o próximo padrão do FS, mas o ZFS também recebe muita atenção, principalmente pelo Ubuntu.

A maioria dos avisos contra o btrfs são antigos e ou dizem respeito a configurações específicas, como o RAID6 (que significa mais de 2drives)

O openSUSE escolhe o btrfs e o suporta bem. tal como um exemplo no diretório / var / lib / libvirt eles desabilitam o COW então eles obviamente enfrentam algum problema e os consertam.

Estou usando o openSUSE com o btrfs em 2 SSDs, como RAID1, que é usado como root, onde eu hospedo 5 VM (KVM) e 20 containers (Docker).

Estou bastante satisfeito com isso.