本番NFSv4マウントを最適化する｜バージョン選択からオプション差分確認と障害時の切り戻し手順まで

NFSv4を本番で選ぶ理由と、v4.0・v4.1・v4.2の差分整理

NFSはLinuxサーバー間のファイル共有において、依然として最も広く採用されているプロトコルです。しかしバージョン違いによる挙動差は見落とされやすく、「動いているからいい」と放置した結果、高負荷時のパフォーマンス劣化や予期しない切断が発生する現場は少なくありません。

NFSv4系を選ぶ現実的な理由は、セキュリティと運用性の両立にあります。v4以降はKerberosベースの認証をプロトコルネイティブでサポートし、ファイアウォール越えもTCPポート2049番のみで完結します。v3以前で必要だったportmapperやrpcbindへの穴あけが不要になるため、ネットワークポリシーの管理が単純化されます。

バージョン間の主な差分は次のとおりです。v4.0はステートフルプロトコルとしての基本形で、UIDマッピングがID-domain依存になります。v4.1でpNFS（並列NFS）が導入され、ストレージバックエンドが対応していれば複数パスへの分散I/Oが可能になります。v4.2ではサーバーサイドコピー（`copy_file_range`システムコール活用）、スパースファイル対応、スペース予約などが追加されました。2026年時点でRHEL 9系・Ubuntu 24.04 LTS・Debian 12いずれもv4.2をデフォルトネゴシエーション対象として扱いますが、サーバー側カーネルが古ければv4.1以下へ自動降格します。まず`nfsstat -m`でネゴシエーション結果を確認する習慣が重要です。

マウントオプションの意味と本番向け推奨設定

NFSのマウントオプションは多岐にわたりますが、本番環境でとくに影響が大きいものに絞って整理します。

• nfsvers=4.2（または4.1）：バージョンを明示することで、ネゴシエーションのタイムアウト待ちを省略します。本番では自動検出に任せず固定が基本です。
• rsize / wsize：読み書きブロックサイズ。現在のカーネルでは最大1MiB（1048576）まで指定可能で、GbE以上の環境では262144〜1048576の範囲で計測して決定します。デフォルト（131072）のままでは大ファイル転送でスループットが伸び悩む場合があります。
• timeo / retrans：タイムアウト（単位：0.1秒）と再送回数。NFSv4はTCP固定のため、timeoは接続断の検出速度に影響します。LANであればtimeo=30・retrans=3程度が現実的な出発点です。
• hard / soft：`hard`はサーバー復旧まで待ち続け、`soft`はタイムアウト後にEIOを返します。データ整合性を優先する本番DBや共有ストレージでは`hard`が原則です。`soft`はバッチ処理など「失敗してもリトライ設計がある」用途に限定します。
• intr：v4では廃止されています。古い設定ファイルに残っていても無視されますが、混乱を避けるため削除を推奨します。
• _netdev：fstabに記述する場合、ネットワーク起動後にマウントさせるために必須です。これがないと起動シーケンス上でマウントが先走り、NFSサーバーに到達できず起動が停止することがあります。
• noresvport：クライアントが非特権ポートを使用することを許可します。コンテナ環境ではルートポート確保が難しいケースがあるため、用途に応じて検討します。

まとめると、汎用的な本番向けエントリはおおむね次の形になります。

nfsserver:/export/data  /mnt/data  nfs  nfsvers=4.2,rsize=1048576,wsize=1048576,hard,timeo=30,retrans=3,_netdev  0  0

この値はあくまで出発点です。実測なしに適用するのは避け、後述する検証手順と合わせて調整してください。

systemd時代のマウント手順とfstab設計

現行のディストリビューションではsystemdがマウントユニットを管理します。fstabに記述するアプローチと、`.mount`ユニットファイルを直接書くアプローチの2つがあります。多くの現場ではfstabが引き続き主流ですが、複雑な依存関係や条件付きマウントが必要な場合はユニットファイルのほうが制御しやすいです。

fstab編集後は、いきなん再起動せずに`systemctl daemon-reload`を実行してからマウントします。

# fstab編集後にデーモンを再読み込み
sudo systemctl daemon-reload

# 特定のマウントポイントだけ有効化
sudo systemctl start mnt-data.mount

# 起動時自動マウントを確認
sudo systemctl is-enabled mnt-data.mount

systemdはfstabの`_netdev`オプションを検出すると、自動的に`network-online.target`への依存を付与します。これにより、ネットワーク疎通が確立する前にNFSマウントを試みる問題を回避できます。ただし`NetworkManager-wait-online.service`や`systemd-networkd-wait-online.service`が正しく有効化されていることが前提です。クラウドVMではこのサービスが無効化されているケースがあるため、`systemctl is-enabled systemd-networkd-wait-online.service`で確認しておくことを推奨します。

automount（autofs）を使う場合は`.automount`ユニットとセットで設定します。アイドルタイムアウトによる自動アンマウントは、長時間アクセスがない共有ディレクトリに有効ですが、デーモンプロセスが開いているファイルハンドルを持つ場合にアンマウントが失敗してログを汚すことがあるため、本番の常時アクセス領域には向きません。

マウント後の動作検証とオプション差分確認

