- Community Home
- >
- HPE Community, Japan
- >
- HP-UX
- >
- System Management
- >
- Serviceguardのネットワーク監視について
system management
1748092
メンバー
5984
オンライン
108758
解決策
フォーラム
カテゴリ
Company
Local Language
戻る
フォーラム
ディスカッションボード
フォーラム
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
ディスカッションボード
ディスカッションボード
ディスカッションボード
フォーラム
ディスカッションボード
戻る
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
ブログ
情報
コミュニティ言語
言語
フォーラム
ブログ
トピックオプション
- RSS フィードを購読する
- トピックを新着としてマーク
- トピックを既読としてマーク
- このトピックを現在のユーザーにフロートします
- ブックマーク
- 購読
- 印刷用ページ
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
03-24-2007 08:41 AM
03-24-2007 08:41 AM
Serviceguardのネットワーク監視について
初歩的な質問かもしれませんが、、すみませんが教えて下さい。。
Serviceguardのネットワーク障害に関する機能として、以下をよく使用しています。
1)ローカルスイッチ
HeartBeatやPublic LAN等を冗長化によってActive/Standbyに構成し、Active側のネットワークに障害が発生した場合、StandbyのNICにスイッチさせる。
2)パッケージによるサブネットの監視(SUBNETパラメータの設定)
パッケージによってサブネットを監視させ、サブネットがダウンした場合にパッケージを停止する。
それで、上記2つの機能それぞれにおける、Serviceguardのネットワーク監視間隔、障害検出時間について教えて下さい。
クラスタ構成ファイルに、NETWORK_POLLING_INTERVALパラメータがあり、これはServiceguardがネットワークの死活監視をするためにポーリングする時間間隔を設定すると認識してますが、上記1)も2)の機能もこのパラメータによって制御されていると考えてよいでしょうか。
つまり、NETWORK_POLLING_INTERVALはデフォルト2秒ですが、この値を例えば10秒とした場合は、1)や2)の機能におけるネットワークの監視間隔及び障害検出時間も10秒になると考えてよいでしょうか。
現在検証する環境がなく、また、NETWORK_POLLING_INTERVALと上記機能の関係性における明確な記載を見つけられず質問させていただきました。
Serviceguardのネットワーク障害に関する機能として、以下をよく使用しています。
1)ローカルスイッチ
HeartBeatやPublic LAN等を冗長化によってActive/Standbyに構成し、Active側のネットワークに障害が発生した場合、StandbyのNICにスイッチさせる。
2)パッケージによるサブネットの監視(SUBNETパラメータの設定)
パッケージによってサブネットを監視させ、サブネットがダウンした場合にパッケージを停止する。
それで、上記2つの機能それぞれにおける、Serviceguardのネットワーク監視間隔、障害検出時間について教えて下さい。
クラスタ構成ファイルに、NETWORK_POLLING_INTERVALパラメータがあり、これはServiceguardがネットワークの死活監視をするためにポーリングする時間間隔を設定すると認識してますが、上記1)も2)の機能もこのパラメータによって制御されていると考えてよいでしょうか。
つまり、NETWORK_POLLING_INTERVALはデフォルト2秒ですが、この値を例えば10秒とした場合は、1)や2)の機能におけるネットワークの監視間隔及び障害検出時間も10秒になると考えてよいでしょうか。
現在検証する環境がなく、また、NETWORK_POLLING_INTERVALと上記機能の関係性における明確な記載を見つけられず質問させていただきました。
2件の返信2
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
04-05-2007 11:23 AM
04-05-2007 11:23 AM
Serviceguardのネットワーク監視について
ローカルスイッチについては、
「NETWORK_POLLING_INTERVALの値の6倍の時間」という記述がHPのDeveloperEdgeの文書にあります。『Serviceguard環境でのフェイルオーバー時間の最適化』の8ページです。
http://www.hp.com/ja/developer
の「ホワイトペーパー」の「ハイ・アベイラビリティ」にあります。10秒にしたら10秒になるわけではないようですね。
但し、経験上ですけど、アプリやらハートビートやらで通信しているので、NICやドライバが直ぐにエラーを検知しているようです。直ぐにSGに通知されるて、NETWORK_POLLING_INETRAVL*6のように長い時間かかってないです。10秒に設定しても、数秒だったように思います。NICやドライバで検知できないケースは6倍になるのでしょうかね。
NODE_TIMEOUTより長くすると、ローカルスイッチ発生前にクラスタ再構成になるので注意です。クラスタ再構成が発生しても、Cable抜く等の障害テストでは、ハートビート経路の場合、やはりNICとドライバがエラーを直ぐに検知するので、すぐにローカルスイッチも発生し、結局また元の2台構成になり、パッケージは稼動したまま影響なかったですね。でも、ログ上は嫌な動作なので無理にNODE_TIMEOUT値より長くするのは危険かもしれませんね。
SUBNET監視は、SGがサブネットダウンと判断した時点で即座にパッケージのフェイルオーバーを起こします。ログを見る限り、サブネットダウンの後、即座にパッケージのフェイルオーバーを開始してます。
SGがサブネットダウンと判定するタイミングは、ローカルスイッチが発生して、その後に切り替わったNICも駄目になったと判断した時に即座です。この、「切り替わったNICも駄目になったと判断」するタイミングは冒頭のローカルスイッチのプライマリNICの障害判断と同様ですね。
明確な回答にはなっていなくてすいません。
NETWORK_POLLING_INTERVALの6倍って、どなたか障害パターンを検査された方いらっしゃいますでしょうかね。ケーブル抜いたり、スイッチの電源切ったりでは確認できないようですけれど。
「NETWORK_POLLING_INTERVALの値の6倍の時間」という記述がHPのDeveloperEdgeの文書にあります。『Serviceguard環境でのフェイルオーバー時間の最適化』の8ページです。
http://www.hp.com/ja/developer
の「ホワイトペーパー」の「ハイ・アベイラビリティ」にあります。10秒にしたら10秒になるわけではないようですね。
但し、経験上ですけど、アプリやらハートビートやらで通信しているので、NICやドライバが直ぐにエラーを検知しているようです。直ぐにSGに通知されるて、NETWORK_POLLING_INETRAVL*6のように長い時間かかってないです。10秒に設定しても、数秒だったように思います。NICやドライバで検知できないケースは6倍になるのでしょうかね。
NODE_TIMEOUTより長くすると、ローカルスイッチ発生前にクラスタ再構成になるので注意です。クラスタ再構成が発生しても、Cable抜く等の障害テストでは、ハートビート経路の場合、やはりNICとドライバがエラーを直ぐに検知するので、すぐにローカルスイッチも発生し、結局また元の2台構成になり、パッケージは稼動したまま影響なかったですね。でも、ログ上は嫌な動作なので無理にNODE_TIMEOUT値より長くするのは危険かもしれませんね。
SUBNET監視は、SGがサブネットダウンと判断した時点で即座にパッケージのフェイルオーバーを起こします。ログを見る限り、サブネットダウンの後、即座にパッケージのフェイルオーバーを開始してます。
SGがサブネットダウンと判定するタイミングは、ローカルスイッチが発生して、その後に切り替わったNICも駄目になったと判断した時に即座です。この、「切り替わったNICも駄目になったと判断」するタイミングは冒頭のローカルスイッチのプライマリNICの障害判断と同様ですね。
明確な回答にはなっていなくてすいません。
NETWORK_POLLING_INTERVALの6倍って、どなたか障害パターンを検査された方いらっしゃいますでしょうかね。ケーブル抜いたり、スイッチの電源切ったりでは確認できないようですけれど。
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
04-05-2007 02:42 PM
04-05-2007 02:42 PM
Serviceguardのネットワーク監視について
ご返信ありがとうございます!
いろいろと個人的にクリアになりました。
> ローカルスイッチについては、
>「NETWORK_POLLING_INTERVALの値の6倍の時間
>という記述がHPのDeveloperEdgeの文書にあり
>ます。
文書を拝見しました。6倍!なのですね。
私の経験上でも、ケーブルを抜くことで障害を発生させた場合、ローカルスイッチでもサブネット監視でもServiceguardのログ上では2秒程度で検出され、制御が行われていました。
これはご指摘の通り、NICやドライバレベルで検出されており、NETWORK_POLLING_INTERVALパラメータによるものでは無いことになりますね。
NETWORK_POLLING_INTERVALのデフォルト値は2秒で、この値を変更したことがなかったこともあり、この値が影響を及ぼしているのかどうか判断できていませんでした。でもこの値が影響した場合の検出は、設定値の6倍の時間がかかるということですので、影響していないことがクリアになりました。ありがとうございます。
余談ですが、AutoPortAggrigation(APA)も使用したことがあるのですが、こちらもLAN Monitorという機能によるポーリングによってネットワーク障害を検出できるのですが、
1)レイヤ1レベルの障害 −> NICやドライバにより即時に検出できる
2)レイヤ2レベルの障害 −> LAN Monitorのポーリングによって検出できる
と聞いたことがあります。ケーブルを抜いた場合は、1)の障害に当たるため即時に検出されました。
Serviceguardによる監視も上記が当てはまるとしたらレイヤ2レベルの障害を起こさないと、NETWORK_POLLING_INTERVAL値での検出は確認できないのかもしれません。(すみません、、擬似障害の方法は分からないのですが。。)
以上になりますが、頂いたご回答からServiceguardのNETWORK_POLLING_INTERVALパラメータが影響した場合の検出時間について知ることができ、大変参考になりました。ありがとうございます。
いろいろと個人的にクリアになりました。
> ローカルスイッチについては、
>「NETWORK_POLLING_INTERVALの値の6倍の時間
>という記述がHPのDeveloperEdgeの文書にあり
>ます。
文書を拝見しました。6倍!なのですね。
私の経験上でも、ケーブルを抜くことで障害を発生させた場合、ローカルスイッチでもサブネット監視でもServiceguardのログ上では2秒程度で検出され、制御が行われていました。
これはご指摘の通り、NICやドライバレベルで検出されており、NETWORK_POLLING_INTERVALパラメータによるものでは無いことになりますね。
NETWORK_POLLING_INTERVALのデフォルト値は2秒で、この値を変更したことがなかったこともあり、この値が影響を及ぼしているのかどうか判断できていませんでした。でもこの値が影響した場合の検出は、設定値の6倍の時間がかかるということですので、影響していないことがクリアになりました。ありがとうございます。
余談ですが、AutoPortAggrigation(APA)も使用したことがあるのですが、こちらもLAN Monitorという機能によるポーリングによってネットワーク障害を検出できるのですが、
1)レイヤ1レベルの障害 −> NICやドライバにより即時に検出できる
2)レイヤ2レベルの障害 −> LAN Monitorのポーリングによって検出できる
と聞いたことがあります。ケーブルを抜いた場合は、1)の障害に当たるため即時に検出されました。
Serviceguardによる監視も上記が当てはまるとしたらレイヤ2レベルの障害を起こさないと、NETWORK_POLLING_INTERVAL値での検出は確認できないのかもしれません。(すみません、、擬似障害の方法は分からないのですが。。)
以上になりますが、頂いたご回答からServiceguardのNETWORK_POLLING_INTERVALパラメータが影響した場合の検出時間について知ることができ、大変参考になりました。ありがとうございます。
上記の意見は、Hewlett Packard Enterpriseではなく、著者の個人的な意見です。 このサイトを使用することで、利用規約と参加規約に同意したことになります 。
© Copyright 2024 Hewlett Packard Enterprise Development LP