[Linux] AWS 環境における、よくあるお問い合わせ

  • 更新
フォローする

Linux 環境における、EC2 Recovery Kit、Route53 Recovery Kit を用いた環境での、
よくあるお問い合わせを以下にご紹介させていただきます。

▼ 目次（クリックで開閉）


(1）EC2 リソースの quickCheck で "129110:Could not get the Elastic Network Interface ID for (NIC)" のエラーが発生した場合

【原因】
EC2 リソースの quickCheck（監視処理）においてこのエラーが発生した場合、curl コマンド
による AWS のインスタンスメタデータへの接続において、ENI ID の情報取得に失敗しています。

【LifeKeeper 内部での実行コマンド】
LifeKeeper は ENI ID の情報を取得するために、内部で以下のコマンドを実行しています。
curl コマンドにて、AWS のメタデータの取得に失敗した要因までは、LifeKeeper 観点では
確認することが出来ないため、お手数とはなりますが、該当時間帯に AWS のメタデータへの
アクセス状況に問題等が発生していなかったか、AWS 観点でご確認いただけますようお願い
いたします。

ENI IDの取得（取得したMACアドレスを使用）

curl --connect-timeout 5 -s -S http://169.254.169.254/latest/meta-data/network/interfaces/macs/＜MAC Address＞/interface-id

MACアドレスの取得は以下コマンドにて取得を行います。

ip -o link show eth0 | grep 'link/ether'


(2）EC2 リソースの quickCheck で "129157:curl call failed (err=7)..." のエラーが発生した場合

【原因】
err=7 は Failed to connect to host（接続拒否・失敗）を意味し、メタデータへの接続が
タイムアウト等で失敗したことを示します。

【対策】
一時的なアクセス遅延などを許容し、不要なフェイルオーバーを防ぐために、バージョンに
応じて LifeKeeper の設定ファイル（/etc/default/LifeKeeper）に以下のパラメータを設定・調整します。

 

v9.9.0 以前の場合：
LK_CURL_TIMEOUT : curl コマンドのタイムアウト時間を延伸します（デフォルトは5秒）。

v9.9.1 以降の場合：
LK_CURL_TIMEOUT : タイムアウト時間の指定。
LK_CURL_ATTEMPT_NUM : メタデータ取得失敗時のリトライ回数を指定します（デフォルトは4回）。


(3）AWS CLI に対してタイムアウトを延伸するように指示があった場合

【対策】
EC2 リソースや Route53 リソースの quickCheck でエラーが発生し、AWS サポート等から AWS CLI 
のタイムアウト延伸を指示された場合、LifeKeeper v9.9.1 以降であれば /etc/default/LifeKeeper
に以下のパラメータを設定できます。

AWSCLI_CONNECT_TIMEOUT : コネクション確立のタイムアウト時間。
AWSCLI_READ_TIMEOUT : 応答待ちのタイムアウト時間。


(4）LifeKeeper での AWS CLI 実行において、プロキシを設定したい場合

【対策】
AWS のサービスエンドポイントへアクセスする際にプロキシを経由させる必要がある場合、
/etc/default/LifeKeeper ファイルに以下の環境変数を追記します。

HTTP_PROXY
HTTPS_PROXY
NO_PROXY (※ メタデータ 169.254.169.254 などをプロキシ経由にしないための除外設定として必ず指定してください)


(5）EC2 リソース、Route53 リソースの作成に失敗する場合（デバッグログ取得手順）

【調査・デバッグ手順】
リソース作成失敗の原因を特定するため、以下の手順でエラー出力の詳細を記録するデバッグログを取得します。

1. LifeKeeper の設定ファイル /etc/default/LifeKeeper を vi コマンド等
   で開き、ファイル内の最下部に次のパラメータを追記して保存します。

　VERBOSE_AWS_ROLE_CHECK=/var/log/aws_role_check.log

2. 次のコマンドを実行し、LifeKeeper のログ出力を強化します。

 EC2 リソースの場合

/opt/LifeKeeper/bin/flg_create -f debug_ec2

 Route53 リソースの場合

/opt/LifeKeeper/bin/flg_create -f debug_route53


3. リソースの作成等、意図的にエラー事象を再現させます。

4. 出力された /var/log/aws_role_check.log を回収します。

5. サポートログ（lksupport）の取得 次のコマンドを実行し、LifeKeeper のログを
   取得します。　 

/opt/LifeKeeper/bin/lksupport


6. 手順1 にて追記した VERBOSE_AWS_ROLE_CHECK のパラメータを削除
　 またはコメントアウト）して保存します。
 

7. 次のコマンドを実行し、LifeKeeper のログ出力を標準に戻します。

 EC2 リソースの場合 

/opt/LifeKeeper/bin/flg_remove -f debug_ec2

 Route53 リソースの場合

/opt/LifeKeeper/bin/flg_remove -f debug_route53


8. 「手順4で取得した aws_role_check.log」および「手順5で取得した lksupport ファイル」
　 をサポート窓口までお送りください。


(6）S3 を使用した Storage Quorum（QWK_STORAGE_TYPE=aws_s3）の要件は？

バケットの配置リージョン: データの整合性と可用性を保つため、LifeKeeper クラスタが
動作している EC2 インスタンスと異なるリージョンの S3 バケットを使用することが強く推奨されています。

必要な IAM 権限: S3 オブジェクトの読み書きのため、以下の権限が付与されている必要があります。

s3:PutObject
s3:GetObject
s3:ListBucket
s3:GetBucketLocation

 

—————————————————————————————————
改訂履歴
[改訂日：2026年8月3日] 初版作成