VPN 背後の NFS:起動時マウントかオンデマンド自動マウントか
起動時マウントは、まだ上がっていないかもしれないトンネルで停止します。自動マウントは最初のアクセスを待ち、VPN への依存はトリガーではなくマウントユニットに置くべきです。
二つの構成は同じ問題を解き、正反対の方向に失敗する。共有を起動時にマウントすると、すべてのサービスは、そこにあるか、起動が止まった理由を示すファイルシステムを得る。オンデマンドの自動マウントはマシンに速い起動を与え、待ち時間を最初にそのパスに触れた者へ渡す。VPN の背後では後者のほうがたいてい良い取引であり、その理由は、トンネルが起動シーケンスには見えない順序を課すからだ。
起動時マウントと自動マウントの比較
起動時マウントは理屈が簡単だ。ファイルシステムのターゲットはマウントを待ち、それへの依存を宣言したサービスはその後に起動し、サーバーに到達できなければ、オプションに応じてマシンは待つか失敗する。下流のすべてがその一つの決定を引き継ぐ。
自動マウントはそれを逆にする。パスは即座に存在し、実際のマウントは何かがそれを開いたときに起こり、早く起動するサービスはまだ上がっていないトンネルでブロックしない。
比較は、遅延を誰が引き受けるべきかに帰着する。ユーザーが作業できる前に共有を必要とするワークステーションは、おそらく待つべきだ。鞄の中で起動するノート PC や、共有が任意のサーバーは待つべきではない。
どちらの選択肢も欠けたルートを直さない。どちらも、失敗がいつ観測されるかを決めるだけだ。
fstab の行を、オプションごとに
既存の OpenVPN クライアントインスタンスが [email protected]、サーバーが files.corp.example、マウントポイントが /mnt/work だとしよう。三つとも自分のサイトの許可された値に置き換える。動作する一行は次のようになる:
files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0
_netdev はマウントにネットワークが必要だと印を付け、トンネルを一切名指ししない。nofail は通常のファイルシステムターゲットに対して共有を任意のままにする。x-systemd.automount は即座にマウントする代わりにオンデマンドのトリガーを作る。
x-systemd.requires= はマウントの試行を VPN ユニットに結びつける部分であり、トリガーではなくマウント操作に属する。自動マウントユニット自体に広い順序を置くのが、人々が循環を作り、あとで systemd が誰も二度読まない言葉で不平を言う原因だ。
x-systemd.mount-timeout=30s は最初のマウントコマンドを制限する。それは後に起きることには何も制限をかけず、これがこのオプションについて最も多い誤解だ。
「起動した」が意味しないこと
名指しした VPN ユニットについて active の意味を確認してほしい。トンネルサービスは、ファイルサーバーへのルートが存在する前、あるいはプライベート名が解決する前に、自分が起動したと報告できる。その後に順序を付けても何も得られない。ほぼすべての失敗した試行はこの隙間に住んでおり、ユニットの状態ではなくルートとリゾルバーを見ない限り、それは見えない。
存在する場合、接続の所有者自身の準備完了シグナルを追加の前提条件として使う。固定の sleep はあなたの机の上では機能し、遅いネットワークや再接続の後では失敗する推測だ。
例のパスについて生成されたユニットを調べる:mnt-work.automount と mnt-work.mount。レビュー済みの fstab 変更の後は、systemd を再読み込みし、無関係なエントリを動かす包括的な mount コマンドを走らせるのではなく、それらのユニットを直接管理する。
もう一つ注意点がある。起動時に /mnt/work に触れるサービスは今もマウントを引き起こし、今もそれを待つので、共有を任意にしても、すべてのアプリケーションが辛抱強くなるわけではない。
マウントの後は別の失敗だ
NFS がマウントされると、その後の障害が読み取りや書き込みに何をするかは、ファイルシステムの再試行と回復の振る舞いが決める。設定したマウントタイムアウトはそれに影響しない。
ソフトマウントは一部の待ちを短くし、エラーの意味を変え、起動の速さを狙うときには見落としやすいデータ整合性の結果を伴う。起動の二秒を稼ぐために選ぶのは、めったに良い取引ではない。本当に要求が障害中の有界な操作なら、それはアプリケーション側の決定であり、fstab のフラグではない。
トンネルが落ちたとき、書き込みの途中にあるプロセスをどうするかを決め、書き留める。その答えはどんなオプション文字列よりも役に立つ。
一つの状態ではなく四つの状態を試す
トンネルが利用できる通常の起動は易しいケースで、ほとんど何も証明しない。文字列が正しく綴られていることを確認するだけで、それ以上ではない。VPN がない状態で最初のアクセスを試し、次にそれが上がったときの回復を、次に成功したマウント後の制御された障害を試す。
四つの状態、四つの観察、そしてメモは fstab のエントリの隣に置く。次の人は、リバースエンジニアリングしなければならない設定ではなく、振る舞いを引き継ぐ。