自動ヒーリングを使用した、失敗したインスタンスの置き換え

すべてのインスタンスには、サービスと定期的に通信する AWS OpsWorks スタックエージェントがあります。AWS OpsWorksスタックでは、インスタンスの状態のモニタリングにこの通信が使用されます。エージェントとサービスとの通信が約 5 分以上途絶えると、AWS OpsWorks スタックではインスタンスが失敗したと見なされます。

自動ヒーリングはレイヤーレベルで設定されます。次のスクリーンショットにあるように、レイヤー設定を編集することで自動ヒーリングの設定を変更できます。

注記

インスタンスは複数のレイヤーのメンバーである場合があります。自動ヒーリングが無効なレイヤーが 1 つでもある場合、インスタンスが失敗したときは AWS OpsWorks スタックによりヒーリングが実行されません。

レイヤーのデフォルト設定である自動ヒーリングが有効になっている場合、レイヤーの失敗したインスタンスが以下のように AWS OpsWorks スタックは自動的に置き換えます。

Instance store-backed インスタンス

1. Amazon EC2 インスタンスを停止し、シャットダウンしていることを確認します。

2. ルートボリューム上のデータは削除されます。

3. 同じホスト名、構成、レイヤーメンバーシップの新しい Amazon EC2 インスタンスを作成します。

4. 古いインスタンスの最初の起動後にアタッチしたボリュームも含め、Amazon EBS ボリュームが再アタッチされます。

5. 新しいパブリックアドレスおよびプライベート IP アドレスが割り当てられます。

6. 古いインスタンスが Elastic IP アドレスに関連付けられている場合は、同じ IP アドレスが新しいインスタンスに関連付けられます。

Amazon EBS-backed インスタンス

1. Amazon EC2 インスタンスを停止して、停止したことを確認します。

2. EC2 インスタンスを起動します。

自動ヒーリングされたインスタンスがオンラインになると、AWS OpsWorks スタックはそのスタックのすべてのインスタンスに対して Configure ライフサイクルイベントをトリガーします。関連するスタック設定およびデプロイ属性には、インスタンスのパブリック IP アドレスおよびプライベート IP アドレスが含まれます。カスタム Configure レシピは、ノードオブジェクトから新しい IP アドレスを取得できます。

レイヤーのインスタンスに Amazon EBS ボリュームが指定されている場合、AWS OpsWorks スタックはそのインスタンスの起動時に新しいボリュームを作成して各インスタンスにアタッチします。後でインスタンスからボリュームをデタッチする場合は、[Resources] ページを使用します。

AWS OpsWorks スタックがレイヤーのインスタンスの 1 つを自動的に復旧させるときに、ボリュームを次の方法で処理します。

• ボリュームが添付されたインスタンスが失敗した場合は、ボリュームとデータが AWS OpsWorks スタックに保存され、新しいインスタンスに添付されます。

• ボリュームが添付されていないインスタンスが失敗した場合は、レイヤーで指定されている設定を使用して AWS OpsWorks スタックが新しい空のボリュームを作成し、新しいインスタンスにそのボリュームを添付します。

自動ヒーリングはすべてのレイヤーで自動的に有効になっていますが、レイヤーの全般設定を編集して無効にすることができます。

重要

自動ヒーリングを可能にしている場合は、必ず次の手順に従います。

• インスタンスを停止するには、AWS OpsWorksスタックコンソール、CLI、または API のみを使用します。

  その他の方法 (コンソールを使用するなど) でインスタンスを停止すると、AWS OpsWorks スタックはインスタンスが失敗したと見なして、自動ヒーリングを実行します。

• インスタンスが自動ヒーリングされている場合、失われないようにデータを保存するには、Amazon EBS ボリュームを使用してデータを保存します。

  自動ヒーリングが古い Amazon EC2 インスタンスを停止させると、Amazon EBS ボリュームに保存されていないデータはすべて損なわれます。Amazon EBS ボリュームは新しいインスタンスに再アタッチされるため、保存したあらゆるデータが失われることはありません。