test

Solaris のシステム管理 (ネットワークサービス)

NFS デーモン

NFS アクティビティーをサポートするために、システムが実行レベル 3 またはマルチユーザーモードで稼動し始めたときに、複数のデーモンが起動されます。mountd デーモンおよび nfsd デーモンは、サーバーであるシステム上で実行されます。サーバーデーモンの自動起動は、NFS ファイルシステムのタイプでラベル付けされたエントリが /etc/dfs/sharetab に存在するかどうかで変わります。lockd デーモンおよび statd デーモンは、NFS クライアントおよび NFS サーバー上で実行され、NFS のファイルロックをサポートします。ただし、以前のバージョンの NFS とは異なり、NFS version 4 では、デーモン lockd、statd、mountd、および nfslogd は使用されません。

この節では、次のデーモンについて説明します。

automountd デーモン

このデーモンは autofs サービスからのマウントおよびアンマウント要求を処理します。このコマンドの構文は次のとおりです。

automountd [ -Tnv ] [ -D name= value ]

このコマンドは、次のように動作します。

自動マウントマップのデフォルト値は /etc/auto_master です。トラブルシューティングには -T オプションを使用してください。

lockd デーモン

このデーモンは NFS ファイルのレコードロックをサポートします。lockd デーモンは、ネットワークロックマネージャー (NLM) プロトコルについて、クライアントとサーバー間の RPC 接続を管理します。通常は、パラメータを指定しないで起動します。使用できるオプションは 3 つあります。lockd(1M) のマニュアルページを参照してください。これらのオプションは、コマンド行からも、/etc/default/nfs 内の適切な文字列を編集することによっても使用することができます。次は、/etc/default/nfs ファイルに設定可能なキーワードの説明です。

注 –

Solaris 10 以降のリリースでは、LOCKD_GRACE_PERIOD キーワードと-g オプションの使用は推奨されていません。推奨されていないキーワードは、新しいキーワード GRACE_PERIOD に置き換えられています。両キーワードが設定されている場合、GRACE_PERIOD の値は、LOCKD_GRACE_PERIOD の値に優先します。次の GRACE_PERIOD の説明を参照してください。

LOCKD_GRACE_PERIOD 同様、/etc/default/nfs に GRACE_PERIOD= graceperiod を追加すると、クライアントがサーバーのリブート後に NFS version 3 のロック (NLM が提供) と version 4 のロックを再要求する秒数を設定できます。つまり、GRACE_PERIOD の値は、NFS version 3 と NFS version 4 に対するロックリカバリの猶予期間を制御します。

/etc/default/nfs に LOCKD_RETRANSMIT_TIMEOUT=timeout パラメータを追加すると、ロック要求をリモートサーバーに再転送するまでの秒数を選択できます。このオプションは NFS クライアントのサービスに関係します。デフォルト値は 15 秒です。この値を小さくすると、トラフィックの多いネットワーク上の NFS クライアントに対する応答時間を改善できます。ただし、ロック要求が増えることによってサーバーの負荷が増す可能性があります。デーモンに -t timeout オプションを指定して開始すると、コマンド行から同じパラメータを使用できます。

/etc/default/nfs に LOCKD_SERVERS=nthreads パラメータを追加すると、サーバーが同時に処理できる各接続ごとのスレッドの最大数を指定できます。この値は、NFS サーバーに対して予想される負荷に基づいて決定してください。デフォルト値は 20 です。TCP を使用する各 NFS クライアントは、NFS サーバーとの間で 1 つの接続を使用するため、各クライアントは、サーバー上で、最大 20 のスレッドを同時に使用することができます。

UDP を使用するすべての NFS クライアントは、NFS サーバーと 1 つの接続を共有します。その場合、UDP 接続が使用できるスレッドの数を増やさなければならないことがあるかもしれません。各 UDP クライアントには、少なくとも 2 つのスレッドを許可します。ただし、この数は、クライアントの負荷により違います。そのため、クライアントごとに 2 つのスレッドを許可しても、十分ではない場合があります。多くのスレッドを使用する場合の不利な点は、これらのスレッドを使用すると、NFS サーバー上で使用するメモリーの容量が増えるという点です。ただし、スレッドを使用しない場合は、nthreads の値を増やしても影響がありません。デーモンに nthreads オプションを指定して開始すると、コマンド行から同じパラメータを使用できます。

mountd デーモン

このデーモンは、リモートシステムからのファイルシステムマウント要求を処理して、アクセス制御を行います。mountd デーモンは、/etc/dfs/sharetab を調べて、リモートマウントに使用可能なファイルシステムと、リモートマウントを実行できるシステムを判断します。このコマンドでは、-v オプションと -r オプションを使用できます。mountd(1M) のマニュアルページを参照してください。

