NFSv3本番環境をNFSv4.1へ無停止移行する並行運用期と切り戻し設計

なぜ今NFSv3からNFSv4.1へ移行するのか

NFSv3は長年にわたり Linux 環境の標準的なネットワークファイル共有プロトコルとして運用されてきました。しかし2026年現在、多くのディストリビューションのデフォルト設定がNFSv4系へと移行し、一部のクラウドネイティブなストレージサービスはNFSv3の新規サポートを打ち切り始めています。

NFSv4.1の主な利点は、ステートフルなプロトコル設計によるロック管理の改善、セッション単位のフェイルオーバー（pNFS連携時のマルチパス対応）、そしてKerberos統合の簡素化です。一方でNFSv3はUDP/TCPの選択の自由度や、古い実装との互換性という点でまだ根強く使われています。

本番サービスを止めずに移行するには、「いきなりv4.1に切り替える」のではなく、v3とv4.1を並走させる期間を設けながら段階的に移行する設計が不可欠です。本記事ではその全体像を整理します。

移行前アセスメント：見落としがちな確認項目

移行を始める前に、現在の環境が「NFSv4.1で動作可能か」を確認しておく必要があります。実際の現場では手順を先走った結果、IDマッピングの不整合でファイルオーナーが全て nobody になるトラブルが報告されています。

カーネルとパッケージの確認
NFSv4.1のセッション機能（backchannel）はカーネル3.9以降で安定していますが、RHEL 8系では一部のオプション挙動が9系と異なります。まず uname -r でカーネルバージョンを確認し、nfs-utilsが1.3以降であることを確かめてください。RHEL 9/Ubuntu 24.04であれば標準パッケージで問題ありません。

IDマッピングデーモンの状態確認
NFSv4ではユーザー名とUID/GIDの変換に rpc.idmapd が関与します。サーバー・クライアント双方で /etc/idmapd.conf の Domain 設定が一致していないと、ファイルオーナーが nobody にマッピングされます。systemctl status nfs-idmapd で起動状態を確認し、Domain 値をドメイン名またはカスタム文字列で統一しておきます。

ファイアウォール・ポートの整理
NFSv3ではportmapper（111番）・mountd・statdなど複数の動的ポートが必要でした。NFSv4以降はTCP 2049番のみで通信が完結するため、ファイアウォールルールをシンプルに整理できます。ただし移行期は両方のルールセットを並立させる必要があります。

クライアント棚卸し
/proc/fs/nfsd/clients/（サーバー側）や nfsstat -m（クライアント側）で現在接続中のバージョンを把握します。古い組み込みデバイスや NetApp/EMC 側のクライアントがNFSv4非対応の場合、それらを別エクスポートで維持するか移行対象から除外する判断が必要です。

並行運用期の設計：v3とv4.1を共存させる

無停止移行の核心は「並行運用期」の設計です。サーバー側は同一エクスポートをv3・v4.1の両方で提供し続けながら、クライアントを少数ずつv4.1に切り替えていきます。

サーバー側のエクスポート設定
/etc/exports にバージョン制限の記述がある場合は取り除くか、fsid=0 を適切に設定してNFSv4のルートエクスポートを定義します。典型的な設定例は以下の構成になります（fsid=0 でv4ルートを宣言し、サブエクスポートを nohide でバインドする）。並行期は vers=3 を禁止する設定を入れないことが重要です。nfsd はクライアントのネゴシエーションに応じて自動的にバージョンを選択するため、サーバー設定を変えずともv3クライアントは引き続き接続できます。

クライアント側のマウントオプション変更
v4.1に切り替えるクライアントでは、/etc/fstab のマウントオプションに vers=4.1（または nfsvers=4.1）を明示します。proto=tcp も合わせて記載しておくと、UDPフォールバックによる予期しない動作を防げます。まず非本番系（ステージング・バッチサーバー）から切り替え、数日間の観察期間を置いてから本番クライアントに順次適用するのが安全な進め方です。

並行期の監視ポイント
サーバー側で nfsstat -s を定期的に確認し、v3とv4系それぞれのリクエスト数の推移を追います。v4系のカウンタが増え、v3系が減っていけば移行が進んでいる証左です。またクライアント側では mount | grep nfs でマウントされているバージョンを随時確認します。

マウント切り替えと本番適用手順

クライアント単位での切り替えは、ローリング方式で進めます。一気に全クライアントを切り替えると問題発生時の影響範囲が広がるため、役割やサービス重要度に応じてグルーピングし、グループ単位で適用します。

手順の流れ

