UnixのNFSサーバー障害：ネットワークファイルシステム復旧

【注意】 NFS障害の切り分け・復旧は、障害原因（ネットワーク／名前解決／認証／ストレージ／カーネル／設定差分）で最適手順が変わります。誤った再起動や強制アンマウントで状況が悪化することもあるため、重要データや業務影響がある場合は、株式会社情報工学研究所のような専門事業者に相談のうえ進めてください。

　

第1章: 「mount が返らない」夜――NFSは静かに止まる

NFS障害は、派手に落ちるより「静かに詰まる」形で始まります。mount が戻らない、ls が固まる、アプリのスレッドが待ち続ける――ログは少ないのに、現場の体感は最悪。SREや情シスが一番しんどいタイプです。

「ネットワーク？ いや、ping は通る。DNS？ たぶん…」「でも本番は止められない。役員には“何分で復旧？”って聞かれる」――こういうとき大事なのは、原因当てクイズを始めないことです。最初の目的は“完璧な根本原因”ではなく、被害最小化とダメージコントロールです。

「固まる」の正体：NFSは“待つ”設計になりやすい

NFSクライアントは、サーバー応答が遅い／途切れると、処理を再送しながら待機します。設定によっては、I/Oが永遠に待つ形になり、ユーザープロセスがD状態（uninterruptible sleep）に入ります。見た目は「CPUもメモリも余裕なのに、アプリだけ止まっている」になります。

この瞬間、現場は焦って「再起動」「強制umount」「サーバー再起動」をやりがちですが、順番を間違えると、ロックや書き込み整合性の問題が表面化し、復旧を遅らせます。まずは“場を整える”――つまり、状況を可視化し、どこで待っているかを分離します。

最初の5分でやること：症状を“分類”してノイズカットする

いきなり深掘りせず、現象を次のように分類します。分類できると、以降の調査がノイズカットされます。

• クライアント全体が固い（複数マウント・複数ホストで同時）
• 特定のNFSマウントだけ固い（別マウントやローカルI/Oは正常）
• 特定ディレクトリ配下だけ固い（特定exportや特定ボリューム疑い）
• 読み取りはできるが書き込みが詰まる／または逆

判断を誤りやすいポイント：pingが通っても“生きてる”とは限らない

NFSはRPC（NFSv3）や特定ポート（NFSv4）で動くため、ICMPが通っても「NFS応答がある」とは限りません。さらに、サーバーがI/O待ちで詰まっている場合、ネットワークは正常でもNFSスレッドが捌けず、結果としてクライアントが待ち続けます。

---

この章の結論はシンプルです。最初にやるのは“復旧の魔法の呪文”ではなく、症状の分類と待ちの位置（クライアント／サーバー／ストレージ）を切り分ける準備です。一般論だけで判断が難しいケース（業務停止・重要データ・書き込み整合性が関わる場合）は、早い段階で株式会社情報工学研究所のような専門家へ相談するのが、結果的に収束を早めます。

　

第2章: まず疑うべきはネットワークではなく「名前解決」と「時刻」

「NFSが遅い＝ネットワーク障害」と直結しがちですが、現場で多い“ハマりどころ”は、名前解決（DNS/hosts）と時刻（NTP）です。ここがズレると、NFS自体が壊れていなくても、周辺要素の不整合で“動いていないように見える”状態になります。

名前解決：サーバーは同じでも“別物”に見える瞬間がある

たとえば、NFSサーバーをFQDNでマウントしている環境で、DNSがフェイルオーバーや変更の途中だと、クライアントが想定外のIPへ向かうことがあります。さらに、/etc/hosts の残骸、社内DNSのキャッシュ、コンテナのDNS設定差分が重なると、「あるノードだけ繋がる」「あるノードだけ固まる」が起きます。

ここでのポイントは、“そのホストが実際に見ている解決結果”を確認することです。頭の中のDNS設計ではなく、現物の結果を見ます。

時刻：Kerberos/NFSv4（sec=krb5系）を使うなら致命傷になりうる

NFSv4でKerberos（sec=krb5/krb5i/krb5p）を使っている場合、時刻のズレは認証に直撃します。認証失敗は「繋がらない」「操作が戻らない」へ繋がりやすく、しかも現場からは“なんかNFSが死んだ”に見えます。ここで闇雲に再起動を繰り返すと、原因が見えにくくなります。

最短で確かめるチェックリスト（最初に当てるべき伏線）

次の表は、NFSが不調に見えるときの「まず当てるべきチェック」です。どれも数分で確認でき、後工程の無駄を減らします。

観点	確認	よくある結果	意味
名前解決	getent hosts / dig / nslookup	ホストごとにIPが違う	同名でも別サーバーへ行っている可能性
逆引き	getent hosts <IP>	逆引きが遅い／失敗	ログ・認証周りで遅延や拒否の誘因
時刻同期	chronyc tracking / timedatectl	数分以上ズレ	Kerberos利用時は認証失敗の原因になりうる
経路	traceroute / mtr	一部経路でロス・遅延	RPC再送増で“固まり”が発生しやすい

