Azure SQL仮想マシンでドメインに依存しないAlwaysOn可用性グループを構成してみた

こんばんは。今日は、SQL Serverの「ドメインに依存しないAlwaysOn可用性グループ」機能について少し勉強して、実際にAzure SQL仮想マシン上に構成してみましたので、手順や分かったことなどをメモしておきたいと思います。

それではまいります。

Contents

ドメインに依存しない可用性グループとは？

ドメインに依存しない可用性グループを作成する – SQL Server Always On | Microsoft Docs

Domain Independent Cluster and Availability Group – Microsoft Tech Community

ADドメインはもう不要？ワークグループでクラスター作成が可能に――フェイルオーバークラスターの新機能（その3）：vNextに備えよ！次期Windows Serverのココに注目（32）（1/3 ページ） – ＠IT (itmedia.co.jp)

Windows Server 2012 R2以前は、WSFCの作成には、Active Directoryドメインが必須で、クラスターに参加するサーバーはすべて同じActive Directoryのメンバーである必要があった。（単一ドメインクラスター）
Windows Server 2016では、これに加えて以下二つのクラスター構成が可能に。
- ワークグループ構成のクラスター
- マルチドメイン構成のクラスター
ワークグループ構成のクラスターとは、Active Directoryドメインのメンバーとして構成されていない、ワークグループ構成のノード間で構成されたクラスター
マルチドメイン構成のクラスターとは、異なるActive Directoryドメインに参加したノード間で構成されたクラスター
SQL Server自体の機能拡張というよりは、Windows ServerのWSFC（Windows Server Failoveer Cluster）機能が拡張されたことで実現できるようになった構成
なので、Windows Server 2016以降で動作していれば、SQL Serverのバージョンによらず利用可能

