☰

NFS 마운트 그룹

tag-icon • tag-icon systemd nfs
NFS 마운트 그룹

일련의 NFS 마운트 지점이 마운트된 여러 대의 서버가 있습니다. 이러한 마운트 지점에 사용되는 내보내기 그룹화는 각 서버의 "특성"을 정의합니다. 각 "개성"에는 동일한 장착 지점이 많이 포함되는 경향이 있지만 일부 고유한 장착 지점도 포함됩니다.

이는 일반적으로 각 역할에 대해 고유한 fstab을 저장하여 수행됩니다(실제로 Ansible을 사용하여 각 서버에 마운트 그룹을 추가함).

나는 사용자가 필요에 따라 (가능한 경우 재부팅하지 않고) 서버의 NFS 특성을 전환하는 동시에 Ansible을 통해 특성에 대한 제어를 유지할 수 있는 방법을 제공하고 싶습니다. 이 문제를 해결하는 방법은 백만 가지가 있을 것이라고 확신하지만, 보다 일반적인 기술 중 일부(있는 ​​경우)를 조사하고 싶었습니다.

  • fstab 기반 접근 방식을 사용해 봐야 합니까?
  • systemd 대상을 사용하여 이를 수행하는 더 좋은 방법이 있습니까?
  • RHEL7/8 세계에 이보다 더 적합한 도구가 있습니까?

어떤 아이디어라도 감사드립니다!

답변1

질문을 완전히 이해했는지 잘 모르겠습니다. 하지만 목표가 Mary에게 탈것 몇 개를 주고 John에게 또 다른 탈것 세트를 주는 것이라면...

이것은 쉽습니다.

  1. 허용된 마운트 지점과 주소를 사용하여 파일을 생성하고 fstab 구조를 모방할 수도 있습니다. 실제 설치는 /etc/fstab일반 설치에 사용되며 루트에 의해서만 제어됩니다. 따라서 사용자를 위해 다음을 수행할 수 있습니다.
# /etc/fstab.user/mary
10.0.0.40:/source-repo repository nfs

# /etc/fstab.user/john
//server/Secret-Documents documents cifs
  1. /etc/profile다음과 같은 코드(또는 각 사용자에 대해 호출되는 동등한 코드)를 추가합니다 .
if [ -e /etc/fstab.user/$USER ] ; then
   while read device dir tp
   do
      mkdir -p /home/$USER/mnt/$dir
      mount -t $tp $device /home/$USER/mnt/$dir 
   done < /etc/fstab.user/$USER
fi

따라서 각 사용자는 자신만의 설치 세트를 갖게 되며 $HOME/mnt/실제 루트 사용자는 누가 무엇을 얻을지 제어하게 됩니다.

이 방법은 실제 폴더 /etc/fstab.users자체가 네트워크에서 마운트된 경우에도 작동합니다.

답변2

너할 수 있다.target 단위를 사용하여 마운트 시작 및 중지 - 예를 들어 .mount 단위 세트를 개별-one.target에 넣으면 사용자는 systemctl enable전체 대상을 즉시 또는 비활성화할 수 있습니다. (하지만멈추다대상을 "하위" 유닛에 전파하려면 더 많은 작업이 필요할 수 있으며, 각 .mount 유닛에 "StopWhenUnneeded="가 있을 수 있습니다. )

그러나 autofs자동 설치 프로그램을 사용하는 것이 좋습니다. 그 주요 업무예NFS 마운트 그룹을 관리합니다. (또한 관리하는 마운트가 "요청 시"라는 장점도 있습니다. 따라서 200개의 호스트가 각각 200개의 파일 시스템을 마운트하는 경우 이를 다시 시작해도 수천 개의 마운트 요청이 발생하지 않습니다. 파일 서버는 마운트 요청으로 가득 차 있습니다.)

각 마운트 세트가 동일한 디렉토리에 있는 경우(예: 모두 /data의 하위 디렉토리) 전체 디렉토리를 자동 마운트 맵(예: /etc/auto.data)으로 정의한 다음 "마스터"에서 참조할 수 있습니다. (/etc/auto.master). 이 구조에 맞지 않는 독립형 설치는 "직접" 맵을 통해 정의할 수 있습니다. 예를 들어:

  • 이 콘솔에 맞게 사용자 정의할 수 있는 메인 맵:

    # cat /etc/auto.master

