SQL Server を備えた VM と、50 人以下のユーザーを使用するアプリケーションがあります。VM やデータセンターに問題が発生した場合に備えて、ゼロ ダウンタイム アプリケーションを用意する必要はありませんが、少なくとも 30 分以内にアプリを再び利用できるようにする必要があります。
最初のアプローチ: SQL Server が同じ VM に存在し、可用性セットが SQL Server データのリアルタイム レプリケーションを処理するとは思わないため、2 つの VM で可用性セットを使用しても実際には機能しません。永続的なデータではなく、Web アプリケーション自体について (間違っている場合はお知らせください)、上記のステートメント AV Set は私には向いていません。また、2 つの VM があるため、2 倍の費用がかかります。
2 番目のアプローチ: ディザスタ リカバリでリカバリ サイトを使用する レプリケーションの最小頻度があり、1 時間だと思うため、データ損失ゼロの保証はないと読んでいました。そのため、1 時間のデータを処理する準備をする必要があります。損失と私はこれが好きではありません。
3 番目のオプション: SQL Server VM 用の Azure バックアップ。このオプションが機能する唯一の欠点は、RPO が 15 分とそれほど大きくないことですが、問題は、何らかの理由でユーザーがアプリでいくつかの重要なレコードを生成した場合に、ユーザーはアプリに登録するとすぐにすべてを破棄するため、再びアプリにアクセスすることはできません。
4 番目のアプローチ: ゼロ ダウンタイム アプリは実際には必要ないため、SQL Server データ ファイル用と SQL Server ログ用の 2 つのプレミアム ディスクを実際の VM で使用することだけを考えていました。VM に障害が発生した場合は、すぐにユーザーから通知を受け取ります。私ができることは、OS ディスクと SQL プレミアム ディスク (合計 3 つ) のスナップショットを作成し、これらのスナップショットを使用して新しい VM を作成することです。新しい稼働中の VM は、障害が発生する前に SQL に挿入された正確な最後のデータを持つ別のリージョンにある可能性があります。
もちろん、トラフィックを新しい VM に再ルーティングできるように、VM の上にロード バランサーが必要になると思います。失敗した VM を強制終了し、新しい VM を新しいシステムとして使用します。失敗が再び発生した場合は、同じプロセスに従うだけなので、この方法では 2 つではなく 1 つの VM に対してのみ支払います。
これは誰かがすでに試したことがありますか、これは合理的で実行可能に聞こえますか、それとも私は大きなことを見逃していますか、それとも期待どおりの結果が得られないのでしょうか?