13

更新 2009-05-21

単一のネットワーク共有を使用する 2 番目の方法をテストしてきました。これにより、Windows Server 2003 の負荷がかかると、次のような問題が発生します。

http://support.microsoft.com/kb/810886

更新を終了する

次のように動作する ASP.NET Web サイトの提案を受け取りました。

ハードウェア ロード バランサー -> 4 つの IIS6 Web サーバー -> フェールオーバー クラスターを備えた SQL Server DB

これが問題です...

Web ファイル (aspx、html、css、画像) を保存する場所を選択しています。2 つのオプションが提案されています。

1) 4 つの IIS サーバーのそれぞれに Web ファイルの同一のコピーを作成します。

2) Web ファイルの 1 つのコピーを、4 つの Web サーバーからアクセスできるネットワーク共有に配置します。4 つの IIS サーバー上の Web ルートは、単一のネットワーク共有にマップされます。

より良い解決策はどれですか? オプション 2 は、ファイルを 1 つの場所にコピーするだけでよいため、明らかに展開が簡単です。ただし、4 つの Web サーバーがすべて 1 つのファイル セットにアクセスしているため、スケーラビリティの問題があるのではないかと思います。IIS はこれらのファイルをローカルにキャッシュしますか? すべてのクライアント要求でネットワーク共有にヒットしますか? また、ネットワーク共有へのアクセスは、ローカル ハード ドライブ上のファイルを取得するよりも常に遅くなりますか? IIS サーバーを追加すると、ネットワーク共有の負荷が大幅に悪化しますか?

概観を示すために、これは現在 1 か月あたり約 2,000 万ヒットを受け取る Web サイトの場合です。最近のピーク時には、1 秒あたり約 200 ヒットを受信して​​いました。

そのような設定で特別な経験があれば教えてください。入力していただきありがとうございます。

更新 2009-03-05

私の状況を明確にするために、このシステムの「展開」は、典型的な Web アプリケーションよりもはるかに頻繁です。Web サイトは、バック オフィス CMS のフロント エンドです。コンテンツが CMS で公開されるたびに、新しいページ (aspx、html など) がライブ サイトに自動的にプッシュされます。展開は基本的に「オンデマンド」です。理論的には、このプッシュは 1 分以内に数回発生する可能性があります。そのため、一度に 1 つの Web サーバーを展開することが実際的かどうかはわかりません。考え？

4

13 に答える 13

22

4台のサーバー間で負荷を分担します。それほど多くはありません。

展開時の単一障害点も、本番環境での単一障害点も望ましくありません。

デプロイするときは、一度に1つずつ実行できます。デプロイツールは、サーバーを使用してはならないことをロードバランサーに通知し、コードと必要な事前コンパイル作業をデプロイし、最後にサーバーの準備ができたことをロードバランサーに通知することで、これを自動化する必要があります。

この戦略は200以上のWebサーバーファームで使用され、サービスを中断することなく展開するためにうまく機能しました。

于 2009-03-05T04:51:08.000 に答える
6

あなたの主な関心事がパフォーマンスである場合、それはあなたがハードウェアにこのすべてのお金を費やしているからだと私は思います、そして便宜のためだけにネットワークファイルシステムを共有することは本当に意味がありません。ネットワークドライブのパフォーマンスが非常に高い場合でも、ネイティブドライブほどのパフォーマンスは得られません。

Webアセットのデプロイはとにかく自動化されているので（そうですか？）、複数でデプロイすることはそれほど不便ではありません。

許可しているよりも複雑な場合は、DeltaCopyのようなものがそれらのディスクの同期を維持するのに役立つかもしれません。

于 2009-03-05T04:52:39.963 に答える
3

中央の共有が悪い理由の 1 つは、共有サーバー上の NIC がファーム全体のボトルネックになり、単一障害点が生じるためです。

于 2009-03-05T05:37:19.590 に答える
2

理想的な高可用性の状況では、単一障害点があってはなりません。

