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

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

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

注記

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

レイヤで自動修復が有効になっている場合 (デフォルト設定)AWS OpsWorksスタックは、Layer の失敗したインスタンスを次のように自動的に置き換えます。

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 ボリュームの指定Layer のインスタンスの場合、AWS OpsWorksスタックでは、インスタンスの起動時に新しいボリュームを作成し、各インスタンスにアタッチします。後でインスタンスからボリュームをデタッチする場合は、[Resources] ページを使用します。

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

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

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

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

重要

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

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

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

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

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