System Management
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

MC/ServiceGurdについて

hiro_760329
アドバイザー

MC/ServiceGurdについて

実は先日、当システムにてsyslog上に以下のメッセージを出力しました。



内容としましては、システム負荷や カーネルショートハングが原因でcmcldがメッセージ中の秒数(2.11秒)の間、セイフティタイマの更新処理遅延。

−補足−

セイフティタイマとは、NODE_TIMEOUTや HEARTBEAT_INTERVAL等 MC/SGにより

監視される値を用いて、cmcldにより内部で設定される値であり、カーネルハングの検出に使用されております。このタイマの更新が出来ず時間切れになった場合には、/var/adm/syslog/syslog.logや カーネルのメッセージバッファーにその旨のメッセージがされ TOCが発生致します。

なお、定義値は以下のとおりです。

HEARTBEAT_INTERVAL 1000000(1秒)

NODE_TIMEOUT 5000000(5秒)

そこで何点か問い合わせさせていただきたいのですが、

(1)TOC発行の契機

今回の事象はsyslog上に上記メッセージを出力したにも関わらず、TOCを発行しておらずクラスタの再編成にはいたっておりません。

これはセイフティタイマの遅延がNODE_TIMEOUT設定値(5秒)に達しなかったために再編成されなかったと考えて宜しいのでしょうか?

(2)セイフティタイマとは

セイフティタイマとはHEARTBEAT_INTERVALのことと考えて宜しいでしょうか?

当システムでは1秒に設定しております。今回の事象(2.11秒遅延)においては

ハートビートパケットが2回ロストしたということになるのでしょうか?

(3)パートビートLANの2重化について

当システムではハートビートLANを専用に準備し2重化しております。ネットワークに負荷(輻輳)がかかっているとは考えにくく、

仮に片側で障害が発生しても副側で代替できることから、システム装置内部(CPU、メモリ、カーネルハング)に問題がある可能性が

高いと考えて宜しいでしょうか?

(4)cmcldシステム監視について

項番(3)で示すようにシステム装置内部の問題の場合、cmcldがCPU、メモリ、カーネルハングのいずれかに問題を検知したということになります。cmcldは各項目(CPU、メモリ、カーネルハング)についてどういう手段でどういうタイミング(HEARTBEAT_INTERVALに依存?)で監視しているのでしょうか?
3 件の返信
cube0015
レギュラーアドバイザー

MC/ServiceGurdについて

わかる範疇で以下にコメントします。

> (1)TOC発行の契機

> 今回の事象はsyslog上に上記メッセージを出力したにも関わらず、TOCを発行しておらずクラスタの再編成にはいたっておりません。

> これはセイフティタイマの遅延がNODE_TIMEOUT設定値(5秒)に達しなかったために再編成されなかったと考えて宜しいのでしょうか?

>

> (2)セイフティタイマとは

> セイフティタイマとはHEARTBEAT_INTERVALのことと考えて宜しいでしょうか?

> 当システムでは1秒に設定しております。今回の事象(2.11秒遅延)においては

> ハートビートパケットが2回ロストしたということになるのでしょうか?

cmcld が常時Safety Timerの値を更新、カーネルがその値を監視し、現在の時刻(実時刻)が更新された値の時刻を超えた場合に カーネルがTOCを発行します。

(1)(2)に関して:

→実時刻が、Safety Timerが更新した時刻を越えなかったのでは。

cmcldが更新する値は現在時刻にタイムアウト値を加えた値です。

で、タイムアウト値の計算式は公開されていないので

不明ですが。



> (3)パートビートLANの2重化について

> 当システムではハートビートLANを専用に準備し2重化しております。ネットワークに負荷(輻輳)がかかっているとは考えにくく、

> 仮に片側で障害が発生しても副側で代替できることから、システム装置内部(CPU、メモリ、カーネルハング)に問題がある可能性が

> 高いと考えて宜しいでしょうか?

2重化しているから、ネットワーク負荷はOKと言い切るのも、調査しなければ判断するに難しいですが、

おそらく、HW側に負荷がかかっているのでは。

>

> (4)cmcldシステム監視について

> 項番(3)で示すようにシステム装置内部の問題の場合、cmcldがCPU、メモリ、カーネルハングのいずれかに問題を検知したということになります。cmcldは各項目(CPU、メモリ、カーネルハング)についてどういう手段でどういうタイミング(HEARTBEAT_INTERVALに依存?)で監視しているのでしょうか?

このアルゴリズムも非公開なのではないでしょうか!?

#ちなみに、「半角カタカナ」にご注意願います。
Fu_Hi
頻繁なアドバイザー

MC/ServiceGurdについて

技術情報ツリーの

(1)(2)の答えは

jnav001421とjnav000360を参照されると良いと思います

抜粋すると

-----------------------------------------------

cmcld はセーフティ・タイム・レジスタを毎秒システム・クロックよりも5秒先行する値を設定します。

カーネルはそれをチェックして、システム・クロックがレジスタ値を超えていることを検出した(レジスタが更新されない状態が5秒以上続いた)場合、クラスタ・デーモンに障害があったと判断し、システムをTOCで停止させます。

------------------------------------------------

と書いてあります。

cmcldがメッセージ中の秒数(2.11秒)の間、セイフティタイマの更新処理遅延というのは サーバの負荷などでcmcldがタイマを更新ができなかったときに表示されるものです。したがいましてこのメッセージとハートビートの設定やネットワークの状態は関係ありません。
hiro_760329
アドバイザー

MC/ServiceGurdについて

ご回答いただきましてありがとうございます。けっきょくシステムリソースの負荷がどうだったかということになるようですね。リソース情報は定期的に取得しているのですが、1分間隔であるため瞬間的な値は残念ながらわからない状態です。若干心配な気もしますが、今回はこれにて様子見としたいと思います。お世話になりました。