☰

서버가 다시 시작되면 NFS 클라이언트가 복구되지 않습니다.

tag-icon • tag-icon mount nfs
서버가 다시 시작되면 NFS 클라이언트가 복구되지 않습니다.

두 개의 머신이 있습니다. (a)는 NFS 서버이고, (b)는 NFS 클라이언트입니다.
컴퓨터(a)가 재부팅되면 재부팅하지 않고 컴퓨터(b)에서 NFS 클라이언트를 복구할 수 있는 방법이 있나요?

답변1

그 단어가 무슨 뜻인지는 모르겠지만, 그 recover뜻이라면 remount간단합니다 sudo mount -a.

답변2

당신은 시도 할 수 있습니다umount -f mountpoint

Windows NFS 서버에 연결된 RHEL 7 시스템에서 이 현상이 자주 발생합니다. umount 명령은 실패하지만 클라이언트 실행을 방해하는 모든 항목을 해제합니다.

답변3

적어도 세 가지 가능한 문제 지점이 있습니다.

  • rpc.statd및 해당 포트 할당
  • NFS 프로토콜에서 내부적으로 사용되는 호스트 이름
  • fsid서버 측 비영구적으로 할당된 파일 시스템 ID

rpc.statd

NFS 공유가 하드 마운트된 경우 공유에 액세스하는 모든 프로세스는 NFS 서버를 다시 시작하는 동안 중단되지만 NFS 서버가 완전히 가동되어 다시 실행되면 자동으로 재개됩니다. 만약 그렇게 되지 않는다면 뭔가 잘못된 것입니다.

NFS 버전 4의 모든 복구 기능은 동일한 네트워크 포트(일반적으로 2049/TCP)를 사용하지만 이전 프로토콜 버전에는 일반적으로 이라는 별도의 서비스로 네트워크 상태 모니터 하위 프로토콜이 있습니다 rpc.statd. 이 프로세스는 클라이언트에서 실행되어야 합니다.그리고rpc.statdNFS 클라이언트와 서버 모두 서로의 네트워크 에 연결할 수 있어야 합니다 . 그렇지 않으면 두 시스템 중 하나를 다시 시작한 후 NFS 연결이 제대로 복구되지 않을 수 있습니다. (바라보다man sm-notify자세한 내용이 필요한 경우. NSM OPERATION IN DETAIL; 은 sm-notify다시 시작 알림을 사전에 보내는 구성 요소입니다 rpc.statd. 라는 단락을 찾으세요. )

역사적으로 rpc.statd동적으로 할당된 포트 번호가 있으면 먼저 portmapper/ rpcbind서비스(항상 포트 111, UDP 및 TCP)에 현재 사용 중인 포트 번호를 쿼리해야 합니다 rpc.statd.

이렇게 동적으로 할당된 포트는 최신 방화벽 네트워크에서는 바람직하지 않습니다. 모범 사례는 필요한 최소한의 포트 수에서만 트래픽을 허용하는 것이기 때문입니다. 따라서 NFSv2/v3 서버와 해당 클라이언트 사이에 방화벽이 있는 경우 rpc.statdNFSv2/v3 하위 프로토콜과 다른 NFSv2/v3 하위 프로토콜이 고정 포트 번호를 사용하도록 하는 것은 NFS 안정성을 향상시키는 중요한 단계입니다.

정확한 프로세스는 운영 체제와 해당 버전에 따라 다릅니다. 결국 일반적으로 프로세스에 옵션과 포트 번호를 추가하는 문제로 끝나지만 rpc.statd많은 운영 체제와 Linux 배포판에는 이에 대한 일부 기능이 포함되어 있으므로 주석 처리를 제거할 수 있습니다. 시작 구성 파일의 설정 또는 스크립트의 셸 변수 rpc.statd.

NFSv3 서버에서는 및 / rpc.mountd의 포트 번호 도 고정 값으로 잠겨야 합니다. 클라이언트에서는 신경만 쓰면 됩니다 ( NFS에서 파일 잠금을 사용할 수도 있음).lockdnlockmgrrpc.statdlockd

RHEL 7 이하에서는 끝에 다음 줄을 추가하여 이를 달성할 수 있습니다 /etc/sysconfig/network.

LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047
# PCNFSD_PORT=4048
RQUOTAD_PORT=4049

RHEL 8 이상에는 .txt 파일에 주석 처리된 예제 행이 있습니다 /etc/nfs.conf. 행을 주석 처리하고 편집하여 다음을 생성합니다.

[lockd]
port=4045
udp-port=4045

[mountd]
port=4047

[statd]
port=4046

Debian 및 관련 배포판에서 필요한 설정은 다른 파일에 있습니다:

  • STATDOPTS="-p 4046"존재하다/etc/default/nfs-common
  • RPCMOUNTDOPTS="-p 4047"존재하다/etc/default/nfs-kernel-server
  • options lockd nlm_udpport=4045 nlm_tcpport=4045in /etc/modprobe.d/nfs-options.conf(존재하지 않는 경우 생성).

이러한 설정을 추가하고 적절한 NFS 서비스를 다시 시작(또는 재부팅)한 후 rpcinfo -pNFSv3 하위 프로토콜이 이제 고정 포트 번호를 가져오는 것을 확인할 수 있습니다.

(위의 포트 번호도NetApp NAS 장치용 NFSv3 서비스기본적으로 사용되지만 NetApp은 rpc.mountd포트 635에 배치됩니다. )

CPU 이름

프로토콜은 rpc.statdIP 주소가 아닌 호스트 이름을 사용합니다. 클라이언트와 서버 모두 IP 주소에서 표준 호스트 이름을 찾을 수 있어야 합니다. 이것이 가능하지 않으면 sm-notify유효한 다시 시작 알림을 NFS 연결의 반대편으로 보낼 수 없으며 다시 시작 후 복구가 실패할 수 있습니다.

NFS 프로토콜에는 비대칭성이 있습니다. NFS 서버는 클라이언트의 호스트 이름( caller_nameNFS 프로토콜에서는 s라고 함)을 자동으로 학습하여 이를 서버에 제공 rpc.statd하지만 클라이언트에 서버의 호스트 이름을 알리는 동등한 상호 작용은 없습니다. 따라서 mountIP 주소 지정 명령을 사용하고 클라이언트가 해당 IP 주소를 호스트 이름에 역방향 매핑할 수 없는 경우 클라이언트는 NFS 서버에 다시 시작 알림을 보낼 때 NFS 서버가 자체적으로 호출할 이름을 알 수 없습니다. 고객 rpc.statd.

mount이는 성공적인 서버 재시작에서 NFS 마운트를 자동으로 복구하려는 경우 명령에 IP 주소를 사용하는 것이 좋지 않을 수 있음을 의미합니다 . 또한 클라이언트 mount명령에 사용된 이름이 NFS 서버에서 실제로 사용되는 이름과 일치하는지 확인해야 합니다.

비 fsid지속적

최신 Linux NFS 서버는 가능한 경우 자동으로 NFS용 파일 시스템 UUID를 사용합니다 fsid. 기본적으로 이러한 fsid은 지속적이어야 합니다.

그러나 이전 Unix 및 기타 NFS 구현에서는 여전히 이전 스타일의 작은 정수를 사용할 수 있으며 fsid, 일부는 달리 구성하지 않는 한 비영구적인 방식으로 무작위로 할당할 수도 있습니다. 그렇다면 NFS 서버가 다시 시작된 후 클라이언트는 stale file handle공유가 마운트 해제되었다가 다시 마운트될 때까지 마운트된 NFS 공유에 액세스하려고 할 때 오류 메시지를 생성합니다. 이 문제에 대한 해결책은 fsid이러한 항목이 NFS 서버에 지속적으로 할당되도록 하는 것입니다.

(내결함성 NFS 서버 역할을 하는 장애 조치 클러스터(HP ServiceGuard)로 실행되는 세 개의 HP-UX 시스템에서 이런 일이 발생하는 것을 보았습니다. fsid이러한 s가 NFS 내보내기/공유 구성에 명시적으로 정의되지 않은 경우 클라이언트는 장애 조치 클러스터링의 목적을 무효화하는 한 노드에서 다른 노드로의 NFS 서비스로 인해 fsid장애 조치가 예상대로 작동하기 시작했습니다.

관련 정보