オートマウント

オートマウント機能は、ユーザー プログラムによるアクセス操作に応じてファイル システムを自動的にマウントするプログラムまたはソフトウェア機能です。オートマウント機能システム ユーティリティ ( Unixではデーモン) は、選択的に監視されたサブディレクトリ ツリーの下にあるファイルおよびディレクトリへのアクセス試行が通知されると、動的かつ透過的にローカル デバイスまたはリモート デバイスにアクセスできるようにします。

オートマウント機能は、ローカル システム リソースを節約し、多数のサーバーとファイル システムを共有するシステム間の結合を減らすことを目的としています。たとえば、大規模から中規模の組織には、数百のファイル サーバーと、それらのサーバーの任意の数のファイルにアクセスする数千のワークステーションまたはその他のノードが存在する場合があります。通常、任意のノードで任意の時点でアクティブになるリモート ファイル システム (エクスポート)は比較的少数です。プロセスが実際にアクセスする必要があるときまでそのようなファイル システムのマウントを延期すると、そのようなマウントを追跡する必要性が減り、信頼性、柔軟性、およびパフォーマンスが向上します。

1 台以上のファイル サーバーがアクセス不能になることがよくあります (メンテナンスのためダウンしている、リモート ネットワークで一時的に切断されている、または混雑したリンク経由でアクセスしているなど)。管理者は、容量の問題を解決して負荷を分散するために、あるファイル サーバーから別のファイル サーバーにデータを移動する必要があることにも気付くことがよくあります。データ マウント ポイントを自動化すると、このような場合にクライアント システムを再構成しやすくなります。

fstabこれらの要因が組み合わさって、ファイルシステム マウント テーブル ( Unix システム上のファイル)の従来の「静的」管理方法に課題が生じています。自動マウント ユーティリティはこれらの課題に対処し、システム管理者がマウント ポイント (ディレクトリ名) とエクスポートの関連付けを統合して一元化できるようにします。適切に実行すれば、ユーザーは、すべてのワークステーションとその他のノードが単一のエンタープライズ全体のファイルシステムに接続されているかのように、ファイルとディレクトリに透過的にアクセスできます。

また、自動マウント機能を使用して、読み取り専用データ用の複数のリポジトリを定義することもできます。クライアント システムは、可用性、ファイル サーバーの負荷、またはネットワーク上の近接性に基づいて、マウントするリポジトリを自動的に選択できます。

多くの組織には、さまざまなユーザーのホーム ディレクトリをホストするファイル サーバーが多数あります。このような組織内のすべてのワークステーションとその他のノード (通常は、インターネットから分離する共通のファイアウォールの背後にあるすべてのノード) は、自動マウント サービスを使用して構成されます。これにより、任意のノードにログインするすべてのユーザーが、暗黙的に自分のホーム ディレクトリへのアクセスをトリガーし、その結果、そのホーム ディレクトリは、などの共通のマウント ポイントにマウントされます。これにより、ユーザーは企業内のどこからでも自分のファイルにアクセスできるようになります。これは、、、、などのさまざまなジョブ ディスパッチ コマンドや、 X11またはVNCプロトコルを介して、多くのリモート システムでコマンドを頻繁に呼び出す可能性がある UNIX 環境では非常に便利です。 /home/usersshtelnetrshrlogin

非常に一般的なデフォルトのオートマウント ローカル パスは、 という形式です 。 ここで、はリモート マシンのホスト名、 はリモート マシン上でNFS経由でエクスポートされるパスです。この表記により、システム管理者は、中央のオートマウント マップを介してエクスポートされた各パスを明示的に管理する必要がなくなります。 /net/hostname/nfspathhostnamenfspath

一部のコンピューティング環境では、ユーザーのワークステーションとコンピューティング ノードには、ユーザーがアクセスする可能性のあるすべてのソフトウェアがインストールされていません。システムは、最も一般的に使用されるソフトウェアの最小または一般的な断面で「イメージ化」されている場合があります。また、一部の環境では、ユーザーは古いバージョンのソフトウェアに特別にアクセスしたり、時々アクセスしたりする必要があります (たとえば、開発者はバグ修正や回帰テストを実行する必要があるかもしれませんし、一部のユーザーは古いツールを使用してアーカイブされたデータにアクセスする必要があるかもしれません)。

