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

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

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

連載「日常運用・障害試験で役立つ！監視・通知・トラブルシューティング術」の第一弾では、システムの異常をいち早く察知する「目」と「声」――すなわちログ監視とメール通知の極意について解説しました。これらを正しく設定することで、管理者は現場に張り付くことなく、システムの「異変」を掴むことができるようになります。

しかし、異変を察知した後に必ず必要となるのが、現在の詳細なステータスを確認し、必要に応じてリソースの切り替えやリカバリー操作を行うための「窓（管理画面）」です。LifeKeeperにおいて、この「窓」が曇ったり、開かなくなったりすることは、有事の際の判断を遅らせる致命的な問題に繋がります。

設計・構築が終わり、いよいよ本番運用という段階で、次のような「困った！」に直面したことはないでしょうか。「GUIを起動しようとしても、砂時計が回ったままで数分待たされる……」「ログイン画面までは出るのに、なぜかノードの操作が一切受け付けられない」「Javaのバージョンやブラウザの制約に振り回され、管理端末の用意だけで一苦労している」

これらの問題の多くは、ネットワークの動的ポートの挙動や名前解決の優先順位、あるいはクライアント側の実行環境といった、LifeKeeper本体の設定とは少し異なる「外側の要因」に起因しています。

第二弾となる今回は、旧来のJavaベースのGUIから、最新のWeb Management Console (LKWMC)まで、「管理画面にまつわるトラブルシューティング」を徹底解説します。画面が開かない時の切り分けフローから、運用を楽にする次世代インターフェースへの移行ポイントまで、実例を元にした解決策を提示します。

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

▶【日常運用・障害試験で役立つ！監視・通知・トラブルシューティング術 #1】異変を逃さない！メール通知の「落とし穴」と、原因を読み解くログ監視の極意 – TechHarmony

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

はじめに

今回のテーマは、LifeKeeperの操作の要である「GUI」および「LKWMC」です。

LifeKeeperには強力なCLI（コマンドラインインターフェース）が備わっていますが、クラスタ全体の依存関係を直感的に把握し、ミスのない操作を行うためには、GUI（グラフィカルユーザーインターフェース）の存在が欠かせません。

しかし、GUIはネットワーク通信、Java Runtime Environment (JRE)、Webブラウザ、X11といった多くの要素が組み合わさって動作するため、トラブルが起きた際の切り分けが難しい領域でもあります。また、近年ではJavaのライセンス変更やブラウザの進化に伴い、HTML5ベースの「LKWMC」への移行も進んでいます。

本記事では、サポートに寄せられた実際の事例をベースに、以下の3点を学べる構成にしています。

接続トラブルの解消： 「ポートは開いているはずなのに動かない」原因となる動的ポートの正体。
パフォーマンス改善： GUIの起動を劇的に遅くさせる「名前解決」と「メトリック」の設定ミス。
次世代への備え： LKWMC導入時のネットワーク設計と、サポート環境の考え方。

この記事を読み終える頃には、画面越しの「困った！」に対して、自信を持って調査・対応できるようになっているはずです。

今回の「困った！」事例

管理画面にまつわるトラブルは、その「見え方」によって原因が大きく異なります。今回は、サポートによく寄せられる3つの代表的なシナリオをご紹介します。

【ケースA：通信編】「ログインはできるのに、画面の中が動かない！？」

事象の概要： Webブラウザ経由でLifeKeeper GUIを立ち上げたところ、ログイン画面は表示され、ログイン自体も成功する。しかし、いざ画面が開くとノードが「Disconnected」や「×」印のまま、リソースの操作が一切できない。
発生時の状況： 新規構築中の環境で、セキュリティポリシーに基づきファイアウォール（F/W）を設定。マニュアル通りにポート（TCP 778等）を解放したはずなのに、一向に管理画面が正常に機能しない。再インストールを試みても事象が改善せず、八方塞がりの状態。
原因究明のプロセス： サポートファイル（lksupport）を確認したところ、ノード間ではコミュニケーションパスが「DEAD（切断）」状態になっていた。さらに、ログには「SSL証明書の期限切れ」や「名前解決の失敗（NXDOMAIN）」といった複数のエラーが混在。しかし、これらを一つずつ解消しても、依然としてブラウザ上の操作が反映されない。
判明した根本原因： 実は、LifeKeeper GUI（Java RMI）の動作には、「1024番以降の動的ポート（エフェメラルポート）」による双方向通信が必要でした。お客様環境では、入り口となる特定のポートのみを許可し、それ以外の高位ポートがF/Wで遮断されていたため、「画面（ガワ）は表示されるが、中身（データ）が流れてこない」という半死状態に陥っていたのです。

特定のポート（778番）を開けるだけでは不十分です。
高位ポートの双方向通信を許可する必要があります。

【ケースB：環境・設定編】「GUIがとにかく重い、あるいは表示すらされない」

事象の概要：
（1）AWS環境でGUIの起動を試みると、画面が表示されるまでに3〜4分かかる。
（2）別の環境でCLIからlkGUIappを叩くと、エラーが出て画面が立ち上がらない。
発生時の状況：
（1）では「起動さえしてしまえば動くが、毎回待たされるので運用に支障がある」という状態。
（2）では「HeadlessException」というエラーが出て、X11経由の表示が拒否される。
原因究明のプロセス：
（1）の遅延については、Javaが利用するNICの優先順位（メトリック）に着目。AWSのように複数のNIC（管理用と業務用など）がある場合、Javaが意図しない経路で通信を試みている可能性が浮上。
（2）については、DISPLAY環境変数の設定ミスが疑われました。
判明した根本原因：
（1）の遅延原因は、OS上のNICメトリックの設定でした。メトリックが「自動」になっていると、通信の優先順位が不安定になり、GUIの初期化処理（イクイバレンシリストの取得等）でタイムアウト待ちが発生します。これを固定値に設定することで解消。
（2）については、リモート接続時のX11転送設定およびDISPLAY変数が適切でなかったため、GUIアプリが「出力先の画面が見つからない」と悲鳴を上げていたことが分かりました。

