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 é a sua garantia de integridade de dados. A capacidade de aumentar trivialmente o armazenamento à medida que minhas necessidades de armazenamento aumentam também é algo que eu gostaria de ver.
No entanto, eu também executo algumas VMs no mesmo host. (Embora normalmente, no meu caso, apenas uma VM esteja sendo executada no host por vez.)
Considerando o comportamento de soma de verificação de dados e cópia na gravação do ZFS, juntamente com o fato de as imagens de disco da VM serem arquivos comparativamente grandes (o arquivo de imagem de disco da minha VM principal atualmente possui 31 GB), quais são as implicações de desempenho no convidado da VM desse tipo uma migração? Que medidas posso tomar para reduzir o possível impacto negativo no desempenho?
Posso viver com menos garantias de integridade de dados nas imagens de disco da VM, se necessário (não faço nada realmente crítico dentro de nenhuma das VMs) e posso separá-las facilmente do resto do sistema de arquivos, mas seria bom se eu não precisa (mesmo seletivamente) desativar 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 suporta muito um servidor high-end (32 GB de RAM com raramente> 10 GB em uso, CPU de 6,3 GHz e 6 núcleos, atualmente utilizável em 2,6 TB espaço em disco de acordo com dfe um total de cerca de 1,1 TB livre; migrar para o ZFS provavelmente adicionará mais espaço livre ) e não estou planejando executar a desduplicação de dados (como ativar a desduplicação não adicionaria muito à 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 justificarem.
fonte
Respostas:
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.
fonte
O ZFS em um hardware decente (ou seja, buff) provavelmente será mais rápido que em outros sistemas de arquivos; é provável que você queira criar um ZIL em um local rápido (ou seja, SSD). Este é essencialmente um local para armazenar gravações em cache (bem, mais como um diário no ext3 / 4). Isso permite que a caixa ack escreva como sendo gravada em disco antes que os eixos reais tenham os dados.
Você também pode criar um L2 ARC no SSD para cache de leitura. Isso é fantástico em um ambiente de VM em que você pode colocar discos físicos de joelhos inicializando várias VMs ao mesmo tempo.
As unidades entram nos VDEVs, os VDEVs entram nos zpools (use discos inteiros de cada vez). Se este for um sistema menor, convém ter um único zpool e (se você não estiver muito preocupado com a perda de dados) um único VDEV. Os VDEVs são onde você seleciona o nível RAID (embora você também possa MIRROR VDEVs se você tiver discos suficientes). O disco mais lento em um VDEV determina a rapidez com que o VDEV inteiro é.
O ZFS tem tudo a ver com integridade de dados - a razão pela qual muitas das ferramentas tradicionais de manutenção do sistema de arquivos não existem (como o fsck) é o problema que elas resolvem não pode existir em um sistema de arquivos ZFS.
Na IMO, a maior desvantagem do ZFS é que, se seus sistemas de arquivos se aproximarem (digamos, 75% +), fica MUITO lento. Só não vá lá.
fonte
31GB realmente não é nada grande ...
De qualquer forma, dependendo do sistema de arquivos que você está usando no momento, você pode achar que o ZFS é um pouco mais lento, mas, considerando as especificações de hardware, pode ser insignificante.
Obviamente, o ZFS usará uma boa parte da RAM para armazenar em cache, o que pode fazer com que suas VMs pareçam mais rápidas em uso geral (quando não estiver lendo ou gravando muito). Não tenho certeza de como o ZFS está sintonizado no Linux, mas pode ser necessário limitar seu ARC, se possível, para impedir que ele se esgote com toda a sua RAM (já que você precisará de um pedaço decente para o seu sistema host e VMs).
Eu habilitaria a compactação (atualmente, o conselho é ativá-la, a menos que você tenha um bom motivo para não fazê-lo). Lembre-se de que isso precisa ser feito antes de colocar os dados no sistema de arquivos. A maioria das pessoas fica surpresa ao descobrir que é realmente mais rápido com isso, pois os algoritmos de compactação geralmente rodam mais rápido que as E / S do disco. Duvido que isso cause muito problema de desempenho no seu processador de 6 núcleos. Eu não esperava que as VMs compactassem muito, mas consegui transformar ~ 470 GB de dados da VM em 304 GB apenas com a configuração de compactação padrão.
Não se preocupe com a desduplicação, ela voltará para assombrá-lo mais tarde e você passará semanas baralhando os dados tentando se livrar deles.
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 contém um pequeno número de discos / vdevs.
Para adicionar: eu realmente tentaria começar com uma configuração redundante, se possível (idealmente espelhos), ou converter para espelhos a partir de uma faixa o mais rápido possível. Embora o ZFS faça a soma de todos os dados e detecte erros em tempo real (ou durante uma limpeza), ele não poderá fazer nada a respeito (sem usar cópias = 2, o que duplicará o uso do disco). Você ficará sabendo que há erros nos arquivos (provavelmente as imagens de disco da sua VM) que você não poderá fazer muito sem excluir e recriar esses arquivos.
fonte
Dependendo dos seus casos de uso e VMs, eu consideraria o seguinte. Deixe o sistema operacional host cuidar dos arquivos que você está armazenando nos volumes ZFS.
Se possível, crie apenas um LUN para cada VM, contendo apenas o sistema operacional e os arquivos binários necessários. E apresente o armazenamento para Dados Individuais como compartilhamentos via NFS, samba ou iSCSI (ou zvols, conforme mencionado nos comentários). O ZFS é capaz de acompanhar todos os arquivos com soma de verificação e tempos de acesso etc. Obviamente, 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ê criar um LUN para o segundo disco rígido virtual e criar um sistema de arquivos NTFS, o ZFS precisará lidar com um grande blob binário e não conhecer nenhum conteúdo ou arquivos e, portanto, não poderá tirar proveito do cache ZIL ou ARC no da mesma maneira que os arquivos de avião podiam.
Mencionando ACLs, o ZFS pode usar ACLs via NFSv4 ou Samba (se ativado). Eu admito que uso o ZFS no FreeBSD e não posso garantir como habilitar as ACLs do Sambas acasalando nos volumes do ZFS. Mas tenho certeza de que isso não deve ser grande coisa.
A redução de redundância em combinação com um cache de leitura é uma grande vantagem quando se trata de economizar espaço e melhorar leituras massivas (tempestade de inicialização), pois todas as VMs começam a ler os mesmos blocos.
O mesmo vale para os instantâneos do ZFS para as VMs e os datastores. Você pode criar um script de shell simples, para congelar a VM, tirar uma captura instantânea da VM e do armazenamento de dados e continuar trabalhando, ou apenas o armazenamento de dados sozinho, e clonar a VM para 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 de disco duplo! Se você tiver um único disco sobressalente, ele nunca estará errado, mas duas falhas no disco deverão ser suficientes para uma rápida reação. Acabei de postar meu script para monitorar o status do disco aqui
fonte