Qual é a maneira mais rápida de enviar grandes quantidades de dados entre dois computadores? [fechadas]

Esta é uma situação em que estou frequentemente:

• Eu tenho um servidor de origem com um disco rígido de 320 GB e 16 GB de RAM ( especificações exatas disponíveis aqui , mas como esse é um problema que eu encontro frequentemente em outras máquinas também, prefiro a resposta para trabalhar em qualquer máquina Linux "razoável")
• Eu tenho um servidor de backup com vários terabytes de espaço no disco rígido ( especificações exatas aqui , consulte o aviso acima)

Desejo transferir 320 GB de dados do servidor de origem para o servidor de destino (especificamente, os dados de /dev/sda).

1. Os dois computadores estão fisicamente próximos um do outro, para que eu possa passar os cabos entre eles.
2. Estou em uma LAN e estou usando um roteador novo , o que significa que a velocidade da minha rede deve "idealmente" ser de 1000Mbit, certo?
3. Segurança não é um problema. Estou em uma rede local e confio em todas as máquinas da rede, incluindo o roteador.
4. (opcional) Não preciso necessariamente de uma soma de verificação assinada dos dados, mas a verificação básica de erros (como pacotes descartados ou a unidade se tornar ilegível) deve ser detectada em vez de simplesmente desaparecer na saída.

Eu procurei esta pergunta online e testei vários comandos. O que aparece com mais frequência é o seguinte:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Este comando se mostrou muito lento (ele foi executado por uma hora, só obteve cerca de 80 GB pelos dados). Demorou cerca de 1 minuto e 22 segundos para o pacote de teste de 1 GB e acabou sendo duas vezes mais rápido quando não compactado. Os resultados também podem ter sido distorcidos pelo fato de o arquivo transferido ser menor que a quantidade de RAM no sistema de origem.

Além disso (e isso foi testado em peças de teste de 1 GB), estou tendo problemas se usar o gzipcomando e dd; o arquivo resultante possui uma soma de verificação diferente quando extraída no destino, do que se for canalizada diretamente. Ainda estou tentando descobrir por que isso está acontecendo.

Como os servidores estão fisicamente próximos um do outro e você mencionou nos comentários que tem acesso físico a eles, a maneira mais rápida seria retirar o disco rígido do primeiro computador, colocá-lo no segundo e transferir os arquivos pela conexão SATA.

netcat é ótimo para situações como essa em que a segurança não é um problema:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Note que, se você estiver usando o ddGNU coreutils, poderá enviar SIGUSR1para o processo e ele emitirá progresso para o stderr. Para BSD dd, use SIGINFO.

pv é ainda mais útil ao relatar o progresso durante a cópia:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

1. Não usar rápido compressão.

   • Qualquer que seja o seu meio de transferência - especialmente para rede ou usb - você estará trabalhando com rajadas de dados para leituras, caches e gravações, e elas não estarão exatamente sincronizadas.
   • Além do firmware do disco, caches de disco e caches de kernel / ram, se você também pode empregar as CPUs do sistema de alguma forma para concentrar a quantidade de dados trocados por burst , faça isso .
   • Qualquer algoritmo de compactação manipulará automaticamente execuções esparsas de entrada o mais rápido possível, mas há muito poucos que manipularão o restante nas taxas de transferência de rede.
   • lz4 é sua melhor opção aqui:

     O LZ4 é um algoritmo de compactação sem perdas muito rápido, que fornece velocidade de compactação a 400 MB / s por núcleo, escalável com CPU de vários núcleos. Ele também possui um decodificador extremamente rápido, com velocidade em vários GB / s por núcleo, normalmente atingindo os limites de velocidade da RAM em sistemas com vários núcleos.

