次の方法で共有


フェールオーバー クラスタリングと Always On 可用性グループ (SQL Server)

適用対象:SQL Server - Windows のみ

Always On 可用性グループ で導入された SQL Server 2012 (11.x) (High Availability and Disaster Recovery) ソリューションには、Windows Server フェールオーバー クラスタリング (WSFC) が必要です。 また、Always On 可用性グループは SQL Server フェールオーバー クラスタリングに依存しませんが、フェールオーバー クラスタリング インスタンス (FCI) を使用して可用性グループの可用性レプリカをホストできます。 各クラスタリング テクノロジの役割を把握し、Always On 可用性グループ環境を設計するときに必要な考慮事項を把握することが重要です。

注意

Always On 可用性グループの概念については、「Always On 可用性グループとは」を参照してください。

Windows Server フェールオーバー クラスタリングと可用性グループ

Always On 可用性グループ を配置するには、Windows Server フェールオーバー クラスター (WSFC) が必要です。 Always On 可用性グループを有効にするには、SQL Server のインスタンスが WSFC ノード上に存在し、WSFC とノードがオンライン状態である必要があります。 さらに、特定の可用性グループの各可用性レプリカが、同じ WSFC の異なるノード上に存在する必要があります。 唯一の例外は、別の WSFC に移行するときに、可用性グループは一時的に 2 つのクラスターにまたがることができるという点です。

Always On 可用性グループ では、特定の可用性グループに属している可用性レプリカの現在のロールを監視、管理したり、フェールオーバー イベントが可用性レプリカに及ぼす影響を判断したりするために、Windows Server フェールオーバー クラスター (WSFC) が使用されます。 WSFC リソース グループは、作成されたすべての可用性グループに対して作成されます。 WSFC は、このリソース グループを監視して、プライマリ レプリカの正常性を評価します。

Always On 可用性グループ のクォーラムは、クラスター ノードが可用性レプリカをホストしているかどうかに関係なく、WSFC 内のすべてのノードに基づきます。 データベース ミラーリングとは異なり、Always On 可用性グループには監視ロールはありません。

WSFC の全体的な正常性は、クラスター内のノードのクォーラムの投票によって決定されます。 災害や永続的なハードウェア障害または通信障害が原因で WSFC がオフラインになった場合は、管理操作を手動で行う必要があります。 Windows Server または WSFC の管理者は、クォーラムを強制し、稼動しているクラスター ノードをフォールト トレラントではない構成でオンラインに戻す必要があります。

重要

Always On 可用性グループ レジストリ キーは WSFC のサブキーです。 WSFC を削除してから再作成した場合は、元の WSFC 上の可用性レプリカをホストしていた Always On 可用性グループ の各インスタンスについて、SQL Server 機能を無効にしてから再度有効にする必要があります。

WSFC ノードでの SQL Server の実行と WSFC クォーラムの詳細については、「SQL Server を使用した Windows Server フェールオーバー クラスタリング」を参照してください。

SQL Server フェールオーバー クラスター インスタンス (FCI) と可用性グループ

SQL Server と FCI を WSFC と共に実装することにより、サーバー インスタンス レベルで第 2 のフェールオーバー レイヤーをセットアップできます。 SQL Server のスタンドアロン インスタンスまたは FCI インスタンスは、可用性レプリカをホストできます。 特定の可用性グループのレプリカをホストできる FCI パートナーは 1 つに限られます。 可用性レプリカが FCI で実行されている場合、可用性グループの有効な所有者の一覧には、アクティブな FCI ノードだけが含まれます。

Always On 可用性グループは、どの形式の共有ストレージにも依存しません。 ただし、 SQL Server フェールオーバー クラスター インスタンス (FCI) を使用して 1 つまたは複数の可用性レプリカをホストする場合、各 FCI では標準の SQL Server フェールオーバー クラスター インスタンスのインストールと同様、共有ストレージが必要になります。

追加の前提条件の詳細については、「 Always On 可用性グループ (SQL Server) の前提条件、制限事項、および推奨事項」を参照してください。

フェールオーバー クラスター インスタンスと可用性グループの比較

FCI のノードの数に関係なく、FCI 全体は可用性グループ内の 1 つのレプリカをホストします。 次の表に、FCI 内のノードと可用性グループ内のレプリカの概念の違いについて説明します。

FCI 内のノード 可用性グループ内のレプリカ
WSFC を使用する はい はい
保護レベル インスタンス データベース
ストレージの種類 Shared 非共有

可用性グループ内のレプリカはストレージを共有しませんが、FCI によってホストされているレプリカでは、その FCI の必要に応じて共有ストレージ ソリューションが使用されます。 ストレージ ソリューションは、可用性グループのレプリカ間ではなく、FCI 内のノードでのみ共有されます。
ストレージ ソリューション 直接接続、SAN、マウント ポイント、SMB ノードの種類によって異なる
読み取り可能なセカンダリ いいえ* はい
該当するフェールオーバー ポリシー設定 WSFC クォーラム

FCI 固有

可用性グループ設定**
WSFC クォーラム

可用性グループの設定
フェールオーバー リソース サーバー、インスタンス、およびデータベース データベースのみ

