【リソース起動・フェイルオーバー失敗の深層 #1】EC2リソースが起動しない！クラウド連携の盲点とデバッグ術

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

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

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

LifeKeeper の運用は、システムの安定稼働を支える重要な役割を担いますが、時には「なぜか動かない」「エラーが出てフェイルオーバーできない」といった『困った』事態に直面することもありますよね。そんな時、サポートに問い合わせて解決した経験は、多くの方にとって貴重な財産となっているはずです。

本連載企画「LifeKeeper の『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策」では、実際に LifeKeeper のサポートに寄せられた問い合わせ事例を基に、よくあるトラブルの原因、究明プロセス、そして何よりも『再発防止策』に焦点を当てて深掘りしていきます。

はじめに

LifeKeeper for Linux を利用した高可用性クラスタにおいて、EC2 リソースの起動やフェイルオーバーはシステムの安定稼働に不可欠な要素です。しかし、予期せぬエラーで EC2 リソースが起動せず、クラスタの自動切り替えが機能しない、手動での起動もできないといった「困った！」状況に直面することは少なくありません。

本連載の第一弾では、この「EC2 リソースが起動しない」という問題に焦点を当てます。特に、AWSとの連携部分における見落としがちな設定や、トラブルシューティングのプロセス、そして何よりも「再発させない」ための具体的な対策と学習ポイントを、実際のサポート事例を交えて解説します。この記事を読み終える頃には、EC2 リソース起動失敗の原因を特定し、自信を持って対処できるようになるでしょう。

今回の「困った！」事例

LifeKeeper の EC2 リソースが起動しないという問題は、一見すると同じ事象に見えても、その裏には様々な原因が潜んでいます。今回は、LifeKeeper のバージョンアップ後に EC2 リソースが起動しなくなったという、特に見落としがちな事例を深掘りします。

事象の概要:

待機系サーバにて LifeKeeper for Linux のバージョンアップ後、待機系サーバで EC2 リソースの起動（スイッチオーバー時の起動処理）に失敗する事象が発生しました。LifeKeeper for Linux のバージョンアップ前の稼働系での EC2 リソース起動（スイッチバック）は成功しており、特定のバージョンアップが関連している可能性があります。

発生時の状況:

あるお客様環境で、LifeKeeper for Linux のバージョンを v9.5.2 から v9.7.0 へアップデートする作業を実施しました。バージョンアップ後、待機系サーバで EC2 リソースの起動テストを行ったところ、これまで正常に動作していた EC2 リソースが突如起動に失敗。エラーメッセージからは、AWS メタデータへのアクセスに問題がある可能性が示唆されました。しかし、LifeKeeper for Linux のバージョンアップしていない稼働系サーバでは同じ EC2 リソースが正常に起動できる状況であり、その場での原因の特定が出来ませんでした。

原因究明のプロセス:

サポートチームによる調査の結果、以下の点が判明しました。

  1. LifeKeeper for Linux v9.7.0 へのアップデートと IAM 権限の関係: お客様に設定していただいていた既存の IAM ロールの権限リストは v9.5.2 のものであり、v9.7.0 へのアップデートに伴い、LifeKeeper for EC2 Recovery Kit が必要とする IAM 権限が変更されている可能性が浮上しました。 サポートチームは、LifeKeeper の公式ドキュメント「Recovery Kit for EC2 の要件」を参照するよう促しました。
    • v9.7.0 のルートテーブル構成に必要な権限:
      • ec2:DescribeRouteTables
      • ec2:ReplaceRoute
      • ec2:DescribeNetworkInterfaceAttribute
      • ec2:ModifyNetworkInterfaceAttribute
    • v9.5.2 の権限（比較用）:
      • ec2:DisassociateAddress
      • ec2:DescribeAddresses
      • ec2:AssociateAddress
      • ec2:DescribeRouteTables
      • ec2:ReplaceRoute 

この比較から、特に v9.6.0 以降で「送信元/送信先チェック」の対応を行うために、いくつかの権限が追加・変更されていることが確認されました。

  1. アップデート時のドキュメント参照の重要性: LifeKeeper 製品のバージョンアップ時には、今回のように IAM 権限をはじめとする各 Recovery Kit の「要件」「設定」「考慮事項」が変更されることがあります。これらの変更情報は、製品の新機能、バグ情報、各 Recovery Kit のドキュメントといった複数の箇所に記載されているため、全体を網羅的に確認することが重要です。今回の事例は、アップデート作業の際には、関連する公式ドキュメント群を丹念に確認し、最新の要件を漏れなく把握することの重要性を改めて示すものでした。これにより、予期せぬトラブルを未然に防ぐことができます。

判明した根本原因:

LifeKeeper for Linux のバージョンアップ（v9.5.2 から v9.7.0）に伴い、EC2 Recovery Kit が必要とする IAM ロールの権限が不足していたことが根本原因でした。特に v9.6.0 で「送信元/送信先チェック」の対応が行われたことにより、必要な権限セットが変更されており、この変更がお客様の既存の IAM ロールに反映されていなかったため、EC2 リソースの起動に失敗していました。

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

EC2リソースが起動しないという問題は、一度解決しても再発させないための予防策が非常に重要です。

具体的な解決策:

上記事例の解決策は以下の通りです。

  • EC2リソースで操作するための IAM 権限の付与: LifeKeeper for EC2 Recovery Kit v9.7.0 の要件に合致するよう、関連する IAM ロールに不足している EC2 関連の権限（ec2:DescribeNetworkInterfaceAttribute、ec2:ModifyNetworkInterfaceAttribute など）を追加しました。これにより、EC2 リソースは正常に起動するようになりました。

再発防止策とトラブルシューティングのヒント（チェックリスト形式）:

EC2 リソース起動失敗は多様な原因で発生するため、以下のチェックリストを参考に、日々の運用やトラブルシューティングにご活用ください。

  1. IAM ロール・権限に関する確認:
    •  LifeKeeper バージョンアップ時の権限要件確認: LifeKeeper for Linux や各 Recovery Kit をバージョンアップする際は、必ず最新バージョンの公式ドキュメントで「Recovery Kit for EC2 の要件」を確認し、必要な IAM 権限が変更・追加されていないか確認しましたか？
    •  IAM ロールへの最小権限付与: LifeKeeper が EC2 リソース操作に利用するIAMロールには、必要な権限が過不足なく付与されていますか？（最小権限の原則を遵守しつつ、不足がないか確認）
    •  一時的な資格情報の有効期限: 一時的な資格情報を使用している場合、その有効期限は適切に設定されていますか？
  2. AWS CLI と AWS サービスに関する確認:
    •  AWS CLI の実行確認: LifeKeeper が内部で実行する AWS CLI コマンド（aws ec2 replace-route など）が、OS で手動実行した際に正常に完了しますか？
    •  AWS 側エラーコードの確認: AWS CLI の実行が失敗する場合、AWS 側から返されるエラーコード（例: エラー253）の内容を AWS サポートに確認し、AWS 側の設定（ルートテーブル、セキュリティグループなど）に見直すべき点がないか確認しましたか？
    •  AWS サービスヘルスダッシュボード: 利用している AWS リージョンで、EC2 や IAM、VPC などの関連サービスに障害が発生していないか、AWS サービスヘルスダッシュボードを確認しましたか？
  3. 環境設定と競合に関する確認:
    •  デバッグログの有効化と取得: EC2 リソース起動失敗時は、LifeKeeper のデバッグログを有効にして、詳細なエラー情報を収集しましたか？（具体的な設定方法はサポートに確認）
    •  セキュリティ製品との競合: LifeKeeper および DataKeeper のインストールフォルダ（通常/opt/LifeKeeper、/usr/local/bin/nbd-client、/usr/local/bin/nbd-server等）が、ウイルス対策ソフトや証跡管理ソフトの監視対象から除外されていますか？（競合によりリソース起動失敗や誤検知が発生する可能性があります）
    •  環境変数の確認: perform_action コマンドなど、LifeKeeper 関連コマンドを特定のユーザーで実行する場合、そのユーザーの環境変数（特に http_proxy、https_proxy などのプロキシ設定）が LifeKeeper の GUI 実行時（通常 root）と一致しているか、または EC2 リソースの起動に必要な設定が適切に行われていますか？（例: root ユーザーで sudo -i を使用すると環境変数が引き継がれないケースなど）

ベストプラクティス:

  • 公式ドキュメントの熟読と定期的な確認: LifeKeeper のバージョンアップ時だけでなく、定期的に Recovery Kit for EC2 の「要件」「設定」「考慮事項」セクションを公式ドキュメントで確認しましょう。最新の情報に常にキャッチアップすることが、未然のトラブル防止につながります。
  • 最小権限の原則と定期的な見直し: IAM ロールには、LifeKeeper の運用に必要な最小限の権限のみを付与する「最小権限の原則」を適用し、定期的にその権限セットが最新の要件に合致しているか見直しましょう。
  • LifeKeeper と外部ツールとの共存設定: ウイルス対策ソフトや証跡管理ソフトを導入する際は、事前に LifeKeeper のインストールディレクトリを除外設定することを徹底しましょう。これにより、不要な競合による問題を回避できます。
  • AWS CLI の安定稼働: LifeKeeper は内部で AWS CLI を利用するため、基盤となる OS 環境で AWS CLI が安定して動作することが重要です。プロキシ設定やネットワーク疎通など、AWS CLI が AWS エンドポイントと正常に通信できることを確認しましょう。

まとめ

LifeKeeper の EC2 リソース起動失敗は、クラウド環境と連携するシステムならではの複雑さがあります。しかし、本記事でご紹介したように、バージョンアップに伴う IAM 権限の変更、AWS CLI のエラー、環境変数の設定不備など、その原因は明確に特定できます。

特に重要なのは、「常に最新のドキュメントを確認する習慣」と、「発生したエラーメッセージやデバッグログから原因を特定するプロセス」です。そして、一度解決した問題は二度と起こさないための「再発防止策チェックリスト」を活用することで、より堅牢なシステム運用が可能になります。

日々の運用でこれらのポイントを意識し、今回学んだトラブルシューティングと再発防止策を実践することで、EC2 リソースの「困った！」を「できた！」に変え、安定した高可用性クラスタを維持できるようになるでしょう。

次回予告

次回の連載では、「リソース起動・フェイルオーバー失敗の深層」の第二弾として、「IP リソースが切り替わらない！ネットワーク設定の落とし穴と診断術」と題し、LifeKeeper の IP リソースに関するトラブルシューティングと、ネットワーク設定に関するベストプラクティスを深掘りします。どうぞお楽しみに！

詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
タイトルとURLをコピーしました