SQL Server 2012 で追加された AlwaysOn 可用性グループ (AlwaysOn Availability Group) ですがフェールオーバーに影響する設定がいくつかあります。
今回の投稿ではどのような設定があるかまとめてみたいと思います。
■フェールオーバーに影響する設定
フェールオーバーに影響するものとして以下の 3 種類の設定があります。
- FailureConditionLevel
- HeathCheckTimeout
- SESSION_TIMEOUT
最初の 2 つについてはクラスターリソースのプロパティになります。
AlwaysOn 可用性グループ用に SQL Server Availability Group のクラスターリソースが作成されます。
このクラスターリソースのプロパティとして設定ができるものになります。
FailureConditionLevel はどのような事象を検知した場合にフェールオーバーを行うかを設定するものになります。
レベルと条件の関係については 可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー (SQL Server) に記載されています。
この設定は AlwaysOn ファイルオーバークラスターインスタンス (AlwaysOn Failover Cluster Instance : FCI) でも使用できるのですが、FCI の場合とは設定できる値が異なっています。
フェールオーバー クラスター インスタンスのフェールオーバー ポリシー
可用性グループでは1 ~ 5 となっていますが、FCI では 0 ~5 となっています。
この設定を変更することでフェールオーバーする条件を変更することができます。
# ユーザーが何段階かで条件を変更することができるために柔軟なフェールオーバーポリシーと呼ばれています。
HeathCheckTimeout についてはHealthCheckTimeout プロパティ設定の構成 に記載されています。
AlwaysOn 可用性グループでは sp_server_diagnostics を使用して SQL Server の状態を取得しています。
このストアドプロシージャを使用して先ほどの FailureConditionLevel の情報を取得しています。
この情報を取得する際のタイムアウト設定が HeathCheckTimeout になります。
# 可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー (SQL Server) にも情報が記載されていますね。
SQL Server のサービスが起動していてクエリが正常に実行できる状態なのかをこのタイムアウト値を使用して確認をしています。
可用性グループの正常性チェックのタイムアウトしきい値の 3 分の 1 の間隔で結果を返します。
とあるように設定値の 1/3 の間隔で実行されているようです。
SQL Server 2008 R2 まではクラスターのリソースが定期的に SELECT @@VERSION を実行していましたが、SQL Server 2012 では sp_diagnostics を実行するスレッドが常駐して監視を行うようになっています。
最初に常駐で実行されますので、ワーカースレッドの枯渇で SQL Server で新規のクエリが実行できない場合などにも対応できるようになっているようです。
クラスターリソースのタイムアウト関連のプロパティとしてもう一つ LeaseTimeout という設定があるのですがこの設定に関しては BOL に情報が見当たりませんでした。
How It Works: Failover Cluster/Availability Group XEL Logging Frequency のコメントで開設されているのですが、この設定値の 1/3 の間隔でクラスターリソースと SQL Server 間でリソースの維持が行われているようです。
スプリットブレインへの対応などをするための操作で使われているようですね。
可用性レプリカのセッション タイムアウト期間の変更 (SQL Server) と AlwaysOn 可用性グループの概要 (SQL Server) に記載されています。
データベースミラーリングでは DBM Ping と呼ばれるものでプリンシパルとミラーの死活監視が行われていましたが AlwaysOn 可用性グループでも Ping による死活監視が行われています。
ミラーリングと同様で Ping と呼ばれていますが ICMP が使用されているのではなくエンドポイントのポートを使用して監視を行っているようです。
Network Monitor のようなパケットキャプチャのソフトを使用すると確認ができるのですが、プライマリとセカンダリ間ではミラーリングエンドポイントのポート (初期の設定だと TCP : 5022) を使用して、毎秒通信が行われています。
データ同期で使用されているエンドポイントのポートは SQL Server が起動したタイミングでオープンされますので SQL Server が起動していない状況などもこれで把握ができるようですね。
遠隔地にセカンダリを配置して、ネットワークの遅延が発生しそうな場合にはデフォルトの 10 秒から変更をすることで調整をすることができます。
# 間隔を延ばすとそのサーバーの SQL Server の死活監視の許容期間が延びますので遠隔地に配置した非同期モードのセカンダリに対して間隔を延ばすために使用するケースが多いと思います。
可用性グループのフェールオーバーに関する設定の大きなところに関しては以上のようになると思います。
可用性グループはクラスターのテクノロジを使用していますので、クラスターグループのフェールオーバー回数 (時間内のエラーの許容数) にも気を付ける必要がありますが。
# 可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー (SQL Server) にも記載されていますね。
また、正常性チェックのタイムアウトしきい値 にも記載されていますが、状態を監視するために使用されている sp_server_diagnostics はインスタンスの状態を監視するものであり、データベース単位の状態を監視するものではありません。
プロセスやネットワークがダウンした場合は監視ができますが、データベースを格納しているハードディスクを抜いて、DB に意図的に以上を発生させた場合などは検知ができなかったはずです。
# iSCSI のディスクや VHD マウント、ゲスト OS に SCSI ディスクを接続するとディスクを抜くというシナリオを再現できます。
高可用性のソリューションを使用する場合、どのようなことが起因し待機系が使用されるかは意識をしておきたいですね。