---

この章の要点は、障害対応の初動は“盲目的にネットワークを疑う”ではなく、前提条件（名前解決・時刻）を固めることです。ここが崩れていると、以降の調査が全部ブレます。個別環境では、DNS冗長化方式や認証方式、境界FWの設定が絡み、一般論のままでは判断が難しいことがあります。影響が大きい場合は、早めに株式会社情報工学研究所のような専門家と一緒に“収束”へ向けて設計的に整理するのが安全です。

　

第3章: 症状をログに落とす：クライアント側（dmesg/syslog/nfsiostat）

NFS障害で一番つらいのは、「現場の体感は重いのに、証拠が薄い」ことです。そこでやるべきは、感覚を捨てて、症状をログ・統計に固定すること。ここが後半の“帰結”への伏線になります。なぜなら、NFSはクライアント側に待ち・再送・タイムアウトの痕跡が残るからです。

カーネルログ：まず見るべきメッセージは決まっている

Linuxなら dmesg / journalctl、他Unix系でも同等のカーネルメッセージを確認します。典型例は次のようなものです。

• server not responding, still trying（応答なし、再試行継続）
• server OK（応答復帰）
• stale file handle（ハンドル不整合、exportやFS再構成の影響が疑われる）
• permission denied / access denied（exportsや認証方式、IDマッピングの問題の可能性）

これらが出ているなら、「アプリが遅い」ではなく「NFSが待たされている」ことが確定し、原因候補を絞れます。

統計：nfsstat / nfsiostat で“詰まり方”を数値化する

次に、NFSクライアント統計で再送や遅延の兆候を見ます。ディストリビューションによりコマンドは異なりますが、一般に次の観点が有効です。

• RPC再送が急増していないか（ネットワークロスやサーバー遅延の示唆）
• read/writeの平均応答時間が跳ねていないか（サーバー側I/O待ちやスレッド枯渇の示唆）
• 特定マウントだけ悪化していないか（特定export/特定ボリュームの示唆）

「再送が多い」のか「応答自体が遅い」のかで、次に見るべき場所が変わります。ここで初めて“次の一手”が技術的に決まります。

プロセス観点：D状態が増えていないか（アプリ停止の見え方を整理する）

現場の独り言としてよくあるのがこれです。「CPUも空いてるのに、なんでAPIが返らないんだよ…」。NFS待ちでD状態が増えると、アプリは応答しません。ここでアプリだけ疑っても、議論が過熱するだけで、空気を落ち着かせる材料になりません。

“待ちの正体”を示すには、次のような観点が役立ちます。

• アプリのスレッドがファイルI/O待ちで滞留している（ログやスタックに表れる）
• 同ホストのローカルI/Oは正常だが、NFSパスだけ詰まる
• 複数アプリが同時に遅い（共通基盤：NFSの可能性が上がる）

最小限のコマンド例（“やりすぎない”のがコツ）

障害対応は、採取が過剰になると本質が見えません。まずは「軽く、確実に」取ります。

（例）カーネルログ dmesg -T | tail journalctl -k -n 200
（例）NFS統計
nfsstat -c
nfsiostat 1 5

（例）DNS/時刻（前章の確認を再掲）
getent hosts nfs-server.example
timedatectl

---

この章の結論は、“NFSが遅い”を、ログと統計で言い切れる状態にすることです。ここまでできると、次章以降で「サーバー側（rpcbind/nfsd/exports）なのか」「ロック・ハンドルなのか」「ストレージI/O待ちなのか」を論理的に詰められます。とはいえ、現実の環境は設定差分や複合障害が起きます。影響が大きい場合は、一般論で押し切らず、株式会社情報工学研究所のような専門家に相談して、最短で収束へ向かう段取りを組むのが安全です。

/

　

第4章: サーバー側の心拍を読む：rpcbind・nfsd・exports・スレッド枯渇

クライアント側で「待っている」証拠が取れたら、次はサーバー側です。ここで重要なのは、サーバーを“動いている/動いていない”の二択で見ないこと。NFSサーバーは、プロセスが存在していても、捌けていない・詰まっている・特定exportだけ破綻という中間状態が起こります。現場が求めているのは、論争の材料ではなく、復旧へ向けたダメージコントロールの判断材料です。

まずは「NFSの入口」が生きているか：rpcbind（NFSv3系）とNFSv4

NFSv3はRPCの仕組み（portmapper/rpcbind）を使ってサービスのポートを解決します。NFSv4は仕組みが違い、v3ほどrpcbind依存ではない構成もありますが、現場では混在が珍しくありません。いずれにせよ「入口が生きているか」を最初に見ておくと、以降の調査がノイズカットされます。

• NFSv3中心：rpcbindが死ぬと、クライアントはポート解決できず、mountやI/Oが詰まりやすい
• NFSv4中心：NFS本体が応答しても、idmapや認証・ACL周りで見え方が崩れることがある