/data   /etc/auto.data
/tools  /etc/auto.tools
/-      /etc/auto.direct

  • /data자동 마운트 맵(/data/one, /data/two 등) 아래의 마운트 세트:

    # cat /etc/auto.data

one     -nosuid,nodev datahost.example.com:/exports/data_one
two     -nosuid,nodev datahost.example.com:/exports/data_two

  • "직접" 설치를 위한 자동 설치 매핑(어디서나):

    # cat /etc/auto.direct

/opt/sometool    filehost.example.com:/exports/software/sometool
/var/backup      filehost.example.com:/exports/backups/$HOST

    (systemd .automount 유닛을 사용해 본 적이 있다면 동일한 autofs 기능을 사용하며 "직접" 자동 마운트 매핑과 매우 유사하게 작동합니다.)

자동 마운트 서비스를 시작하면 /data에 "autofs" 가상 파일 시스템이 마운트됩니다.~인 것 같다처음에는 비어 있지만 /data/one과 같은 하위 디렉터리가 나타나면방문했다모든 프로그램은 해당 NFS 공유에서 마운트됩니다.

Ansible을 통해 모든 맵을 배포하고 사용 가능한 마스터 맵 중 하나를 "/etc/auto.master"에 심볼릭 링크할 수 있습니다. 사용자는 마스터 맵에 다시 심볼릭 링크(예: "/etc/dist/auto.master.groupA")를 연결하고 자동 마운트 데몬을 다시 로드하여 호스트 특성을 전환할 수 있습니다. 자동 마운트 데몬은 관리하는 autofs 마운트를 자동으로 추가하거나 제거합니다.

(auto.master 파일에는 .so와 같은 특수 항목을 사용하는 디렉토리의 "플러그인"도 포함될 수 있으므로 +dir:/etc/auto.master.d/사용자는 하이브리드 시스템이 필요한 경우 더 작은 부분을 심볼릭 링크할 수 있습니다.)

답변3

기본 대상 장치별로 그룹화된 시스템 마운트 및 자동 마운트 장치를 몇 번 반복한 후 일반 fstab 생성기가 이미 제공한 동작을 복제하는 데 필요한 종속성 및 다양한 옵션이 수렁에 빠졌다는 사실을 발견했습니다.

각 "개성"에 대한 많은(거의 50개) 마운트 포인트로 인해 전체 작업이 너무 번거로워서 계속할 수 없게 되었습니다. 그래서 저는 fstab 항목의 전체 섹션(키워드로 차단됨)을 가져와 해당 섹션의 주석 처리를 효과적으로 제거하는 동시에 다른 fstab 항목 그룹의 덩어리를 주석 처리하는 Python 도구를 백업하고 작성했습니다. 서버를 다시 시작하면 fstab 생성기가 강제로 장치를 다시 빌드합니다.

그런 다음 권한 있는 관리자는 새 도구를 사용하여 서버 특성을 전환하고 서버를 다시 시작할 수 있습니다.

배운 교훈은 시스템 fstab 생성기처럼 복잡한 것을 다시 구현하려고 시도해서는 안 된다는 것입니다. 나는 그것이 어떻게 작동하는지 확실히 많이 배웠지만 내가 가지고 있는 마운트 지점의 수와 수많은 종속성(하나의 마운트는 다른 마운트에 따라 다르며 자동 마운트 등...) 때문에 fstab에서 항목을 지정할 수 있다는 편리함도 너무 뛰어납니다. 무시하는 것이 유리합니다. Ansible에서 (100개의 유닛 파일 대신) 단일 마스터 fstab(blockinfile)을 관리할 수 있다는 단순성도 무시할 수 없습니다.

확실히, fstab 생성기가 임의의 입력 파일(fstab)에서 단위를 생성하고 시스템 검색 경로와 결합될 수 있는 임의의 경로로 출력하는 방법이 있는 경우 다른 솔루션이 있을 수 있습니다(내 RHEL7 환경에서는 불가능). ) 계획.

의견을 보내주신 모든 분들께 감사드립니다!

관련 정보