-v オプションは、コマンドを冗長モードで実行します。クライアントが付与されるアクセス権を NFS サーバーが決定するたびに、コンソールにメッセージが表示されます。この情報は、クライアントがファイルシステムにアクセスできない理由を調べるときに役立ちます。

-r オプションは、その後のクライアントからのマウント要求をすべて拒絶します。このオプションを指定しても、すでにファイルシステムがマウントされているクライアントには影響しません。

注 –

NFS version 4 は、このデーモンを使用しません。

nfs4cbd デーモン

NFS version 4 クライアントの排他使用のための nfs4cbd は、NFS version 4 コールバックプログラムでの通信の終端を管理します。デーモンには、ユーザーがアクセス可能なインタフェースがありません。詳細は、nfs4cbd(1M) のマニュアルページを参照してください。

nfsd デーモン

これは、他のクライアントからのファイルシステム要求を処理するデーモンです。このコマンドに対してはいくつかのオプションを指定できます。オプションをすべて確認するには、nfsd(1M) のマニュアルページを参照してください。これらのオプションは、コマンド行からも、/etc/default/nfs 内の適切な文字列を編集することによっても使用することができます。

/etc/default/nfs に NFSD_LISTEN_BACKLOG=length パラメータを追加すると、接続型トランスポートを使用した NFS および TCP の接続キューの長さを設定できます。デフォルト値は 32 エントリです。nfsd に -l オプションを指定して開始すると、コマンド行から同じ項目を選択できます。

/etc/default/nfs に NFSD_MAX_CONNECTIONS=#-conn パラメータを追加すると、接続型トランスポートごとの最大接続数を選択できます。#-conn のデフォルト値はありません。コマンド行から -c #-conn オプションを指定してデーモンを開始すると、同じパラメータを使用できます。

/etc/default/nfs に NFSD_SERVER=nservers パラメータを追加すると、サーバーが一度に処理する要求の最大数を選択できます。nservers のデフォルト値は 16 です。コマンド行から nservers オプションを指定して nfsd を起動すると、同じように最大数を選択できます。

以前のバージョンの nfsd デーモンとは異なり、現在のバージョンの nfsd では複数のコピーを作成して要求を同時に処理することはありません。処理テーブルを ps でチェックすると、動作しているデーモンのコピーが 1 つしかないことがわかります。

nfslogd デーモン

このデーモンは実行された処理のログ機能を提供します。サーバーに対して記録される NFS 操作は、/etc/default/nfslogd に定義されている構成オプションに基づくものです。NFS サーバーのログ機能がオンになると、選択されたファイルシステム上でのすべての RPC 操作の記録がカーネルによりバッファーファイルに書き込まれます。次に nfslogd がこれらの要求を後処理します。ログインおよび IP アドレスへの UID をホスト名に割り当てやすくするために、ネームサービススイッチが使用されます。識別されたネームサービスで一致するものが見つからない場合は、その番号が記録されます。

パス名へのファイルハンドルの割り当ても nfslogd により行われます。このデーモンは、ファイルハンドルパスマッピングテーブル内でこれらの割り当てを追跡します。/etc/nfs/nfslogd で識別される各タグについて 1 つのマッピングテーブルが存在します。後処理の後に、レコードが ASCII ログファイルに書き込まれます。

注 –

NFS version 4 は、このデーモンを使用しません。

nfsmapid デーモン

version 4 の NFS プロトコル (RFC3530) では、クライアントとサーバーの間でユーザー識別子またはグループ識別子を交換する方法が変更されました。このプロトコルでは、NFS version 4 クライアントと NFS version 4 サーバーとの間で、ファイルの所有者とグループの属性をそれぞれ user@nfsv4_domain、group@nfsv4_domain の形式で文字列として交換する必要があります。

たとえば、known_user ユーザーに完全指定のホスト名が system.example.com である NFS version 4 クライアント上に UID 123456 が割り当てられているとします。このクライアントが NFS version 4 サーバーに要求を行うには、UID 123456 を known_user@example.com に割り当ててから、この属性を NFS version 4 サーバーに送信する必要があります。NFS version 4 サーバーは、ユーザーとグループのファイル属性を user_or_group@nfsv4_domain 形式で受信することを予期します。サーバーがクライアントから known_user@example.com を受信すると、サーバーはこの文字列をローカルの UID 123456 に割り当て 、配下のファイルシステムがこれを認識します。この機能では、ネットワーク上のすべての UID と GID が一意であること、およびクライアント上の NFS version 4 のドメインがサーバー上の NFS version 4 のドメインと一致していることを前提としています。

