SQL Server Always On 可用性グループの構成手順とフェイルオーバー検証ガイド

本記事では、Windows Server 2019 上で稼働する SQL Server に Always On 可用性グループ(Availability Groups) をインストールおよび構成する手順を、ステップバイステップで詳しく解説します。フェイルオーバーのシナリオや、構成時に遭遇しやすいトラブルとその対処法についても取り上げます。

Always On 可用性グループは、Microsoft SQL Server に高可用性を提供する機能で、SQL Server 2012 から導入されました。

SQL Server Always On 可用性グループの主な機能

SQL Server の可用性グループは、以下のような用途に活用できます。

• MS SQL の高可用性と自動フェイルオーバー
• ノード間での SELECT クエリの負荷分散(セカンダリレプリカを読み取り専用として利用可能)
• セカンダリレプリカからのバックアップ取得
• データの冗長化。各レプリカが可用性グループのデータベースのコピーを保持します。

Always On は Windows Server フェイルオーバークラスタリング(WSFC) を基盤としています。WSFC が可用性グループのノードを監視し、自動フェイルオーバーを実現します。なお、SQL Server 2017 以降では、WSFC を使用しない構成や、Linux 環境でも Always On を利用できるようになりました。Linux ベースのクラスタを構築する場合は、WSFC の代わりに Pacemaker を使用します。

Standard エディションでの制限事項

Always On は Standard エディションでも利用可能ですが、以下の制限があります。

• レプリカは 2 つまで(プライマリとセカンダリ)
• セカンダリレプリカをデータの読み取りに使用できない
• セカンダリレプリカからバックアップを取得できない
• 1 つの可用性グループにつき 1 データベースのみサポート

Enterprise エディションではこれらの制限はありません。

基本用語の整理

• Always On 可用性グループ:レプリカとデータベースの集合体です。
• レプリカ:可用性グループに参加する SQL Server インスタンスです。プライマリまたはセカンダリのロールを持ち、各レプリカには 1 つ以上のデータベースを含めることができます。

Always On は WSFC を基盤としているため、可用性グループの各ノードは Windows フェイルオーバークラスタのメンバーである必要があります。各 SQL Server インスタンスは複数の可用性グループを持つことができ、1 つの可用性グループには最大 8 つのセカンダリレプリカを設定できます。

プライマリレプリカに障害が発生すると、クラスタが新しいプライマリレプリカの投票を行い、Always On がセカンダリレプリカの 1 つをプライマリに昇格させます。ユーザーは Always On の動作中、リスナー(Listener)(専用のクラスタ IP アドレスと対応する DNS 名)に接続するため、フェイルオーバー後も書き込みクエリを継続して実行できます。リスナーは、セカンダリレプリカ間での SELECT クエリの負荷分散も担います。

Always On 可用性グループ向け Windows フェイルオーバークラスタの構成

まず、Always On で使用するすべてのノードにフェイルオーバークラスタを構成する必要があります。

今回の検証環境は以下のとおりです。

• Windows Server 2019 を稼働する仮想マシン 2 台
• SQL Server 2019 Enterprise インスタンス 2 つ
• ノードのホスト名は testnode1 と testnode2。SQL Server インスタンス名は node1 と node2。

フェイルオーバークラスタリング機能のインストール

サーバーマネージャーから フェイルオーバークラスタリング の役割を追加するか、PowerShell で以下のコマンドを実行してインストールします。

Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools

インストールは自動的に完了し、現時点で追加の設定は不要です。フェイルオーバークラスターマネージャー(FailoverClusters.SnapInHelper.msc)を起動し、新しいクラスタを作成します。

クラスタの作成手順

ウィザードに従い、クラスタに参加させるホスト名を追加します。次に検証テストの実行を求められるので、最初の項目(すべてのテストを実行)を選択します。

続けて、クラスタ名を指定し、ネットワークとクラスタの IP アドレスを選択します。クラスタ名は DNS に自動的に登録されるため、DNS レコードを手動で作成する必要はありません。ここではクラスタ名を ClusterAG とします。

「対象となるすべての記憶域をクラスターに追加する」のチェックは外しておきましょう。ディスクは後から追加できます。

クラスタクォーラムの設定

