클라이언트에 표시되는 내보내기 경로를 변경하지 않고 NFS 데이터 세트를 재구성하는 방법

클라이언트에 표시되는 export 네임스페이스를 안정적으로 유지한 채 그 뒤에서 스토리지를 이동하면, 오래된 클라이언트 핸들 없이도 NFS 데이터셋을 재구성할 수 있습니다.

예방을 위한 설계는 클라이언트가 마운트하는 경로와 나중에 변경할 수 있는 실제 데이터셋 이름을 분리하는 것입니다. 안정적인 export 트리를 구축하고, 데이터셋을 그 안에 의도적으로 매핑하며, 가능한 경우 파일 시스템 ID를 유지하고, 파괴적인 교체 전에 클라이언트를 중지한 뒤, 전환 후에도 동일한 export 경로가 사용되는지 확인하세요. 서버에서 백업 파일 시스템을 삭제하고 다시 만들어야 한다면 이를 ID 변경으로 간주하고, 보이지 않는 연속성을 약속하는 대신 클라이언트의 일괄 재마운트를 계획해야 합니다.

데이터셋 위에 안정적인 Export 네임스페이스 만들기

클라이언트에 표시되는 이름이 내부의 모든 ZFS 또는 Btrfs 데이터셋 이름을 그대로 반영하지 않도록 전용 NFS export 루트를 사용하세요. 그러면 스토리지 관리자가 백엔드 데이터셋을 재구성하더라도 모든 클라이언트에 새 마운트 경로를 알려줄 필요가 없습니다.

NFSv4 설계 논의에서는 의도적으로 관리되는 의사 파일 시스템 아래에서 bind mount로 안정적인 export를 만드는 방법을 설명합니다.

클라이언트 경로를 호환성 계약으로 문서화하세요. 내부 데이터셋 이름은 나중에 변경할 수 있지만, 먼저 export 계층을 동일한 경로에 맞게 다시 매핑하고 테스트해야 합니다.

검색 순서에 의존하지 말고 Export ID 고정하기

현재 서버에서 사용하는 파일 시스템 UUID, export 경로, NFS 버전, 명시적 fsid 설정을 기록하세요. NFS 서버가 이동 후 기본 파일 시스템을 다르게 식별한다면, 동일한 디렉터리 이름만으로는 충분하지 않습니다.

SUSE는 NFS가 각 export 파일 시스템을 식별한다고 설명하며, export를 단순한 경로 별칭으로 취급하지 않습니다.

NFS 구현에서 지원하는 경우에만 명시적 식별자를 사용하고, 각 값이 고유하도록 유지하세요. 두 파일 시스템을 동시에 export하면서 동일하게 보이게 하려고 하나의 fsid를 두 파일 시스템에 복사하지 마세요.

동일한 Export 경로 뒤에 새 데이터셋 준비하기

교체할 데이터셋을 서버의 임시 경로에 생성하거나 수신하고, 콘텐츠를 복사 또는 복제한 뒤, 권한을 확인하세요. 그런 다음 유지 관리 시간 동안 안정적인 export 트리에 매핑합니다. 롤백을 위해 기존 데이터셋은 사용할 수 있는 상태로 유지하되, 동일한 export ID로 활성화하지는 마세요.

NFS export 예시에서는 여러 파일 시스템이 하나의 NFS 네임스페이스 아래에 나타날 때 마운트된 하위 트리를 의도적으로 export하는 방법을 보여줍니다.

전환 시에는 클라이언트 마운트 정의와 데이터셋 ID를 동시에 변경하지 말고, 서버 측 매핑 하나만 변경해야 합니다. 그러면 새 트리가 잘못되었을 때 문제 해결에 필요한 단서를 그대로 유지할 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

백업 파일 시스템을 교체하기 전에 쓰기 작업 중지하기

NFS 마운트를 통해 활발하게 쓰기 작업을 수행하는 서비스를 중지하거나 일시 중지한 다음, 중요한 클라이언트가 전환 중 장시간 파일 작업을 유지하고 있지 않은지 확인하세요. 쓰기 작업을 중지한 후에 최종 동기화를 완료합니다.

IBM은 NFSv4 상태에 안정적인 스토리지가 필요하다고 설명합니다. 클라이언트 상태는 서버 측 파일 콘텐츠뿐 아니라 연속성의 일부이기 때문입니다.

홈 서버에서는 클러스터 장애 조치보다 목표가 단순합니다. 실행 중인 애플리케이션에서 파일 ID가 변경되지 않도록 하세요. 짧고 통제된 일시 중지가 데이터베이스, 미디어 또는 백업 클라이언트가 실시간 파일 시스템 교체를 견디도록 강제하는 것보다 안전합니다.

클라이언트 재마운트가 불가피한 경우 파악하기

재구성 과정에서 파일 시스템을 삭제하고 다시 만들거나, 새 파일 시스템으로 스냅샷을 복원하거나, 서버 측 파일 핸들 ID가 변경된다면 서버 경로가 안정된 후 일괄 언마운트 및 재마운트를 계획하세요.

최신 NFS 문제 해결 가이드에서는 서버 ID 변경으로 오래된 핸들이 발생한다고 설명하며, 문제가 반복될 때 안정적인 서버 ID를 확인할 것을 권장합니다.

기본 ID가 실제로 변경되는 상황에서 “재마운트 없이 유지 관리”를 내세우지 마세요. 애플리케이션이 정상적인 쓰기 작업 중 ESTALE 오류를 발견하게 두는 것보다, 문서화된 재마운트 시간을 마련하는 편이 낫습니다.

기존 데이터셋을 폐기하기 전에 클라이언트 경로 테스트하기

새 클라이언트와 기존의 중요하지 않은 클라이언트 한 대에서 export를 마운트한 다음, 디렉터리 ID, 권한, 대표적인 읽기 작업, 되돌릴 수 있는 쓰기 작업 하나, 애플리케이션이 예상하는 경로를 비교하세요. 클라이언트 한 대를 재부팅해 영구 마운트 설정이 변경되지 않았는지도 확인합니다.

Arch Linux 사례에서는 별도의 export 루트, bind mount, 명시적 파일 시스템 ID를 사용해 반복적으로 발생하던 오래된 핸들 문제를 해결했으며, 안정적인 NFS 루트가 백엔드 파일 시스템 변경 후 ESTALE을 방지한다는 사실을 보여줍니다.

클라이언트가 계속 기존 export 경로를 사용하고, 숨겨진 참조 없이 기존 데이터셋을 폐기할 수 있다면 재구성이 완료된 것입니다. ESTALE이 이미 발생했다면 데이터셋 이름 변경 후 오래된 핸들에 관한 관련 ZimaSpace 문서에서 복구 절차를 확인하세요.