tópicos relacionados
Meu problema é semelhante, mas não exatamente o mesmo, ao tubo quebrado SSH, código de autenticação de mensagem incorreto para o qual não há resposta.
Tarefa
Copie arquivos grandes de um Linux para outro. Ambos estão no mesmo local do ISP.
Configurar
Origem e destino são ambos: Ubuntu 16.04.3 LTS
Versão SSH em ambos: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 de março de 2016
A máquina de origem está em uso há um ano, sem problemas. A máquina de destino é um servidor dedicado recém-configurado (1 dia).
comando scp:
scp -P [customport] /some/large/file user@targetmachine:/target/folder/
O arquivo tem cerca de 20 GB de tamanho.
Descrição do Problema
Geralmente aborta após cerca de 3-4%. A velocidade total é de cerca de 112 MB/s. Quando eu acelero com, por exemplo, scp -l 16384, ele atinge cerca de 2 MB/s, aborta muito mais tarde, mas em uma porcentagem semelhante.
O aborto é sempre exatamente da mesma maneira. O cliente obtém:
Write failed: Broken pipe
lost connection
Enquanto o servidor tem isso em /var/log/auth.log
Nov 24 13:04:54 Ubuntu-1604-xenial-64-minimal-no-hwe sshd[1900]: Corrupted MAC on input.
Nov 24 13:04:54 Ubuntu-1604-xenial-64-minimal-no-hwe sshd[1900]: fatal: ssh_dispatch_run_fatal: Connection from [client-ip] port 54050: message authentication code incorrect
Investigação
Eu tentei ambos com iptables ativado e desativado, sem alteração.
De cerca de 10 tentativas, 1 foi bem-sucedida até o fim e, em seguida, o próximo arquivo foi abortado novamente.
Parece que depois de reiniciar a máquina de destino, mais bytes podem ser gravados nela.
SSH não é problema. Posso manter uma conexão ssh ociosa aberta por horas ou uma em que o top
comando está sendo executado e não é interrompido.
Perguntas
Isso é um bloqueador. Primeiro, parece impossível copiar um arquivo de 200 GB. Em segundo lugar, não quero uma máquina em produção com problemas de rede.
O que posso fazer para investigar melhor isso?
Eu li em outro lugar que pode ser um problema de placa de rede/hardware, como posso provar isso ao meu provedor para obter uma substituição?
Atualização 1
O resultado por 10 minutos mtr
parece bom:
└─(~)─(49 files, 12Gb)─> mtr -r -c 600 -rw [targetserver]
Start: Fri Nov 24 18:36:21 2017
HOST: Ubuntu-1404-trusty-64-minimal Loss% Snt Last Avg Best Wrst StDev
1.|-- static.XX.XX.XX.XX.clients.your-server.de 0.0% 600 0.5 0.3 0.2 24.5 1.3
2.|-- core24.fsn1.hetzner.com 0.0% 600 0.3 0.3 0.2 6.8 0.4
3.|-- core22.fsn1.hetzner.com 0.0% 600 0.4 0.4 0.3 9.7 0.8
4.|-- ex9k2.dc1.fsn1.hetzner.com 0.0% 600 0.4 0.5 0.3 6.8 0.8
5.|-- my.target.hostname 0.0% 600 0.4 0.3 0.3 0.4 0.0
┌(myuser@Ubuntu-1404-trusty-64-minimal)─(✓)─(06:46 PM Fri Nov 24)
Logo depois tentei outro scp, falhou em 44% após 7,5 GB, a taxa foi de 111 MB/s. A falha novamente veio instantaneamente, sem parar antes disso.
Em relação à possível duplicata: sempre recebi o "tubo quebrado", nunca o "Tipo de protocolo errado para soquete". Não usando Mac, ambos Linux (versões acima). Não usando rsync. A resposta foi que o usuário colocou outra placa de rede no servidor, sem descobrir qual era a causa real, pelo que entendi. Não tenho essa opção (servidor dedicado no centro de host remoto).
Aqui está a saída de lshw em relação à placa de rede:
myuser@Ubuntu-1604-xenial-64-minimal-no-hwe /home/myuser # lshw -class network
*-network:0 DISABLED
description: Ethernet interface
product: NetXtreme II BCM57810 10 Gigabit Ethernet
vendor: Broadcom Corporation
physical id: 0
bus info: pci@0000:61:00.0
logical name: eth0
version: 10
serial: e0:d5:5e:1e:73:18
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msix pciexpress bus_master cap_list rom ethernet physical fibre 1000bt-fd
configuration: autonegotiation=off broadcast=yes driver=bnx2x driverversion=1.712.30-0 firmware=bc 7.14.2 latency=0 link=no multicast=yes port=fibre
resources: iomemory:14c0-14bf iomemory:14c0-14bf iomemory:14c0-14bf irq:81 memory:14c0b000000-14c0b7fffff memory:14c0a800000-14c0affffff memory:14c0b810000-14c0b81ffff memory:e5f80000-e5ffffff memory:14c0ba20000-14c0bc1ffff memory:14c0bca0000-14c0bd1ffff
*-network:1 DISABLED
description: Ethernet interface
product: NetXtreme II BCM57810 10 Gigabit Ethernet
vendor: Broadcom Corporation
physical id: 0.1
bus info: pci@0000:61:00.1
logical name: eth1
version: 10
serial: e0:d5:5e:1e:73:1a
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msix pciexpress bus_master cap_list rom ethernet physical fibre 1000bt-fd
configuration: autonegotiation=off broadcast=yes driver=bnx2x driverversion=1.712.30-0 firmware=bc 7.14.2 latency=0 link=no multicast=yes port=fibre
resources: iomemory:14c0-14bf iomemory:14c0-14bf iomemory:14c0-14bf irq:102 memory:14c0a000000-14c0a7fffff memory:14c09800000-14c09ffffff memory:14c0b800000-14c0b80ffff memory:e5f00000-e5f7ffff memory:14c0b820000-14c0ba1ffff memory:14c0bc20000-14c0bc9ffff
*-network:0
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:62:00.0
logical name: eth2
version: 01
serial: 6c:b3:11:23:32:18
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.3.0-k duplex=full firmware=1.63, 0x80000cbb ip=94.130.51.145 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:71 memory:e5900000-e59fffff memory:e5a84000-e5a87fff memory:e5a00000-e5a7ffff memory:14c0bf60000-14c0bf7ffff memory:14c0bf40000-14c0bf5ffff
*-network:1 DISABLED
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0.1
bus info: pci@0000:62:00.1
logical name: eth3
version: 01
serial: 6c:b3:11:23:32:19
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.3.0-k firmware=1.63, 0x80000cbb latency=0 link=no multicast=yes port=twisted pair
resources: irq:82 memory:e5800000-e58fffff memory:e5a80000-e5a83fff memory:14c0bf20000-14c0bf3ffff memory:14c0bf00000-14c0bf1ffff
*-network DISABLED
description: Ethernet interface
physical id: 1
logical name: virbr0-nic
serial: 52:54:00:80:b4:28
size: 10Mbit/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair speed=10Mbit/s
Isso me lembra, eu instalei o KVM
apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
Mas nenhuma VM está ativada ainda.
Eu tive um problema semelhante ao usar
scp
oursync
+samba
/cifs
.O problema foi resolvido no lado
rsync
+samba
/cifs
ignorando o cache de gravação usando--cache=none
ao montar o servidor no cliente (consulte também rsync mantém a desconexão: tubo quebrado ). Uma explicação detalhada sobre a causa raiz desse problema é fornecida em Faça o Linux gravar no sistema de arquivos da rede simultaneamente com as leituras do disco local .Com
scp
você, você pode considerar a limitação da taxa de transferência para evitar o preenchimento do cache da página antes que o disco consiga alcançá-lo, consulte, por exemplo, https://stackoverflow.com/questions/30020519/broken-pipe-error-on-scp .Esta foi uma instalação "minimal-no-hwe". A versão "mínima" do Ubuntu provavelmente teria funcionado desde o início.
Esses comandos foram usados para instalar o hwe nesta versão no-hwe com defeito (portanto, não há reinstalação completa):
Depois disso, todas as cópias scp funcionam, sem interrupções.
Uma nota lateral, a saudação no terminal ainda mostra
mesmo que hwe esteja ligado agora.
Esclareço mais uma vez o comportamento antes desta correção: Todos os scp grandes PARA esta máquina, de vários locais, abortados, enquanto todos os scp DE esta máquina, para vários locais, foram bem-sucedidos.
Esta é a especificação do servidor https://www.hetzner.de/epyc-server , embora o hoster não especifique os modelos para placa-mãe/rede.