Backup Rápido pela Internet

Question

Desejamos instalar alguns servidores em um datacenter remoto para atuar como um local de armazenamento de backup para nosso datacenter principal.

Assumindo que ambos os sites terão conectividade GigE, qual é o melhor método para usar na transferência rápida de arquivos? Eu amo o rsync, no entanto, como temos muitos dados para transferir (1,5 TB por noite), acho que o protocolo SSH usado no rsync pode atrasar bastante as coisas: (

Poderíamos instalar alguns terminais de VPN rápidos para atender à criptografia de links, no entanto, a questão ainda permanece: qual é a melhor ferramenta para a transferência real?

    

Answer 1

o desempenho do backup é determinado por vários fatores. Largura de banda sendo uma delas.

• Desempenho de gravação de armazenamento

Frequentemente determinado pelo desempenho de gravação de armazenamento.

• Largura de banda de rede

Uma boa opção é executar o rsync no modo daemon no servidor de backup, fazendo isso você evitaria o ssh. No entanto, a menos que você esteja tendo realmente processadores lentos, a sobrecarga do ssh não seria significativa.

Para executar o rsync como o daemon iniciar o daemon rsync no servidor

  rsync --daemon 

Por padrão, ele escuta na porta TCP 873 e você pode alterá-lo no rsyncd.conf.

Em seguida, use o rsync como

 rsync [OPTIONS] source-path \
          rsync://backup_username@backup-server:873:destination-path

Não há informações suficientes para fornecer uma estimativa do desempenho esperado. No entanto, a adição diária de 1,5 TB não é impossível.

• IOPS de armazenamento

Durante o backup, você combina operações de gravação com várias operações do sistema de arquivos. Consultas e atualizações do sistema de arquivos. Geralmente, é uma boa ideia executar vários processos de rsync para ocultar a latência da criação de arquivos.

    

Answer 2

Você pode querer examinar o software de aceleração de arquivos. Eu acho que há muitos jogadores nesse mercado, mas o que eu vi usado no passado foi aspera. Aqui está uma página comparando aspera sync para rsync (tabelas de comparação na parte inferior da página).

link

    

Answer 3

Além disso, certifique-se de que nenhum dos lados envolvidos use versões realmente antigas do rsync. Ainda existem versões 2.x em uso, estas fazem com que toda a cadeia volte para uma versão mais antiga e, em alguns casos, muito menos eficiente do protocolo (Se você for informado "enviando lista de arquivos incrementais", você está bem. Se for "enviando lista de arquivos", que é o protocolo 2.x usado.)

    

Answer 4

Acho que o delta / dia de 1,5 TB está um pouco fora do tamanho típico para soluções como o rsync. O SSH tem um limite arquitetônico de cerca de 2-3MB / s IIRC e, conforme escrito antes, o protocolo rsync padrão é muito mais rápido, mas não criptografado.

Você deve realmente dar uma olhada nas soluções projetadas especificamente para sincronizar essas quantidades de dados. O que eu trabalhei no passado são os dispositivos Quantum DXi que são dispositivos de armazenamento, mas também oferecem desduplicação e replicação criptografada. Você pode querer dar uma olhada nelas.

/ edit: Para estender um pouco mais minha afirmação acima, é importante levar em consideração as seguintes considerações ao medir a velocidade do SSH:

• O problema de velocidade ocorre devido à estrutura do buffer interno do SSH porque ele não foi originalmente desenvolvido para transferir grandes quantidades de dados pela WAN (leia aqui para mais detalhes e uma possível solução
• Leve em consideração o RTT. Por causa do problema do buffer, o desempenho sobre a WAN (que é o que o TO pergunta) pode ser muito pior do que no gigabit local, mesmo quando se adiciona apenas 10ms de RTT
• Compactação: uma empresa de hospedagem terá muitos arquivos que não podem mais ser compactados, como downloads que já foram compactados, filmes, imagens etc. Isso reduz a taxa de transferência geral, já que não é possível reduzir os dados para 20% ou menos, eu estimo que você pode calcular com topos de taxa de compressão de 50%.
• Contagem de arquivos / compactação: você obviamente não pode criar um único arquivo de 1,5 TB e sincronizar isso. Por quê? Porque se um byte deste arquivo estiver corrompido (devido a qualquer motivo), todo o backup poderá ser inútil. Então você teria que dividir os deltas para talvez um arquivo por cliente, o que adiciona sobrecarga à transferência e também piora a taxa de compactação

A grande vantagem da desduplicação aqui é que os dados são desduplicados em um nível de bloco. Ou seja, se você criar um tar (não compactado!) Por cliente e colocar um dos dispositivos DXi em seu site principal, este appliance automaticamente eliminará blocos duplicados no fluxo de arquivos (por exemplo, 100 clientes têm o mesmo filme em seu tar - só será armazenada uma vez e será referenciada as outras 99 vezes), e os blocos também serão compactados.

Se você adicionar um segundo fora do local, somente os blocos de dados exclusivos serão transferidos para o segundo appliance. Com isso, você poderia, de fato, realizar backups diários completos em seu site principal e apenas o tamanho de blocos únicos recém-gravados teria que ser transferido pela WAN para o local externo

    

Answer 5

alguém mencionado aqui usando o daemon rsync - esta é uma solução muito mais leve do que encapsular o tráfego sobre o ssh. mas mesmo com o encapsulamento ssh transferindo 1.5TB durante a noite e saturando o link gigabit deve ser factível.

assumindo que você tem poucos arquivos grandes [suposição possivelmente errada] - você deve ser capaz de transferir a carga dentro de ~ 5h. Eu fiz um teste rápido:

server:/mnt/big/tmp# rsync -av --progress root@otherServer:/big/file ./
receiving incremental file list
file
  1849044309 100%   74.47MB/s    0:00:23 (xfer#1, to-check=0/1)

sent 30 bytes  received 1849270109 bytes  75480413.84 bytes/sec
total size is 1849044309  speedup is 1.00

informando ao ssh para usar o método de compactação mais leve:

server:/mnt/big/tmp# rsync -e "ssh -c arcfour" -av --progress root@otherServer:/big/file ./
receiving incremental file list
file
  1849044309 100%  106.70MB/s    0:00:16 (xfer#1, to-check=0/1)

sent 30 bytes  received 1849270109 bytes  112076978.12 bytes/sec
total size is 1849044309  speedup is 1.00

supondo que o armazenamento não seja um gargalo - 106MB / s ~ = 350GB / h ~ = 1.5TB em 5h.

ambos os testes foram feitos em máquina inativa com xeon E5430 @ 2.66GHz cpu.

para tornar as coisas mais eficientes [faça uso de múltiplos núcleos se você tiver uma CPU mais lenta] ou apenas use melhor largura de banda disponível e IO - você pode executar algumas sessões rsync paralelas para alguns arquivos.

Eu não sei se você possui / aluga a fibra ou apenas usa o serviço mpls fornecido pelo operador, independentemente de que o ssh oferece a você um benefício adicional de criptografia strong sem definir a vpn intermediária.