2. De preferência, não procure desnecessariamente.

   • Isso pode ser difícil de avaliar.

   • Se houver muito espaço livre no dispositivo do qual você copia e o dispositivo não foi zerado recentemente, mas todos os sistemas de arquivos de origem devem ser copiados, provavelmente vale a pena fazer o primeiro algo como:

     </dev/zero tee >empty empty1 empty2; sync; rm empty*

   • Mas isso depende de qual nível você deve ler a fonte. Geralmente, é desejável ler o dispositivo do início ao fim do /dev/some_diskarquivo do dispositivo, porque a leitura no nível do sistema de arquivos geralmente envolve a busca e o retorno do disco de forma não sequencial. E assim seu comando de leitura deve ser algo como:

     </dev/source_device lz4 | ...

   • No entanto, se o sistema de arquivos de origem não deve ser transferido inteiro, a leitura no nível do sistema de arquivos é inevitável e, portanto, você deve agrupar seu conteúdo de entrada em um fluxo. paxgeralmente é a melhor e mais simples solução nesse caso, mas você também pode considerar mksquashfs.

     pax -r /source/tree[12] | lz4 | ...
     mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
     

3. Você não criptografar com ssh.

   • A adição de sobrecarga de criptografia a uma mídia confiável é desnecessária e pode prejudicar seriamente a velocidade das transferências sustentadas , pois a leitura dos dados precisa ser lida duas vezes .
   • O PRNG precisa dos dados lidos, ou pelo menos alguns deles, para sustentar a aleatoriedade.
   • E é claro que você também precisa transferir os dados.
   • Você também precisa transferir a sobrecarga de criptografia em si - o que significa mais trabalho por menos dados transferidos por burst .

   • Então, você deve usar netcat( ou, como preferir, o nmapprojeto é mais capazncat ) para uma cópia de rede simples, como já foi sugerido em outros lugares:

     ###  on tgt machine...
     nc -l 9999 > out.lz4
     ###  then on src machine...
     ... lz4 | nc tgt.local 9999
     

Existem várias limitações que podem estar limitando a velocidade de transferência.

1. Há sobrecarga de rede inerente em um canal de 1 Gbps. Normalmente, isso reduz a taxa de transferência REAL para 900 Mbps ou menos. Então, lembre-se de que esse é um tráfego bidirecional e você deve esperar significativamente menos que 900 Mbps.

2. Mesmo usando um "novo roteador ish", você tem certeza de que o roteador suporta 1Gbps? Nem todos os novos roteadores suportam 1Gbps. Além disso, a menos que seja um roteador de nível empresarial, você provavelmente perderá largura de banda de transmissão adicional, pois o roteador será ineficiente. Embora com base no que encontrei abaixo, parece que você está ficando acima de 100Mbps.

3. Pode haver congestionamento na rede de outros dispositivos que compartilham sua rede. Você já tentou usar um cabo diretamente conectado, como disse que podia fazer?

4. Qual a quantidade de IO do seu disco que você está usando? Provavelmente, você está sendo limitado, não pela rede, mas pela unidade de disco. A maioria dos HDDs de 7200 rpm alcança apenas cerca de 40 MB / s. Você está usando invasão? Você está usando SSDs? O que você está usando no terminal remoto?

Sugiro usar o rsync se for esperado que seja executado novamente para backups. Você também pode scp, ftp (s) ou http usando um downloader como o filezilla na outra extremidade, pois ele paraleliza as conexões ssh / http / https / ftp. Isso pode aumentar a largura de banda, pois as outras soluções passam por um único pipe. Um único pipe / thread ainda é limitado pelo fato de ser de thread único, o que significa que pode até ser vinculado à CPU.

Com o rsync, você tira grande parte da complexidade da sua solução, além de permitir compactação, preservação de permissão e permitir transferências parciais. Existem vários outros motivos, mas geralmente é o método de backup preferido (ou executa os sistemas de backup) de grandes empresas. O Commvault, na verdade, usa o rsync sob o software como mecanismo de entrega de backups.

Com base no seu exemplo de 80 GB / h, você terá 177 Mbps (22,2 MB / s). Eu sinto que você poderia facilmente dobrar isso com o rsync em uma linha Ethernet dedicada entre as duas caixas, já que eu consegui isso nos meus próprios testes com o rsync sobre gigabit.

Lidamos com isso regularmente.

Os dois métodos principais que costumamos usar são:

1. SATA / eSATA / sneakernet
2. Montagem direta do NFS, depois local cpoursync

O primeiro depende se a unidade pode ser realocada fisicamente. Isso não é sempre o caso.

