2

AzureWebの役割をスケーリングするためにWindowsAzureManagementAPIをいじっています。ある時点で、インスタンスが1つあり、1つのインスタンスから2つのインスタンスに移動することにしました。HTTPPOStリクエストをに送信します

https://management.core.windows.net:443/<my-subscription-id>/services/hostedservices/<my-service-name>/deployments/<my-deployment-name>/?comp=config

現在のデプロイメントと同じ構成を指定するXMLを使用し、インスタンス数を2に設定します。呼び出しは成功し、変更が開始されます。これで、約30秒間、WebロールはHTTP呼び出しを受け入れません-呼び出し元は次のようになります

10061 connection refused

ブラウザで。これは、ロールがクライアント要求を処理していないことを意味します。それは問題だ。

クライアントの要求を常に処理するようにWebロールをスケーリングするにはどうすればよいですか？

4

2 に答える 2

7

SLA（サービスレベルアグリーメント-コンピューティング）によると：

異なるフォールトドメインに2つ以上のロールインスタンスをデプロイし、ドメインをアップグレードする場合、インターネットに面するロールが少なくとも99.95％の時間外部接続できることを保証します。

つまり、SLAではインスタンスが1つあることはサポートされていないため、ダウンタイムが発生する可能性があります（または発生する可能性があります）。2以上、または2以上のスケールの場合、停止は発生しません。

このブログ投稿では、障害ドメインとアップグレードドメインに関する適切な説明の概要を説明しています。何よりも、スケーリングとは「アップグレード」を意味します。構成を変更する場合、この構成の変更はすべてのロールとインスタンスに伝播する必要があります。（現在）ダウンタイムなしでこれを行う唯一の方法は、少なくとも2つのインスタンスを用意することです。各インスタンスは、別々のドメインに存在します。

于 2012-04-04T10:14:37.600 に答える
0

インスタンスが2つ以上ある場合でも、サービス構成を変更すると（Service Management APIを使用してインスタンスの数を変更するなど）、停止が発生する可能性があることに注意してください。構成を変更すると、インスタンスの再起動がトリガーされます。

これを防ぐには、WebRole.cs / WorkerRole.csに次のコードを実装する必要があります（その結果、インスタンスの数を変更しても停止することはありません）。

public override bool OnStart()
{
    RoleEnvironment.Changing += RoleEnvironmentChanging;
    return base.OnStart();
}

private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)
{
    if (e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange))
    {
        e.Cancel = false;
    }
}

編集：以下のastaykovのコメントを参照してください。

于 2012-04-05T08:20:46.470 に答える