2016-04-13 15 views
0

分割せずにステートレスサービスをどのように拡張することができますか?Azureサービスファブリックのスケーラビリティステートレスサービス

クラスタに5つのノードがあり、5つのサービスインスタンスがあるとします。シンプルなテストでは、ノードはスティッキーとして動作しています。ここでは、送信しているすべての要求がただ1つのノードによって処理されています。大量の要求が入ってくるシナリオでは、他のインスタンスを自動的に使用してトラフィックを処理できます。サービスファブリックでこのようなスケールアウト状況をどのように処理しますか?

ありがとうございます!

more on SF partitioning, including why its not normally used for stateless services

あなたはServiceProxyのAPIを使用している場合、それは与えられた物理的に粘着性の接続を維持します:

答えて

1

は通常、あなたができればというステートレスSFのサービスのためにパーティション化を使用するので、回避するための必要はありませんクラスタ内のノード。 HTTPエンドポイントを公開しているとしたら、クラスタ内の物理インスタンスごとに1つのエンドポイントが存在します(つまり、手動で繰り返し実行しない限り、一度に1つずつ話を終えることになります)。あなたがすることで、これを避けることができます:あなたがすることができ、例えばエンドポイントURLのリストスルーたくさん(または手動でサイクルにそれを行う場合は、高価になりがち各呼び出しのための新しいプロキシインスタンスを作成する

  1. 退屈で/

  2. クラスタの前にロードバランサを配置し、クライアントからSFノードまでのすべてのトラフィックを転送するように設定します。

Azure Load Balancer

Azure Traffic Manager

幸運:ロードバランサは、スタイル意味論など、ラウンドロビンのために設定することができます!

+0

私はすべてのコールに対して1つのプロキシインスタンスを使用していたと私は私が他のノードを打つことができなかった理由はだと思います。あなたは "それをたくさんするなら高価になる"とあなたは言った。私はWebサービスを使用しており、Apiエンドポイントはプロキシの作成を開始し、そのエンドポイントは多くヒットします。それはお勧めの方法ではありませんか? @ JoshL – Krishh

+1

あなたは正しい道を歩いています。考慮すべき唯一のことは、クラスタ内の各ステートレスインスタンスには独自のエンドポイントがあることです。そのため、どのインスタンスでも要求を処理したい場合は、それを確実にするためのメカニズムが必要です。 SFはあなたのためにこれをしません(まだ)。上記の2つのアプローチは、そのための実行可能なオプションです。 – JoshL

+0

クラスタ内にWeb APIと通常のステートレスサービスがある場合、すべての呼び出しで1つのノードを使用しないようにするために、Web APIからサービスにコールするときにロードバランサが必要ですか? –

1

各ノードにインストールされているリバースプロキシを使用して要求を照会することができます。 https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reverseproxy

リバースプロキシがエンドポイントを解決します。ステートレスサービスのインスタンスが複数ある場合は、リクエストをランダムなものに転送します。

負荷が高いときに、サービスとプロキシのインスタンス数を増やして新しいインスタンスを自動的に含めることができます。

+0

ロード中にインスタンス数を自動的に増やすにはどうしたら後で減らすことができますか? –

+0

負荷を測定し、インスタンスカウントを増加または減少させる手段が必要です。ウォッチャーアプリを作成してパフォーマンス(CPU使用率、キューメッセージ数など)を監視し、インスタンス数を自動更新することができます。 – duongthaiha

0

クラスタの外からサービスを呼び出すと仮定します。はいの場合、問題はサービスファブリックに固有の問題ではなく、Azure VMSS + LBです。

サービスファブリックは仮想マシンスケールセットの上で実行され、これらのVMはLoad Balancerの背後に作成され、クライアントがサービスに接続すると、ロードバランサを介してサービスに接続が確立されますロードバランサは要求を処理するための1つのターゲットVMを割り当てます。同じ接続(キープアライブ)を使用している間は、クライアントからの要求はすべて同じノードによって処理されます。

LBは、同じ接続を使用しているためLBをラウンドロビンしません。この問題を回避するにはLBの制限(機能)です。複数の接続を開くか、複数のクライアント(インスタンス)を使用する必要があります。

これは、デフォルト配布モード(ハッシュベース)用です。また、配布モードがハッシュベースの(5タプル= ip +ポート)か、IPアフィニティモード(ipのみ)であるかどうかを確認するには、LBのルーティングルールもチェックする必要があります。 IPは依然として同じノードにリンクされます。

出典:Azure Load Balaner Distribution Mode

関連する問題