注 –

NFS version 4 のドメインが一致している場合でも、渡されたユーザー名またはグループ名をサーバーが認識しない場合、そのサーバーはそのユーザー名またはグループ名を一意の ID (整数値) に割り当てることができません。そのような場合は、サーバーは着信ユーザー名または着信グループ名を nobody ユーザーに割り当てます。そうした状況が発生することを避けるために、管理者は NFS version 4 クライアントだけに存在する特別なアカウントを作成しないようにしてください。

NFS version 4 のクライアントとサーバーは、整数から文字列への変換と文字列から整数への変換に対応しています。たとえば、NFS version 4 サーバーが GETATTR 処理を受け取ると、配下のファイルシステムから取得した UID および GID をそれぞれの文字列表現に割り当てたうえで、この情報をクライアントに送信します。またクライアントでも、UID と GID を文字列表現に割り当てる必要があります。たとえば、クライアントが chown コマンドを受け取ると、新しい UID および GID を文字列表現に割り当ててから、SETATTR 処理をサーバーに送信します。

ただし、クライアントとサーバーでは、文字列が認識されない場合の対処が異なることに注意してください。

構成ファイルと nfsmapid

次に、nfsmapid デーモンが /etc/nsswitch.conf ファイルと /etc/resolv.conf ファイルをどのように使用するかについて説明します。

優先ルール

    nfsmapid が正しく動作するには、NFS version 4 のクライアントとサーバーが同じドメインに割り当てられている必要があります。NFS version 4 ドメインが確実に一致するように、nfsmapid は次の厳密な優先ルールに従って動作します。

  1. デーモンは、NFSMAPID_DOMAIN キーワードに割り当てられた値を /etc/default/nfs ファイルで最初に確認します。値が検出された場合、その割り当てられている値は他の設定よりも優先されます。割り当てられている値は、発信属性文字列に追加され、着信属性文字列と比較されます。/etc/default/nfs ファイル内のキーワードの詳細は、「/etc/default/nfs ファイルのキーワード」を参照してください。手順については、「NFS サービスの設定」を参照してください。

    注 –

    NFSMAPID_DOMAIN 設定を使用する方法はスケーラブルではないため、大規模な配備を行う場合には推奨されません。

  2. 値が NFSMAPID_DOMAIN に割り当てられていない場合、デーモンは DNS TXT RR でドメイン名を確認します。nfsmapid は、resolver の一連のルーチンによって使用される /etc/resolv.conf ファイル内の指令に依存します。resolver は、設定されている DNS サーバーから _nfsv4idmapdomain TXT RR を検索します。DNS TXT レコードを使用する方がよりスケーラブルです。このため、/etc/default/nfs ファイルにキーワードを設定するよりも、TXT レコードを継続して使用する方がよいでしょう。

  3. ドメイン名を提供する DNS TXT レコードが設定されていない場合、nfsmapid デーモンは /etc/resolv.conf ファイル内の domain または search 指令で指定された値を使用します。このとき、最後に指定された指令が優先されます。

    次の例では、domain および search の両方の指令が使用されています。nfsmapid デーモンは、search 指令のあとに最初に記載されているドメイン名である company.com を使用します。


    domain example.company.com
search company.com foo.bar.com

  4. /etc/resolv.conf ファイルが存在しない場合、nfsmapid は domainname コマンドの動作に従って NFS version 4 ドメインの名前を取得します。より詳しく説明すると、/etc/defaultdomain ファイルが存在する場合には、nfsmapid は NFS version 4 ドメインのためにそのファイルの内容を使用します。/etc/defaultdomain ファイルが存在しない場合には、nfsmapid はネットワークに設定されているネームサービスから渡されるドメイン名を使用します。詳細は、domainname(1M) のマニュアルページを参照してください。

nfsmapid と DNS TXT レコード

DNS は汎用性が高いので、NFS version 4 のドメイン名を格納して配布するための効率的な機構です。また、DNS は本質的にスケーラブルなので、DNS TXT リソースレコードを使用する方法は、大規模な配備の NFS version 4 のドメインを設定するうえで、もっとも推奨される方法です。エンタープライズレベルの DNS サーバーでは、_nfsv4idmapdomain TXT レコードを設定するようにしてください。このように設定すれば、NFS version 4 のクライアントまたはサーバーは DNS ツリーをたどることによって NFS version 4 ドメインを見つけることができます。