以下は、一方のデータセンター(Data Center1）のノードはADドメインに参加しているけど、もう片方のデータセンターのノードは参加していない状況でのクラスター構成のイメージ図。WSFCに参加するすべてのサーバでDNSサフィックスを設定し、すべての接続元が同じDNS情報を参照するようにすればいけるらしい。

ドメインに依存しない可用性グループを作成する – SQL Server Always On | Microsoft Docs

Active Directoryドメインとワークグループの違い

ワークグループという言葉に躓いたのでちょっと調べてみた。
以下記事が分かりやすく解説されていた。

https://tooljp.com/windows/chigai/html/Windows/domain-workgroup-chigai.html

ドメインに依存しない可用性グループの使いどころ

公式ドキュメントみてもこれくらいしか説明がなかった。マルチサイトやディザスターリカバリーのシナリオで使える、らしい。DRだと同じActive Direcotryドメインに参加できないようなシナリオもあるということかな？

ドメインに依存しない可用性グループは、マルチサイトまたはディザスターリカバリーシナリオに使用するためだけではありません。これは、1 つのデータセンターに展開することができ、基本的な可用性グループ (Standard Edition 可用性グループとしても知られる) でも使用され、次のように証明書を含むデータベースモニタリングを使用して達成するために使用されるものに同様のアーキテクチャを提供します。
ドメインに依存しない可用性グループを作成する – SQL Server Always On | Microsoft Docs

うーん、SQL Server & Active Directory初学者にはこれだけみてもこの機能のメリットや、既存の可用性グループ構成との使い分けの判断が難しい・・・ネット見てもあまり触れられている記事がない。

このあたりはまた分かったら更新したいと思います。

ドメインに依存しない可用性グループの制限事項

クォーラムと共に使用できる監視の種類は、ディスクとクラウドのみ。（クラウドは、Windows Server 2016 の新機能）
WSFC の基になるワークグループクラスターバリアントは、PowerShell を使用してのみ作成できる（フェールオーバークラスターマネージャーを使用して管理できる）
Kerberos が必要な場合、Active Directory にアタッチされる標準の WSFC を展開する必要がある。ドメインに依存しない可用性グループは、Kerberosが利用できない可能性がある。
リスナー構成時はDNS に登録する必要がある。リスナーに対する Kerberos サポートはない。
ドメインが存在しなかったり、連携するように構成されていない可能性があったりするため、SQL Server に接続しているアプリケーションでは、主に SQL Server 認証を使用する。
証明書は、可用性グループの構成で使用されます。

Azure VM上のSQL Serverで実際に構成してみた

今回は、以下の手順に沿って構築を進めてみました。が、前提条件の説明がさらっとしかかいていないので、不足していてうまく構成できない、ということが頻発したので、そのあたり含めて補足しておきたいと思います。

また、以下の手順はVNNリスナーを追加する前提の手順っぽいですが、今回私はDNNリスナーを追加する前提で進めたので、クラスターのIPアドレスを設定したりといったステップは省略しています。

ドメインに依存しないワークグループ可用性グループを構成する – SQL Server on Azure VMs | Microsoft Docs

以下のステップで構成できるようです。

DNSサフィックスを設定
ホストファイルを編集してノード間の名前解決できるようにする
フェールオーバークラスター作成権限を付与する
フェールオーバークラスター機能をWindows Serverに追加する
フェールオーバークラスターを構成する
クラウド監視を構成する
AlwaysOn可用性グループ機能を有効化する
SQL Server認証のためのキーと証明書を作成する
SQL Server認証のためのログインを作成する
SQL Server認証を有効化する
ログインに一時的にsysadmin権限を追加する
Systemアカウントに可用性グループ構成権限を付与する
SQL Server上にテスト用データベースを作成し、完全バックアップを取得
AlwaysOn可用性グループを構成する

事前準備

SQL仮想マシンをデプロイする仮想ネットワークとサブネットを作成済
クラスターを構成するAzure SQL仮想マシンを2台作成済（SQL Server 2019 on Windows Server 2022）
クラウド監視用のAzure Storageリソースを作成済

DNSサフィックスの設定

ドメインに依存しないクラスターを作成するためには、最初にクラスターに含まれる各ノードでDNSサフィックスを振る必要があるようです。

各ノードでサフィックスを追加。

ノード１（sqlserver-0）

追加したら再起動されます。再起動後、Full Computer Nameが以下のようにサフィックス付きの名前になっていればOKです。

ノード２（sqlserver-1）も同様に。

hostsの編集

次にhostsの編集。これは、可用性グループの各ノードがお互いと通信できるようにするための設定かと思います。

フェールオーバークラスター作成権限の付与

つづけて、フェールオーバークラスター作成権限の付与。各ノードでPowerShellを開き、以下コマンドを実行します。

new-itemproperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

Windows Serverにフェールオーバークラスター機能を追加

続いて各ノードのWindows Serverにフェールオーバークラスター機能を追加します。

フェールオーバークラスターを構成

その上で、片方のノード（sqlserver-0）から、フェールオーバークラスターの作成を行います。

Windows ServerのToolsからFailover Cluster Mangerを開いて構成できます。

ここで、クラスターに含めるノード名をDNSサフィックス付きで入力します。

ここは今回はNoに。

任意のクラスター名を指定して・・・

作成完了。

クラウド監視を構成

続いてクラウド監視を構成。手順は以下。

フェールオーバークラスターのクラウド監視を展開する | Microsoft Docs

Failver Cluster Mangerからクォーラム監視の設定を開いて、クラウド監視を設定します。

設定する内容は、事前に作成しておいたAzure Storageの接続情報。これらはAzureポータルから確認できます。

構成は数クリックで完了します。完了すると、Azure Storageにクラウド監視用のコンテナが自動作成されていることが確認できます。

可用性グループ機能を有効化

続いて各ノードのSQL ServerでSql Server Configuration Mangerを開いてAlways On 可用性グループ機能を有効化し、サービスを再起動します。

キーと証明書を作成する

続いてキーと証明書の作成。ドメインに依存しない可用性グループの場合、あるノードから別のノードに接続する場合、ドメインの資格情報が使えないので、SQL Server認証を使うことになるのですが、その上でこうした手順が必要になるっぽい。

公式手順の通り、各ノードのSQL ServerにSSMSで接続し、以下コマンドを実行して証明書を作成してきます。以下はsqlserver-0での実行例ですが、両方のノードで実行します。（ノード毎に指定値は微妙に異なるので詳しくは公式手順参照）

USE master;  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'PassWOrd123!';  
GO

--create a cert from the master key
USE master;  
CREATE CERTIFICATE AGNode1Cert   
   WITH SUBJECT = 'AGNode1 Certificate';  
GO  

--Backup the cert and transfer it to AGNode2
BACKUP CERTIFICATE AGNode1Cert TO FILE = 'C:\certs\AGNode1Cert.crt';  
GO

--CREATE or ALTER the mirroring endpoint
CREATE ENDPOINT hadr_endpoint  
   STATE = STARTED  
   AS TCP (  
      LISTENER_PORT=5022  
      , LISTENER_IP = ALL  
   )   
   FOR DATABASE_MIRRORING (   
      AUTHENTICATION = CERTIFICATE AGNode1Cert  
      , ENCRYPTION = REQUIRED ALGORITHM AES  
      , ROLE = ALL  
   );  
GO

各ノードで証明書を作成したら、それを別のノードにコピーして、各ノード、同じディレクトリ階層にお互いの証明書を保持した状態にします。

ログインを作成

次に先ほどの証明書を使って、各ノードで相手ノードからの接続のためのログインとユーザを作成します。以下はsqlserver-0上で実行するコマンド（公式手順と同じ）ですが、各ノードで実行します。またコマンドはノード毎に異なるので詳しくは公式手順参照。

--create a login for the AGNode2
USE master;  
CREATE LOGIN AGNode2_Login WITH PASSWORD = 'PassWord123!';  
GO  

--create a user from the login
CREATE USER AGNode2_User FOR LOGIN AGNode2_Login;  
GO  

--create a certificate that the login uses for authentication
CREATE CERTIFICATE AGNode2Cert  
   AUTHORIZATION AGNode2_User  
   FROM FILE = 'C:\certs\AGNode2Cert.crt'  
GO 

--grant connect for login
GRANT CONNECT ON ENDPOINT::hadr_endpoint TO [AGNode2_login];  
GO

SQL Server認証を有効化する

次に各ノードのSQL ServerでSQL Server認証を利用できるようにしておきます。これはデータベースのプロパティから変更可能。

作成したログインにsysadmin権限を付与

手順の最後にしれっとかいていましたが、今回各ノードで作成したログインに、sysadmin権限を付与しておかないと可用性グループの作成が正常に行えませんでしたので、この段階で追加しておきます。”一時的に”とあるので、構成が終わったら消して大丈夫かもしれません。

同期プロセス中にエラーが発生した場合は、最初のノード (AGNode1 など) 上にクラスターリソースを作成するために NT AUTHORITY\SYSTEM sysadmin 権限を一時的に付与することが必要になる場合があります。
ドメインに依存しないワークグループ可用性グループを構成する – SQL Server on Azure VMs | Microsoft Docs

システムアカウントへの権限の付与

これも躓いたポイント。SQL Serverサービスを実行しているシステムアカウントに、可用性グループの作成権限を与えておかないと構成プロセスでエラーがでてしまいます。

この公式手順では明記されていなかった気がしますが、以下別のチュートリアルで権限付与の手順が紹介されていますので、これを各ノードのSQL Server > SSMS上で実行します。

チュートリアル: サブネットが 1 つの可用性グループの前提条件 – SQL Server on Azure VMs | Microsoft Docs

GRANT ALTER ANY AVAILABILITY GROUP TO [NT AUTHORITY\SYSTEM]
GO
GRANT CONNECT SQL TO [NT AUTHORITY\SYSTEM]
GO
GRANT VIEW SERVER STATE TO [NT AUTHORITY\SYSTEM]
GO

なお、この権限付与がなければ可用性グループの作成中、以下のようなエラーが出てしまいます。

===================================

Create failed for Availability Group 'AG1'.  (Microsoft.SqlServer.Management.HadrModel)

------------------------------
For help, click: https://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=16.100.47021.0&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Create+AvailabilityGroup&LinkId=20476

------------------------------
Program Location:

   at Microsoft.SqlServer.Management.HadrModel.HadrTask.Perform(IExecutionPolicy policy, CancellationToken token, ScenarioTaskHandler taskDelegate)
   at Microsoft.SqlServer.Management.Hadr.CreateAvailabilityGroupWorkItem.DoWork()
   at Microsoft.SqlServer.Management.TaskForms.SimpleWorkItem.Run()

===================================

An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

------------------------------
Program Location:

   at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(String sqlCommand, ExecutionTypes executionType, Boolean retry)
   at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(StringCollection sqlCommands, ExecutionTypes executionType, Boolean retry)
   at Microsoft.SqlServer.Management.Smo.ExecutionManager.ExecuteNonQuery(StringCollection queries, Boolean retry)
   at Microsoft.SqlServer.Management.Smo.SqlSmoObject.ExecuteNonQuery(StringCollection queries, Boolean includeDbContext, Boolean executeForAlter)
   at Microsoft.SqlServer.Management.Smo.SqlSmoObject.CreateImplFinish(StringCollection createQuery, ScriptingPreferences sp)
   at Microsoft.SqlServer.Management.Smo.SqlSmoObject.CreateImpl()

===================================

Failed to bring availability group 'AG1' online.  The operation timed out. If this is a Windows Server Failover Clustering (WSFC) availability group, verify that the local WSFC node is online. Then verify that the availability group resource exists in the WSFC cluster. If the problem persists, you might need to drop the availability group and create it again.
Failed to create availability group 'AG1'.  The operation encountered SQL Server error 41131 and has been rolled back.  Check the SQL Server error log for more details.  When the cause of the error has been resolved, retry CREATE AVAILABILITY GROUP command. (.Net SqlClient Data Provider)

------------------------------
For help, click: https://docs.microsoft.com/sql/relational-databases/errors-events/mssqlserver-41131-database-engine-error

------------------------------
Server Name: sqlserver-0
Error Number: 41131
Severity: 16
State: 0
Line Number: 1


------------------------------
Program Location:

   at Microsoft.SqlServer.Management.Common.ConnectionManager.ExecuteTSql(ExecuteTSqlAction action, Object execObject, DataSet fillDataSet, Boolean catchException)
   at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(String sqlCommand, ExecutionTypes executionType, Boolean retry)

SQL Server上にテスト用データベースを作成し、完全バックアップを取得

ここまで終わったら、あとは可用性グループを構成していくだけ。なのですが、同期するデータベースがないとだめなので、片方のノード（sqlserver-0）で空のデータベースを作成し、完全バックアップを取得しておきます。

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

これで必要な前準備がすべて終わったので、可用性グループの構成です。

片方のノード（sqlserver-0）から、新規可用性グループ作成のウィザードを開始します。

途中、セカンダリとなるレプリカ（sqlserver-1）を追加します。このとき、先ほど設定したログイン情報を使ってプライマリからセカンダリのsql serverにログインします。

無事追加完了。

セカンダリの初期化には、今回は手軽な自動シードを設定しておきます。

以上で必要な設定が終わって検証。リスナーはまだ追加していないのでwarningでますが、これはあとから追加します。

このまま作成にすすみ、正常に作成されることを確認します。

可用性グループが構成されました。

一応、セカンダリレプリカに、プライマリのデータベースが同期されていることも確認しておきます。

このあと、最後にDNNリスナーを追加するプロセスがありますが、これは以下の手順に従って進めていくことになるかと思いますのでいったんリンクだけ貼っておきます。

以上、ドメインに依存しない可用性グループを作成する手順のメモでした。以下感想。

ドメインコントローラが不要になったので構成が必要なサーバは減らせて楽
ただ、ドメインコントローラが担ってくれていた名前解決を代替するための設定（hostsやDNSサフィックス追加）や、SQL Server認証を設定するための証明書やキーの作成ステップが追加で必要だったりとするので、構成ステップは同じくらいの時間がかかった気が・・

というわけで、構成ステップを

少しでも参考になりましたら幸いです。

おしまい。