クラスタが 2 ノード構成の場合は、クラスタクォーラム(Cluster Quorum) の設定が必須です。クォーラムは決定票の役割を果たします。たとえば、クラスタノードの 1 台が利用できなくなった場合、クラスタはどのノードが実際にオンラインで相互に通信可能かを判定しなければなりません。クォーラムはこのクラスタの一貫性を保証します(クラスタ → その他の操作 → クラスタクォーラム設定の構成)。

クォーラム監視のオプションを選択し、監視の種類として ファイル共有監視(File Share Witness) を指定します。共有フォルダーへの UNC パスを入力してください。このディレクトリは事前に手動で作成し、フェイルオーバークラスタ外のサーバー上に配置する必要があります。

ファイル共有監視の構成エラーと対処法

クラスタ構成時に、次のようなエラーが表示されることがあります。

There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.

このエラーは、クラスタが実行されているユーザーアカウントに、共有フォルダーへの NTFS アクセス権限がないことが原因である可能性が高いです。既定では、クラスタはローカルユーザーアカウントで実行されます。フォルダーに対してクラスタの全コンピューターオブジェクトに権限を付与するか、クラスタサービスのアカウントを変更して適切な権限を付与してください。

これで Windows フェイルオーバークラスタの基本構成は完了です。

MS SQL Server での Always On 可用性グループの構成

SQL Server インスタンスを標準的な手順でインストールしたら、Always On 可用性グループを有効化して構成します。SQL Server 構成マネージャー のインスタンスのプロパティで有効化します。スクリーンショットのとおり、SQL Server は既に WSFC クラスタに所属していることを検出しています。「AlwaysOn 可用性グループの有効化」にチェックを入れ、MSSQL インスタンスのサービスを再起動してください。2 台目のインスタンスでも同じ操作を行います。

ヒント: Always On を構成する前に、SQL Server サービスがローカルシステムアカウントで実行されていないことを確認してください。グループ管理サービスアカウント(gMSA)または通常のドメインアカウントの使用を推奨します。そうしないと、Always On の構成を完了できません。

可用性グループウィザードでの設定

SQL Server Management Studio(SSMS)を起動してホストに接続し、「Always On 高可用性」を右クリックして 「新しい可用性グループウィザード」を実行します。

なお、SQL Server 2017 および SQL Server 2019 向けの SSMS 18.x では、従来 T-SQL でのみ設定できた Always On の項目が GUI に追加されています。最新バージョンの SSMS を使用することを推奨します。

可用性グループの名前を指定し、「データベースレベルの正常性検出(Database Level Health Detection)」を選択します。このオプションを有効にすると、Always On がデータベースレベルの異常を検出できるようになります。

可用性グループに追加する SQL Server データベースを選択します。

レプリカの追加と各パラメータの意味

「レプリカの追加」をクリックして、2 台目の SQL Server に接続します。この方法で最大 8 台のサーバーを追加できます。

• 初期ロール(Initial Role):グループ作成時点でのレプリカのロールです。プライマリまたはセカンダリのいずれかになります。
• 自動フェイルオーバー(Automatic Failover):データベースが利用できなくなった場合、Always On がプライマリロールを別のレプリカに移行します。必ずチェックを入れましょう。
• 可用性モード(Availability Mode):同期コミットまたは非同期コミットを選択します。同期モードを選択した場合、プライマリレプリカに届いたトランザクションは、同期モードに設定されたすべてのセカンダリレプリカに送信されます。プライマリレプリカは、他のレプリカがディスクに書き込みを完了した後にのみトランザクションを確定します。そのため、プライマリレプリカに障害が発生してもデータ損失が発生しません。非同期モードでは、プライマリレプリカは他のレプリカの応答を待たずに即座に変更を書き込みます。
• 読み取り可能なセカンダリ(Readable Secondary):セカンダリレプリカに対して SELECT クエリを実行できるようにするパラメータです。「はい」を設定した場合、クライアントは ApplicationIntent=readonly を指定しなくても読み取り専用アクセスが可能になります。
• コミットに必要な同期セカンダリの数(Required synchronized secondaries to commit):トランザクションを確定するために必要な、同期済みセカンダリレプリカの数です。レプリカの数に応じて設定します。ここでは 1 に設定します。

エンドポイント(Endpoint) タブでは何も変更しないでください。

バックアップの基本設定(Backup Preferences) タブでは、バックアップの取得元を選択できます。ここでは既定の 「セカンダリを優先(Prefer Secondary)」のままにします。