exports：設定ミスは「一部だけ固い」「特定クライアントだけ拒否」で現れる

/etc/exports（あるいは管理ツール）で公開しているexportは、NFSの“仕様”そのものです。ここで起きやすいのは、運用変更の途中での不整合です。

• クライアントのIPレンジ変更・NAT変更で、意図せず拒否される
• exportのパスがストレージマウントに依存していて、背後のFSが未マウントになっている
• read-only / root_squash などの期待差で、書き込みだけ詰まる／失敗する

ここでの危険は、原因がexportsでも、現象が「NFSサーバー障害」に見えることです。だからこそ、サーバー側でexportの状態（“公開されているはずのものが本当に公開されているか”）を確認し、議論の温度を下げます。

スレッド枯渇：プロセスは生きているのに“捌けない”という障害

現場が一番苦しむパターンはこれです。「nfsdは動いてる。ログも少ない。でも遅い」。このとき、NFSサーバーのワーカースレッドや関連スレッドが枯渇している、もしくはI/O待ちで停滞している可能性があります。

典型的には、次の要因が重なります。

• バックエンドストレージが遅くなり、nfsdがI/O待ちで詰まる
• 大量のクライアントが同時にアクセスし、処理待ちが増える
• ロックやメタデータ操作が集中し、待ちの連鎖が起こる

こうなると、サーバーのロード平均（load average）は上がるのに、CPU使用率は高くないこともあります。数字だけ見ると「余裕がある」に見えるため、説明が難しくなり、議論が過熱しがちです。ここで“場を整える”ために、I/O待ちと処理待ちのキューの有無を確認します。

最小限の確認項目：まずは“死活”ではなく“応答品質”を測る

障害対応では、チェック項目を増やしすぎると混乱します。最初は「応答品質」を絞って取ります。

見る場所	観点	示唆
nfsd/rpc	応答が返るか、遅延が増えていないか	入口が詰まっている／内部処理が停滞
exports	公開設定と実体（背後FS）の整合	特定exportだけ破綻、拒否、見え方の差
OS全体	I/O待ち、ファイルシステムエラー兆候	ストレージ起因でNFSが巻き込まれる

---

この章のまとめは、NFSサーバーを“生死”で見ずに、入口（rpcbind/NFS）・公開設定（exports）・捌き能力（スレッド/待ち）で観察することです。ここまで整理できると、次章の「ロックとハンドル不整合」へ自然に繋がります。個別環境ではNFSv3/v4混在、認証方式、ネットワーク境界、ストレージ構成が絡みます。業務影響が大きい場合は、一般論で判断せず、株式会社情報工学研究所のような専門家と一緒に“収束”へ向けて手順を設計するのが安全です。

　

第5章: ロック地獄の入口：lockd/statd と “stale file handle” の正体

NFS障害の切り分けが難しくなる瞬間があります。それが、ファイルロックとファイルハンドルの問題が絡んだときです。ここは、原因が単純でも現象が複雑になりやすく、対応の順番を誤ると復旧が長引きます。だからこそ、焦りをクールダウンして、仕組みとして理解します。

ファイルロック：アプリは“正しい”のに詰まる

多くのアプリは排他制御のためにロックを使います。NFS環境では、このロックがネットワーク越しに成立する必要があり、lockd/statd（NFSv3系で典型）が関わることがあります。ここで起きるのは、アプリ側が悪いわけではなく、ロックの状態が不整合になり、結果として処理が待ち続けることです。

現場の心の会話としてはこうです。「DBじゃないのに、なんでこんなに待つの？」「ロックなんて数ミリ秒で終わるはずでは？」――でも、NFS越しのロックは“分散ロック”に近い性質を持ちます。ネットワーク断やサーバー再起動を挟むと、整合性の前提が崩れます。

stale file handle：ファイルはあるのに“掴めない”

“stale file handle” は、NFSを触る人が一度は遭遇する典型的なメッセージです。直感的には「ファイルが古い？」に見えますが、実態はNFSが参照している識別子（ハンドル）と、サーバー側の実体が一致しない状態です。

このズレが起こりうる代表例は次の通りです。

• exportしている背後のファイルシステムを作り直した／入れ替えた
• スナップショットやリストアでメタデータが変わった
• クラスタ化／フェイルオーバーで見えている実体が切り替わった

つまり、現象としては「そのファイルは存在するのに、NFS越しに触れない」「ディレクトリ一覧は取れるのに、特定ファイルだけ失敗する」などになります。ここで闇雲に再マウントを繰り返すと、別の待ち（ロックやI/O待ち）が混ざり、原因が見えにくくなります。

復旧判断の落とし穴：強制アンマウントが“万能”ではない

強制umount（いわゆる強引な切り離し）は、短期的には症状の抑え込みになることがあります。しかし、プロセスがD状態で待っている場合、期待どおりに剥がれないことがありますし、剥がれたとしてもアプリ側の整合性や再試行が別の形で噴出します。

