VPN을 통한 NFS 재내보내기는 패킷 포워딩이 아니다

Linux 머신이 VPN에 가입하고 원격 NFS 내보내기를 마운트한 뒤 그 마운트를 다른 클라이언트 집합에 제공한다. 이런 구성은 단계가 더해진 라우팅처럼 보인다는 첫 번째 잘못된 가정이다. 중간 기계는 상류 서버의 클라이언트이자 하류 클라이언트의 서버이며 두 파일 서비스 관계에 모두 참여한다. 패킷 포워딩은 파일 핸들, 잠금, 파일 시스템 정체성에 대해 아무 의견이 없지만 재내보내기는 그렇지 않다.

하류 클라이언트가 원래 서버에 직접 도달할 수 있었는지부터 물어보라. 도달할 수 있다면 중간 기계는 선택 사항이다.

세 가지 모델, 세 가지 일관성 이야기

직접 마운트가 가장 단순하다. 각 클라이언트가 터널을 통해 원래 서버를 마운트하고, 그 서버의 내보내기 정책이 접근을 지배한다. 재내보내기는 중간 기계가 다른 서비스 경계를 제시하는 것으로, 클라이언트 쪽 네트워크가 서버에 직접 도달해서는 안 될 때 유용하다. 복제는 세 번째 모델이며 질문을 일관성에서 동기화와 충돌 해결로 옮긴다.

복제된 사본을 살아 있는 재내보내기처럼 묘사하지 마라. 실패 양상이 다르고, 모든 작업이 원래 파일 시스템에 도달하리라 기대하는 사용자는 링크 단절 중에 놀랄 것이다.

정체성은 마운트 명령보다 오래 산다

재내보내기에는 명시적 파일 시스템 ID가 필요하고, 그 정체성은 재시작과 구성 재구성을 견뎌야 한다. 커널 문서는 이 요구 사항을 분명히 밝히며, 또한 다음과 같이 경고한다.crossmnt 는 자식 파일 시스템을 자체 ID로 내보내야 할 필요를 없애지 않는다. 사용자에게 연속적으로 보이는 디렉터리 트리가 여러 파일 시스템 경계를 넘을 수 있다. 현재 nfs-utils는 지원되는 구성에 대해 ID를 자동으로 할당할 수 있고, 그렇게 하면 그 데이터베이스가 게이트웨이 상태의 일부가 된다. 이러한 ID를 일회용 파일이 아니라 서비스 정체성으로 취급하라.

파일 핸들은 또 다른 정체성 경계다. 재내보내기는 원래 핸들을 감싸므로 더 커지고 클라이언트의 한도를 초과할 수 있다. 성공적인 마운트는 모든 내보내기 배치가 호환된다는 것을 증명하지 않는다.

모든 NFS 기능이 중간 기계를 살아남지는 않는다

커널의 재내보내기 안내서는 재내보내기하는 서버가 잠금이나 위임 요청을 지원하지 않는다고 밝힌다. 그런 작업에 의존하는 애플리케이션에는 다른 경로나 그에 대해 검증된 설계가 필요하다. 성공적인 마운트와 작동하는 디렉터리 목록은 애플리케이션의 실제 작업이 작동한다는 것을 보여 주지 않는다.

사용자 정체성과 내보내기 정책도 각 홉에서 중요하다. VPN 로그인은 네트워크 참여자가 인증되었음을 증명하지만, NFS 사용자를 승인하지 않으며 클라이언트의 자격 증명을 게이트웨이 너머로 전달하지 않는다.

게이트웨이에는 두 가지 상류 의존성이 있다

게이트웨이는 상류 마운트를 위해 VPN에, 파일 시스템 자체를 위해 상류 서버에 의존한다. 아직 실행 중인 로컬 내보내기 프로세스는 사용할 수 없는 스토리지를 건강하게 만들 수 없다. 시작 순서, 재연결 동작, 서버 재시작을 계획하고, 클라이언트가 이미 보유한 파일 핸들이 어떻게 되는지도 포함하라. 게이트웨이를 통해 마운트했다가 핸들을 잃은 클라이언트는 다시 마운트해야 하며, 그것은 투명한 복구가 아니라 운영상의 사건이다.

요구 사항이 필요로 했던 것이 사설 IP 도달성뿐이었다면, 원래 서버로 직접 라우팅하는 것이 더 단순한 아키텍처다. 재내보내기는 문서로 남겨도 살아남는 이유로 존재해야 한다.

마운트가 아니라 워크로드를 시험하라

통제된 환경에서 실제 파일 워크로드를 연습하라. 애플리케이션이 수행하는 작업, 사용하는 파일 크기, 기대하는 동시성을 포함하라. 전송 오류만이 아니라 기능 격차를 지켜보고, 어떤 모델을 선택했고 왜 그랬는지 기록하라. 그렇지 않으면 다음 사람이 게이트웨이를 라우터로 가정할 것이다.

재내보내기는 의도적인 이유가 있을 때 정당하다. 예를 들어 격리된 클라이언트 네트워크나 통제된 버전 경계 같은 것이다. 그것은 나쁜 사고이며, 차이는 누군가 그것을 결정했는지 여부다.