EC2 Linux インスタンスにアクセスできず、ステータスチェックの一方または両方が失敗するのはなぜですか?

所要時間3分

Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスにアクセスできず、ステータスチェックの一方または両方に失敗します。

短い説明

Amazon EC2 は以下の 2 つのステータスチェックを使用して EC2 インスタンスの状態を監視しています。

システムステータスチェック

システムステータスチェックはインスタンスの基盤となるハードウェアの問題を検出します。ネットワーク、ハードウェア、またはソフトウェアの問題のために基盤となるハードウェアが応答しない、または接続できない場合、システムステータスチェックは失敗します。

インスタンスステータスチェック

インスタンスステータスチェックの失敗は、インスタンスにアクセスできないことを示しています。次の一般的な問題のせいで、インスタンスステータスチェックが失敗します。

オペレーティングシステム (OS) の起動に失敗します
ボリュームの適切なマウントに失敗します
CPU およびメモリの枯渇
カーネルパニック
ネットワーク障害

**警告:**以下の一部の解決策は、インスタンスを停止して起動する必要があります。インスタンスを停止して起動する前に、以下の条件に注意してください。

インスタンスストアボリュームに格納されているデータは、インスタンスが停止すると失われます。インスタンスを停止する前に、データを必ずバックアップしてください。Amazon Elastic Block Store (Amazon EBS) バックアップボリュームとは異なり、インスタンスストアボリュームは一時的なもので、データの永続性をサポートしていません。
Amazon EC2 が起動時または開始時にインスタンスに自動的に割り当てた静的パブリック IPv4 アドレスは、停止して開始すると変更されます。インスタンスの停止時に変わらないパブリック IPv4 アドレスを保持するには、Elastic IP アドレスを使用します。

詳細については、「インスタンスを停止するための前提条件」を参照してください。

決議

インスタンスステータスチェックまたはシステムステータスチェックが失敗したかどうかを判断するには、インスタンスのステータスチェックメトリクスを表示します。

システムステータスチェックに失敗した場合は、「EC2 Linux インスタンスのシステムステータスチェックに失敗しました。これをトラブルシューティングするにはどうすればよいですか?」を参照してください。

インスタンスのステータスチェックに失敗した場合は、インスタンスのシステムログを確認して失敗の原因を特定します。次に、以下のいずれかの解決策を使用して問題を解決します。

OS の起動の失敗

システムログにブートエラーが含まれている場合は、「オペレーティングシステムの問題が原因でインスタンスステータスチェックに失敗した EC2 Linux インスタンスのトラブルシューティングを行うにはどうすればよいですか?」を参照してください。

ボリュームの適切なマウントに失敗します

マウントポイントに失敗すると、インスタンスステータスチェックが失敗する可能性があります。

マウントポイント失敗の例:

[FAILED] Failed to mount /
See 'systemctl status mnt-nvme0n1p1.mount' for details.
[DEPEND] Dependency failed for Local File Systems.

詳細については、以下の AWS ナレッジセンターの記事を参照してください。

「依存関係失敗」エラー: EC2 Linux インスタンスを起動しようとすると緊急モードになるのはなぜですか?
「マウントに失敗」または「依存関係失敗」エラー: オペレーティングシステムの問題が原因でインスタンスのステータスチェックに失敗した EC2 Linux インスタンスをトラブルシューティングする方法を教えてください。

インスタンスタイプを Xen から Nitro に変更すると、ボリュームマウントに失敗することがあります。マウントが失敗するのは、Nitro ベースのインスタンスでは Amazon EBS ボリュームが NVMe ブロックデバイスとして公開されているためです。デバイス名は /dev/nvme0n1、/dev/nvme1n1 などです。ブロックデバイスマッピングで指定したデバイス名は NVMe デバイス名 (/dev/nvme[0-26]n1) に変更されます。ブロックデバイスドライバーでは、ブロックデバイスマッピングで指定した元の順序とは異なる順序で NVMe デバイス名が割り当てられる場合があります。Nitro ベースのインスタンスでマウントエラーを回避するには、デバイス名にラベルまたは UUID を使用するのが最前の方法です。詳細については、「Amazon EBS ボリュームを Linux で使用できるようにする」を参照してください。

CPU およびメモリの枯渇

CPU 使用率が高い

CPUUtilization メトリクスが 100% またはそれに近い場合は、インスタンスにカーネルを実行するのに十分なコンピューティング能力がない可能性があります。

T2 または T3 インスタンスの場合は、Amazon CloudWatch CPU クレジットメトリックスを確認して、UPC クレジットがゼロまたはゼロに近いかどうかを判断します。CPU クレジットがゼロの場合、CPUUtilization メトリックはインスタンスのベースラインパフォーマンスが飽和状態になっていることを示します。インスタンスの種類によっては、ベースラインパフォーマンスが 20%、40% などになる場合があります。

