Copie arquivos grandes de um servidor Linux para outro

20

Estou tentando copiar um 75 gigabyte tgz (instantâneo mysql lvm) de um servidor Linux em nosso data center de LA para outro servidor Linux em nosso data center de NY por um link de 10 MB.

Estou recebendo cerca de 20-30 KB / s com rsync ou scp, que varia entre 200-300 horas.

No momento, é um link relativamente silencioso, pois o segundo data center ainda não está ativo e obtive excelentes velocidades com pequenas transferências de arquivos.

Eu segui diferentes guias de ajuste tcp que encontrei pelo google sem sucesso (talvez esteja lendo os guias errados, comprei um bom?).

Eu já vi a dica do túnel tar + netcat, mas meu entendimento é que ele é bom apenas para muitos arquivos pequenos e não atualiza você quando o arquivo é transferido com eficiência.

Antes de eu recorrer ao envio de um disco rígido, alguém tem alguma entrada boa?

UPDATE: Bem ... pode ser o link afinal :( Veja meus testes abaixo ...

Transferências de NY para LA:

Obtendo um arquivo em branco.

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

Obtendo o tarball de instantâneo.

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

Transferências de LA para NY:

Obtendo um arquivo em branco.

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

Obtendo o tarball de instantâneo.

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

Acho que vou falar com as pessoas que administram nossas instalações, o link é rotulado como um link MPLS / Ethernet de 10 MB. (dar de ombros)

Nathan Milford
fonte
Apenas um comentário, recebi recentemente uma versão de um fornecedor de software em um Seagate FreeAgent (disco USB) com cerca de 50 GBytes. A empresa em questão tinha uma presença na Web e geralmente solicitava aos clientes que simplesmente fizessem o download em seu site. Achei que era uma solução interessante e achei que isso poderia adicionar algumas informações para ajudar na sua decisão.
Mdpc 13/08/09
Que tipo de latência você está vendo?
retracile
Cerca de 80 ms no link.
Nathan Milford
Sim, agora estou apenas confuso e frustrado. Dividi em pedaços de 50mb e ainda vai devagar! Mas rsyncing outros dados fica 500kb / s ... deve haver algo terrivelmente errado ehre estou em falta ....
Nathan Milford
Inspecione seu tráfego com tcpdump. Pode ajudá-lo a descobrir o que atrasa a transferência.
lexsys 13/08/2009

Respostas:

16

Sneakernet Alguém?

Supondo que seja uma cópia única, não creio que seja possível copiar o arquivo para um CD (ou outra mídia) e durante a noite para o destino.

Essa pode ser a opção mais rápida, pois uma transferência de arquivos desse tamanho, por essa conexão, pode não ser copiada corretamente ... nesse caso, você começa novamente.


rsync

Minha segunda opção / tentativa seria o rsync, pois detecta transferências com falha, transferências parciais etc. e pode continuar de onde parou.

rsync --progress file1 file2 user@remotemachine:/destination/directory

O sinalizador --progress fornecerá algum feedback em vez de ficar sentado e deixar que você pense duas vezes. :-)


Vuze (bittorrent)

A terceira opção provavelmente seria tentar usar o Vuze como um servidor de torrent e fazer com que sua localização remota usasse um cliente bitorrent padrão para fazer o download. Conheço outras pessoas que fizeram isso, mas você sabe ... no momento em que tudo estava funcionando, etc ... Eu poderia ter passado a noite nos dados ...

Depende da sua situação, eu acho.

Boa sorte!


ATUALIZAR:

Sabe, fiquei pensando um pouco mais no seu problema. Por que o arquivo precisa ser um único tarball enorme? O Tar é perfeitamente capaz de dividir arquivos grandes em arquivos menores (para abranger a mídia, por exemplo). Por que não dividir esse tarball enorme em pedaços mais gerenciáveis ​​e depois transferi-los?