O segundo funciona surpreendentemente bem. Geralmente, atingimos no máximo uma conexão de 1GB / s com facilidade com montagens NFS diretas. Você não chegará nem perto disso com scp, dd over ssh ou qualquer coisa semelhante (geralmente você obtém uma taxa máxima suspeita de quase 100mpbs). Mesmo em processadores multicore muito rápidos, você encontrará um gargalo na taxa de transferência máxima de criptografia de um dos núcleos na mais lenta das duas máquinas, o que é deprimente em comparação com o cp ou rsync de furo máximo em uma montagem de rede não criptografada. Ocasionalmente, você atinge a parede do IOP por um tempo e fica preso a cerca de ~ 53 MB / s em vez dos ~ 110 MB / s mais comuns, mas isso geralmente dura pouco, a menos que a origem ou o destino seja realmenteuma única unidade, você pode acabar sendo limitado pela taxa sustentada da própria unidade (que varia o suficiente por razões aleatórias que você não saberá até tentar) - meh.

O NFS pode ser um pouco chato de configurar, se for uma distro desconhecida, mas de um modo geral, tem sido a maneira mais rápida de encher os canos da maneira mais completa possível. A última vez que fiz isso acima de 10 gbps, nunca descobri se a conexão estava no máximo, porque a transferência havia terminado antes de eu voltar a tomar um café - então pode haver algum limite natural que você atinja lá. Se você tiver alguns dispositivos de rede entre a origem e o destino, poderá encontrar alguns atrasos ou soluços do efeito furtivo da rede, mas geralmente isso funcionará em todo o escritório (sem outro tráfego disfarçado) ou em uma extremidade do datacenter para o outro (a menos que você tenha algum tipo de filtragem / inspeção ocorrendo internamente, caso em que todas as apostas estão desativadas ).

EDITAR

Notei algumas conversas sobre compressão ... não comprima a conexão. Isso diminuirá a velocidade da mesma maneira que uma camada de criptografia. O gargalo sempre será um núcleo único se você compactar a conexão (e você nem obterá uma utilização particularmente boa do barramento desse núcleo). A coisa mais lenta que você pode fazer na sua situação é usar um canal compactado e criptografado entre dois computadores sentados um ao lado do outro em uma conexão de 1 gbps ou superior.

FUTURA PROVA

Este conselho é válido desde meados de 2015. Isso quase certamente não será o caso por muitos outros anos. Portanto, leve tudo com um pouco de sal e, se você enfrentar essa tarefa regularmente, tente vários métodos com cargas reais, em vez de imaginar que obterá algo próximo dos ótimos teóricos ou mesmo taxas de taxa de transferência de compressão / criptografia observadas típicas para coisas como a Web tráfego, grande parte do qual é textual (protip: transferências em massa geralmente consistem principalmente em imagens, áudio, vídeo, arquivos de banco de dados, código binário, formatos de arquivo de escritório etc.) que já estão compactadosà sua maneira e beneficiam-se muito pouco de serem executados em outra rotina de compactação, cujo tamanho do bloco de compactação quase garante não se alinhar com os dados binários já compactados ...).

Imagino que, no futuro, conceitos como SCTP sejam levados para um local mais interessante, onde as conexões ligadas (ou as conexões de fibra canalizada internamente por espectro) são típicas, e cada canal pode receber um fluxo independente dos outros, e cada o fluxo pode ser compactado / criptografado em paralelo, etc. etc. Isso seria maravilhoso! Mas esse não é o caso hoje em 2015, e embora fantasiar e teorizar seja bom, a maioria de nós não possui clusters de armazenamento personalizados executando em uma câmara de criogenia, alimentando dados diretamente nas entranhas de um Blue Gene / Q gerando respostas para Watson. Isso simplesmente não é realidade. Também não temos tempo para analisar exaustivamente nossa carga útil de dados para descobrir se a compactação é uma boa ideia ou não - a transferência em si terminaria antes de terminarmos nossa análise,

Mas...

Os tempos mudam e minha recomendação contra compactação e criptografia não será válida. Eu realmente adoraria que esse conselho fosse revogado no caso típico muito em breve. Isso tornaria minha vida mais fácil.

Uma ferramenta bacana que eu usei no passado é bbcp. Como visto aqui: https://www.slac.stanford.edu/~abh/bbcp/ .

Veja também http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

Eu tive velocidades de transferência muito rápidas com esta ferramenta.

