오토마운터

Automounter

오토마운터는 사용자 프로그램에 의한 액세스 조작에 응답하여 파일 시스템을 자동으로 마운트하는 프로그램 또는 소프트웨어 설비입니다.오토마운터 시스템 유틸리티(유닉스에서는 데몬)는 선택적으로 감시되는 서브디렉토리 트리에서 파일 및 디렉토리 액세스 시도가 통지되면 로컬 또는 리모트디바이스에 동적으로 투과적으로 액세스 할 수 있도록 합니다.

오토마운터는 로컬 시스템 자원을 절약하고 다수의 서버와 파일 시스템을 공유하는 시스템 간의 결합을 줄이는 것을 목적으로 합니다.예를 들어, 대기업에서 중간 규모의 조직에는 수백 개의 파일 서버와 수천 개의 워크스테이션 또는 기타 노드가 언제든지 이러한 서버로부터 파일에 액세스할 수 있습니다.통상, 특정의 노드상에서 액티브하게 되는 리모트파일 시스템(export)은, 항상 비교적 적은 수 밖에 없습니다.프로세스가 실제로 액세스할 때까지 이러한 파일 시스템의 마운트를 지연시키면 이러한 마운트를 추적할 필요성이 줄어들어 신뢰성, 유연성 및 성능이 향상됩니다.

1대 이상의 파일 서버에 액세스 할 수 없게 되는 일이 자주 있습니다(유지보수를 위해 다운되거나 리모트 및 일시적으로 접속이 끊긴 네트워크 또는 congestion 링크를 통해 액세스 할 수 있습니다).또한 관리자는 용량 문제를 해결하고 부하를 분산하기 위해 파일 서버 간에 데이터를 재배치해야 하는 경우가 많습니다.데이터 마운트 지점을 자동화하면 이러한 경우 클라이언트 시스템을 보다 쉽게 재구성할 수 있습니다.

