Multiplexagem inversa para acelerar a transferência de arquivos

Enviei uma grande quantidade de dados de uma máquina para outra. Se eu enviar com o rsync (ou qualquer outro método), ele ficará a 320kb / seg. Se eu iniciar duas ou três transferências ao mesmo tempo, cada uma delas será 320, e se eu fizer quatro ao mesmo tempo, elas maximizarão o link.

Preciso enviar dados o mais rápido possível, por isso preciso de uma ferramenta que possa fazer multiplexagem inversa com transferências de arquivos. Eu preciso de uma solução geral, portanto, executar divisões na máquina de origem e agrupá-las na outra extremidade não é prático. Eu preciso que isso funcione de forma automatizada.

Existe uma ferramenta que faz isso ou preciso criar a minha? O remetente é o CentOS, o receptor é o FreeBSD.

Prova disso tudo - eu apresento o 'Santo Graal' dos comandos do espelho remoto. Obrigado a davr pela lftpsugestão.

lftp -c "mirror --use-pget-n=10 --verbose sftp://username:[email protected]/directory" 

O exemplo acima espelha recursivamente um diretório remoto, dividindo cada arquivo em 10 threads à medida que ele é transferido!

Existem algumas ferramentas que podem funcionar.

• LFTP - suporta FTP, HTTP e SFTP. Suporta o uso de várias conexões para baixar um único arquivo. Supondo que você deseja transferir um arquivo de remoteServer para localServer, instale o LFTP no localServer e execute:

  lftp -e 'pget -n 4 sftp://[email protected]/some/dir/file.ext'

  O '-n 4' é quantas conexões usar em paralelo.

• Depois, há muitas ferramentas de 'aceleração de download', mas geralmente oferecem suporte apenas a HTTP ou FTP, que talvez você não precise configurar no servidor remoto. Alguns exemplos são Axel , aria2 e ProZilla

Se você tiver poucos e grandes arquivos em uso lftp -e 'mirror --parallel=2 --use-pget-n=10 <remote_dir> <local_dir>' <ftp_server>: baixará 2 arquivos com cada arquivo dividido em 10 segmentos, com um total de 20 conexões ftp para <ftp_server>;

Se você possui uma grande quantidade de arquivos pequenos, use lftp -e 'mirror --parallel=100 <remote_dir> <local_dir>' <ftp_server>: você baixará 100 arquivos em paralelo sem segmentação. Um total de 100 conexões será aberto. Isso pode esgotar os clientes disponíveis no servidor ou banir você em alguns servidores.

Você pode usar --continuepara retomar o trabalho :) e a -Ropção de fazer upload em vez de fazer o download (alternando a ordem dos argumentos para <local_dir> <remote_dir>).

Você pode ajustar suas configurações de TCP para evitar esse problema, dependendo do que está causando o limite de 320 KB / s por conexão. Meu palpite é que ele é não taxa de conexão por explícita limitando pelo ISP. Existem dois prováveis ​​culpados pela limitação:

1. Algum link entre as duas máquinas está saturado e descartando pacotes.
2. As janelas TCP estão saturadas porque o produto de atraso da largura de banda é muito grande.

No primeiro caso, cada conexão TCP competiria efetivamente igualmente no controle de congestionamento TCP padrão. Você também pode melhorar isso alterando os algoritmos de controle congestionado ou reduzindo a quantidade de retirada.

No segundo caso, você não está limitado pela perda de pacotes. Adicionar conexões extras é uma maneira simples de expandir o tamanho total da janela. Se você pode aumentar manualmente o tamanho da janela, o problema desaparecerá. (Isso pode exigir o dimensionamento da janela TCP se a latência da conexão for suficientemente alta.)

Você pode dizer aproximadamente o tamanho da janela multiplicando o tempo de "ping" de ida e volta pela velocidade total da conexão. 1280 KB / s precisa de 1280 (1311 para 1024 = 1 KB) bytes por milissegundo de ida e volta. Um buffer de 64 K será atingido no máximo com uma latência de cerca de 50 ms, o que é bastante típico. Um buffer de 16K saturaria cerca de 320 KB / s.

Como seus dados são estruturados? Alguns arquivos grandes? Alguns diretórios grandes? Você pode gerar várias instâncias do rsync em ramificações específicas da sua árvore de diretórios.

Tudo depende de como os dados de origem estão estruturados. Existem inúmeras ferramentas unix para cortar, cortar e remontar arquivos.

