Transferência de arquivos de rede com vários segmentos

Question

Muitos dos links que conectam o NY e o AMS costumam estar saturados. Isso significa que executar uma transferência sobre eles (por exemplo, mover 300 GB a 1 MB / s) levaria uma idade se comparado ao que nossas conexões podem oferecer.

Eu me deparei com o problema no passado, como 3 anos atrás, quando eu era realmente novato em codificação e linux, eu cheguei à conclusão de que vou postar no final deste post. No entanto, é sujo e eu não gosto disso. O script não funciona como está, desde que foi escrito para um ambiente muito específico, no entanto, dá-lhe a ideia.

Minha pergunta é: você sabe de alguma alternativa melhor para transferir arquivos pelo oceano de maneira rápida?

#!/bin/sh

upto="$1"
filepath="$2"
remotepath="$3"

if [ ! -f ${filepath} ]
then
exit 0
fi

password=$(/all/script/password 10)
filesize=$(du -b ${2} | sed 's/\([0-9]*\)\(.*\)//')

if [ $filesize -gt 5368709120 ]; then
parts="80"
elif [ $filesize -gt 2147483648 ]; then
parts="50"
elif [ $filesize -gt 1310720 ]; then
parts="20"
else
parts="2"
fi

splitsize=$(($filesize / $parts))

split -b "$splitsize" -a 2 "$2" /all/tmp/cup/${password}_

#UPLOAD
declare -a pwait
for tmpfile in /all/tmp/cup/${password}_*
do
    scp ${tmpfile} root@${upto}.domain.com:/all/tmp/cup/ &
        array_lenght=${#pwait[@]}
        pwait[${array_lenght}]=$!
done

#ATTENDERE
for prid in ${pwait[@]}
do
wait $prid
done

#UNISCI FILE REMOTO
ssh root@${upto}.domain.com "cat /all/tmp/cup/${password}_* > ${remotepath} && wait && rm -f /all/tmp/cup/${password}_*"

#RIMUOVI ROBA DI TROPPO LA
#eval ssh root@${upto}.domain.com rm -f /all/tmp/cup/${password}*

#REMOVE HERE
rm -f /all/tmp/cup/${password}_*

exit 0

    

Answer 1

Assumindo que a sua rede está não saturada (ao contrário do que você está afirmando na pergunta), você deve ajustar seu link para lidar com o (comparativamente) alto produto de atraso de largura de banda como Andrew mencionou. (Os artigos mencionados nesse link incluem algumas informações sobre o que ajustar, quando e por quê).

Se, de fato, seus links de rede estão saturados (movendo a quantidade máxima de dados que podem), a única solução é adicionar mais largura de banda (mais troncos de fibra entre os dois sites, pagando outra portadora por trânsito para descarregar parte do pico tráfego de período, ou se você estiver usando links "dedicados" pagando por um CIR mais alto / adicionando mais circuitos ao loop).

Como você pode perceber a diferença?
Bem, se começar mais streams você ganha mais velocidade, não saturou seu link. Você provavelmente está sendo atropelado pelo tempo relativamente longo de ida e volta dos EUA para a Europa (em comparação com o tempo de ida e volta em uma rede local). (Há um ponto de retorno decrescente aqui, pois a sobrecarga para mais conexões TCP acabará causando outros gargalos para aparecer.)

Se a adição de mais fluxos não fornecer um aumento líquido na velocidade (dois fluxos são executados a metade da velocidade da rede de um) seu link estará saturado e você precisará adicionar largura de banda para melhorar o desempenho.

Outras coisas a serem consideradas

Você deve procurar minimizar os dados que estão sendo enviados pelo pipe, usando rsync ou protocolos semelhantes, se apropriado (o rsync funciona melhor com conjuntos de mudanças small-ish para grandes coleções de dados).

Nunca subestime a largura de banda de um pacote overnight da FedEx com alguns discos rígidos nele. Especialmente para sincronizações iniciais.

    

Answer 2

Eu verificaria as opções de ajuste de TCP / IP, por exemplo, dimensionamento de janela, retransmissão, tabela de roteamento e icmp. Se tudo isso estiver funcionando bem, e a pilha de rede no sistema operacional não for o Windows XP ou o Centos 5 ou algo mais antigo que o Vista, você deve estar OK da maneira que a conexão de rede multithread não é necessária. Ou, não melhoraria melhor que 20%, então, na verdade, apenas desfragmentaria o sistema de arquivos e o retardaria ainda mais.

    

Answer 3

link

A high bandwidth-delay product is an important problem case in the design of protocols such as Transmission Control Protocol (TCP) in respect of TCP tuning, because the protocol can only achieve optimum throughput if a sender sends a sufficiently large quantity of data before being required to stop and wait until a confirming message is received from the receiver, acknowledging successful receipt of that data. If the quantity of data sent is insufficient compared with the bandwidth-delay product, then the link is not being kept busy and the protocol is operating below peak efficiency for the link.

Essa é a teoria básica, mas existem fatores adicionais: dependendo do sistema operacional e das opções de ajuste TCP você pode ter grandes janelas em jogo (grandes janelas fazem com que seja mais rápido), mas alguns ISPs usam "TCP Window Manipulation" como uma ferramenta de controle de conformação e congestionamento (ou seja, uma caixa no meio sabe que algum link está congestionado e tenta saciar a fonte TCP editando os pacotes ACK para convencer a fonte que o tamanho da janela do receptor é pequeno), portanto suas janelas grandes pode não estar realmente em jogo, mesmo quando você acha que eles estão ligados.

Há mais uma coisa que pode estar acontecendo, já que as filas de pacotes se acumulam em um roteador congestionado, ele pode começar a soltar aleatoriamente os pacotes fora da fila (veja o Cisco Weighted Random Early Detection ou WRED), mas o cara usando apenas um fluxo TCP tende a recuar mais rapidamente do que o cara usando um monte de fluxos TCP paralelos, então usando múltiplos fluxos paralelos, você pode obter uma "participação" maior da largura de banda naquela fila congestionada (às custas de outros que se abstêm de esta técnica).

Existe uma ferramenta divertida chamada "tcptrace" que lhe dá visibilidade do que está acontecendo, presumindo que você pode capturar pacotes nas duas extremidades. Infelizmente você precisa trabalhar com o "xplot", que é um programa horrível, mas você pode viver com ele.