FreeBSD で NFS – (NFSの概要 / NFS とは)

今回は NFS について改めて纏めてみました．

FreeBSD の NFS について以前 Pukiwiki の「FreeBSD で NFS(Network File System) サーバ & クライアント」に纏めていましたが，当時 5.0 RELEASE の頃に纏めてましたのでだいぶ状況が変わってしまいました．
ですので今のバージョン 9.2-RELEASE をターゲットに改めて解説します．

NFS に関する話題

NFSのおさらい

NFSのおさらい

NFS というプロトコルの説明は他色々な場所で説明されていますので以下では簡単に説明します．

NFS のバージョン

NFS バージョンは v2, v3, v4 の3つがあります．v1 は Sun Microsystems 内部でのみ存在したバージョンのようです．
多くのところでは NFSv3 が利用されています．v2 はもう利用している所は殆どないと思います．NFSv4 の利用は増えていっていますが，v3 決め打ちの製品がある等で今一歩という所です．~~v3 決め打ちの有名どころでは ESX/ESXi ですね．~~
vSphere も現在は NFSv3 と NFSv4 の両方を利用できるようになっています．

NFS には v2，v3，v4 の 3つのバージョンがあります．v1 は Sun Microsystems 内部でのみ存在したと言われています．
現在一般的には，多くの場所で NFSv3が利用されています．NFSv2 はほとんど使われていません．

NFSv4 の利用は増えていますが，NFSv3 に固定された製品があるため，完全に移行するにはまだ一歩が残っています．以前の ESX/ESXi などの製品が NFSv3 に固定されていましたが，現在では NFSv3 と NFSv4 の両方を利用できます．

各バージョンの違いを簡単に表にすると次のようになります．

	NFSv2	NFSv3	NFSv4
トランスポート	UDP	UDP/TCP	TCP
ファイルサイズ制限	2GB	なし	なし
ファイルロック	あり(別プロトコル)	あり(別プロトコル)	あり
非同期書き込み	なし	あり	あり
ステート保持	あり(別プロトコル)	あり(別プロトコル)	あり

NFSv3 を構成するプログラム(デーモン)

NFS は単純なようですが実際には複雑で，複数のデーモンを使用してサービスが提供されています．それらのデーモンの役割を簡単に説明します．

rpcbind

以前は portmap デーモンと呼ばれていました．RPC プログラム番号からユニバーサルアドレスに変換するサーバです．RPC を使用するプログラムは，プログラム開始時に rpcbind に通知され，それらプログラムが待ち受けるポート番号の情報や RPC プログラム番号等が登録されます．後述する mountd は RPC を利用しますのでこのプログラムは動作必須なものとなります．

以前は portmap デーモンとして知られていました．RPC プログラム番号をユニバーサルアドレスに変換するサーバーです．RPC を使用するプログラムは，プログラム開始時に rpcbind に通知され，それらのプログラムが待ち受けるポート番号の情報や RPC プログラム番号などが登録されます．
後述する mountd は RPC を利用するため，このプログラムは必須となります．

mountd

mountd はマウント処理を担当するデーモンです．NFS アクセスにはファイルハンドルが必要で，これは inode のようなものです．NFS クライアントは，このファイルハンドルの番号を知るために mountd がNFS共有しているディレクトリ（マウントポイント）のファイルハンドルを通知します．
その後，NFSクライアントは基点のファイルハンドルを知り，直接 nfsd と通信します．
このため，mountd は NFS アクセスの最初の段階でのみ介入します．NFS マウント済みのクライアントを許可ネットワークから外した場合でも，NFS クライアントは通信を継続します．対処方法は NFS セッションを切断することのみですので注意してください．

nfsd

NFS サーバーデーモンは，RPCを使用ますので rpcbind に依存します．NFS リクエストを受け取った後，ローカルのファイルシステムへのアクセスに変換し，読み書きなどの処理を行った後に NFS クライアントに結果を返します．

rpc.lockd

rpc.lockd は NFSプロトコル上でファイルロックを実現するためのデーモンです．NFS Lock Manager（NLM）という別のプロトコルが開発され，rpc.lockd がそのプロトコルを担当します．
このデーモンが動作していないとファイルロックが利用できず，さまざまな不都合が生じます．
このデーモンはサーバーとクライアントの両方で動いている必要があります．5.0-RELEASE あたりから利用可能になり，8.x 頃にカーネルに統合されました．

rpc.statd

rpc.statd は NFS Lock Manager のステータスを管理する NFS Status Monitor プロトコルのデーモンです．NFS Lock Manager は状態を保持せず，NFS サーバーが再起動するとロック情報が失われます．これを防ぐために rpc.statd はロック情報をローカルに保持し，サーバーの復旧後にロック状態を引き継ぎます．

FreeBSD の NFS 実装

FreeBSD 8.0 で NFS 実装に大きな変更がありました．新しい実装は NFSv4 に対応し，古い実装と並行して提供されます．
デフォルトでは古い実装が動作しますが，9.0 では逆に新しい実装が優先されます．
9.2-RELEASE 以降は特に理由がない限り新しい実装を利用することが推奨されます．
私の環境では以前は新しい実装が不安定でしたが，現在は問題なく利用しています．

NFSv3 までの落とし穴

NFS を使う際によく問題になる箇所は FreeBSD に限らずいくつかあります．

UID と GID の不一致

NFSv3 まででは、サーバー上の UID/GID とクライアントの UID/GID が一致していることが前提です．管理できないクライアントを NFS サーバに接続すると，意図しないファイルアクセスが発生する可能性があります．
例えば，サーバ側の「UID 100: seichan」と、クライアント側の「UID 100: foo」がある場合，クライアントの「foo」が NFS アクセスすると，サーバ上の「seichan」のファイルの所有者として認識されます．
root アクセスを許可している場合はさらに危険です．管理できない端末の接続を最初から拒否する運用が必要です．

ポート番号が不定

RPC を使用する為，ポート番号が一定ではありません．その為，良くファイアウォールで拒否されてしまい NFS アクセスが出来ない．なんてトラブルが発生します．指定する事で固定化出来ますので固定化をしたのちに問題が無いか確認，その後フィルタルールを設定する．なんていう対応が必要となります．
また，異機種間の場合は正しく固定化出来るのか．等をあらかじめ確認しておく事をお薦めします．

RPC を使用するため，ポート番号は一定ではありません．そのため，ファイアーウォールで拒否されて NFS アクセスができないトラブルがよく発生します．
使用するポート番号固定化，ファイアーウォールのフィルタールールを設定することで問題を回避しができます．
異なる機種間では固定化できるかどうか事前に確認することをお勧めします．

以上が NFS の概要についての説明です．次回は NFS サーバーの設定について解説します．