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

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

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

LifeKeeperを導入し、システムの高可用性を実現する上で、アプリケーションリソースの保護は非常に重要な要素です。しかし、アプリケーションARKは、その特性ゆえに、設定のわずかな見落とし、予期せぬ通信障害、そしてバージョンアップによる仕様変更など、多岐にわたる要因で『困った』事態に直面することがありますよね。

本連載企画「LifeKeeper の『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策」では、まさにそんな「なぜかアプリケーションが切り替わらない」「エラーが出て起動できない」といった、LifeKeeper運用の現場で実際に発生した問い合わせ事例を基に、トラブルの原因、究明プロセス、そして何よりも『再発防止策』に焦点を当てて深掘りしていきます。今回の第三弾では、アプリケーションARK特有の「落とし穴」に焦点を当て、その解決と再発防止の鍵を探ります。

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

はじめに

LifeKeeperの心臓部とも言えるアプリケーションリソースの保護は、システムの高可用性を実現する上で不可欠です。専用ARKから汎用ARKまで多岐にわたりますが、その複雑さゆえに設定ミスや連携アプリケーション側の要因で予期せぬトラブルが発生しがちです。本記事では、LB Health Check、MySQL、IIS、そしてGeneric ARKを用いたJP1/Baseのリソース構築・運用で実際に発生したサポート事例を元に、アプリケーションARK特有の「落とし穴」を深掘りします。通信障害、バージョン間の仕様変更、ホスト名の制約、スクリプトの依存性など、様々な角度から原因と対策を学ぶことで、アプリケーションの安定稼働と再発防止につなげるヒントを提供します。

その他の連載企画は以下のリンクからどうぞ！

【リソース起動・フェイルオーバー失敗の深層 #1】EC2リソースが起動しない！クラウド連携の盲点とデバッグ術 – TechHarmony
【リソース起動・フェイルオーバー失敗の深層 #2】ファイルシステムの思わぬ落とし穴：エラーコードから原因を読み解く – TechHarmony

今回の「困った！」事例

ケース1：ロードバランサーとの連携トラブル – ヘルスプローブの落とし穴

lbhcリソース作成中にエラー(140251)が発生する、LB Health Checkリソース作成時のエラーについて

事象の概要: LifeKeeper for Windows環境でLB Health Checkリソース作成・起動時にエラーが発生し、リソース作成に失敗。ロードバランサーからの正常性プローブがLifeKeeper側で受け取れない状況に陥りました。
発生時の状況: LBHCリソース作成後のリソース起動でロードバランサーとの通信がタイムアウト（エラーコード140251）しました。Azure内部ロードバランサーからの通信は許可済みと認識されていたにも関わらず、プローブが到達しませんでした。また、LifeKeeperのホスト名に小文字が混在している環境でした。
原因究明のプロセス: 初期にはHC_TIMEOUTの調整やデバッグログ取得を試みましたが、デバッグログからも最終的にプローブを受け取れていない状況が判明。さらに、ホスト名に小文字が含まれることがLifeKeeper for Windowsの既知の不具合であり、リソース情報取得エラーの原因であることが明らかになりました。
判明した根本原因: 1. ロードバランサーからの正常性プローブがLifeKeeper側で受け取れていない通信経路上の問題、および 2. LifeKeeper for Windowsのホスト名が小文字混在であったことによるリソース情報取得エラーが複合的に発生していました。

ケース2：データベースARK特有の設定ミス – MySQLのパスワードとログパスの罠

MySQLリソース作成時のエラーについて