Se você pode configurar o login ssh sem senha, isso abrirá 4 conexões simultâneas de scp (-n), com cada conexão manipulando 4 arquivos (-L):

encontrar . tipo f | xargs -L 4 -n 4 /tmp/scp.sh usuário @ host: caminho

Arquivo /tmp/scp.sh:

#!/bin/bash

#Display the help page
function showHelp()
{
    echo "Usage: $0 <destination> <file1 [file2 ... ]>"
}

#No arguments?
if [ -z "$1" ] || [ -z "$2" ]; then
    showHelp
    exit 1
fi

#Display help?
if [ "$1" = "--help" ] || [ "$1" = "-h" ]; then
    showHelp
    exit 0
fi

#Programs and options
SCP='scp'
SCP_OPTS='-B'
DESTINATION="$1";shift;

#Check other parameters
if [ -z "$DESTINATION" ]; then
    showHelp
    exit 1
fi

echo "$@"

#Run scp in the background with the remaining parameters.
$SCP $SCP_OPTS $@ $DESTINATION &

Tente classificar todos os arquivos no inode (find / mydir -type f -print | xargs ls -i | sort -n) e transfira-os com, por exemplo, cpio sobre ssh. Isso maximizará seu disco e tornará a rede um gargalo. Mais rápido que isso, é difícil ir ao atravessar a rede.

Conheço uma ferramenta que pode transferir arquivos em pedaços. A ferramenta é chamada de pacote / porta 'rtorrent', disponível nos dois hosts;) Os clientes BitTorrent costumam reservar espaço em disco antes da transferência, e os pedaços são gravados diretamente dos soquetes no disco. Além disso, você poderá revisar os estados de TODAS as transferências em uma bela tela de ncurses.

Você pode criar scripts simples do bash para automatizar a criação de arquivos "* .torrent" e enviar um comando ssh para a máquina remota para fazer o download. Parece um pouco feio, mas acho que você não encontrará nenhuma solução simples sem desenvolver :)

O FTP usa várias conexões para downloads. Se você pode configurar um canal seguro para FTP através de uma VPN ou FTP através de SSH , poderá maximizar o seu link de rede. (Observe que considerações especiais são necessárias para FTP sobre SSH - consulte o link.)

O FTPS (FTP sobre SSL) também pode fazer o que você precisa.

Você também pode usar um cliente SFTP que ofereça suporte a várias conexões, mas não tenho certeza se o SFTP suporta várias conexões para um único arquivo. Isso deve fazer o que você precisa na maioria das vezes, mas pode não fornecer o rendimento máximo quando você só precisa transferir um arquivo grande.

Solução 1: não sei se isso é prático no seu caso, mas você pode criar um arquivo estendido (por exemplo, um arquivo tarfile dividido em partes ou um arquivo 7zip estendido) e usar várias instâncias do rsync para enviá-las a rede e remonte / extraia-os do outro lado. Você pode escrever um script de uso geral cujos argumentos sejam o diretório a ser transferido e o número de conexões a serem usadas. A desvantagem óbvia é que você precisará do dobro de espaço livre nos dois lados e terá a sobrecarga adicional de arquivar / extrair os arquivos nas duas extremidades.

Solução 2: uma solução melhor seria escrever um script ou programa que divida a grande árvore de diretórios em subárvores com base no tamanho e depois copiá-las em paralelo. Isso pode simplificar as coisas se você copiar toda a estrutura de diretórios (sem os arquivos) primeiro.

Vocês são duas máquinas executando em um ambiente confiável? Você pode tentar o netcat . No lado do servidor:

tar -czf - ./yourdir | nc -l 9999

e no cliente:

nc your.server.net 9999 > yourdir.tar.gz

Você pode fazer com que a conexão do cliente use um túnel ssh:

ssh -f -L 23333:127.0.0.1:9999 [email protected] sleep 10; \
    nc 127.0.0.1 23333 > yourdir.tar.gz

Até uma partição inteira pode ser movida desta maneira:

dd if=/dev/sda1 | gzip -9 | nc -l 9999

e no cliente:

nc your.server.net 9999 > mysda1.img.gz

.

Nota

O netcat não é a ferramenta de transferência mais segura disponível no mercado, mas no ambiente certo pode ser rápida porque possui uma sobrecarga tão baixa.

O HowtoForge possui uma boa página de exemplos .