最新のアップデートを見るには下にスクロールしてください。
ユーザーのためのNFSサーバーホスティングホームとして構成されたインフラストラクチャがあります。サーバーはUbuntuサーバーを実行し、10Gファイバーイーサネット（Myri-10Gデュアルプロトコルネットワークカード）を備えています。過去2年間でよく運営されてきました。このネットワークカードの切り替え中、サーバーは変更されず、サーバーは常に10G光ファイバでした。
インフラの概要:
- サーバー：（10.131.39.114）Ubuntu 16.04.4、Myri-10Gデュアルプロトコルネットワークカード、ファームウェア1.4.57、nfs-kernel-server 1：1.2.8-9ubuntu12.3、linuxカーネル4.4.0-109-gener
- スイッチ：Force 10 S2410、レイヤ2のみ、10Gファイバインタフェースのみ
- クライアント：Linux Mint 18.2、Myri-10Gデュアルプロトコルネットワークカード、ファームウェア1.4.57、autofs実行、Linuxカーネル4.8.0-53-generic（すべてのクライアントに同じ、参考としてIntel 82579LMギガビットネットワーク接続を使用）銅イーサネット）
クライアントワークステーションはDellワークステーションクラスのコンピュータです。はい内蔵の1Gイーサネット（Intel 82579LM）を使用してください。ビッグデータの作業を進めており、さらにMyri-10Gデュアルプロトコルネットワークカードを獲得しました。
私たちのワークステーションの半分は新しいネットワークカードにアップグレードされ、光ファイバを介してS2410スイッチに接続されました。これらすべて〜らしい再起動後に動作します。 Intelを終了し、Myricomを設定しました。同じIPアドレスを持っている銅ネットワークカードとして（私たちは銅ネットワークカードをオフにしました）。すべてが大丈夫に見えます。 ping、ファイルのダウンロードなどができます。しかし、、クライアントがログインすると停止します。短い調査の最後に、NFSサーバーが接続されていないことに気づきました。
注：私たちはVLANを使用しています。最初は、VLANルーティングの問題かもしれないと考え、クライアントとサーバーを同じVLANに配置しました。私たちも同じ問題に直面しました。
観察/問題解決：
lshw -C network
*-network
description: Ethernet interface
product: Myri-10G Dual-Protocol NIC
vendor: MYRICOM Inc.
physical id: 0
bus info: pci@0000:22:00.0
logical name: enp34s0
version: 00
serial: 00:60:dd:44:96:a8
size: 10Gbit/s
width: 64 bits
clock: 33MHz
capabilities: msi pm pciexpress msix vpd bus_master cap_list rom ethernet physical fibre
configuration: autonegotiation=off broadcast=yes driver=myri10ge driverversion=1.5.3-1.534 duplex=full firmware=1.4.57 -- 2013/10/23 13:58:51 m latency=0 link=yes multicast=yes port=fibre speed=10Gbit/s
resources: irq:62 memory:fa000000-faffffff memory:fbd00000-fbdfffff memory:fbe00000-fbe7ffff
*-network
description: Ethernet interface
physical id: 1
logical name: enp34s0.731
serial: 00:60:dd:44:96:a8
size: 10Gbit/s
capabilities: ethernet physical fibre
configuration: autonegotiation=off broadcast=yes driver=802.1Q VLAN Support driverversion=1.8 duplex=full firmware=N/A ip=10.131.31.181 link=yes multicast=yes port=fibre speed=10Gbit/s
rpcinfo -p 10.131.39.114
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100011 1 udp 787 rquotad
100011 2 udp 787 rquotad
100011 1 tcp 787 rquotad
100011 2 tcp 787 rquotad
100005 1 udp 40712 mountd
100005 1 tcp 45016 mountd
100005 2 udp 44618 mountd
100005 2 tcp 49309 mountd
100005 3 udp 43643 mountd
100005 3 tcp 53119 mountd
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 51511 nlockmgr
100021 3 udp 51511 nlockmgr
100021 4 udp 51511 nlockmgr
100021 1 tcp 43334 nlockmgr
100021 3 tcp 43334 nlockmgr
100021 4 tcp 43334 nlockmgr
rpcinfo -u 10.131.39.114 mount
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting
rpcinfo -u 10.131.39.114 portmap
program 100000 version 2 ready and waiting
program 100000 version 3 ready and waiting
program 100000 version 4 ready and waiting
rpcinfo -u 10.131.39.114 nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting
program 100003 version 4 ready and waiting
しかし、これは失敗します。
showmount -e 10.131.39.114
rpc mount export: RPC: Timed out
ちなみに、動作しているクライアント（銅）では通常、次のことがわかります。
showmount -e 10.131.39.114
Export list for 10.131.39.114:
/mnt/homes 10.131.84.0/26,10.131.31.187,10.131.31.186,10.131.31.185,10.131.31.184,10.131.31.183,10.131.31.182,10.131.31.181,10.131.31.180
/mnt/clones 10.131.31.0/24,10.131.39.0/24,10.131.84.0/26
（はい、私は別のLANにいることを知っていますが、長年働いてきました。）
注：ネットワーク管理者はオフになっており、/etc/network/interfacesには次のものが含まれています。
auto enp34s0.731
iface enp34s0.731 inet static
vlan-raw-device enp34s0
address 10.131.31.181
netmask 255.255.255.0
gateway 10.131.31.1
dns-nameservers 10.131.31.53,10.35.32.15
おそらくこの情報は役に立ちます：
10Gを使用するクライアントからサーバーからエクスポートされた別のディレクトリをマウントするためにディレクトリを作成し、/mnt/clones（複製のために開きます）と言い、NFSv4を使用して手動でマウントすると〜らしい動作しますが、インストールされたディレクトリでlsまたはcdを実行することはできません。 dfは機能しますが、ディレクトリ内のファイル数は数えません。以前はこの問題を見たことがありますが、理由は覚えていません。
クライアントはデフォルトでnfs4を使用します（たとえば、auto.homeが有効になっているアクティブな銅イーサネットクライアントなど）。
10.131.39.114:/mnt/homes/usera on /home/usera type nfs4 (rw,nosuid,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.131.31.185,local_lock=none,addr=10.131.39.114)
銃:
- 10gigにアップグレードした後、NFSはもはやクライアント側で動作していないようです...私は過去にこれらの正確なNICを使用していたことを知っています（実際、この正確なNICは私が2012年に使用したものでした）。そしてそれを別のクラスターに配置しました。これは、このnfsが機能しないことを意味し、これははるかに意味がありません）。
- nfs 共有を手動でマウントすると失敗します。
- v4を強制的に適用してnfs共有を手動でマウントすると、機能しているように見えますが、マウント専用です。 df コマンドを除いて、ファイルと操作は失敗します。
- ログインしてホームディレクトリを自動マウントしようとすると失敗します。
- 10Gクライアントでv4を使用するように自動マウントを強制した場合〜らしいマウントされていますが、ユーザーはまだログインに失敗します。家そうだマウントされていますが、何もできません。
興味深いことに、サーバーにはクライアントが試みた認証要求のログはありません。たとえば、稼働中のCopperクライアントにユーザーがログインしている場合、NFSサーバーのsyslogは認証されたnfs要求を記録します。同じクライアントが10Gワークステーションにログインしようとすると、NFSサーバーにマウント要求は記録されません。リクエストがサーバーに到達できなかったようです。
繰り返しますが、10Gワークステーションから始めると、ネットワークの他のすべてがうまく機能します。ファイル転送、サーバーアクセス（ssh、http経由のNFSサーバー、試行したすべてのポートも機能します）。この問題は NFS にのみ影響するようです。
この記事の基本的な質問は次のとおりです。次はどのような診断を行うべきですか？ RPCタイムアウトが発生しているようですが、インターネット上のすべてのヘルプ/ FAQはルーティングまたはネットワーキングを指します。これらのホストは同じスイッチに接続されており、同じ結果をテストするために実際に同じVLANに移動しました。どんな考えや洞察力でも大変感謝いたします。
修正する:私はこれが非常に重要であり、私の問題の原因だと思いますが、これを診断する方法がわかりません。
10Gigファイバーカードを使用するクライアントでは：
nmap -sC -p111 10.131.39.114
Starting Nmap 7.80 ( https://nmap.org ) at 2021-03-12 15:20 UTC
Nmap scan report for cmixhyperv03.cmix.louisiana.edu (10.131.39.114)
Host is up (0.00011s latency).
PORT STATE SERVICE
111/tcp open rpcbind
MAC Address: 00:60:DD:46:D6:DE (Myricom)
Nmap done: 1 IP address (1 host up) scanned in 3.79 seconds
同様のクライアントで1G銅イーサネットを使用している場合：
nmap -sC -p111 10.131.39.114
Starting Nmap 7.01 ( https://nmap.org ) at 2021-03-12 09:21 CST
Nmap scan report for cmixhyperv03.cmix.louisiana.edu (10.131.39.114)
Host is up (0.00044s latency).
PORT STATE SERVICE
111/tcp open rpcbind
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/udp nfs
| 100005 1,2,3 43643/udp mountd
| 100005 1,2,3 53119/tcp mountd
| 100011 1,2 787/tcp rquotad
| 100011 1,2 787/udp rquotad
| 100021 1,3,4 43334/tcp nlockmgr
| 100021 1,3,4 51511/udp nlockmgr
| 100227 2,3 2049/tcp nfs_acl
|_ 100227 2,3 2049/udp nfs_acl
Nmap done: 1 IP address (1 host up) scanned in 1.21 seconds
20210315アップデート
クライアントとサーバーのWiresharkにtcpdumpを追加します。動作中のCopperクライアントと失敗したFiberクライアントとの間で見られる唯一の違いは、サーバーが接続され、すべてがCopperクライアントが接続されたときと同じように見えることです。ただし、ホームディレクトリファイル（.bash_profileなど）を読み始めた後はそうです。 、サーバーが再送信を開始し、偽の再送信を受けているようです。しばらくすると、NFSはまだディレクトリをロードしようとしていますが、TCP RST、ACK、およびRSTが表示され、次にNFS NFSERR_BADSESSIONが表示されます。これまでWiresharkがサーバーが再送信する理由やクライアントが失敗した理由を特定することはできません。
これまで、10gigスイッチを別のスイッチに交換し、他のクライアントも使用していました。不運。
ベストアンサー1
これを撤回した後、ふと気づきました...言及したように、テスト中の銅とファイバーの両方を含むワークステーションがありますが、ファイバーは機能しません...しかし、私の考えでは、それらはすべてVLAN境界を拡張し、はL2のみなのでルータと通信中です。
ここで得た答えは...間違っています。クライアントを1500MTUに移動すると問題が「解決」され、ネットワークチームはルータMTUも1500と信じることになりました。これは正確ではありません。ワークステーションを別のスイッチに移動し、すべての人のMTUを9000に設定しても機能しません。わかりました... NFSはMTU 9000が好きではないようです。
私は言及していますこれら 記事しかし、10GigとJumboフレームを使用しているため、問題は「解決」されません。クライアントを1500バイトのMTUに移動すると、この問題を解決できます。