kdump の設定をしているのであれば、 softdog カーネルモジュールをロードする際のパラメータに soft_panic=1 という指定を追加していただきますようお願いします。
■お知らせの背景
Pacemaker を使っているシステムが突然再起動したというお問合せは少なくありません。具体的な件数については把握していませんが、仮想化環境での発生事例が多いようです。残念なことに、ログファイルや sar を調査しても手がかりが残っておらず、原因不明のまま諦めざるを得ないという状態が何年も続いてきました。
RHEL6/CentOS6 以降の softdog カーネルモジュールには、タイムアウトの発生時に「システムを再起動させる」代わりに「カーネルパニックを発生させる」ための soft_panic というパラメータが存在しています。このパラメータを kdump の設定と組み合わせることで、タイムアウトの発生時に vmcore を取得することが可能になります。
vmcore にはタイムアウトが発生した時点の情報しか含まれないので、 vmcore を取得できればタイムアウトの原因を必ず突き止められるという訳ではありません。しかし、たくさんの事例を積み重ねることで、傾向を分析して対策を考えることはできるものと考えます。
■分析により見つかった問題点の例
Corosync main process was not scheduled for X ms (threshold is Y ms). Consider token timeout increase. というメッセージは、一般的には「カーネルが corosync プロセスにＣＰＵ時間を割り当てできなかった」という解釈／説明がされていますが、必ずしもカーネルやハードウェア側の問題を示唆している訳ではありません。１個のスレッドが様々な処理を行っているという corosync プロセスの構造上、「（カーネルは corosync プロセスにＣＰＵ時間を割り当てていたものの、 corosync プロセスが他の処理で忙しかったことにより、）このメッセージを出力するための関数を呼び出せるようになるまでに想定外の時間がかかっただけ」という可能性もあるのです。
このような問題が実際の業務負荷で発生しているのかどうかは、 vmcore を取得して確認してみないと判断できません。サポートセンタでは実際の業務負荷をかけることができないので、利用者の方々に vmcore の取得へのご協力をお願いする必要があります。
■ＮＴＴ ＯＳＳセンタを利用されている方への補足
vmcore を送付できる場合には、サイズが数十ＧＢのファイルであってもそのまま扱える「ファイルアップロード／ダウンロードシステム」をご利用ください。 vmcore を送付できない場合、あるいは、送付にかかる時間が勿体ないので自前で初期解析を行いたい場合には、 crash コマンドを用いて vmcore の初期解析を行う手順をご利用ください。詳細については、（ＮＴＴ ＯＳＳセンタの契約者向けコンテンツである）「ナレッジの泉」を参照してください。