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

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

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

連載「クラスタ健全性維持の要」の第一弾では、クラスタの命運を分ける最後の審判を下す「番人」――Quorum/Witnessの重要性について解説しました。共有ディスク構成やクラウド環境における最適な「番人」の選び方、そしてLCMログを意識した運用のポイントは、もうチェックいただけましたでしょうか。

「番人」が正しい審判を下すためには、ノード同士が互いの状態を常に正確に把握していなければなりません。その情報をやり取りする「神経系」とも呼べる命綱が、今回のテーマである「コミュニケーションパス」です。

設計・構築の現場では、次のような疑問やトラブルがよく聞かれます。 「AWSのようなクラウド環境では、ネットワークが抽象化されているのだから、わざわざパスを複数に分ける必要はないのではないか？」 「マニュアル通りに設定を進めているつもりなのに、なぜかGUI上でノードが正しく認識されず、増殖してしまう……」

これらは、物理環境からクラウドへの移行に伴う設計思想の変化や、OSの基本的な名前解決の設定といった、意外な「落とし穴」に起因することが少なくありません。

本連載カテゴリ5の第二弾となる今回は、クラスタの健全性を根底で支える「コミュニケーションパス」にスポットを当て、AWS環境でのベストプラクティスから、構築時にハマりやすいケアレスミスの防ぎ方までを深掘りします。

はじめに

LifeKeeperにおいて、ノード間の生存を確認し合う「コミュニケーションパス」は、システムの可用性を左右する極めて重要な要素です。もしこの通信が不安定になれば、両ノードが同時に「自分が本番機だ」と判断してしまう「スプリットブレイン」を引き起こし、システムのサービス停止やデータの不整合を招く恐れがあるからです。

特にクラウド環境においては、インフラの冗長性が提供元によって担保されている反面、ネットワークレイヤーがブラックボックス化されています。そのため、「どこまで冗長設計をすべきか」という判断が難しくなっているのも事実です。

今回の記事では、サポートによく寄せられる3つの事例をベースに、コミュニケーションパスの「あるべき姿」を考えます。

1. クラウドでの設計指針： 他の通信に影響されない「パス専用サブネット」を推奨する理由
2. S3 Witnessの深層： 内部での読み書き動作（AWS CLI）と、異常を検知するためのログ監視
3. 構築現場のトラブル： GUIの挙動がおかしくなる「/etc/hosts」設定の罠

前回解説した「番人（Quorum/Witness）」が、いざという時に正しく機能するための土台作りを、本稿を通じて学んでいきましょう。

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

▶【クラスタ健全性維持の要 #1】クラスタの番人Quorum/Witness：その設定、本当に必要？ 正しく選んで正しく守る設計術 – TechHarmony

今回の「困った！」事例

本連載ではお馴染みとなりましたが、今回も実際にサポートデスクへ寄せられた「切実な」お問い合わせをベースに、3つのケーススタディを見ていきましょう。

ケース①：クラウドに「専用パス」は必要？ ネットワーク設計の迷い

• 事象の概要： AWS環境でのクラスタ構築において、コミュニケーションパス（ハートビート）専用のサブネットやENI（仮想ネットワークインターフェース）を設けるべきか、それとも業務通信と相乗りで良いのかという設計上の疑問。
• 発生時の状況： 「クラウドでは物理層が抽象化されているのだから、ENIを分けても裏側で混ざっているのではないか？」「わざわざ分けるメリットや推奨される理由は何か？」といった、コストや構成の簡素化を優先したい構築担当者からの相談。
• 原因究明のプロセス： サポートチームでは、LifeKeeperの基本原則である「可用性の最大化」の観点から調査。物理環境・クラウド環境を問わず、コミュニケーションパスが業務通信（データ転送やバックアップ）の影響を受けるリスクを再確認しました。
• 判明した根本原因： クラウド環境といえど、ネットワーク帯域は有限です。高負荷な通信が発生した際、同一サブネット/ENIを利用していると、ハートビートのパケットが遅延・喪失し、両ノードが健全であるにもかかわらず「相手が死んだ」と誤認してフェイルオーバー（スプリットブレイン状態）を引き起こすリスクがあることが改めて浮き彫りになりました。
• 具体的な解決策： 可能な限り「コミュニケーションパス専用のサブネット」を用意し、業務通信とは物理・論理的に分離することを推奨。また、パスを複数構成する場合も、それぞれを別のサブネットに配置することで、単一のネットワーク障害に巻き込まれない構成をベストプラクティスとして提示しました。

---

ケース②：見落としがちな「S3 Witness」の死活監視