ここで大切なのは、「何を守るか」です。業務データ、書き込み中のトランザクション、アプリの状態、そして障害調査の証拠。これらを守るには、一般論の手順よりも、システム構成に即した順番が必要になります。

ロック・ハンドル問題を“見える化”する観点

この章では、細かいコマンド列挙より、判断のための観点に絞ります。

• 詰まっているのは「読み」か「書き」か（ロックや権限の影響が変わる）
• 全体か、特定パスか（staleは局所に出やすい）
• 直前に構成変更（FS入れ替え、フェイルオーバー、リストア）がなかったか
• ロックを使うアプリが集中していないか（キューが伸びる）

---

この章の結論は、NFSの復旧は“サービス再起動”だけでは終わらず、ロックとハンドルの整合性が復旧時間を支配することがある、という点です。一般論のまま強制操作を繰り返すと、状況が複雑化して収束が遅れます。重要データが絡む、変更履歴が曖昧、フェイルオーバーやリストアが関係する――こうしたケースでは、株式会社情報工学研究所のような専門家に相談して、被害最小化の手順を設計することを強く推奨します。

　

第6章: ストレージ起因の遅延：I/O待ちがNFS全体を巻き込むメカニズム

NFS障害の根本原因として、ネットワークより多いことがあるのがストレージ起因です。クライアントから見ると「NFSが遅い」ですが、サーバーの中では「ストレージI/Oが遅い」。NFSはその遅さを隠してくれません。結果として、全体がじわじわ固まります。

NFSは“ストレージの遅さ”を増幅しやすい

サーバー側ストレージが遅いと、NFSサーバーは要求を捌くために待ちます。待つ間にスレッドが占有され、同時要求が増えるとキューが積み上がります。さらに、クライアント側はタイムアウトや再送を行い、要求数が増えて状況を悪化させることがあります。これは設計上起こり得る“負のループ”です。

どんなストレージ問題がNFSに波及するか

事実として起きやすいのは、次のようなカテゴリです（脚色ではなく、典型的な現場要因の分類です）。

• ディスク障害の前兆によるリトライ増（I/Oがたまに遅い、が最悪）
• RAID再構築・リビルド・整合性チェックでの性能低下
• NAS/SAN側の輻輳、キャッシュミス、コントローラ負荷
• スナップショット・バックアップジョブによるメタデータ負荷
• ファイル数爆発によるメタデータ操作の遅延（lsが遅い等）

「ディスクが完全に死んだ」なら原因が明確ですが、厄介なのは“少しずつ遅い”“たまに遅い”です。このときNFSは、見た目として“静かに止まる”状態になります（第1章の書き出しに戻る伏線回収です）。

説明が難しいポイント：CPUが暇でも、I/O待ちは待つ

I/O待ちが支配している場合、CPU使用率は高くありません。グラフだけ見る上司や非技術者には「余裕があるのに何をしている？」に見えます。ここで必要なのは、ストレージ待ちが処理全体をブロックするという“翻訳”です。

現場向けには、「NFSは“リモートのディスク”なので、ディスクが遅ければ全部遅い。しかも待ちが連鎖すると、要求が増えてさらに遅くなる」と整理すると、議論の温度を下げやすいです。

切り分けの観点：NFSの問題か、背後ストレージか

ここでは「次に見るべき方向」を決めるための観点を表にします。

観測	起点の疑い	次の一手
RPC再送が増える	ネットワークロス／サーバー応答遅延	経路・ロス・サーバー負荷/I/O待ちを同時確認
read/write応答時間が跳ねる	サーバー側I/O待ち	ストレージ指標、FSエラー兆候、バックアップジョブ確認
特定exportだけ遅い	特定ボリューム／特定ディレクトリ負荷	該当ボリュームのI/Oとメタデータ操作を重点確認

---

この章の結論は、NFS障害は“ネットワークの話”で終わらず、背後のストレージが原因で被害最小化が難しくなるケースが多い、ということです。ここから先は、復旧手順（順番）と再発防止（設計）が重要になります。個別のRAID/NAS/SAN構成、バックアップ運用、ジョブスケジュール、監視の粒度で最適解が変わるため、一般論だけで判断すると遠回りになります。深刻な業務影響がある場合は、株式会社情報工学研究所のような専門家に相談して、最短で収束させる道筋を一緒に組むのが現実的です。

　

第7章: 事故対応の鉄則：データ保全を崩さない安全な復旧手順（順番が命）

ここからが本番です。NFS障害の対応で一番やってはいけないのは、「とにかく動かす」ために順番を崩すことです。NFSは“クライアントとサーバーとストレージ”の三者で状態を持ちます。順番を誤ると、いったんは動いても、あとからロック不整合・再送の嵐・データの見え方の揺れが噴き出し、結果的に収束が遅れます。

現場の独り言はたぶんこうです。「とにかく夜勤を終わらせたい」「再起動したら直るんじゃ…」。その気持ちは自然です。ただ、重要データが絡むときは、焦って操作を増やすほど、復旧までの距離が伸びます。ここでは、一般的に安全性が高い“型”を示します（環境差分で最適手順は変わるため、判断が難しい場合は株式会社情報工学研究所のような専門家に相談してください）。

