VPN 経由の NFS 再エクスポートはパケット転送ではない

Linux マシンが VPN に参加し、リモートの NFS エクスポートをマウントし、そのマウントを別のクライアント群に提供する。この構成は 余分な手順を伴うルーティングのように見えるが、それが最初の誤った前提である。中間マシンは上流サーバーのクライアントであり、下流クライアントのサーバーであり、両方のファイルサービス関係に関与する。パケット転送はファイルハンドル、ロック、ファイルシステムの同一性について何も主張しないが、再エクスポートは主張する。

まず、下流クライアントが元のサーバーに直接到達できるかを問う。できるならば、中間マシンは任意である。

三つのモデル、三つの一貫性の物語

直接マウントが最も単純である。各クライアントがトンネル経由で元のサーバーをマウントし、そのサーバーのエクスポートポリシーがアクセスを決める。再エクスポートは中間マシンが別のサービス境界を提示するもので、クライアント側のネットワークがサーバーに直接到達してはならない場合に有用である。レプリケーションは三つ目のモデルであり、問いを一貫性から同期と競合解決へ移す。

レプリケートされたコピーを、生きている再エクスポートのように説明してはならない。障害の様式は異なり、すべての操作が元のファイルシステムに届くと期待する利用者は、リンク断の間に驚くことになる。

同一性はマウントコマンドより長く生きる

再エクスポートには明示的なファイルシステム ID が必要であり、その同一性は再起動や設定の再構築を越えて存続しなければならない。カーネルの文書はこの要件を明確に述べており、さらに次のように警告している。crossmnt は、子ファイルシステムを独自の ID でエクスポートする必要性を取り除かない。利用者にとって連続して見えるディレクトリツリーが、複数のファイルシステム境界をまたぐことがある。現在の nfs-utils は対応する設定に対して ID を自動的に割り当てることができ、そうする場合、そのデータベースはゲートウェイの状態の一部になる。これらの ID は使い捨てのファイルではなく、サービスの同一性として扱うべきである。

ファイルハンドルはもう一つの同一性の境界である。再エクスポートは元のハンドルをラップするため、より大きくなり、クライアントの上限を超えることがある。マウントの成功は、すべてのエクスポート構成が互換であることを証明しない。

すべての NFS 機能が中間マシンを越えて生き残るわけではない

カーネルの再エクスポートガイドは、再エクスポートするサーバーがロックや委任要求をサポートしないと述べている。それらの操作に依存するアプリケーションには、別の経路か、それらに対して検証された設計が必要である。マウントの成功と動作するディレクトリ一覧は、アプリケーションの実際の操作が機能することを示さない。

利用者の同一性とエクスポートポリシーも各ホップで重要である。VPN ログインはネットワーク参加者が認証されたことを証明するが、NFS 利用者を認可するものではなく、クライアントの資格情報をゲートウェイ越しに転送するものでもない。

ゲートウェイには二つの上流依存がある

ゲートウェイは上流のマウントについて VPN に依存し、ファイルシステム自体について上流サーバーに依存する。まだ動作しているローカルのエクスポートプロセスは、利用できないストレージを健全にはできない。起動順序、再接続の挙動、サーバー再起動を計画し、クライアントがすでに保持しているファイルハンドルがどうなるかも含める。ゲートウェイ経由でマウントし、ハンドルを失ったクライアントには再マウントが必要であり、それは透過的な復旧ではなく運用上の出来事である。

要件がこれまで必要としたのがプライベート IP への到達性だけであったなら、元のサーバーへ直接ルーティングする方が単純なアーキテクチャである。再エクスポートは、書き留めても残る理由のために存在すべきである。

マウントではなくワークロードを試験する

管理された環境で実際のファイルワークロードを実行する。アプリケーションが行う操作、使用するファイルサイズ、想定する同時実行数を含める。トランスポートのエラーだけでなく、機能の不足に注目し、どのモデルを選び、なぜ選んだかを記録する。さもなければ次の人物はゲートウェイをルーターとみなすだろう。

再エクスポートは、分離されたクライアントネットワークや管理されたバージョン境界など、意図的な理由がある場合に正当である。それはまずい偶然であり、違いは誰かがそれを決めたかどうかである。