Servidor de armazenamento de backup com o ZFS

Question

Eu sou tudo em uma pequena empresa. Desejo criar uma nova infraestrutura, incluindo um novo servidor e um servidor de backup separado, com política de backup para toda a empresa.

O mais importante na empresa é o SQL Server e seus bancos de dados. Existem 10 bancos de dados, mas apenas 2 deles são realmente importantes. O primeiro 8GB, principalmente dados de texto e números. O segundo, com cerca de 300 GB e 16 GB / mês, contém PDFs e GIFs.

Para salvar a política de backup atual de armazenamento, considere um backup completo por semana e seis diferenciais. Eu acho que é cerca de 350GB por semana, 1,4TB por mês.

Depois de ler os artigos sobre corrupção silenciosa de dados, decidi experimentar o ZFS com a edição Nexenta Community.

Minha pergunta: o ZFS com desduplicação é bom para armazenar arquivos de backup em termos de confiabilidade ou devo pensar em algum backup em fita ou outra coisa?

EDIT: Eu sei que agora não podemos prever o desempenho, a taxa de desduplicação, etc, mas eu quero saber se é uma boa idéia em tudo.

    

Answer 1

Certamente o ZFS é bastante estável o suficiente para fazer esse tipo de coisa, existem muitas plataformas de produção confiáveis e de alto perfil, baseadas inteiramente no ZFS e Nexenta.

Dito que sempre gostaria de ter backups baseados em disco no local, como o que você está sugerindo E backups de disco removível ou fita que vão diariamente para proteger contra incêndio / terremoto / Cthulhu etc.

Então, minha resposta é sim, tudo bem, mas eu posso optar por ambas as opções, se puder.

    

Answer 2

(supondo que você esteja se referindo ao uso de desduplicação no ZFS versus seu software de backup)

Eu não recomendo usar a desduplicação ZFS nativa para seu sistema de backup, a menos que você projete seu sistema de armazenamento especificamente para ele.

O uso da desduplicação no ZFS é extremamente intensivo em RAM. Como a deduplicação ocorre em tempo real à medida que os dados são transmitidos / gravados no conjunto de armazenamentos, há uma tabela mantida na memória que controla os blocos de dados. Esta é a tabela DDT . Se o seu servidor de armazenamento ZFS não tiver RAM suficiente para acomodar essa tabela, o desempenho sofrerá tremendamente. A Nexenta irá avisá-lo quando a mesa ultrapassar um certo limiar, mas aí já é tarde demais. Isso pode ser aumentado pelo uso de um dispositivo L2ARC (cache de leitura), mas muitos dos primeiros usuários do ZFS essa armadilha.

Veja:

ZFS - destruindo zvol desduplicado ou conjunto de dados bloqueia o servidor. Como se recuperar?

ZFS - Impacto da falha do dispositivo de cache L2ARC (Nexenta)

Quando digo que o requisito de RAM é alto para usar dedupe, eu estimaria as necessidades de RAM e L2ARC para o conjunto de dados que você está descrevendo em 64 GB + RAM e 200 GB + L2ARC. Isso não é um investimento menor. Manter muitos arquivos de sistema do Windows e documentos de imagem que não serão relidos irá preencher esse DDT muito rapidamente. A recompensa pode não valer o trabalho de engenharia que precisa ser adiantado.

Uma ideia melhor é usar a compactação no zpool, possivelmente aproveitando os recursos do gzip para os tipos de dados mais compactáveis. A desduplicação não valerá a pena, pois há um problema quando você precisa excluir os dados desduplicados (precisa fazer referência ao DDT).

Além disso, como você apresentará o armazenamento ao seu software de backup? Qual pacote de software de backup você usará? Nos ambientes Windows, apresento o ZFS como armazenamento em block para o Backup Exec sobre iSCSI. Eu nunca achei os recursos do ZFS CIFS robustos o suficiente e preferi as vantagens de um dispositivo formatado nativamente.

Além disso, aqui está um excelente recurso do ZFS para ideias de design. Coisas sobre o ZFS que ninguém lhe contou

    

Answer 3

Um SO alternativo é o OpenIndiana, que é igualmente bom e recebe atualizações mais freqüentes por algum tempo.

Outra opção é configurar um segundo servidor ZFS com um pool de armazenamento (potencialmente) menor com a compactação ativada. Você pode usar este segundo dispositivo para backups estáticos. Você pode dispensar o cache de leitura e também não precisa de quantidades bobas de CPU / RAM para lidar com isso.

Nós executamos uma configuração assim onde eu trabalho:

• Servidor de armazenamento principal OpenIndiana [ main ] com seis discos de 2 TB em um pool RaidZ1 de três conjuntos de pares espelhados. Isso, ao cortar o espaço de armazenamento disponível, cria um pool de armazenamento rápido e com redundância múltipla.
• Um servidor de armazenamento secundário [<>> backup ] também executando o OpenIndiana com uma configuração semelhante de discos que serve apenas como um dispositivo de backup.
• main tem um script que é executado a partir de um trabalho cron que snapshots / tank / [dataset] regularmente ao longo do dia
• Todas as noites, outra tarefa do cron é executada e envia os instantâneos do dia pela rede para backup . Assim que a sincronização inicial de todos os seus instantâneos estiver concluída (um procedimento único), a natureza incremental dos instantâneos significa que as alterações são enviadas para o dispositivo de backup muito rapidamente.

Eu tenho um breve resumo sobre como equipar o envio / recebimento do ZFS aqui: link