네트워크 카드 업그레이드 후 NFS 작동이 중지됨

최신 업데이트를 보려면 아래로 스크롤하세요.

사용자를 위한 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-generic
• 스위치: Force 10 S2410, Layer 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 주소를 가지고 있음구리 네트워크 카드로서(우리는 구리 네트워크 카드를 껐습니다). 모든 것이 괜찮아 보입니다. 핑, 파일 다운로드 등을 할 수 있습니다.하지만, 클라이언트가 로그인하면 정지됩니다. 짧은 조사 끝에 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 스위치를 다른 스위치로 교체하고 다른 클라이언트도 사용했습니다. 불운.