관련 주제
내 문제는 다음과 유사하지만 정확히 동일하지는 않습니다.SSH 깨진 파이프, 메시지 인증 코드가 잘못됨대답이 없습니다.
일
한 Linux에서 다른 Linux로 대용량 파일을 복사합니다. 둘 다 동일한 ISP 위치에 있습니다.
설정
소스와 대상은 모두 Ubuntu 16.04.3 LTS입니다.
둘 다의 SSH 버전: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 2016년 3월 1일
소스 머신은 1년 동안 사용해 왔지만 아무런 문제가 없습니다. 대상 머신은 새로 설정된 전용 서버(1일)입니다.
scp 명령:
scp -P [customport] /some/large/file user@targetmachine:/target/folder/
파일 크기는 약 20GB입니다.
문제 설명
일반적으로 약 3~4% 후에 중단됩니다. 최대 속도는 약 112MB/s입니다. 예를 들어 scp -l 16384를 사용하여 조절하면 약 2MB/s로 진행되고 훨씬 나중에 중단되지만 비슷한 비율로 중단됩니다.
중단은 항상 똑같은 방식으로 수행됩니다. 클라이언트는 다음을 얻습니다.
Write failed: Broken pipe
lost connection
서버의 /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
조사
iptables를 활성화 및 비활성화한 상태에서 두 가지를 모두 시도했지만 변경 사항은 없습니다.
약 10번의 시도 중 1번은 끝까지 성공했고, 이후 다음 파일이 다시 중단되었습니다.
대상 머신을 재부팅한 후에는 더 많은 바이트를 쓸 수 있는 것 같습니다.
SSH는 문제 없습니다. 유휴 SSH 연결을 몇 시간 동안 열어 두거나 top명령이 실행 중이고 중단되지 않는 연결 을 유지할 수 있습니다 .
질문
이것은 차단제입니다. 첫째, 200GB 파일을 복사하는 것은 불가능해 보입니다. 둘째, 네트워킹 문제가 있는 프로덕션 환경의 머신을 원하지 않습니다.
이 문제를 추가로 조사하려면 어떻게 해야 합니까?
네트워크 카드/하드웨어 문제일 수 있다는 내용을 다른 곳에서 읽었습니다. 교체품을 받기 위해 공급자에게 이를 증명하려면 어떻게 해야 합니까?
업데이트 1
10분 동안의 결과는 mtr좋아 보입니다.
└─(~)─(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)
그 직후 다른 scp를 시도했는데 7.5GB 이후 44%로 실패했고 속도는 111MB/초였습니다. 실패는 즉시 다시 발생했으며 그 전에는 지연이 발생하지 않았습니다.
가능한 중복에 관해서 : 나는 항상 "깨진 파이프"를 얻었고 "소켓에 대한 프로토콜 유형이 잘못되었습니다"는 결코 얻지 못했습니다. Mac을 사용하지 않고 Linux(위 버전)를 모두 사용합니다. rsync를 사용하지 않습니다. 그에 대한 대답은 내가 아는 한 사용자가 실제 원인을 파악하지 못한 채 다른 네트워크 카드를 서버에 넣었다는 것이었습니다. 이 옵션(원격 호스트 센터의 전용 서버)이 없습니다.
네트워크 카드에 관한 lshw의 출력은 다음과 같습니다.
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
KVM을 설치했다는 사실이 생각나네요.
apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
하지만 아직 VM이 켜져 있지 않습니다.
답변1
scp또는 rsync+ samba/ 를 사용할 때 비슷한 문제가 발생했습니다 cifs.
클라이언트에 서버를 마운트할 때 사용하는 쓰기 캐시를 우회하여 rsync+ samba/ 측 에서 문제가 해결되었습니다 (참조:cifs--cache=nonersync 연결이 계속 끊어집니다. 파이프가 끊어졌습니다.). 이 문제의 근본 원인에 대한 자세한 설명은 다음에서 제공됩니다.로컬 디스크 읽기와 동시에 Linux가 네트워크 파일 시스템에 쓰기를 수행하도록 합니다..
scp디스크가 따라잡기 전에 페이지 캐시가 채워지는 것을 방지하기 위해 전송 속도를 조절하는 것을 고려할 수 있습니다. 예를 참조하세요 .https://stackoverflow.com/questions/30020519/broken-pipe-error-on-scp.
답변2
이것은 "최소화" 설치였습니다. Ubuntu의 "최소" 버전은 처음부터 작동했을 가능성이 높습니다.
다음 명령은 제대로 작동하지 않는 no-hwe 버전에 hwe를 설치하는 데 사용되었습니다(따라서 완전한 재설치는 불가능함).
apt-get install --install-recommends linux-generic-hwe-16.04
shutdown -r now
그 후에는 모든 scp 복사본이 작동하고 중단되지 않습니다.
참고로 터미널의 인사말은 계속 표시됩니다.
"myuser@Ubuntu-1604-xenial-64-minimal-no-hwe"
지금 hwe가 켜져 있는데도요.
이 수정 전의 동작을 한 번 더 명확하게 설명하겠습니다. 다양한 위치에서 이 시스템으로의 모든 대형 scp가 중단된 반면, 이 시스템에서 다양한 위치로의 모든 scp는 성공했습니다.
서버스펙입니다https://www.hetzner.de/epyc-server호스팅 업체에서는 메인보드/네트워킹 모델을 지정하지 않습니다.