SE の雑記

 

AlwaysOn が Windows Azure Virtual Machine (VMs) で正式にサポートされるようになりました。

関連する情報としては、

Availability Group Listener in Windows Azure Now Supported! (And Scripts for Cloud-Only Configuration)
Tutorial: Listener Configuration for AlwaysOn Availability Groups in Windows Azure
Update enables SQL Server Availability Group Listeners on Windows Server 2012-based Windows Azure virtual machines
Windows Azure: General Availability of SQL Server Always On Support and Notification Hubs, AutoScale Improvements + More
Windows Azure で SQL Server AlwaysOn を正式サポート ＆ Windows Azure 通知ハブを正式リリース

が参考になります。

以前はリスナーが作成できなかったため、ミラーリングの接続文字列で代用していたのですが、今回のサポートにより、AlwaysOn のリスナーが Azure VM 上で作成できるようになり、単一の接続ポイントによる接続が可能となっています。

リスナーの構築以外の大きな流れは以前検証した、
AlwaysOn を Azure 上に構築してみる – WSFC の構築編 –
AlwaysOn を Azure 上に構築してみる – AlwaysOn の構築編 –
AlwaysOn を Azure 上に構築してみる – テストの実施編 –
の流れと同じなのですが、ポイントについてはまとめながら書いていきたいと思います。

■ベース部分の構築

---

まずは、リスナー以外のベース部分の構築をざっと見ていきたいと思います。

WSFC の構築に関しては以前の手順から変更はないようです。
チュートリアル: Windows Azure AlwaysOn 可用性グループ (GUI)
Tutorial: AlwaysOn Availability Groups in Windows Azure (GUI)

サポートされるようになったのはリスナーの箇所になりますので CNO (クラスター名オブジェクト) に関しては今までと同様のようです。

一度ダミーで IP を設定しクラスターコアリソースをオンラインにし、AD 上にコンピューターアカウントを作成し、

その後、IP アドレスを削除して、クラスター名をオフラインにします。

AlwaysOn のリスナー以外の箇所の手順も変わっていないようです。
最初にWindows Firewall としてはこの段階で最低限以下は受信許可をしておく必要があります。
# デフォルトの設定の場合ですが。

プロトコル	ポート	役割
TCP	1433	SQL Server インスタンス
TCP	5022	ミラーリングエンドポイント

 

ファイアウォールの設定が終わったら AlwaysOn の設定をします。
リスナーに関しては GUI からではなく PowerShell から作成する必要がありますので、まずはリスナー以外の箇所を SSMS の GUI から設定をしてしまいます。
# PowerShell でも設定可能です。

ここまでは今までの構築の手順と変わりません。

 

■リスナーを追加するための設定

---

これ以降の作業が今回サポートされたことにより追加で実施する必要があるものになります。

リスナーを追加するための最初の手順としては、死活監視付きの負荷分散エンドポイントを作成する必要があります。

負荷分散エンドポイントとACL (と、バグ)
Windows Azure Virtual Machinesで、死活監視（ヘルスチェック）しながらロードバランシングする手順

以下は実際に使用するコマンドになります。
負荷分散エンドポイントは Azure 側の設定になりますので、まずは こちら から Windows Azure PowerShell をダウンロードしてインストールをする必要があります。

# PublishSetting ファイルの取り込み (一度の未実施する) Get-AzurePublishSettingsFile Import-AzurePublishSettingsFile -PublishSettingsFile <セッティングファイル> $AGNodes = "NAWAGAMI-SQL-01","NAWAGAMI-SQL-02" $ServiceName = "NAWAGAMI-SQL" $EndpointName = "AlwaysOn" $EndpointPort = "1433" ForEach ($node in $AGNodes) {     Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -Protocol "TCP" -PublicPort $EndpointPort -LocalPort 1433 -LBSetName "$EndpointName-LB" -ProbePort 59999 -ProbeProtocol "TCP" -DirectServerReturn $true | Update-AzureVM }

これにより以下のようなエンドポイントの構成となります。
# 現状のポータルからは死活監視のポートの設定は表示されませんが、負荷分散セットとして、設定がされていることが確認できます。

PowerShell で確認をすると各ノードのエンドポイントに ProbePort が設定されていることが確認できます。

[負荷分散エンドポイントとACL (と、バグ)] の記事の図を参考にさせていただくと以下のような構成になっている感じでしょうか。
死活監視用のポートとしては、[59999] を設定しているのですが、各クラウドサービスではこの段階ではこのポートは立ち上げていませんので、現状は死活監視は動作していない状態となっています。

