☰

ホスト検索に関連するautofsのインストール遅延を解決するには？

tag-icon • tag-icon nfs autofs
ホスト検索に関連するautofsのインストール遅延を解決するには？

私はautofsを使用して組織内の他の場所のサービスからエクスポートされたさまざまなNFSファイルシステムを自動的にマウントするCentOS 6およびCentOS 7クライアントシステムのインフラストラクチャを持っています。最近、クライアントはこれらのファイルシステムの自動マウントが非常に遅くなる問題のある動作を示し始めました。以前は数秒しかかかっていなかったマウントが、約2分かかり始めます。

私は問題をさまざまな要因に分類したと思います。

  • サーバーのホスト名にはさまざまな解像度があります（32）。
  • ホスト名に複数の解決策がある場合、autofs は各解決策を検出し、応答しない解決策を拒否し、残りの解決策の中から現在の応答時間が最善の解決策を選択します。
  • autofsが各サーバーに発行した2つのプローブRPCのうちの1つがタイムアウトしているようです。みんな私のサーバー。

以下は、デバッグログから抜粋した代表的な内容です。

Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 6 version 0x20
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: nfs v3 rpc ping time: 0.000290
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: host nfs.my.org cost 289 weight 0
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 17 version 0x20
Jul 13 15:48:21 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.84) proto 6 version 0x20

これは、完全なプローブと3秒後に次のプローブの開始を示しています。遅延に加えて、2番目のRPC応答については何も表示されません。これは私にとって「タイムアウト」です。タイムアウト自体はわずか3秒ですが、これを32台のマシンで乗算すると、実際にマウントを試みる前に1分30秒以上のタイムアウトが必要になります。

クライアントはCentOS 6および7用の標準NFSクライアントスタック（nfs-utils 1.2.3およびautofs 5.0.5またはnfs-utils 1.3.0およびautofs 5.0.7）を実行し、それぞれCentOSにパッケージ化されています。クライアントが構成管理を受けているので、問題が始まる前からソフトウェアや構成を変更したことはありません。

サーバーがGaneshaユーザースペースNFSスタックを実行しているという事実、特にNFS4をサポートしていないという事実は、過去には問題ではありませんでしたが、これに関連している可能性があります。サーバー管理では、意図的な構成変更は行われていませんが、定期的なソフトウェア更新プログラムのインストールを許可したと主張しています。

したがって、最終的に質問は、タイトルが示すように、ホストプロービングによるマウント遅延を解決する方法です。 Ganeshaにデフォルト値が変更された可能性がある関連構成設定はありますか？または、失敗したRPC試行を防ぐためにautofsを設定する方法はありますか？それとも私が問題を間違って認識したのでしょうか？

autofs設定パラメータをオンにするとuse_hostname_for_mounts問題が解決するようですが、私が理解しているように、これは個々のサーバーエラーと過負荷に対する回復力を失う対価を払います。もっと良い方法はありませんか？

ベストアンサー1

ログメッセージの重要な手がかりは、「proto 6」で記録されたプローブは成功したのに対し、「proto 17」で記録されたプローブは失敗したことです。 ６及び１７は、それぞれＴＣＰ及びＵＤＰを示すＩＰ転送プロトコル番号である。

NFSは伝統的にUDPを介して提供されていましたが、ほとんどのスタックはTCPを介したサービスをサポートし、この例のサーバーは常にTCPを介してのみNFSを提供するように構成されています。ただし、サーバーにまだ特徴付けられていない変更のため、nfs / udpトラフィックが適切なICMP応答で拒否されるのではなく、自動的に破棄されるまで問題は発生しませんでした。これはファイアウォールの変更によって引き起こされる可能性が高いですが、現在のところ、サーバーのアプリケーションレベルの変更を排除することはできません。

とにかく、proto=tcpautofsマップファイルの影響を受けたファイルシステムごとにマウントオプションを追加して、クライアント側の問題を解決しました。このオプションが適用されると、AutofsはUDPスタイルの検索を中断するのに十分スマートです。問題が解決されただけでなく、現在タイムアウト問題が発生する前よりもマウント性能も良くなったようです。

おすすめ記事