Usando o MySQL e o LxD sobre o Btrfs

Question

Eu tenho uma estação de trabalho Ubuntu 16.04, com um sistema de arquivos ext4.

1. Ao jogar com o LxD, eu gostaria de ter uma capacidade de snapshoting light-fast (já que minhas imagens normalmente seriam grandes). Essa capacidade, no meu entendimento, só poderia ser alcançada se o sistema de arquivos de apoio fosse um sistema de arquivos CoW como o Btrfs.

(Nota: A única ressalva relacionada ao desempenho para o Btrfs que eu encontrei até agora é o uso recomendado do sinalizador noatime mount).

2. Mas como também tenho uma instância do MySQL neste sistema cujo desempenho eu não gostaria de ver sofrer (em relação ao sistema de arquivos ext4), decidi fazer uma verificação final para quaisquer possíveis problemas com minha alternância para um MySQL suportado pelo Btrfs. . E, veja o que eu encontrei :

It's usually best to mount Btrfs with the 'nodatacow' option, disabling copy-on-write, because COW causes fragmentation, dish thrashing, and CPU and RAM spikes when you have a lot of random writes.

Agora, isso parece ser um verdadeiro amortecedor!

Pergunta: Existe alguma maneira que eu possa ter snapshot rápido e uma performance do MySQL com o Btrfs?

    

Answer 1

Eu tentei meu próprio comentário e tudo parece estar funcionando bem. Melhores alternativas ainda são bem-vindas.

Veja o que eu fiz.

# 1. Initial, onetime setup.
#   1.a) Create a sparse, 20G file.
      $ truncate -s 20G disk.20g

#   1.b) Format the loopback device with Btrfs.
      $ losetup /dev/loop0 disk.20g
      $ mkfs.btrfs /dev/loop0

# 2. Do this every time you wish to actually start using LxD.
# Note: Replace '/dev/loop0' with whatever loop-device is free on your system.
  $ sudo service lxd stop
  $ sudo mkdir -p /var/lib/lxd
  $ sudo mount -o noatime /dev/loop0 /var/lib/lxd
  $ sudo service lxd start

# 3. Do this to gracefully 'shutdown' the effects of Step 2.
  $ sudo service lxd stop
  $ sudo umount /var/lib/lxd
  $ losetup -d /dev/loop0
  $ sudo service lxd start

Então, para reiterar:

1. O sistema de arquivos principal do sistema operacional do meu host é o Ext4. O arquivo disk.20g acima reside apenas neste sistema de arquivos. Esse sistema de arquivos pode continuar a hospedar o MySQL e outros softwares cujo desempenho pode ser afetado negativamente pelo Btrfs.
2. O LxD armazena suas imagens e contêineres em uma partição do Btrfs. Isso permite instantâneos extremamente rápidos.

Answer 2

Fragmentação é um efeito colateral inevitável de um sistema de arquivos sendo projetado com copy-on-write. É também o que permite os instantâneos do sistema de arquivos quase livres.

A razão para isso é bastante simples: toda vez que um bloco é alterado, o novo bloco deve ser gravado em algum local diferente daquele do bloco original. Portanto, mesmo que o arquivo fosse contíguo originalmente, não será depois de modificado.

Não sei como o Btrfs nodatacow interage com os instantâneos, mas tenho a sensação de que, no instante em que você tem um instantâneo em um conjunto de dados, você força pelo menos um comportamento parcial de cópia na gravação, independentemente de quais bandeiras usando; caso contrário, como você seria capaz de acessar os dados antigos através do instantâneo?

No entanto, não é um dado que isso necessariamente afetará severamente seu desempenho no MySQL, por dois motivos:

• Discos modernos são realmente muito rápidos para cargas de trabalho de usuário único (o que eu acho que você está mais interessado porque você mencionou que seu sistema é uma "estação de trabalho")
• Os sistemas operacionais modernos possuem algoritmos de cache muito bons, reduzindo, assim, a necessidade de realmente atingir o armazenamento físico

Só para você ter uma ideia, eu mesmo estou executando o ZFS (do qual o Btrfs empresta muitas ideias), e atualmente há um scrub em andamento. O pool em questão é um raidz2 de seis discos, que não é realmente conhecido por seu desempenho estelar, apoiado fisicamente por seis discos de 7200 rpm (dois SATA, quatro SAS) que também não são exatamente conhecidos por IOPS estelares em particular. Um scrub do ZFS navega por toda a árvore Merkle em disco, lê todos os dados e verifica somas de verificação em tudo para garantir que tudo seja lido como foi gravado anteriormente; no meu caso, computando SHA-256 hashes de tudo ao longo do caminho. A velocidade de scrub atual (depois que passou da parte inicial, pesada de metadados, que envolve busca pesada) está pairando em torno de 200 MB / s e, na verdade, subindo lentamente. E isso é para E / S real em platter , sem o cache envolvido (porque o cache não faz sentido quando você quer verificar o que está no armazenamento persistente).

Claro, é muito provável que você veja alguma degradação de desempenho da fragmentação se mudar para um sistema de arquivos copy-on-write. Mas você não pode comer o bolo e guardá-lo também; Se rápido, instantâneos de baixo custo é algo que você quer, é provável que você vai ter que desistir de algo mais para obtê-los.

O que eu faria no seu caso é benchmark. Configure algum armazenamento Btrfs, coloque uma cópia do banco de dados MySQL lá e veja como os dois funcionam sob cargas de trabalho razoáveis.