EC2Rescue for Linux を使用してオペレーティングシステムレベルの問題をトラブルシューティングする方法を教えてください。

簡単な説明

EC2Rescue for Linux は、Amazon EC2 Linux インスタンスの問題の診断やトラブルシューティングに役立つツールです。Linux 用 EC2Rescue は Amazon EC2 Linux インスタンスで実行し、オペレーティングシステムレベルの問題を修正します。Linux 用 EC2Rescue では、詳細なログ、システム使用状況レポート、設定ファイルも収集し、さらなる分析を実施できます。

Linux 用 EC2Rescue が対処する一般的なシナリオ:

• vmstat、iostat、mpstat などのシステム使用率レポートを収集する。
• syslog、dmesg、アプリケーションエラーログ、SSM ログなどのログと詳細を収集する。
• 非対称ルーティングやルートデバイスラベルの重複など、システムの問題を検出する。
• OpenSSH ファイルのアクセス許可の修正、既知の問題のあるカーネルパラメータの無効化など、システムの問題を自動的に修正します。

システム要件

EC2Rescue for Linux では、以下の前提条件を満たす Amazon EC2 Linux インスタンスが必要です。

サポートされているオペレーティングシステム

• Amazon Linux 2
• Amazon Linux 2016.09+
• SLES 12+
• RHEL 7+
• Ubuntu 16.04+

ソフトウェア要件

• Python 2.7.9+ または 3.2+

注: Linux 用 EC2 シリアルコンソールを有効にしている場合は、それを使用して、サポートされている Nitro ベースのインスタンスタイプのトラブルシューティングを行うことができます。シリアルコンソールは、起動の問題、ネットワーク設定、および SSH 設定に関する問題のトラブルシューティングに役立ちます。シリアルコンソールは、正常に動作するネットワーク接続を必要とすることなく、インスタンスに接続します。シリアルコンソールには、Amazon EC2 コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用してアクセスできます。

シリアルコンソールを使用する前に、アカウントレベルでコンソールにアクセス権を付与します。その後、IAM ユーザーにアクセス権を付与する AWS Identity and Access Management (IAM) ポリシーを作成します。また、シリアルコンソールを使用するすべてのインスタンスには、パスワードベースのユーザーを 1 つ以上含める必要があります。インスタンスが到達不能で、シリアルコンソールへのアクセスを設定していない場合は、解決方法のセクションの手順に従います。Linux 用 EC2 シリアルコンソールの設定の詳細については、EC2 シリアルコンソールへのアクセスを設定するをご参照ください。

注: AWS CLI コマンドの実行時にエラーが発生した場合は、AWS CLI の最新バージョンを使用していることを確認してください。

解決方法

EC2Rescue for Linux を使用して、到達不能な Amazon EC2 Linux インスタンスをトラブルシューティングするには、次の手順を実行します。

1.    同じ Amazon Machine Image (AMI) を使用しかつ障害のあるインスタンスと同じアベイラビリティーゾーンで、仮想プライベートクラウド (VPC) で新しい Amazon EC2 インスタンスを起動します。新しいインスタンスは「レスキュー」インスタンスになります。または、同じ AMI を使用しかつ障害のあるインスタンスと同じアベイラビリティーゾーンにある場合は、アクセスできる既存のインスタンスを使用できます。

2.    障害のあるインスタンスから Amazon Elastic Block Store (Amazon EBS) ルートボリューム (/dev/xvda または /dev/sda1) をデタッチします。後で再添付するときに同じであることを確認できるように、デバイス名を書き留めます

3.    レスキューインスタンスに、セカンダリデバイス (/dev/sdf) として EBS ボリュームを添付します。

4.    SSH を使用してレスキューインスタンスに接続します。

5.    ルートになり、lsblk を使用して正しいデバイス名を特定し、これをプロセス全体で使用できるように保存します。

$ sudo -i
# lsblk
# rescuedev=/dev/xvdf1

注: デバイス (/dev/xvdf1) は、別のデバイス名でレスキューインスタンスに添付されている場合があります。lsblk コマンドを使って、使用可能なディスクデバイスとマウントポイントを表示し、正しいデバイス名を確認してください。