CPU 使用率が 100% またはそれに近い、または T2 または T3 インスタンスが飽和状態にある場合は、リソースの過剰使用のためにステータスチェックが失敗したことを示します。この問題のトラブルシューティングについては、「EC2 Linux インスタンスがリソースの過剰使用が原因でインスタンスのステータスチェックに失敗しました。これをトラブルシューティングするにはどうすればよいですか?」を参照してください。

ブロックデバイスエラー、ソフトウェアのバグ、またはカーネルパニックにより、異常な CPU 使用率が急上昇する可能性があります。CPU 使用率が 100% の場合は、システムログにブロックデバイスまたはメモリに問題があるエラー、またはその他の異常なシステムエラーが記録されているか確認してください。次に、インスタンスを再起動、または停止して起動します。

メモリ不足

メモリ負荷が高いと、インスタンスステータスチェックが失敗する可能性があります。次のログエントリ例では、OS のメモリが不足しています。このエラーを解決するためには、最もメモリを消費しているプロセスを停止します。

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB

デフォルトでは、EC2 インスタンスのメモリとディスクメトリクスは Amazon CloudWatch に送信されません。ただし、CloudWatch エージェントを使用して追加のメトリックスを収集およびモニタリングすることができます。

メモリ不足の問題をトラブルシューティングして解決するには、インスタンスをより大きいインスタンスタイプにアップグレードします。または、インスタンスにスワップストレージを追加してメモリ負荷を軽減します。詳細については、以下の AWS ナレッジセンターの記事を参照してください。

ディスク容量不足エラー

システムログにディスク容量不足エラーが含まれている場合は、ルートデバイスがいっぱいになっているためインスタンスが緊急モードになっています。

システムログ例:

$: service apache2 restart
Error: No space left on device

$: /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl): mysql.serviceError: No space left on device


root@example:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

ディスク容量不足エラーのトラブルシューティングと解決方法の詳細な手順については、次の AWS ナレッジセンターの記事を参照してください。

カーネルパニック

カーネルパニックは、動作中にカーネルが致命的な内部エラーを検出したときに発生します。OS の起動中にエラーが発生する場合は、カーネルが正しくロードされない可能性があります。これにより OS の起動に失敗します。

カーネルパニックエラーメッセージ例:

Linux version
2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
Kernel command
line:  root=/dev/sda1 ro 4
Registering block device major 8
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

カーネルパニックエラーのトラブルシューティングと解決方法については、次の AWS ナレッジセンターの記事を参照してください。

ネットワーク障害

次の一般的な理由により、ネットワーク障害が発生する可能性があります。

cloud-init パッケージがインスタンスにインストールされていない

cloud-init パッケージは起動時にネットワーク設定を更新するために使用されます。

このエラーを修正するには、次のコマンドを実行して cloud-init パッケージをインスタンスにインストールします。

$ sudo yum install cloud-init

MAC アドレスが設定ファイルにハードコードされている

ハードコーディングされた MAC アドレスは Linux 設定ファイルと udev 設定ファイルにあります。これらのファイルは、通常次の場所にあります。

/etc/udev/rules.d/
/etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/80-net-name-slot.rules

ハードコーディングされた MAC アドレスが原因で生じるネットワークの問題を解決するには、エントリまたは設定ファイルを削除します。例えば、以下のコマンドを実行してください。

mv /etc/udev/rules.d/70-persistent-net.rules/root/

IP アドレスは設定ファイルにハードコーディングされています

静的に設定された IP アドレスを持つインスタンスから Amazon マシンイメージ (AMI) を作成すると、設定ファイルにハードコーディングされた IP アドレスが含まれる場合があります。

このエラーを修正するには、ネットワークインスタンスが DHCP を使用するように設定します。

**注記:**既存の AMI は更新できません。新しい AMI を作成するには、DHCP を使用するようにネットワークインターフェースを設定する必要があります。

ENA または Intel 拡張ネットワークドライバーが不足している

Elastic Network Adapter (ENA) または Intel 拡張ネットワークドライバーが見つからない場合の詳細については、「Linux での拡張ネットワーク」を参照してください。

ネットワークインターフェイスの名前が起動時に変更されます

この問題を解決するには、カーネルコマンドラインに net.ifnames=0 を追加して、予測可能なネットワークインターフェース名を無効にします。この変数を使用するには、ENA を使用する拡張ネットワーキングをアクティブ化する必要があります。

ネットワークの問題の詳細については、「ネットワークインターフェース設定のベストプラクティス」を参照してください。