第8章 Network File System (NFS)

ネットワークファイルシステム (NFS) を利用すると、リモートのホストはネットワーク経由でファイルシステムをマウントし、そのファイルシステムをローカルにマウントしているファイルシステムと同じように操作することができるようになります。また、システム管理者は、リソースをネットワーク上の中央サーバーに統合することができるようになります。
この章では、基本的な NFS の概念と補足的な情報に焦点を絞って説明します。

8.1. NFS の概要

現在、Red Hat Enterprise Linux には以下の 2 つの主要バージョンの NFS が含まれています。
  • NFS バージョン 3 (NFSv3) は安全な非同期書き込みをサポートしており、以前の NFSv2 よりもエラー処理において安定しています。64 ビットのファイルサイズとオフセットもサポートしているため、クライアントは 2 GB を超えるファイルデータにアクセスできます。
  • NFS バージョン 4 (NFSv4) はファイアウォールやインターネットを介して動作し、rpcbind サービスを必要とせず、ACL に対応し、ステートフルな操作を利用します。
Red Hat Enterprise Linux は 7.4 リリース以来、NFS バージョン 4.2 (NFSv4.2) に完全に対応しています。
以下は Red Hat Enterprise Linux 7.5 における NFSv4.2 の機能です。
  • サーバー側のコピー: NFSv4.2 は copy_file_range() システム呼び出しに対応しています。これにより、NFS クライアントはネットワークリソースを無駄にせずに、効率よくデータをコピーできます。
  • スパースファイル: ファイルの容量効率を検証し、プレースホルダーを許可してストレージ効率を向上します。これは、1 つ以上のホールを持つファイルです。これらのホールは、割り当てられていない、または初期化されていないゼロのみから成るデータブロックです。NFSv4.2 の lseek() 操作は seek_hole() と seek_data() に対応しています。これにより、アプリケーションがスパースファイルにホールの場所をマッピングできるようになります。
  • スパース予約: ストレージサーバーが空き領域を予約することを許可します。これにより、サーバーで領域が不足することがなくなります。NFSv4.2 は、スペースを予約するための allocate() 操作、スペースの予約を解除するための deallocate() 操作、およびファイル内のスペースの事前割り当てまたは割り当て解除を行う fallocate() 操作をサポートしています。
  • ラベル付き NFS: データアクセス権を強制し、NFS ファイルシステム上の個々のファイルに対して、クライアントとサーバー間の SELinux ラベルを有効にします。
  • レイアウト拡張: NFSv4.2 では、新しい操作 layoutstats() を利用できます。この操作では、クライアントがレイアウトとの通信についてのメタサーバーを通知するのに使用できます。
最大 4.1 までの 7.4 以前のバージョンの Red Hat Enterprise Linux
NFSv4.1 の機能は次のとおりです。
  • ネットワークのパフォーマンスとセキュリティーを強化し、Parallel NFS (pNFS) のクライアント側サポートも含みます。
  • コールバックに個別の TCP 接続を必要としなくなりました。これにより、NAT やファイアウォールが干渉した場合など、クライアントと通信できない場合でも NFS サーバーは委任を許可できます。
  • 応答が失われて、操作が 2 回送信された場合に特定の操作が不正確な結果を返すことがあるという以前の問題を防ぐために、1 回限りのセマンティクスを提供します (リブート操作を除く)。
NFS クライアントはデフォルトで NFSv4.1 を使用してマウントを試みます。サーバーが NFSv4.1 に対応していない場合は、NFSv4.0 にフォールバックします。サーバーが NFSv4.0 に対応していない場合は、NFSv3 にフォールバックします。

注記

NFS バージョン 2 (NFSv2) は、Red Hat のサポート対象外になりました。
NFS の全バージョンで、IP ネットワーク経由で実行する Transmission Control Protocol (TCP) を使用することができ、NFSv4 の場合は TCP が必須になります。NFSv3 では IP ネットワーク経由で実行する User Datagram Protocol (UDP) を使用してクライアントとサーバー間のステートレスなネットワーク接続を提供することができます。
UDP で NFSv3 を使用する場合、(通常の状況では) ステートレスな UDP 接続のプロトコルのオーバーヘッドは TCP より少なくなります。つまり、クリーンで適度なトラフィックのネットワーク上では、UDP の方がパフォーマンスがよくなります。ただし、UDP はステートレスのため、予期しないサーバーダウンなどが発生すると、UDP クライアントはサーバーの要求でネットワークを飽和させ続けます。また、UDP の場合にフレームがなくなると、RPC 要求全体を再転送しなければならなくなります。一方、TCP の場合、再送信が必要なのは失ったフレームのみになります。こうした理由から NFS サーバーへの接続には TCP プロトコルが推奨されます。
マウントおよびロックのプロトコルが NFSv4 プロトコルに組み込まれています。サーバーは、一般的に使用されている TCP ポート 2049 でもリッスンします。このように、NFSv4 では、デーモン rpcbind[1]、 lockd、rpc.statd とのやりとりが必要なくなります。rpc.mountd デーモンは、NFS サーバーでエクスポートをセットアップするのに必要ですが、送信オペレーションには関与しません。

注記

