ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Oracle Solaris 11.1 でのネットワークファイルシステムの管理 Oracle Solaris 11.1 Information Library (日本語) |
3. ネットワークファイルシステムへのアクセス (リファレンス)
Oracle Solaris 11 リリースで NFS version 4 のデフォルトドメインを構成する
Solaris 10 リリースで NFS version 4 のデフォルトドメインを構成する
NFS version 4 におけるファイルシステムの共有解除と再共有
NFS version 4 におけるファイルシステムの名前空間
NFS version 4 における OPEN 共有サポート
NFS version 4 での ACL と nfsmapid
ACL エントリ内のすべてのユーザーおよびグループ ID が NFS version 4 のクライアントとサーバーの両方に存在することを確認します。
マウント時の -public オプションと NFS URL の意味
NFS version 4 におけるクライアント側フェイルオーバー機能
autofs は、自動的に適切なファイルシステムをマウントするためのクライアント側のサービスです。自動マウントを行うのに、次のコンポーネントが相互に動作します。
automount コマンド
autofs ファイルシステム
automountd デーモン
自動マウントサービス svc:/system/filesystem/autofs は、システムの起動時に呼び出され、マスターマップファイル auto_master を読み取って、autofs マウントの最初のセットを作成します。これらの autofs のマウントは起動時に自動的にはマウントされません。後でファイルシステムがマウントされるポイントです。このようなポイントをトリガーノードと呼ぶこともあります。
autofs マウントが設定されると、要求があったときにファイルシステムをマウントすることができます。たとえば、autofs が、現在マウントされていないファイルシステムをアクセスする要求を受け取ると、automountd を呼び出して要求されたファイルシステムを実際にマウントさせます。
最初に autofs マウントをマウントしたあとは、必要に応じて automount コマンドを実行し、autofs マウントを更新します。このコマンドは、auto_master マップにあるマウントのリストと、マウントテーブルファイル /etc/mnttab (前のバージョンでは /etc/mtab) にあるマウントされたファイルシステムのリストを比較します。その後、automount によって、適切な変更が加えられます。このプロセスにより、システム管理者は auto_master 内のマウント情報を変更し、autofs デーモンを停止したり再起動したりすることなく、それらの変更結果を autofs プロセスに使用させることができます。ファイルシステムがマウントされれば、以後のアクセスに automountd は不要になります。次に automountd が必要になるのは、ファイルシステムが自動的にアンマウントされたときです。
mount とは異なり、automount はマウントすべきファイルシステムを調べるために /etc/vfstab ファイル (各コンピュータごとに異なる) を参照しません。automount コマンドは、ドメイン内とコンピュータ上で名前空間とローカルファイルを通して制御されます。
次の図では、autofs のしくみの概要を簡単に説明します。
自動マウントデーモンである automountd は、ブート時にサービス svc:/system/filesystem/autofs によって起動されます。図 3-3 を参照してください。このサービスは automount コマンドも実行します。このコマンドはマスターマップを読み取り、autofs のマウントポイントをインストールします。詳細は、「autofs のナビゲーションプロセス開始法 (マスターマップ)」を参照してください。
図 3-3 svc:/system/filesystem/autofs サービスによる automount の起動
autofs は、自動マウント操作とアンマウント操作をサポートするカーネルファイルシステムの 1 つです。
autofs マウントポイントで、ファイルシステムへのアクセスが要求された場合は、次の動作が行われます。
autofs がその要求に介入します。
autofs は要求されたファイルシステムをマウントするよう、automountd にメッセージを送信します。
automountd がマップからファイルシステム情報を見つけ、マウントを実行します。
autofs は、介入した要求の実行を続行させます。
そのファイルシステムが一定期間非アクティブである場合、autofs はそのファイルシステムをアンマウントします。
注 - autofs サービスによって管理されるマウントは、手動でマウントまたはアンマウントは行わないでください。たとえこの操作がうまくいったとしても、autofs サービスはオブジェクトがアンマウントされたことを認識しないので、一貫性が損なわれる恐れがあります。リブートによって、autofs のマウントポイントがすべて消去されます。
autofs は一連のマップを探索することによって、ネットワークをナビゲートします。マップは、ネットワーク上の全ユーザーのパスワードエントリや、ネットワーク上の全ホストコンピュータの名前などの情報を含むファイルです。マップには UNIX の管理ファイルに相当するネットワーク規模の管理ファイルも含まれています。マップはローカルに使用するか、あるいは NIS のようなネットワークネームサービスを通じて使用できます。「autofs のネットワークナビゲート法の変更 (マップの変更)」を参照してください。
automount コマンドはシステムの起動時にマスターマップを読み取ります。図 3-4 に示すように、マスターマップ内の各エントリは、直接または間接のマップ名、そのパス、およびそのマウントオプションです。エントリの順序は重要ではありません。automount は、マスターマップ内のエントリとマウントテーブル内のエントリを比較して、現在のリストを生成します。
図 3-4 マスターマップによるナビゲーション
マウント要求が発生したときに autofs サービスが何を実行するかは、オートマウンタマップの構成によって異なります。マウントプロセスの基本はすべてのマウントで同じですが、指定されているマウントポイントとマップの複雑さによって結果が変わります。マウントプロセスにはトリガーノードの作成が含まれます。
autofs マウントプロセスの説明のために、次のファイルがインストールされていると仮定します。
$ cat /etc/auto_master # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /share auto_share $ cat /etc/auto_share # share directory map for automounter # ws gumbo:/export/share/ws
/share ディレクトリがアクセスされると、autofs サービスは /share/ws に対するトリガーノードを作成します。これは、/etc/mnttab の中では次のようなエントリになります。
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=###
/share/ws ディレクトリがアクセスされると、autofs サービスは次の手順を実行します。
サーバーのマウントサービスが使用可能かどうかを確認します。
要求されたファイルシステムを、/share の下にマウントします。これで、/etc/mnttab ファイルには次のエントリが追加されます。
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### #####
オートマウンタファイルに複数の層が定義されていると、マウントプロセスはさらに複雑になります。前の例の /etc/auto_shared ファイルを拡張して、次の行を追加したとします。
# share directory map for automounter # ws / gumbo:/export/share/ws /usr gumbo:/export/share/ws/usr
この場合、/share/ws マウントポイントがアクセスされたときのマウントプロセスは基本的に最初の例と同じです。また、/share/ws ファイルシステムの中に次のレベル (/usr) へのトリガーノードを作成することにより、そのレベルがアクセスされたときにマウントできるようにします。この例でトリガーノードが作成されるためには、NFS に /export/share/ws/usr が存在している必要があります。
一定時間アクセスがないためにアンマウントされるときは、マウントと逆の順序で実行されます。あるディレクトリより上位のディレクトリが使用中であれば、それより下のディレクトリだけがアンマウントされます。アンマウントすると、トリガーノードがすべて削除され、ファイルシステムがアンマウントされます。ファイルシステムが使用中であれば、アンマウントは失敗してトリガーノードは再インストールされます。
注意 - 階層的にマウントを指定する場合は、-soft オプションは使用しないでください。-soft オプションを使用すると、トリガーノードを再インストールする要求がタイムアウトすることがあります。トリガーノードを再インストールできないと、マウントの次の階層にアクセスできません。この問題を解決するには、オートマウンタを使用して、階層にあるすべてのコンポーネントのマウントを解除します。オートマウンタでアンマウントするには、ファイルシステムが自動的にアンマウントされるのを待つか、システムをリブートします。 |
/usr/local -ro \ /bin ivy:/export/local/sun4\ /share ivy:/export/local/share\ /src ivy:/export/local/src /usr/man -ro oak:/usr/man \ rose:/usr/man \ willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news \ willow:/var/spool/news
マウントポイント /usr/man および /usr/spool/news には複数の場所があり、/usr/man のマウントポイントは 3 つ、/usr/spool/news のマウントポイントは 2 つの場所が記述されています。複製された場所のどこからマウントしてもユーザーは同じサービスを受けられます。ユーザーの書き込みまたは変更が可能ならば、その変更をロケーション全体で管理しなければならなくなるので、この手順は、読み取り専用のファイルシステムをマウントするときにだけ意味があります。あるときに、あるサーバー上のファイルを変更し、そのすぐあとに別のサーバー上で「同じ」ファイルを変更するといった作業は避けたいものです。この利点は、もっとも利用しやすいサーバーが、そのユーザーの手をまったく必要としないで自動的にマウントされるということです。
ファイルシステムを複製として構成してあると (「複製されたファイルシステムとは」を参照)、クライアントはフェイルオーバー機能を使用できます。最適なサーバーが自動的に決定されるだけでなく、そのサーバーが使用できなくなるとクライアントは自動的に 2 番目に適したサーバーを使います。
複製として構成するのに適しているファイルシステムの例は、マニュアルページです。大規模なネットワークでは、複数のサーバーがマニュアルページをエクスポートできます。どのサーバーからマニュアルページをマウントしても、そのサーバーが動作しており、しかもそのファイルシステムをエクスポートしているかぎり、問題ありません。上の例では、複数のマウント位置は、マップエントリ内のマウント位置のリストになっています。
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man
この例では、サーバー oak、rose、willow のどれからでもマニュアルページをマウントできます。どのサーバーが最適であるかは、次のいくつかの要素によって決まります。
特定レベルの NFS プロトコルをサポートしているサーバーの数
サーバーとの距離
重み付け
順位を決定するときには、各バージョンの NFS プロトコルをサポートしているサーバーの数が数えられます。サポートしているサーバーの数が多いプロトコルがデフォルトになります。これによって、クライアントにとっては利用できるサーバーの数が最大になります。
プロトコルが同じバージョンのサーバーの組の中で数がもっとも多いものがわかると、サーバーのリストが距離によってソートされます。距離を判定するために、IPv4 アドレスが調査されます。IPv4 アドレスは、どのサーバーが各サブネットにあるかを示します。ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。もっとも近いサーバーが優先されることにより、待ち時間とネットワークトラフィックが軽減されます。
注 - IPv6 アドレスを使用している複製に対しては、距離を判定できません。
図 3-5 に、サーバーとの距離を示します。
図 3-5 サーバーとの距離
ローカルサブネット上に同じプロトコルをサポートしているサーバーが複数あるときは、それぞれのサーバーに接続する時間が計測され、速いものが使用されます。優先順位には、重み付けも関係します (「autofs と重み付け」を参照してください)。
たとえば、version 4 サーバーの方が多いと、version 4 がデフォルトで使用されるプロトコルになります。ただし、優先順位の決定は複雑になります。次に、優先順位の決定の例をいくつか示します。
ローカルサブネット上のサーバーには、リモートサブネット上のサーバーよりも高い優先順位が付けられます。ローカルサブネットに version 3 サーバーがあり、もっとも近い version 4 サーバーがリモートサブネット上にあると、version 3 サーバーが優先されます。同様に、ローカルサブネットが version 2 サーバーで構成されていると、version 3 と version 4 サーバーを使用するリモートサブネットよりも優先されます。
ローカルサブネットがさまざまな数の version 2、version 3、および version 4 サーバーで構成されていると、さらに優先順位付けが必要になります。オートマウンタは、ローカルサブネット上でもっとも高いバージョンを優先します。この場合、version 4 がもっとも高いバージョンです。ただし、ローカルサブネットに、version 4 サーバーよりも version 3 または version 2 サーバーの方が多い場合、オートマウンタはローカルサブネットのもっとも高いバージョンから 1 つ下のバージョンを選択します。たとえば、ローカルサブネットに、version 4 サーバーが 3 台、version 3 サーバーが 3 台、version 2 サーバーが 10 台ある場合、version 3 サーバーが選択されます。
同じように、ローカルサブネットがさまざまな数の version 2 と version 3 サーバーで構成されていると、最初にオートマウンタは、どのバージョンがローカルサブネットでもっとも高いバージョンかを見つけます。次に、オートマウンタは各バージョンを実行するサーバーの数を数えます。ローカルサブネット上でもっとも高いバージョンが、同時にもっとも多いサーバーの場合、もっとも高いバージョンが選択されます。低いバージョンのサーバーの数が多い場合、オートマウンタはローカルサブネットのもっとも高いバージョンから 1 つ下のバージョンを選択します。たとえば、ローカルサブネット上で version 2 サーバーの方が version 3 サーバーよりも多い場合、version 2 サーバーが選択されます。
注 - 重み付けには、SMF リポジトリに保存されているパラメータも影響します。特に、server_versmin、client_versmin、server_versmax、および client_versmax の値により、いくつかのバージョンを優先順位の決定から除外できます。これらのパラメータの詳細は、「mountd デーモン」および 「nfsd デーモン」を参照してください。
フェイルオーバー機能を指定していると、この優先順位はサーバーが選択されるマウント時に確認されます。複数の場所を指定しておくと、個々のサーバーが一時的にファイルシステムをエクスポートできないときに便利です。
多くのサブネットを持つ大規模ネットワークでは、フェイルオーバーは特に便利です。autofs は適切なサーバーを選択して、ネットワークトラフィックをローカルネットワークのセグメントに限定することができます。サーバーが複数のネットワークインタフェースを持つ場合は、それぞれのインタフェースが別々のサーバーであるとみなして、各ネットワークインタフェースに対応付けられているホスト名を指定します。autofs はそのクライアントにいちばん近いインタフェースを選択します。
注 - 手動によるマウントでは、重み付けと距離の確認は行われません。mount コマンドは、左から右へ一覧表示されるサーバーの優先順位を付けます。
詳細は、automount(1M) のマニュアルページを参照してください。
距離のレベルが同じサーバーから 1 つを選択するために、autofs マップに重み付けの値を追加することができます。例:
/usr/man -ro oak,rose(1),willow(2):/usr/man
括弧内の数値が重み付けを表します。重み付けのないサーバーの値はゼロであり、選択される可能性が最高になります。重み付けの値が大きいほど、そのサーバーが選択される可能性は低くなります。
注 - 重み付けは、サーバーの選択に関係する要素の中でもっとも小さい影響力しかありません。ネットワーク上の距離が同じサーバーの間で選択を行う場合に考慮されるだけです。
変数名の前にドル記号 ($) を付けることによって、クライアント固有の変数を作成できます。この変数は、同じファイルシステムの位置にアクセスする異なるアーキテクチャータイプの調整に役立ちます。変数名を括弧でくくることで、その後に続く文字や数字と変数とを区切ることができます。表 3-3 に定義済みのマップ変数を示します。
表 3-3 定義済みのマップ変数
|
鍵として使用する場合を除いて、変数はエントリ行内のどこにでも使用できます。たとえば、/usr/local/bin/sparc および /usr/local/bin/x86 から、SPARC アーキテクチャーと x86 アーキテクチャーのバイナリをそれぞれエクスポートするファイルサーバーがあるとします。クライアントは、次のようなマップエントリを使ってマウントすることができます。
/usr/local/bin -ro server:/usr/local/bin/$CPU
これで、すべてのクライアントの同じエントリがすべてのアーキテクチャーに適用されます。
注 - どの sun4 アーキテクチャー向けに書かれたアプリケーションでも、ほとんどはすべての sun4 プラットフォームで実行できます。-ARCH 変数は、sun4 にハードコードされています。
ファイルマップで使用されたマップエントリ +mapname により、automount は指定されたマップを、あたかも現在のマップに含まれているかのように読み取ります。mapname の前にスラッシュがない場合、autofs はそのマップ名を文字列として扱い、ネームサービススイッチ方式を使用してマップ名を検出します。パス名が絶対パス名の場合、automount はその名前のローカルマップを検索します。マップ名がダッシュ (-) で始まる場合、automount は hosts などの適切な組み込みマップを参照します。
svc:system/name-service/switch サービスはネームサービスの検索順序を保持しています。config プロパティーグループの automount プロパティーは、自動マウントエントリを探すときのネームサービスデータベースの検索順序を指定します。特定の config/automount プロパティーが指定されていない場合は、config/default プロパティーで定義された順序が使用されます。例:
# svcprop -p config svc:/system/name-service/switch config/value_authorization astring solaris.smf.value.name-service.switch config/printer astring user\ files config/default astring files\ nis config/automount astring files\ nis
この例では、ローカルファイル内のマップが NIS マップよりも先に検索されます。config/automount プロパティーが指定されていなかったとしても、config/default エントリが使用されるため、結果は同じになります。そのため、ローカルマップ /etc/auto_home に、もっとも頻繁にアクセスするホームディレクトリ用のエントリをいくつか含めることができます。他のエントリについては、スイッチを使用して NIS マップにフォールバックすることができます。
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny
組み込まれたマップを参照したあと、一致するものがなければ、automount は現在のマップの走査を続けます。そのため、+ エントリの後にさらにエントリを追加できます。
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny +auto_home
組み込まれたマップは、ローカルファイルまたは組み込みマップとすることができます。ローカルファイルだけが + エントリを持つことができることに注意してください。
+/etc/auto_mystuff # local map +auto_home # NIS map +-hosts # built-in hosts map
autofs マウントポイントを生成するコマンドを実行する autofs マップを作成することもできます。データベースやフラットファイルから autofs 構造を作成しなければならない場合は、実行可能な autofs マップが有効なことがあります。短所は、マップをすべてのホストにインストールしなければならないことです。実行可能なマップは、NIS ネームサービスに含めることができません。
実行可能マップは、auto_master ファイルにエントリが必要です。
/execute auto_execute
実行可能マップの例を示します。
#!/bin/ksh # # executable map for autofs # case $1 in src) echo '-nosuid,hard bee:/export1' ;; esac
この例が機能するためには、ファイルが /etc/auto_execute としてインストールされ、実行可能ビットがオンになっている必要があります。アクセス権は 744 に設定します。この場合、次のコマンドを実行すると、bee のファイルシステム /export1 がマウントされます。
% ls /execute/src
マップへのエントリを変更、削除、または追加して、ユーザーの環境ニーズに合わせることができます。ユーザーが必要とするアプリケーションやその他のファイルシステムがその位置を変更すると、マップはこれらの変更を反映しなければなりません。autofs のマップは、いつでも変更できます。automountd が次にファイルシステムをマウントしたときにその変更内容が有効になるかどうかは、変更したマップと変更内容によって決まります。
ブート時に、autofs は、サービス svc:/system/filesystem/autofs によって起動され、マスターマップ auto_master を確認します。次に説明する規則が適用されます。
autofs は、svc:/system/name-service/switch サービスの config/automount プロパティーで指定されたネームサービス順序を使用します。config/automount が定義されていない場合は、config/default プロパティーが使用されます。NIS を選択し、autofs が必要なマップを検出できない場合で、1 つまたは複数のアンダースコアを含むマップ名を検出したときには、それらのアンダースコアがドットに変更されます。こうすることにより、NIS の古いファイル名を利用することができます。図 3-6 に示されているように、次に autofs はもう一度マップを調べます。
図 3-6 autofs によるネームサービスの使用
このセッションでは、画面は次の例のようになります。
$ grep /home /etc/auto_master /home auto_home $ ypmatch brent auto_home Can't match key brent in map auto_home. Reason: no such map in server's domain. $ ypmatch brent auto.home diskus:/export/home/diskus1/&
ネームサービスとして「ファイル」が選択された場合、すべてのマップは /etc ディレクトリ内のローカルファイルとみなされます。autofs は、使用するネームサービスとは無関係に、スラッシュ (/) で始まるマップ名をローカルとして解釈します。