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

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

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

注記

インスタンスは複数の Layer のメンバーである場合があります。自動ヒーリングが無効なレイヤーが 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 スタックが新しい空のボリュームを作成し、新しいインスタンスにそのボリュームを添付します。

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

重要

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

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

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

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

  自動ヒーリングによって以前の Amazon EC2 インスタンスが停止されると、Amazon EBS インスタンスに保存されていないデータはすべて失われます。Amazon EBS ボリュームは新しいインスタンスに再アタッチされるため、保存済みデータは保持されます。