つまり、Web ページが入った単一のボックスはダメです。大手通信会社の HA 作業を行った後、私は最初に次のことを提案します。

  • 4 つのサーバーのそれぞれに、独自のデータのコピーがあります。
  • 静かな時間に、2 台のサーバーをオフラインにします (つまり、HA バランサーを変更して削除します)。
  • 2 つのオフライン サーバーを更新します。
  • 2 つの古いサーバーではなく、2 つの新しいサーバーを使用して開始するように HA バランサーを変更します。
  • それをテストして、正確性を確認します。
  • 他の 2 つのサーバーを更新してから、それらをオンラインにします。

これが、追加のハードウェアなしで実行できる方法です。私が働いていた電話会社の肛門保持の世界では、私たちがしたことは次のとおりです。

  • 私たちは 8 台のサーバーを持っていたはずです (当時、私たちはあなたが棒を突くよりも多くのお金を持っていました)。移行の時期になると、4 台のオフライン サーバーに新しいデータがセットアップされます。
  • 次に、HA バランサーを変更して、4 つの新しいサーバーを使用し、古いサーバーの使用を停止します。これにより、スイッチオーバー (さらに重要なことに、詰め込んだ場合はスイッチバック) が非常に高速で痛みのないプロセスになりました。
  • 新しいサーバーがしばらく稼働していた場合にのみ、次の切り替えを検討します。その時点まで、4 台の古いサーバーはオフラインのままでしたが、念のため準備ができていました。
  • より少ない費用で同じ効果を得るには、追加のサーバー全体ではなく追加のディスクを使用できます。サーバーの電源を切って古いディスクを元に戻す必要があるため、回復はそれほど速くはありませんが、それでも復元操作よりは高速です。
于 2009-04-01T02:28:17.870 に答える
1

月間6000万アクセスのゲームサイトの開発を担当しました。私たちがそれを行った方法は、オプション＃1でした。ユーザーは画像などをアップロードすることができ、それらはサーバー間で共有される NAS に置かれました。それはかなりうまくいきました。家のアプリケーション側で、ページのキャッシュなども行っていると思います。また、オンデマンドで新しいページをすべてのサーバーに同時に展開します。

于 2009-03-31T19:53:31.860 に答える
1

一度に 1 つずつ展開するプロセスを備えた展開ツールを使用すると、システムの残りの部分が機能し続けます (Mufaka が言ったように)。これは、コンテンツ ファイルとアプリケーションのコンパイル済み部分の両方で機能する試行済みのプロセスです (このデプロイにより、asp.net プロセスのリサイクルが発生します)。

更新率に関しては、これはあなたが制御できるものです。更新プログラムがキューを通過するようにし、各アイテムを展開するタイミングを制御する単一の展開プロセスを用意します。これは、各更新を個別に処理するという意味ではないことに注意してください。キュー内の現在の更新を取得して、それらをまとめてデプロイできるからです。さらに更新がキューに到着し、現在の一連の更新が終了すると取得されます。

更新:コメントの質問について。これは、更新率を制御する必要がある重い/長いプロセスでの私の経験に基づくカスタム ソリューションです。このような動的コンテンツの場合、通常はさまざまなレベルで DB とキャッシュを組み合わせて使用​​するため、展開シナリオでこのアプローチを使用する必要はありませんでした。

キューは完全な情報を保持する必要はありません。プロセスが情報を渡して外部ツールで公開プロセスを開始できるようにするための適切な情報 (ID/パス) が必要なだけです。カスタムコードなので、公開する情報に結合させることができるので、公開プロセス/ツールでそれを処理する必要はありません。

DB の変更は発行プロセス中に行われますが、必要な変更の情報がどこにあるかを知り、発行プロセス/ツールに処理させるだけで済みます。キューに何を使用するかに関して、私が使用した主なものはmsmqと、SQLサーバーの情報を使用したカスタム実装です。キューは更新の速度を制御するためだけに存在するため、デプロイを特に対象としたものは必要ありません。

