ZFS Sincroniza a WAN lenta e não confiável. Replicação ZFS ou rsync?

Question

Recebi a tarefa de fazer um trabalho de backup fora do site pela WAN. Ambas as caixas de armazenamento são caixas NAS baseadas no FreeBSD executando o ZFS.

Uma ou duas vezes por semana, 15 a 60 GB de dados fotográficos são enviados para o NAS do escritório. Meu trabalho é descobrir como obter esses dados fora do local da maneira mais confiável possível usando a conexão DSL MUITO LENTA (~ 700Kb / s de upload). A caixa receptora está em muito melhor forma, a 30Mb / s para baixo, 5Mb / s para cima.

Eu sei, transportar um disco rígido para fora do site moveria os dados muito mais rapidamente, mas não é uma opção nesse caso.

Minhas opções parecem ser:

• Envio incremental do ZFS sobre ssh
• Rsync

O rsync é uma solução honrada pelo tempo e tem a importantíssima capacidade de retomar um envio se algo for interrompido. Tem a desvantagem de iterar muitos arquivos e não saber sobre dedup.

O envio de snapshots do ZFS pode transferir um pouco menos de dados (ele sabe muito mais sobre o sistema de arquivos, pode fazer dedup, pode compactar as alterações de metadados mais eficientemente que o rsync) e tem a vantagem de duplicar o estado do sistema de arquivos que simplesmente copiar arquivos individualmente (o que requer mais disco).

Estou preocupado com o desempenho da replicação do ZFS [1] (embora esse artigo tenha um ano). Também estou preocupado em poder reiniciar a transferência se algo ficar inativo - o recurso de instantâneo não parece incluir isso. Todo o sistema precisa ser completamente desligado.

[1] link

Usando uma das opções, eu deveria ser capaz de des-priorizar o tráfego, roteando-o através de uma porta especificada e, em seguida, usando o QOS nos roteadores. Preciso evitar um grande impacto negativo nos usuários em ambos os sites durante cada transferência, já que levará vários dias.

Então ... esse é o meu pensamento sobre o assunto. Eu perdi alguma boa opção? Alguém mais definiu algo semelhante?

    

Answer 1

1. Se você pode transferir no máximo 6GB por dia (assumindo zero sobrecarga e zero tráfego concorrente) e precisar mover "15-60 shows" com uma frequência de "uma ou duas vezes por semana", funciona com 15-120 GB por semana, ou entre 2-17 GB por dia. Como é necessário planejar a demanda de pico e 17 GB é muito mais do que seu máximo teórico de 6 GB, é provável que você tenha um problema sério de largura de banda. O que será necessário para atualizar a conexão? Se a atualização da conexão for impossível, considere a opção de enviar mídia física de maneira programada (por exemplo, semanalmente).

2. Supondo que você possa fazer com que a matemática da largura de banda faça um pouco mais de sentido, rsync provavelmente será a melhor opção. A conscientização da desduplicação seria imensamente valiosa ao replicar dados altamente redundantes (por exemplo, imagens de máquinas virtuais), mas deveria ter pouco ou nenhum benefício quando se trata de conteúdo digital exclusivo (áudio, vídeo, fotos) ... a menos que, é claro, os usuários armazenando inadvertidamente cópias duplicadas de arquivos idênticos.

Answer 2

Depois de fazer algumas pesquisas, acredito que você esteja certo sobre o envio de instantâneos. Os comandos SEND e RECEIVE do ZFS podem ser canalizados para o bzip2 e, em seguida, esse arquivo pode ser rsync-ed para a outra máquina.

Aqui estão algumas fontes que usei:

• O Guia do administrador do ZFS do Oracle Solaris página 211 (ou a versão da web aqui ) começa a falar sobre isso.

• Também encontrei uma postagem no blog que forneceu um exemplo simples disso. Este blog também mostrou o fluxo de bits através do bzip2 e o enviou.

Eu não encontrei nenhuma postagem com scripts de replicação postados, mas encontrei alguém que postou seu script de backup . Dito isso, eu não entendi, então pode ser lixo.

Muitos dos sites falaram sobre a configuração de um cron job para fazer isso com frequência. Se esse for o caso, você poderá replicar / fazer backup com menos impacto na largura de banda e nos usuários e ser um bom recurso de recuperação de desastres, pois os dados externos estão mais atualizados. (Isto é, após o bloco inicial de dados ao começar.)

Mais uma vez, acho que você teve a ideia certa ao enviar instantâneos. Parece haver muitas vantagens em usar SEND / RECEIVE .

EDIT: Apenas assisti a um video1 video2 que ajuda a suportar o uso de SEND / RECEIVE e fala sobre o rsync (começa em 3m49s). Ben Rockwood foi o orador e aqui está um link para o seu blog .

    

Answer 3

Qual é o propósito dos backups e como eles precisarão ser acessados?

Se os backups forem principalmente para recuperação de desastre, os instantâneos do ZFS poderão ser preferíveis, já que você poderá obter um sistema de arquivos de volta ao estado exato em que estava no momento do último incremental.

No entanto, se os seus backups também devem fornecer aos usuários acesso a arquivos que podem ter sido acidentalmente excluídos, corrompidos, etc., então o rsync pode ser uma opção melhor. Os usuários finais podem não entender o conceito de instantâneos ou talvez o seu NAS não forneça aos usuários finais acesso a instantâneos anteriores. Em ambos os casos, você pode usar o rsync para fornecer um backup que seja facilmente acessível ao usuário por meio do sistema de arquivos.

Com o rsync, você pode usar o sinalizador --backup para preservar os backups dos arquivos que foram alterados e, com o sinalizador --suffix, você pode controlar como as versões antigas dos arquivos serão renomeadas. Isso facilita a criação de um backup em que você pode ter versões antigas de arquivos como

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Você pode combinar isso facilmente com um cronjob contendo um comando find para limpar todos os arquivos antigos, conforme necessário.

Ambas as soluções devem ser capazes de preservar metainformation suficiente sobre os arquivos para funcionar como backup (o rsync fornece sinalizadores --perms, --owner etc.). Eu uso o rsync para fazer backup de grandes quantidades de dados entre os datacenters e estou muito feliz com a configuração.

    

Answer 4

O ZFS deve receber o recurso 'envio recuperável', que permitirá a continuação de uma replicação interrompida em algum momento próximo a março deste ano. O recurso foi completado por Matt Ahrens e algumas outras pessoas, e deve ser enviado em breve.

    

Answer 5

Talvez o dispositivo de compactação WAN seja uma solução ...? usamos Riverbed e estamos muito felizes com eles (por exemplo, o NetApp SnapMirror está sendo muito bem compactado, até 80-90%)