一般的に、組織は、必要に応じてインストールできるようなソフトウェアのリポジトリまたは「デポ」を提供します。これらには、マシンに最初にオペレーティング システムがインストールされたシステム イメージの完全なコピーや、マシンのライフサイクル中に破損する可能性のあるシステム ファイルの修復に使用できるコピーも含まれる場合があります。

一部のソフトウェアは、かなり大きなストレージ スペースを必要とする場合や、急速な (おそらく社内での) 開発が行われている場合があります。そのような場合、ソフトウェアはファイル サーバーにインストールされ、ファイル サーバーから直接実行されるように構成されることがあります。

最も単純なケースでは、ファイルサーバーには環境内のどのシステムからもアクセスできるデータやスクリプトが格納されます。ただし、特定の種類のファイル (特に実行可能バイナリや共有ライブラリ) は、特定の種類のハードウェアや特定のオペレーティング システムの特定のバージョンでのみ使用できます。

このような状況では、自動マウント ユーティリティは通常、マウント引数に変数データを「マッピング」または「補間」する何らかの手段をサポートしています。

たとえば、Linux システムとSolarisシステムが混在する組織では、それぞれ や などのエクスポート名を使用して、共通のファイル サーバー上でそれぞれのソフトウェア パッケージリポジトリをホストするように設定できます。その下に、サポートする OS バージョンごとにディレクトリを作成できます。自動マウント機能の動的バリエーション機能を使用して、すべてのシステムを構成すれば、企業内のどのマシンの管理者でも の下にある利用可能なソフトウェア更新にアクセスできます。Solaris システムのユーザーは の下にある Solaris コンパイル済みパッケージを見つけ、Linuxユーザーは の下にある特定の OS バージョン用のRPM、DEB 、またはその他のパッケージを見つけます。さらに、 SPARCワークステーションの Solaris ユーザーは がそのシステムのアーキテクチャに適したエクスポートにマップされ、x86 PCの Solaris ユーザーは自分のシステムに適したパッケージを含むディレクトリを透過的に見つけることができます。一部のソフトウェア ( PerlやPythonなどのスクリプト言語で記述) は、移植、再コンパイル、再パッケージ化を一切行わずに、サポートされている任意のプラットフォームにインストールおよび/または実行できます。システム管理者は、エクスポート内でそのようなソフトウェアを見つける可能性があります。 depot:/export/linuxdepot:/export/solaris/software/updates/software/software/updates/software/updates/software/common

場合によっては、組織は地域または場所に基づく変数/動的マッピングを使用することもあります。これにより、ある建物またはサイトのユーザーは、他の場所でホストされているリソースの複製をホストする、より近いファイル サーバーに誘導されます。

これらすべてのケースにおいて、オートマウント ユーティリティを使用すると、ユーザーは実際の物理的な場所に関係なく、ファイルやディレクトリにアクセスできます。オートマウントを使用すると、ユーザーとシステム管理者は通常、ファイルが「あるはずの」場所にアクセスし、そこにファイルが存在することを確認できます。

トム・ライオンはサン・マイクロシステムズでオリジナルの自動マウントソフトウェアを開発しました。1988年にSunOS 4.0で自動マウントが利用可能になりました。[1] サン・マイクロシステムズは最終的にこの実装を他の商用UNIXディストリビューションにライセンス供与しました。1992年に最初にリリースされたSolaris 2.0は、マウントを実行するユーザーモードデーモンと通信すると呼ばれる疑似ファイルシステムを使用して自動マウント機能を実装しまし^たautofs。^{[2] [3]} AIX、HP-UX、Mac OS X 10.5以降など、 他のUnix系システムでもその自動マウント機能の実装が採用されています。