KPWINC
fonte
3
+1, embora provavelmente não seja rentável neste caso. Nunca subestime a largura de banda de um 747 cheio de discos rígidos :)
Chad Huneycutt
2
Não consegui encontrar o link, mas há alguns anos o Google procurava caixas de unidades de transporte. Se você pode mover uma caixa de unidades, totalizando 500TB do ponto A ao ponto B, qualquer maneira você cortá-la de que é algum poderoso-fino largura de banda
STW
2
Talvez você esteja se referindo a este artigo: arstechnica.com/science/news/2007/03/…
KPWINC 13/08/09
11
Sim, acabei enviando um disco rígido. O problema real, pelo que me disseram, era o controle de fluxo no (s) comutador (es).
2119 Nathan
O Bittorrent só funciona melhor do que uma transferência direta se você tiver vários semeadores. Mesmo se o OP instala o bt em várias máquinas, ele tem apenas uma conexão. E ele já determinou que vários arquivos pequenos não são mais rápidos que um grande, o que aponta a conexão de rede.
Xalorous 17/11
7

Eu fiz isso no passado, com um arquivo tbz2 de 60 GB. Não tenho mais o script, mas deve ser fácil reescrevê-lo.

Primeiro, divida seu arquivo em pedaços de ~ 2 GB:

split --bytes=2000000000 your_file.tgz

Para cada peça, calcule um hash MD5 (para verificar a integridade) e armazene-o em algum lugar, depois comece a copiar as peças e o md5 para o site remoto com a ferramenta de sua escolha (eu: netcat-tar-pipe em uma tela sessão).

Depois de um tempo, verifique com o md5 se suas peças estão bem e, em seguida:

cat your_file* > your_remote_file.tgz

Se você também fez um MD5 do arquivo original, verifique-o também. Se estiver tudo bem, você pode descompactar seu arquivo, tudo deve ficar bem.

(Se eu encontrar tempo, reescreverei o script)

edomaur
fonte
5

Normalmente sou um grande defensor do rsync, mas ao transferir um único arquivo pela primeira vez, isso não faz muito sentido. Se, no entanto, você estivesse transferindo novamente o arquivo com apenas pequenas diferenças, o rsync seria o vencedor. Se você optar por usar o rsync de qualquer maneira, eu recomendo executar uma extremidade no --daemonmodo para eliminar o túnel ssh que prejudica o desempenho. A página de manual descreve esse modo completamente.

Minha recomendação? FTP ou HTTP com servidores e clientes que oferecem suporte à retomada de downloads interrompidos. Ambos os protocolos são rápidos e leves, evitando a penalidade do túnel ssh. O Apache + wget estaria gritando rápido.

O truque do pipe netcat também funcionaria bem. O tar não é necessário ao transferir um único arquivo grande. E o motivo de não notificá-lo quando terminar é porque você não disse. Adicione um -q0sinalizador ao lado do servidor e ele se comportará exatamente como você esperaria.

servidor $ nc -l -p 5000> outfile.tgz

cliente $ nc -q0 server.example.com 5000 <infile.tgz

A desvantagem da abordagem netcat é que ela não permitirá que você retome se sua transferência morrer 74 GB em ...

Insyte
fonte
+1 para rsyncd. Na verdade, eu o uso para transferências na minha LAN, porque vejo uma taxa de transferência mais alta em comparação ao CIFS ou NFS.
Ophidian
11
Enquanto o FTP e o HTTP evitam a "penalidade de ssh-tunnel", a "penalidade" por não criptografar os dados precisa ser considerada.
25915 J.Money
3

Dê uma chance ao netcat (às vezes chamado de nc). O seguinte funciona em um diretório, mas deve ser fácil o suficiente para ajustar apenas um arquivo.

Na caixa de destino:

netcat -l -p 2342 | tar -C /target/dir -xzf -

Na caixa de origem:

tar czf * | netcat target_box 2342

Você pode tentar remover a opção 'z' no comando tar para obter um pouco mais de velocidade, pois o arquivo já está compactado.

David
fonte
1

O SCP padrão e o Rsync (que usa o SCP) são muito lentos para arquivos grandes. Eu acho que gostaria de usar um protocolo com menor sobrecarga. Você já tentou usar um codificador de criptografia mais simples ou não? Tente procurar a --rshopção do rsync para alterar o método de transferência.

