【Part2:AG構成編】Azure VM上のSQL ServerにAlways On可用性グループを構成してみた

こんにちは。「Azure VM上のSQL ServerにAlwaysOn可用性グループを構成してみた」第二部 AG構成編です。

それではさっそくまいります。

前回の記事：事前準備編

今回の記事は、以下の記事で実施した事前準備が完了している前提なので、まだであればPart1からお試しいただければと思います。

AlwaysOn可用性グループの構成ステップ

ここからのステップでは、以下のチュートリアルに従って進めています。

チュートリアル:可用性グループを手動で構成する (Azure VM 上の SQL Server)

https://docs.microsoft.com/ja-jp/azure/azure-sql/virtual-machines/windows/availability-group-manually-configure-tutorial-single-subnet?view=azuresql

フェールオーバークラスターを作成する

まずはフェールオーバークラスターの作成です。プライマリのSQL Server VM（sqlserver-0）にInstallユーザでログインした上で作業を進めていきます。

Windows Serverマネージャ > Tools > Failover Cluster Managerで、新規クラスターの作成。

ここでまずはsqlserver-0を追加。

このオプションはNoを選択して

クラスター名をつけて・・

作成完了。

ここで、Windows Server 2019以降の場合は分散サーバ名、というものが作成されていることが確認できます。（これを使うとVNNリスナー + Azure Load Balancerが不要になるらしい）

クラスターにSQL Serverノードを追加する

先ほどの画面から、もう一台のSQL Serverもクラスタに追加します。

クラスタークォーラムファイル共有を作成する

次はクォーラム監視用のファイル共有を作成します。

これは、監視用VM “cluster-fsw”でInstallアカウントでログインして作業を実施。

Windows Server Manager > Tools > Computer ManagementのShared Folders > Sharesを右クリックして新規ファイル共有の作成。

適当なディレクトリ（じゃだめなのかもしれないですがチュートリアル手順に特に指示はなかったのでDocuments配下に適当なディレクトリを作成）を指定して・・・

“Install”ユーザにFull Control権限を与えておく。

クラスタークォーラムを構成する

次にクォーラムの構成。具体的には、上で作成したファイル共有をクォーラム監視で利用するように設定していきます。

プライマリのSQL Server VMから、Windows Server Manager > Tools > Failover Cluster Manger > Configure Cluster Quorum Settingsを開いて・・

Quorum Witnessオプションを選択し・・・

ファイルサーバ監視オプションを選択し・・・

先ほどのファイル共有のパスを指定して・・

設定完了！

Unable to save property changes for file ‘Property Witness’エラーが出る

上の手順で、最後以下のようなAccess is deniedのエラーが出ることがあります。

これは、フェールオーバークラスター”SQLAGCluster”に必要な権限がないからの模様。クォーラム監視用ファイル共有で、SQLAGClusterにFull Control権限を与えると成功するようになりました。（手順に書いてなかった気が・・）

可用性グループを有効にする

次に可用性グループの有効化。このAGを構成するには事前にこの機能を有効化しておく必要があるみたいですね。

SQL Server Configuration Managerから、チェックをいれます。これを2台のSQL Serverそれぞれで実施。

プライマリSQL Serverでデータベースを作成する

次にプライマリのSQL Serverでデータベースを作成。

データベースバックアップ用のファイル共有を作成する

それから可用性グループを構成するときに必要なデータベースバックアップ用のファイル共有を作成。プライマリSQL Serverの適当なディレクトリを指定しました。

このファイル共有には、2台のSQL Server両方がアクセスできる必要があるので、アクセス権を付与しておきます。（試してみて分かりましたが、下の”Security”タブの方でも同様に権限を追加しておく必要がありました）

データベースの完全バックアップを取得する

次にプライマリSQL Serverで先ほど作成したデータベースの完全バックアップを取得。

可用性グループを構成する

ここまできてようやく最後のステップ、可用性グループの構成。

プライマリSQL ServerでSSMS > Always On High Availabilityを右クリックして新規可用性グループの作成に進みます。

先ほどのデータベースを指定して

セカンダリSQL Serverをレプリカとして追加し、

ミラーリングエンドポイントのポートがファイアウォールで穴あけ許可したポートと一致していることを確認しつつ

Full database and log backup & バックアップ用ファイル共有のパスを指定し・・

検証をパスしたら・・・

構成完了。

作成したAGを右クリック > Show Dashboardから、可用性グループの状況が確認できるようになりました。（AG構成時にレプリカの同期方式を同期コミットにしていると、セカンダリが”Synchronized”に、非同期だと”Synchronizing”になっている想定）

さて、ここまでのステップで、可用性グループ内のレプリカが同期できるようになりましたが、リスナーが存在しないのでまだ外部から接続することはできません。

次の記事では、このリスナーを構成する手順を確認していきたいと思います。今回も最後までご覧いただきありがとうございました。

余談

とここまで書いておいてあれなのですが、2022年5月末現在、Azure VMのSQL ServerでもAzureポータル上からの構成が可能になっているようですね。（ただしプレビュー）こちらを使うともっと簡単に構成できそうなので、また試してみたいと思います。

＊上の手順で手動で構成した場合でも、ちゃんとポータルに反映されています。

おしまい