web-dev-qa-db-ja.com

I / Oがnfsマウントに失敗する（ときどき）-サーバーがタイムアウトしました

Linuxベースのファイルサーバー（ark）があり、nfs4を介してRAIDボリュームをエクスポートします。

大きなコピー操作を行うと、タイムアウトになることがあります。

[nathan@ebisu /mnt/extra/disk] rsync -a --progress . /mnt/raid/backup/backup.extra/disk
sending incremental file list
BSD.0/
BSD.0/BSD.0.vdi
   411336704  12%   48.60MB/s    0:00:56
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/mnt/raid/backup/backup.extra/disk/BSD.0/BSD.0.vdi": Input/output error (5)
rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
rsync: connection unexpectedly closed (32 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

Dmesgが私にそう言うので、これがタイムアウトであることを私は知っています：

 [nathan@ebisu ~] dmesg | tail
 [52722.138132] nfs: server ark not responding, timed out
 [52722.138137] nfs: server ark not responding, timed out
 [52722.138145] nfs: server ark not responding, timed out
 [52722.138150] nfs: server ark not responding, timed out
 [52722.138154] nfs: server ark not responding, timed out

これがrsyncに関連するバグである可能性があると思われる場合は、通常のコピーも実行してみました。

[nathan@ebisu /mnt/extra/disk] cp BSD.0/BSD.0.vdi /mnt/raid/backup/backup.extra/disk
cp: error writing ‘/mnt/raid/backup/backup.extra/disk/BSD.0.vdi’: Input/output error
cp: failed to extend ‘/mnt/raid/backup/backup.extra/disk/BSD.0.vdi’: Input/output error

この問題を解決するためにどこから始めればよいのかさえわかりません。これらは両方とも、ギガビットスイッチを介してギガビットイーサネット経由で接続されています。私はethtoolを使用して、両方が実際にギガビット速度で実行されていることを検証しました。ホストとサーバー間のほとんどの操作は正常に機能します。それが死ぬのは大きな移籍の真っ只中だけです。

ファイルサーバーのdmesgには、厄介なものとして目立つものはありません。

[root@ark ~]# dmesg | tail
[    7.088959] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[    7.266363] NFSD: starting 90-second grace period (net ffffffff81880e80)
[ 8492.222871] type=1326 audit(1365926452.334:2): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=336 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fe1be17edc7 code=0x0
[ 8492.314714] type=1326 audit(1365926452.424:3): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=338 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fe30fd9ddc7 code=0x0
[ 8492.405336] type=1326 audit(1365926452.514:4): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=340 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f6bb032ddc7 code=0x0
[ 8492.501048] type=1326 audit(1365926452.611:5): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=342 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f81d7c2fdc7 code=0x0
[ 8492.603056] type=1326 audit(1365926452.714:6): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=344 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f97c8bc9dc7 code=0x0
[ 8492.703732] type=1326 audit(1365926452.814:7): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=346 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f0661b2fdc7 code=0x0
[ 8492.837977] type=1326 audit(1365926452.947:8): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=348 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fd024f8cdc7 code=0x0
[54125.173195] type=1326 audit(1365972085.286:9): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=353 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f390a6b9dc7 code=0x0

Syslogにも同様に問題はありません。

私が収集したさらにランダムな診断情報：

[root@ebisu etc]# nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
1057273    34163      1050608

それはたくさんの再トランスです。

Nfsdスレッドが飽和しているかどうかを確認しましたが、ほとんどアイドル状態でした。

楽しみのために、ディスクエラーや速度低下が発生していないかどうかを確認するために、同様の転送を完全にローカルで実行しました。

[root@ark ~]# rsync --progress test.img /mnt/bigraid/backup/backup.ark/
test.img
  8589934592 100%   48.38MB/s    0:02:49 (xfer#1, to-check=0/1)

sent 8590983238 bytes  received 31 bytes  50386998.65 bytes/sec
total size is 8589934592  speedup is 1.00

50MB/sを少し下回ったようです。これは、リモートrsyncで取得していた速度とほぼ同じです。

サーバーでhtopを実行しているときに転送を実行しようとしましたが、しばらくすると、nfsdがより多くのメモリバッファーを要求したように見えることに気付きました。最新の標準ではサーバーはハイメモリシステムではないため、メモリに関連している可能性があります。しかし、これにより、完全にタイムアウトするのではなく、転送が遅くなるだけであるように思われます。

linuxnetworkingnetwork-sharesfile-transfernfs
2
Nathan

これは実際には答えではありませんが、いくつかのトラブルシューティングのヒントです。

  1. 問題がNFSに接続されていることを確認し、別のプロトコルを使用して同じボリュームをエクスポートします。SMBたとえば（手順については ここ を参照）。同じエラーが発生しますか？または、scpでコピーしてみてください。

    [nathan@ebisu ~] scp root@ark:/mnt/bigraid/backup/backup.ark/test.img .

  2. これは、単一の大きなファイルをコピーする場合にのみ発生しますか、それとも同じ量のデータを多数の小さなファイルにコピーした場合にも同じエラーが発生しますか？

    split test.img
rsync -a --progress x* /mnt/raid/backup/backup.extra/disk

  3. このページ によると、高い再変換値は

    サーバーで使用可能なNFSカーネルスレッドの数が、このクライアントからの要求を処理するには不十分であること

    したがって、RPCNFSDCOUNT変数を設定して、スレッドの数を増やしてみてください。ディストリビューションに応じて、これは/etc/sysconfig/nfsまたは/etc/default/nfs-kernel-serverで設定できます（私のDebianではここにあります）。次のようなものを試してください

    RPCSVCGSSDOPTS=16

  4. 同じページでは、クライアントでブロックサイズを32に設定することも提案しています。 /etc/fstabから共有をマウントしていると仮定して、次のオプションを関連する行に追加します。

    rsize=32768,wsize=32768,intr,noatime

    これらのオプションは、読み取り/書き込みブロックサイズを増やすだけでなく、

    また、ハングが発生した場合にNFS操作が中断される可能性があり、リモートNFSファイルシステムでアクセスされるファイルでatimeが常に更新されないようにします。

2
terdon

それは私にはネットワークの問題に非常によく似ています。一部のネットワークカード（特にRealtekチップの場合）は、特に1Gbpsで、間にスイッチがある場合、標準にあまり準拠していません。だからあなたは試してみるべきです：

  • スイッチなしで2つを接続する
  • イーサネットケーブルの変更
  • 接続速度を1000Mbps全二重に強制し、問題が続くかどうかを確認します
  • 接続速度を100Mbps全二重に強制し、問題が解決するかどうかを確認します（ほとんどの場合、不安定性は100Mbpsで表示されません。これは目的の設定ではありませんが、非互換性を絞り込むのに役立ちます）
  • ifconfigとethtool -S ethXのエラーをチェックしています
  • ifconfigを使用してMTUをチェックし、それが高い場合は15に設定します
  • ping -fを使用して、特に-s（pingパケットサイズ）の値が高い場合に、2つの間でドロップされたパケットをチェックします-不安定な接続willping -f -s 10000のようなものを数秒間実行すると、パケット損失が発生します
1
Stefan Seidel

同じエラーメッセージが表示されました（ただし、毎回エラーを再現できるため、同じ問題ではありません！）。

rsyncをより詳細に実行（_rsync -vv_）は、ターゲットファイルシステムがいっぱいであることを明らかにしました！

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) test/file1 is uptodate test/file2 is uptodate test/file3 is uptodate rsync: recv_generator: mkdir "test/file4" failed: No space left on device (28) * Skipping any contents from this failed directory * rsync: recv_generator: mkdir "test/file5" failed: No space left on device (28) rsync: close failed on "test/file6": Input/output error (5) rsync: connection unexpectedly closed (78708 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

0
Franklin Piat