6.    使用に適した暫定的なマウントポイントを選択し、マウントポイントが確実に存在する状態で、まだ使用されていなければ、/mnt を使用します。

# rescuemnt=/mnt
# mkdir -p $rescuemnt

7.    添付されているボリュームからルートファイルシステムをマウントします。

# mount $rescuedev $rescuemnt

注: ボリュームのマウントに失敗した場合は、dmesg | tail を確認してください。ログで UUID の競合が示されている場合は、オプションの -o nouuid を使用します。

8.    特別なファイルシステムをマウントし、ルートディレクトリ (chroot) を新しくマウントしたファイルシステムに変更します。

# for i in proc sys dev run; do mount --bind /$i $rescuemnt/$i ; done
# chroot $rescuemnt

9.     オフラインの Linux ルートボリュームに EC2Rescue for Linux ツールをダウンロードし、インストールします。

# curl -O https://s3.amazonaws.com/ec2rescuelinux/ec2rl.tgz
# tar -xf ec2rl.tgz

10.    ヘルプファイルを一覧表示して、インストールを確認します。

# cd ec2rl-<version_number>
# ./ec2rl help

11.    すべてのモジュールを実行するには、オプションを指定せずに EC2Rescue for Linux を実行します。

# ./ec2rl run

12.    /var/tmp/ec2rl で結果を表示します。

# cat /var/tmp/ec2rl/*/Main.log | more

13.    結果に基づいて、サポートされているモジュールの修正を有効にします。

# ./ec2rl run --remediate

14.    修正が完了したら、chroot を終了し、セカンダリデバイスをマウント解除します。

# exit
# umount $rescuemnt/{proc,sys,dev,run,}

注: マウント解除ができない場合は、レスキューインスタンスを停止または再起動して、マウント解除のクリーンを有効にする必要があります。

15.    レスキュー EC2 インスタンスからセカンダリボリューム (/dev/sdf) をデタッチし、/dev/xvda または /dev/sda1 (ルートボリューム) として元のインスタンスに添付します。これはステップ 2 の作業と同じになるよう確実に行います。

16.    EC2 インスタンスを起動し、インスタンスが応答していることを確認します。

注: AWS Systems Manager Automation ドキュメントを使用して、接続の問題をトラブルシューティングすることもできます。詳細については、チュートリアル: 到達不可能なインスタンスでの EC2Rescue ツールの実行をご参照ください。AWSSupport-ExecuteEC2Rescue ドキュメントは、EC2Rescue for Linux を使用するために通常必要な手順を自動化するように設計されています。これらの手順は、Systems Manager のアクション、AWS CloudFormation のアクション、および AWS Lambda 関数の組み合わせです。

追加のトラブルシューティング

• Linux インスタンスの一般的な復旧手順については、ホストコンピュータに障害が発生した場合のインスタンスの復旧をご参照ください。Windows インスタンスの場合は、「接続できないインスタンスのトラブルシューティング」をご参照ください。
• インスタンスのルートデバイスが Amazon EBS-backed ボリュームの場合は、インスタンスを停止してから起動してみてください。詳細については、「インスタンスの停止と起動」をご参照ください。
• インスタンスストアでバックアップされているインスタンスの場合、インスタンスのカスタム AMI を作成すると、その AMI をバックアップとして使用してインスタンスを復元できる場合があります。所有する AMI から新しいインスタンスを作成する手順については、「古いインスタンスの起動ウィザードを使用してインスタンスを起動する」をご参照ください。
• 場合によっては、EBS ボリュームの I/O アクセスが無効になっていることがあります。これにより、インスタンスにアクセスできなくなる可能性があります。こうした場合を特定しトラブルシューティングする方法については、「Auto-Enable IO ボリューム属性の操作」をご参照ください。
• SSH キーペアを紛失した場合は、Systems Manager Automation および AWSSupport-ResetAccess ドキュメントを使用してリセットできます。

---

関連情報

EC2Rescue と Amazon EC2 Systems Manager Automation を使用して、障害のあるインスタンスを復旧する