Distribuir arquivos terrabytes para o público a partir do servidor da web

Question

Precisamos criar um site que disponibilize publicamente dois ou três arquivos grandes - os arquivos terão 1 ou 2 terrabytes cada. Embora sejam públicos, na prática, espero que apenas um número relativamente pequeno de cientistas queira baixá-los. Qual é a melhor maneira de permitir isso?

Eu tive uma conversa rápida com um provedor de hospedagem na web (rackspace) e eles sugeriram uma solução híbrida.

• Um servidor gerenciado de nível de entrada (prevemos tráfego razoavelmente baixo para o site, mas precisamos instalar algum software CGI personalizado).
• Algum armazenamento em nuvem que se conecta à Limelight Networks. Isso hospedaria os arquivos grandes, para download por FTP.

Pareceu-me bem, mas sei relativamente pouco sobre a administração do servidor. Faz sentido?

Obrigado antecipadamente, Mark

    

Answer 1

Um ou dois arquivos terabytes?

Uau ... bem, sim, se são arquivos públicos, usar uma rede de distribuição de conteúdo para distribuir faria sentido. Você também pode considerar, se outras organizações estiverem dispostas a usá-las e suas informações úteis, hospedando-as como uma torrente, já que isso é ótimo para espalhar arquivos grandes em múltiplas fontes e agir como um tipo de anti-vírus embutido. verificação de corrupção. Seria péssimo para alguém baixar um terabyte de dados e fazer com que o MD5 mostre que está corrompido.

    

Answer 2

Existem pessoas com experiência em servir coisas semelhantes ao que você está pedindo.

• Terra visível
• Arquivo Nacional de Modelo Operacional e Sistema de Distribuição

