ZFS no disco virtual único

Question

• Como as empresas gerenciam grandes servidores de arquivos (por exemplo, 17 TB) e seus relacionados backups em um orçamento muito apertado?
• Há algum problema em usar o ZFS (ou o BTRFS) em um único disco virtual para sua natureza de copy-on-write para eliminar a necessidade de fsck? (isto é, não para seus recursos de RAID, snapshot, etc.)

Situação específica:

Precisamos aposentar um antigo sistema de armazenamento problemático que estava servindo armazenamento NFS para virtuais e ainda é nosso servidor de arquivos principal. Agora tenho um novo sistema de armazenamento baseado em iSCSI FreeNAS de 40TB e já disponibilizei todos os virtuais do armazenamento antigo para o novo, mas os 17 TB de SMB / CIFS & Os arquivos compartilhados do AFP permanecem.

Backups são feitos via rsync, o que leva muito tempo para escanear 17 TB, então dividimos em dois volumes:

• 13 TB em um volume de "arquivamento" somente leitura para arquivos que não foram modificado por um ano. Para fazer backup, simplesmente fazemos no local e fora do local cópias usando rsync - não há necessidade de versões diárias de backup.
• 4 TB de armazenamento gravável ao vivo. Este backup é feito diariamente com o rsync e usa hard-links para criar “instantâneos” / versões do estado do servidor de arquivos naquele dia em particular, para que possamos recuperar arquivos sobrescritos.

A equipe de TI move os arquivos do arquivamento para o local em que as modificações são necessárias, mas essas solicitações são feitas várias vezes ao dia e não são mais aceitáveis.

Plano original:

• Crie um servidor de arquivos virtual do Linux.
• Crie discos virtuais de 2x em nosso novo sistema de armazenamento de 40 TB. (13 TB de arquivo + 4 TB graváveis ao vivo)
• Formate os discos acima com os sistemas de arquivos ext4
• Use o UnionFS com a opção cow mount para apresentar uma única visualização unificada dos sistemas de arquivos acima aos usuários, com todas as gravações indo para o sistema gravável de 4 TB.

Problemas com o plano original:

• Estamos superando a natureza baseada em arquivos do rsync como uma ferramenta de backup, por exemplo, renomear uma pasta de nível superior de 1 TB resulta em uma nova cópia completa de toda a pasta de 1 TB. Isso adicionaria apenas alguns KB a um backup baseado em bloco.
• A implementação do UnionFS acrescenta mais uma camada de complicação a todo o sistema, o que eu realmente gostaria de evitar.
• Devido ao fato de o rsync precisar varrer novamente todo o servidor de arquivos para comparar os arquivos alterados, leva muito tempo para concluir os backups, mesmo que apenas alguns arquivos tenham sido alterados.
• É necessário que façamos o arquivamento contínuo para manter o volume gravável pequeno o suficiente para que os backups sejam concluídos da noite para o dia.

Plano alternativo 1: Um grande volume e instantâneos do ZFS para backups

• Crie o servidor de arquivos do Linux planejado acima, mas com um grande volume, em vez de dois, eliminando a necessidade do UnionFS
• Para fazer backup desse servidor muito grande, que demoraria muito tempo com o rsync, use instantâneos do ZFS e use "zfs send" para replicar externamente.

Problema com o plano alternativo 1:

• fsck em um sistema de arquivos ext4 de 17 TB levaria dias! Imagine um incidente de segunda-feira que requer uma reinicialização e fsck forçado durante a inicialização, ou pior, uma corrupção do sistema de arquivos!

Plano alternativo 2: sistema de arquivos ZFS / BTRFS no servidor Linux

• De acordo com o plano alternativo 1, use um sistema de arquivos copy-on-write, como ZFS ou BTRFS, em vez de ext4, porque eles não exigem fsck.

Perguntas / preocupações para o plano alternativo 2:

