問題タブ [load-balancing]

デュアル CPU で Windows 2003 サーバーを使用しており、IIS が要求でオーバーフローして処理できなくなりますが、同時に CPU の 20% 未満と RAM の 40% 未満しか使用しません。サーバーがリクエストに対応できない場合、サイトを閲覧できないだけでなく、他のサイトで使用されている画像を提供することさえできません。VMWare をインストールして、このマシンに 2 つのサーバーを配置し、1 つのサーバーを使用して asp.net ページを提供し、もう 1 つのサーバーを画像と単純な html ページを提供することを考えています。画像と HTML ページの要求をあるサーバーにルーティングし、aspx ページの要求を別のサーバーにルーティングする方法を知っていますか?

どんなアイデアでも大歓迎です。

ありがとう、デニス

ユーザーが読むのと同じくらい書く場合、つまり、大きなサイトが異なるDBサーバー間で負荷を分散する方法を知りたいです。書き込みを受け入れる 1 つのマスターと、ユーザーにデータの読み取りのみを許可する複数のスレーブを用意するという標準的なソリューションでは、マスター サーバーがボトルネックになるだけなので、うまくいきません。

ロードバランサー -> 複数の Web サーバー -> 複数の DB サーバーを使用して大規模なサイトを管理している場合、DB サーバー間で負荷を均等に分散して、ユーザーが (せいぜい) 待機する必要がないようにするにはどうすればよいですか?マスターがスレーブを更新するか、または (最悪の場合) ユーザーがまだ更新されていないスレーブからダーティ データを読み取ることになりますか?

ありがとうございました。

Windows Azure Platform では、アプリケーションを 1 つ以上のインスタンスに展開できます。その後、ファブリック コントローラーは、それらのインスタンス間でアプリケーションのワークロードのバランスをとります。

• インスタンスの数は、需要に基づいてスケールアップ/ダウンできますか?それともインスタンスの数は静的ですか? インスタンスを動的に開始できる場合、これがどのように発生するかをどの程度制御できますか?

• Azure はアプリケーション インスタンス間でワークロードをどのようにバランスさせますか? また、その方法を制御することはできますか?

負荷分散された n 層システム用の DB 接続マネージャーを設計するための最良のアプローチについて疑問に思っています。

従来の n 層は次のようになります。

私が見ている負荷分散ソリューションは、次のようになります。

図のように、ビジネス サーバー コンポーネントは複数のインスタンスを介して負荷分散されており、ハードウェア ゲートウェイがそれらの間で負荷を分散しています。

セッション サーバーは、重複してはならない状態を管理するため、おそらく負荷分散アレイの外に配置する必要があります。

これまでの設計に重大なエラーがなければ、DB 接続管理を実装する最良の方法は何ですか?

私はいくつかのオプションを考え出しましたが、私が気付いていない他のオプションがあるかもしれません:

1. DBServer と他のコンポーネントの間に新しい Broker コンポーネントを導入し、DB 接続を処理させます。

   • 利点は、すべての接続を 1 つのポイントから管理できることです。これは非常に便利です。
   • 欠点は、システムに「単一障害点」が追加されることです。他のコンポーネントは、何らかの方法で DB に関係するすべての要求に対してそれを通過する必要があり、これもボトルネックになります。
     
     

2. DB 接続管理を BusinessServer および SessionServer コンポーネントに移動し、それぞれが独自の DB 接続を処理できるようにします。

   • 利点は、追加の「単一障害点」またはボトルネック コンポーネントがないことです。
   • 欠点は、DBServer 自体が提供できるもの以外に、競合やデッドロックの可能性を制御できないことです。

他に何ができますか？

FWIW: テクノロジは .NET ですが、ベンダー固有のスタックは使用されていません (たとえば、WCF、MSMQ などはありません)。

私は、2 つのアクティブ/アクティブ負荷分散サーバー上に存在し、別のサーバー上のクラスター化されたデータベースにアクセスするマルチスレッド アプリを作成しています。明らかに、複数のスレッドが同時に同じレコードに書き込むことは望ましくありません。SQL はロックを提供して、これが起こらないようにします。アクティブ - アクティブ構成では衝突を完全に止めることはできませんが、アプリケーション内でミューテックスを使用することの利点と欠点は何ですか?

ありがとう、パトリック

私は、RESTサービスの利点、ステートレス全体、およびセッションアフィニティの「もの」について検討してきました。インフラストラクチャ内の複数のマシンにサービスの複数の展開バージョンがあり、それらがすべて特定のリソースに作用する場合、そのリソースの状態はどこに保存されているのでしょうか。

分散キャッシュを利用する単一のホストと、サービス内で変更される状態をインフラストラクチャに含めることは意味がありますか？それは単にキャッシュをフェッチ/プットしますか？これにより、負荷分散の理由でデプロイされたサービスがいくつでも、リソースの同じ状態ビューをすべて表示できるようになります。

負荷分散サーバーに WCF サービス (Windows サービス上のホスト) を作成しました。このサービス インスタンスのそれぞれは、現在のユーザーのリストを維持します。たとえば、インスタンス A にはユーザー A001、A002、A005 があり、インスタンス B にはユーザー A003、A004、A008 などがあります。

各サービスには、ユーザー リストを取得するために使用するインターフェイスがあります。このメソッドは、すべてのサービス インスタンスのすべてのユーザーを返すことを期待しています。たとえば、インスタンス A またはインスタンス B からユーザー リストを取得すると、A001、A002、A003、A004、A005、および A008 が返されます。

現在、現在のユーザーのリストをデータベースに保存すると思いますが、このリストは頻繁に更新されるようです。

私の状況に合ったWCFサービス間でデータを共有する別の方法はありますか?

おそらく以前にこれを解決したことがあります。

セッションの固定性がない環境で open id を使用できるようにする必要があります。サーバーはヘッダーを保持します。

ASP.NET MVC と dotNetOpenId バージョン 3.2.0.9177 を使用しています。サード パーティの Web サイトでの認証は問題なく行われますが、応答を返すとエラーが発生し、認証に失敗します。

何かご意見は？

ユーザーが常にアクセスする3つのTomcatサーバーがあります。各リクエストの処理が重い（SQLが多い）ため、3つです。Lusers はサーバー 1 または 2 または 3 に入ります。今度はそれらを「1 つ」にします。クラスタリングを行う必要があることはわかっていますが、クラスタリングによってリクエストが 3 つのサーバーに分散されますか、それともここで apache2 を使用して負荷分散を実装する必要がありますか?