先日 Preview support for Azure Shared Disks for SQL Server failover cluster instance on Azure IaaS is now available というアナウンスがありました。
詳細なアナウンスについては Lift and Shift Always On SQL Server Failover Cluster Instance (SQL FCI) to Azure VMs でも公開されています。
SQL Server 2019 CU2 以降+ Windows Server 2019 以降を使用することで Azure 上で、共有ディスク型の Failover Cluster Instance (フェールオーバー クラスター インスタンス : FCI) を構築できるようになりました。
軽く構築をしてみてみましたのでその際のメモを。
構築方法については、Create an FCI with Azure shared disks (SQL Server on Azure VMs) を参照してください。
Contents
2020/7/20 時点で構築可能なリージョン
検証を実施した時点では、前提条件は次のようになっています。
- Azure サブスクリプション。 無料で開始しましょう。
- 同じ可用性セットと近接配置グループに含まれる、2 つ以上の米国中西部の準備済み Windows Azure 仮想マシン。可用性セットは、障害ドメインと更新ドメインを 1 に設定して作成する必要があります。
- Azure の仮想マシンと Active Directory の両方にオブジェクトを作成するためのアクセス許可を持つアカウント。
- 最新バージョンの PowerShell。
現時点では、米国中西部で環境を構築が前提状況となっていましたので、仮想マシンはこのリージョンに構築を行います。
リージョンの前提ですが、Shared Disk 自体は GA されているようなのですが、米国中西部の縛りがついているのがよく分かっておらず。
GA されたタイミングが 7 月に入ってからなので、ドキュメントの更新が間に合っていないだけなのかも。
Enable shared disk では、Premium SSD を使用した Shard Disk には「Currently only supported in the West Central US region.」の記述がありますので、最新の情報はここをチェックした方が良いのかもしれませんね。
また、Shared Disk については、共有ディスクを有効にする の設定により、共有ディスク化された Managed Disk を使用する必要があります。
今回は Premium SSD を使用して構築しているのですが、P15 以上のサイズでないと、maxShares を設定することができませんので、ディスクのサイズについては、256 GB 以上のディスクを使用します。
Shared Disk をサポートしている Managed Disk であれば、次のようなスクリプトで、共有ディスク化を行うことができます。
$disk=Get-AzDisk -ResourceGroupName "WSFC" -Name "SharedDisk" $disk.Maxshares=2 $disk | Update-AzDisk
共有ディスク化した Managed Disk については、maxShares の台数の VM で共有ディスクとして利用することができますので、FCI を構築する両ノードで接続をしてから構築を行います。
FCI の構築方法のポイント
FCI の構築については、オンプレミスの共有ディスク型の FCI を構築する場合と流れは変わりません。
冒頭で紹介した Create an FCI with Azure shared disks (SQL Server on Azure VMs) からも構築の手順を確認することができます。
SQL Server の FCI をインストールする際には、クラスターの IP アドレスを指定する必要がありますが、IP アドレスについては、DHCP ではなく、未使用の IP アドレスを設定するようにしておけば、インストールで詰まる個所はないかと。(FCI の IP アドレスを DHCP のまま、構築を進めると、FCI の仮想 IP のクラスターリソースをオンラインにすることができずにエラーとなります)
オンプレミスで構築する場合と同様の方法で構築を進めていくと、次のようなリソース構成の環境を Azure 上でも構築することができるかと思います。
Azure 上で FCI の SQL Server を構築する方法ですが、従来までも方法は提供されていました。
これらの構築方法では、FCI の SQL Server への接続には、Azure のロードバランサー経由で接続を行う必要がありました。
今回、情報が公開された共有ディスクを使用する方法は「SQL Server 2019 CU2 以降」でサポートされた方法となります。
SQL Server 2019 CU2 以降では DNN (Distributed Network Name) を使用した、FCI の接続がサポートされるようになりました。
この方法を使用すると、ロードバランサーを使用せずに FCI に接続することができるようになります。
DNN についてはいくつかのドキュメントが公開されています。
DNN を使用しない構成の場合、FCI の SQL Server は、SQL Server のクラスターの IP アドレスでポートをリスニングします。
そのため、Azure ではロードバランサーに、このクラスター IP アドレスを割り当て、アクセスを行うような構成にする必要があります。
それでは、DNN を設定するとどうなるでしょうか。
DNN は AD のコンピューターアカウントが有効なオブジェクトとして作成されますので、最初に、次の作業を実施しておきます。
- DNN の名称のコンピューターアカウントを AD 上に作成する
- 作成したコンピューターアカウントを無効にし、WSFC の CNO のコンピューターアカウントにフルコントロールを設定
AD のコンピューターアカウントの準備が完了したら次のコマンドを実行します。
Add-ClusterResource -Name FCIDNN -ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)" Get-ClusterResource -Name FCIDNN | Set-ClusterParameter -Name DNSName -value FCIDNN Start-ClusterResource -Name FCIDNN
DNN が作成されると、コンピューターアカウントの有効化が行われ、DNS に次のようなレコードが登録されます。
この IP アドレスは、FCI を構成している各ノードの IP アドレスとなり、DNN に指定した名称で、各ノードの IP アドレスが登録されることになります。
DNN の作成後に FCI の SQL Server のサービスを再起動します。
Stop-ClusterGroup -Name "SQL Server (MSSQLSERVER)" Start-ClusterGroup -Name "SQL Server (MSSQLSERVER)"
最終的なクラスターのリソースの状態は次のようになります。
DNN が有効な状態で、FCI のサービスが起動すると先ほどとは異なり、「0.0.0.0:1433」で SQL Server のポートがリスニングされます。
これにより、FCI の稼働系のノードの IP アドレスで SQL Server がリスニングされることになりますので、ロードバランサーを使用することなく、各ノードの IP アドレスにアクセスができれば、SQL Server にアクセスすることができるようになります。
AD の DNS を参照しているのであれば、上記の構成例では、FCIDNN の解決ができれば、FCI の SQL Server に接続できることになります。
$con = New-Object System.Data.SqlClient.SqlConnection("Server=FCIDNN;Integrated Security=SSPI;Connection Timeout=5")
$con.Open()
$cmd = $con.CreateCommand()
$cmd.CommandText = "SELECT @@SERVERNAME"
$reader = $cmd.ExecuteReader()
$reader.Read()
$reader[0]
$con.Close()
$con.Dispose()
今回の構成では FCIDNN という A レコードで 2 つの IP が登録されていますので、「TransparentNetworkIPResolution=True」や、「MultiSubnetFailover=True」の接続文字列を使用して、接続の高速化は検討する必要があると思いますが。
ドキュメントを見ても、どうしてロードバランサーが不要になったのかが、ぱっと見わからなかかったのですが、設定を有効化し、SQL Server のポートのリスニング状況を確認してみると、設定の効果がわかりやすいのではないでしょうか。