Maneira rápida de copiar um arquivo grande em uma LAN

21

Estou tendo alguns problemas com o NFS e gostaria de tentar usar apenas TCP antigo.

Não sei por onde começar, no entanto.

Em termos de hardware, estou usando um cabo crossover de ethernet para conectar em rede dois netbooks.

Para fazer a rede, eu digito

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

no primeiro netbook e

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

no segundo

onde /mnt/network1 é especificado em / etc / fstab como

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

, bem como em /etc/exports (usando a sintaxe desse arquivo), no primeiro netbook.

O acima funciona bem, mas os arquivos e diretórios são enormes. Os arquivos têm em média cerca de meio gigabyte por peça, e os diretórios estão entre 15 e 50 gigabytes.

Estou usando rsync para transferi-los e o comando (em 192.168.1.2 ) é

$ rsync -avxS /mnt/network1 ~/somedir

Não tenho certeza se existe uma maneira de ajustar minhas configurações de NFS para lidar melhor com arquivos grandes, mas gostaria de ver se a execução de um daemon rsync sobre TCP antigo funciona melhor que rsync sobre NFS.

Então, para reiterar, como configuro uma rede semelhante com o TCP?

ATUALIZAÇÃO:

Então, depois de algumas horas tentando me livrar do pântano da minha própria ignorância (ou, como gosto de pensar, me recompondo com minhas próprias botas), eu inventei algumas fatos.

Mas antes de tudo, o que me levou nesta trilha de coelho, em vez de simplesmente aceitar a melhor resposta atual, foi: nc é um programa inacreditavelmente legal que resolutamente não funciona para mim. Eu tentei os pacotes netcat-openbsd e netcat-traditional sem sorte alguma.

O erro que recebo no aparelho receptor ( 192.168.1.2 ) é:

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route dá:

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

Mas, eis a boa notícia: ter os endereços IP estáticos definidos em /etc/network/interfaces , que comecei a fazer ao tentar obter nc funcionando, corrigi todos os meus problemas de NFS e reacendi meu amor pelo NFS.

A configuração exata que usei (com 192.168.1.1 para o primeiro netbook, é claro) foi:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

Com essas configurações, os dois netbooks poderão fazer ping uns aos outros diretamente após serem inicializados, mesmo sem um ifup .

De qualquer forma, eu ainda gostaria muito de ver nc em ação, então espero que alguém me ajude a depurar esse processo.

    
por ixtmixilix 17.09.2012 / 14:06

3 respostas

36

O caminho rápido

A maneira mais rápida de transferir arquivos em uma LAN provavelmente não é o rsync, a menos que haja poucas mudanças. O rsync gasta um bom tempo fazendo somas de verificação, calculando diferenças, etc. Se você sabe que vai transferir a maioria dos dados de qualquer maneira, faça algo assim (note: existem várias implementações de netcat ; o manual para as opções corretas. Em particular, o seu pode não querer o -p ):

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

Isso usa o netcat ( nc ) para enviar tar sobre uma conexão TCP bruta na porta 1234. Não há criptografia, verificação de autenticidade, etc., portanto é muito rápido. Se sua conexão cruzada estiver sendo executada em gigabits ou menos, você conectará a rede; se mais, você vai ligar o disco (a menos que você tenha uma matriz de armazenamento ou disco rápido). Os v sinalizadores para tar fazem com que ele imprima os nomes dos arquivos à medida que vão sendo usados (modo detalhado). Com arquivos grandes, praticamente não há sobrecarga. Se você estivesse fazendo milhares de arquivos pequenos, desligaria isso. Além disso, você pode inserir algo como pv no pipeline para obter um indicador de progresso:

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

É claro que você pode inserir outras coisas, como gzip -1 (e adicionar o z sinalizador na extremidade de recebimento - o sinal z na extremidade de envio usaria um nível de compactação maior que 1, a menos que você defina a variável de ambiente GZIP, é claro). Embora o gzip provavelmente seja mais lento, a menos que seus dados sejam realmente compactados.

Se você realmente precisa do rsync

