Always On フェールオーバー クラスター インスタンス (SQL Server)

適用対象: SQL Server

SQL Server Always On フェールオーバー クラスター インスタンスは、Windows Server フェールオーバー クラスタリング (WSFC) を使用してローカルの高可用性を提供します。 フェールオーバー クラスター インスタンス (FCI) は、サーバー インスタンス レベルの冗長性を備えています。 FCI は、SQL Server の単一インスタンスで、Windows Server クラスター ノード全体および、場合によっては複数のサブネットにわたりインストールされます。 FCI は、ネットワーク上では 1 台のコンピューターで実行されている SQL Server のインスタンスとして見えますが、現在のノードが使用できなくなった場合には、1 つの WSFC ノードから別の WSFC ノードにフェールオーバーする機能を備えています。

FCI は [Always On 可用性グループ] を使用して、データベース レベルでのリモートのディザスター リカバリーを実現します。 詳細については、「フェールオーバー クラスタリングと可用性グループ (SQL Server)」を参照してください。

フェールオーバー クラスター インスタンスの利点

サーバーのハードウェアまたはソフトウェアに障害が発生すると、そのサーバーに接続しているアプリケーションまたはクライアントで、ダウンタイムが発生します。 冗長ノードは、SQL Server インスタンスがスタンドアロン インスタンスではなく FCI である場合に、可用性を保護します。 一度に FCI 内のノードの 1 つだけが WSFC リソース グループを所有します。 障害 (ハードウェア、オペレーティング システム、アプリケーション、サービスなどの障害) が発生した場合や計画していたアップグレードが行われる場合は、クラスターはリソース グループの所有権を別の WSFC ノードに移動します。 このプロセスは、SQL Server に接続しているクライアントまたはアプリケーションに対して透過的です。 これにより、障害発生時にアプリケーションやクライアントが遭遇するダウンタイムが最小限に抑えられます。 次の一覧は、 SQL Server フェールオーバー クラスター インスタンスの主な利点を示しています。

• 冗長性によるインスタンス レベルでの保護。

• 障害 (ハードウェア、オペレーティング システム、アプリケーション、サービスなどの障害) 発生時の自動フェールオーバー。

  重要

  可用性グループでは、FCI から可用性グループ内の他のノードへの自動フェールオーバーはサポートされていません。 このため、自動フェールオーバーが高可用性ソリューションの重要なコンポーネントである場合は、FCI とスタンドアロン ノードを 1 つの可用性グループ内で組み合わせて使用することはできません。 ただし、ディザスター リカバリー ソリューションではこの組み合わせを使用できます。

• WSFC クラスター ディスク (iSCSI、ファイバー チャネルなど) やサーバー メッセージ ブロック (SMB) ファイル共有などのさまざまなストレージ ソリューションのサポート。

• マルチサブネット FCI を使用している、または FCI によってホストされるデータベースを可用性グループ内で実行しているディザスター リカバリー。 Microsoft SQL Server 2012 (11.x) の新しいマルチサブネット サポートでは、マルチサブネット FCI に仮想 LAN が不要になり、マルチサブネット FCI の管理性とセキュリティが向上します。

• フェールオーバー時にアプリケーションとクライアントの再構成は必要ありません。

• 自動フェールオーバーの詳細なトリガー イベント用の柔軟なフェールオーバー ポリシー。

• 専用接続および永続接続を使用した、定期的および詳細な正常性状態の検出による信頼性の高いフェールオーバー。

• 間接バックグラウンド チェックポイントにより、フェールオーバー時に構成と予測が可能です。

• フェールオーバー時に、リソース使用状況が調整されます。

推奨事項

運用環境の場合:

• 静的 IP アドレスをフェールオーバー クラスター インスタンスの仮想 IP アドレスと組み合わせて使用してください。
• DHCP は、運用環境では使用しないでください。 ダウンタイムが発生した場合に DHCP の IP リース期限が切れると、DNS 名に関連付けられている新しい DHCP IP アドレスの再登録に余分な時間がかかります。

