Estou pensando em migrar do ext3 para o ZFS para armazenamento de dados no meu host Debian Linux, usando o ZFS no Linux . Um recurso matador do ZFS que eu realmente quero é sua garantia de integridade de dados. A capacidade de aumentar o armazenamento de maneira trivial, conforme aumenta o meu armazenamento, também é algo que eu gostaria de esperar.
No entanto, também executo algumas VMs no mesmo host. (Embora normalmente, no meu caso, apenas uma VM está sendo executada no host a qualquer momento.)
Considerando o comportamento de soma de verificação e copy-on-write dos dados do ZFS, juntamente com o fato de que as imagens de disco da VM são arquivos comparativamente grandes (o arquivo de imagem de disco da VM principal está atualmente em 31 GB), quais são as implicações de desempenho dentro do convidado VM de tal migração? Que passos posso dar para reduzir o possível impacto negativo no desempenho?
Eu posso viver com menos garantias de integridade de dados nas imagens de disco da VM, se necessário (eu não faço nada realmente crítico dentro de qualquer VM) e posso facilmente separá-las do resto do sistema de arquivos, mas seria bom se eu não tiver que (mesmo seletivamente) desligar praticamente o recurso que mais me faz querer migrar para um sistema de arquivos diferente.
O hardware é bastante robusto para um sistema de classe de estação de trabalho, mas não serve muito para um servidor high-end (32 GB de RAM com raramente > 10 GB em uso, CPU de 6 núcleos de 3,3 GHz, atualmente espaço em disco utilizável de 2,6 TB de acordo com df e um total de aproximadamente 1,1 TB livre; a migração para o ZFS provavelmente adiciona um pouco mais espaço livre ) e não estou planejando executar a deduplicação de dados (como ativar a dedup apenas não acrescentaria muito na minha situação). O plano é começar com uma configuração JBOD (obviamente com bons backups), mas eu posso passar para uma configuração de espelho bidirecional eventualmente, se as condições o permitirem.
Como o ZFS funciona em um nível de bloco, o tamanho dos arquivos não faz diferença. O ZFS requer mais memória e CPU, mas não é inerentemente significativamente mais lento como um sistema de arquivos. Embora você precise estar ciente de que o RAIDZ não é equivalente em velocidade ao RAID5. O RAID10 é bom quando a velocidade é uma prioridade.
O ZFS em hardware decente (ou seja, buff) provavelmente será mais rápido do que outros sistemas de arquivos, você provavelmente desejará criar um ZIL em um local rápido (ou seja, SSD). Este é essencialmente um local para gravar em cache (bem, mais como um diário em ext3 / 4). Isso permite que a caixa ack seja gravada no disco antes que os eixos reais tenham os dados.
Você também pode criar um L2 ARC no SSD para o cache de leitura. Isso é fantástico em um ambiente de VM em que você pode colocar discos físicos de joelhos ao inicializar várias VMs ao mesmo tempo.
Drives entram em VDEVs, VDEVs entram em zpools (por favor use discos inteiros de cada vez). Se este for um sistema menor, você pode querer ter um único zpool e (se não estiver muito preocupado com a perda de dados) um único VDEV. VDEVs são onde você seleciona o nível de RAID (embora você também possa ESPELHAR VDEVs se tiver discos suficientes). O disco mais lento em um VDEV determina a velocidade de todo o VDEV.
O ZFS tem tudo a ver com integridade de dados - a razão pela qual muitas das ferramentas tradicionais de manutenção de sistemas de arquivos não existem (como fsck) é que o problema que elas resolvem não pode existir em um sistema de arquivos ZFS.
IMO, a maior desvantagem do ZFS é que, se os sistemas de arquivos se aproximarem completamente (digamos, 75% +), ele fica MUITO lento. Apenas não vá lá.
31GB realmente não é grande de todo ...
De qualquer forma, dependendo do sistema de arquivos que você está usando atualmente, você pode achar que o ZFS é um pouco mais lento, mas considerando suas especificações de hardware, pode ser insignificante.
Obviamente, o ZFS usará uma boa quantidade de RAM para armazenar em cache, o que pode fazer com que suas VMs pareçam mais "agitadas" no uso geral (quando não estiver fazendo leitura ou escrita pesadas). Não tenho certeza de como o ZFS está sintonizado no Linux, mas você pode precisar limitar seu ARC, se possível, para impedir que ele seja executado com toda a sua RAM (veja se você quer um pedaço decente sobra para o seu sistema host e VMs).
Eu habilitaria a compactação (o conselho atual é ativá-lo, a menos que você tenha um bom motivo para não ativá-lo). Lembre-se de que isso deve ser feito antes de colocar dados no sistema de arquivos. A maioria das pessoas fica surpresa ao descobrir que é realmente mais rápido, pois os algoritmos de compactação geralmente são executados mais rápido que o disco IO. Eu duvido que isso cause muito de um problema de desempenho com o seu processador de 6 núcleos. Eu não esperava que as VMs compactassem muito, mas consegui transformar ~ 470 GB de dados de VM em 304 GB apenas com a configuração padrão de compactação.
Não se preocupe com dedupe, ele só voltará para assombrá-lo mais tarde e você passará semanas vasculhando dados tentando se livrar dele.
Se você encontrar problemas de desempenho, a resposta óbvia é adicionar um SSD como ZIL / L2ARC ou ambos. Não é ideal usar um dispositivo para ambos, mas provavelmente ainda melhorará o desempenho em um pool que contenha um pequeno número de discos / vdevs.
Para adicionar: Eu realmente tentaria e começaria com uma configuração redundante, se possível (idealmente espelhos), ou converter em espelhos de uma faixa, o mais rapidamente possível. Embora o ZFS monitore todos os dados e detecte erros rapidamente (ou durante um scrub), ele não poderá fazer nada a respeito (sem usar o = 2 que duplicará o uso do disco). Você só vai ficar com ele dizendo que há erros nos arquivos (provavelmente suas imagens de disco da VM) que você não será capaz de fazer muito sem eliminar e recriar esses arquivos.
Dependendo de seus casos de uso e VMs, considero o seguinte. Permita que o sistema operacional Host cuide dos arquivos que você está armazenando nos volumes do ZFS.
Se possível, crie apenas um LUN para cada VM, contendo apenas o sistema operacional e os arquivos binários necessários. E presente Storage stace para dados individuais como compartilhamentos via NFS, samba ou iSCSI (ou zvols como mencionado nos comentários). O ZFS é capaz de controlar todos os arquivos com checksum e tempos de acesso ect. É claro que, se a velocidade não for tão importante, você também poderá ativar a compactação em alguns Datastores. O benefício seria uma camada ausente de outro sistema de arquivos. Se você criasse um LUN para o segundo Disco Rígido Virtual e criasse um Sistema de Arquivos NTFS, o ZFS teria que lidar com um grande Binary blob e não conheceria nenhum conteúdo ou arquivos e, portanto, não poderia aproveitar o cache do ZIL ou do ARC. da mesma forma que os arquivos de avião poderiam.
Mencionando as ACLs, o ZFS pode usar ACLs via NFSv4 ou Samba (se ativado). Eu admito que eu uso o ZFS no FreeBSD, e não posso garantir como habilitar ACLs do Sambas que se encaixem nos volumes do ZFS. Mas tenho certeza de que isso não deve ser um grande problema.
A desduplicação em combinação com um cache de leitura é uma grande vantagem quando se trata de economizar espaço e melhorar as leituras massivas (Boot storm), pois todas as VMs começam a ler os mesmos blocos.
O mesmo acontece com os instantâneos do ZFS para as VMs e os Datastores. Você pode criar um script de shell simples, congelar a VM, tirar um instantâneo da VM e do Datastore e continuar trabalhando ou apenas o Datastore sozinho e clonar a VM, apresentar o instantâneo do original e testar algumas coisas.
As possibilidades são infinitas com o ZFS;)
EDIT: Espero ter explicado um pouco melhor agora
EDIT2: Opinião pessoal: Considere usar um RAIDZ2 (RAID6), pois você pode suportar uma falha dupla de disco! Se você tiver um único disco sobrando, ele nunca estará errado, mas duas falhas de disco devem ser suficientes para um reaktion rápido. Acabei de postar meu script para monitorar o status do disco aqui