• 事象の概要： AWS環境での第三者判定として「S3 Witness」を導入したが、S3へのアクセスが失敗した際にどのように検知すればよいか分からないという悩み。
• 発生時の状況： 通常のリソース障害やノード障害についてはイベントメール通知を設定しているが、S3への書き込み失敗（Witnessデバイスとしての異常）が通知イベントに含まれていないことに気づき、監視漏れを懸念した状況。
• 原因究明のプロセス： S3 Witnessの内部動作を精査。LifeKeeperは内部的に「AWS CLI」を利用してS3上のオブジェクト（QWKオブジェクト）を読み書きしていますが、この通信自体はLifeKeeperのリソース監視対象（ARK）ではないため、標準のメール通知には引っかからない仕様であることが判明しました。
• 判明した根本原因： S3への疎通不可や権限不足による書き込み失敗は、システムログ（lifekeeper.log）には記録されるものの、LifeKeeperの「イベント通知」のトリガーには設定されていませんでした。
• 具体的な解決策： ログ監視ツールを用い、特定のログメッセージ（例：ERROR:qwk:::135851）を検知対象に加えることを提案。「ハートビートが生きている限りクラスタは継続するが、いざという時の審判（Witness）が不在にならないよう、ログベースでの監視が不可欠である」という運用指針を共有しました。

---

ケース③：GUIに自ノードが増殖！？ 構築を阻む「hosts」の罠

• 事象の概要： コミュニケーションパスの作成操作中、GUI上で自ノードが複数表示されたり、Javaエラーが発生して操作不能になったりする不可解な挙動。
• 発生時の状況： 稼働系ノードから待機系ノードを「Remote Server」として追加しようとしたところ、Addボタンを押すたびに自ノードのアイコンがGUI上に増殖。反対に待機系から操作するとエラーポップアップが出てしまい、コミュニケーションパスが作成できない状態。
• 原因究明のプロセス： Javaの不具合やLifeKeeperの再インストールを検討する前に、ネットワークの基本設定を確認。特に、ノード間の名前解決を担う /etc/hosts ファイルの中身を精査しました。
• 判明した根本原因： /etc/hosts のループバックアドレス（127.0.0.1 および ::1）の行に、自分自身だけでなく「相手ノードのホスト名」が記載されていました。これにより、LifeKeeperが通信相手を特定しようとした際に「自分自身」に繋がってしまい、内部的な整合性が崩れてGUIが異常な挙動を示していました。
• 具体的な解決策： /etc/hosts のループバック行から相手ノード名を削除し、正しいIPアドレスとホスト名の対応を追記。この修正により、GUI上でのノード認識が正常化し、無事にコミュニケーションパスが作成できました。

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

コミュニケーションパスとQuorum/Witnessは、一度構築してしまえば「触る機会」は少ないかもしれません。しかし、その安定性が損なわれた時の影響は甚大です。現場での教訓を、具体的な対応策に落とし込んでいきましょう。

具体的な解決策：障害発生時にどう向き合うか

• 通信異常を疑う前に「名前解決」を疑う： GUIの挙動がおかしい、対向ノードが追加できないといった初期構築時のトラブルの多くは、通信経路そのものよりも /etc/hosts やDNSの設定といった「名前解決」に起因します。まずは ping [ホスト名] で意図したIPアドレスに紐付いているかを再確認するのが鉄則です。
• 「相乗り」による遅延を甘く見ない： もしコミュニケーションパスと業務通信を共用している環境で、理由のないフェイルオーバー（誤検知）が発生した場合は、ネットワークの負荷状況を調査してください。バックアップ処理やバッチ処理などの高負荷通信が、ハートビートの「邪魔」をしていないかを切り分ける必要があります。

再発防止策：構築・運用チェックリスト

今後、同様のトラブルを起こさないために、設計・構築・運用の各フェーズで以下のチェックリストを活用してください。

フェーズ	確認項目	チェック内容
設計	パスの物理・論理分離	パスを2本以上持ち、かつ業務通信とは異なるサブネット/ENIに配置しているか？
構築	hostsファイルの整合性	127.0.0.1 や ::1 の行に相手ノード名が含まれていないか？
構築	S3アクセスの権限	AWS CLIがS3バケットに対して適切に読み書きできるIAM権限を持っているか？
運用	S3 Witnessのログ監視	lifekeeper.log 内の ERROR:qwk:::135851 を検知対象に含めているか？
運用	定期的な疎通確認	障害試験時に、片方のパスを切断してもクラスタが健全性を維持できるか確認しているか？

ベストプラクティス：クラスタ健全性維持の極意

1. 「神経系（パス）」の独立性を保つ クラウド環境では、ネットワークの構築が容易な分、つい構成を簡素化（共有）してしまいがちです。しかし、可用性の本質は「単一障害点の排除」と「相互干渉の防止」にあります。たとえ仮想的なネットワークであっても、コミュニケーションパスには「専用の通り道（サブネット）」を与えることが、予期せぬフェイルオーバーを防ぐ最大の防御策となります。

2. 「見えない異常」をログで可視化する S3 WitnessなどのクラウドサービスをWitnessデバイスとして利用する場合、LifeKeeperの標準イベントメール通知だけでは「判定役の不在」に気づけません。

   • 重要監視ログ： ERROR:qwk:::135851（S3へのオブジェクト読み込み失敗） こうした、通知対象外だが「システムの健全性に関わるログ」を運用監視に組み込むことで、初めて真の冗長化が完成します。