0) まず“被害最小化”を定義する（復旧前にブレない軸を作る）

障害対応が迷走する原因は、「何を守るか」が曖昧なまま操作が始まることです。最初に次を短く決めます。

• 守る対象：データ整合性（最優先）／サービス復旧時間／調査証拠
• 許容できること：一部機能停止／読み取り専用での暫定運用／段階復旧
• 禁止：無根拠な強制操作の連発（強制アンマウント、乱暴な再起動など）

この“軸”があるだけで、議論が過熱しにくくなり、場を整えられます。

1) 影響範囲を確定する（クライアント横断の共通点を拾う）

次に、影響が「全クライアント」か「一部クライアント」か、「全export」か「特定export」かを確定します。ここは第1〜6章の伏線回収で、クライアント側ログ・再送・応答時間の情報が効きます。

• 全体に遅い：サーバー側（nfsd/スレッド/I/O待ち）やネットワーク基盤の疑いが強い
• 特定exportだけ：背後ストレージや特定ディレクトリ負荷、exports設定差分の疑い
• 特定クライアントだけ：DNS/時刻/経路/MTU/クライアント設定差分の疑い

2) “追加の被害”を止める：書き込みを抑え込み、状況を固定する

データ保全が必要な状況では、「書き込みが続いている状態」のまま闇雲に操作すると、問題が増幅します。安全側の選択肢として、段階的に書き込みを抑え込みます。

• アプリ側で書き込み系処理を一時停止（ジョブ停止、キュー停止、メンテモードなど）
• 影響が大きい場合は、対象exportを一時的に読み取り中心に寄せる（運用で制御）
• “直すための再起動”より前に、まず流量を落としてクールダウンする

ここで大事なのは、「いま書き込みが正しく完了しているか」を曖昧にしたままサーバーを揺らさないことです。

---

3) 復旧の順番：最小操作で“段階復旧”する

復旧は、いきなり全面復旧を狙わず、段階的に戻します。一般に安全側になりやすい順序は次の通りです（ただし、構成により例外があるため注意）。

段階	狙い	理由
① 観測の固定	ログ/統計で詰まりを確認	原因当てではなく“現象”を確定し、ノイズカットする
② 負荷の低減	書き込み・大量ジョブを止める	再送やロック待ちの連鎖を減らし、収束を早める
③ サーバー側の詰まり解消	nfsd/関連サービスの状態確認と是正	入口が捌けない状態では何をしても改善しない
④ 背後ストレージの健全化	I/O待ち・エラー兆候の是正	NFSはストレージの遅さを隠せないため、根の改善が必要
⑤ 小さく再開	限定範囲で再開し観測	全面再開は再燃しやすい。段階復旧で歯止めを利かせる

4) “強制操作”を使うなら、目的と副作用を言語化してから

強制アンマウントや強制再起動が必要になる場面はあります。ただし、必要なのは“強い操作”ではなく、“強い操作の前提”です。

• 目的：何を解消したいのか（ロック待ちか、応答停止か、特定exportか）
• 副作用：書き込み中断、ロック不整合、アプリ側リトライ嵐、復旧後の整合性確認コスト
• 代替：負荷低減・限定復旧・読み取り優先での暫定運用が可能か

ここを言葉にできるだけで、現場の空気を落ち着かせ、作業が“炎上/クレーム対応”モードに落ちにくくなります。

---

この章のまとめは、「復旧手順はテクニックではなく順番」であり、順番はデータ保全と被害最小化のために存在する、ということです。一般論だけで判断しにくいのは、NFSがネットワーク・OS・ストレージ・認証・運用変更の影響を同時に受けるからです。業務影響や重要データが絡む場合は、早い段階で株式会社情報工学研究所のような専門家に相談し、最短で収束させる段取りを組むのが現実的です。

　

第8章: 復旧を早める設計：マウントオプション、タイムアウト、再送、分離

ここからは「次の障害で楽になる」話です。NFSは“うまく動いている間”は存在感が薄い一方、壊れ方は業務を巻き込みます。だから復旧を速くするには、障害が起きた瞬間にダメージコントロールできるよう、設計で“逃げ道”を作っておく必要があります。

ただし注意点があります。マウントオプションは、性能を上げる魔法ではなく、失敗モードをどう扱うかの設計です。良かれと思って変えた設定が、データ整合性やアプリ挙動を壊すこともあります。個別案件では、システム構成・運用・アプリ特性に合わせて設計すべきで、迷う場合は株式会社情報工学研究所のような専門家に相談してください。

hard/soft：まず“データ整合性”の優先順位を決める

一般に、NFSクライアントの挙動は「サーバーが応答しないときにどうするか」で分かれます。

• hard：応答が返るまで待ち続ける（アプリは固まって見えるが、勝手に失敗しにくい）
• soft：一定回数で失敗を返す（アプリ側でエラー処理できるが、扱いを誤ると整合性リスクが増える）