フェールオーバー クラスター インスタンスの概要

FCI は、1 つ以上の WSFC ノードのある WSFC リソース グループで実行します。 FCI が起動すると、ノードの 1 つにリソース グループの所有権が付与され、それによって SQL Server のインスタンスがオンラインにされます。 このノードが所有するリソースは次のとおりです。

• ネットワーク名

• IP アドレス

• 共有ディスク

• SQL Server データベース エンジン サービス

• SQL Server エージェント サービス

• SQL Server Analysis Service サービス (インストールされている場合)

• 1 つのファイル共有リソース (FILESTREAM 機能がインストールされている場合)

任意の時点で、リソース グループ所有者だけがリソース グループ内のそれぞれの SQL Server サービスを実行しています (FCI の他のノードでは実行されません)。 フェールオーバーが発生すると、それが自動フェールオーバーと計画的フェールオーバーのいずれであるかにかかわらず、次の一連のイベントが発生します。

1. ハードウェアまたはシステムの障害が発生しない限り、バッファー キャッシュ内のすべてのダーティ ページがディスクに書き込まれます。

2. リソース グループ内のそれぞれの SQL Server サービスが、すべてアクティブ ノードで停止されます。

3. リソース グループの所有権が FCI の別のノードに転送されます。

4. 新しいリソース グループ所有者が SQL Server サービスを開始します。

5. クライアント アプリケーション接続要求が、同じ仮想ネットワーク名 (VNN) を使用して新しいアクティブ ノードに自動的に送られます。

FCI は、基になる WSFC クラスターが正常なクォーラム状態にある限りオンラインになります (クォーラム WSFC ノードの大半は、自動フェールオーバー ターゲットとして使用できます)。 WSFC クラスターがクォーラムを失うと、その原因がハードウェア、ソフトウェア、ネットワーク障害であるか、不適切なクォーラム構成であるかにかかわらず、WSFC クラスター全体が FCI と共にオフラインになります。 この予定外のフェールオーバー シナリオでは、WSFC クラスターと FCI をオンラインに戻すために、手動介入によって残りの使用可能ノードでクォーラムを再確立する必要があります。 詳細については、「 WSFC クォーラム モードと投票の構成 (SQL Server)」をご覧ください。

予測可能なフェールオーバー時間

SQL Server インスタンスによってチェックポイント操作が最後に実行されたタイミングによっては、バッファー キャッシュに多数のダーティ ページが存在する可能性があります。 このため、フェールオーバーは、残りのダーティ ページをディスクに書き込むまで継続し、フェールオーバー時間が長く予測不能になる場合があります。 Microsoft SQL Server 2012 (11.x) 以降の FCI では、間接チェックポイントを使用して、バッファー キャッシュに保持されるダーティ ページの数を調整できます。 これにより、通常の作業負荷ではリソースの消費が増えますが、フェールオーバー時間の予測や構成が可能になります。 これは、組織内のサービス レベル契約で、高可用性ソリューションの目標復旧時間 (RTO) を指定する場合に非常に役立ちます。 間接的なチェックポイントの詳細については、「 Indirect Checkpoints」を参照してください。

信頼性の高い正常性監視と柔軟なフェールオーバー ポリシー

FCI が正常に開始した後で、WSFC サービスは基になる WSFC クラスターの正常性と SQL Server インスタンスの正常性の両方を監視します。 Microsoft SQL Server 2012 (11.x) からは、WSFC サービスでは専用接続を使用して、アクティブな SQL Server インスタンスにシステム ストアド プロシージャを通じて詳細コンポーネント診断をポーリングします。 これには 3 つの影響があります。

• SQL Server インスタンスへの専用接続により、FCI が非常に高負荷の場合でも、コンポーネント診断を常に確実にポーリングできます。 これにより、高負荷状態のシステムと、実際に障害条件が発生しているシステムを区別できるため、誤ったフェールオーバーなどの問題を回避できます。