DNS サーバーから NFS version 4 のドメイン名を提供するように設定するときは、次の例のように入力することをお勧めします。


_nfsv4idmapdomain		IN		TXT			"foo.bar"

この例では、設定されるドメイン名は、二重引用符で囲まれている値です。ttl フィールドが指定されていないことと、ドメインが owner フィールドの値である _nfsv4idmapdomain に追加されていないことに注意してください。この設定により、TXT レコードで、Start-Of-Authority (SOA) レコードのゾーンの ${ORIGIN} エントリを使用できるようになります。たとえば、さまざまなレベルのドメイン名前空間で、レコードは次のように読み取ることができます。


_nfsv4idmapdomain.subnet.yourcorp.com.    IN    TXT    "foo.bar"
_nfsv4idmapdomain.yourcorp.com.           IN    TXT    "foo.bar"

この設定では、DNS クライアントが DNS ツリー階層を検索するときに、resolv.conf ファイルを使用して柔軟に検索することができます。resolv.conf(4) のマニュアルページを参照してください。この機能により、TXT レコードの検索での確率がより高くなります。柔軟性の向上により、低いレベルの DNS サブドメインが、自身の DNS TXT リソースレコード (RR) を定義できるようになりました。この機能により、低いレベルの DNS サブドメインを、高いレベルの DNS ドメインの定義した TXT レコードに優先させることができます。

注 –

TXT レコードで指定したドメインには、任意の文字列を使用できます。この文字列は、NFS version 4 を使用するクライアントとサーバーの DNS ドメインと同じである必要はありません。 NFS version 4 データをほかの DNS ドメインと共有しないようにするオプションがあります。

NFS version 4 のドメインを確認する

ネットワークの NFS version 4 ドメインの値を割り当てる前に、ネットワークに NFS version 4 ドメインがすでに設定されているかどうかを確認します。次の例は、ネットワークの NFS version 4 ドメインを確認する方法を示します。

詳細は、次のマニュアルページを参照してください。

NFS version 4 のデフォルトドメインを設定する

この節では、ネットワークがどのようにして目的のデフォルトドメインを取得するかについて説明します。

Solaris Express 5/06 リリースで NFS version 4 のデフォルトドメインを設定する

初期 Solaris 10 リリースでは、OS インストール後の初回システムリブート中に、ドメインの定義が行われていました。Solaris Express 5/06 リリースでは、OS のインストール中に NFS version 4 ドメインの定義が行われます。この機能を提供するために、次の機能が追加されました。

    次に、この機能の動作手順を説明します。

  1. sysidnfs4 プログラムは /etc/.sysIDtool.state ファイルをチェックし、NFS version 4 ドメインが特定されているかどうかを判定します。

    • .sysIDtool.state ファイルから、ネットワークの NFS version 4 ドメインが設定されていることが判明すると、sysidnfs4 プログラムはそれ以上のチェックを行いません。次の .sysIDtool.state ファイルの例を参照してください。


      1       # System previously configured?
1       # Bootparams succeeded?
1       # System is on a network?
1       # Extended network information gathered?
1       # Autobinder succeeded?
1       # Network has subnets?
1       # root password prompted for?
1       # locale and term prompted for?
1       # security policy in place
1       # NFSv4 domain configured
xterms

      # NFSv4 domain configured の前に 1 が表示されていれば、NFS version 4 ドメインが設定されています。

    • .sysIDtool.state ファイルから、ネットワークの NFS version 4 ドメインが設定されていないことが判明した場合、sysidnfs4 プログラムはさらなるチェックを行う必要があります。次の .sysIDtool.state ファイルの例を参照してください。


      1       # System previously configured?
1       # Bootparams succeeded?
1       # System is on a network?
1       # Extended network information gathered?
1       # Autobinder succeeded?
1       # Network has subnets?
1       # root password prompted for?
1       # locale and term prompted for?
1       # security policy in place
0       # NFSv4 domain configured
xterms

      # NFSv4 domain configured の前に 0 が表示されていれば、NFS version 4 ドメインは設定されていません。

  2. NFS version 4 ドメインが特定されていない場合、sysidnfs4 プログラムは sysidcfg ファイル内の nfs4_domain キーワードをチェックします。

    • nfs4_domain の値が存在する場合は、その値が /etc/default/nfs ファイル内の NFSMAPID_DOMAIN キーワードに設定されます。NFSMAPID_DOMAIN に値が設定されると、その値が何であれ、それが nfsmapid デーモンの動的ドメイン選択機能よりも優先されます。nfsmapid の動的ドメイン選択機能の詳細については、「優先ルール」を参照してください。

    • nfs4_domain の値が存在しない場合、sysidnfs4 プログラムは、オペレーティングシステムの設定済みネームサービスから nfsmapid によって派生されるドメインを特定します。この派生値はデフォルトドメインとして対話プロンプトに表示されますが、ユーザーは、そのデフォルト値を受け入れるか、異なる NFS version 4 ドメインを割り当てるかを選択できます。