リスナーの作成

可用性グループリスナーの名前、ポート、IP アドレスを指定します。

読み取り専用ルーティング(Read-Only Routing) の設定は変更せずそのままにします。

レプリカの同期タイプを選択します。ここでは最初の項目の 「自動シード処理(Automatic seeding)」にチェックを入れたままにします。

その後、設定内容の検証が行われます。エラーがなければ「完了」をクリックして変更を適用します。

リスナー作成時のエラー(EVENTID 1194)と対処法

検証環境では、すべてのテストに成功しましたが、インストール後の結果画面で、可用性グループリスナーの作成エラーが表示されました。クラスタのイベントログには次のエラー(EVENTID 1194)が記録されていました。

Cluster network name resource failed to create its associated computer object in the domain.

これは、クラスタにリスナーを作成するための十分な権限がないことを意味します。ドキュメントによれば、クラスタのコンピューターオブジェクトに対して「コンピューターオブジェクトの作成」権限を付与すれば十分です。AD で権限の委任を行うのが簡単です(手軽ですが安全でない方法としては、CLUSTERAG$ オブジェクトを一時的に Domain Admins グループに追加する方法もあります)。

なお、Always On のトラブルシューティングや可用性グループにおける SQL のパフォーマンス問題を診断する際は、SQL Server の標準的な診断ツールに加えて、Windows クラスタのログも入念に調査することをお勧めします。

今回は可用性グループは作成できたもののリスナーが作成できていなかったため、手動で追加しました。可用性グループのコンテキストメニューを開き、「リスナーの追加」をクリックします。

リスナーの IP アドレス、ポート、DNS 名を指定します。Always On グループの 「可用性グループリスナー」セクションにリスナーが表示されていることを確認してください。

以上で、Always On 可用性グループの基本構成は完了です。

SQL Server Always On の動作確認とフェイルオーバー検証

まず、可用性グループダッシュボード(ダッシュボードの表示)を確認してみましょう。

グループが作成され、正常に動作していることがわかります。

手動フェイルオーバーの実施

次に、node2 を手動でプライマリインスタンスに切り替えてみます。可用性グループを右クリックして 「フェールオーバー」を選択します。

「フェールオーバーの準備(Failover Readiness)」の値に注目してください。「データ損失なし(No data loss)」と表示されていれば、データを失うことなく切り替え可能です。

node2 に接続して「完了」をクリックします。node2 が可用性グループのプライマリレプリカ(プライマリインスタンス)になったことを確認してください。

リスナー経由の接続確認

リスナーが正常に動作していることを確認します。SSMS では、リスナーの DNS 名とポートをカンマで区切って指定します(例:ag1-listener-1,1445)。

データベースに対して、簡単な INSERT、SELECT、UPDATE の SQL クエリを実行してみましょう。

自動フェイルオーバーの検証

続いて、プライマリレプリカの自動フェイルオーバーを確認します。TESTNODE2 上の sqlservr.exe プロセスを強制終了してください。

残ったノード(TESTNODE1\NODE1)で可用性グループの状態を確認します。

testnode2\node2 が利用できなくなったため、クラスタが自動的に testnode1\node1 のステータスをプライマリに変更しました。

クライアントはリスナー経由で接続するため、リスナーの状態も確認します。

「クォーラム不足」エラーの原因と解決策

検証環境ではリスナーへの接続には成功しましたが、データベースにアクセスしようとすると、次のエラーが発生しました。

Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.

このエラーは、「コミットに必要な同期セカンダリの数」オプションが原因で発生しました。構成時にこの値を 1 に設定したため、残っているのがプライマリレプリカ 1 台だけの状態では、Always On がデータベースへの接続を許可しないのです。

この値を 0 に変更して、再度クエリを実行してみてください。

testnode1 はプライマリインスタンスのステータスを維持し、testnode2 はセカンダリになりました。testnode2 の電源が切れていた間に testnode1 上で変更されたデータは、コンピューターの起動後に正常に同期されました。

これで、すべてが正しく動作しており、重大な障害が発生した場合でもデータが読み書き可能な状態で維持されることを確認できました。

Always On 可用性グループは比較的簡単に構成できます。SQL Server ベースのフェイルオーバーソリューションを構築したい場合、可用性グループは非常に有効な選択肢となるでしょう。