オープンソースのログパーサーで Pacemaker イベントを分析する - パート 4
Google Cloud Japan Team
※この投稿は米国時間 2022 年 8 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
このブログは、前回のブログ Cloud Logging で Pacemaker イベントを分析するに続く、シリーズ第 4 弾です。前回は Google Cloud Ops エージェントのインストールと構成を行って、使用している高可用性クラスタすべての Pacemaker ログを Cloud Logging にストリーミングする方法について述べました。そうすることで、どのクラスタで発生した Pacemaker イベントでも一元的に分析できるようになります。しかし、このエージェントがインストールされていない場合に、クラスタで起こったことを知るにはどうすればよいのでしょうか？
今回は、オープンソースの Python スクリプト「logparser」に目を向けることにします。このスクリプトを使うと、関連のある Pacemaker ログをクラスタ ノードから集めてひとまとめにし、フェンシングやリソース障害のような重大イベントに関係するログエントリのフィルタリングを行うことができるようになります。以下に示すログファイルが入力ファイルとして使われ、重大イベントのログエントリが時系列で書き込まれた出力ファイルが生成されます。
/var/log/messages などのシステムログ
/var/log/pacemaker.log や /var/log/corosync/corosync.log などの Pacemaker ログ
SUSE の hb_report
RedHat の sosreport
このスクリプトの使用法
このスクリプトはこちらの GitHub リポジトリからダウンロードでき、複数のプラットフォームに対応しています。
前提条件
このプログラムには Python 3.6 以上が必要です。Linux、Windows、および MacOS 上で実行できます。まず Python 環境をインストールするか更新します。次に、以下に従って GitHub リポジトリのクローンを作成します。
スクリプトを実行する
ヘルプを表示するにはオプション「-h」を使用します。入力ログファイルを指定し、必要に応じて時間の範囲または出力ファイルの名前を指定します。デフォルトでは、「logparser.out」という名前の出力ファイルが現在のディレクトリに作成されます。
hb_report は SUSE が提供するユーティリティです。関連のある Pacemaker ログをすべて 1 つのパッケージに集めます。パスワードを使わない SSH によるログインがクラスタノード間で構成されている場合、すべての情報がすべてのノードから収集されます。それ以外の場合は、クラスタノードごとに hb_report を実行します。
sosreport も同様のユーティリティです。RedHat から提供されており、システムのログファイル、設定の詳細、システム情報を収集します。Pacemaker ログも収集されます。sosreport はクラスタノードごとに実行します。
また、単一のシステムログや Pacemaker ログを対象としたパースも行えます。
Windows の場合には、Python ファイル「logparser.py」を実行します。
次に、ログパーサーを使って得られた結果から構成される出力情報を解析する必要があります。
出力情報の理解
出力ログにはさまざまな情報が書き込まれています。たとえばフェンシングやリソースに関するアクション、障害、Corosync サブシステムのイベントなどが含まれますが、これらに限定されません。
フェンシング アクションの理由と結果
クラスタノードに対するフェンシング アクション（再起動）の例を以下に示します。ノードがクラスタから離れたことがアクションの理由になっています。その後のログエントリを見るとフェンシング操作が正常に行われた（「OK」）ことが分かります。
クラスタ リソースの管理を目的とした Pacemaker のアクション
以下に示す例では、クラスタ リソースに影響を及ぼす複数のアクションが実行されています。異なるクラスタノードの間でリソースの移動が行われたり、特定のクラスタノードでリソースの停止が行われたりしています。
リソース操作で発生する障害
Pacemaker によるクラスタ リソースの管理は、モニタリング、開始、停止のような、リソースに対する操作の呼び出しによって行われます。操作は対応するリソース エージェント（シェルや Python スクリプト）で定義されています。ログパーサーは障害が発生した操作のログエントリに対するフィルタリングを行います。仮想 IP リソースが稼働されていないために失敗したモニタリング操作の例を以下に示します。
リソース エージェント、フェンス エージェントの警告とエラー
リソース エージェントやフェンス エージェントによって、操作の詳細なログが書き込まれます。リソース操作が失敗した場合に根本原因を特定するにはエージェント ログが有効です。ログパーサーは、すべてのエージェントを対象にしたエラーログのフィルタリングを行います。さらに SAP HANA エージェントを対象とした警告ログのフィルタリングも行います。
Corosync の通信エラーまたは障害
Corosync は、クラスタノードが互いに通信をする際に使用するメッセージング レイヤです。Corosync を使用したノード間の通信が失敗すると、フェンシング アクションがトリガーされることがあります。
以下に示す例では、Corosync からのメッセージが繰り返し送信され、最終的には一方のクラスタノードがクラスタを離れたというエラーレポートが出力されています。
次に示す例では、定められた時間内に Corosync トークンの受信が行われず、最終的に、一方のクラスタノードがクラスタを離れたというエラーレポートが Corosync によって出力されています。
移動しきい値への到達とリソースの強制的な切り離し
あるリソースで発生する失敗の回数が、定められた移動しきい値（パラメータ「migration-threshold」）に達すると、そのリソースは強制的に別のクラスタノードに移動させられます。
あるクラスタノードでリソースの起動が失敗した場合、失敗の発生回数は無限大に更新され、暗黙的に移動しきい値に達したことになり、強制的にリソースが移動させられます。ロケーションの制約があるために他のクラスタノードでリソースが稼働できない場合、または他に使用可能なクラスタノードがない場合、リソースは停止され、どこにも稼働できなくなります。
手作業によるリソースの移動に起因するロケーション制約の追加
ロケーション制約のうち接頭辞「cli-prefer」または「cli-ban」の付いたものはすべて、ユーザーがクラスタ リソースの移動または禁止コマンドをトリガーした場合に暗黙的に追加されます。そうした制約は、リソースの移動後に解除される必要があります。リソースに制約が課され、リソースを稼働できるノードが限定されるからです。以下に示す例では、ロケーション制約「cli-ban」が作成され、ロケーション制約「cli-prefer」が削除されています。
クラスタ / ノード / リソースのメンテナンス / スタンバイ / 管理モードへの変更
ログパーサーは、クラスタ、クラスタノード、またはリソースでメンテナンス コマンドが発行されると、ログエントリに対するフィルタリングを行います。以下に示す例では、クラスタのメンテナンス モードが有効化され、ノードがスタンバイ状態に設定されています。
結論
この Pacemaker ログパーサーは、使用している高可用性クラスタで発生する重大イベントを表示する、1 つの単純化されたビューを提供します。さらに Google Cloud カスタマーケア チームによるサポートが必要な場合は、診断ファイルを収集するためのガイドを参照し、サポートケースを登録してください。
Pacemaker を使って Google Cloud で SAP を実行する方法の詳細については、このシリーズでこれまでに掲載した以下のブログを参照してください。
- Senior Technical Solution Engineer, Cherry Legler