どちらが正しいかは一概に言えません。重要なのは「あなたのアプリはI/O失敗を正しく扱えるか」です。扱えないのにsoft寄りにすると、静かに不整合が増えることがあります。一方、hard寄りだと障害時に固まりやすいので、運用側で“止め方”や“逃がし方”を設計しておく必要があります。

timeo/retrans：待ち方を“制御可能”にしておく

NFSは再送・タイムアウトで粘ります。ここを何も決めていないと、障害時に「どこまで待つのか」「いつ諦めるのか」が環境任せになり、復旧手順が組みにくくなります。そこで、次を“設計として決める”のがポイントです。

• 短時間で復旧する障害（瞬断）を許容するのか
• 一定時間でエラーにして上位で切り替えるのか
• 監視（アラート）をどのタイミングで上げるのか

これは、技術というよりSLO/運用設計です。「待つ設計」にするなら、監視とエスカレーションで“場を整える”仕組みが必要になります。

分離：NFSを“全部同じ扱い”にしない（障害ドメインを切る）

復旧を早める最大のコツは、NFSを一枚岩にしないことです。障害は必ずどこかで起きるので、起きたときに巻き込まれる範囲を小さくします。

• 用途別にexportを分ける（ログ／共有設定／ユーザーデータを分離）
• 重い処理（大量ファイル、メタデータ多発）と、レイテンシ敏感な処理を分離
• 可能なら、ストレージボリュームやネットワーク経路も分離し、同時障害を避ける

こうしておくと、障害時に「止めるべきもの」と「生かすべきもの」を切り分けやすくなり、被害最小化が現実的になります。

---

属性キャッシュ・メタデータ：lsが遅い、が障害の前兆になる

NFSは、データ本体だけでなくメタデータ（属性取得、ディレクトリ走査）でも負荷が出ます。ファイル数が増えると、たとえデータI/Oが軽くても、属性取得の遅延で“体感が重い”状態になります。ここは、障害の前兆として観測できることがあります。

• 特定ディレクトリだけ遅い（ファイル数・小さいファイルの密度が高い）
• バックアップやスキャンが走る時間帯だけ遅い（メタデータ負荷）
• 監視上は正常でも、体感が先に悪化する（現場の声がシグナルになる）

この段階で対策（分離、ジョブ時間調整、構成見直し）を入れると、次の本格障害をブレーキできます。

“正しさ”より“運用可能性”：現場が回せる設計に落とす

NFSの設計は、理論上の最適だけでは回りません。現場の本音はこうです。「また新しいルール？ どうせ運用が増えるだけじゃないの？」。その疑いは健全です。だから、設計のゴールは“複雑さの増加”ではなく、障害時に迷わないための“手すり”を作ることです。

• 障害時の判断フローを短くする（どのメトリクスを見て、どの順に止めるか）
• 変更点を少なくする（闇雲なオプション増は避ける）
• 説明可能にする（上司・顧客へ、なぜ待つ／なぜ止めるを説明できる）

---

この章のまとめは、NFSの復旧を速くするのは“障害後の頑張り”ではなく、障害時の失敗モードを前提にした設計だということです。マウントオプションや分離は、一般論だけで最適解を出しにくく、個別のアプリ特性・業務要件・ストレージ構成で結論が変わります。迷ったときは、一般論の限界を認め、株式会社情報工学研究所のような専門家に相談して、あなたの案件に合う“収束しやすい設計”へ落とし込むのが安全です。

　

第9章: 再発防止を仕様にする：監視指標・SLO・定期リハーサル（復旧訓練）

NFSの障害対応は、復旧した瞬間に「もう二度と起きないでくれ」と祈って終わりがちです。でも現実は逆で、NFSは“便利な共有”であるほど依存が増え、いずれまた同じ種類の問題が起こります。だから再発防止は反省文ではなく、仕様として組み込みます。言い換えると、次の障害を早く沈静化させるための仕組み作りです。

監視のゴールは「原因特定」ではなく「収束の判断」を速くすること

監視というと、CPU/メモリ/ディスク使用率を並べがちですが、NFS障害の本質は「待ち」と「再送」と「局所的な遅延」です。だから、復旧判断に効くのは次のような指標です。

• クライアント側：RPC再送の増加、NFS I/Oレイテンシの跳ね（read/write/metadata）
• サーバー側：nfsdの捌き状況（待ちの兆候）、I/O待ち時間、FSエラー兆候
• ストレージ側：平均/最大レイテンシ、キュー深さ、リトライ/エラー率、リビルド等の状態

ここで大事なのは、これらを“高精度に測る”よりも、“事故対応の順番を決められる程度に見える化”することです。完璧を目指して計測を増やしすぎると、運用が増えて現場が回りません。

SLO（期待値）を決めないと、障害時の議論が過熱する

現場が一番困るのは、障害が起きた瞬間に「どれくらい遅いと異常なの？」が合意できないことです。だから、SLOは技術というより社内調整の道具です。たとえば、次のような形で“期待値”を決めます。