事象の概要: MySQLリソース作成時に「Invalid parameter value」エラーが発生し、さらにその後log-binのパスに関するエラーが発生。リソース作成が成功しませんでした。
発生時の状況: my.cnf内のMySQLユーザーパスワードに「$」が含まれており、ダブルクォーテーションで囲んでいましたがエラーが解消されませんでした。また、log-binパラメータがファイル名のみで指定されていました。既存システム（LifeKeeper v9.3.2）ではファイル名のみで動作していましたが、新システム（LifeKeeper v9.9.0）ではエラーとなりました。
原因究明のプロセス: サポートとのやり取りにより、パスワードの特殊文字（「$」）を正しく扱うためにはシングルクォーテーションで括る必要があること、およびlog-binのパスはLifeKeeper for Linux v9.6以降ではフルパス指定が必須になったことが判明しました。
判明した根本原因: 1. MySQLユーザーパスワードに特殊文字（「$」）が含まれる場合の記述ルール（シングルクォーテーションで括る）の不理解、および 2. LifeKeeper for Linuxのバージョンアップに伴うMySQL ARKの仕様変更（log-binのフルパス指定必須化）への追従不足が原因でした。

ケース3：WebサーバーARKの特性理解不足 – IISの拡張前処理スクリプト

IISリソース拡張前処理スクリプト実行時のエラーメッセージについて

事象の概要: IISリソース作成時の拡張前処理スクリプト実行中にエラーメッセージが発生しましたが、その後の拡張はエラーなく実行され、IISリソースの作成自体は完了しました。
発生時の状況: 既にボリュームリソースが拡張済みであったにも関わらず、IISリソースの拡張前処理スクリプト内で再度ボリューム拡張を試みていました。
原因究明のプロセス: サポートの確認により、このエラーは既にボリュームリソースが拡張されているため発生する、運用上問題のない情報メッセージであることが確認されました。
判明した根本原因: 拡張前処理スクリプトが、既に拡張済みのボリュームに対し再度拡張処理を行おうとしたため発生する、意図されたエラーメッセージであり、IISリソースの拡張自体には影響がありませんでした。

ケース4：Generic ARK利用時の注意点 – スクリプト依存とサポート範囲

Generic ARK リソース (JP1/Base)における quickCheck の仕組みについて

事象の概要: Generic ARK（JP1/Base）におけるquickCheckの動作について問い合わせ。ネットワークメンテナンスに伴う通信断の影響で、quickCheckが失敗しOSが再起動しました。
発生時の状況: quickCheckスクリプト内で名前解決を使用しており、通信断により名前解決ができずquickCheckが失敗したと推測されました。
原因究明のプロセス: 問い合わせたGeneric ARKがサポート対象外であることが判明し、お客様が作成したスクリプトの内容に依存するため、LifeKeeper製品としての詳細な案内はできませんでした。
判明した根本原因: サポート対象外のGeneric ARKを利用しており、スクリプトの内容（名前解決への依存）が起因する問題であったため、LifeKeeper製品としての根本原因は特定できず、スクリプト作成者による詳細確認が必要でした。

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

具体的な解決策:

LB Health Checkリソース関連: ネットワークセキュリティグループ(NSG)やファイアウォールで、ILBのIPアドレスからのプローブ用ポートへの通信を確実に許可する。HC_TIMEOUTの設定値を環境に合わせて調整する。LifeKeeper for Windowsを導入するサーバーのホスト名は、すべて大文字で設定する。
MySQLリソース関連: MySQLユーザーのパスワードに特殊文字（「$」など）を使用する場合は、必ず「’」（シングルクォーテーション）で文字列全体を括って設定する。my.cnf内のdatadir、log-bin、log-tcパラメータは、LifeKeeper for Linux v9.6以降では共有ディスク上の絶対パス(フルパス)で指定する。
IISリソース関連: IISリソース作成時の拡張前処理スクリプト実行中に、既に拡張済みのボリュームに関するエラーメッセージが表示された場合、その後のIISリソース拡張が成功していれば、運用上問題ないメッセージとして認識する。
Generic ARK関連: 利用するアプリケーションがLifeKeeperのサポート対象であることを事前に確認する。Generic ARKで利用するスクリプトは、作成者が動作内容（特に外部依存性）を詳細に把握し、デバッグログ出力やエラーハンドリングを適切に実装する。

