0

クライアントセッションの状態を失ったり、ダウンタイムを発生させたりすることなく、新しいバージョンのasp.net/mvcWebサイトを展開できるようにしたいと考えています。これを実現するために私が考えている方法は、Windowsネットワーク負荷分散サーバーを作成して、クライアントがhttps://mysite.org/などの単一のURLを介してサーバーにアクセスできるようにすることです。次に、トラフィックを他の2つのサイト（A.mysite.orgまたはB.mysite.org）のいずれかにリダイレクトします。NLBのアフィニティをシングルに設定し、サイトBを無効にして、すべてのセッションがサイトAに転送されるようにします。新しいバージョンのWebサイトを展開する必要がある場合は、サイトBに展開し、サイトBを有効にして、サイトAを無効にします。したがって、サイトAにいた全員は、ログオフするまで（バージョン1を使用して）そこにとどまることができます。すべての新しいセッションはサイトBに接続し、バージョン2を実行します。次にデプロイするときは、その逆を行います。

私はNLBを使ったことがありません。これは適切ですか？より簡単で簡単な方法はありますか？

NLBは、クライアントXからの要求がすでにAまたはBでセッションを持っていることをどのように知るのですか？つまり。彼らがウェブサイトからログオフし、再度ログインしようとすると、nlbは彼らを以前と同じサイトに送信しますか？

4

1 に答える 1

0

ここにはかなりの考慮事項があります

まず、NLBでアフィニティを調整するよりも、ASP.NETセッションをStateServerまたはSQLベースのセッション管理に格納して、Webクライアント（またはWebサービスクライアント）が「スティッキー」なアフィニティなしでサイトにアクセスできるようにする方がよいでしょう。StateServerをセットアップするか、SQLセッションDBを作成したら、アプリのWeb構成を簡単に変更する必要があります。

NLB自体は、サイトをアップグレードしている間、サイトを維持するのに最適です。通常、アプリを再インストールする前にクラスター内のサーバーをドレインストップし、テストしてから、次のサーバーなどでプロセスを繰り返す前に、NLBクラスターに戻します。

AFAIK、NLBシングルアフィニティはTCP / IPレベルで機能し、ASP.NETセッションに問い合わせることはありません。基本的に、同じクライアントIPから同じサーバーIP：ポートの組み合わせへの接続はすべて同じサーバーに送信されます。また、AFAIKでは、両方のサーバーがNLB IPを共有します（既存のIPに加えて）。サイトでSSLを使用しているように見えるため、アフィニティがない限り、SSLセッションキーはリクエストごとに再ネゴシエートする必要があり、パフォーマンスに影響を与える可能性があります。

于 2012-04-24T19:34:28.903 に答える