単一サーバー上のWebサイトの複数のインスタンス-一度に1つずつアップグレードする
単一の物理マシンを同じサイトの2つのコピーでホストしたいアップグレード中のダウンタイムを最小限に抑えるため。
マシンの前にロードバランサーを配置し、このマシンに2つのIPを割り当てて、ロードバランサーにIPを設定できると思います。
問題は、サイトを更新する必要がある場合です（インフラストラクチャではなくコード）。サイトの「インスタンス」の1つを取り出し、アップグレードしてからオンラインに戻し、他のインスタンスでも同じことを行うことで、ダウンタイムを最小限に抑えることができると思います。
これは実行可能ですか？
これは価値がありますか？
確かに、これは私たちがしていることです。 AとBの2つのWebサーバーがあります。それらの前にhaproxyがあり、それらの間で要求のバランスを適切に取っています。あなたのように、リクエストが元のサーバーに戻るような方法でセッションデータを保存することはありません必須。
アップグレードを実行する場合は、サーバーAをプールから取り出します。アップグレードを実行し、サイトを内部でテストします。次に、サーバーAをプールに入れ、同時にサーバーBをプールから取り出します。次に、サーバーBをアップグレードし、元に戻します。
利点：ダウンタイムが0のサイトアップグレード。
欠点：アップグレード中は、負荷分散や冗長性がありません。これを解決するには、さらに多くのサーバーを組み合わせる必要があります。
それが価値があるかどうかに関しては、あなただけがそれに答えることができます。私たちのソフトウェアは非常に複雑で、展開には5分以上かかる場合があり（完全に自動化されているため）、24時間年中無休で使用されています。ですから、それは私たちにとって簡単なことではありませんでした。
サイトが1日を通して散発的に、またはほとんどの場合、たとえば勤務時間中にトラフィックを取得し、単一のWebサーバーが処理できるものの障壁を押し上げていない場合は、面倒な価値がない可能性があります。 svn exportの実行中にメンテナンスバナーを10秒間スローする方が、より適切な解決策になる可能性があります。
WebFarmFrameworkとARRをご覧ください。 WFFは、コードの展開とIIS設定を自動化します。また、ロードバランサーを使用すると、アップグレード中にノードがオフラインになります。
私は実際に同じ問題を現在調査しているので、本番環境でこれを保証することはできません。別のアイデアを検討するだけです。