6

単一の EC2 サーバー インスタンスで軽量の Web アプリを実行しています。これは私たちのニーズには適していますが、ダウンした場合に監視して再起動することについて疑問に思っています。

EC2 を監視し、必要に応じて新しいインスタンスを開始し、古いインスタンスをシャットダウンするために使用したい別の非 Amazon サーバーがあります。すべてのユーザー データは Elastic Storage にあるため、何かが失われる心配はありません。

この方法で EC2 を使用した経験があり、特に新しいインスタンスを開始するプロセスを自動化した経験があるかどうか疑問に思っていましたか? ゼロから何かを作成することに問題はありませんが、解決された問題のように思われるので、誰かが共有するヒント、リンク、スクリプト、チュートリアルなどを持っているかどうか疑問に思っていました.

ありがとう。

4

5 に答える 5

6

puppetとそのAWSのサポートを確認する必要があります。また、RightScale AWS ライブラリと、RightScale スクリプトを使用したサーバーの起動に関するこの投稿も参照してください。また、EC2 を使用した Web サービスに関するこの記事も役立つかもしれません。私はこれと似たようなことをしましたが、外部監視がなければ、ノードはそれ自体を監視し、不要になったときにシャットダウンし、後でやるべき仕事があるときに新しいノードが起動しました。

于 2008-10-30T15:19:44.973 に答える
2

ポイントのカップル:

Amazon EBS ボリュームをバックアップする必要があります。

彼らは「より良い」信頼性を主張していますが、100% ではなく、S3 の「12 9」の耐久性から数桁離れています。S3 耐久性 >> EBS 耐久性。あれは事実です。EBS は、ストレージを効率的かつ増分的に S3 にバックアップする「スナップショット」機能をサポートしています。また、EBS スナップショットでは、通常、割り当てられたボリューム サイズよりもはるかに小さい圧縮されたデルタに対してのみ料金が発生します。別の人生で、EBS は「耐久性がある」と「考え」、ミッション クリティカルなデータベースの唯一のコピーでそれを信頼したあなたのような小規模な顧客に、ボリュームのないメールを送信しました... それは悲痛です.

あなたの Q: 新しいインスタンスの自動起動

あなたが言及したデザインパスは比較的未踏です。その理由は次のとおりです...多くの企業は、2 番目のインスタンスが起動されて実行されている冗長な「ホットスペア」インスタンスを実行しています。これにより、「障害」（ハードウェアまたはソフトウェアの可能性があります）が発生した場合に、迅速なフェイルオーバー（秒）が可能になります。「コールドスペア」の問題は、マシンを最新の状態に保ち、古いボックスが中断したところから再開できるようにするのが難しいことです。さらに重要なことは、スペアが本番サービスを正常に回復できることを検証するのが難しいことです。ハードウェアは、テストされていないソフトウェア システムよりも信頼性が高くなります。テストテストテスト。フェールオーバーをテストしていない場合、機能しません。

新しい EBS インスタンスを開始する単純な自動化は簡単で、取るに足らないものです。これは、EC2 コマンドライン ツールを呼び出す 1 行の bash スクリプトです。トリッキーなのは、その上にあるすべてです。このようなソリューションは、完全に 100% 自動化された展開プロセスを意味します。そして、これはすべてアプリケーション固有のものです。アプリは、実行に必要なすべてのデータを取得できますか (S3 に保存されている可能性がありますか?)。今日インスタンスを強制終了し、0.000 の手動セットアップ/インストール手順で新しいインスタンスを起動できますか?

または、 「EBS ボリュームの再インスタンス化」と呼ぶシナリオについて話している可能性があります。

  1. EC2 ボックスが死ぬ (ルートボリュームは EBS)
  2. EBS ボリュームを強制的にデタッチする
  3. EBS ボリュームで新しい EC2 インスタンスを起動します

...それはほとんどうまくいきます。落とし穴:

  • EBS の障害 (ボリューム全体の損失または可用性の損失) から保護されない
  • すべてが正常に機能すると仮定すると、回復時間は O(分) です
  • 自動的に再起動するようにサービスを構成する必要があります。Nginx が実行されていない場合、ボックスを元に戻しても意味がありません。
  • DNS ルートやその他のサービス、または IP アドレスの変更に問題がない必要があるもの。これは、ElasticIP で回避できます。
  • ホストの SSH キーはどのように処理されますか? 同じ名前の新しいホスト キーは、ホスト キーの変更に関する強力な警告を受け取ると、SSH ベースの自動化を中断する可能性があります。
  • これを証明するものはありませんが (一度発生することを確認する以外に)、EC2/EBS は EBS インスタンスからの起動に対して自動的に_already_does_this_を実行すると信じています

繰り返しますが、ここでの難しい部分はあなたの皿にあります。本番サービスを今日停止して、新しいインスタンスで確実に起動できますか? もしそうなら、ストーリーの EC2 部分は本当に簡単です。

于 2013-04-02T22:12:18.797 に答える
1

サイドポイントとして：

すべてのユーザー データは Elastic Storage にあるため、何かが失われる心配はありません。

まだ行っていない場合は、定期的に EBS (Elastic Block Storage) のスナップショットを S3 に作成することを強くお勧めします。

于 2009-01-15T12:42:46.877 に答える
0

最小/最大/目的の数量が 1 の自動スケール グループを使用できます。インスタンスを ELB の背後に配置し、ELB の正常なノード数によって自動スケール グループがトリガーされるようにします。これにより、クラウドウォッチによる監視と ELB ヘルスチェックを組み込むことができます。問題が発生した場合はいつでも、インスタンスが自動スケーリング サービスに置き換えられます。

于 2013-12-29T04:15:00.383 に答える