데이터셋 이름 변경 후 오래된 NFS 파일 핸들을 해결하는 방법

데이터셋 이름을 변경한 후 NFS 파일 핸들이 오래된 상태로 남는 것은 일반적으로 클라이언트가 서버에서 변경된 객체나 내보내기 식별자에 대한 참조를 계속 보유하고 있다는 의미입니다.

가장 안전한 복구 방법은 한 클라이언트만 오래된 상태인지, 아니면 내보내기 식별자 자체가 변경되었는지 확인하고, 마운트를 적극적으로 사용하는 애플리케이션을 중지한 다음, 이름을 변경한 데이터셋이 의도한 경로에서 내보내지고 있는지 검증한 후 클라이언트를 정해진 순서로 다시 마운트하는 것입니다. 오래된 핸들이 캐시된 한 클라이언트 마운트에서만 발생하는지, 이름을 변경한 내보내기에 연결하는 모든 클라이언트에서 발생하는지 확인하기 전에는 모든 시스템을 재부팅하거나 데이터셋을 다시 생성하지 마세요.

데이터셋 이름 변경 시 오류가 시작되었는지 확인

기존 데이터셋 이름과 마운트 지점, 새 데이터셋 이름과 마운트 지점, 내보낸 경로, 그리고 ESTALE을 반환한 첫 번째 클라이언트 작업을 기록하세요. 영향을 받은 클라이언트와 이름 변경 후에만 공유 폴더를 마운트한 클라이언트를 비교하세요.

최근 NFS 문제 해결 글에서는 오래된 상태는 핸들이 변경되었다는 의미이며, 단순히 네트워크 경로가 중단되었다는 뜻은 아니라고 설명합니다.

새 클라이언트의 마운트는 정상적으로 작동하지만 기존 클라이언트가 실패한다면, 이름을 변경한 내보내기는 연결 가능하고 즉각적인 문제는 기존 클라이언트의 캐시된 상태일 가능성이 높습니다. 새로 마운트한 클라이언트에서도 실패한다면 서버의 내보내기와 데이터셋 식별자를 계속 조사하세요.

내보내기가 이제 의도한 데이터셋을 가리키는지 확인

이름을 변경한 후 서버의 활성 내보내기 목록과 파일시스템 마운트 테이블을 확인하세요. 경로가 계속 존재하더라도 이제 다른 데이터셋, 비어 있는 마운트 지점, 또는 잘못된 파일시스템 아래의 디렉터리로 해석될 수 있습니다.

OneUptime은 객체, 내보내기, 파일시스템 ID 또는 복원된 데이터가 변경되면 내보내기 변경으로 인해 핸들이 무효화될 수 있다고 설명합니다.

클라이언트를 조작하기 전에 내보내기 대상을 바로잡으세요. 잘못된 서버 측 경로를 다시 마운트하면 ESTALE이 해결된 것처럼 보이지만, 애플리케이션이 다른 디렉터리 트리를 사용하게 될 수 있습니다.

기존 마운트를 계속 보유한 프로세스 중지

클라이언트의 마운트 및 프로세스 도구를 사용해 기존 NFS 마운트를 계속 열어 둔 셸, 미디어 서버, 백업 작업, 컨테이너 또는 데이터베이스 프로세스를 확인하세요. 강제 마운트 해제를 수행하기 전에 영향을 받은 서비스 중 최소한의 범위만 중지하세요.

집중적인 Linux 복구 가이드에서는 다시 마운트하기 전에 프로세스를 확인할 것을 권장합니다. 그래야 복구 과정에서 프로세스가 반쯤 분리된 파일시스템 뷰에 남지 않습니다.

오래된 경로를 사용하는 주체가 컨테이너 하나뿐이라면 먼저 해당 컨테이너를 중지하세요. 여러 서비스가 마운트를 공유한다면, 실행 중인 애플리케이션 스택 전체에서 즉시 지연 마운트 해제를 수행하기보다 짧은 유지보수 시간을 예약하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

서버 경로가 안정된 후 클라이언트 다시 마운트

