이름이 변경된 데이터 세트와 안정적인 파일 핸들을 위한 NFS 마이그레이션 체크리스트

안전한 접근 방식은 가능하면 클라이언트에 제공되는 네임스페이스를 유지하고, 파일 핸들 식별자가 변경될 때 의도적으로 클라이언트를 다시 마운트하는 일시 중지된 익스포트 마이그레이션을 단일 명령이 아닌 관찰 가능한 단계들의 연속으로 취급하는 것입니다.

홈 서버 클라이언트가 사용하는 NAS 데이터셋을 Linux NFS 서버에서 마이그레이션할 때의 실질적인 위험은 익스포트된 데이터셋의 이름을 바꾸거나 이동하면 클라이언트에 오래된 NFS 파일 핸들이 남거나 다시 마운트하지 못할 수 있다는 점입니다. 현재 식별 정보와 복구 지점을 기록하고, 가장 영향이 적은 판별부터 시작한 다음, 다른 변수를 변경하기 전에 성공 및 실패 결과를 해석하고, 스토리지가 불안정해지거나 복구 가능한 유일한 사본이 노출될 상황에서는 중단하세요. 아래 워크플로는 원래 워크로드가 성공하거나 증거가 에스컬레이션 경계에 도달한 경우에만 종료됩니다.

익스포트 및 파일 핸들 종속성 목록 작성

소스 파일 시스템 또는 데이터셋 식별 정보, 서버 측 경로, NFSv4 의사 루트, 익스포트 옵션, 명시적인 fsid 값, 클라이언트 마운트 경로, autofs 또는 systemd 유닛, 그리고 해당 마운트를 사용하는 모든 컨테이너나 애플리케이션을 기록하세요. 다운타임을 계획하기 전에 활성 마운트와 열린 파일을 캡처하세요.

NFS 파일 핸들은 서버가 선택한 객체 식별 정보를 인코딩하므로 파일 시스템을 이동한 후 경로 문자열이 변하지 않았다고 해서 핸들이 안정적이라는 보장은 없습니다. 독립적인 NFS 오래된 파일 핸들 메커니즘 설명에서는 디렉터리가 눈에 보이게 존재하더라도 삭제, 재생성 또는 다시 매핑된 익스포트가 어떻게 오래된 핸들을 만드는지 설명합니다.

목표가 네임스페이스 안정성인지 실시간 핸들 연속성인지 결정하세요. 클라이언트에 제공되는 경로를 유지하면 구성 변경을 줄일 수 있지만, 데이터를 다른 파일 시스템으로 이동하면 모든 클라이언트가 마운트를 해제하고 새 핸들을 받아야 할 수 있습니다.

클라이언트가 소스에 연결된 동안 대상 준비

대상 데이터셋을 만들고, ACL, 소유자, 확장 속성, 하드 링크, 스파스 파일 및 타임스탬프를 보존하면서 데이터를 복사한 다음 개수와 대표 해시를 비교하세요. 대상이 운영 클라이언트에 노출되기 전에 익스포트 보안 설정과 ID 매핑을 일치시키세요.

Linux 서버 간 NFSv4 ID를 일치시키려면 ZimaSpace의 NFSv4 ID 매핑 가이드를 사용하세요. 안정적인 파일 핸들이 숫자 소유권이나 이름 도메인 불일치를 해결해 주지는 않으므로 파일 식별 계층과 사용자 식별 계층을 독립적으로 검증하세요.

복사 방식이 이를 지원하는 경우에만 소스가 활성 상태인 동안 초기 동기화를 수행한 다음, 최종적으로 중지된 상태에서 변경분을 동기화할 계획을 세우세요. 같은 클라이언트 네임스페이스에서 두 복사본을 모두 읽기-쓰기로 익스포트하지 마세요. 명확한 오류 없이 쓰기가 서로 달라질 수 있습니다.

클라이언트 일시 중지 및 익스포트 전환

모든 클라이언트에서 애플리케이션의 쓰기 작업, 컨테이너 및 예약된 작업을 중지한 다음, 중요한 프로세스가 마운트 아래의 파일을 보유하고 있지 않은지 확인하세요. 클라이언트의 마운트를 정상적으로 해제하세요. 최종 동기화 후 소스의 익스포트를 해제하거나 읽기 전용으로 전환하고, 서버 측 마운트 또는 익스포트를 대상으로 변경한 다음 익스포트를 다시 로드하세요.

GitLab의 NFS 이름 변경 및 오래된 상태 사례에 관한 엔지니어링 기록은 이름 변경 및 위임 동작으로 인해 클라이언트에서 오래되거나 일관되지 않은 관찰 결과가 나타날 수 있음을 보여줍니다. 안전한 운영 대응은 애플리케이션이 계속 쓰는 동안 캐시 삭제 명령을 반복하는 것이 아니라, 계획된 일시 중지와 다시 마운트하는 것입니다.

대상이 파일 시스템 식별 정보를 변경한다면 새 핸들이 생성될 것으로 예상하고 클라이언트를 새로 마운트하세요. 원래 익스포트를 운영 환경이 아닌 복구용 이름으로 계속 사용할 수 있게 두되, 이전 트리와 새 트리가 서로 경쟁하는 쓰기를 허용하도록 해서는 안 됩니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

모든 클라이언트를 다시 마운트하고 새 식별 정보 확인

먼저 카나리 클라이언트 하나를 다시 마운트하고 목록 조회, 읽기, 생성, 이름 변경, 삭제, 파일 잠금 및 소유권을 테스트하세요. 해당 클라이언트의 종속 애플리케이션을 다시 시작하고 원래 워크로드를 확인하세요. 그런 다음 나머지 클라이언트를 순차적으로 전환하면서 마운트 소스, NFS 버전 및 오래된 핸들 오류가 없는지 기록하세요.

카나리에서 자동 마운트를 재부팅하거나 다시 시작하여 영구 구성에서 안정적인 클라이언트 제공 네임스페이스를 가리키는지 확인하세요. 서버 로그, 클라이언트 커널, 백업 작업 및 컨테이너에서 숨겨진 이전 경로를 확인하세요. 수동 마운트가 성공했다고 해서 부팅 순서나 서비스 종속성이 올바르다는 뜻은 아닙니다.

모든 클라이언트가 다시 마운트되고, 일반 작업이 통과하며, 백업이 성공하고, 한 번의 복원이 테스트된 후에만 소스를 폐기하세요. 카나리에서 실패하면 새 쓰기를 허용하기 전에 롤백하세요. 대상에 쓰기가 시작된 후에는 익스포트를 앞뒤로 전환하지 말고 중지한 뒤 의도적으로 조정하세요.