設定を適用したら、必ず動作検証を行います。「マウントできた＝正常」ではなく、「意図したオプションでマウントされているか」「スループットが期待値に近いか」まで確認することが本番品質の基準です。

マウントオプションの確認は`nfsstat -m`または`findmnt`で行います。

# マウント中のNFSオプションをすべて表示
nfsstat -m

# findmntで特定パスのオプションを確認
findmnt -t nfs4 -o TARGET,OPTIONS

ここでnfsversが意図したバージョンになっているか、rsize/wsizeが設定値と一致しているかを目視します。カーネルが対応していない場合、指定値より小さい値に自動調整されることがあります。

スループット計測にはddまたはfioを使います。NFSマウント上でddを実行し、ローカルディスクとの差分を把握しておくことで、後日のパフォーマンス問題の切り分けが容易になります。

# 書き込みスループットの簡易計測（キャッシュを排除するため conv=fdatasync を付与）
dd if=/dev/zero of=/mnt/data/testfile bs=1M count=1024 conv=fdatasync

# 読み込みスループット（ページキャッシュを除外）
echo 3 | sudo tee /proc/sys/vm/drop_caches
dd if=/mnt/data/testfile of=/dev/null bs=1M

NFSの統計情報は`nfsiostat`（nfs-utils同梱）で継続監視できます。`ops/s`や`avg RTT`を定常状態で記録しておくと、障害時の比較基準になります。

障害時の切り戻し手順と強制アンマウント

NFSサーバー側の障害やネットワーク断が発生すると、`hard`オプションでマウントしたクライアントは無限に再試行を続けます。この状態では対象マウントポイントへのアクセスがブロックされ、プロセスがDスリープ（割り込み不可スリープ）に陥ります。

通常の`umount`はこの状態では応答しません。対処手順は次のとおりです。

# ステップ1: 遅延アンマウント（プロセスが離れたら自動的にアンマウント）
sudo umount -l /mnt/data

# ステップ2: それでも残る場合は強制アンマウント（データ損失リスクあり）
sudo umount -f /mnt/data

# ステップ3: Dスリープ中のプロセスを確認
ps aux | grep ' D '

`umount -l`（lazy umount）はファイルシステムをVFSから切り離し、既存の参照が閉じられ次第クリーンアップします。`-f`（force）はNFS固有の強制切断で、正常にクリーンアップできない場合がある点に注意が必要です。

切り戻しが必要な場合は、fstabの該当行をコメントアウトするか、別のマウントポイント（ローカルディレクトリ・別NASなど）に差し替えてから`systemctl daemon-reload`と`systemctl start`を再実行します。再マウント前にサーバー側の`exportfs -v`でエクスポート状態を確認し、アクセス権や`fsid`の設定も合わせて検証することが重要です。

なお、NFSv4ではサーバーが一時的に不在でもクライアントがグレースピリオド（デフォルト90秒）内に再接続できればロックを回復できます。このため、短時間の瞬断に対してすぐ切り戻しを実施するのではなく、まずサーバー側の状態復旧を試みるほうが整合性の観点からは安全です。

2026年の現行環境差分と運用上の注意点

2026年時点での主要ディストリビューションにおける挙動差分をまとめます。

RHEL 9 / AlmaLinux 9 / Rocky Linux 9：デフォルトのNFSクライアントはv4.2をネゴシエーションします。`nfs-utils` 2.6系が同梱されており、`nfsconf`コマンドによるクライアント設定ファイル（`/etc/nfs.conf`）の管理が推奨されています。`/etc/nfsmount.conf`はRHEL 9以降では非推奨とされているため、古いドキュメントを参照する際は注意が必要です。

Ubuntu 24.04 LTS：`nfs-common`パッケージで`rpcbind`ではなく`rpcbind.socket`（systemdソケットアクティベーション）を使用します。NFSv4のみ使用する場合はrpcbindを完全に無効化することも可能で、攻撃面の削減に有効です。`/etc/idmapd.conf`のDomain設定は依然として必要で、サーバー・クライアント間で不一致があるとUID/GIDマッピングが`nobody`になる問題が続いています。

Debian 12（Bookworm）：`nfs-utils` 2.6系採用。`/etc/default/nfs-common`でのNFSBASEVERSION指定は廃止傾向にあり、`/etc/nfs.conf`への移行が推奨されています。

コンテナ・Kubernetes環境でNFSを使用する場合は、CSI NFSドライバ（`csi-driver-nfs`）経由のマウントが標準的です。この場合PersistentVolumeのmountOptionsにオプションを記述しますが、カーネルレベルの制約（コンテナのネームスペース分離）により一部オプションが無視されることがあります。とくに`sec=krb5`等のセキュリティオプションはホストカーネルのKerberos設定に依存するため、コンテナ単体では動作しません。

最後に、定期的な設定レビューの重要性を強調しておきます。NFSのマウントオプションは一度設定すると長期間変更されないことが多く、カーネルアップデートやnfs-utilsのバージョンアップで挙動が変わっても気づかれないケースがあります。`nfsstat -m`の出力をモニタリングツールで定期的に取得し、想定外のバージョンネゴシエーションやオプション変更を検出できる体制を整えることが、本番環境における継続的な安定運用の基盤となります。