赤松
akama****@oss*****
2009年 2月 25日 (水) 10:16:21 JST
To:関根さん 赤松と申します。 下記、インラインで回答いたします。 > 上記の示すSIDCHLDシグナルは内部(各ノード単体)に閉じた世界 > なのでしょうか？ > それともクラスタグループ全体からの相互通信によるもの > なのでしょうか？ > あくまでサーバ（host02？）内のHeartbeatの動作に特化したシグナルです。 クラスタグループとは関係ありません。 > また、今回のメッセージでクラスタ環境に悪影響を及ぼす様な事は > 有るのでしょうか？ > （リソースの消滅や多重起動など） > このメッセージは、処理依頼が来てから実際の処理を行うまでの間の時間が 閾値（100msec、変更不可）を超えた事を知らせています。 実際の処理を行う前に、閾値を超えていたらログに出力しています。 おそらくコミュニティとしては、この時に多少の負荷が存在していた事を 保守者へ伝える為のお知らせとして、組み込んだものと思われます。 このメッセージが出力されている時、それなりの負荷が存在した事を示す 目安程度と考えるのが良いかと思います。 短い時間にあまりに頻発するようであれば、負荷によるリソースの監視 タイムアウトが万一発生する可能性を考慮し、リソースの各種タイム アウト値の調整を検討する、くらいの運用で良いのではないかと 考えます。 > 今回のアラートがトリガーとなってfailoverの発生してしまう場合は別途 > 「ERROR」が出力されるイメージなのでしょうか？ > 上記に示しました通り、当アラートがトリガとなる事でfailoverが発生 する事はないと思われます。 > 監視抑止するのに「WARN」を全部抑止は考えていません。 > どんな文言を抑止の対象とすれば障害の際に弊害とならずに済むでしょうか？ > 関根さんのご利用環境（Heartbeatのバージョンや追加パッケージ等）が 判りませんし、運用方針にも依存するので、こうすべきと言い切る事は できませんが、あくまで個人見解として述べさせて頂きます （ちなみに私の環境は 2.1.3-1.p1 及び 2.1.4-1 です） 私としましては、ERROR及びCRITの二つは、重点的に見ています。 （ERRORと出たからと言って必ずしもERRORではない場合もありました） それ以外の見方としましては、WARNやinfo等のファシリティ単位ではなく 状態が変更された際のログそのものを監視対象にしています。 "状態の変更"とは主に、リソースの開始・監視・停止失敗時、クラスタ グループへの参加・離脱、ネットワーク監視、Heartbeat用LANの断線・結線等 が挙げられます。 これらを試験的に実施し、出力されるログを参考にして監視対象にする という方法を採っています。 Heartbeatはログ解析がとても大変なので、この辺りの作業を楽にして くれる追加パッケージの登場が待たれる所です。 以上です。 > 赤松様 > > 回答ありがとうございます。 > 1点気になっている点が有るのですが、 > > SIGCHLD シグナルを受信してから、SIGCHLD シグナルに括りつけられた処理を開始 > > するまでの時間 > 上記の示すSIDCHLDシグナルは内部(各ノード単体)に閉じた世界なのでしょうか？ > それともクラスタグループ全体からの相互通信によるものなのでしょうか？ > 認識不足で申し訳ありませんが教えて頂けたらと思います。 > > また、今回のメッセージでクラスタ環境に悪影響を及ぼす様な事は有るのでしょ > うか？ > （リソースの消滅や多重起動など） > > 当アラートを検知する直前に毎回決まったメッセージが出力されています。 > 何かの参考になればと思います。 > =============================================== > Daily informational memory statistics > MSG stats: 6/9634137 ms age 0 [pid24518/MST_CONTROL] > ha_malloc stats: 724/305366571 175824/93154 [pid24518/MST_CONTROL] > RealMalloc stats: 404684 total malloc bytes. pid [24518/MST_CONTROL] > Current arena value: 0 > MSG stats: 0/0 ms age 6978126360 [pid24521/HBFIFO] > ha_malloc stats: 440/473 51072/28485 [pid24521/HBFIFO] > RealMalloc stats: 51072 total malloc bytes. pid [24521/HBFIFO] > Current arena value: 0 > MSG stats: 0/0 ms age 6978126360 [pid24522/HBWRITE] > ha_malloc stats: 445/3364206 60876/33958 [pid24522/HBWRITE] > RealMalloc stats: 69556 total malloc bytes. pid [24522/HBWRITE] > Current arena value: 0 > MSG stats: 0/0 ms age 6978126420 [pid24523/HBREAD] > ha_malloc stats: 446/6422331 60968/34022 [pid24523/HBREAD] > RealMalloc stats: 65012 total malloc bytes. pid [24523/HBREAD] > Current arena value: 0 > MSG stats: 0/0 ms age 6978126470 [pid24524/HBWRITE] > ha_malloc stats: 447/3364216 61060/34086 [pid24524/HBWRITE] > RealMalloc stats: 69740 total malloc bytes. pid [24524/HBWRITE] > Current arena value: 0 > MSG stats: 0/0 ms age 6978127740 [pid24525/HBREAD] > ha_malloc stats: 448/6422345 61152/34150 [pid24525/HBREAD] > RealMalloc stats: 65196 total malloc bytes. pid [24525/HBREAD] > Current arena value: 0 > These are nothing to worry about. > =============================================== > 今回のアラートがトリガーとなってfailoverの発生してしまう場合は別途 > 「ERROR」が出力されるイメージなのでしょうか？ > 監視抑止するのに「WARN」を全部抑止は考えていません。 > どんな文言を抑止の対象とすれば障害の際に弊害とならずに済むでしょうか？ > > いろいろ質問が多く恐縮ですが、お力をお借りできたらと思っています。 > > 以上、宜しくお願い致します。 > > 関根 > > > 赤松 さんは書きました: > > To:関根様 > > > > はじめまして、赤松と申します。 > > > > 御提示頂きましたログ情報についての見解をお伝えします。 > > > > ログのメッセージは、Heartbeatの内部処理にて、SIGCHLD シグナルを > > 受信してから、SIGCHLD シグナルに括りつけられた処理を開始するまでの > > 時間が、予め設定された制限時間を超えた事を意味するものです。 > > > > なお、"予め設定された制限時間"は100msで、プログラム内にハード > > コーディングされており、設定ファイル内の数値による調整は > > できません。 > > つまり当ログを出力させないようにする手順は、現時点では > > ございません。 > > > > メッセージが出力された原因としましては、その時点での相応の負荷に > > よるものではないかと推測できます。 > > > > 現時点での運用上で、特に問題が無い様であれば、暫定対処及び > > 本格対処の検討等は必要ないと考えます。 > > 運用監視ソフト等にて当メッセージを監視対象としている場合には > > 監視対象から外して頂いても問題ないと思われます。 > > > > > > 以上です。 > > 宜しくお願い致します。 > > > > > > > >> お世話になっております。 > >> 関根 と申します。 > >> > >> 下記につきまして、対応の経験やトラブル対応のナレッジをお持ちの方がいまし > >> たら返答願いたいと思います。 > >> > >> この度下記のアラーとが発生しております。 > >> ================================== > >> Feb 19 19:07:07 host02 logger: " host02 [messages] Feb 19 19:07:07 > >> host02 heartbeat: [24518]: WARN: Gmain_timeout_dispatch: Dispatch > >> function for check for signals took too long to execute: 580 ms (> 510 > >> ms) (GSource: 0x64cba8) " > >> Feb 19 19:07:07 host02 logger: " host02 [messages] Feb 19 19:07:06 > >> host02 heartbeat: [24518]: WARN: Gmain_timeout_dispatch: Dispatch > >> function for check for signals was delayed 2620 ms (> 510 ms) before > >> being called (GSource: 0x64cba8) " > >> Feb 19 19:07:07 host02 logger: " host02 [messages] Feb 19 19:07:06 > >> host02 heartbeat: [24518]: WARN: Gmain_timeout_dispatch: Dispatch > >> function for send local status was delayed 2860 ms (> 510 ms) before > >> being called (GSource: 0x64c5a8) " > >> ================================== > >> 上記アラートが最近になってほぼ毎日、同じような時間に発生しています。 > >> メッセージでは通信に遅延が発生しているように感じられます。 > >> 通信に異常が出ていない為、問題はないのかとも考えていますが、本エラーに関 > >> する情報をお持ちの方が居たら教えて頂けたらと思います。 > >> > >> また参考までに構成ですがシンプルな2台構成でそれぞれにVIPを1つずつリソー > >> スとして持たせています。 > >> リソースはVIPのみで、襷掛けの形のActive-Standby構成になっています。 > >> > >> 変わった特徴としてはセグメントを3つ使用しVIPが上がるセグメント以外の2つ > >> のネットワーク帯でucast通信を行っています。 > >> > >> 現在、この時間に負荷がかかる様な処理は確認できませんが、半年以上restart > >> していないので不具合？とも疑っています。 > >> > >> 情報が少なくて恐縮ですが、お力を貸して頂けたら幸いです。 > >> > >> 以上、宜しくお願い致します。 > >> > >> 関根 > >> > >> _______________________________________________ > >> Linux-ha-japan mailing list > >> Linux****@lists***** > >> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan > >> > > > > > > > -- > +----------------------------------------++ > 関根 勇喜 (sekine.yuki) > 株式会社 シンプレクス・テクノロジー > 〒106-6016 > 東京都港区六本木1-6-1 泉ガーデンタワー16F > mailto:sekin****@simpl***** > TEL: 03-5545-7870 > FAX: 03-5545-7875 > +----------------------------------------++ > > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
Fork