*可用性グループ内の同期セカンダリ レプリカは常にそれぞれの SQL Server インスタンスで実行されますが、FCI のセカンダリ ノードは実際にはそれぞれの SQL Server インスタンスを起動していないため、読み取りできません。 FCI 内のセカンダリ ノードは、FCI フェールオーバー中にリソース グループの所有権が転送されたときにのみ、 SQL Server インスタンスを起動します。 ただし、アクティブな FCI ノードでは、FCI でホストされるデータベースが可用性グループに属している場合、ローカル可用性レプリカが読み取り可能なセカンダリ レプリカとして実行されている場合、データベースは読み取り可能です。

**可用性グループのフェールオーバー ポリシー設定は、スタンドアロン インスタンスでも FCI インスタンスでも、すべてのレプリカに適用されます。

FCI での可用性レプリカのホストに関する考慮事項

重要

SQL Server フェールオーバー クラスター インスタンス (FCI) で可用性レプリカをホストする場合は、Windows Server 2008 ホスト ノードがフェールオーバー クラスター インスタンス (FCI) の Always On の前提条件と制限を満たしていることを確認します。 詳細については、「Always On 可用性グループの前提条件、制限事項、および推奨事項 (SQL Server)」を参照してください。

SQL Server フェールオーバー クラスター インスタンス (FCI) は可用性グループによる自動フェールオーバーをサポートしないため、FCI ホストが手動フェールオーバー用にのみ構成できる可用性レプリカ。

すべてのノードで使用できない共有ディスクを含むように WSFC を構成することが必要な場合があります。 たとえば、3 つのノードを持つ 2 つのデータ センター間の WSFC を検討します。 2 つのノードがプライマリ データ センターで SQL Server FCI をホストし、同じ共有ディスクにアクセスできます。 3 番目のノードは、別のデータ センターで SQL Server のスタンドアロン インスタンスをホストし、プライマリ データ センターから共有ディスクにアクセスすることはできません。 この WSFC 構成では、FCI がプライマリ レプリカをホストし、スタンドアロン インスタンスがセカンダリ レプリカをホストしている場合、可用性グループのデプロイがサポートされます。

特定の可用性グループの可用性レプリカをホストする FCI を選択する場合は、FCI フェールオーバーによって、1 つの WSFC ノードが同じ可用性グループに対して 2 つの可用性レプリカのホストを試行できない可能性があることを確認します。

この構成によってどのような問題が起きるかを次のサンプル シナリオに示します。

  • WSFC は、NODE01NODE02の 2 つのノードで構成します。
  • fciInstance1NODE01の現在の所有者である NODE02NODE01 の両方に、SQL Server フェールオーバー クラスター インスタンス (fciInstance1) をインストールします。
  • NODE02では、スタンドアロン インスタンスである SQL Server Instance3 の別のインスタンスをインストールします。
  • NODE01では、Always On 可用性グループの fciInstance1 を有効にします。 NODE02では、Always On 可用性グループの Instance3 を有効にします。 次に、fciInstance1 がプライマリ レプリカをホストし、セカンダリ レプリカをホスト Instance3 可用性グループを設定します。
  • ある時点で、 fciInstance1NODE01で使用できなくなり、WSFC によって fciInstance1 のフェールオーバーが NODE02されます。 フェールオーバー後の fciInstance1 は、 Always On 可用性グループ上でプライマリ ロールとして動作する NODE02対応のインスタンスです。 しかし、この時点で Instance3 は、 fciInstance1と同じ WSFC ノードに存在します。 これは Always On 可用性グループ の制約に違反します。

このシナリオで発生する問題を修正するには、スタンドアロン インスタンス ( Instance3) が、 NODE01 および NODE02と同じ WSFC 内の別のノードに存在する必要があります。

SQL Server FCI の詳細については、「 Always On フェールオーバー クラスター インスタンス (SQL Server)」を参照してください。

可用性グループでの WSFC Manager の使用に関する制限事項

フェールオーバー クラスター マネージャーを使用して可用性グループを操作しないでください。 例えば次が挙げられます。

  • 可用性グループのクラスター化されたサービス (リソース グループ) 内のリソースを追加または削除しないでください。

  • 使用可能な所有者や優先所有者など、可用性グループのプロパティを変更しないでください。 これらのプロパティは、可用性グループによって自動的に設定されます。

  • フェールオーバー クラスター マネージャーを使用して可用性グループを別のノードに移動したり、可用性グループをフェールオーバーしたりしないでください。 フェールオーバー クラスター マネージャーは可用性レプリカの同期状態を認識しないため、ダウンタイムが長くなることがあります。 Transact-SQL または SQL Server Management Studio を使用する必要があります。

警告

フェールオーバー クラスター マネージャーを使用して、可用性グループをホストしている フェールオーバー クラスター インスタンス を同じ可用性グループのレプリカを にホストしているノードに移動すると、可用性グループ レプリカが失われ、ターゲット ノードで可用性グループ のレプリカがオンラインになるのを防ぐことができます。 フェールオーバー クラスターの 1 つのノードで、同じ可用性グループに対して複数のレプリカをホストすることはできません。 これがどのように発生し、どのように復旧するかの詳細については、 可用性グループでレプリカが予期せず削除されたブログを参照してください。