Windows Server フェールオーバー クラスタリングと SQL Server

適用対象: SQL Server

この記事では、高可用性とディザスターリカバリーのために Windows Server フェールオーバークラスター (WSFC) とSQL Server を使用する方法の概要について説明します。 Windows Server フェールオーバー クラスター (WSFC) は、アプリケーションとサービスの可用性を高めるために連携する独立したサーバーのグループです。 SQL Server は、WSFC サービスと機能を活用して Always On 可用性グループ と SQL Server フェールオーバー クラスター インスタンスをサポートします。

用語と定義

Windows Server フェールオーバー クラスター (WSFC) WSFC は、アプリケーションとサービスの可用性を高めるために連携する独立したサーバーのグループです。

Node
WSFC に参加しているサーバー。

クラスター リソース
物理的または論理的エンティティです。ノードによる所有、オンライン化またはオフライン化、ノード間での移動、クラスター オブジェクトとしての管理が可能です。 特定の時点でクラスター リソースを所有できるのは 1 つのノードのみです。

Role
特定の機能を提供するために単一クラスター オブジェクトとして管理されるクラスター リソースのコレクション。 SQL Server の場合、ロールは Always On 可用性グループ (AG) または Always On フェールオーバー クラスター インスタンス (FCI) となります。 ロールには、AG または FCI に必要なクラスター リソースがすべて含まれます。 フェールオーバーとフェールバックは常にロールのコンテキストで機能します。 FCI の場合では、ロールには IP アドレス リソース、ネットワーク名リソース、SQL Server リソースが含まれます。 AG ロールには AG リソースが含まれ、リスナーが構成されている場合には、ネットワーク名と IP リソースが含まれます。

ネットワーク名リソース
クラスター リソースとして管理されている論理サーバーの名前です。 ネットワーク名リソースは、IP アドレス リソースと共に使用する必要があります。 これらのエントリでは、Active Directory Domain Services および/または DNS 内のオブジェクトが必要な場合があります。

リソースの依存関係
他のリソースが依存するリソースです。 リソース A がリソース B に依存している場合には、B は A の依存関係です。リソース A はリソース B なしでは開始できません。

優先所有者
リソース グループの実行が優先されるノードです。 各リソース グループには、優先順に並べられた優先所有者のリストが関連付けられています。 自動フェールオーバー中に、リソース グループは、優先所有者リスト内の次の優先ノードに移動します。

実行可能な所有者
リソースを実行できるセカンダリ ノードです。 各リソース グループには、実行可能な所有者のリストが関連付けられています。 ロールは、実行可能な所有者としてリストされているノードにのみフェールオーバーできます。

クォーラム モード
クラスターが維持できるノード障害の数を決定するフェールオーバー クラスター内のクォーラム構成です。

クォーラムの強制
クォーラムに必要な少数の要素のみが通信しているときでもクラスターを開始するためのプロセスです。

Windows Server フェールオーバー クラスタリングの概要

Windows Server フェールオーバー クラスタリングは、Microsoft SQL Server や Microsoft Exchange などのホストされるサーバー アプリケーションの高可用性とディザスター リカバリー シナリオをサポートするインフラストラクチャ機能を提供します。 クラスター ノードまたはサービスに障害が発生すると、そのノードでホストされていたサービスは自動的に、または手動で、他の可用性ノードに転送されます。このプロセスを フェールオーバーと呼びます。

