こんにちは。今日は、SQL Serverの高可用性オプションの一つとして登場するAlways Onフェールオーバークラスターインスタンスについて調べてみましたので、学んだことを記事にまとめておきたいと思います。
（図解と書いたけど図１個しかなかった・・また足していきます）
同じことを勉強している方の参考になりましたら幸いです。
Contents
AlwaysOnフェールオーバークラスターインスタンス（FCI）とは？
- SQL ServerのAlwaysOn機能の一つ。（他には、AlwaysOn 可用性グループ：AGがある）
- Windows Server Failover Clustering (WSFC) 機能を利用して、サーバー インスタンス レベルの冗長性を通じてローカルの高可用性を提供する
- FCIはSQL Serverの単一インスタンスであり、Windows Server Failover Clustering (WSFC) ノードと、場合によっては複数のサブネットにインストールされる
- ネットワーク上では、FCI は 1 台のコンピューターで実行されている SQL Server のインスタンスのように見えるが、現在のノードが使用できなくなった場合、FCI は WSFC ノード間でフェールオーバーを実施して、可用性を維持する
参考：
AlwaysOnフェールオーバークラスターインスタンス（FCI）のメリット
FCIを利用することによるメリットの一部は以下です。
- インスタンス レベルの冗長性
- 障害 (ハードウェア、オペレーティング システム、アプリケーション、サービスなどの障害) 発生時に自動フェールオーバー
- フェールオーバー時にアプリケーションとクライアントの再構成が不要
- フェールオーバー ポリシーにより自動フェールオーバーの動作を柔軟に制御できる
参考：
AlwaysOnフェールオーバークラスターインスタンス（FCI）の構成
公式ドキュメントの図解が不足しすぎていて、これしか見つけられませんでした笑 （初心者には厳しい・・・笑）AGの説明も混ざっていますが、右側にちらっとFCIの絵が描かれています。
これと、ドキュメントの記載をにらめっこすると、以下のように理解できます。（一部絵には表れていない要素の説明もありますが・・）
- FCIとWSFC リソース グループ：
- FCIは複数のノードにまたがった単一のSQL Serverインスタンス。
- FCIはWSFCリソースグループ上で動作する。
- WSFC サービスは、サーバー クラスター、クォーラム構成、フェールオーバー ポリシー、フェールオーバー操作、FCI の VNN および仮想 IP アドレスなどを管理する。
- フェールオーバが発生すると、所有権がFCIの別のノードに移る。
- FCIに含めることができるノード数はSQL Serverのエディションによる。
- SQL Server：
- SQL ServerはFCIの各ノードのローカルにインストールされる。
- ただし、サービスの開始・停止はWSFCによって管理される
- 共有ストレージ：
- FCIは、データベースとログの格納のためにすべてのノード間で共有されたストレージを利用する必要がある。
- これにより、フェールオーバー時FCIの全ノードが同じデータを共有することができる。
- ただし一方で、ストレージが単一障害点になる可能性もある。
- 共有ストレージは、WSFCクラスターディスク、SAN上のディスク、記憶域スペースダイレクト（S2D）、SMB上のファイル共有の形式にすることができる。
- 仮想ネットワーク名（Virtual Network Name）：
- FCIに統一された接続エンドポイントを提供。
- これによって、接続元はFCI内のアクティブなノードを意識する必要がなくなる。
- フェールオーバーが発生すると、このネットワーク名には新しいアクティブ ノードが登録される。
- 仮想IPアドレス：
- 複数のサブネットにFCIが存在する場合、FCIの各サブネットに仮想IPアドレスが割り当てられる。
- フェールオーバー時、DNSのネットワーク名は、それぞれのサブネットの仮想IPアドレスを指すように自動的に更新される。
- これによって、接続元はフェールオーバー後も同じネットワーク名を利用してSQL Serverに接続できる。
参考：
フェールオーバー時の動作
基本的なFCIのフェールオーバ時の動作は、以下のようになります。
- ハードウェアまたはシステムの障害が発生しない限り、バッファー キャッシュ内のすべてのダーティ ページがディスクに書き込まれる
- リソースグループ内のアクティブなノードのSQL Serverの各サービスが停止される
- リソース グループの所有権が FCI の別のノードに移る
- 新しいリソース グループ所有者となったノードで、SQL Serverサービスが開始される
- クライアント アプリケーションからの接続は、同じ仮想ネットワーク名 (VNN) を使用して新しいアクティブ ノードに自動的に送られる
ではそもそも、どういった場合にフェールオーバーが発生するのでしょうか。
- WSFCクラスターが正常なクォーラム状態である限り、FCIはオンライン状態
- WSFCクラスターがクォーラムを失うと、WSFCクラスター全体がオフラインになる（予定外のフェールオーバー）。
- このようなのシナリオ場合、WSFCとFCIをオンラインに戻すために、手動で、残りの利用可能なノードでクォーラムの再構成を行う必要がある。
参考：
WSFCのクォーラムについては、別の記事にまとめました。
フェールオーバーポリシーと正常性監視
実はフェールオーバーは、上記のクォーラムに基づく方法以外でもトリガーするようにできます。これを実現する機能が、フェールオーバーポリシーです。
フェールオーバーポリシーを利用すると、FCIがフェールオーバーする障害条件を柔軟に設定できるようになります。
でも、そもそも構成した障害条件に一致する状況が発生しているか、どのように判断するのでしょうか。ここで活用されるのが、WSFCサービスがWSFCクラスターおよびSQL Serverに対して行う正常性監視の結果です。
この機能の概要を以下にまとめました。
- FCIが開始されると、WSFCサービスが、WSFCクラスターおよびFCI上のSQL Serverの正常性監視を行う。
- SQL Server 2012 (11.x)以降、WSFCサービスは専用接続を利用して、正常性監視（アクティブな SQL Server インスタンスが、コンポーネントの診断セットをWSFCリソースグループに定期的に報告する）できるようになった。これによって・・・
- 診断専用の接続を利用するので、FCIの負荷が高い場合も確実に正常性の診断が行える。（＝診断の問題による誤ったフェールオーバーを防げる）
- 診断結果をもとに、より柔軟なフェールオーバーポリシーを構成可能
- 診断結果は蓄積されるので、過去にさかのぼって自動フェールオーバーのトラブルシューティングを行える。
- 診断は、具体的にはSQL Serverインスタンス上でシステム ストアド プロシージャ sp_server_diagnosticsを定期的に実行することで行われる。
- SQL ServerデータベースエンジンリソースDDLが、検出された正常性状態がエラー条件に該当するかどうかを判定する
- 受け取った診断結果に対して、WSFCサービスがどのように対処するのかは、WSFCクォーラムの状態などに依存。
参考：
AlwaysOn可用性グループ（AG）との違いは？どう使い分ける？
さて、ここまでFCIの概要についてみてきましたが、そもそも同じAlwaysOn機能として提供されている可用性グループとFCIでは何が違うのでしょうか？また、結局のところどちらを使うのが良いのでしょうか。
この点については、以下のドキュメントに言及されていましたので、参考になるかと思います。
違いについては、以下のように言及されています。
- FCIでは高可用性は提供されるが、ディザスタリカバリ（＝災害復旧＝問題が発生したときの復旧（手動でクォーラムを再構成すれば復旧はできるから、自動で復旧されない、という意図かな・・？））がサポートされていない
- AGでは共有ストレージを利用しないため、FCIと比べて構成が容易
- FCIでは共有ストレージを利用する分、ストレージが単一障害点になる可能性がある
また、こちらのブログにもわかりやすく整理されていました。
使い分けについては、公式ドキュメントに以下の記載があります。
AG が導入されるまでは、SQL Server の高可用性を導入する方法として FCI が最も一般的でした。 しかし FCI が設計されたのは、物理的なデプロイが主流の時代です。 仮想化された環境では、FCI で提供される保護の多くが、物理ハードウェアの場合と同じようには提供されません。VM で問題が発生するのはまれであるためです。 FCI は、ネットワーク カードの障害やディスクの障害に対する保護を想定して設計されましたが、そのどちらも、Azure で発生する可能性は低くなっています。
とはいえ、Azure でも FCI を利用する価値はあります。 FCI は役に立ちます。提供されるものとされないものとを正しく理解していれば、しっかり条件にかなったソリューションとなります。
https://docs.microsoft.com/ja-jp/learn/modules/describe-high-availability-disaster-recovery-strategies/6-explore-iaas-high-availability-disaster-recovery-solution
ということで、AlwaysOn可用性グループ(AG)の登場や、クラウドなどの仮想環境上での運用が増えた現在においては、AGの利用が一般的ではあるようですが、全く必要がなくなったかというとそうではなく、FCIを使うシナリオはある、との見解のようです。
以上、SQL Serverのフェールオーバークラスターインスタンスの概要についてのまとめでした。
ご参考になりましたら幸いです。また、この記事が少しでも参考になりましたら、以下のいいねボタンをポチっていただけると励みになります！
おしまい
コメントを残す