システム管理
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

Serviceguardのネットワーク監視について

manamana
時折のビジター

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と上記機能の関係性における明確な記載を見つけられず質問させていただきました。

2 件の返信
tomonari
頻繁なアドバイザー

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倍って、どなたか障害パターンを検査された方いらっしゃいますでしょうかね。ケーブル抜いたり、スイッチの電源切ったりでは確認できないようですけれど。
manamana
時折のビジター

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パラメータが影響した場合の検出時間について知ることができ、大変参考になりました。ありがとうございます。