• 詳細コンポーネント診断により、より柔軟なフェールオーバー ポリシーを構成できるため、フェールオーバーをトリガーする障害条件とトリガーしない障害条件を選択できます。

• 詳細コンポーネント診断により、自動フェールオーバーをさかのぼってトラブルシューティングすることもできます。 診断情報がログ ファイルに格納され、 SQL Server エラー ログと併置されます。 これらをログ ファイル ビューアーに読み込んで、そのフェールオーバーの原因を判断するためにフェールオーバーの発生までのコンポーネント状態を調査できます。

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

フェールオーバー クラスター インスタンスの構成要素

FCI は、類似するハードウェア構成と同一のソフトウェア構成 (オペレーティング システムのバージョンとパッチ レベル、および SQL Server のバージョン、パッチ レベル、コンポーネント、インスタンス名など) を含む物理サーバー (ノード) のセットから構成されます。 同一のソフトウェア構成は、ノード間でフェールオーバーする際に FCI が完全に機能できるようにするために必要です。

WSFC リソース グループ
SQL Server FCI は、WSFC リソース グループで実行されます。 リソース グループ内の各ノードは、構成設定の同期されたコピーおよびチェックポイントが設定されたレジストリ キーを保持して、フェールオーバー後に FCI が完全に機能し、一度にクラスター内の 1 つのノード (アクティブ ノード) だけがリソース グループを所有するようにします。 WSFC サービスは、サーバー クラスター、クォーラム構成、フェールオーバー ポリシー、およびフェールオーバー操作に加え、FCI の VNN および仮想 IP アドレスを管理します。 障害 (ハードウェア、オペレーティング システム、アプリケーション、サービスなどの障害) が発生した場合や計画していたアップグレードが行われる場合は、リソース グループの所有権が FCI の別のノードに移動します。 WSFC リソース グループでサポートされるノードの数は、お使いの SQL Server のエディションによって異なります。 また、CPU、メモリ、ディスク数などのハードウェア容量に応じて、同じ WSFC クラスターが複数の FCI (複数のリソース グループ) を実行できます。

SQL Server バイナリ
製品バイナリは FCI の各ノードにローカルにインストールされます。これは、 SQL Server スタンドアロン インストールと同様のプロセスです。 ただし、スタートアップ時にサービスが自動的に開始されることはなく、WSFC によって管理されます。

ストレージ
可用性グループとは対照的に、FCI は FCI のすべてのノード間でデータベースとログの格納に共有ストレージを使用する必要があります。 共有ストレージは、WSFC クラスター ディスク、SAN 上のディスク、記憶域スペース ダイレクト (S2D)、または SMB 上のファイル共有の形式にすることができます。 このようにして、フェールオーバーの発生時に、FCI のすべてのノードがインスタンス データについて同じビューを持ちます。 ただし、これは共有ストレージに単一障害点が生じる可能性があり、FCI が基になるストレージ ソリューションに依存してデータ保護を行うことを意味します。

ネットワーク名
FCI の VNN は、FCI に統一された接続ポイントを提供します。 これにより、アプリケーションは、現在アクティブなノードを知らなくても VNN に接続できます。 フェールオーバーが発生した場合、VNN は開始後に新しいアクティブ ノードに登録されます。 この処理は、SQL Server に接続しているクライアントまたはアプリケーションに認識されることなく実行され、これによって障害発生中のアプリケーションおよびクライアントのダウンタイムを最小限に抑えることができます。

仮想 IP
マルチサブネット FCI の場合、FCI の各サブネットに仮想 IP アドレスが割り当てられます。 フェールオーバー時に、DNS サーバー上の VNN は、それぞれのサブネットの仮想 IP アドレスを指すように更新されます。 アプリケーションとクライアントは、マルチサブネット フェールオーバー後に同じ VNN を使用して FCI に接続できます。

SQL Server フェールオーバーの概念とタスク

関連トピック