• Tanto o ZFS quanto o BTRFS desejam acesso direto a discos brutos para implementar seu próprio RAID e, portanto, não são normalmente usados em discos virtuais. Quão bem isso funcionará em um único disco virtual?

Plano alternativo 3: FreeNAS como servidor de arquivos diretamente

• Em vez de ter um servidor de arquivos virtual separado, compartilhe arquivos diretamente do FreeNAS

Problema com o plano alternativo 3:

• Precisamos instalar vários pacotes e scripts personalizados perl / bash / python para integrar esse servidor de arquivos ao nosso sistema de rastreamento de trabalhos. Isso vai funcionar bem no Linux, mas eu não acho que seja uma boa idéia em um sistema de armazenamento ZFS baseado em FreeBSD (FreeNAS). As atualizações podem substituir nossas alterações, etc.

Perguntas:

• O plano alternativo 2 - ZFS no disco virtual único - é uma boa ideia? Se não, por quê?
• Alguém pode sugerir melhores opções?

Answer 1

How do companies manage large file servers (e.g. 17 TB) and their related backups on a very tight-budget?

Depende das restrições de desempenho e orçamento. Por exemplo, o Backblaze (uma empresa de backup na nuvem) tem um orçamento muito restrito para cada TB, mas eles não precisam do melhor desempenho ou do tempo de resposta para os dados. Algumas outras empresas podem precisar de desempenho barato, mas encontram uma maneira de reduzir os dados necessários (com a deduplicação, a remoção de dados antigos de backup ou simplesmente reduzindo os dados reais que podem não ser necessários para os negócios).

Is it ok to use ZFS (or BTRFS) on a single virtual disk for its copy-on-write nature to eliminate the need for fsck? (i.e. not for its RAID, snapshot, etc. features)

Eu não usaria o BTRFS em nada que não fosse de desenvolvimento, no qual você precisa confiar na segurança de seus dados como primeiro princípio. Eu usaria o ZFS porque não encontrei uma alternativa mais barata e segura a ele (outros FS com recursos semelhantes da IBM, NetApp etc. são mais caros, outros sistemas de arquivos livres não são maduros (HAMMER2, BTRFS) ou carecem de recursos essenciais ( ext2 / 3/4, reiserfs, etc.).

Suas respostas específicas: Eu preferiria o plano 3, mas o plano 2 também funcionaria.

Ao contrário de muito FUD flutuando na web, o ZFS não se importa com o armazenamento subjacente, seja ele físico, virtual ou misto. É claro que só pode ser tão bom / rápido / seguro quanto o armazenamento subjacente e só pode raciocinar sobre o que é dado. Isso significa que seu desempenho não será tão bom quanto o nativo, sua solução de problemas envolve as duas camadas e ambas as camadas podem ter problemas. Se você souber disso e aprovar essas desvantagens, vejo isso como uma alternativa viável.

Você ainda tem recursos de conforto como enviar / receber, snapshots, CoW, somas de verificação e desduplicação em nível de bloco. O que você sacrifica é principalmente desempenho e possivelmente segurança (se sua SAN é apenas um único disco, por exemplo). Você também deve ajustar os tamanhos do setor do ZFS ( ashift ) para o armazenamento subjacente ao criar o pool. Você pode ter tamanhos diferentes para sistemas de arquivos individuais depois, mas a configuração do conjunto não pode ser revertida sem destruí-lo.

Mas primeiramente eu avaliaria se a reescrita desses scripts e integrações é tão demorada quanto você imagina. Além disso, até mesmo aparelhos como FreeNAS (ou napp-it, para nomear uma alternativa) têm geralmente scripts de usuário ou plugins ou módulos definidos pelo usuário, que sobrevivem às atualizações e funcionam bem com o appliance (o novo FreeNAS 10 aka Corral substituiu seu plugin arquitetura com Docker, se isso é algo que você está familiarizado com ele pode ser uma alternativa).