ディスクエラーが原因で起動に失敗した EC2 Linux インスタンスを回復する方法を教えてください。

簡単な説明

カスタム AMI から作成された Amazon EC2 インスタンスで、fstab ファイル内の次の設定ミスが原因でディスクエラーが発生します:

• 正しくないデバイス ID
• 正しくないパス名
• 正しくないまたは重複した UUID

これらのエラーを解決するには、インスタンスのオペレーティングシステムにアクセスする必要があります。インスタンスにアクセスできない場合は、次の方法のいずれかを使用してアクセスします:

• EC2 シリアルコンソール
• エラーを手動で修正するためのレスキューインスタンス

解決策

EC2 シリアルコンソールを使用する

Linux インスタンス用 EC2 シリアルコンソールを有効にすると、サポートされている Nitro ベースのインスタンスタイプとベアメタルインスタンスのトラブルシューティングに使用できます。シリアルコンソールは、起動の問題、ネットワークや SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、稼働中のネットワーク接続を必要とせずに、インスタンスに接続します。シリアルコンソールにアクセスするには、Amazon EC2 コンソール、または AWS コマンドラインインターフェイス (AWS CLI) を使用します。

EC2 シリアルコンソールを初めて使用する場合は、接続を試みる前に、必要条件を確認してからアクセスを設定してください。インスタンスに到達できず、シリアルコンソールへのアクセスを設定していない場合は、次のセクション「レスキューインスタンスを使用してエラーを手動で修正する」の手順に従ってください。EC2 シリアルコンソールの設定については、「EC2 シリアルコンソールへのアクセスを設定する」を参照してください。

レスキューインスタンスを使用してエラーを手動で修正する

警告: 以下の手順では、インスタンスを停止する必要があります。インスタンスストアボリュームに保存されているデータは、インスタンスが停止されると失われます。インスタンスを停止する前に、データのバックアップを必ず保存してください。Amazon Elastic Block Store (Amazon EBS) バックアップボリュームとは異なり、インスタンスストアボリュームは一時的なもので、データの永続性をサポートしていません。

Amazon EC2 が起動時または開始時にインスタンスに自動的に割り当てた静的パブリック IPv4 アドレスは、停止および起動後に変更されます。インスタンスの停止時に変わらないパブリック IPv4 アドレスを保持するには、Elastic IP アドレスを使用します。

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

1. ディスクエラーが発生したインスタンスと同じ AMI を使用して、仮想プライベートクラウド (VPC) 内で新しい EC2 インスタンスを起動します。障害が発生したインスタンスと同じアベイラビリティーゾーンで、新しいインスタンスを起動します。新しいインスタンスがレスキューインスタンスになります。または、同じ AMI を使用し、障害が発生したインスタンスと同じアベイラビリティーゾーンにある既存のインスタンスを使用します。

2. 障害が発生したインスタンスを停止します。

3. 障害が発生したインスタンスから Amazon EBS ルートボリューム (/dev/xvda または /dev/sda1) をデタッチします。ルートボリュームのデバイス名 (/dev/xvda または /dev/sda1) を書き留めておきます。

4. レスキューインスタンスに、セカンダリデバイス (/dev/sdf) として ボリュームをアタッチします。

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

6. レスキューインスタンスにアタッチした新しいボリュームのマウントポイントディレクトリ (/rescue) を作成します:

   $ sudo mkdir /rescue

7. ディレクトリにボリュームをマウントします。

   $ sudo mount /dev/xvdf1 /rescue

   注: デバイス (/dev/xvdf1) は別のデバイス名でレスキューインスタンスにアタッチされている可能性があります。正しいデバイス名を確認するには、lsblk コマンドを使用して、使用可能なディスクデバイスとそのマウントポイントを確認します。

次に、ボリュームをトラブルシューティングします。
次のコマンドを実行して fstab エントリを確認します。

$ cat /rescue/etc/fstab

以下の例では、fstab エントリには 2 つのボリュームがあります:

UUID=47834bf7-764e-42f9-9507-11a3e70b99de / xfs defaults,noatime 1 1
UUID=1b75bcf4-ee55-428e-8d68-88dca398da01 /test xfs defaults,nofail 0 2

fstab エントリで、次の設定を確認します:

• エントリにデバイス ID が含まれていないかどうかを確認します。デバイス ID が正しくないと、問題や不一致の原因になります。デバイス ID の代わりに UUID を使用するのがベストプラクティスです。デバイス ID がファイルにある場合は、それらをボリュームの UUID で置き換えてください。以下のコマンドを実行して、正しい UUID を見つけてください:

  lsblk -f

• マウントポイントのパスが正しく、ボリュームに存在することを確認してください。

• 重複する UUID がないことを確認します。また、障害が発生しているインスタンス上の追加のボリュームが同じ UUID を使用していないことも確認してください。追加のボリュームの UUID を確認するには、前述の手順に従ってそれらをレスキューインスタンスにアタッチします。UUID が重複している場合、ボリュームをマウントすることができず、以下のようなエラーが表示されます:

  mount: /rescue: wrong fs type, bad option, bad superblock on /dev/xvdg1, missing codepage or helper program, or other error

• 次のコマンドを実行して、アタッチされているボリュームの UUID を確認します:

  $ lsblk -f

• UUID が重複している場合は、次のコマンドを実行して UUID を変更します:

• XFS ファイルシステムの場合:

  $ sudo xfs_admin -U <unique UUID> /dev/xvdb1

• EXT4 ファイルシステムの場合:

  $ tune2fs -U random /dev/sdb1

• また、次の例のように、fstab エントリに nofail オプションを追加します:

  UUID=aebf131c-6957-451e-8d34-ec978d9581ae /data xfs defaults,nofail 0 2

• 注: 特定のボリュームをアタッチせずにインスタンスを起動する場合、nofail マウントオプションにより、マウントエラーが発生してもインスタンスは起動できます。例えば、ボリュームを別のインスタンスに移動した後にインスタンスを起動しようとする場合があります。Debian 派生 (16.04 より前のバージョンの Ubuntu を含む) では、nobootwait マウントオプションも追加する必要があります。

エラーを修正した後にファイルを保存し、次の手順を実行します。

1. umount コマンドを実行して、マウントされたボリュームをアンマウントします。

   $ sudo umount /rescue

2. 一時インスタンスからボリュームをデタッチします。

3. ボリュームを元のインスタンスにアタッチし、インスタンスを起動して正常に起動することを確認します。