WSFC 内のノードは連携して、次のような機能を提供します。

  • 分散メタデータと通知。 WSFC サービスとホストされるアプリケーション メタデータは、クラスター内の各ノードで維持されます。 このメタデータには、ホストされるアプリケーションの設定に加え、WSFC 構成と状態が含まれます。 ノードのメタデータまたは状態の変更は、WSFC 内の他のノードに自動的に反映されます。

  • リソース管理。 WSFC内の個々のノードは、直接接続ストレージ、ネットワークインターフェース、共有ディスクストレージへのアクセスなどの物理リソースを提供する場合があります。 ホストされたアプリケーションは、クラスタリソースとして自身を登録し、他のリソースに対する起動および健全性の依存関係を設定する場合があります。

  • 正常性状態の監視。 ノード間およびプライマリ ノードの正常性状態の検出は、ハートビート ネットワーク通信およびリソース監視の組み合わせによって行われます。 WSFC の全体的な正常性状態は、WSFC 内のノードのクォーラムの投票によって決定されます。

  • フェールオーバーの調整。 各リソースはプライマリ ノードでホストされるように構成され、それぞれ自動的に、または手動で 1 つ以上のセカンダリ ノードに転送されます。 正常性ベースのフェールオーバー ポリシーによって、ノード間でのリソース所有権の自動転送が制御されます。 フェイルオーバーが発生すると、ノードとホストされたアプリケーションに通知が送信され、適切な対応が可能になります。

詳細については、「フェールオーバー クラスタリングの概要- Windows サーバー」を参照してください。

SQL Server Always On テクノロジと WSFC

SQL Server Always On は、WSFC を利用する、高可用性およびディザスター リカバリー ソリューションです。 Always On 機能は、アプリケーションの可用性を高め、ハードウェア投資の回収率を上げ、高可用性配置と管理を簡素化する、統合された柔軟なソリューションを提供します。

Always On 可用性グループ と Always On フェールオーバー クラスター インスタンスのどちらも WSFC をプラットフォーム テクノロジとして使用して、コンポーネントを WSFC クラスター リソースとして登録します。 関連するリソースはロールとしてまとめられ、他の WSFC クラスター リソースに依存するように設定できます。 これによって、WSFC は、SQL Server インスタンスを再起動する必要がある場合はこれを検出して通知したり、WSFC 内の他のサーバー ノードに自動的にフェールオーバーしたりできます。

重要

SQL Server Always On テクノロジの利点を完全に活かすには、WSFC 関連のいくつかの前提条件を適用する必要があります。

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

Always On フェールオーバー クラスター インスタンスとインスタンス レベルの高可用性

Always On フェールオーバー クラスター インスタンス (FCI) は、WSFC 内のノードにまたがってインストールされた SQL Server インスタンスです。 このタイプのインスタンスは、ストレージと仮想ネットワーク名のリソースに依存します。 ストレージは共有ディスク ストレージにファイバー チャネル、iSCSI、FCoE、または SAS を使用したり、記憶域スペース ダイレクト (S2D) でローカルにアタッチされたストレージを使用したりできます。 仮想ネットワーク名のリソースは、それぞれが異なるサブネットに存在する 1 つまたは複数の仮想 IP アドレスに依存します。 SQL Server サービスと SQL Server エージェント サービスもリソースであり、どちらもストレージと仮想ネットワーク名リソースに依存します。

フェールオーバーが発生した場合、WSFC サービスはインスタンスのリソース所有権を指定されたフェールオーバー ノードに転送します。 その後、フェールオーバーノード上で SQL Server インスタンスが再起動され、データベースは通常通り復旧します。 特定の時点で、FCI と基になるリソースをホストできるのは、クラスター内の 1 つのノードのみです。

注意

Always On フェールオーバー クラスター インスタンスには、記憶域ネットワーク (SAN) や SMB ファイル共有などの対称的な共有ディスク ストレージが必要です。 共有ディスク ストレージ ボリュームは、WSFC クラスター内のすべてのフェールオーバー ノードで使用できる必要があります。

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

データベース レベルの高可用性 Always On 可用性グループ

Always On 可用性グループ (AG)とは、共にフェールオーバーする 1 つ以上のユーザー データベースです。 可用性グループは、1 つのプライマリ 可用性レプリカ と、共有ストレージを必要としないデータ保護のために SQL Server ログに基づくデータ移動を介して維持される 1 ~ 4 個のセカンダリ レプリカから構成されます。 各レプリカは、WSFC の別々のノードにある SQL Server のインスタンスによってホストされます。 可用性グループとこれに対応する仮想ネットワーク名は、WSFC クラスターのリソースとして登録されます。

