Distribuição centralizada / sincronização de conjuntos de arquivos grandes através da rede local

Question

Mesmo sabendo que versões desta pergunta foram feitas a googol várias vezes, vou tentar não repeti-los.

Eu tenho muitos conjuntos de muitos arquivos (alguns arquivos são pequenos, mas alguns são grandes, como ~ 10 a 20GB). Eu tenho vários servidores, cada um pode hospedar um ou mais desses conjuntos de arquivos. É claro que um servidor pode hospedar 50% do número total de conjuntos e outros 50% podem hospedar outro número de conjuntos.

Você pode pensar em conjunto a partir da coleção de grandes arquivos de mídia, bibliotecas de imagens realmente grandes, aplicativos completos, o que realmente não importa, contanto que existam arquivos grandes no conjunto .

O servidor pode atualizar sua cópia do conjunto a qualquer momento (seja substituindo arquivos no conjunto por arquivos completamente novos ou aplicando patches em alguns arquivos, o que resultaria em ter quase os mesmos arquivos com pequenas diferenças) .

Por outro lado, eu tenho muitos clientes, que devem ser capazes de obter qualquer conjunto (ou vários conjuntos) de servidores, e manter suas cópias de conjuntos atualizados (sincronizados) com conjuntos no servidor, sempre Ninguém quer usar o conjunto.

As ferramentas que considero seguem:

• rsync - É ótimo para sincronizar muitos arquivos de pequeno a médio porte, mas não é tão ideal ao sincronizar arquivos grandes, pois usa um algoritmo que lê arquivos inteiros em ambos os lados para determinar se o arquivo deve ser copiado ou não. Está tudo bem quando o arquivo deve ser copiado pela primeira vez, ou quando o arquivo é completamente alterado, mas não tão bem, quando, digamos, apenas 1% do arquivo de 10GB é alterado.
• SVN - É ótimo quando se trata de encontrar diferenças e transferir apenas esses deltas, mas não tenho certeza de como é ótimo quando se trata de uso de disco (o conjunto inteiro será duas vezes maior em cliente e servidor, uma vez que uma vez definido é armazenado no repositório?).
• Torrent - Este pode ser viável, em termos de distribuição. Por exemplo, crie um torrent para cada conjunto no servidor, comece a propagá-lo para lá e os clientes que receberem esses conjuntos também continuarão a propagar para outros clientes, distribuindo assim a carga em todos os computadores que contêm cópia do conjunto. No entanto, não tenho certeza se seria capaz de distribuir as diferenças de alguma forma, uma vez definido no servidor é alterado ... Seria necessário a criação de nova torrent para cada alteração? Além disso, eu não sei como o torrent se comportaria na rede local, em termos de velocidade (ele poderia transferir arquivos entre um servidor e um cliente no máximo, velocidade limitada pela rede ou adicionar alguma sobrecarga de protocolo séria? congestão de rede?)
• Solução personalizada. Bem, não há muito a acrescentar aqui, mas é muito provável que ele esteja reinventando a roda e que algumas soluções existentes provavelmente atendem às minhas necessidades, se eu soubesse disso.

Então, a questão é: qual método de distribuição / sincronização (utilitários, abordagem) seria mais adequado para minha situação?

    

Answer 1

No final, escolho o BitTorrent. Aqui está o porquê.

• É rápido: satura completamente o uplink do servidor (embora, ele realmente reduza a velocidade de rede nos computadores envolvidos devido à quantidade insana de pacotes minúsculos, que podem ser um pouco otimizados ao desativar o uso de pacotes UDP).
• É realmente bom e rápido para distribuir qualquer conjunto de alterações em qualquer conjunto de arquivos (a menor unidade de dados do protocolo BT é uma "peça", que varia de 4 KB a 4 MB e o arquivo é dividido em partes, as partes são soma de verificação e somente partes diferentes são transferidas, se o arquivo em questão tem tamanho de KB ou GB - isso é feito muito rapidamente).
• Ele é totalmente distribuído: você pode hospedar muitos conjuntos de arquivos de vários servidores de origem diferentes e fazer com que os clientes recuperem arquivos, independentemente de onde eles estejam armazenados (como um ponto discutível, eu sei).
• Depois que o servidor envia sua cópia de conteúdo para a rede, a carga do servidor cai drasticamente e o tempo para o cliente recém-implantado receber conjuntos atualizados é reduzido drasticamente, pois os conjuntos são recebidos de toda a rede de computadores, em vez de , servidor centralizado.
• Ele pode ser usado em pequenas instalações com nada mais do que o programa cliente uTorrent adequadamente configurado, que pode ser usado tanto para criar .torrent, rastrear sementes / peers e para receber dados em computadores clientes.

Sobre os dois únicos contras que encontrei:

• A criação de torrents para conjuntos de big data pode levar muito tempo (muito: 5 a 10 minutos), enquanto o .torrent é criado (o conjunto inteiro é lido, dividido em partes, soma de verificação) não estão disponíveis localmente, mas sim da rede. Além disso, a mesma quantidade de tempo é necessária quando se deseja distribuir uma quantidade arbitrária de alterações em um grande conjunto - cada computador - servidor e todos os clientes - precisa fazer parte da soma de verificação, o que, como eu disse, pode ser demorado. (Devo observar aqui que, no meu caso, as alterações eram muito pequenas e seria impraticável copiar GB de dados em torno de apenas alguns MB de dados alterados, portanto, essa é uma solução muito aceitável.)
• Pode demorar um pouco até que a semeadora inicial suba a velocidade máxima, então este método não é adequado se você precisar simplesmente copiar arquivos entre menos de 5 computadores (mas, na verdade, os benefícios podem ser notados até mesmo com 2-3 computadores).

Aí vai, espero ter ajudado alguém que enfrenta o mesmo dilema.

    

Answer 2

Se você puder presumir com segurança que todos os clientes terão versões consistentes, você poderá usar uma ferramenta de correção binária pronta para uso e aplicar sua própria solução para distribuir os diffs para os clientes e aplicá-los. Se os clientes tiverem versões inconsistentes, você terá que ler o arquivo no cliente para determinar quais os diffs que precisam ser enviados (basicamente o problema do rsync). Se os clientes são consistentes, você pode simplesmente calcular os diffs uma vez e enviá-los para fora.

Parece que você está procurando algo como uma implementação do multicast rsync . Eu nunca usei essa ferramenta, mas valeria a pena olhar. Parece que eles estão segmentando apenas o Linux e o Unix OS agora.

    

Answer 3

Você pode experimentar o armazenamento em cache de sistemas de arquivos de rede:

• link
• link

Eles armazenam em cache as leituras e gravações localmente e, como tal, não são compatíveis com o desempenho da rede, se você tiver espaço local suficiente para o cache.

    

Answer 4

Você pode usar o Windows Storage Server 2008, ele é vendido com um dispositivo NAS de provedores diferentes, mas é muito bom e eficaz, com armazenamento de instância única também economiza alguns GBs. Você pode então ter um dispositivo dedicado servindo esses arquivos grandes.

A maioria desses NAS vem com Dual Nic e você também pode obter o Quad Port nics, portanto, se você tiver uma infraestrutura Gigabit ou Lan maior, poderá agrupar / agrupar essas portas para fornecer mais taxa de transferência.

Coloque mais memória RAM e você deve estar pronto, www.broadberry.com link

A Dell também vende o Window Storage Server, obtenha o que possui iscsi para que você possa utilizar o armazenamento, caso tenha também via iscsi posteriormente.

Espero que ajude