関連トピック
私の問題は、次のものと似ていますが、まったく同じではありません。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% で中止します。最大速度は約 112 MB/秒です。たとえば scp -l 16384 でスロットルすると、約 2 MB/秒になり、かなり遅れて中止しますが、割合は同じです。
中止は常にまったく同じ方法で行われます。クライアントは次のものを受け取ります:
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 回は最後まで成功しましたが、次のファイルは再び中止されました。
ターゲットマシンを再起動すると、より多くのバイトを書き込むことができるようです。
topSSH は問題ありません。アイドル状態の SSH 接続を何時間も開いたままにしたり、コマンドが実行されている接続を切断せずに開いたままにしたりできます。
質問
これは障害です。まず、200 GB のファイルをコピーするのは不可能に思えます。次に、ネットワークの問題のあるマシンを本番環境に置きたくありません。
これをさらに調査するにはどうすればいいでしょうか?
他の場所でネットワーク カード/ハードウェアの問題である可能性があると読んだのですが、交換してもらうためにプロバイダーにこれを証明するにはどうすればよいでしょうか?
アップデート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.5 GB 後の 44% で失敗し、速度は 111 MB/秒でした。失敗は再びすぐに発生し、それ以前に停止することはありませんでした。
重複の可能性について: 常に「壊れたパイプ」が表示され、「ソケットのプロトコル タイプが間違っています」は表示されませんでした。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ただし、ホスティング会社はマザーボード/ネットワークのモデルを指定していません。