3. OSの基本設定に立ち返る LifeKeeperはOSの上で動くミドルウェアです。/etc/hosts の書き方ひとつで、クラスタ管理機能は容易に混乱します。LifeKeeperの高度な機能を疑う前に、OSレベルのネットワーク設定や名前解決が「クラスタ構成のセオリー」に則っているかを常に意識しましょう。

まとめ

前回と今回の二回にわたり、「クラスタ健全性維持の要」としてQuorum/Witnessとコミュニケーションパスについて深く掘り下げてきました。

第一弾で紹介した「番人（Quorum/Witness）」が正しく、かつ迅速に判断を下せるかどうかは、今回解説した「命綱（コミュニケーションパス）」がいかに安定して情報を伝達できているかにかかっています。

クラウド環境においては、物理的な制約が見えにくい分、ついネットワーク設計を簡略化したくなるかもしれません。しかし、今回見てきた事例の通り、「通信の分離（専用サブネット）」や「OSレベルでの正しい名前解決（/etc/hosts）」といった基本をおろそかにすると、いざという時にクラスタが正常に機能せず、予期せぬダウンタイムを招くことになります。

また、S3 Witnessのように、標準の通知機能だけでは捉えきれない「見えない異常」があることも忘れてはなりません。ログID 135851 の監視のように、製品の特性を理解した一歩先の運用設計が、システムの信頼性を一段上のレベルへと引き上げます。

「神経系（パス）」が正しく情報を伝え、「番人（Quorum）」が正しく判断する。このシンプルな構造を、基本に忠実な設計と監視で支えること。それが、変化の激しいクラウド時代においても揺るぎない、HAクラスタの健全性を維持するための唯一の近道です。

次回予告

さて、カテゴリ5までで、LifeKeeperの「リソース」「OS・環境」「ネットワーク・判定ロジック」といった、クラスタの土台となる部分を網羅してきました。

次回の新シリーズ（カテゴリ6）では、いよいよ「日々の運用」にフォーカスします。構築が終わった後に、運用担当者が最も長く付き合うことになる「監視・通知・ログ」の極意を伝授します。

【次回テーマ（予定）】 カテゴリ6：日常運用・障害試験で役立つ！監視・通知・トラブルシューティング術 「記事案1：イベントメール通知とログ活用の極意：障害を早期発見・早期解決する」

「通知メールの件数が多すぎて重要なエラーが埋もれてしまう……」「ログのどこを見れば原因にたどり着けるのか？」といった、現場の悩みに応える実践的なアプローチを紹介します。

次回の記事も、どうぞお楽しみに！

📚 本連載のバックナンバー
過去のトラブル事例と解決策もぜひあわせてご覧ください！

カテゴリ1：リソース起動・フェイルオーバー失敗の深層
▶【リソース起動・フェイルオーバー失敗の深層 #1】EC2リソースが起動しない！クラウド連携の盲点とデバッグ術 – TechHarmony
▶【リソース起動・フェイルオーバー失敗の深層 #2】ファイルシステムの思わぬ落とし穴：エラーコードから原因を読み解く – TechHarmony
▶【リソース起動・フェイルオーバー失敗の深層 #3】設定ミス・通信障害・バージョン違いの深層と再発防止策 – TechHarmony

カテゴリ2：OS・LKバージョンアップで泣かないために
▶【OS・LKバージョンアップで泣かないために #1】OSバージョンは変えていないのに！？カーネル更新の「落とし穴」と互換性の真実 – TechHarmony
▶【OS・LKバージョンアップで泣かないために #2】「設定が消えた！？」「亡霊IPが警告！？」を防ぐロードマップ：単純な上書き更新に潜む落とし穴と回避策 – TechHarmony

カテゴリ3：クラウド環境特有の落とし穴
▶【クラウド環境特有の落とし穴 #1】良かれと思った自動復旧が仇に！？AWS環境（EC2/Route53/S3）でハマる構成と回避策 – TechHarmony
▶【クラウド環境特有の落とし穴 #2】オンプレ感覚の「同一サブネット」はNG!?Azure環境のネットワーク要件とQuorum設計の最適解 – TechHarmony

カテゴリ4：DataKeeper：ミラー同期とデータ保護の核心
▶【DataKeeper：ミラー同期とデータ保護の核心 #1】同期中だから切り替わらない！？フェイルオーバーの「絶対条件」と性能評価の罠 – TechHarmony
▶【DataKeeper：ミラー同期とデータ保護の核心 #2】スナップショットから戻したのに動かない！？リストア後の「整合性」確保とバックアップ連携の盲点 – TechHarmony

カテゴリ5：クラスタ健全性維持の要
▶【クラスタ健全性維持の要 #1】クラスタの番人Quorum/Witness：その設定、本当に必要？ 正しく選んで正しく守る設計術 – TechHarmony

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