LifeKeeperの『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策

こんにちは、SCSKの前田です。

いつも TechHarmony をご覧いただきありがとうございます。

連載「クラスタ健全性維持の要」の第二弾では、ノード同士を結ぶ命綱――「コミュニケーションパス」の設計と、AWS環境におけるベストプラクティスについて解説しました。クラスタの「神経系」を正しく整えることが、安定稼働の第一歩であることをお伝えできたかと思います。

しかし、どんなに頑強な神経系を備えたクラスタでも、中で何が起きているのかを外から把握できなければ、有事の際に迅速な対応はできません。異常をいち早く察知する「目（監視）」と、それを管理者に伝える「声（通知）」が備わって初めて、システムは真に守られていると言えるのです。

設計・構築を終え、いざ運用や障害試験のフェーズに入ると、次のような「困った！」に直面することがよくあります。
「障害を発生させたのに、なぜかイベントメール通知が飛んでこない……」
「フェイルオーバーの開始をログで検知したいが、どのメッセージをキーワードにすればいいのか？」
「Linux版の監視には慣れているが、Windows版の監視タイミングや挙動がよく分からない」

これらは、LifeKeeperとOS側のメール機能との連携仕様や、OSによる監視構造の違いといった、マニュアルの行間にある「実務上のポイント」を掴むことで解消できます。

新連載カテゴリ6の第一弾となる今回は、日々の運用や障害試験で欠かせない「イベントメール通知」と「ログ監視」にスポットを当てます。メールが届かない時の切り分け方法から、確実に障害を捉えるためのログキーワード選定まで、サポート事例を元にした「現場で使える知識」を深掘りします。

💡 前回の記事（カテゴリ6 第二弾）はこちら！

▶【クラスタ健全性維持の要 #2】途絶えた命綱が「分離」を招く。コミュニケーションパス設計の定石とAWS環境の最適解 – TechHarmony

はじめに
今回の「困った！」事例
「再発させない！」ための対応策と学び
まとめ
次回予告

はじめに

本記事では、LifeKeeperの運用フェーズにおいて最も重要といっても過言ではない「監視と通知」をテーマに扱います。

クラスタシステムを導入する目的は「止まらないシステム」を作ることですが、それと同時に「万が一止まった時に、即座に状況を把握し、ダウンタイムを最小化すること」も同じくらい重要です。
本記事を通じて、以下の3つのポイントをマスターすることを目指します。

１．確実な通知設定の極意： LifeKeeperとOS側のメールソフト（mailx/s-nail）の役割分担を理解し、設定ミスを防ぐ。
２．ログ監視のキーワード選定：リソース異常やフェイルオーバーなど、事象ごとに「どのログを見るべきか」を明確にする。
３．OSによる仕様差の理解： Linux版とWindows版のリソース監視の仕組み（QC/DC）の違いを知り、正しい試験計画を立てられるようにする。

まずは、サポートセンターによく寄せられる「メールが通知されない」というトラブル事例から、その原因と対策を見ていきましょう。

今回の「困った！」事例

本セクションでは、サポートセンターに寄せられた実際のお問い合わせをベースに、運用・試験フェーズで陥りやすい3つのトラブルシナリオを紹介します。

【ケース①】メール通知設定の盲点：届かない原因と「フィルタリング」の可否

事象の概要： LifeKeeperのイベントメール通知を有効にするため、両ノードで /etc/default/LifeKeeper の LK_NOTIFY_ALIAS を設定。しかし、試験運用を始めると「特定のノードからメールが届かない」というトラブルや、「不要な通知メールが多く、必要なものだけを選別したい」という要望が発生しました。
発生時の状況：
1. 届かない問題： 1号機は正常だが、2号機側では lifekeeper.log に contains invalid byte や No recipients specified というエラーが出てメールが送信されない。
2. 選別したい要望： 「フェイルオーバーの通知は欲しいが、日常的な起動・停止の通知は不要なので、特定のイベントだけ除外したい」という相談が寄せられた。
原因究明のプロセス： サポートでの調査により、以下の2点が明らかになりました。
1. 外部依存の壁： LifeKeeperは自身でSMTP通信を行うのではなく、OSにインストールされた mail コマンド（mailxやs-nail）を呼び出しているだけである。そのため、宛先書式の解釈はOS側のソフトに依存する。
2. 仕様の壁： LifeKeeperには、特定のイベントだけを通知対象から除外する（フィルタリングする）機能は備わっていない。
判明した根本原因：
1. 2号機でメールが届かなかったのは、OS側のメールソフトが宛先リストの「カンマ区切り」を正しく解釈できていなかったため。
2. 通知されるイベントの種類はシステムで固定されており、LifeKeeper側での「一部除外」設定は不可能。「通知を受け取る側（メーラーや運用監視ソフト）」での振り分け対応が必要であるという仕様上の制限があった。