再発防止策（チェックリスト形式）:

ARKのサポート範囲と互換性確認: 専用ARK利用時もGeneric ARK利用時も、対象アプリケーションとLifeKeeperのバージョンがサポートされているか、サポートマトリクスで事前に確認する。
OS/LifeKeeperバージョンアップ時の仕様変更確認: OSやLifeKeeper本体のバージョンアップを行う際は、リリースノートやドキュメントを詳細に確認し、ARK固有の仕様変更（例: MySQL ARKのlog-binパス指定）がないか確認する。
ARK固有の設定ファイル（例: my.cnf）の厳格な管理: アプリケーションARKが参照する設定ファイルは、LifeKeeperの要件（例: パスワードの記述ルール、パスの絶対指定）に沿って適切に設定・管理する。
通信経路とセキュリティ設定の徹底確認: ロードバランサーのヘルスプローブやアプリケーション間の通信など、LifeKeeperが監視・利用する通信経路について、ファイアウォールやネットワークセキュリティグループの設定を構築前に徹底的に確認し、必要なポートが解放されていることを保証する。
命名規則（ホスト名・ユーザー名など）の遵守: LifeKeeperが動作する環境では、ホスト名やユーザー名にLifeKeeperの制約（例: Windows版でのホスト名の大文字制約）がないか事前に確認し、命名規則を遵守する。
Generic ARK利用時のスクリプト詳細把握: Generic ARKを利用する場合は、スクリプトの作成者が動作内容（特に外部依存性、名前解決など）を詳細に把握し、デバッグログ出力やエラーハンドリングを適切に実装する。
LifeKeeperログの日常的な監視とエラーコード理解: LifeKeeperログに記録されるエラーメッセージやエラーコードの意味を正確に理解し、日常的に監視することで異常を早期に検知・対処できる体制を整える。

ベストプラクティス:

設計段階での詳細な要件定義: アプリケーションリソースを保護する際は、LifeKeeperの要件、アプリケーションの要件、ネットワークの要件を詳細に定義し、設計書に落とし込む。特に通信要件や設定ファイルのパス、パスワードポリシーは入念に検討する。
公式ドキュメントの積極的活用: 各ARKの管理ガイド、処理概要、リリースノート、動作環境リストなど、SIOSが提供する最新の公式ドキュメントを常に参照し、推奨設定や既知の制約を把握する。
検証環境での徹底的なテスト: OSアップデート、LifeKeeperバージョンアップ、アプリケーション設定変更など、システム構成に影響を与える変更は、必ず本番適用前に検証環境でLifeKeeperリソースを含むシステム全体の動作テストを実施する。
運用フローとチェックリストの確立: リソース作成、変更、OSアップデートなどの主要な運用タスクについて、具体的な手順と確認項目を記した運用フローとチェックリストを確立し、ヒューマンエラーを防止する。
サポート活用と情報共有: 疑問点やエラー発生時には、積極的にSIOSサポートに問い合わせ、得られた知見はチーム内で共有しナレッジとして蓄積する。

まとめ

本記事では、LB Health Check、MySQL、IIS、Generic ARKといったアプリケーションリソースに関連する様々なトラブル事例を取り上げました。
これらの事例から、アプリケーションARKの安定稼働には、LifeKeeper本体やARKの仕様への深い理解に加え、連携するOSやアプリケーションの設定、そして基盤となるネットワーク通信環境の綿密な確認が不可欠であることが明らかになりました。
特に、OSやLifeKeeperのバージョンアップに伴う仕様変更への追従、設定ファイル記述ルールへの注意、そしてGeneric ARK利用時のスクリプト内容への詳細な把握が、トラブルを未然に防ぐ鍵となります。日々の運用でこれらの点を意識し、公式ドキュメントの活用と検証を徹底することで、「困った！」を「できた！」に変え、より堅牢なクラスタ環境を構築・維持できるでしょう。