問題タブ [autoscaling]

アマゾン ウェブ サービス/EC2 でアベイラビリティ ゾーンが停止した場合に、別のアベイラビリティ ゾーンに新しいインスタンスを自動的に作成するために利用できるツールまたは手法はありますか?

アベイラビリティーゾーン (AZ) が停止した場合に自動フェイルオーバーを行う方法は理解できたと思いますが、停止からの自動復旧 (新しい AZ に新しいインスタンスを作成する) はどうでしょうか? それは可能ですか？

シナリオ例:

1. 3 つのインスタンスのクラスターがあります。
2. ELB はクラスターへのトラフィックをラウンドロビンします。
3. 1 つのインスタンスを失うことはありますが、クラスター内の 2 つのインスタンスを失うことはありません。それでも完全に機能します。
4. (3) のため、各インスタンスは異なる AZ にあります。それらを AZ A、B、および C と呼びます。
5. ELB ヘルス チェックは、ELB が各インスタンスが正常であることを確認できるように構成されています。
6. AZ A での AZ の停止により、1 つのインスタンスが失われたとします。

この時点で、ELB は失われたインスタンスがヘルス チェックに応答しなくなったことを確認し、そのインスタンスへのトラフィックのルーティングを停止します。すべてのリクエストは、残りの 2 つの正常なインスタンスに送信されます。フェイルオーバーが成功しました。

はっきりしないのは回復です。失われたインスタンスを新しい AZ (AZ D など) に自動的に (つまり、人間の介入なしで) 置き換える方法はありますか? これにより、障害が発生した AZ (A) が回避され、既にインスタンスが含まれている AZ (AZ B および C) は使用されません。

AutoScaling グループ?

AutoScaling Groups は有望な出発点のように思えますが、このユース ケースを適切に処理できるかどうかはわかりません。

質問:

AutoScaling グループでは、デッド/異常なインスタンスを置き換える新しいインスタンスを新しい AZ に作成する必要があることを指定する方法がないようです (たとえば、AZ A ではなく AZ D に作成します)。これは本当ですか？AutoScaling グループでは、失敗した AZ を削除して新しい AZ を自動的に追加するよう ELB に指示する方法がないようです。そうですか？

これらは AutoScaling グループの本当の欠点ですか、それとも何か不足していますか?

これが AutoScaling Groups で実行できない場合、これを自動的に実行する他のツールはありますか?

2011 年に、FourSquare、Reddit などは、単一のアベイラビリティ ゾーンに依存していることが発覚しました ( http://www.informationweek.com/cloud-computing/infrastructure/amazon-outage-multiple-zones-a-smart-str/240009598 ) 。 . それ以来、ツールは長い道のりを歩んできたようです。自動回復ソリューションがないことに驚いています。各企業は、独自のソリューションを導入したり、手動で復旧したりしていますか? それとも、彼らはサイコロを振って、それが再び起こらないことを望んでいるだけですか?

アップデート：

@Steffen Opel、詳細な説明をありがとう。Auto Scaling Group は見栄えが良くなりましたが、ELB で使用する場合はまだ問題があると思います。

最小、最大、および必要なセットを 3 に設定し、4 つの AZ にまたがる単一の Auto Scaling グループを作成するとします。自動スケーリングでは、3 つの異なる AZ に 1 つのインスタンスが作成され、4 番目の AZ は空のままになります。ELB を構成するにはどうすればよいですか? 4 つの AZ すべてに転送する場合、1 つの AZ には常にゼロ インスタンスがあり、ELB は引き続きトラフィックをルーティングするため、うまくいきません。これにより、トラフィックが空の AZ に向かうときに HTTP 503 が返されます。これは私自身、過去に経験したことがあります。これは私が以前に見たものの例です。

これには、ELB の AZ を、インスタンスが実行されているものだけに手動で更新する必要があるようです。これは、Auto Scaling によって異なる AZ の組み合わせが生じるたびに発生する必要があります。そうですか、それとも何か不足していますか?

AWS Auto Scale のタイム スケジューリング機能を使用して、インスタンスを問題なく起動できます。

しかし、このインスタンスを終了するようにスケジュールしようとしても、何も起こりません:

どこが間違っていますか？

ありがとうステフェン。遅延は問題ではありませんでしたが、1 日に 4 つ以上のスケジュールを試した場合かもしれません。完全を期すために、1 つのインスタンスを起動し、数分後に停止するために必要な手順は次のとおりですか。

AWS AutoScale を使用してスケーリングされた ELB の背後にある EC2 で実行されているウェブサーバーがあります。新しいインスタンスが起動すると、最新のアプリケーション コードが git リポジトリからフェッチされます。

初期化中のエラーに対応する最善の方法は何ですか?

• gitサーバーが稼働していない/到達できない可能性があります
• ディスクが破損している可能性があります。git pull が存在し、エラーが発生しています (はい、これは私に起こりました)。

私は Amazon Cloud Auto Scaling (および AWS をすべて一緒に) にかなり慣れていません。

現在、起動構成を自動的に作成してから自動スケーラーを作成する .bat スクリプトを作成しようとしています。目的は、同僚が約 1 週間前に設定したイメージです。

私が遭遇する問題は、スクリプトを実行すると、起動構成コマンド以降のコマンドが実行されないことです。

コードは次のとおりです。

この問題のデバッグに役立つ提案を探しています。もしくは解決方法のアドバイス。「echo Timer Complete」の後、オートスケーラーを作成するコマンドがあります。ただし、「echo Timer Complete」も実行されません。コンソールは、起動構成が作成されたことを示して戻ります:)

また、各コマンドをコマンドラインに順番に入力すると、それぞれが完全に実行されます。起動構成は、Auto Scale グループと同様に作成されます。

毎日何十万回も外部 API を (HTTP リクエスト経由で) 呼び出すアプリがあります。

Heroku アプリにある Web dyno の数は、速度や 1 秒あたりに実行できる呼び出しの数、または取得したデータを保存する機能に影響しますか?

私は AWS AutoScaling と CloudWatch を初めて使用し、Windows コマンドラインでこれらの両方の SDK を使用しています。私がやろうとしていることが不可能であるか、チュートリアルから情報が欠落しているか、または完全に理解が途切れています。どれかを教えてください。

AWS を使用して、起動構成、オートスケーラー、ポリシー、およびそれらのポリシーに関連するアラームを正常にセットアップしました。ただし、これまでに行ったすべてのチュートリアルと Web 上の例を通して、アラームでメトリックを監視するキューを実際に正確に指定する方法をまだ確認していません。

Amazon クラウドにいくつかのキューがあるとします。キューの 1 つだけに自動スケーリングとアラームを設定するように指定するにはどうすればよいですか?

私はこれらのチュートリアルに従いました：

1. http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US_BasicSetup.html
2. http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/as-scale-based-on-demand.htmlの「ポリシーとアラームの作成」セクション

コード ビハインドによってインスタンス数を増やそうとしています。

まず、1 つの .cer ファイルと .pfx ファイルを作成し、それを .pfx にアップロードしてクラウドサービス証明書にアップロードし、.cer を設定 --> 管理証明書にアップロードします。

コードで .cer ファイルを使用した後。このuplodファイルは本当ですか？

これが私のコードです:

VMのいくつかのフィールドをチェックしていて、 currentInstanceCount を増やしています。

ChangeConfigurationBySlot メソッドが例外をスローしています:

リモート サーバーが予期しない応答を返しました: (400) 不正な要求。

どこが間違っていますか？理解できませんでした。メソッドのパラメーターまたは間違ったアップロード証明書に関するものですか?

見積もりはありますか？

ありがとう。