VPN 뒤의 NFS: 부팅 시 마운트인가, 요청 시 자동 마운트인가

두 구성은 같은 문제를 풀고 반대 방향으로 실패한다. 공유를 부팅 시 마운트하면 모든 서비스가 거기 있거나 부팅이 멈춘 이유를 알려주는 파일 시스템을 얻는다. 요청 시 자동 마운트는 머신에 빠른 부팅을 주고 기다림을 경로를 처음 만지는 쪽에 넘긴다. VPN 뒤에서는 두 번째가 대개 더 나은 거래이며, 이유는 터널이 부팅 순서가 볼 수 없는 순서를 강요하기 때문이다.

부팅 시 마운트와 자동 마운트

부팅 시 마운트는 이해하기 단순하다. 파일 시스템 대상이 마운트를 기다리고, 그에 대한 의존성을 선언한 서비스가 그 뒤에 시작되며, 서버에 닿을 수 없으면 옵션에 따라 머신이 기다리거나 실패한다. 그 아래의 모든 것이 그 한 가지 결정을 물려받는다.

자동 마운트는 그 반대다. 경로가 즉시 존재하고, 실제 마운트는 무언가가 그것을 열 때 일어나며, 일찍 시작하는 서비스는 아직 올라오지 않은 터널에서 막히지 않는다.

비교는 지연을 누가 흡수해야 하는가로 귀결된다. 사용자가 작업하기 전에 공유가 필요한 워크스테이션은 아마 기다려야 한다. 가방 속에서 부팅하는 노트북이나 공유가 선택 사항인 서버는 기다리지 않아야 한다.

어느 옵션도 빠진 경로를 고치지 않는다. 둘 다 실패가 언제 관찰되는지만 정한다.

fstab 행, 옵션별로

기존 OpenVPN 클라이언트 인스턴스가 [email protected]이고 서버가 files.corp.example, 마운트 지점이 /mnt/work라고 하자. 세 가지를 모두 자기 사이트의 승인된 값으로 바꾼다. 쓸 만한 한 행은 이렇게 생겼다:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev는 마운트에 네트워크가 필요하다고 표시하며, 어떤 터널도 지목하지 않는다. nofail는 일반 파일 시스템 대상에 대해 공유를 선택 사항으로 유지한다. x-systemd.automount는 즉시 마운트하는 대신 요청 시 트리거를 만든다.

x-systemd.requires=는 마운트 시도를 VPN 유닛에 묶는 부분이며, 트리거가 아니라 마운트 작업에 속한다. 자동 마운트 유닛 자체에 넓은 순서를 두는 것이 사람들이 순환을 만들고 systemd가 나중에 아무도 두 번 읽지 않는 언어로 불평하는 방식이다.

x-systemd.mount-timeout=30s는 초기 마운트 명령을 제한한다. 그 뒤에 일어나는 어떤 것도 제한하지 않으며, 이것이 이 옵션에 대한 가장 흔한 오해다.

‘시작됨’이 의미하지 않는 것

지목한 VPN 유닛에 대해 활성이 무엇을 뜻하는지 확인한다. 터널 서비스는 파일 서버로 가는 경로가 생기기 전이나 사설 이름이 해석되기 전에 스스로 시작됐다고 보고할 수 있고, 그 뒤에 순서를 맞춰도 아무것도 얻지 못한다. 거의 모든 실패한 시도가 이 틈에 산다. 유닛 상태가 아니라 경로와 리졸버를 보지 않으면 보이지도 않는다.

있는 경우 연결 소유자의 자체 준비 신호를 추가 전제 조건으로 쓴다. 고정된 대기는 책상에서는 통하고 느린 네트워크나 재연결 후에는 실패하는 추측이다.

예제 경로에 대해 생성된 유닛을 살펴본다: mnt-work.automount와 mnt-work.mount. 검토된 fstab 변경 후에는 systemd를 다시 읽고, 관계없는 항목을 건드리는 포괄적 마운트 명령을 돌리는 대신 그 유닛을 직접 관리한다.

여기 한 가지 주의가 더 붙는다. 시작 시 /mnt/work를 만지는 서비스는 여전히 마운트를 유발하고 여전히 그것을 기다리므로, 공유를 선택 사항으로 표시한다고 모든 애플리케이션이 참을성이 생기지는 않는다.

마운트 이후는 다른 실패다

NFS가 마운트되면, 이후의 장애가 읽기나 쓰기에 무엇을 하는지는 파일 시스템의 재시도와 복구 동작이 결정한다. 설정한 마운트 시간 제한은 그것에 아무런 영향을 주지 않는다.

소프트 마운트는 일부 대기를 줄이고 오류의 의미를 바꾸며, 목표가 더 빠른 부팅일 때 놓치기 쉬운 데이터 무결성 결과를 동반한다. 시작의 이 초를 얻으려고 그것을 고르는 것은 좀처럼 좋은 거래가 아니다. 요구 사항이 정말 장애 중의 경계 있는 작업이라면 그것은 애플리케이션 수준의 결정이지 fstab 플래그가 아니다.

터널이 떨어질 때 쓰기 중간에 있는 프로세스가 어떻게 되어야 하는지 정하고 적어 둔다. 그 답이 어떤 옵션 문자열보다 유용하다.

하나가 아니라 네 상태를 시험한다

터널이 있을 때의 정상 부팅은 쉬운 경우이며 거의 아무것도 증명하지 않는다. 문자열이 올바로 적혔다는 것만 확인하고 그 이상은 아니다. VPN이 없을 때의 첫 접근, 그다음 올라왔을 때의 복구, 그다음 성공한 마운트 후의 통제된 장애를 시험한다.

네 상태, 네 관찰, 그리고 메모는 fstab 항목 옆에 둔다. 다음 사람은 역설계해야 하는 구성 대신 동작을 물려받는다.