10

複数の Web ロール間の負荷を分散するために azure が提供するオプションをいじっていました。

これを行う3つの可能な方法を見つけました。

1 つ目は、何もせずにデフォルト (ラウンド ロビン) の実装に任せることです。

2 番目の可能性は、ServiceDefinitionFile でカスタム LoadBalancerProbe を定義することです。これは、試してみましたが機能しませんでした。私の理解では、ロールでステータス チェックが実行されるたびに、カスタム aspx ページが呼び出されます。http 応答コードに応じて、ロールのステータスがビジーに変わります。-しかし、これは決して起こりません。また、カスタム LoadBalancingProbe を定義するための例を実際に見つけることができませんでした。

したがって、これを行う別の方法を探しました。

ここで、RoleEnvironment.StatusCheck イベントをサブスクライブしています。これにより、いくつかのロジックを実装し、結果に応じてロールの状態をビジーで使用可能に設定できます。

私の質問: 1) カスタム LoadBalancerProbe が MSDN で説明されているように機能すると仮定すると、StatusCheckEvent へのサブスクライブとカスタム プローブの使用の違いは何ですか?

2) カスタム ロード バランサー プローブが機能しないのはなぜですか? - 今のところ Azure エミュレーターでテストしているだけで、エミュレーターでビジーに設定されているにもかかわらず、トラフィックが Webrole インスタンスにルーティングされることを十分に認識しています。しかし、私のカスタム プローブは、webroleinstances のステータスをまったく変更しません。

これは非常に初歩的なコードです。私の知る限り、webrole instance_n_0 のステータスをビジーに設定する必要があります。

public class LoadBalanceController : Controller
{

    public ActionResult Index()
    {

        WebOperationContext woc = WebOperationContext.Current;
        if(RoleEnvironment.CurrentRoleInstance.Id.ToLower().Contains("_0"))
        {
            woc.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.ServiceUnavailable;
        }else
        {
            woc.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.OK;

        }           

        return View(); //not relevant
    }

また、servicedefinitionfile を構成し、ルートを設定して、カスタム プローブで定義された healthcheck.aspx を呼び出すときに、このコントローラー/アクションにリダイレクトします。

<LoadBalancerProbes>
    <LoadBalancerProbe name="WebRoleBalancerProbeHttp" protocol="http" path="healthcheck.aspx" intervalInSeconds="5" timeoutInSeconds="100"/>
</LoadBalancerProbes>
...
<InputEndpoint name="EndpointWeb" protocol="http" port="80" loadBalancerProbe="WebRoleBalancerProbeHttp"/>

ルート：

    routes.MapRoute(
            name: "HealhCheck",
            url: "healthcheck.aspx",
            defaults: new { controller = "LoadBalance", action = "Index", id = UrlParameter.Optional }

        );
4

2 に答える 2

0

カスタム プローブが機能しない理由はわかりませんが、相違点は次のとおりです。ヘルス チェック イベントを使用すると、インスタンスが使用可能かどうかを通知できますが、これが呼び出される頻度に関して柔軟性がありません。また、カスタム ポート (またはポート タイプ) をリッスンする別のサービスを起動することはできません。

カスタム プローブを使用すると、任意のタイプのポート リスナーを作成して正常性を判断できるため、柔軟性が大幅に向上します。

仮想マシンではゲスト エージェントが実行されておらず、ヘルス チェック イベントが提供されないため、これがヘルス プローブの唯一の方法です。

于 2013-03-04T12:11:48.677 に答える