4

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

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

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

アプリケーションに関する限り、データベースは単一のIPアドレスであるため、データベースに問題が発生することはないと思います。ただし、ASP.NETとWeb層について懸念しています。私がすでに心配しているいくつかの問題：

  • ラウンドロビン方式で5つのサーバーのそれぞれへの要求をファームアウトするロードバランサーのみを実装する最も簡単なモデルですか？

  • HTTPS接続とSSL接続に問題はありますか？リクエストが行われるたびに異なる物理サーバーで終了できるようになりましたか？（たとえば、パフォーマンス？）

  • クッキーを介したセッションの維持（ログオン）に関して懸念はありますか？私の推測はノーですが、理由を完全に説明することはできません... ;-)

  • セッションデータ自体（保存サーバー側）に懸念はありますか？明らかに、サーバー間でセッション状態を複製する必要があります。または、どういうわけか、リクエストを単一のサーバーにのみ送信するように強制する必要があります。いずれにせよ、ここに問題があります...

4

5 に答える 5

3

Davidが指摘しているように、この質問の多くは実際には管理上のものであり、ServerFaultで役立つ可能性があります。彼が投稿したリンクには、詳しく調べるための良い情報があります。

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

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

ラウンドロビンDNSは、この状況で負荷分散を行うための最も簡単な方法です。各サーバーの実際の負荷は考慮されておらず、メンテナンスのために1台のサーバーがダウンする可能性がある場合のプロビジョニングもありません。その特定のIPを取得した人は、他の4台のサーバーが実行されている場合でも、サイトが「ダウン」していると見なします。

負荷分散とSSL接続の処理は、どちらもリバースプロキシタイプの状況から恩恵を受ける可能性があります。ここで、プロキシは着信するすべての接続を処理しますが、実行するのは暗号化とWebサーバーへの実際の要求負荷のバランスを取ることだけです。（もちろん、これらの問題は管理側にありますが...）

すべてのWebサーバーが（ホストヘッダーなどを介して）同じWebサイトであると宣伝している場合、Cookieは問題になりません。各サーバーは、同じドメイン名を使用する他のサーバーによって設定されたCookieを、どのサーバーが送信したかを知らなくても、喜んで受け入れます。これは、Cookie値を取得するときにWebブラウザが接続しているサーバーのホスト名に基づいています。

于 2010-12-28T22:07:36.503 に答える
2

これはかなり幅広い質問であり、このようなフォーラムで完全に答えるのは困難です。質問がここにあるのか、それともserverfault.comにあるべきなのかさえわかりません。でも....

マイクロソフトは、このテーマについて多くのガイダンスを提供しています。BINGからの「asp.netアプリケーションのスケーリング」の最初の結果はこれになります。

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

于 2010-12-28T21:59:17.400 に答える
1

私はあなたがデータベースに関して気にかけるべき領域を持ち出したいだけです。

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

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

もちろん、サーバー間でユーザーを分割する方法を理解する必要があります...

私のポイントは、この領域を軽く消してはならず、データベースサーバーをより大きなハードウェアに配置して単に「スケールアップ」するよりも、ほとんどの場合、達成するのが難しいということです。

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

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

DBとネットワークのトラフィックをちょうどから、そしてそれらの目的がデータベースとネットワークのトラフィックを減らすことであったことを考えると、彼らがもはやあなたに何も買わない方法を理解するでしょう。

于 2010-12-28T22:21:19.687 に答える
0

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

SQLセッションを回避できますが、httpからhttpsに切り替えたときに、F5ボックスが粘着性を維持できなかったことを意味します。最終的にSQLセッションに変更しました。

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

于 2010-12-28T22:21:15.967 に答える
0

SQLサーバー上のセッションデータベースは、コードと構成をほとんど変更することなく簡単にスケールアウトできます。asp.netセッションをセッションデータベースに貼り付けることができ、ファーム内のどのWebサーバーが要求を処理するかに関係なく、セッションIDベースのSQL状態サーバーマッピングは問題なく機能します。これは、SQLサーバーを使用してASP.NETセッションの状態をスケールアウトするための最良の方法の1つです。詳細については、セッション状態のTrueScaleoutモデルのリンクを参照してください。

于 2011-01-12T09:58:17.447 に答える