次の方法で共有


フェールオーバー クラスタリングと 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 可用性グループの概要 (SQL Server)」を参照してください。

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 クォーラムについては、「Windows Server フェールオーバー クラスタリング (WSFC) と SQL 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)」の「SQL Server のフェールオーバー クラスター インスタンス (FCI) を使用して可用性レプリカをホストするための前提条件と制限」を参照してください。

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

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 インスタンスのどちらでホストされているかに関係なく、すべてのレプリカに適用されます。

注意

SQL Server の各エディションにおける FCI 内のノード数および Always On 可用性グループの詳細については、「SQL Server 2012 の各エディションがサポートする機能」 (https://go.microsoft.com/fwlink/?linkid=232473) を参照してください。

FCI で可用性レプリカをホストする場合の考慮事項

重要

SQL Server フェールオーバー クラスター インスタンス (FCI) で可用性レプリカをホストすることを計画している場合は、Windows Server 2008 ホスト ノードが Always On の前提条件およびフェールオーバー クラスター インスタンス (FCI) の制限を満たしていることを確認してください。 詳細については、「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 つのノードで構成します。 NODE01fciInstance1の現在の所有者である NODE01NODE02 の両方に、SQL Server フェールオーバー クラスター インスタンス (fciInstance1) をインストールします。
NODE02では、スタンドアロン インスタンスである SQL Server Instance3の別のインスタンスをインストールします。
NODE01では、Always On 可用性グループに対して fciInstance1 を有効にします。 NODE02では、Always On 可用性グループの Instance3 を有効にします。 次に、fciInstance1 がプライマリ レプリカをホストし、セカンダリ レプリカをホスト Instance3 可用性グループを設定します。
あるとき、fciInstance1 上の NODE01 が利用できなくなり、WSFC によって fciInstance1NODE02 にフェールオーバーされたとします。 フェールオーバー後の fciInstance1 は、 Always On 可用性グループ上でプライマリ ロールとして動作する NODE02対応のインスタンスです。 しかし、この時点で Instance3 は、 fciInstance1と同じ WSFC ノードに存在します。 これは Always On 可用性グループ の制約に違反します。
このシナリオで起きる問題を回避するには、スタンドアロン インスタンス ( Instance3) が、NODE01NODE02 と同じ WSFC 内の別のノードに存在している必要があります。

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

WSFC フェールオーバー クラスター マネージャーを使用した可用性グループの操作に関する制限事項

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

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

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

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

警告

フェールオーバー クラスター マネージャーを使用して、可用性グループをホストしているフェールオーバー クラスター インスタンスを、同じ可用性グループのレプリカを "すでに" ホストしているノードに移動すると、可用性グループのレプリカが失われ、それによってターゲット ノード上でオンラインにできなくなる可能性があります。 フェールオーバー クラスターの 1 つのノードでは、同じ可用性グループの複数のレプリカをホストすることはできません。 これがどのように発生し、どのように回復するかの詳細については、ブログ記事の「Replica unexpectedly dropped in availability group」(可用性グループでレプリカが予想外に削除される) を参照してください。

関連コンテンツ

参照

Always On 可用性グループの概要 (SQL Server)
AlwaysOn 可用性グループの有効化と無効化 (SQL Server)
可用性グループの監視 (Transact-SQL)
Always On フェールオーバー クラスター インスタンス (SQL Server)