Se você estiver trabalhando em um centro da NASA, precisará obter uma autorização para poder usar peer-to-peer; isso vale tanto para o servidor quanto para os usuários, portanto, apenas tornar os dados disponíveis via p2p pode torná-los efetivamente inacessíveis para alguns cientistas (a menos que estejam dispostos a passar por isso.

Pessoalmente, quando as pessoas pedem grandes quantidades de nossos dados (são imagens e cubos de dados, com a maioria dos arquivos abaixo de 100MB), se estiver sob alguns GB, tenho alguns CGIs que geram arquivos tarballs / zip em tempo real . Estávamos olhando para escrever nosso próprio gerenciador de downloads, mas estou pensando em ir mais genérico e escrever um BagIt interface para servir Sacos não preenchidos e um cliente para preencher os Sacos & verificando-os.

Para os dados do tamanho que você está falando, temos pessoas que nos enviam discos rígidos, formatamos e enviamos de volta. As probabilidades são de que eles precisarão de espaço em disco para armazená-lo quando baixá-lo, e isso só acontece algumas vezes por ano, então é mais eficaz para nós do que pagar por mais largura de banda. (Acabamos de receber uma remessa ontem de 7 drives de 2TB para alguém que deseja os dados completos para dois dos instrumentos cujos dados nós arquivamos aqui).

... e eu também tento me certificar de não gerar arquivos maiores que 2GB ... eles ficam muito difíceis de lidar e você começa a encontrar problemas com sistemas operacionais e sistemas de arquivos mais antigos.

...

E se alguém tiver alguma recomendação sobre limitação de largura de banda e conexão com um determinado IP dentro do Apache, eu ficaria grato - a cada poucos dias eu faço com que alguém da China abra todas as conexões disponíveis para extrair dados de nossos sistemas . Eu vi mais de 800 por vez. (os firewalls são gerenciados por outro departamento, e eles bloqueiam os IPs, mas não controlam)

...

Você também pode querer perguntar na lista de discussão Informática em Ciências da Terra e do Espaço - mesmo que não seja o seu campo, Estamos todos interessados em problemas de distribuição de dados.

    

Answer 3

Arquivos Terabyte, como em um tebibyte, 1024 gibibytes, em HTTP? Não faça isso.

Eu sugeriria examinar quais plataformas (sistemas operacionais) os consumidores esperados desses arquivos usam. Se for o Windows, então o 7-Zip gratuito pode compactar o arquivo e dividir o arquivo de saída resultante em vários menores ( digamos 3.9 arquivos de tamanho GiB). No Unix, o GNU TAR pode fazer o mesmo por você; ou você pode usar o 7-Zip novamente, mas a maioria dos usuários Unix pode não ter instalado.

Esses arquivos menores podem ser transferidos e descompactados no destino. Se uma parte do arquivo for corrompida durante a transferência, somente aquele arquivo menor precisará ser baixado novamente . E se o download do arquivo levar dias para ser concluído, o usuário pode desligar o computador sempre que um arquivo menor tiver sido baixado por completo e continuar o download dos arquivos restantes posteriormente. Por fim, usar um arquivo compactado oferece verificação de erros incorporada.

A desvantagem é que durante a compactação & descompactar o espaço livre dos usuários em seus discos rígidos correspondendo a ~ 2x o tamanho do arquivo.

Você pode usar FTP ou HTTP simples para transferir os arquivos menores. FTP seria a minha escolha, mas usuários menos inclinados tecnicamente podem não ter um cliente FTP, e prefeririam HTTP. Pode ser uma boa idéia escrever um FAQ ou uma lista de problemas comuns - sistemas de arquivos mais antigos e programas de FTP geralmente não podem manipular arquivos maiores que 4 gibibytes (cabeçalhos de 32 bits).

Editar: +1 para a sugestão de Joe H de sneakernet os arquivos. O envio de unidades de disco rígido por correio / correio é mais rápido & mais barato do que transmitir pela Internet, a menos que todos os envolvidos tenham canais de Internet grandes .

    

Answer 4

Concordo com as sugestões de sneakernet (ou mabye postmailnet?). O envio de um disco rígido (ou dois) pode ser muito mais rápido e barato.

Mas e se os arquivos mudarem com o tempo? talvez cada mês seja um conjunto diferente de arquivos e seus usuários querem ficar atualizados?

Nesse caso, a melhor solução seria enviar pela mídia física pela primeira vez e depois baixar as diferenças.

para conseguir isso, há algumas sugestões óbvias:

• publique as diferenças, talvez usando o rdiff para gerar arquivos de patch binários. contras: se o usuário não atualizar todas as vezes, então tem que aplicar todos os patches que ele perdeu para recuperar o atraso. a menos que você publique diferenças contra n-1, n-2, n-3, etc.
• sugira que seus usuários usem o rsync, dessa forma, não importa se o usuário não está atualizado. contras: seu servidor tem que suportar rsync.
• use o zsync (meu favorito): você publica seus arquivos grandes e um arquivo de 'assinatura' para cada um. o cliente faz o download do arquivo de assinatura, calcula o que será necessário e baixa apenas as partes do arquivo grande (usando HTTP range headers para fazer downloads parciais). cons: szync website parece desatualizado, você terá que testá-lo completamente sozinho.

Answer 5

Um fator flexível a considerar é como limitar os downloads. Recomendamos que você tenha uma página de sinalização que forneça a chave necessária para fazer o download e que essa chave seja válida por x dias. Você pode deixá-los fazer o download novamente depois de um segundo registro, etc., mas isso evitará que as pessoas o utilizem como um arquivo de download de teste ou algo parecido.

Se houver duas chaves ao mesmo tempo, você pode ter uma fila, isso controlará a quantidade de downloads simultâneos.

Eu lembro que o site da NASA usou algo assim para grandes imagens de mármore azul (talvez ainda existam).

Além disso, se você não usar a solução de torret, eu dividiria o arquivo em mandris de 1 GB. Eu acho que é isso que Akami faz pelos grandes downloads da Microsoft. Eles fazem isso automaticamente, mas como esses são cientistas, você provavelmente pode ter instruções sobre como se juntar a eles.

    

Answer 6

Você desejará um CDN que ofereça controles de acesso do usuário e um gerenciador de upload / download baseado em java.

Isso consertará três coisas:

• Eles hospedarão seu conteúdo globalmente e de vários pontos resilientes. Isso servirá melhor para seus clientes.
• Os clientes precisarão configurar contas antes de fazer o download, isso dá a você a rastreabilidade e garante que as pessoas não desperdicem largura de banda iniciando downloads que não têm intenção de concluir.
• Um cliente Java com suporte a vários sistemas operacionais usará normalmente o protocolo HTTP confiável em lotes para preencher o download completo e lidar com subtransferências truncadas - normalmente, eu odeio esse tipo de coisa (pense no adode downloader), mas eles ter seu lugar para transferências tão grandes.

Então fale com os grandes CDNs (Akamai etc.) e peça por isso.