1

バックグラウンド

Azure アプリケーションの最適な構造を見つけようとしています。各 worker ロールは、複数の長時間実行ジョブを起動します。時間の経過とともに、ジョブをソース インスタンスで読み取り専用モードに切り替え、ターゲット インスタンスでジョブをスピンアップし、ソース インスタンスで元のジョブをスピン ダウンすることで、あるインスタンスから別のインスタンスにジョブを転送できます。

ジョブが多すぎる場合は、Azure に追加のロール インスタンスをスピンアップし、それらを新しいジョブに使用するように指示できます。逆に、負荷が低下した場合 (夜間など) は、未処理のジョブをいくつかのマシンに統合し、Azure にインスタンスの数を減らすように指示できます。

問題は、(私が理解しているように) Azure には、どのインスタンスを停止するかを決定できるメカニズムが用意されていないことです。したがって、どのサーバーに統合すればよいかわかりません。ジョブの一部は、インスタンスが停止すると終了し、残りのインスタンスでそれらのジョブを再開する間、ユーザーに遅延が発生します。

アイデア 1 : どのインスタンスを停止するかを決定し、その Run() から戻ります。次に、インスタンス数を 1 つ減らすように Azure に指示し、壊れたインスタンスが適切な候補であると判断されることを願っています。誰もこのようなことを試しましたか?

アイデア 2 : まったく同じ内容のさまざまなワーカー ロールをあらかじめ定義します。インスタンス数を 0 から 1 に切り替えたり、元に戻したりすることで、個別に停止および開始できます。このアイデアはうまくいくと思いますが、Azure の自然なやり方に反するように思われ、追加のワーカー ロールを管理するために多くの余分な簿記が必要になるため、好きではありません。

アイデア 3 : 一緒に暮らす。

より良いアイデアはありますか？

4

2 に答える 2

1

あなたのアイデアに応えて

アイデア1： あなたが説明していることを正確に試したことはありませんが、私の経験では、最初のインスタンスには_0、次の_1で終わる名前があり、残りは推測できると確信しています。インスタンス数を減らすと、番号の接尾辞が最も大きいインスタンスから削除されます。特定のインスタンスの状態を考慮に入れた場合、私は驚かれることでしょう。

アイデア 2: おっしゃる通り、これは管理上の問題を引き起こします。ホステッド サービスごとに 5 つの異なるワーカーしか持てないため、スケールできるようにしたい 5 つのロールのグループごとにサービスが必要になります。また、更新を展開するときは、X 倍のサービスをアップロードする必要があります。ここで、X は現在サポートしているインスタンスの最大数です。

アイデア 3: 技術的に最も簡単。いくつかの明確化が保留されていますが、これはおそらく私が今のところやっていることです。このオプションの欠点を軽減するには、データをより高速にロードする方法を調査する必要があります。通常、これを支援するゴールディロックス レベル (多すぎず、少なすぎず) の並列処理があります。

于 2011-03-18T01:33:19.697 に答える
1

その通りです。停止するインスタンスを選択することはできません。一般に、各ワーカー ロール インスタンスで同じジョブを実行し、各インスタンスは同じキュー (または複数のキューを監視する複数のスレッドまたはジョブ) を監視します。

1 つのインスタンス (スケジューラなど) でジョブを実行する必要がある場合は、これを制約する方法として BLOB リースの使用を検討してください。ブロブをミューテックスとして作成します。次に、各インスタンスがスピンアップすると、スケジューラ ジョブはその BLOB の書き込みリースを取得しようとします。成功すると、実行されます。失敗した場合は、単純に (おそらく 1 分間) スリープ状態になり、再試行します。将来のある時点で、インスタンス数を縮小すると、スケジューラを実行しているインスタンスが強制終了されたとします。1 分後 (または任意の時間間隔)、別のインスタンスがリースの取得を試みて成功し、スケジューラ コードを実行します。

于 2011-03-17T23:41:12.607 に答える