10

アマゾン ウェブ サービス/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 の組み合わせが生じるたびに発生する必要があります。そうですか、それとも何か不足していますか?

4

3 に答える 3

7

失われたインスタンスを新しい AZ (AZ D など) に自動的に (つまり、人間の介入なしで) 置き換える方法はありますか?

Auto Scalingは実際にユースケースに適したサービスです - それぞれの質問に答えるには:

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

それを明示的に指定/伝える必要はありません。Auto Scaling の仕組みに暗示されています ( Auto Scaling の概念と用語を参照)。グループが持つ必要がある実行中の EC2 インスタンスの最小数、最大数、および必要な数を定義します) および b) インスタンスの適切なターゲットとなる AZ (通常/理想的には、リージョン内のアカウントで利用可能なすべての AZ)。

その後、Auto Scaling は、a) 要求された数のインスタンスを開始し、b) 構成された AZ でこれらのインスタンスのバランスをとります。AZ の停止は自動的に処理されます。アベイラビリティーゾーンとリージョンを参照してください。

Auto Scaling を使用すると、Auto Scaling グループをリージョン内の複数のアベイラビリティーゾーンにまたがることで、地理的冗長性の安全性と信頼性を活用できます。1 つのアベイラビリティ ゾーンが異常または使用不可になると、Auto Scaling は影響を受けていないアベイラビリティ ゾーンで新しいインスタンスを起動します。異常なアベイラビリティ ゾーンが正常な状態に戻ると、Auto Scaling は指定されたすべてのアベイラビリティ ゾーンに均等にアプリケーション インスタンスを自動的に再配布します。[鉱山を強調]

後続のセクション「複数のゾーンにまたがるインスタンスの分散とバランス」では、アルゴリズムについてさらに説明します。

Auto Scaling は、Auto Scaling グループで有効になっているアベイラビリティーゾーン間でインスタンスを均等に分散しようとします。Auto Scaling は、インスタンスが最も少ないアベイラビリティーゾーンで新しいインスタンスを起動しようとすることでこれを行います。ただし、試行が失敗した場合、Auto Scaling は成功するまで他のゾーンで起動を試みます。[鉱山を強調]

詳細とエッジケースの処理方法については、リンクされたドキュメントを確認してください。

アップデート

AZ の数がインスタンスの数よりも多いというフォローアップの質問については、実用的なアプローチに頼る必要があると思います。

実行するインスタンスの数以下の AZz の数を選択する必要があります。AZ が停止した場合、Auto Scaling は残りの正常な AZ 間でインスタンスのバランスを調整します。つまり、この例では 3 つの AZ のうち 2 つが停止しても、残りの AZ で3 つのインスタンスすべてを実行できます。 AZ。

利用可能な限り多くの AZ を使用するのは興味深いかもしれませんが、新規のお客様はいずれにせよ、米国東部 (バージニア北部) の 3 つの EC2 アベイラビリティーゾーンと米国西部 (北カリフォルニア) の 2 つの EC2 アベイラビリティーゾーンにしかアクセスできないことに注意してください (グローバルインフラストラクチャを参照)。の 5 つの AZ すべてに実際にアクセスできるのは、古いアカウントだけでありus-east-1、4 つだけの AZ と、新しいアカウントは最大で 3 つです。

  • これは従来の問題であると考えています。つまり、AWS は古い AZ を運用から外しているようです。たとえば、 の 5 つの AZ すべてにアクセスできる場合でも、実際にus-east-1は一部のインスタンス タイプはこれらすべてで利用できない場合があります (たとえば、新しい EC2 第 2 世代標準インスタンス m3.xlargeでm3.2xlarge、いずれかの 5 つの AZ のうち 3 つでのみ利用可能です)。使用しているアカウント)。

別の言い方をすれば、2 ～ 3 個の AZ は、リージョン内のフォールト トレランスのかなり良い妥協点であると考えられています。クロス リージョンのフォールト トレランスがおそらく次に心配になるとしたら。

于 2013-05-01T19:59:39.647 に答える
0

コメントするには十分な担当者がいません。

ELB はトラフィックを空の AZ にルーティングしないことを付け加えたいと思いました。これは、ELB がトラフィックを AZ ではなくインスタンスにルーティングするためです。

AZ を ELB にアタッチすると、その AZ のサブネットにElastic Network Interface が作成されるだけなので、そのAZ にインスタンスが追加された場合にトラフィックをルーティングできます。ルーティングを作成するのは、インスタンス (インスタンスに関連付けられているだけでなく、ELB にも関連付けられている AZ) を追加することです。

于 2014-05-16T17:47:05.470 に答える