項目	例（あくまで例）	狙い
通常時のI/O遅延	平均は○ms台、ピークは○○ms以内	「どこから異常か」を共有する
一時的な遅延の許容	バックアップ時間帯は許容範囲を広げる	誤アラートを減らし、疲弊を防ぐ
復旧目標	読み取り復旧を先に、書き込みは段階復旧	被害最小化の“順番”を仕様化

SLOがあると、障害時に「誰の責任だ」ではなく「今どの段階の復旧を目指すか」に話題を寄せられます。結果として、現場の温度を下げ、収束が速くなります。

復旧訓練（リハーサル）：本番で初めて手順を試さない

NFS障害は、手順の“順番”が命でした（第7章）。順番が命なら、訓練しないのは危険です。ここで言う訓練は、大げさなDR訓練だけではなく、次のような“小さな練習”でも効きます。

• 監視が鳴ったとき、誰がどの指標を見て、何分で判断するか
• 限定範囲で読み取り復旧→書き込み復旧の段階復旧をどう進めるか
• 構成変更（DNS/時刻/exports/ストレージ）時に、どこを確認するか

これを回すと、「本番で迷うこと」が減り、障害時に“ブレーキ”を利かせられます。

---

この章の結論は、再発防止は「気合い」ではなく「仕様化」であり、監視・SLO・訓練は次の障害の被害最小化と収束のためにある、ということです。とはいえ、指標設計はシステム構成・業務要件・ストレージ特性で最適解が変わります。一般論だけで作ると、アラート疲れや運用過多になりがちです。個別案件として設計したい場合は、株式会社情報工学研究所のような専門家に相談し、現場が回る形に落とし込むのが安全です。

　

第10章: 帰結――NFSは「リモートのローカル」ではない：失敗モード前提で強くする

ここまでの話を一本にまとめます。書き出しは「静かに詰まるNFS」でした。伏線は「名前解決・時刻」「クライアント側の待ちと再送」「サーバー側の捌き」「ロックとハンドル」「ストレージI/O待ち」。そして帰結はこれです。NFSは“リモートのローカルディスク”ではない。分散した状態を前提に、失敗モードを織り込んで初めて、運用が強くなります。

なぜNFSは“静かに止まる”のか：待つ・再送する・整合性を守ろうとする

NFSは、ネットワーク越しのI/Oを成立させるために、待ちや再送という仕組みを持ちます。これは「簡単に壊れない」ための設計でもあります。一方で、障害時はその粘りが「固まって見える」状態を生みます。つまり、NFSの“良さ”が、障害時には“つらさ”になります。

だから、障害対応の上手さは、魔法のコマンドではなく、次の3点に集約されます。

• 現象を固定する（ログ・統計で“待っている”を証明する）
• 被害最小化を優先する（書き込み・負荷を落としてクールダウン）
• 順番で復旧する（段階復旧で再燃に歯止めをかける）

一般論の限界：NFSは“環境差分”が大きすぎる

ここで、あえて冷静な話をします。NFSの復旧や設計は、一般論だけで完結しません。理由は明確で、NFSは次の要素が組み合わさって初めて動くからです。

• ネットワーク（経路、ロス、MTU、DNS、境界制御）
• OS/カーネル（NFS実装差、バージョン差、設定差）
• 認証/権限（NFSv3/v4、Kerberos、IDマッピング、ACL）
• ストレージ（RAID/NAS/SAN、性能劣化パターン、バックアップ/スナップショット）
• アプリ（ロックの使い方、I/O失敗時の挙動、再試行の設計）

このどれか1つだけを見て「原因はこれ」と断言すると、だいたい外れます。だから、現場では“切り分け”と“順番”が最重要になります。

読者が次にやるべき「小さな一歩」：設計と運用の穴埋めを始める

本記事を読み終えた今、次の一歩は大きな刷新ではありません。まずは、今日からできる穴埋め（漏れ止め）をします。

1. クライアント側で「再送・遅延」が見える状態を作る（軽い監視でよい）
2. DNS/時刻/exports/ストレージの“変更点”が追える運用にする
3. 復旧の順番（段階復旧）を短い手順に落として共有する

これだけでも、次の障害の収束速度は変わります。

---

最後に、この記事のゴールに正面から触れます。NFS障害対応は、現場の経験と構成理解がモノを言います。一方で、一般論だけでは「あなたのシステムで安全な順番」を保証できません。影響範囲が大きい、重要データがある、構成が複雑、復旧判断に迷う――そういうときは、株式会社情報工学研究所のような専門家に相談し、個別案件として最短で収束させる計画を立てることが、結果的にコストもリスクも下げます。

「また新しいベンダー？ 面倒が増えるだけでは」と感じるのも自然です。ただ、障害時に必要なのは押し売りではなく、“現場の意思決定を支える設計と手順”です。具体的な案件・契約・システム構成で悩んだときこそ、まずは状況整理だけでも、株式会社情報工学研究所への相談を検討してください。

　