更新 2: DB の変更に下位互換性があることを確認してください。変更を別のサーバーにライブでプッシュする場合、これは非常に重要です。

于 2009-03-25T19:54:49.970 に答える
0

私たちはあなたと同様の状況にあり、私たちの解決策はパブリッシャー/サブスクライバーモデルを使用することです。CMSアプリは実際のファイルをデータベースに保存し、ファイルが作成または更新されたときにパブリッシングサービスに通知します。次に、この発行元は、サブスクライブしているすべてのWebアプリケーションに通知し、データベースからファイルを取得して、ファイルシステムに配置します。

サブスクライバーはパブリッシャーの構成ファイルに設定されていますが、アプリの起動時にWebアプリにサブスクリプション自体を実行させて、管理をさらに容易にすることができます。

ストレージにUNCを使用できます。本番環境とテスト環境の間の利便性と移植性のために、DBを選択しました（DBをコピーして戻すだけで、すべてのライブサイトファイルとデータがあります）。

于 2009-03-26T17:31:34.643 に答える
0

複数のサーバーにデプロイする非常に簡単な方法 (ノードが正しく設定されていれば) は、robocopy を使用することです。

できれば、テスト用に小さなステージング サーバーを用意してから、(ネットワーク共有を使用する代わりに) すべての展開サーバーに「ロボコピー」します。

robocopy はMS ResourceKitに含まれています- /MIR スイッチと共に使用します。

于 2009-03-26T19:58:14.557 に答える
0

IIS サーバーが Windows Server 2003 R2 以降を実行していると仮定すると、DFS レプリケーションを確認してください。各サーバーにはファイルの独自のコピーがあり、他の多くのサーバーが警告しているような共有ネットワークのボトルネックを解消します。デプロイは、レプリケーション グループ内のいずれかのサーバーに変更をコピーするのと同じくらい簡単です (フル メッシュ トポロジを想定)。レプリケーションは、リモート差分圧縮を使用して変更されたファイルのデルタのみを送信するなど、残りを自動的に処理します。

于 2009-03-31T08:50:55.883 に答える
0

それぞれページのローカル コピーを含む 4 つの Web サーバーと、フェールオーバー クラスターを備えた SQL Server を使用して、非常に満足しています。

于 2009-04-01T14:58:24.323 に答える
0

考える材料を与えるために、 Microsoft の Live Mesh の ようなものを見ることができます。それがあなたにとっての答えだと言っているわけではありませんが、それが使用するストレージ モデルはそうかもしれません。

メッシュを使用して、メッシュに含める各 Windows マシンに小さな Windows サービスをダウンロードし、メッシュの一部であるシステム上のフォルダーを指定します。ファイルを Live Mesh フォルダーにコピーすると (システム上の他のフォラーにコピーするのとまったく同じ操作です)、サービスはそのファイルを他のすべての参加デバイスに同期します。

例として、すべてのコード ソース ファイルを Mesh フォルダーに保存し、職場と自宅の間で同期させています。VS.Net、メモ帳、またはその他のアプリでファイルを保存するアクションを同期させるために、何もする必要はありません。更新が開始されます。

複数のサーバーに移動する必要がある頻繁に変更されるファイルを含む Web サイトがあり、それらの変更に対しておそらく複数の作成者がいる場合、Mesh サービスを各 Web サーバーに置くことができ、作成者がファイルを追加、変更、または削除すると、更新は次のようになります。自動的にプッシュされます。作成者が行っている限り、ファイルをコンピューター上の通常の古いフォルダーに保存しているだけです。

于 2009-03-27T08:50:41.113 に答える
0

4IIS を使用して NLB で得たものは、アプリケーション サーバーを使用した BottleNeck で失われます。

スケーラビリティのために、フロント エンド Web サーバー上のアプリケーションをお勧めします。

ここ私の会社では、そのソリューションを実装しています。フロント エンドの .NET アプリと、Sharepoint 用の APP サーバー + SQL 2008 クラスター。

それが役に立てば幸い！

よろしく！

于 2009-03-25T18:21:00.740 に答える