Se você está realmente transferindo apenas uma pequena parte dos dados que foram alterados, o rsync pode ser mais rápido. Você também pode querer olhar para a opção -W / --whole-file , como em uma rede realmente rápida (como uma conexão cruzada) que pode ser mais rápida.

A maneira mais fácil de executar o rsync é por meio do ssh. Você vai querer experimentar com cifras ssh para ver qual é o mais rápido, será AES, ChaCha20 ou Blowfish (embora existam algumas preocupações de segurança com o tamanho de bloco de 64 bits do Blowfish), dependendo se o chip tiver o AES da Intel -NI instruções (e seu OpenSSL usa-los). Em um ssh novo o suficiente, o rsync-over-ssh se parece com isso:

user@source:~$ rsync -e 'ssh -c [email protected]' -avP /source/ user@dest-ip:/target

Para ssh / sshd mais antigo, experimente aes128-ctr ou aes128-cbc em vez de [email protected] .

ChaCha20 seria [email protected] (também precisa de um novo ssh / sshd) e Blowfish seria blowfish-cbc. O OpenSSH não permite a execução sem uma cifra. É claro que você pode usar qualquer uma das opções de rsync que você preferir no lugar de -avP . E, claro, você pode ir na outra direção e executar o rsync da máquina de destino (pull) em vez da máquina de origem (push).

Tornando o rsync mais rápido

Se você executar um daemon rsync, poderá se livrar da sobrecarga de criptografia. Primeiro, você criaria um arquivo de configuração do daemon ( /etc/rsyncd.conf ), por exemplo, na máquina de origem (leia a página do manual rsyncd.conf para obter detalhes):

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

Então, na máquina de destino, você executaria:

user@dest:~$ rsync -avP source-ip::big-archive/ /target

Você pode fazer o inverso também (mas é claro que precisará definir somente leitura como não). Existem opções para autenticação, etc., verifique a página de manual para detalhes.

    
por 17.09.2012 / 20:14
16

Como? Ou TL; DR

O método mais rápido que encontrei é uma combinação de tar , mbuffer e ssh .

Por exemplo:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Usando isso, obtive transferências sustentadas de redes locais acima de 950 Mb / s em links de 1 Gb. Substitua os caminhos em cada comando tar para ser apropriado para o que você está transferindo.

Por quê? mbuffer!

O maior gargalo na transferência de arquivos grandes em uma rede é, de longe, E / S de disco. A resposta para isso é mbuffer ou buffer . Eles são muito semelhantes, mas mbuffer tem algumas vantagens. O tamanho padrão do buffer é de 2 MB para mbuffer e 1 MB para buffer . Buffers maiores são mais propensos a nunca estarem vazios. A escolha de um tamanho de bloco que seja o menor múltiplo comum do tamanho de bloco nativo no sistema de arquivos de destino e de destino proporcionará o melhor desempenho.

O armazenamento em buffer é o que faz all a diferença! Use-o se você o tiver! Se você não tem, pegue! Usar (m}?buffer mais qualquer coisa é melhor do que qualquer coisa sozinha. é quase literalmente uma panacéia para transferências lentas de arquivos em rede.

Se você estiver transferindo vários arquivos, use tar para agrupá-los em um único fluxo de dados. Se for um único arquivo, você pode usar o cat ou o redirecionamento de E / S. A sobrecarga de tar vs. cat é estatisticamente insignificante, então eu sempre uso tar (ou zfs -send onde eu puder) a menos que já seja um tarball . Nenhum destes é garantido para dar-lhe metadados (e em particular cat não). Se você quiser metadados, deixarei isso como um exercício para você.

Finalmente, usar ssh para um mecanismo de transporte é seguro e carrega muito pouca sobrecarga. Novamente, a sobrecarga de ssh vs. nc é estatisticamente insignificante.

    
por 19.09.2012 / 02:15
0

Você nem precisa usar o TCP. O AoE é uma implementação do ATA sobre Ethernet, sendo a camada 2 uma abordagem de baixa sobrecarga sem o conhecimento da pilha TCP / IP. Ele fornecerá a transferência mais rápida possível com o mínimo de sobrecarga.

link

*** se a rede é o gargalo, certifique-se de estar enviando dados compactados.

    
por 13.01.2017 / 05:09