Red Hat Enterprise Linux では、TCP が NFS バージョン 3 のデフォルトの転送プロトコルになります。UDP は互換性に必要となる場合は使用できますが、その使用範囲についてはできるだけ限定することを推奨しています。NFSv4 には TCP が必須となります。
すべての RPC/NFS デーモンには '-p' コマンドラインオプションがあり、ポートを設定することができるため、ファイアウォールの設定が容易になります。
TCP ラッパーによってクライアントにアクセスが許可されると、NFS サーバーは、/etc/exports 設定ファイルを参照して、そのクライアントがエクスポート済みファイルシステムへのアクセスできるかどうかを確認します。アクセスが可能なことが確認されると、そのユーザーは、ファイルおよびディレクトリーへの全操作を行えるようになります。

重要

ファイアーウォールを有効にしている Red Hat Enterprise Linux のデフォルトインストールで NFS を正しく動作させるために、IPTables は、デフォルトの TCP ポート 2049 に設定してください。IPTables が正しく設定されていないと、NFS は正常に動作しません。
NFS の初期化スクリプトおよび rpc.nfsd プロセスでは、システム起動中の指定ポートへのバインドが可能になりました。ただし、このポートが使用できない場合や、別のデーモンと競合してしまう場合は、エラーが発生しやすくなる可能性があります。

8.1.1. 必須サービス

Red Hat Enterprise Linux では、NFS ファイル共有を提供するのに、カーネルベースのサポートとデーモンのプロセスの組み合わせを使用します。NFS のすべてのバージョンは、クライアントとサーバー間の Remote Procedure Call (RPC) に依存します。Red Hat Enterprise Linux 7 での RPC サービスは rpcbind サービスで制御されます。NFS ファイルシステムの共有やマウントには、実装されている NFS のバージョンに応じて次のようなサービスが連携して動作することになります。

注記

portmap サービスは、Red Hat Enterprise Linux の旧バージョンで、RPC プログラム番号を、IP アドレスとポート番号の組み合わせにマッピングするのに使用されていました。このサービスは、Red Hat Enterprise Linux 7 でIPv6 に対応にするため、rpcbind に置き換えられています。
nfs
systemctl start nfs により NFS サーバーおよび該当の RPC プロセスが起動し、共有 NFS ファイルシステムの要求が処理されます。
nfslock
systemctl start nfs-lock は、適切な RPC プロセスを起動する必須サービスをアクティベートし、NFS クライアントがサーバー上のファイルをロックできるようにします。
rpcbind
rpcbind で、ローカルの RPC サービスからポート予約を受け取ると、これらのポートはリモートの RPC サービスによってアクセス可能であることが公開されます。rpcbind は、RPC サービスの要求に応答し、要求された RPC サービスへの接続のセットアップを行います。NFSv4 では rpcbind は使用されません。
以下の RPC プロセスは NFS サービスと連携して動作します。
rpc.mountd
NFS サーバーは、このプロセスを使用して NFSv3 クライアントの MOUNT 要求を処理します。要求されている NFS 共有が現在 NFS サーバーで公開されているか、またその共有へのクライアントのアクセスが許可されているかをチェックします。マウントの要求が許可されると、rpc.mountd サーバーは Success ステータスで応答し、この NFS 共有用の File-Handle を NFS クライアントに戻します。
rpc.nfsd
rpc.nfsd では、サーバーが公開している明示的な NFS のバージョンとプロトコルを定義できます。NFS クライアントが接続するたびにサーバースレッドを提供するなど、NFS クライアントの動的なデマンドに対応するため、Linux カーネルと連携して動作します。このプロセスは nfs サービスに対応します。
lockd
lockd はクライアントとサーバーの両方で実行されるカーネルスレッドです。Network Lock Manager (NLM) プロトコルを実装し、NFSv3 のクライアントがサーバー上でファイルのロックを行えるようにします。NFS サーバーが実行中で、NFS ファイルシステムがマウントされていれば、このプロセスは常に自動的に起動します。
rpc.statd
Network Status Monitor (NSM) RPC プロトコルを実装します。NFS サーバーが正常にシャットダウンされず再起動すると、NFS クライアントに通知します。 rpc.statd は、nfslock サービスによって自動的に起動されるため、ユーザー設定を必要としません。このプロセスは NFSv4 では使用されません。
rpc.rquotad
リモートユーザーのユーザークォータ情報を提供します。rpc.rquotad は nfs サービスによって自動的に起動するため、ユーザー設定を必要としません。
rpc.idmapd
rpc.idmapd は、ネットワーク上の NFSv4 の名前 (user@domain 形式の文字列) とローカルの UID および GID とのマッピングを行う NFSv4 クライアントアップコールおよびサーバーアップコールを提供します。idmapd を NFSv4 で正常に動作させるには、/etc/idmapd.conf ファイルを設定する必要があります。最低でもNFSv4 マッピングドメインを定義する「Domain」パラメーターを指定する必要があります。NFSv4 マッピングドメインが DNS ドメイン名と同じであると、このパラメーターをスキップできます。クライアントとサーバーが ID マッピングの NFSv4 マッピングドメインに一致しないと、適切に動作しません。

注記

Red Hat Enterprise Linux 7 では、NFSv4 サーバーのみが rpc.idmapd を使用します。NFSv4 はキーリングベース の idmapper の nfsidmap を使用します。nfsidmap は要求に応じてカーネルによって呼び出され、ID マッピングを実行するスタンドアロンプログラムで、デーモンではありません。nfsidmap に問題がある場合、クライアントは rpc.idmapd を使用してフォールバックします。nfsidmap の詳細は、nfsidmap の man ページを参照してください。

[1] rpcbind サービスは、旧バージョンの Red Hat Enterprise Linux で、各 RPC プログラムの番号を、IP アドレスのポート番号の組み合わせにマッピングするために使用していた portmap に代わります。詳細は 「必須サービス」 を参照してください。