1台のサーバーマシンに障害が発生した場合でも、データベースバックエンドが24時間利用可能であるため、SQL Server 2012に依存するアプリケーションを確認する必要があると仮定します。
DBAではなく開発者として、フェールオーバー/高可用性にどのシナリオを使用するかを理解するのに苦労しています。
これらのシナリオのどれが、どのような種類のワークロードで機能し、どのような種類の障害/停止がそれらのシナリオで処理できるのでしょうか？彼らは同等/交換可能ですか？
回答:
私が常に高可用性ソリューションを視覚化する方法は次のとおりです。
高可用性とは何ですか？ インスタンス全体。これには、すべてのサーバーオブジェクト（ログイン、SQL Serverエージェントジョブなど）が含まれます。これには、データベースとそれに含まれるエンティティも含まれます。可用性の高いSQL Serverインスタンスには最適なソリューションです。これは、この特定のソリューションでの封じ込めレベルになるからです。
レポートはどうですか？ なし、NULL、存在しない。フェールオーバークラスターインスタンスには、インスタンス、VNNなどを含むクラスターグループを配信するアクティブノードがあり、他のすべてのノードはパッシブで、アイドル状態（現在のクラスターグループに関する限り）であり、フェールオーバーを待機しています。
フェールオーバーが発生するとどうなりますか？ FCIのダウンタイムは、パッシブノードがクラスターリソースを取得し、SQL Serverインスタンスを実行状態にするのにかかる時間によって決まります。通常、これは時間的に最小限です。
クライアントの抽象化？ はい。これは、フェールオーバークラスターインスタンスの仮想ネットワーク名を使用して本質的に組み込まれます。これは、常にSQL Serverクラスターリソースを現在配信しているアクティブノードを指します。
高可用性とは何ですか？ 可用性グループはここで高可用性の論理的な封じ込めになりますが、可用性グループは多数のデータベースと仮想ネットワーク名（リスナー、オプションのクラスターリソース）で構成されます。ログインやSQL ServerエージェントジョブなどのサーバーオブジェクトはHAソリューションの一部ではないことに注意してください。これらが可用性グループで適切に実装されるように特別な考慮が必要です。過度に負担のかかる要件ではありませんが、注意が必要です。
レポートはどうですか？これはレポート用の優れたソリューションですが、レポートインスタンスとして同期レプリカを使用することはおそらくないでしょう。同期と非同期の2つのコミット関係があります。私の意見では、実際に見たところ、同期セカンダリレプリカが災害を待っているということです。問題が発生した場合にデータ損失なしのフェールオーバーを実行する準備ができているレプリカと考えてください。次に、そのレポートワークロードを処理できる非同期レプリカがあります。このレプリカを前述のソリューションとして使用するのではなく、レポート作成などに使用します。レポートワークロードは、このレプリカを指すことができます（直接、またはリスナーを介した読み取り専用ルーティングを通じて間接的に）。
フェールオーバーが発生するとどうなりますか？ 自動フェールオーバーとペアになっている同期コミットセカンダリレプリカの場合、これはレプリカロールの状態がSECONDARY_NORMALからPRIMARY_NORMALに変更されます。自動フェールオーバーを行うには、現在同期されている同期セカンダリレプリカが必要です。実装されるのは、実際にこのフェールオーバーが発生するタイミングを決定するフレキシブルフェールオーバーポリシーです。そのポリシーは実際に構成可能です。
クライアントの抽象化？ はい、オプションでAlwaysOn可用性グループリスナーを構成できます。これは基本的に、現在のプライマリレプリカを指す仮想ネットワーク名（WSFCを介してAGのクラスターグループ内のクラスターリソースとして見ることができる）にすぎません。これは、レポートワークロードを変更するうえで重要な部分です。また、ReadOnlyトラフィックをリダイレクトするサーバーに読み取り専用ルーティングリストを設定します（これは、SQL用の.NET Framework Providerを使用して、接続文字列を通じて設定されます）サーバー、これはApplication Intentパラメーターになり、ReadOnlyに設定されます。また、セカンダリレプリカの役割のときにこのレポートワークロードを受信するレプリカごとに読み取り専用ルーティングURLを設定する必要があります。
高可用性とは何ですか？ これは議論の余地がありますが、私は何も言わないつもりです。私は、レプリケーションを高可用性ソリューションとはまったく考えていません。はい、データの変更は購読者にプッシュされていますが、私たちは出版物/記事レベルで話しています。これはデータのサブセットになります（すべてのデータを含めることはできますが、強制されません。つまり、パブリッシャーデータベースに新しいテーブルを作成し、サブスクライバーに自動的にプッシュされません）。HAに関する限り、これは最下層であり、堅固なHAソリューションでグループ化するつもりはありません。
レポートはどうですか？ データのサブセットについてレポートするための優れたソリューション、それについては疑いの余地はありません。トランザクションの多い1 TBのデータベースがあり、そのレポートワークロードをOLTPデータベースから除外したい場合、トランザクションレプリケーションは、レポートワークロードのサブスクライバー（またはサブスクライバー）にデータのサブセットをプッシュする優れた方法です。その1 TBのデータのうち、レポートワークロードが約50 GBだけの場合はどうなりますか？これはスマートなソリューションであり、ビジネスニーズを満たすように比較的構成可能です。
要約すると、回答が必要な少数の質問です（一部はビジネス側）。
Windowsフェールオーバークラスター内の2つ（またはそれ以上）のサーバー、クラスター化されたインスタンスとしてのSQL Server
どのようなワークロードですか？「それは依存します」-しかし、真剣に、これは、データセンターの高可用性をローカルにする必要があるオンラインアプリケーションに役立ちます。1台のマシンまたは1つのオペレーティングシステムの障害から保護されます。ログイン、ジョブ、新しいデータベース、メンテナンスなどはすべて、同じストレージを共有するまったく同じ2つのノードを持つクラスターであるため、自動的に同期が保たれるため、システムデータベースはすべて同じになります。非常に高速なフェールオーバーですが、フェールオーバーが発生するとSQL Serverが再起動するように見える問題がまだあります。
短所/懸念 -単一障害点は、ストレージとそのすべてのコンポーネントです。SANベンダーは常に「SANは失敗しない」と言いますが、ストレージエリアネットワークには多くの可動部品があり、ここでブログで書いたように、できます。また、あなたは何もすることができないセカンダリサーバーにお金を払って待っています。アクティブ/アクティブ/マルチノードを行い、どちらの方向にもフェイルオーバーして2番目のノードを使用できる2つのアクティブなインスタンスを持つことができます。
自動フェイルオーバー？「ほとんどの」自動。目撃者は必要ありません、それはクラスターです。これは、可能な限りシームレスにするためのクラスターの仕事です。これらのいずれでも、フェールオーバーが発生すると、SQLを起動する必要があるか、接続を指す必要があるため、それを「感じる」ことになります。ここで、それが起こると、基本的にSQLの再起動のように感じられ、DBが復旧し、recovery / etcを実行します。
ダウンタイムの許容度が非常に低いため、ローカルデータセンターの高可用性環境で「すべてのデータベース、すべてのログインなどを完全に起動したい」というクライアントがいる場合、フェールオーバークラスターインスタンスを検討します（ただし、あなたが言及した最後のオプションは強力な候補であり、管理のオーバーヘッドをいくらか省く必要があります。サイトの障害やSANの障害から保護するために、おそらくローカルFCIとAG非同期セカンダリを実行します。
トランザクションレプリケーションで最新の状態に維持される2つ（またはそれ以上）のSQL Serverインスタンス
同期コミットモードで構成されたSQL Server可用性グループ内の2つ（またはそれ以上）のSQL Server
これは私が人々が最近ますます実装するのを助けてきたものですが、時々私はまだクラスタリングに行きます。
概要
HAとDRは異なります。そして、これらの技術はどちらかの部分を提供するのに役立ちます。高可用性とは、（私にとって）1台のマシンに何か問題が発生した場合に迅速に復旧できることを意味し、目標復旧時間と目標復旧時間を短くすることができます。それがクラスタリングと同期AGです。
ディザスタリカバリとは、「HAソリューションに障害が発生した場合に立ち上がることができることです。別のデータセンター、ミラーリング、またはレプリケーションに移動するときにAGになります。
何を共有するかを検討することも重要です。
フェールオーバークラスタリングは、1つのディスクアレイを共有する2つ以上のサーバーノードを使用します。ディスクアレイがダウンすると、サーバーノードの数に関係なく、サービスが失われます。そのディスクアレイが配置されているサーバールームで火災や洪水が発生すると、サービスが失われます。
AlwaysOn可用性グループとデータベースミラーリングは、「共有なし」のクラスタリングテクノロジーです。データベースは、複数のサーバーの複数のディスクアレイに存在します。良好なネットワークリンクがあれば、複数のサーバーが複数のサーバールームに配置され、火災や洪水から保護されます。
完全を期すために、単純な古いミラーリングを使用するオプションがあります。ここでの利点は、可用性グループを使用する複雑さや、フェールオーバークラスタリングの共有ストレージを必要とせずに、データベースのコピーを2つ持つことです。欠点は、わずかではありますが、ミラーリングは非推奨です。
ミラーリングを使用したフェイルオーバー時間は10秒程度ですが、アプリケーションコードはフェイルオーバー時に発生しているトランザクションを再試行できる必要があります。