プライマリ レプリカのノード上の 可用性グループ リスナー は、受信クライアント要求に応答し、仮想ネットワーク名に接続します。そして、接続文字列の属性に基づいて各要求を適切な SQL Server インスタンスにリダイレクトします。

フェールオーバーが発生した場合、共有物理リソースの所有権を別のノードに転送するのではなく、WSFCを使用して、別の SQL Serverインスタンス上のセカンダリレプリカを可用性グループのプライマリレプリカとして再構成します。 その後、可用性グループの仮想ネットワーク名リソースが、そのインスタンスに転送されます。

任意の時点で、可用性グループのデータベースのプライマリレプリカをホストする SQL Serverインスタンスは1つだけである可能性があり、関連するすべてのセカンダリレプリカはそれぞれ別のインスタンス上に存在する必要があり、各インスタンスは別の物理ノード上に存在する必要があります。

Note

Always On 可用性グループでは、フェールオーバー クラスター インスタンスを配置する必要はありません。また、対称共有ストレージ (SAN または SMB) を使用する必要もありません。

フェールオーバークラスターインスタンス (FCI) を可用性グループと共に使用して、可用性レプリカの可用性を高めることができます。 ただし、WSFC クラスター内での競合状態の発生を回避するため、FCI 上でホストされる可用性レプリカとの間の可用性グループの自動フェールオーバーはサポートされていません。

詳細については、「Always On 可用性グループの概要に関するページ」を参照してください。

WSFC の正常性監視とフェールオーバー

常時稼働ソリューションの高可用性は、物理的および論理的なWSFCクラスタリソースの積極的な健全性監視と、冗長ハードウェアへの自動フェイルオーバーおよび再構成により実現されます。 また、システム管理者は、可用性グループまたはノード間での インスタンスの 手動フェールオーバー SQL Server を開始できます。

ノード、フェールオーバー クラスター インスタンス、可用性グループのフェールオーバー ポリシー

フェールオーバー ポリシー は、WSFC ノード、SQL Server フェールオーバー クラスター インスタンス (FCI)、可用性グループのレベルで構成されます。 これらのポリシーは、クラスター リソースの異常な状態の重大度、期間、頻度とノードの応答時間に基づいたもので、サービスの再起動のトリガー、ノード間でのクラスター リソースの 自動フェールオーバー のトリガー、 SQL Server インスタンス間での可用性グループ プライマリ レプリカの移動のトリガーを行うことができます。

可用性グループのレプリカのフェールオーバーは、その基盤となる SQL Serverインスタンスには影響を与えません。 FCI のフェイルオーバーにより、インスタンスとともにホストされている可用性グループのレプリカが移動します。

詳細については、「フェールオーバー クラスター インスタンスのフェールオーバー ポリシー」を参照してください。

WSFC リソースの正常性の検出

WSFC 内の各リソースの状態と正常性は、定期的または要求時に報告できます。 さまざまな状況がリソースの故障を示している可能性があります。例えば、停電、ディスクまたはメモリーエラー、ネットワーク通信エラー、応答のないサービスなどです。

ネットワーク、ストレージ、サービスなどの WSFC リソースは、互いに依存するように構成できます。 リソースの累積正常性は、リソース依存関係の正常性で正常性を連続的にロール アップすることで決定されます。

WSFC ノード間の正常性の検出とクォーラム投票

WSFC 内の各ノードは、定期的なハートビート通信に参加し、ノードの正常性状態を他のノードと共有します。 応答しないノードは、エラー状態であると見なされます。

クォーラムは、十分なリソースが WSFC でオンラインになっていることを確認することで、WSFC が確実に稼働するようにするメカニズムです。 WSFC に十分な票があれば、健全であり、ノードレベルのフォールトトレランスを提供できます。