1989年12月、Jan-Simon Pendryは、SunOSの自動マウントプログラムを「精神に基づいて」ベースにした自動マウントツールであるAmdをリリースしました。 ^[4] AmdはBerkeley Automounterとしても知られています。

Linux にはautofs ベースの自動マウント機能が独自に実装されており、その自動マウント機能のバージョン 5 は、通常、Solaris 自動マウント機能と互換性を持って動作します。

FreeBSDはかつてAmdを提供していましたが、10.1からはSolarisのものと非常によく似た新しい自動マウント機能を備えています。^{[5]その後、} DragonFly BSD ^[6]とNetBSD ^[7] に移植されました。

一部のオペレーティングシステムでは、外付けドライブ（ FireWireまたはUSB接続を使用するディスクドライブやフラッシュドライブなど）やリムーバブルメディア（ CDやDVDなど）の自動マウントもサポートされています。このテクノロジは、ここで説明する自動マウントとは異なります。これは、リモートファイルサーバーのディレクトリが参照されたときにマウントするのではなく、ユーザーがローカルメディアをシステムに接続または挿入したときにローカルメディアをマウントします。現在、Linux（Linux 2.6 以降）では、この形式の自動マウントにユーザー空間プログラムudev を使用しています。一部の自動マウント機能は、別のプログラムHALで実装されていますが、2010 年現在、 udev に^{[アップデート]}統合されています^{[誰によって? ]}。OpenBSD には、リムーバブルデバイスの接続または切断時に特別なスクリプトをトリガーする hotplugd(8) があり、ユーザーはリムーバブルドライブのマウントを簡単に追加できます。macOS では、diskarbitrationdこの形式の自動マウントを実行します。FreeBSD では、ネットワーク共有と同様に、リムーバブルメディアを自動マウント機能で処理できます。^{[8] [9]}

オートマウント ユーティリティ (および一般的なリモート ファイル システム) は、組織のストレージ サービスへの集中管理された、一貫性のある、ほぼ透過的なアクセスを提供できますが、次のような欠点もあります。

• 自動マウントされたディレクトリにアクセスすると、自動マウント機能がマッピングを解決し、エクスポートを所定の位置にマウントするまでに遅延が発生する可能性があります。
• タイムアウトにより、マウントされたディレクトリがアンマウントされる可能性があります (この状況により、次回のアクセス試行時にマウント遅延が発生する可能性があります)。
• マウントポイントからエクスポート引数へのマッピングは、通常、LDAPやNISなどのディレクトリ サービスを介して行われますが、これが別の依存関係 (潜在的な障害ポイント) を構成します。
• 一部のシステムでは一部のリソースに頻繁にアクセスする必要がある一方で、他のシステムでは時々しかアクセスする必要がないという場合、ローカルに「ミラーリングされた」(複製された) ディレクトリと自動マウントされたディレクトリを企業全体で一貫して混在させて実装することが困難または不可能になる問題が発生する可能性があります。
• データが 1 つのファイル サーバー (エクスポート) から別のファイル サーバーに移行されると、さまざまな理由により、古い場所にアクティブなマウント (「古いNFSマウント」)がまだ残っているシステムが不特定多数存在する可能性があります。これにより、問題が発生する可能性があり、それ以外は完全に安定しているホストの再起動が必要になる場合もあります。
• 組織では、マッピングの「スパゲッティ」を作成していることに気付くことがあります。これにより、かなりの管理オーバーヘッドが発生し、場合によってはユーザーと管理者の間でかなりの混乱が生じる可能性があります。
• ユーザーは、自動マウントされたリソースの透過性に慣れすぎて、ローカルにマウントされたデバイスと比較して、ネットワーク ファイルシステムに適用される可能性のあるアクセス セマンティクスの違いのいくつかを考慮しない場合があります。特に、プログラマーは、安全で、ローカル ファイルシステムで必要なアトミック性を保証する「ロック」手法を使用しようとする場合があります。ただし、この手法は、NFS で使用すると競合状態に対して本質的に脆弱であることが文書化されています。