이러한 요소들이 결합되어 파일 시스템 마운트 테이블의 오래된 "정적" 관리 방법에 문제가 됩니다.fstab파일(Unix시스템에 있습니다.오토마운터 유틸리티는 이러한 과제에 대응하여 sysadmin이 마운트포인트(디렉토리명)의 export 관련성을 통합하고 일원화할 수 있도록 합니다.올바르게 실행되면 사용자는 모든 워크스테이션 및 기타 노드가 하나의 전사적 파일 시스템에 연결된 것처럼 파일 및 디렉토리에 투과적으로 액세스할 수 있습니다.

또한 오토마운터를 사용하여 읽기 전용 데이터의 여러 저장소를 정의할 수도 있습니다.클라이언트 시스템은 네트워크의 가용성, 파일 서버 부하 또는 근접성에 따라 마운트할 저장소를 자동으로 선택할 수 있습니다.

홈 디렉토리

많은 시설에는 다양한 사용자의 홈 디렉토리를 호스트하는 다수의 파일 서버가 있습니다.이러한 조직의 모든 워크스테이션 및 기타 노드(일반적으로 공통 방화벽의 배후에 있는 모든 노드)에는 오토마운터 서비스가 설정되어 노드에 로그인한 사용자가 자신의 홈 디렉토리에 암묵적으로 액세스 할 수 있도록 합니다.이것에 의해, 결과적으로 공통의 마운트 포인트에 마운트 됩니다.가지다/home/user이를 통해 사용자는 기업 내 어디에서나 자신의 파일에 액세스할 수 있습니다.이는 UNIX 환경에서 매우 유용합니다. UNIX 환경에서는 사용자가 다음과 같은 다양한 작업 디스패치 명령을 통해 많은 원격 시스템에서 명령을 자주 실행할 수 있습니다.ssh,telnet,rsh또는rlogin또는 X11 또는 VNC 프로토콜을 사용합니다.

/net

매우 일반적인 디폴트오토운터 로컬 패스는 다음과 같습니다./net/hostname/nfspath어디에hostname리모트 머신의 호스트명입니다.nfspath원격 시스템의 NFS를 통해 내보내는 경로입니다.일반적으로 이 표기법에 의해 시스템 매니저는 중앙 오토마운터 맵을 통해 내보낸 각 경로를 명시적으로 관리할 필요가 없어집니다.

소프트웨어 공유 및 저장소

컴퓨팅 환경에 따라서는, 유저 워크스테이션과 컴퓨팅 노드가, 유저가 액세스 하고 싶은 모든 종류의 소프트웨어의 인스톨을 호스트 하지 않는 경우가 있습니다.시스템은 가장 일반적으로 사용되는 소프트웨어의 최소 단면적 또는 일반적인 단면적으로 "이미지화"될 수 있습니다.또, 환경에 따라서는, 유저에게 구버전의 소프트웨어에의 전문적 액세스나 때때로 액세스 할 필요가 있는 경우가 있습니다(예를 들면, 개발자는 버그 수정이나 회귀 테스트를 실시할 필요가 있는 경우나, 유저에 따라서는 낡은 툴을 사용해 아카이브 데이터에 액세스 할 필요가 있는 경우도 있습니다).

일반적으로 조직은 필요에 따라 설치할 수 있는 이러한 소프트웨어의 저장소 또는 "저장소"를 제공합니다.또, 머신의 operating system이 최초로 인스톨 되고 있는 시스템 이미지의 완전한 카피나, 머신의 라이프 사이클중에 파손되는 시스템 파일의 수복에 사용할 수 있는 것도 있습니다.

소프트웨어에 따라서는 상당한 스토리지 공간이 필요하거나 빠른 개발(아마도 내부)이 진행 중일 수 있습니다.이 경우 소프트웨어는 파일서버에 인스톨 되어 파일서버에서 직접 실행되도록 설정할 수 있습니다.

동적으로 변화하는 자동 마운트

가장 간단한 경우 파일 서버에는 데이터 및 스크립트가 저장되어 있으며, 이 스크립트는 환경 내의 모든 시스템에서 액세스할 수 있습니다.그러나 특정 유형의 파일(특히 실행 가능한 바이너리 및 공유 라이브러리)은 특정 유형의 하드웨어 또는 특정 버전의 운영 체제에서만 사용할 수 있습니다.

이러한 상황에서 자동운송 유틸리티는 일반적으로 변수 데이터를 마운트 인수에 "매핑"하거나 "인터폴링"하는 방법을 지원합니다.

예를 들어 Linux 시스템과 Solaris 시스템이 혼재하는 조직은 다음과 같은 내보내기 이름을 사용하여 공통 파일 서버에서 각각의 소프트웨어 패키지 저장소를 호스트하도록 준비할 수 있습니다.depot:/export/linux그리고.depot:/export/solaris각각 다음과 같다.그 아래에, 서포트하는 각 OS 버전의 디렉토리가 있는 경우가 있습니다.오토마운터의 동적인 변동 기능을 사용하면, 사내의 어느 머신상의 관리자라도 다음의 소프트웨어 업데이트에 액세스 할 수 있도록, 모든 시스템을 설정할 수 있습니다./software/updatesSolaris 시스템상의 사용자는 다음과 같이 컴파일된 Solaris 패키지를 찾을 수 있습니다./softwareLinux 사용자는 특정 OS 버전의 RPM, DEB 또는 기타 패키지를 찾을 수 있습니다.게다가 SPARC 워크스테이션의 Solaris 유저는,/software/updatesx86 PC의 Solaris 사용자는 자신의 시스템을 투과적으로 찾을 수 있지만 시스템 아키텍처의 적절한 내보내기에 매핑됩니다./software/updates자신의 시스템에 맞는 패키지가 들어 있는 디렉토리일부 소프트웨어(Perl이나 Python 등 스크립트 언어로 작성)는 어떤 종류의 이식, 재컴파일 또는 재패키지 없이 지원되는 플랫폼에서 설치 및/또는 실행할 수 있습니다.시스템 관리자는 아마도 이러한 소프트웨어를/software/common수출.

경우에 따라서는 지역 또는 로케이션 베이스의 변수/동적 매핑을 사용하는 경우도 있습니다.이를 통해 한 건물 또는 사이트의 사용자는 다른 로케이션에서 호스트되는 자원의 레플리케이션을 호스트하는 보다 가까운 파일서버에 접속할 수 있습니다.

이러한 경우 모두 오토마운터 유틸리티를 통해 사용자는 실제 물리적 위치에 관계없이 파일 및 디렉토리에 액세스할 수 있습니다.일반적으로 사용자와 시스템 관리자는 오토마운터를 사용하여 "있는 것으로 추정되는" 파일에 액세스하여 해당 파일이 있는 것처럼 보이는지 확인할 수 있습니다.

소프트웨어

Tom Lyon은 Sun Microsystems에서 오리지널 오토마운트 소프트웨어를 개발했습니다.SunOS 4.0은 1988년에 [1]자동 마운트를 이용할 수 있게 되었습니다.Sun Microsystems는 결국 이 구현을 다른 상용 UNIX 배포판에 라이선스했습니다.1992년에 처음 출시된 Solaris 2.0은 라는 이름의 의사 파일 시스템을 사용하여 오토마운터를 구현했습니다.autofs이는 [2][3]마운트를 수행하는 사용자 모드 데몬과 통신합니다.AIX, HP-UX, Mac OS X 10.5 이후를 포함한 다른 Unix 유사 시스템에서는 오토운터의 구현을 채택하고 있습니다.

1989년 12월 Jan-Simon Pendry는 SunOS 오토마운트 [4]프로그램을 기반으로 한 자동차 회사 Amd를 출시했습니다.Amd는 또한 버클리 오토마운터로 알려지게 되었다.

Linux 에는 autofs 기반 automounter가 독립적으로 구현되어 있으며, autofs 기반 automounter 버전5는 일반적으로 Solaris automounter와 호환성이 있습니다.

FreeBSD는 Amd를 제공하기 위해 사용되었으며, 10.1부터는 Solaris와 [5]매우 유사한 새로운 오토마운터를 탑재하고 있습니다.그 후 DragonFly BSD[6] 및 NetBSD로 [7]이식되었습니다.

일부 운영 체제에서는 외장 드라이브(예: FireWire 또는 USB 연결을 사용하는 디스크 드라이브 또는 플래시 드라이브)와 이동식 미디어(예: CD 및 DVD)의 자동 마운트도 지원합니다.이 테크놀로지는 여기서 설명하는 자동 마운트와는 다릅니다.사용자가 로컬 미디어를 시스템에 연결하거나 삽입할 때 로컬 미디어를 마운트하는 것입니다.리모트 파일 서버에 참조할 때 디렉토리를 마운트하는 것이 아닙니다.현재 Linux(Linux 2.6 현재)에서는 이 형식의 자동 마운트에 사용자 공간 프로그램 udev를 사용합니다.일부 자동 마운트 기능은 별도의 프로그램 HAL에 구현되었지만 2010년 현재 udev에 통합되고[by whom?] 있습니다.OpenBSD에는 리무버블 디바이스의 탈착시에 특수 스크립트를 기동하는 핫 플러그(8)가 있어, 유저가 리무버블 드라이브의 마운트를 간단하게 추가할 수 있습니다.MacOS에서는diskarbitrationd는 이러한 형태의 자동 마운트를 수행합니다.FreeBSD에서는 네트워크 공유와 [8][9]마찬가지로 리무버블 미디어를 오토마운터에 의해 처리할 수 있습니다.

단점 및 주의사항

오토마운터 유틸리티(및 일반적으로 리모트 파일 시스템)는 조직의 스토리지 서비스에 대한 중앙 관리, 일관성 및 투과적인 액세스를 제공할 수 있지만 다음과 같은 단점도 있습니다.

  • 자동 마운트된 디렉토리에 액세스하면 자동 라우터가 매핑을 해결하고 내보내기를 제자리에 마운트하는 동안 지연이 발생할 수 있습니다.
  • 타임아웃으로 인해 마운트된 디렉토리가 마운트 해제될 수 있습니다(이 경우 나중에 다음 액세스 시도 시 마운트 지연이 발생할 수 있습니다).
  • 마운트 포인트와 export 인수의 매핑은, 통상, LDAP 나 NIS 등의 디렉토리 서비스를 개입시켜 행해집니다.이러한 서비스는, 다른 의존 관계(잠재적인 장해 지점)를 구성합니다.
  • 일부 시스템에서는 일부 리소스에 대한 빈번한 액세스가 필요한 반면 일부 시스템에서는 간헐적인 액세스만 필요한 경우 로컬에서 "미러링"(복제)된 디렉토리와 자동 마운트된 디렉토리가 일관되게 전사적으로 혼재되어 구현될 때 어렵거나 불가능한 문제가 발생할 수 있습니다.
  • 데이터를 파일 서버(내보내기) 간에 이행할 때, 다양한 이유로 인해 이전 위치에 액티브 마운트가 남아 있는('스테이 NFS 마운트') 시스템의 수가 결정되지 않을 수 있습니다.이러한 이유로 인해 완전히 안정된 호스트를 재부팅해야 할 수도 있는 문제가 발생할 수 있습니다.
  • 조직은 매핑의 '스파게티'를 작성함으로써 상당한 관리 오버헤드를 초래하고 사용자와 관리자가 상당한 혼란을 겪을 수 있습니다.
  • 사용자는 자동 마운트된 자원의 투과성에 익숙해지기 때문에 로컬에 마운트된 디바이스와 비교하여 네트워크 파일 시스템에 적용되는 액세스 시멘틱스의 차이를 고려하지 않습니다.특히 프로그래머는 로컬 파일 시스템에서 안전하고 원하는 원자성 보증을 제공하는 "잠금" 기술을 사용하려고 시도할 수 있지만 NFS에서 사용할 경우 레이스 조건에 본질적으로 취약한 것으로 문서화되어 있습니다.

레퍼런스

  1. ^ Callaghan, Brent (2000) [1999]. NFS Illustrated. Addison-Wesley. pp. 322–323. ISBN 0-201-32570-5. Retrieved 2007-12-23.
  2. ^ Callaghan, Brent; Singh, Satinder (June 21–25, 1993). The Autofs Automounter. USENIX Summer 1993 Technical Conference. Cincinnati, Ohio.
  3. ^ Labiaga, Ricardo (November 7–12, 1999). Enhancements to the Autofs Automounter. 1999 LISA XIII. Seattle, Washington.
  4. ^ Jan-Simon Pendry (1989-12-01). "''Amd'' - An Automounter". Newsgroup: comp.unix.wizards. Retrieved 2007-12-23.
  5. ^ Edward Tomasz Napierała (2014-07-30). "Autofs" (PDF). Archived (PDF) from the original on 7 June 2021.
  6. ^ Tomohiro Kusumi (2016-06-02). "git: autofs: Port autofs from FreeBSD". commits@dragonflybsd.org (Mailing list). DragonFly BSD. Retrieved 2019-11-13.
  7. ^ "New automounter". NetBSD Wiki. Archived from the original on 7 June 2021.
  8. ^ "FreeBSD Handbook, section 17.4.2. Automounting Removable Media". Archived from the original on 7 June 2021.
  9. ^ Dickison, Anne (2015-03-13). "FreeBSD From the Trenches: Using autofs(5) to Mount Removable Media". FreeBSD Foundation. Archived from the original on 7 June 2021. Retrieved 2019-11-13.