Por que não FTP ou HTTP?

cmcginty
fonte
11
Eu fiz o velho "python -m SimpleHTTPServer" do commandlinefu na fonte e wget'd o arquivo no destino. Ainda recebo "18,5K / s por 15d 3h"
Nathan Milford
1

Embora isso adicione um pouco de sobrecarga à situação, o BitTorrent é realmente uma solução muito boa para transferir arquivos grandes. O BitTorrent possui muitos recursos interessantes, como agrupar nativamente um arquivo e somar cada bloco que pode ser re-transmitido se estiver corrompido.

Um programa como o Azureus [agora conhecido como Vuze] contém todas as peças necessárias para criar, servidor e baixar torrents em um aplicativo. Lembre-se de que o Azureus não é a solução mais enxuta disponível para o BitTorrent e acho que também requer sua GUI - existem muitas ferramentas de torrent orientadas por linha de comando para linux.

DisabledLeopard
fonte
bt só vai mais rápido que a transferência direta se houver várias sementes. Ele tem uma única fonte. Mais importante, ele tem uma rede de origem única com uma conexão de rede ruim. Mesmo copiar o arquivo para vários locais localmente e configurar o bt com várias sementes é contraproducente devido a essa conexão ruim. Além disso, fazer várias cópias e configurá-las como sementes está multiplicando o tempo de cópia em vez de reduzi-lo. O BT pode ser uma solução viável se o OP estiver tentando disponibilizar um arquivo grande para vários destinatários.
Xalorous 17/11
0

Bem, pessoalmente, 20-30Kb / s parece bastante baixo para um link de 10 Mb (assumindo 10 Mb e não 10 MB).

Se eu fosse você, faria uma de duas coisas (assumindo que o acesso físico não está disponível) -

Qualquer um deles, aconselho que você divida o arquivo grande em partes menores, em torno de 500 MB Apenas caso haja corrupção durante o transporte.

Quando você tiver pedaços menores, use o rsync novamente ou eu pessoalmente prefiro usar uma sessão privada de FTP seguro e, em seguida, sincronize os arquivos após a conclusão.

William Hilsum
fonte
0

Algumas perguntas podem ajudar nas discussões: Quão críticos são os dados a serem transferidos? É para recuperação de desastres, backup quente, armazenamento offline ou o quê? Você pretende fazer backup do banco de dados enquanto está ativo ou inativo? Que tal configurar um banco de dados no sistema remoto e mantê-los sincronizados usando cluster ou atualização via changelogs (eu não sou totalmente versado sobre os recursos de um sistema de banco de dados MySql). Isso pode ajudar a reduzir a quantidade de dados que precisam ser transferidos através do link.

mdpc
fonte
É um instantâneo do LVM de outra réplica do MYSQL (da nossa instância principal do MYSQL em outro lugar). Uma vez transferida e situada, a instância do mysql de destino pode simplesmente atualizar a diferença entre esse instantâneo (use-o como um delta) e onde o mestre está agora. O fato de ser um backup MYSQL não é relevante, é apenas uma grande parte dos dados que eu só preciso mover uma vez.
1811 Nathan Milford
0

O bbcp dividirá o arquivo para você e copiará com vários fluxos.

Zaur
fonte
0

Resposta tardia para os googlers:

Ao transferir conjuntos de dados grandes, o rsync pode ser usado para comparar a origem e o destino e gravar um arquivo em lotes na mídia removível local usando o sinalizador --only-write-batch. Em seguida, você envia a mídia local para o local remoto, conecta-o e executa o rsync novamente, usando --read-batch para incorporar as alterações no conjunto de dados remoto.

Se os arquivos de origem mudarem durante o transporte físico ou se a mídia de transporte ficar cheia, você poderá continuar repetindo o --only-write-batch | navio - ciclo de leitura em lote até que o destino seja capturado.

(Ref: eu fui um dos autores desse recurso no rsync - para obter mais informações e casos de uso, consulte esta discussão sobre a implementação do protótipo: https://lists.samba.org/archive/rsync/2005-March/011964 .html )

stevegt
fonte