EC2 Linux インスタンスに到達できず、ステータスチェックに合格できない理由を知りたいです。

所要時間3分
0

Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスに到達できず、ステータスチェックに合格できません。

簡単な説明

Amazon EC2 は、次の 3 種類のステータスチェックを使用して EC2 インスタンスの状態を監視しています。

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

システムステータスチェックはインスタンスの基盤となるハードウェアの問題を検出します。ネットワーク、ハードウェア、またはソフトウェアの問題が原因で基盤となるハードウェアが応答しなかったり到達できなかったりした場合、システムステータスチェックは不合格となります。

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

インスタンスステータスチェックに不合格した場合、そのインスタンスに到達できないことを示しています。次の一般的な問題が原因で、インスタンスステータスチェックが不合格となる場合があります。

  • オペレーティングシステム (OS) を起動できない。
  • ボリュームを正常にマウントできない。
  • CPU およびメモリの枯渇。
  • カーネルパニック。
  • ネットワーク障害。

警告: 次の解決策のうち、いくつかではインスタンスを停止して起動する必要があります。インスタンスを停止して起動する前に、次の条件に注意してください。

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

詳細については、「Amazon EC2 インスタンスの停止と起動」を参照してください。

アタッチド EBS ステータスチェック

アタッチド EBS ステータスチェックは、インスタンスにアタッチされた Amazon EBS ボリュームが到達可能であり、I/O 操作を完了できる状態を監視します。詳細については、「アタッチド EBS ステータスチェック」を参照してください。

解決策

インスタンスステータスチェックまたはシステムステータスチェックが不合格となったかどうかを判断するには、インスタンスのステータスチェックメトリクスを確認します。

システムステータスチェックが不合格になった場合は、「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 ナレッジセンターの記事を参照してください。

インスタンスタイプを Xen から Nitro ベースのインスタンスに変更すると、ボリュームをマウントできない場合があります。Nitro ベースのインスタンスでは、Amazon EBS ボリュームは NVMe ブロックデバイスとして公開されることが原因でマウントに失敗します。たとえば、デバイス名は /dev/nvme0n1/dev/nvme1n1 という形式です。ブロックデバイスマッピングで指定したデバイス名は NVMe デバイス名 (/dev/nvme[0-26]n1) に変更されます。

注: ブロックデバイスドライバーでは、ブロックデバイスマッピングで指定した順序とは異なる順序で NVMe デバイス名が割り当てられる場合があります。Nitro ベースのインスタンスでマウントエラーを回避するには、デバイス名にラベルまたは UUID を使用することをおすすめします。詳細については、「Amazon EBS ボリュームを使用できるようにする」を参照してください。

CPU およびメモリの枯渇

CPU 使用率が高い

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

T2 または T3 インスタンスの場合は、Amazon CloudWatch CPU クレジットメトリックスを確認して、CPU クレジットがゼロまたはゼロに近いかどうかを判断します。CPU クレジットがゼロの場合、CPUUtilization メトリクスは、インスタンスのベースラインパフォーマンスで飽和状態が横ばいになっていることを示します。たとえば、ベースラインパフォーマンスが 20% や 40% になっている可能性があります。CPU 使用率が 100% またはそれに近い場合は、リソースの過剰使用が原因でステータスチェックに合格できないことを示しています。T2 または T3 インスタンスで飽和状態が横ばいとなっている場合は、過剰使用が原因でステータスチェックに合格できないことを示しています。

この問題のトラブルシューティング方法については、「リソースの過剰使用が原因でステータスチェックに合格できない EC2 Linux インスタンスのトラブルシューティング方法を教えてください」を参照してください。

ブロックデバイスエラー、ソフトウェアのバグ、またはカーネルパニックにより、CPU 使用率の異常な急増が起こる場合があります。CPU 使用率が 100% の場合は、まず、システムログでブロックデバイスまたはメモリの問題に関するエラーや、その他のシステムの異常に関するエラーの有無を確認します。次に、インスタンスを再起動するか、停止後に起動します。

メモリ不足

メモリ負荷が高いと、インスタンスステータスチェックが不合格となる場合があります。次のログ抜粋例では、オペレーティングシステムのメモリが不足しており、oom-killer が起動しています。このエラーを解決するには、最もメモリを消費しているプロセスを停止します。

[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 ナレッジセンターの記事を参照してください。

ディスク容量不足エラー

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

システムログ例

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

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

$: df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

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

カーネルパニック

カーネルパニックは、動作中にカーネルが致命的な内部エラーを検出したときに発生します。オペレーティングシステムの起動中にエラーが発生した場合、カーネルは正しく読み込まれていません。カーネルをロードできなかったことが原因で、インスタンスの起動に失敗します。

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

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)

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

ネットワーク障害

ネットワーク障害は、次の原因で発生する場合があります。

  • cloud-init パッケージがインスタンスにインストールされていない
  • 起動時に、cloud-init パッケージを使用してネットワーク設定を更新します。

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

Amazon、Amazon Linux 2、Amazon Linux 2023、RedHat オペレーティングシステム

$ sudo yum install cloud-init -y

Ubuntu、Debian オペレーティングシステム

$ sudo apt install cloud-init -y

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 アドレスがハードコードされていることが原因で発生したネットワークの問題を解決するには、該当するエントリまたは設定ファイルを削除してから、次のコマンドを実行します。

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

設定ファイルを移動した後、ネットワークサービスを再起動して、新しい MAC アドレスが取得されたことを確認します。

IP アドレスがネットワーク設定ファイルにハードコーディングされている

静的に設定した IP アドレスを持つインスタンスから Amazon マシンイメージ (AMI) を作成すると、設定ファイルにはハードコーディングされた IP アドレスが含まれます。このエラーを修正するには、ネットワークインターフェイスが DHCP を使用するように設定します。

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

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

Elastic Network Adapter (ENA) または Intel 拡張ネットワークドライバーが欠けている場合の詳細については、「Amazon EC2 インスタンスでの拡張ネットワーク」を参照してください。

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

予測可能なネットワークインターフェイス名の変更を無効にするには、カーネルのコマンドラインに net.ifnames=0 を追加します。プレースホルダーを使用する場合は、ENA で拡張ネットワーク機能を有効にし、grub 設定ファイルを再構築または更新する必要があります。

関連情報

Amazon EC2 Linux インスタンスがステータスチェックに合格できない場合のトラブルシューティング

EC2 Windows インスタンスがダウンしており、システムステータスチェックエラーが発生したりステータスチェックが 0/2 となったりする理由を知りたいです

インスタンスステータスチェックが失敗して EC2 Windows インスタンスがダウンするのはなぜですか?

ステータスチェックのタイプ

AWS公式
AWS公式更新しました 8ヶ月前
コメントはありません

関連するコンテンツ