付録：現在のプログラム言語各種でNFSを扱うときの注意点（共通の落とし穴）

この付録は、特定の言語が悪いという話ではありません。NFSは“ローカルFSと同じつもりで書く”と、障害時に挙動が変わり、問題が表面化しやすいという事実があります。ここでは、言語ごとに現場で起きがちな注意点を整理します（最終判断は個別システムの要件・構成に依存します）。

共通（全言語）

• エラーは必ず起きる前提：EIO、ETIMEDOUT、ESTALE等を“例外”扱いで握りつぶさない。リトライ方針と上位の失敗設計が必要。
• ロックは過信しない：ファイルロックの語義がローカルFSと違う前提を持つ。障害時のロック不整合を想定する。
• fsync/flushの意味：永続化保証はストレージ/サーバー実装に依存。重要データは「どこまで保証できるか」を設計として明文化する。
• 一時ファイル/テンポラリの置き場所：NFS上にテンポラリを置くと、障害時の遅延が連鎖しやすい。ローカルへ逃がす設計が有効なことが多い。
• 大量の小さいファイル：メタデータ負荷で体感が悪化しやすい。ディレクトリ設計・分割・アーカイブ方式を検討する。

---

C / C++

• 低レベルI/O（open/read/write）で部分書き込みや一時エラーを正しく扱う必要がある。NFS障害時に戻り値とerrnoの扱いを誤るとデータ破損の温床になる。
• fcntl系ロックを使う場合、NFS越しのロック挙動（サーバー再起動、ネットワーク断）を前提に、ロック再取得やフェイルセーフ設計が必要。

Java（JVM系：Java/Kotlin/Scala等）

• java.nio の FileLock は、環境により期待通りに動かないケースがある。ロックが業務の整合性に直結するなら、NFS依存のロックに寄せすぎない設計を検討する。
• 例外の握りつぶし（IOExceptionの再送/再試行）をすると、障害時にスレッドが詰まり、サービス全体が固まりやすい。タイムアウトとサーキットブレーカ（上位制御）が重要。

Go

• goroutineが多い構成だと、NFS待ち（ブロッキングI/O）が増えたときに、アプリが“生きているのに遅い”状態になりやすい。タイムアウト設計とバックプレッシャーが重要。
• ファイルロックや排他をOS依存で実装している場合、NFS環境での挙動を事前に検証する必要がある。

Rust

• 安全性の高いコードでも、I/Oの失敗モードは別問題。Resultの伝播を「ログだけで終わらせる」と、障害時に復旧不能な状態を作りやすい。エラー分類とリトライ方針が重要。
• 非同期I/Oでも、基盤が詰まると待ちが増える。設計として“待てる量”を制御する（キュー制限等）ことが重要。

Python

• 例外処理が柔軟な反面、安易なexceptで握りつぶすと、障害が“静かに悪化”する。NFS関連の例外はログ・メトリクスに必ず残す。
• 多重プロセス/スレッドで同一ファイルを扱う場合、ロック設計が曖昧だと障害時に整合性が崩れやすい。アプリ側の排他・冪等性設計が重要。

Ruby

• ファイルI/O例外の扱いを軽くすると、障害時にジョブが詰まり続ける。特にバッチ/ワーカー構成ではリトライポリシー（回数・間隔・上限）を明確にする。
• ファイルベースのロック・キューをNFS上に置く設計は、障害時の影響が大きくなりやすい。置き場所の再検討が有効なことが多い。

JavaScript / Node.js

• 非同期APIでも、背後のI/Oが詰まるとイベントループ周辺の待ちが増え、レスポンスが落ちる。I/Oのタイムアウト・同時実行数の制御が重要。
• fs操作で返るエラー（EIO/ESTALE等）を“たまに出るノイズ”として無視すると、障害時に大量発生して一気に破綻する。ログとアラートへ接続する。

PHP

• セッション保存先やキャッシュをNFS上に置くと、NFSの遅延がそのままWeb応答遅延になる。高負荷時に連鎖しやすいので要注意。
• ファイルロック（flock等）に依存した排他は、NFS環境で期待通りにいかない場合がある。設計で依存度を下げる（DB/専用ロック機構等）検討が必要。

C# / .NET

• FileStreamや例外（IOException）の扱いを統一しないと、障害時に一部だけ再試行し続ける、など挙動が揃わず収束が遅れる。リトライ方針の共通化が重要。
• ファイル監視や一時ファイルの多用は、NFS環境でメタデータ負荷を増やしやすい。設計段階で置き場所を再検討する。

---

付録の結論は、「言語の差」より「NFSをローカルFSと同一視しない設計」が重要だという点です。個別案件では、アプリのI/O特性、障害時の許容範囲、ストレージ構成、認証方式、運用体制まで絡みます。一般論のまま進めると、最終的に“現場がしんどい仕組み”になりがちです。具体的な案件・契約・システム構成で悩んだときは、株式会社情報工学研究所への相談・依頼を検討してください。現場目線で、被害最小化と収束のための設計・運用に落とし込む支援が可能です。