Cisco 스위치와 LAN의 카테고리 6 유선 케이블을 사용하여 RHEL 7.9를 실행합니다. 어떤 종류의 네트워크 문제가 있을 때(때때로 내가 아는 한 네트워크 문제가 아닐 때도 있음) NFS 클라이언트에서 NFS 때문에 Linux가 중단됩니다. 이유는 무엇입니까?
예를 들어
- NFS vers=4.1은 기본 설정으로
/etc/nfs.conf수정 없이 쉽게 발생합니다./etc/sysconfig/nfs - 서버 A 내보내기
/data /data서버 A에서 서버 B 설치- 어떤 종류의 네트워크 중단이 발생하는 경우 서버 A 또는 B에서 Cat6 케이블을 뽑고 다시 연결하면 됩니다. 네트워크가 다시 연결되고 SSH와 같은 기능은 서버 A와 B 간에는 제대로 작동하지만 NFS 클라이언트인 경우 서버 B에서는 문제가 발생합니다. 이 상황에서는 다음 유형의 문제를 해결하는 방법을 모르겠습니다.
- NFS 오래된 핸들
/data - Ctrl-C가 완료될 때까지 작업 실행이
ls /터미널 창에서 중단됩니다. - ctrl-c가 완료될 때까지 a 실행이
df -h터미널 창에서 중단됩니다. - 하나만 해도
umount /data중단됩니다. - 믿을 수 있는 유일한 해결책은 NFS 클라이언트를 다시 시작하는 것 같습니다.
- NFS 오래된 핸들
누군가 이 문제가 발생하는 이유를 설명할 수 있습니까? 특히 lsand df? NFS 문제를 해결하는 방법에 대한 지침이 있습니까? 작동이 멈추면 마치 블랙박스를 사용하는 듯한 느낌이 들고 재부팅만 하면 해결됩니다.
답변1
다음에 이 문제가 발생하면 /proc/fs/nfsfs/volumes서버 B를 확인하세요. 마운트된 NFS 파일 시스템 목록을 찾아야 합니다.FSID각각. 매달린 설치의 FSID를 기록해 두십시오. 그런 다음 클라이언트를 다시 시작하고 NFS 볼륨을 마운트한 후 다시 확인하세요. FSID는 동일하게 유지되어야 합니다. 변경된 경우에도 마찬가지입니다.
/dataFSID가 계속 변경되는 경우 내보내기가 수행되는 서버 A에서 내보낸 실제 파일 시스템 유형은 무엇입니까?
파일 시스템에 실제 UUID가 없거나 파일 시스템을 보유하는 장치의 장치 번호가 다를 수 있는 경우(서버 A의 핫 플러그 또는 관리 작업으로 인해) 어떤 이유로 서버 A에 유효한 영구 FSID 소스가 없는 경우 서버 A는 이를 동적으로 생성해야 할 수 있습니다.
서버 B가 서버 A에 다시 연결하려고 할 때 다른 FSID를 확인하는 경우 서버 B가 다시 연결하는 NFS 공유가 이전과 정확히 동일하지 않으며 서버 B의 캐시된 데이터가 있다고 가정합니다.오래된주식은 다음에 적용되지 않을 수 있습니다.새로운하나.
이는 서버 B를 문제에 빠뜨립니다. 열린 파일 핸들과 캐시된 데이터가 구체적으로 참조됩니다.오래된공유는 어디에도 없는 것 같습니다. 그냥 맹목적으로 적용해 보세요새로운공유는 데이터 손실을 일으키는 버그일 수 있습니다. 그리고 커널은안 돼요명시적인 통지 없이 의도적으로 사용자 데이터를 손실합니다.
커널에 쓰기 대기 중인 캐시된 데이터가 있는 경우오래된umount /data공유하면 서버 B의 정상적인 작업이 실제로 중단되지만 umount -l /data작동해야 합니다. 불행하게도 이 방법을 사용하면 보다 깔끔하게 종료할 수만 있습니다. umount -l마운트 해제된 파일 시스템에 대한 참조를 보유한 모든 프로세스가 먼저 중지하지 않는 한 마운트 해제된 공유를 다시 마운트하는 것은 불가능할 수 있습니다.
NFS 공유에 고정 FSID가 없는 경우 서버 A fsid=<number>|root|<uuid>에 옵션을 추가하여 /etc/exports고정 FSID(유효한 UUID 또는 레거시 호환성을 위한 단일 작은 정수)를 지정해야 할 수도 있습니다.
서버 B가 서버 A의 NFS 공유가 처음 연결되었을 때와 동일한 FSID로 다시 연결된다는 사실을 발견하면 자동으로 다시 연결을 계속할 수 있습니다.
답변2
이것이 NFS의 특징입니다. 1990년대에 내가 유닉스를 사용하기 시작했을 때도 마찬가지였다.
-o soft이 옵션으로 설치해 보셨나요 ? 도움이 되는지 확인해 보세요.
nfs 매뉴얼 페이지는 다음과 같습니다.
soft / hard Determines the recovery behavior of the NFS client after an NFS request times out. If neither option
is specified (or if the hard option is specified), NFS requests are retried indefinitely. If the soft
option is specified, then the NFS client fails an NFS request after retrans retransmissions have been
sent, causing the NFS client to return an error to the calling application.
NB: A so-called "soft" timeout can cause silent data corruption in certain cases. As such, use the soft
option only when client responsiveness is more important than data integrity. Using NFS over TCP or
increasing the value of the retrans option may mitigate some of the risks of using the soft option.
답변3
경우에 따라 다음을 사용하여 복원할 수 있습니다.
mount -o remount /nfs/mountpoint
실패하면 강제로 제거할 수 있습니다. 그렇게 하면 손상될 위험이 있지만 재부팅과 동일한 위험이 있을 수 있습니다.
umount -f /nfs/mountpoint