web-dev-qa-db-ja.com

automount nfs：信頼できないサーバーのautofsタイムアウト設定-ハングアップを回避する方法

フラット共有用に小さなサーバーを実行しています。ほとんどの場合、ファイルサーバーにいくつかの追加サービスが含まれます。クライアントはLinuxマシン（ほとんどがUbuntuですが、他のディストリビューションもいくつかあります）とその中間のMac（-Book）です（ただし、質問には重要ではありません）。サーバーはUbuntu 11.10（Oneiric Ocelot） 'Server Edition'を実行しています。セットアップとテストを実行するシステムで11.10 'Desktop Edition'を実行しています。私たちはかなり長い間Samba（慣れ親しんでいます）で共有を実行していますが、次に移行します[〜＃〜] nfs [〜＃〜]（LANにWindowsユーザーがいないので試してみたい）と今のところすべてうまくいきます。

次に、autofsを使用して自動マウントをセットアップし、処理をスムーズにしたいと思います（これまでは、必要に応じて全員が手動で共有をマウントしています）。自動マウントも機能しているようです。問題は、私たちの「サーバー」がエネルギーを節約するために24時間年中無休で実行されないことです（誰かがサーバーから何かを必要とする場合、サーバーの電源が入り、後でシャットダウンされるため、毎日数時間しか実行されません）。しかし、autofsのセットアップのため、サーバーが実行されていないときにクライアントがハングアップすることがよくあります。

  • サーバーが稼働していないときでも、すべてのクライアントを正常に起動できます。

  • しかし、サーバーが実行されていないときに/nfsの下の共有へのシンボリックリンクを含むディレクトリを（ターミナルまたはnautilusで）表示したい場合、少なくとも2分間ハングします（autofsはサーバーに接続できないため、試してみてください）。

    • それを回避する方法はありますか？それで、ディレクトリへの変更があるまで、またはそのディレクトリのコンテンツがアクセスされるまで、マウントが遅れるでしょうか？ /nfsの下の共有へのリンクを「見る」ときではないのですか？私はそうは思いませんが、多分それをあまり長い間アクセスしないようにすることは可能でしょうか？そして、空のディレクトリ、または「そのディレクトリが見つからない/接続できない」などのようにしてください。

  • サーバーが稼働している場合、すべてが正常に動作します。

  • しかし、サーバーがシャットダウンすると、before共有がマウント解除されると、ツール（dfまたはll）がハングします（共有はまだオンですが、サーバーは応答しなくなります）。

    • 接続が失われたときに共有を自動的にマウント解除する方法はありますか？

  • また、サーバーがダウンしてもクライアントはシャットダウンまたは再起動せず、共有がマウントされています。 「killing残っているプロセス」で（思われる限り無限に）ハングし、何も起こらないようです。

マウントとアンマウントのタイムアウト値はすべて適切だと思います。また、サーバーへの接続が失われたときにすべての共有を削除することもできます。

だから私の質問は：これをどう扱うか？そしておまけとして、実際の共有をマウントする必要なしに/nfs内にリンクする良い方法はありますか（autofsオプションまたはおそらくマウントが発生したときに置き換えられる疑似FS for /nfsを使用）またはそのようなもの）？

私のセットアップ

NFS設定はかなり基本的ですが、これまでのところNFSv4）：

/ etc/default/nfs-common

NEED_STATD=
STATDOPTS=
NEED_IDMAPD=YES
NEED_GSSD=

/ etc/idmapd.conf

[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

/ etc/exports

/srv/   192.168.0.0/24(rw,no_root_squash,no_subtree_check,crossmnt,fsid=0)

エクスポートルート/srvの下に、bindを含む2つのディレクトリがあります。

/ etc/fstab（サーバー）

...
/shared/shared/      /srv/shared/      none    bind  0 0
/home/Upload/        /srv/upload/      none    bind  0 0

1つ目はほとんどが読み取り専用です（ただし、NFS設定ではなくファイル属性と所有権を使用して強制します）。2つ目はすべてrwです。注：/ etc/exportsに追加のエントリはなく、個別にマウントしても機能します。

クライアント側では、それらは/etc/fstabでセットアップされ、必要に応じて手動でマウントされます（mortonはサーバーの名前であり、正常に解決されます）。

/ etc/fstab（クライアント）

morton:/shared  /nfs/shared nfs4    noauto,users,noatime,soft,intr,rsize=8192,wsize=8192    0   0
morton:/upload  /nfs/upload nfs4    noauto,users,noatime,soft,intr,rsize=8192,wsize=8192    0   0

autofs setupの場合、クライアントの/etc/fstabからエントリを削除し、残りを次のように設定しました。

/ etc/auto.master

/nfs    /etc/auto.nfs

最初に、提供された実行可能ファイル/etc/auto.netを結びました（これを見ることができます here ）が、自動的に何もマウントされません。次に、オンラインで見つけたいくつかのハウツーに基づいて/etc/auto.nfsを記述します。

/ etc/auto.nfs

shared  -fstype=nfs4  morton:/shared
upload  -fstype=nfs4  morton:/upload

そして、それはちょっと動作します...またはサーバーが24/7を実行する場合は動作します。そのため、サーバーが実行されていない状態でクライアントが起動したとき、または共有が接続されたままサーバーがダウンしたときに、ハングアップが発生します。

configurationnfsautomountingfile-serverautofs
18
Brutus

マウントシステムを使用している場合、Nautilusが、マウントされているかどうかにかかわらず、マウントを含むディレクトリを一覧表示する状況を回避する必要があります。したがって、autofsでは、たとえば/ nfsにマウントを作成しないでください。その場合、Nautilusを使用して「ファイルシステム」を一覧表示すると、/ nfsに存在する必要のあるマウントが作成され、それらのマウントの試行が失敗した場合、中止に数分かかります。

それで私がしたことは、auto.masterを変更して、/ nfs/mntにマウントを作成することでした。

これで問題が解決しました。/nfs/mntの内容を一覧表示しようとすると、長い遅延が発生しますが、これは簡単に回避できます。

2
Tim Passingham

Mount-options "bg、intr、hard"を使用して、NFS共有をクライアントにマウントします。

あなたのケースで最も重要なのは、バックグラウンドの「bg」です。これは、サーバーが使用できない場合にブロックしないようにシステムに指示します。

割り込み可能を表す「intr」-killコマンドを使用して、クライアント上のハングしているマウントを強制終了できます。

「ハード」は「ソフト」の反対です。違いは、「ハード」は無限に試行を継続するのに対し、「ソフト」はサーバーが使用できない場合にその再試行を指数関数的にバックオフすることです。

20
Nils

Manページのオプションをいくつか試してみました。すべての bg,hard、bg,soft、fg,hardおよびfg,soft 2分以上の戻り時間を教えてください。

設定retrans=1,retry=0（上記のいずれかと組み合わせて）でも、時間は約3秒です。かなりまとも。それぞれの組み合わせが何を意味するのかはわかりませんが。さらに掘り下げます。

また、autofsオプションMOUNT_WAITおよびUMOUNT_WAIT。私は彼らといくつかの異なる結果を得ることができませんでしたが、私は挑戦し続けます。 likaは "より安全"（別名：より多くの再試行など）を使用するための良い方法のようですが、NFSオプションですが、autofsの戻り時間が短いのですか？

7
Brutus