【ケース②】ログ監視キーワードの罠：フェイルオーバーしたはずなのにアラートが飛ばない！

事象の概要： 運用監視ツールでLifeKeeperのログ（/var/log/lifekeeper.log）を監視し、フェイルオーバー発生時にアラートを上げる設計。しかし、リソース障害を擬似的に発生させてフェイルオーバーさせた際、期待していたログキーワードが検知されず、アラートが発報されなかった。
発生時の状況： 担当者は「フェイルオーバー開始」を意味する以下のキーワードを監視対象にしていました。 011064: FAILOVER RECOVERY OF MACHINE <ホスト名> STARTED しかし、リソース（IPやディスク）の異常による切り替え時には、このログは出力されていませんでした。
原因究明のプロセス： サポートへの確認により、「ノード障害」と「リソース障害」で出力されるログメッセージが明確に使い分けられていることが判明しました。先述の 011064 は、対向ノードがダウンした（コミュニケーションパスが切れた）際の「ノード障害用」のメッセージであり、自ノード内でリソースが異常になった際の「リソース障害用」の切り替えメッセージは別物だったのです。
判明した根本原因： 「フェイルオーバー」という一言の事象でも、そのトリガーによって出力されるメッセージIDが異なる。リソース異常による切り替えを確実に捉えるには、以下のキーワード（メッセージID：004790）が必要でした。 004790:removing resource "リソース名" for transfer

障害の種類（トリガー）によって出力されるログが異なるため、監視設計では両方のログIDを監視対象に設定することが重要です。

【ケース③】Windows版の疑問：クイックチェックとディープチェック、どちらを信じればいい？

事象の概要： Linux版LifeKeeperの経験が豊富なエンジニアが、初めてWindows版の設計を担当。「クイックチェック（QC）」と「ディープチェック（DC）」という2種類の監視があるが、どちらが失敗した時にフェイルオーバーが動くのか、その関係性が分からず設計が進められない。
発生時の状況： 「QCが失敗してもDCが動いていればセーフなのか？」「それとも両方失敗した時に初めて切り替わるのか？」など、監視仕様の組み合わせパターンが不明瞭で、基本設計書の「リソース監視」の項目を埋められない状況でした。
原因究明のプロセス： Windows版の内部構造を確認したところ、Linux版（一定間隔で単一の監視処理が走る）とは異なり、QCとDCは完全に独立したタイマーで動作していることが分かりました。
判明した根本原因： Windows版の仕様として、「QCまたはDCのどちらか一方が異常を検出し、ローカルリカバリに失敗した時点」でフェイルオーバーが実行されます。つまり、「QCは通っているがDCでだけ異常が出る」というケースでも、LifeKeeperは即座に異常と判断し、保護動作を開始します。この独立した監視構造を理解していないと、意図しないタイミングでのフェイルオーバーに驚くことになります。

「再発させない！」ための対応策と学び

事例から学んだ教訓を整理し、確実な運用管理を実現するためのポイントを解説します。

■ 具体的な解決策：障害発生時にまず確認すべきこと

もし「メールが届かない」「ログが検知できない」といった問題が発生したら、以下の順序で切り分けを行いましょう。

メール通知の切り分け：
- LifeKeeperのログ（lifekeeper.log）に mail returned [エラーコード] が出ていないか確認します。
- LifeKeeperを介さず、OSのコマンドラインから直接 mail コマンドでテストメールを送信します。これで届かなければ、OS側のパッケージ設定（s-nail 等）やSMTPサーバー側の問題です。
ログ監視の切り分け：
- 監視対象としているキーワードが「どの障害パターン」のものか再確認します。「ノードダウン」を「IPリソースの停止」で検知しようとしていないか、メッセージID（6桁の数字）を確認するのが確実です。