メトリックの設定ミスやDNS逆引き不可により、通信が迷子になり、
約3分のタイムアウト待ちが発生して遅延につながります。

【ケースC：次世代編】「LKWMC（Web管理コンソール）に切り替えたいけれど……」

事象の概要： Javaの管理に限界を感じ、HTML5ベースの新世代管理画面「LKWMC」の導入を検討。しかし、導入にあたって「どのポートが必要か？」「Windows Serverから操作できるのか？」といった疑問が次々と湧き上がる。
発生時の状況： マニュアルを読み込むも、これまでのJava GUIとは全く異なるアーキテクチャに混乱。「GUIサーバー（ポート5110）」と「REST APIサーバー（ポート5000）」という、新しい登場人物の役割と通信経路を整理する必要がありました。
原因究明のプロセス： 最新版（v9.8.x時点）ではLKWMCは「オプション製品」としての位置づけであり、インストールメディアへの同梱有無や、検証済みOSの範囲（Windows 10/11のみ等）など、従来の「Webブラウザ接続」とは異なる制約を確認。
判明した根本原因： LKWMCは、クライアント⇔ノード間だけでなく、ノード⇔ノード間のREST通信（TCP 5000）も必須となります。これを考慮せずに設計すると、「片方のノードの情報しか見えない」といった事態を招きます。また、Windows Serverからの操作は「技術的には可能だが、動作保証外」といった、製品サポートポリシーの境界線を理解することが重要だと判明しました。

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

管理画面のトラブルで時間を浪費しないためには、「疎通・設定・環境」の3つのレイヤーで正しく設計・確認を行うことが重要です。

■ 解決策と学び：GUIトラブルを防ぐためのチェックリスト

トラブル発生時に確認すべきポイントを、優先度の高い順に整理しました。構築時や環境変更時のセルフチェックシートとしても活用してください。

確認レイヤー	チェック項目	解決のためのアクション
ネットワーク	[ ] 1024番以降のポート	Java GUI（RMI通信）を利用する場合、TCP 778番だけでなく、1024番以降の動的ポート（エフェメラルポート）を「双方向」で許可してください。
ネットワーク	[ ] LKWMC専用ポート	次世代管理画面（LKWMC）を利用する場合、クライアント⇔ノード間のTCP 5110番、およびノード⇔ノード間のTCP 5000番を解放してください。
名前解決	[ ] 正引き・逆引きの徹底	`/etc/hosts` や DNS を利用し、全てのノード名からIP、IPからノード名が即座に解決できることを確認してください（`host`コマンド等でNXDOMAINが出ないこと）。
OS・設定	[ ] NICメトリックの固定	複数のNICがある環境（特にAWSなどのクラウド）では、管理用NICのインターフェースメトリックを小さな値（高優先）に固定し、Javaの通信経路を安定させてください。
実行環境	[ ] X11/DISPLAY変数	Linux CLIから `lkGUIapp` を起動する場合は、`export DISPLAY=（接続元IP）:0.0` の設定と、TeraTerm等での「X11転送」が有効か確認してください。

■ 再発防止のための設計ガイドライン

1. 「名前解決」は両方向（正引き・逆引き）が鉄則
LifeKeeperは、ノード間の信頼関係やGUIの表示においてホスト名を多用します。hostsファイルに設定していても、OSの優先度（nsswitch.conf）やDNSの逆引き設定が不完全だと、GUIの起動に数分のタイムアウト待ちが発生します。構築時には「pingが通るからOK」で済ませず、必ず相互の名前解決を確認しましょう。

2. IP/ホスト名変更後は「命綱」の再確認を
環境変更でIPやホスト名を変えた際、lk_chg_value コマンドによる設定変更だけで満足してはいけません。事例にあったように、コミュニケーションパスのステータスが「DEAD」になっていないか、古い設定が残っていないかを必ず確認してください。管理画面が動かない原因の多くは、この「足元の通信」の不備にあります。

3. 「動作可能」と「サポート対象」の境界線を知る
LKWMCのように、最新の技術を導入する際は製品マニュアルの「動作環境」を厳密にチェックしてください。「Windows Serverでもブラウザから開けた」という事実があっても、それが「公式にサポートされた構成」でなければ、本番環境でのリスクとなります。特に次世代ツールへの移行期は、サポートポリシーの確認をセットで行うのがプロの設計です。

■ ベストプラクティス：困った時の「切り分けフロー」

画面が正常でないと感じたら、以下の順序で切り分けを行うのが最短ルートです。

CLIで現状確認： lcdstatus コマンドを実行。ここでノードが「Alive」なら、問題は「GUIの表示系」に絞られます。
ログでエラーを特定： /var/log/lifekeeper.log や /var/log/steeleye-lighttpd/access.log を確認。SSLエラーやポート拒否の記録がないか探します。
公式ドキュメントの活用：
- Java GUIの動作が遅い時の対処法（SIOSポータル）
- LifeKeeperが使用するポート一覧