0

MSSQL + ASP.NET MVC + ASP.NET Web フォーム + IIS でホストされる WCF サービスという洗練された asp.net ソリューションがあるとします。

週に 1 回、ユーザーに対して透過的にソリューションを単一の実稼働サーバーに展開する必要があります。展開には、データベース スキームの変更、IIS のマイナーな再構成、ファイルの置換が含まれる場合があります。展開には時間がかかり、稼働時間に影響を与える可能性があります。

ユーザーの作業を中断せずに展開したり、ダウンタイムを最小限に抑えるにはどうすればよいですか? テクニックとベストプラクティスは何ですか?

(例: ステージング/本番環境の切り替え)

4

3 に答える 3

0

最も重要な関心事が稼働時間である場合は、サイトの負荷分散されたサーバーを調べることができます。1 つを停止して更新し、その後元に戻してから、もう 1 つを更新することができます。このシナリオでセッションを管理する方法を確認する必要があります。たとえば、SQL サーバーまたは状態サーバーのメカニズムを使用します。

于 2010-02-04T09:38:18.440 に答える
0
  • システムを使用している人数が最も少ない時間を見て、更新を完了することを目指します。
  • DB サーバーに更新を適用するだけの場合は、何かが失敗した場合にバックアップすることだけを心配する必要があり、オフラインにする必要はありません。
  • ユーザーを中断することなく、新しいページをアップロードできるはずです。
  • 人為的ミスのリスクを減らすために、可能な限り自動化してください。可能な限り、Wix をお勧めします。
于 2010-02-04T09:46:03.243 に答える
0

完全な解決策を提供することはできませんが、「うまくいった」いくつかの点があります。

  • DB のアップグレードを (a) 後方互換性のある変更と (b) 破壊的変更に分割します。そうすれば、古いバージョンのソフトウェアがまだ実行されている間に、パート (a) (フィールドの追加、テーブルの追加、インデックスの追加など) を実行できます。(b) の部分 (フィールドの型を変更する、データを変換する、など) については、ダウンタイムを避けることはできないと思います。ほとんどの DB の変更を中断しないようにしてください。

  • ユーザーがそれに適応できるように、ダウンタイムを発表します。アップグレード中は、app_offline.htm 機能を使用して、状況を説明する適切なエラー メッセージがユーザーに表示されるようにします。また、アプリケーションが確実にリロードされます。Web アプリケーションをリロードせずにダウンタイムなしでインプレース アップグレード (つまり、「ファイルを置き換えるだけ」) すると、奇妙なエラーが発生する可能性があります。

  • アップグレードのテスト: システムの実行中に実行できる実稼働システム (ソフトウェアとデータベース) のコピーを作成します。テスト システムでアップグレードを実行します。アップグレード中に問題が発生した場合: 問題を修正し、アップグレード手順を改善して繰り返します。

于 2010-02-04T09:47:32.083 に答える