SQL Server 2008 R2 WebEditionを使用した自動フェイルオーバーの実装

Question

Windows 2008 R2 Web Edition/SQL Server 2008 R2 WebEditionで実行されているASP.NETMVCWebサイトに自動フェイルオーバーを実装しようとしています。これはそのままではサポートされていないことは知っていますが、現在自由に使用できるソフトウェアライセンスを使用する必要があります。

自動フェイルオーバーとは、災害が発生した場合に、セカンダリサーバーがプライマリサーバーのデータベースからのすべてのデータを使用して起動する必要があることを意味します。それが不可能な場合は、「過去5分間にDBに書き込まれたデータを除いたすべてのデータ」にも満足しています。

必要に応じて、プライマリサーバーに切り替えることができます。

これが私がこれまでに思いついたものです：

非常に短い時間間隔（5分）で、プライマリサーバーのDBからセカンダリサーバーへのログ配布を設定します。 DBは大きすぎず（<50 MB）、書き込みが少ないため、パフォーマンスに大きな影響がないことを願っています。ミラーリングを希望しますが、SQL Server WebEditionではサポートされていません
常に両方のサーバーにWebサイトを展開します
DnsMadeEasy（dnsmadeeasy.com）を使用してプライマリサーバーを監視し、プライマリがダウンした場合は動的にセカンダリに切り替えます
毎分DNSエントリを監視するセカンダリでサービスタスクを実行します。セカンダリを指している場合は、もう1回ログ配布の実行をトリガーしてみてください（プライマリWebサーバーがダウンしているが、プライマリDBがまだ実行されている場合）。最後になりましたが、ログ配布を無効にします。

どう思いますか？これを行う簡単な方法はありますか（別のDBまたはクラウドソリューションを使用する以外に）？

ありがとう、

アドリアン

darin strait · Accepted Answer

here にある高可用性に関する情報によると、Webエディションの唯一のオプションはログ配布です。（レプリケーションもオプションではありませんが、アプリのデータベーススキーマに関して非常に煩わしいため、限られた場合にのみ提案します。）

そうは言っても、数分のデータ損失に耐えることができれば、ログ配布は完全に素晴らしいものになる可能性があります。

ただし、「自動」は危険です。留意すべき点：ログ配布のフェイルオーバーは自動ではありません。「監視サーバー」は監視するだけで、問題が発生しても何もしません。何かまたは誰かが、元のサーバーがダウンしていて、フェイルオーバーサーバー上のデータベースをリカバリから外す必要があると判断する必要があります。これを行うプログラムを作成することもできますが、24時間年中無休で監視している場合は人間に依存するリスクがあり、5分間のダウンタイムウィンドウが非常に不快になります。

使用しているジョブ（バックアップやインデックスの再作成などの「管理」機能やアプリに固有のジョブ）は両方のサーバーに存在する必要がありますが、必要になるまでフェイルオーバーで実行しないでください。多数のジョブがある場合は、それらを有効/無効にするための何らかの自動化された方法が必要になります。つい最近、これに関する記事がありました。今は見つかりませんが、グーグルでアイデアを出すための何かを見つけることができるはずです。

パッケージ、リンクサーバー、その他のサーバーレベルのものについても同様です。これらのオブジェクトは常に両方のサーバー上にある必要があり、これらのオブジェクトの変更をプライマリサーバーからfailvoerサーバーに「ログシップ」することはできません。複雑なサーバー構成では、2つのサーバーで同じものを維持することは、かなりの時間を必要とするタスク、またはいくつかのソフトウェアになる可能性があります。

ログイン名、パスワード、およびSIDが両方のサーバーで一致していることを確認する必要があります。そうでない場合、Webアプリは、フェイルオーバーサーバーが起動したときにデータベースにアクセスできない可能性があります。アプリのログインにドメインセキュリティを使用している場合は、SIDについて心配する必要がないため、これは簡単です。 SQL Serverセキュリティを使用している場合は、さらに注意する必要があります。

プライマリサーバーとフェイルオーバーサーバーのホスト名は異なります。 WebアプリケーションのデータソースをSQLServerAからSQLServerBに変更する方法が必要になります。DNSC名を使用しているため、Webサーバー上のファイルを更新するのではなく、DNSのエントリを更新できます。。

当然、本当に必要になる前にこれをテストする必要があります。

月に1回のWindowsパッチの停止が予定されている場合は、サーバーにパッチを適用するプロセスに手動フェイルオーバーを統合する必要があります。これにより、アプリのダウンタイムが最小限に抑えられ、フェイルオーバープロセスがテストされ、作業を行うすべての人に現実的なドリルが提供されます。

実際の緊急事態のためにフェイルオーバーするよりも、ウィンドウにパッチを適用するために何度もフェイルオーバーする可能性があります。

手動でフェイルオーバーするとプロセスがテストされるため、実際の緊急時に機能するかどうかがわかります。また、ログ配布を反対方向にバックアップするように設定する必要があります。これは、大規模なデータベースがある場合、かなりの時間がかかる可能性があります。