クォーラム モードは、WSFC で構成され、クォーラム投票の方法、および自動フェールオーバーを実行するタイミングまたはクラスターをオフラインにするタイミングを指定します。

ヒント

WSFC のクォーラム投票の数は、常に奇数にすることをお勧めします。 クォーラム投票のために、 SQL Server をクラスター内のすべてのノードにインストールする必要はありません。 追加サーバーはクォーラム メンバーとして機能できます。また、リモート ファイル共有を決定機構として使用するように WSFC クォーラム モデルを構成することもできます。

詳細については、「WSFC クォーラム モードと投票の構成」を参照してください。

強制クォーラムによるディザスター リカバリー

実際の運用状況と WSFC 構成に応じて、自動フェールオーバーと手動フェールオーバーの両方を使用できます。これによって、堅牢でフォールト トレランスな SQL Server Always On ソリューションを維持できます。 しかし、WSFC 内の適格な投票ノードの定足数が互いに通信できない場合、またはWSFC クラスターがその他の理由で健全性検証に失敗した場合、WSFC はオフラインになる可能性があります。

災害や、永続的なハードウェア障害または通信障害が原因で WSFC がオフラインになった場合は、手動で管理操作を実行して、クォーラムを強制し、稼働しているクラスター ノードを非フォールト トレラント構成でオンラインに戻す必要があります。

その後、WSFC を再構成し、影響を受けたデータベース レプリカを復元し、新しいクォーラムを再構築するという一連の手順を実行する必要があります。

詳細については、「WSFC の強制クォーラムによる災害復旧」を参照してください。

SQL Server Always On コンポーネントと WSFC との関係

SQL Server Always On と WSFC の機能およびコンポーネント間には、いくつかのリレーションシップの層が存在します。

Always On 可用性グループは、 SQL Server インスタンスでホストされています。
クライアントは、可用性グループ リスナーの論理ネットワーク名を指定してプライマリまたはセカンダリ データベースに接続することを要求します。この要求は、基になる SQL Server インスタンスまたは SQL Server FCI の適切なインスタンス ネットワーク名にリダイレクトされます。

SQL サーバー インスタンスは、1 つのノード上でアクティブにホストされています。
スタンドアロンの SQL Server インスタンスが存在する場合は、静的なインスタンス ネットワーク名で、常に 1 つのノードにあります。 SQL Server FCI が存在する場合は、1 つの仮想インスタンス ネットワーク名で、2 つ以上のフェールオーバー ノードの中の 1 つのノードでアクティブになります。

ノードは、WSFC クラスターのメンバーです。
すべてのノードの WSFC 構成メタデータと状態は、各ノードに保存されます。 各サーバーは、ユーザーまたはシステム・データベース用に非対称ストレージまたは共有ストレージ (SAN) ボリュームを提供する場合があります。 各サーバーには、1 つまたは複数のサブネット上に少なくとも 1 つの物理ネットワーク インターフェイスがあります。

WSFC は、サーバー グループの正常性を監視し、構成を管理します。
WSFC メカニズムでは、WSFC 構成メタデータと状態の変更が、WSFC 内のすべてのノードに反映されます。 ディスク監視が使用されている場合は、メタデータもそこに格納されます。 既定では、WSFC の各ノードはクォーラムに対する投票を取得し、必要に応じてミラーリング監視サーバーが使用され、構成されます。

Always On 可用性グループ レジストリ キーは WSFC クラスターのサブキーです。

WSFC を削除してから再作成した場合は、Always On 可用性グループ を有効にしていた、元の WSFC の各サーバー インスタンスについて、Always On 可用性グループ 機能を無効にしてから再度有効にする必要があります。 詳細については、「Always On 可用性グループの有効化と無効化」を参照してください。

Windows Server フェールオーバー クラスターのスクリーンショット。

関連タスク