• 対象クライアントへのアクセスが少ない時間帯（業務時間外が望ましい）を選ぶ
• umount でいったんアンマウントし、fstab のオプションを vers=4.1,proto=tcp に書き換える
• mount -a または mount /mountpoint で再マウントし、nfsstat -m でv4.1接続を確認する
• アプリケーション動作・ファイルオーナー・パーミッションを確認し、問題がなければ次のグループへ進む

Ansible や Salt などの構成管理ツールを使っている環境では、fstab テンプレートのバージョンパラメータを変数化しておき、グループごとに変数を切り替えて適用すると作業効率と再現性が向上します。

systemd の .mount ユニットを使っている場合は Options= 行に vers=4.1,proto=tcp を追加し、systemctl daemon-reload の後に systemctl restart マウントユニット名.mount を実行します。systemctl status でActive状態とマウントオプションを確認してください。

切り戻し設計：v3への復帰手順と注意点

移行後に問題が発生したとき、迅速にv3へ戻せる設計を事前に用意しておくことが安定した移行の条件です。「切り戻す可能性がある」と最初から織り込んでおくことで、運用担当者の心理的負担も下がります。

サーバー側の切り戻し
NFSv4.1からv3に戻す場合、サーバー側の設定変更はほぼ不要です。エクスポート設定を変えていなければ、クライアントのマウントオプションを vers=3 に戻すだけで接続できます。サーバー側でv4を明示的に無効にしていた場合（RPCNFSDARGS="--no-nfs-version 4" など）は、この設定を削除してnfsdを再起動します。

クライアント側の切り戻し
fstab に vers=3 を記載して再マウントするだけです。Ansibleを使っている場合はグループ変数を差し戻せばよいため、数分以内に全クライアントを戻せます。切り戻し後も nfsstat -m でv3接続であることを必ず確認してください。

ファイルロックの取り扱い
NFSv4系ではロックがステートフルに管理されるため、切り戻し直後にv3のロックマネージャー（lockd）との整合性が取れず、一部ファイルが短時間ロック状態に見えることがあります。アプリケーション側でリトライ処理が実装されていれば自然に解消しますが、業務クリティカルな処理が走っている最中の切り戻しは避けるのが無難です。

並行期をいつまで続けるか
全クライアントの移行が完了し、2〜4週間の安定稼働を確認したのちにv3サポートをサーバー側で無効化します。この期間を短縮したくなる場面もありますが、月次バッチやバックアップジョブなど低頻度の処理がv3を前提にしていることがあるため、1ヶ月程度の観察期間を取ることが推奨されます。

2026年の現行環境における差分と注意点

2026年時点の主要ディストリビューションではNFSv4.1/4.2対応がデフォルト化しており、以前は手動設定が必要だった部分が自動化・簡素化されています。

RHEL 9系・Rocky Linux 9系
nfs-server.service の起動時にNFSv4.1がデフォルトで有効化されます。/etc/nfs.conf（旧来の /etc/sysconfig/nfs の後継）でバージョンごとの有効/無効を細かく制御できます。vers4.1=y と vers3=y を並記することで並行運用が可能です。また nfsconf コマンドで設定を確認・変更できるようになり、直接ファイル編集よりも安全に設定を管理できます。

Ubuntu 24.04 LTS
nfs-kernel-server パッケージが NFSv4 をデフォルト有効で提供します。/etc/default/nfs-kernel-server ではなく /etc/nfs.conf での設定が推奨されています（RHEL系と同じフォーマット）。rpc.idmapd は nfs-idmapd.service として systemd に統合済みです。

pNFS（並列NFS）との関係
NFSv4.1ではpNFS拡張によりデータアクセスをストレージサーバーに直接分散させるアーキテクチャが利用可能になります。ただしpNFS対応にはサーバー側ストレージのレイアウトドライバー対応が必要であり、汎用Linuxサーバー上の通常のnfsdでは現時点ではファイルレイアウト（file layout）の限定サポートにとどまります。移行直後の段階でpNFS活用を目標にするのは現実的ではなく、まずv4.1への移行完了を優先することが推奨されます。

Kerberos認証の統合
NFSv4.1ではGSS-API（sec=krb5）による認証がv3より自然に統合されています。現在NFSv3をIPアドレスベースのアクセス制御のみで運用している環境が多いですが、v4.1移行を機にKerberos統合を検討することで、ゼロトラスト的な認証基盤に近づけることができます。ただしKerberos設定はそれ自体が大きなプロジェクトになるため、移行フェーズとは切り分けて別途計画することが現実的です。

NFSv3からv4.1への移行は、丁寧なアセスメントと並行運用期の設計があれば、多くの環境でサービス停止なく実施できます。切り戻し手順を先に整備しておくことが、移行判断を迷わず進める上での土台になります。