서버 내보내기가 올바르고 종속 서비스가 중지되었으면, 테스트 클라이언트 하나에서 NFS 공유를 마운트 해제한 다음 다시 마운트하세요. 운영 환경에서 유지할 서버 주소, 내보내기 경로, NFS 버전 및 마운트 옵션을 그대로 사용하세요.

NFS 마이그레이션 사례에서는 스토리지를 이동한 후 클라이언트에 새 마운트가 필요하다는 점을 보여 줍니다.

다른 모든 클라이언트를 다시 마운트하기 전에 디렉터리 목록 조회, 읽기 한 번, 되돌릴 수 있는 쓰기 한 번, 실제 애플리케이션 경로를 테스트하세요. 같은 클라이언트가 즉시 다시 오래된 상태가 된다면 마운트를 반복하기보다 서버 식별자를 다시 확인하세요.

이름 변경으로 파일 핸들 식별자가 변경되었는지 확인

NFS 파일 핸들은 일반적인 경로 문자열이 아닙니다. 파일시스템 및 inode 관련 정보를 포함할 수 있는 서버 정의 식별자를 인코딩하므로, 표시되는 내보내기 경로가 비슷해도 기반 파일시스템을 교체, 복원 또는 이동하면 문제가 발생할 수 있습니다.

파일 핸들을 심층적으로 설명한 글에서는 파일 핸들이 텍스트 경로의 책갈피처럼 작동하는 것이 아니라 서버 식별자에 매핑된다고 설명합니다.

이번 이름 변경이 실제로 데이터셋 삭제 및 재생성, 수신, 복제 또는 복원 작업의 일부였다면 더 큰 식별자 변경 사항을 기록하세요. 기존 핸들을 무기한 유지하려 하기보다 모든 클라이언트를 조정하여 다시 마운트하는 것이 올바른 해결책일 수 있습니다.

재부팅 후 모든 클라이언트가 새 내보내기를 사용하는지 확인

첫 번째 클라이언트가 정상적으로 작동하면 나머지 클라이언트를 한 번에 하나씩 다시 마운트하고, 종속 서비스를 복원한 다음, 구성된 마운트 유닛이나 컨테이너 바인드 경로가 의도한 내보내기를 참조하는지 확인하세요. 그런 다음 중요하지 않은 클라이언트 하나를 재부팅하여 지속성을 테스트하세요.

스토리지 문제 해결 글에서는 사용 중인 프로세스와 마운트 상태가 실제로 갱신될 때까지 오래된 마운트가 애플리케이션보다 오래 남을 수 있다고 설명합니다.

새로 마운트한 클라이언트와 재부팅한 클라이언트가 모두 ESTALE 없이 이름을 변경한 데이터셋을 마운트하고, 애플리케이션이 예상한 파일을 읽는다면 복구가 완료된 것입니다. 데이터셋 이름 변경으로 로컬 바인드 경로나 애플리케이션 경로도 변경된 경우에는 관련 ZimaSpace 가이드인 안정적인 홈 서버 마운트 경로를 함께 참고하세요.

자주 묻는 질문

오래된 NFS 파일 핸들이 디스크 고장을 의미할 수 있나요?

그 자체만으로는 그렇지 않습니다. ESTALE은 클라이언트의 캐시된 핸들이 더 이상 예상하는 서버 측 객체를 식별하지 못한다는 의미입니다. 서버에서도 I/O 또는 파일시스템 오류를 보고하는 경우에는 스토리지 상태를 별도로 확인하세요.

NFS 서비스를 다시 시작하면 항상 문제가 해결되나요?

아니요. 내보내기가 이제 다른 데이터셋 식별자를 가리킨다면 기존 클라이언트 핸들은 여전히 잘못된 상태로 남습니다. 먼저 내보내기를 확인한 다음 클라이언트 마운트를 신중하게 갱신하세요.

데이터셋 이름을 변경한 후 모든 클라이언트를 재부팅해야 하나요?

대부분의 경우 그렇지 않습니다. 서버 내보내기가 올바르다면 서비스를 통제된 방식으로 중지하고 다시 마운트하는 것으로 충분합니다. 클라이언트가 오래된 마운트를 정상적으로 해제하지 못할 때나 최종 지속성 테스트를 수행할 때만 재부팅하세요.