ASP.NETアプリケーションのスケーリング

Question

これは非常に広い質問ですが、うまくいけば役に立つヒントを得ることができます。現在、私は単一のサーバー上で動作するASP.NETアプリケーションを持っています。顧客負荷の増加に対応するためにスケールアウトする必要があります。だから私の計画は次のとおりです。

1）ASP.NETとWebコンポーネントを5台のサーバーにスケールアウトします。

2）データベースをファームに移動します。

私は、アプリケーションに関しては単なるIPアドレスなので、データベースに問題があるとは思わない。しかし、私は今、ASP.NETとWeb層について懸念しています。私はおよそすでに心配していくつかの問題：ラウンドロビン方式で5台のサーバーのそれぞれに要求を外注しますちょうどロードバランサを実装するための最も簡単なモデルは

• ですか？

• 要求が送信されるたびに別の物理サーバーで終了できるようになったため、HTTPSおよびSSL接続に問題はありますか？ （パフォーマンスなど）

• クッキーによるセッションのメインテナンス（ログオン）に関して懸念はありますか？私の推測はノーですが、なぜか分かりません... ;-)

• セッションデータ自体（ストアドサーバー側）には何か問題はありますか？明らかに、私はサーバー間でセッション状態を複製する必要があります。または、何らかの理由で、要求が単一のサーバーにしか流れないように強制します。いずれにしても、ここに問題があります。

Answer 1

、この質問の多くは行政の事の本当に多くあり、かつServerFaultの上で有用である可能性があります。彼が投稿するリンクには、細かい情報があります。

Session質問：セッション状態サービス（複数のサーバー間で状態を共通に維持する別個のサービスとしてIISに付属）またはSQLにasp.netセッション状態を格納するデータベース。どちらもDavid Strattonのリンクで見つけることができるオプションです、私は確信しています。

大まかに言えば、アウトオブプロセスのセッション状態を設定すると、それ以外の場合は透過的になります。ただし、セッションにSerializableオブジェクトを格納する必要があります。

---

この状況では、ラウンドロビンDNSが負荷分散を行う最も簡単な方法です。各サーバーの実際の負荷は考慮されておらず、保守のために1台のサーバーがダウンしている可能性もありません。その特定のIPを持っている人は、他の4つのサーバが動作しているにもかかわらず、そのサイトが「ダウン」していると見なします。

SSL接続のロードバランシングと処理は、リバースプロキシタイプの状況の恩恵を受ける場合があります。プロキシは入ってくるすべての接続を処理しますが、暗号化と実際の要求負荷をWebサーバーとのバランスを取るだけです。

---

クッキーは、すべてのWebサーバーは、ホストヘッダーを経由して（同じウェブサイトであるとして自らを宣伝している提供問題になることはありません（これらの問題はもちろん、管理者側のより多くのですが、...） 、など）。各サーバーは、同じドメイン名を使用している他のサーバーが設定したCookieを、サーバーが何を送信したのかを知らずに気にせずに受け入れます。これは、Webブラウザがクッキー値を取得したときに接続しているサーバのホスト名に基づいています。

Answer 2

これはかなり広範な質問で、このようなフォーラムでは完全に答えるのは難しいです。私は質問がここに属しているのか、それともserverfault.comにあるべきかどうかは分からない。しかし....

マイクロソフトでは、この件に関する十分な情報を提供しています。 BINGから「asp.netアプリケーションをスケーリングする」ための最初の結果がこれになります。デビッド・ノートとして

http://msdn.microsoft.com/en-us/magazine/cc500561.aspx

Answer 3

ラウンドロビンhttp/httpsセッションに関連するいくつかの問題があります。私たちはプロセスセッションで使っていましたが、ロードバランサにセッションを固定するように指示しました。 （私は彼らがこれのためにクッキーを使うと思う）。

これはSQLセッションを避けていますが、httpからhttpsに切り替えると、F5のボックスはスティッキーさを維持できませんでした。私たちはSQLセッションに変更しました。

暗号化をロードバランサにプッシュすることを検討できます。私はそれが私たちの問題の可能な解決策であることを覚えていますが、悲しいかな、私たちが調査した問題ではありません。

Answer 4

私はちょうどあなたがデータベースを気にする必要がある領域を持ち出したいと思います。

まず、単一のデータベースサーバーのみを使用して構築されたほとんどのデータモデルでは、マルチマスターモードでデータベースファームをサポートするために大幅な変更が必要です。

プライマリキー（ほとんどの人が行う）に自動インクリメント整数を使用した場合、基本的にゲートから抜け出してしまいます。これを一時的に緩和するにはいくつかの方法がありますが、それらも多くの推測を必要とし、衝突の可能性が高いです。 1つの緩和策では、各サーバーのシード値を十分に高い数値に設定して、衝突の可能性を減らす方法があります。これは通常はしばらくの間有効です。

あなたはサーバー間でユーザーを分割する方法を把握する必要がありもちろん

...

私のポイントはほとんど常により困難達成するために、単に「アップスケーリングよりも、この領域は軽く払い落とされるべきではないことであるとされより大きいハードウェア上に置くことによってデータベースサーバーを構築します。

意図的にマルチマスターのロールを念頭に置いてデータモデルを構築した場合、無視してください。 ;）

セッションについて：「スティッキー」セッションを信頼しないでください。スティッキーは保証ではありません。率直に言って、私たちのものは通常サーバファームに配備されるので、セッションの状態を完全に無効にします。ファームに移動すると、セッション状態を使用する理由はほとんどありません。これは、データを状態サーバーから取得し、逆シリアル化し、シリアライズし、1ページの負荷ごとに状態サーバーに戻す必要があるためです。

DBとネットワークのトラフィックを考えると、その目的はdbとネットワークのトラフィックを減らすことだったので、もう何も購入しない方法を理解できます。

Answer 5

SQLサーバー上のセッションデータベースは、小さなコード&構成の変更で簡単にスケールアウトできます。 asp.netセッションをセッションデータベースに張り付けることができます。また、ファーム内のどのWebサーバーが要求に対応しているかにかかわらず、セッションIDベースのSQLステートサーバーマッピングは完全に機能します。これはおそらく、SQL Serverを使用してASP.NETセッション状態をスケールアウトする最良の方法の1つです。詳細については、リンクTrue Scaleout model for session state