Se você conseguir um primeiro passe de alguma forma (por telefone / sneakernet / qualquer que seja), poderá analisar rsyncalgumas opções que podem acelerar bastante as transferências subseqüentes. Uma maneira muito boa de ir seria:

rsync -varzP sourceFiles destination

As opções são: detalhado, modo de arquivamento, recursivo, compactar, progresso parcial

Adicionado à insistência do pôster original nos comentários à resposta de zackse, embora não tenha certeza de que seja o mais rápido em circunstâncias típicas.

bashtem uma sintaxe especial redireccionamento:
Para saída:      > /dev/tcp/ IP  / porta
Para entrada:       < /dev/tcp/ IP  / porta
IP proibição ser ou IP pontos decimais ou um nome de host; proibição de porta seja um número decimal ou um nome de porta /etc/services.

Não existe um /dev/tcp/diretório real . É um kludge sintático especial que comanda basha criação de um soquete TCP, conecta-o ao destino especificado e, em seguida, faz o mesmo que um redirecionamento de arquivo usual (substitua o respectivo fluxo padrão pelo soquete usando dup2 (2)).

Portanto, pode-se transmitir dados de ddou tarna máquina de origem diretamente via TCP. Ou, inversamente, para transmitir dados para taralgo semelhante diretamente via TCP. De qualquer forma, um netcat supérfluo é eliminado.

Notas sobre o netcat

Há uma inconsistência na sintaxe entre o netcat clássico e o GNU netcat . Vou usar a sintaxe clássica com a qual estou acostumado. Substitua -lppor -lpara GNU netcat.

Além disso, não tenho certeza se o GNU netcat aceita -qswitch.

Transferindo uma imagem de disco

(Seguindo as linhas da resposta de zackse.)
No destino:

nc -lp 9999 >disk_image

Na fonte:

dd if=/dev/sda >/dev/tcp/destination/9999
 

Criando um arquivo tar.gz, com tar

No destino:

nc -lp 9999 >backup.tgz

Na fonte:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Substitua .tgzpor .tbze czcom cjpara obter um bzip2arquivo compactado.

Transferindo com expansão imediata para o sistema de arquivos

Também com tar.
No destino:

cd backups
tar x </dev/tcp/destination/9999

Na fonte:

tar c files or directories to be transferred |nc -q 1 -lp 9999

Ele funcionará sem -q 1, mas o netcat ficará bloqueado quando os dados terminarem. Veja tar (1) para explicação da sintaxe e das advertências de tar. Se houver muitos arquivos com alta redundância (baixa entropia), seguida de compressão (e. G. czE xz, em vez de ce x) pode ser tentado, mas se os arquivos são típicos e da rede é rápido o suficiente, seria apenas retardar o processo. Veja a resposta do mikeserv para obter detalhes sobre compactação.

Estilo alternativo (o destino escuta a porta)

No destino:

cd backups
nc -lp 9999 |tar x

Na fonte:

tar c files or directories to be transferred >/dev/tcp/destination/9999

Tente as sugestões sobre conexões diretas e evitando protocolos criptografados como o ssh. Então, se você ainda deseja obter todo o desempenho, leia este site: https://fasterdata.es.net/host-tuning/linux/ para obter alguns conselhos sobre como otimizar suas janelas TCP.

Eu usaria esse script que escrevi que precisa do socatpacote.

Na máquina de origem:

tarnet -d wherefilesaretosend pass=none 12345 .

Na máquina de destino:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Se o vbufpacote (Debian, Ubuntu) estiver lá, o remetente do arquivo mostrará o progresso dos dados. O receptor do arquivo mostrará quais arquivos foram recebidos. A opção pass = pode ser usada onde os dados podem ser expostos (mais lentamente).

Editar:

Use a -nopção para desativar a compactação, se a CPU for um gargalo.

Se o orçamento não for a principal preocupação, tente conectar as unidades com um "conector de unidade" de núcleo Intel Xeon E5 12. Esse conector geralmente é tão poderoso que você pode até executar o software de servidor atual nele. Dos dois servidores!

Isso pode parecer uma resposta divertida, mas você deve realmente considerar por que está movendo os dados entre servidores e se um grande problema com memória e armazenamento compartilhado pode fazer mais sentido.

