NFS 서버 재부팅 후 NFS 오래된 파일 처리: 이런 일이 발생하는 이유는 무엇이며 업계에서는 이를 어떻게 처리합니까?

Question 1

포트 2049의 기본 NFS 서비스 외에 여러 도우미 서비스가 필요한 NFS 버전 3을 사용하고 있습니다. 이 중 하나는 rpc.statd재부팅을 감지하고 재부팅 후 NFS 잠금을 복구/삭제하는 데 중요한 역할을 합니다.

rpcbind이러한 도우미 서비스는 임의의 포트에 위치할 수 있으며 RPC 포트 매퍼(일반적 으로 최신 Linux에서 명명된 프로세스)에 연결하여 검색됩니다 . 방화벽이 있는 최신 네트워크에서는 이러한 동작으로 인해 문제가 발생할 수 있습니다. 재부팅 후 결정적으로 보이는 포트에서 해당 포트를 찾을 수 있더라도 NFS 서비스를 다시 시작하면 완전히 다른 포트 번호에 할당될 수 있습니다.

다행스럽게도 많은 최신 Unix 계열 시스템에서는 NFS 잠금 관리자(역사적으로는 현재 일반적 으로 rpc.lockd커널 내에서 구현됨) 의 포트 번호를 잠글 수 있습니다 rpc.statd. rpc.mountd이는 어떤 종류의 신뢰성을 가지고 방화벽을 통해 NFSv3을 통과시키려는 경우 필수적입니다.

RHEL 및 관련 배포의 경우 다음 줄을 추가하여 NFS 도우미 포트 번호를 잠글 수 있습니다 /etc/sysconfig/network.

LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047

Debian 및 관련 배포판의 경우 다음 행을 다음에 추가할 수 있습니다 /etc/modprobe.d/nfs.conf.

options lockd nlm_udpport=4045 nlm_tcpport=4045

... 그리고 다음 줄은 다음과 같습니다 /etc/default/nfs-common.

STATDOPTS="-p 4046"

... 그리고 다음 줄은 다음과 같습니다 /etc/default/nfs-kernel-server.

RPCMOUNTDOPTS="-p 4047" # you may want to add a --manage-gids option here

(원하는 경우 다른 포트 번호를 사용할 수 있지만 4045는 Solaris에서 NFSv3 잠금 관리자의 기본 포트이고 HP-UX 11.31에서는 동일하게 하드 코딩되어 있습니다.)

그러나 NFSv3 프로토콜에는 또 다른 함정이 있습니다. IP 주소만 사용하여 NFS 공유를 성공적으로 탑재할 수 있지만 NFSv3 잠금 프로토콜은 내부적으로 호스트 이름을 사용합니다. 클라이언트와 서버는 모두 올바른 이름으로 서로를 알아야 합니다. 그렇지 않으면 재부팅 후 NFS 파일 잠금 및 잠금 복구가 작동하지 않습니다. 그리고 각 시스템의 "올바른 이름"은 에서 보고한 이름입니다 uname -n.

따라서 서버와 클라이언트에서 각각 uname -n반환되는 경우 해당 정확한 이름이 호스트가 NFS에 사용해야 하는 IP 주소로 확인되는지 확인해야 합니다. 즉, 서버는 이름을 사용하여 클라이언트에 접속할 수 있어야 하며 그 반대의 경우도 마찬가지입니다.server.exampleclient.examplerpc.statdclient.example

그렇지 않으면 처음에는 모든 것이 잘 작동하는 것처럼 보일 수 있지만 재부팅할 때 Stale file handle오류가 발생할 수 있습니다.

Answer