エントリー
この投稿では、組織内のソフトウェアパッケージを更新する方法について説明します。
私たちの組織は24時間体制でいくつかのサービスを提供しており、プログラムやデータベースを更新するプロセスは非常に急です。 仕事をせずにシステムを停止することは非常に重要であり、顧客の損失につながります。 したがって、このプロセスを改善し、システム全体のダウンタイムを削減するために、私たちが持っているものをhabrasocietyと共有し、すべてのコメント、批判、提案に耳を傾けることにしました。
ラック内のプロバイダーに2つのIBM x3550サーバーをインストールしました（1つはメイン、もう1つはテストミラー）。 サーバーにはWindows Server 2008 R2がインストールされています。
ソフトウェアパッケージの構成は次のとおりです。
- 2番目のサーバーにミラーが構成されたMS Sql Server 2008 R2上のデータベース。
- 私たちが取り組んでいるいくつかのサーバープログラム。
- サイトおよびWebサービス用のIIS。
主な問題とその解決策
したがって、私を苦しめる主な問題は、すべてのシステムコンポーネント（データベース、プログラム）を更新するプロセスです。 この組織で働くようになったとき、更新プロセスには15分から30〜60分かかることがありました（プログラマーのエラー、システムブレーキなど、さまざまな理由によって異なります）。 主なダウンタイムはプログラムの立ち上げであり、非常に長い間開始されることもありました。
次に、2台目のサーバーを購入し、すぐに重要なデータを保存して（これでデータベースを決定しました）、2台目のサーバーにミラーを構成することにしました。 構成し、2番目のバックアップサーバーを使用して更新することを考えました。 しかし、そこには、ミラーベースは一般的に読めなくてもアクセスできません。
更新スクリプト
更新中のサービスのダウンタイムを減らすために、次の更新スキームを設定します（混乱していると思います）。 交換できるように2つのサーバーを互いに同じように構成し、プライマリとバックアップの両方でサービスが同じように動作するように他に何もする必要はありませんでした（MS SQLでフェールオーバーのみを実行）。このため、同じIISとファイアウォールを構成しました。 。
そして、更新の時期が来ると、次のことが起こります。
- ミラーとして構成されたデータベースのフェールオーバー。
- 2番目のサーバーで、データベースに対して更新が実行され、プログラムが起動します。
- 起動後、サーバーはサーバー間でIPアドレスを変更します。
- その後、メインサーバーでソフトウェアの更新が実行されます。
- 結論として、ステップ1、2、および3が再び実行されます。
結果
このスキームを使用して、サービスのダウンタイムを15〜60分から7〜15分に短縮できました。 平均して、5分の2倍のアイドル時間が得られます。
おわりに
このスキームは非常に混乱し、時間がかかり、複雑であることを理解しています。 しかし、そのように更新されている間。 私の前と同じスキームに従って更新し、たとえば夜間の更新時間を再スケジュールすることも、良い選択肢ではありません。 なぜなら 更新後、システムに問題が発生する可能性があり、これらのエラーをすぐに修正するにはプログラマが必要です。 夜間にタクシーを呼ぶのはダウンタイムであり、時間単位で計算できます。 セキュリティのためにプログラマを更新するためにすぐに呼び出すこともオプションではありません。 作業のリズムに違反し、コードの品質に影響します。
可能な解決策
私は、2番目のサーバー上のデータベースが利用可能になるようにマージレプリケーションに切り替えるアイデアを持っています。2番目のサーバーでアップグレードし、後でスワップします。 競合が発生する可能性があります。
企業のメールやSharepointなどの他のサードパーティサービスについて考える必要がないように、できればサーバーを交換せずに、優れたシンプルな更新ソリューションを探したいと思います。 私は提案を聞いてうれしいです。 3台目のラックサーバーで問題を解決できますか？