■ 再発防止策：構築・試験時のチェックリスト

今後同様のトラブルを起こさないために、以下のチェックリストを納品前や試験工程に組み込むことを推奨します。

カテゴリ	チェック項目	確認内容
通知	全ノードでの送信テスト	稼働系・待機系すべてのノードから手動で外部へメール送信が可能か。
通知	宛先書式の確認	`LK_NOTIFY_ALIAS` のアドレスがカンマ区切りで正しく認識されているか（OSのs-nail等の仕様に合わせる）。
通知	環境変数の設定	外部SMTP利用時、`/etc/default/LifeKeeper` に `MAILRC` の定義が必要な構成ではないか。
監視	トリガー別ログ確認	「ノード障害（電源断）」と「リソース障害（サービス停止）」の両方の試験を実施し、ログの違いを把握したか。
設計	Windows監視仕様の把握	Windows版の場合、QC（クイック）とDC（ディープ）の両方の監視タイミングを設計書に反映しているか。

■ ベストプラクティス：効率的な監視・通知の設計

運用の手間を減らしつつ、確実に異常を捉えるための「プロの技」を紹介します。

1. ログ監視キーワードは「ARK名」と「メッセージID」をセットにする
単純な「ERROR」というキーワードでは、何が起きたかの判別に時間がかかります。

推奨： ERROR:ip:quickCheck や ERROR:filesys:quickCheck このようにリソース種別（ARK名）まで含めて監視することで、通知を受けた時点で「ネットワークの異常だ」「ディスクの異常だ」と即断できます。

2. 監視すべき主要ログメッセージ一覧（逆引き表）
試験時に「このログが出ればOK」という基準を持つための対照表です。

検知したいイベント	推奨キーワード / メッセージID	備考
リソース異常検知	`ERROR:[ARK名]:quickCheck`	監視処理が異常を捉えた瞬間
リソース切替開始	`004790:removing resource...`	自ノードでのリソース障害によるFO
ノード障害検知	`010466:COMMUNICATIONS [ホスト名] FAILED`	相手との通信が途絶えた（心停止）
ノード障害によるFO開始	`011064:...FAILOVER...STARTED`	相手が死んだと判断して起動を開始
DK同期異常（Linux）	`WARN:dr:comm_path_down:`	DataKeeperの同期経路切断

3. 通知のフィルタリングは「受信側」で集約する
ケース➀にあったように、LifeKeeper側で特定の通知だけを止めることはできません。運用上「この通知は不要」と判断されるものは、メーラーの自動振り分け機能や、運用監視サーバー側（ZabbixやHinemos等）のフィルタ条件で制御するのがクラスタ運用の定石です。

まとめ

今回は、LifeKeeperの運用において「異変をいち早く捉える」ための重要項目である「イベントメール通知」と「ログ監視」について解説しました。

本記事のポイントを振り返ると、以下の通りです。

メール通知の主導権はOSにある： LifeKeeperはあくまで「通知のきっかけ」を作る役割です。設定がうまくいかない時は、まずOSコマンドラインからの送信テストを実施し、OS側のメールソフト（mailx/s-nail）の挙動を確認することが解決への近道です。
ログ監視は「メッセージID」と「ARK名」で精度を上げる： 単純なキーワード監視ではなく、メッセージID（004790等）やリソース種別（ip, filesys等）を組み合わせることで、事象の特定が劇的に早まります。
通知のフィルタリングは「受け手」の仕事： LifeKeeper側でイベントを絞り込むことはできません。運用に合わせて、監視サーバーやメーラー側での柔軟な振り分け設定を活用しましょう。
Windows版は「QC/DCの独立性」を意識： クイックチェックとディープチェックのどちらかが失敗すればリカバリが走ります。Linux版との仕様差を理解した上で、障害試験の計画を立てることが重要です。

「監視と通知」は、システムが発する「健康診断の結果」のようなものです。これらを正しく設計・理解しておくことで、万が一の障害時にも「何が起きているか分からない」という不安を払拭し、自信を持ってトラブルシューティングに臨むことができるようになります。

日々の運用で、今回ご紹介したチェックリストをぜひ活用してみてください。