次に各インスタンスで ProbePort (今回は 59999) を設定するための作業を行います。
この作業を行うためには各インスタンスに、KB2854082 を適用する必要があります。
# 適用後は再起動が必要です。

• Enables users to set the subnet to 255.255.255.255 for the IPv4 resource of a cluster.
• Fixes an issue in which the Resource Hosting Subsystem (RHS) process is not cleaned up when an IP resource failure occurs.

この修正プログラムを適用することでサブネットが 255.255.255.255 の IP アドレスリソースを作成できるようになるようですね。

修正プログラムが適用できたらリスナーを作成するための手順を実施します。
まずは各ノードで Windows Firewall で ProbePort として使用するポート (今回は 59999) の受信規則を作成します。

これで ProbePort の応答ができるようになりましたので、次にリスナーのクライアントアクセスポイントを作成します。
通常であれば、SSMS から作成をするのですが、Azure 上で構築する場合には、フェールオーバークラスターマネージャーを併用しながら作成をします。

まずは、フェールオーバークラスターマネージャーを起動し、AlwaysOn 用の役割を選択し、[リソースの追加] から [クライアント アクセス ポイント] を選択し、CAP を作成します。

ネットワーク名はリスナーの名称として使用され、コンピューターアカウントが作成されますので、適切なものを設定しておきます。
IP に関しては後で変更をするのでまずは DHCP で作成しておきます。

次に PowerShell で以下のようなコマンドを実行します。

$ClusterNetworkName = "クラスター ネットワーク 1" $IPResourceName = "IP アドレス 172.16.0.0" $CloudServiceIP = "<SQL Server のクラウドサービスのIP>" Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$CloudServiceIP";"ProbePort"="59999";SubnetMask="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0}

 

ClusterNetworkkName は IP を付与するために使用するクラスターネットワークの名称となります。
現状の Azure VM は一つの NIC しか使えませんのでデフォルトでは上記の名称となるはずです。

IP アドレスはクラスターアクセスポイントを設定した際に作成された IP アドレスリソースの名称となりますので、クラスターマネージャーから確認をするとよいと思います。

設定の確認ができたらコマンドを実行します。
実行すると IP アドレスリソースに設定されている IP がクラウドサービスで使用している IP アドレスとなり、サブネットが 255.255.255.255、ProbePort が設定された IP アドレスリソースに変更がされます。

設定が終わったらリスナーのネットワーク名リソースをオンラインにします。

これで、リスナーの IP アドレスリソースをオンラインにしているノード (プライマリレプリカ) が ProbePort に設定していたポートが起動され、サービスを提供しているノードとして認識がされるようです。
NetStat で確認をしてみると接続が行われていることがわかるかと。

ここまでの作業で、ProbePort の設定は終わりましたが、このままですと SQL Server としては、リスナーのアクセスポイントとしては使用ができないため、可用性グループリソースのプロパティを開き、リスナーのネットワーク名を依存関係として設定します。

この操作を行うことで可用性グループリスナーとして自動的に追加がされます。

この状態ですと、リスナーにポートが設定されていませんので、SSMS からリスナーのプロパティを開き、ポートを設定します。

以上で設定は完了です。

最終的には以下のような構成になるようです

AlwaysOn のリスナーのリソース (正確には可用性グループのリソースも) はプライマリレプリカ (更新可能なレプリカ) でオンラインになります。リスナーが起動しているノードで ProbePort が開かれていることになりますので、ProbePort でアクセスができるノードに対して、クライアントのアクセスを渡せば、更新可能系のサーバーに接続ができるようになっているという仕組みのようです。

AlwaysOn のフェールオーバーが発生すると以下のようにリスナーがオンラインになるノードが切り替わりますので、透過的に接続をすることができます。

今回はパブリックポートは 1433 で設定していますので SSMS からクラウドサービスに接続がすれば、プライマリのサーバーに自動的に接続が行われます。
# 認証方式は SQL Server 認証を使う必要が出てくると思いますが。

可用性グループの読み取り専用ルーティングの構成 を使用した読み取り専用の接続もできたのですが、これは上記の設定だけだと厳しそうなので少し工夫をする必要がありそうです。

読み取り専用ルーティングについては次の投稿でまとめてみたいと思いますがプライマリへの接続であれば、ここまでの内容で対応ができそうです。