Enviei uma grande quantidade de dados de uma máquina para outra. Se eu enviar com rsync (ou qualquer outro método), ele estará em 320kb / s. Se eu iniciar duas ou três transferências de uma só vez, cada uma irá para 320, e se eu fizer quatro de uma vez, elas irão maximizar o link.
Eu preciso enviar dados o mais rápido possível, então preciso de uma ferramenta que possa fazer multiplexação inversa com transferências de arquivos. Eu preciso de uma solução geral, de modo que correr na máquina de origem e colocá-los juntos no outro lado não é prático. Preciso que isso funcione de maneira automatizada.
Existe uma ferramenta que faz isso, ou eu preciso fazer o meu próprio? O remetente é o CentOS, o receptor é o FreeBSD.
Prova disso tudo - eu apresento o 'santo graal' dos comandos espelhados remotos. Obrigado a davr pela sugestão lftp .
lftp -c "mirror --use-pget-n=10 --verbose sftp://username:[email protected]/directory"
O acima irá espelhar recursivamente um diretório remoto, dividindo cada arquivo em 10 threads à medida que ele for 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ê queira transferir um arquivo do remoteServer para o 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.
Em seguida, há muitas ferramentas de 'acelerador de download', mas elas geralmente suportam apenas HTTP ou FTP, que talvez você não queira configurar no servidor remoto. Alguns exemplos são Axel , aria2 e ProZilla
Se você tiver poucos e grandes arquivos, use lftp -e 'mirror --parallel=2 --use-pget-n=10 <remote_dir> <local_dir>' <ftp_server> : você baixará 2 arquivos com cada arquivo dividido em 10 segmentos com um total de 20 conexões de ftp para <ftp_server> ;
Se você tiver uma grande quantidade de arquivos pequenos, use lftp -e 'mirror --parallel=100 <remote_dir> <local_dir>' <ftp_server> : você fará o download de 100 arquivos em paralelo sem segmentação. Um total de 100 conexões será aberto. Isso pode exaurir os clientes disponíveis no servidor ou você pode ser banido em alguns servidores.
Você pode usar --continue para retomar o trabalho :) e a opção -R para fazer upload em vez de fazer o download (depois, alternar a ordem dos argumentos para <local_dir> <remote_dir> ).
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 árvore de diretórios.
Tudo depende de como seus dados de origem são estruturados. Existem várias ferramentas unix para cortar, recortar e remontar arquivos.
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 não é explícita a limitação por taxa de conexão pelo ISP. Existem dois prováveis culpados pelo afogamento:
No primeiro caso, cada conexão TCP competiria, de forma eficaz, igualmente no controle de congestionamento TCP padrão. Você também pode melhorar isso alterando os algoritmos de controle de congestionamento ou reduzindo a quantidade de backoffs.
No segundo caso, você não está limitado pela perda de pacotes. Adicionar conexões extras é uma maneira bruta de expandir o tamanho total da janela. Se você puder aumentar manualmente os tamanhos das janelas, o problema desaparecerá. (Isso pode exigir dimensionamento da janela TCP se a latência da conexão for suficientemente alta.)
Você pode informar aproximadamente o tamanho da janela que precisa multiplicando o tempo "ping" de ida e volta pela velocidade total da conexão. 1280KB / s precisa de 1280 (1311 para 1024 = 1K) bytes por milissegundo de ida e volta. Um buffer de 64K será maximizado em cerca de 50 ms de latência, o que é bastante típico. Um buffer de 16K iria então saturar em torno de 320KB / s.
Se você pode configurar o login ssh sem senha, então ele abrirá 4 conexões scp simultâneas (-n) com cada conexão gerenciando 4 arquivos (-L):
find . -type f | xargs -L 4 -n 4 /tmp/scp.sh user@host:path
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 irá maximizar o seu disco e tornar a rede mais difícil. Mais rápido do que isso, é difícil ir ao atravessar a rede.
Eu conheço uma ferramenta que pode transferir arquivos em blocos. A ferramenta é chamada de pacote / porta 'rtorrent' disponível em ambos os hosts;) Os clientes de BitTorrent geralmente reservam espaço em disco antes da transferência, e pedaços são gravados diretamente de soquetes para o disco. Além disso, você poderá rever os estados de TODAS as transferências em uma boa tela ncurses.
Você pode criar scripts bash simples para automatizar a criação de arquivos "* .torrent" e enviar um comando ssh para a máquina remota para que seja baixado. Isso parece um pouco feio, mas eu não acho que você encontrará uma solução simples sem desenvolver:)
O FTP usa várias conexões para downloads. Se você puder configurar um canal seguro para FTP em uma VPN ou FTP sobre SSH , você deve conseguir maximizar o seu link de rede. (Observe que considerações especiais são necessárias para FTP sobre SSH - consulte o link.)
FTPS (FTP sobre SSL) também pode fazer o que você precisa.
Você também pode usar um cliente SFTP que suporte 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 maior parte do tempo, mas pode não dar a máxima taxa de transferência quando você só precisa transferir um arquivo grande.
Solução 1: Não tenho certeza se isso é prático no seu caso, mas você pode criar um arquivo estendido (por exemplo, um arquivo tar dividido em partes ou um arquivo 7zip estendido) e usar várias instâncias do rsync para enviá-los pela rede e remontá-los / extraí-los do outro lado. Você pode escrever um script de propósito geral cujos argumentos são 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 em ambos os 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 árvore de diretórios grande em subárvores com base no tamanho e copie essas subárvores em paralelo. Isso pode simplificar as coisas se você copiar toda a estrutura de diretórios (sem os arquivos) primeiro.
Existem dois computadores em execução em um ambiente confiável? Você poderia tentar 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é mesmo uma partição inteira pode ser movida dessa 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, mas no ambiente certo pode ser rápido porque tem uma sobrecarga tão baixa.
HowtoForge tem uma boa página de exemplos .