この機能により、次のものが廃止になります。

注 –

DNS 特有のユビキタスでスケーラブルな性質のため、大規模な NFS version 4 配備のドメイン設定には DNS TXT レコードを引き続き使用することを強く推奨します。「nfsmapid と DNS TXT レコード」を参照してください。

Solaris のインストールプロセスに関する具体的な情報については、次を参照してください。

Solaris 10 リリースで NFS version 4 のデフォルトドメインを設定する

初期 Solaris 10 リリースの NFS version 4 では、ネットワーク内に複数の DNS ドメインが存在しているにもかかわらず、単一の UID および GID 名前空間しかない場合、すべてのクライアントが NFSMAPID_DOMAIN に対して単一の値を使用する必要があります。DNS を使用するサイトでは、nfsmapid が、_nfsv4idmapdomain に割り当てられた値からドメイン名を取得して、この問題を解決します。詳細は、「nfsmapid と DNS TXT レコード」を参照してください。ネットワークが DNS を使用する構成になっていない場合は、Solaris オペレーティングシステムの最初のブート時に、 sysidconfig(1M) ユーティリティーによって NFS version 4 のドメイン名に関する次のプロンプトが表示されます。


This system is configured with NFS version 4, which uses a 
domain name that is automatically derived from the system's 
name services. The derived domain name is sufficient for most 
configurations. In a few cases, mounts that cross different 
domains might cause files to be owned by nobody due to the 
lack of a common domain name.

Do you need to override the system's default NFS verion 4 domain 
name (yes/no)? [no]

デフォルトの応答は [no] です。[no] を選択すると、次のプロンプトが表示されます。


For more information about how the NFS version 4 default domain name is 
derived and its impact, refer to the man pages for nfsmapid(1M) and 
nfs(4), and the System Administration Guide: Network Services.

[yes] を選択すると、次のプロンプトが表示されます。


Enter the domain to be used as the NFS version 4 domain name.
NFS version 4 domain name []:
注 –

NFSMAPID_DOMAIN の値が /etc/default/nfs に存在する場合は、指定した [domain_name] が優先されます。

nfsmapid の追加情報

nfsmapid の詳細は、次を参照してください。

statd デーモン

lockd とともに動作し、ロックマネージャーにクラッシュ/回復機能を提供します。statd デーモンは、NFS サーバーにロックを保持するクライアントを追跡します。サーバーがクラッシュした場合は、サーバーのリブート中に、サーバー側 statd がクライアント側 statd にコンタクトします。次にクライアント側 statd は、サーバー上のすべてのロックを再要求します。クライアント側 statd は、サーバー上のクライアントのロックがクリアされるように、サーバー側 statd にクライアントがいつクラッシュしたかを通知します。このデーモンにオプションはありません。詳細は、statd(1M) のマニュアルページを参照してください。

Solaris 7 で、statd がクライアントを追跡する方法が改善されました。Solaris 7 より前のリリースの statd では、クライアントごとにそのクライアントの修飾されていないホスト名を使用して、/var/statmon/sm にファイルが作成されました。そのため、同じホスト名の 2 つのクライアントが異なるドメインに存在する場合や、クライアントが NFS サーバーと異なるドメインに存在する場合に、このファイルのネーミングが原因となり問題が発生していました。修飾されていないホスト名にはドメインや IP アドレスの情報がないため、このようなクライアントを区別する方法がありませんでした。これに対処するため、Solaris 7 の statd では、修飾されていないホスト名に対してクライアントの IP アドレスを使用して /var/statmon/sm にシンボリックリンクを作成します。このリンクは、次のようになります。


# ls -l /var/statmon/sm
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv4.192.168.255.255 -> myhost
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv6.fec0::56:a00:20ff:feb9:2734 -> v6host
--w-------   1 daemon          11 Apr 29 16:32 myhost
--w-------   1 daemon          11 Apr 29 16:32 v6host

この例では、クライアントのホスト名は myhost で、クライアントの IP アドレスは 192.168.255.255 です。ほかのホストが myhost という名前を持ち、ファイルシステムをマウントしていると、myhost というホスト名に対するシンボリックリンクは 2 つ作成されます。

注 –

NFS version 4 は、このデーモンを使用しません。