Não tem certeza sobre as especificações atuais, mas a transferência lenta pode ser limitada pelas velocidades do disco, não pela rede?

Se você se importa apenas com backups, e não com um byte para cópia de bytes do disco rígido, eu recomendaria o backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html É um pouco trabalhoso configurar, mas é transferido muito rapidamente.

Meu tempo de transferência inicial para cerca de 500 G de dados foi de cerca de 3 horas. Os backups subsequentes acontecem em cerca de 20 segundos.

Se você não está interessado em backups, mas está tentando sincronizar as coisas, o rsync ou o unison atenderia melhor às suas necessidades.

Um byte para cópia de byte de um disco rígido geralmente é uma péssima idéia para fins de backup (sem incrementos, sem economia de espaço, a unidade não pode estar em uso, é necessário fazer backup do "espaço vazio" e fazer backup do lixo (como um arquivo de swap de 16 G ou 200 G de core dumps ou algo assim). Usando o rsync (ou backuppc ou outros), você pode criar "snapshots" a tempo para poder ir para "como era o seu sistema de arquivos há 30 minutos" com muito pouco em cima.

Dito isto, se você realmente deseja transferir um byte para cópia de bytes, seu problema está na transferência e não na obtenção de dados da unidade. Com 400G de RAM, uma transferência de arquivos de 320G levará muito tempo. Usar protocolos que não são criptografados é uma opção, mas não importa o quê, você terá que ficar sentado lá e esperar várias horas (pela rede).

Independentemente do programa, geralmente descobri que "puxar" arquivos em uma rede é mais rápido que "empurrar". Ou seja, fazer login no computador de destino e fazer uma leitura é mais rápido do que fazer login no computador de origem e fazer uma gravação.

Além disso, se você usar uma unidade intermediária, considere o seguinte: Obtenha uma unidade externa (como um pacote ou uma unidade separada conectada a uma estação de acoplamento) que use eSATA em vez de USB. Em cada um dos dois computadores, instale uma placa com uma porta eSATA ou obtenha um cabo adaptador simples que leve uma das portas SATA internas a um conector eSATA externo. Em seguida, conecte a unidade ao computador de origem, ligue-a e aguarde a montagem automática (você pode montar manualmente, mas se estiver fazendo isso repetidamente, poderá colocá-la no seu arquivo fstab). Então copie; você estará escrevendo na mesma velocidade que em uma unidade interna. Em seguida, desmonte a unidade, desligue-a, conecte-se ao outro computador, ligue-a, aguarde uma montagem automática e leia.

Vou recomendar que você analise as equipes da NIC. Isso envolve o uso de várias conexões de rede em execução paralela. Supondo que você realmente precise de mais de 1 Gb de transferência e 10 Gb seja proibitivo em termos de custo, 2 Gbs fornecidos pela equipe da NIC seriam um custo menor e seus computadores já podem ter portas extras.

FWIW, eu sempre usei isso:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

O que é esse método é que ele manterá permissões de arquivo / pasta entre máquinas (supondo que os mesmos usuários / grupos existam em ambos) (também costumo fazer isso para copiar imagens de disco virtual, pois posso usar um parâmetro -S para manipular arquivos esparsos. )

Acabei de testar isso entre dois servidores ocupados e conseguiu ~ 14 GB em 216s (cerca de 64 MB / s) - poderia fazer melhor entre máquinas dedicadas e / ou compactação ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

A menos que você queira fazer análise forense do sistema de arquivos, use um programa de despejo / restauração para o seu sistema de arquivos para evitar a cópia do espaço livre que o FS não está usando. Dependendo do sistema de arquivos que você possui, isso normalmente preservará todos os metadados, inclusive ctime. números de inode podem mudar, no entanto, novamente, dependendo do sistema de arquivos (xfs, ext4, ufs ...).

O destino de restauração pode ser um arquivo no sistema de destino.

Se você deseja uma imagem de disco completo com a tabela de partições, pode obter ddo primeiro 1M do disco para obter a tabela de partições / gerenciadores de inicialização / outras coisas, mas depois xfsdumpas partições.

Não posso dizer pelo seu depósito de informações que tipo de sistema de arquivos você realmente possui. Se for BSD ufs, acho que tem um programa de despejo / restauração. Se for ZFS, bem, IDK, pode haver algo.

Geralmente, os discos de cópia completa são muito lentos para qualquer coisa, exceto para situações de recuperação. Você também não pode fazer backups incrementais dessa maneira.

Você também pode configurar os sistemas para ter um armazenamento compartilhado!

Estou considerando que estes estão próximos um do outro, e é provável que você faça isso de novo e de novo ....

Que tal um cabo cruzado Ethernet? Em vez de depender das velocidades sem fio, você está limitado à velocidade com fio da sua NIC.

Aqui está uma pergunta semelhante com alguns exemplos desse tipo de solução.

Aparentemente, apenas um cabo Ethernet típico é suficiente hoje em dia. Obviamente, quanto melhor sua NIC, mais rápida será a transferência.

Para resumir, se qualquer configuração de rede for necessária, deve-se limitar a simplesmente definir IPs estáticos para o servidor e o computador de backup com uma máscara de sub-rede 255.255.255.0

Boa sorte!

Editar:

@Khrystoph tocou nisso em sua resposta

Várias pessoas recomendam que você pule o ssh porque a criptografia o atrasará. As CPUs modernas podem, na verdade, ser rápidas o suficiente em 1Gb, mas o OpenSSH tem problemas com sua implementação de janelas internas que pode atrasá-lo drasticamente.

Se você quiser fazer isso com o ssh, dê uma olhada no HPN SSH . Ele resolve os problemas de janelas e adiciona criptografia multithread. Infelizmente, você precisará reconstruir o ssh no cliente e no servidor.

OK Tentei responder a essa pergunta em dois computadores com "tubos muito grandes" (10Gbe) "próximos" um do outro.

O problema com o qual você se depara aqui é: a maior parte da compactação afunila na CPU, pois os tubos são muito grandes.

desempenho para transferir arquivos de 10 GB (conexão de rede de 6 Gb [linode], dados não compactáveis):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

E duas caixas em 10 Gbe, versões ligeiramente mais antigas do netcat (CentOs 6.7), arquivo de 10 GB:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

Então, em uma instância, o netcat usou menos CPU, por outro, então YMMV.

Com o netcat, se não tiver a opção "-N -q 0", ele poderá transferir arquivos truncados, tenha cuidado ... outras opções como "-w 10" também podem resultar em arquivos truncados.

O que está acontecendo em quase todos esses casos é que a CPU está sendo maximizada, não a rede. scpatinge o máximo de 230 MB / s, atrelando um núcleo a 100% de utilização.

Infelizmente, o Iperf3 cria arquivos corrompidos . Algumas versões do netcat parecem não transferir o arquivo inteiro, muito estranho. Versões especialmente antigas.

Vários encantamentos de "gzip como um pipe para netcat" ou "mbuffer" também pareciam maximizar o cpu com o gzip ou mbuffer, portanto, não resultavam em uma transferência mais rápida com canos tão grandes. lz4 pode ajudar. Além disso, algumas das coisas que eu tentei resultaram em transferências corrompidas para arquivos muito grandes (> 4 GB); portanto, tenha cuidado lá fora :)

Outra coisa que pode funcionar especialmente para uma latência mais alta (?) É ajustar as configurações do tcp. Aqui está um guia que menciona valores sugeridos:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm e https://fasterdata.es.net/host-tuning/linux/ (de outra resposta) possivelmente configurações de IRQ: https://fasterdata.es .net / ajuste do host / 100g-tuning /

sugestões do linode, adicione /etc/sysctl.conf:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

Além disso, eles desejam que você execute:

 /sbin/ifconfig eth0 txqueuelen 10000 

vale a pena conferir duas vezes depois de ajustar para garantir que as alterações também não causem danos.

Também pode valer a pena ajustar o tamanho da janela: https://iperf.fr/iperf-doc.php#tuningtcp

Com conexões lentas (er), a compactação pode definitivamente ajudar. Se você possui tubos grandes, a compactação muito rápida pode ajudar com dados prontamente compactáveis, mas não tentei.

A resposta padrão para "sincronizar discos rígidos" é sincronizar os arquivos, o que evita a transferência sempre que possível.

Outra opção: use "scp paralelo" (de uma forma ou de outra), então ele usará mais núcleos ...