6.3.3.7. NFS-Ganesha サービスがダウンタイム


高可用性のアクティブ/アクティブ環境で、特定のアプリケーションを実行している NFS-Ganesha サーバーに接続されている NFS-Ganesha サーバーがダウンすると、管理上の介入なしにアプリケーション/NFS クライアントは、別の NFS-Ganesha サーバーにシームレスに接続されます。ただし、別の NFS-Ganesha サーバーへの接続に遅延またはフェイルオーバー時間があります。この遅延は、フェイルオーバー時 (接続が元のノード/サーバーにリセットされる場合) にも発生する可能性があります。
以下の一覧では、NFS サーバーがサーバーの再起動を検出または再開するのにかかった時間を説明します。
  • ganesha.nfsd が終了した場合 (crashes、oomkill、admin kill)、これを検出し、ganesha クラスターを猶予する最大時間が 20sec で、pacemaker がフェイルオーバーに必要な時間がプラスされます。
    注記
    この時間は、サービスがダウンしているかを検出するのにかかった時間ですが、すべてのノードで以下のコマンドを使用して編集できます。
    # pcs resource op remove nfs-mon monitor
    # pcs resource op add nfs-mon monitor interval=<interval_period_value>
  • ノード全体が機能しなくなった場合 (ネットワークの障害を含む)、このダウンタイムは、pacemaker がノードがなくなったことを検知するために必要な合計時間、クラスターを正常に設定する時間、および障害の発生時間が発生する時間です。これは ~20 秒です。
  • そのため、max-fail-over 時間は約 20-22 秒であり、通常、平均時間は短くなります。つまり、NFS クライアントがサーバーの再起動を検出または再開するのにかかった時間は 20 - 22 秒です。
6.3.3.7.1. フェイルオーバー時間の変更
フェイルオーバー後、短い期間でクライアントが失われた OPEN/LOCK 状態を再利用しようとします。サーバーは、NFS 仕様に従って、この期間中に特定のファイル操作をブロックします。ブロックされたファイル操作は以下のとおりです。
表6.7
プロトコル ファイル操作
NFSV3
  • SETATTR
NLM
  • LOCK
  • UNLOCK
  • SHARE
  • UNSHARE
  • CANCEL
  • LOCKT
NFSV4
  • LOCK
  • LOCKT
  • OPEN
  • REMOVE
  • RENAME
  • SETATTR
注記
LOCK、SHARE、および UNSHARE は、回収が FALSE に設定された場合にのみブロックされます。
OPEN は、CLAIM_PREVIOUS または CLAIM_DELEGATE_PREV 以外の要求タイプで要求された場合にブロックされます。
猶予期間のデフォルト値は 90 秒です。この値は、/etc/ganesha/ganesha.conf ファイルに以下の行を追加すると変更できます。
NFSv4 {
Grace_Period=<grace_period_value_in_sec>;
}
/etc/ganesha/ganesha.conf ファイルを編集したら、すべてのノードで以下のコマンドを使用して NFS-Ganesha サービスを再起動します。

Red Hat Enterprise Linux 7 の場合

# systemctl restart nfs-ganesha
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.