SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

AlwaysOn 可用性グループを Azure 上で構築した場合のリスナーの構成

leave a comment

数回、AlwaysOn 可用性グループを Azure 上で構築した場合の情報を書きてきましたが今回のリスナーの構成でひと段落かなと。

基本的な情報については チュートリアル:AlwaysOn 可用性グループのリスナー構成 に掲載されています。

MSDN の情報を確認したのですが、

  • 手順 5:可用性グループ リスナーを作成する

については、おそらく見出しの内容と記載内容があまりよくないと思います。

  • 手順 5:クラスターアクセスポイントを作成する

であれば、内容としては良いのですが、可用性グループ リスナーの作成としては記載されている内容だと NG だと考えています。

MSDN の手順では、フェールオーバークラスターマネージャーのみを操作して、クラスターアクセス ポイントの作成を行っています。

Azure 上で構築された、負荷分散されたエンドポイントを利用して接続をしているので可用性グループのリスナーはそれほど大事ではないので書いてある内容でもよいといえばよいのですが…。

どこが NG かと考えているかというと、

  • SQL Server のリスナーのエントリと WSFC の CAP の設定の情報がマッチしていない

という点になります。

MSDN のチュートリアルの手順でリスナーを作成した場合、リスナーの情報を取得するためのシステムビューである

  • sys.availability_group_listeners
  • sys.availability_group_listener_ip_addresses

から、情報を取得することができません。
これは、SQL Server としてリスナーを作成しているのではなく、WSFC の CAP としてのみ設定をしているためです。
このため、チュートリアルの手順で作成した場合、SSMS でもリスナーの情報は表示されません。

image

SQL Server として整合性が取れた情報でリスナーを作成するのであれば、

  • SQL Server で可用性グループリスナーをダミーの IP アドレスを使用して作成する
  • その後、PowerShell を使用して、CAP の IP アドレスと Probe Port を設定する

という手順で実施する必要があります。

本投稿では上記の順序で可用性グループリスナーを作成して、構築を行いたいと思います。

 

■負荷分散エンドポイントの作成


まず、最初に決める必要があるのは可用性グループにどのような経路を使用してアクセスするかということです。
具体的には以下の 2 パターンのどちらでアクセスるかを考慮する必要があるかということになります。

  • パブリック IP 経由でのアクセス (~.cloudapp.net の DNS 名を使用してアクセス)
  • 内部 IP 経由でのアクセス (リスナー名を使用してのアクセス)

パブリック IP 経由でアクセスをする場合には、Azure Load Balancer : ALB (Public Load Balancer) で負荷分散エンドポイントを作成、内部 IP 経由でアクセスをする場合には、Internal Load Balancer : ILB で負荷分散エンドポイントを作成する必要があります。

どちらを使用するかについてはネットワークやセキュリティ要件に依存するかと。
パブリック IP 経由でのアクセスについてはインターネット経由でのアクセスを行うということになるかと思いますので。
どちらのアクセス方法でも DB サーバーに対してのアクセスは ACL で制御するということはありそうですが。

 

それではそれぞれのパターンの負荷分散エンドポイントの作成方法を見ていきたいと思います。
どちらも PowerShell で作成します。

パブリック IP 経由でアクセスをする場合の負荷分散エンドポイントの作成が以下になります。

Add-AzureAccount

# Define variables
$AGNodes = "SQL-01","SQL-02" # all availability group nodes containing replicas should be included, separated by commas
$ServiceName = "kinmugi-mssql" # the name of the cloud service that contains the availability group nodes
$EndpointName = "AlwaysOn" # name of the endpoint
$EndpointPort = "1433" # public port to use for the endpoint

# Configure a load balanced endpoint for each node in $AGNodes, with direct server return enabled
ForEach ($node in $AGNodes)
{
    Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -Protocol "TCP" -PublicPort $EndpointPort -LocalPort $EndpointPort -LBSetName "$EndpointName-LB" -ProbePort 59999 -ProbeProtocol "TCP" -DirectServerReturn $true | Update-AzureVM
}

こちらについては Probe Port と Direct Server Return を使用した負荷分散エンドポイントの作成ですね。

これにより以下のような負荷分散エンドポイントが作成されます。

image

次は内部 IP 経由でアクセスするパターンです。

 
Add-AzureAccount

# Define variables
$AGNodes = "SQL-01","SQL-02" # all availability group nodes containing replicas should be included, separated by commas
$ServiceName = "kinmugi-mssql" # the name of the cloud service that contains the availability group nodes
$EndpointName = "AlwaysOn" # name of the endpoint
$EndpointPort = "1433" # public port to use for the endpoint
$ILBName = "AlwaysOnILB" # chosen name for the new ILB
$SubnetName = "DB-Subnet" # subnet name that the replicas use in the VNet
$ILBStaticIP = "172.0.0.8" # static IP address for the ILB in the subnet

Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $SubnetName -ServiceName $ServiceName -StaticVNetIPAddress $ILBStaticIP

# Configure a load balanced endpoint for each node in $AGNodes using ILB
ForEach ($node in $AGNodes)
{
Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -LBSetName "$EndpointName-LB" -Protocol tcp -LocalPort $EndpointPort -PublicPort $EndpointPort -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName | Update-AzureVM 
} 

こちらのパターンでは ILB を作成しています。

ILB のアドレスには、サブネットから静的な IP を割り当てる必要があるため、未使用の IP アドレスである「172.0.0.8」を指定しています。

PowerShell はチュートリアルのサンプルを使用しているのですが、

  • ALB : DirectServerReturn を指定
  • ILB : DirectServer Return を指定しない

という違いがあるようですね。

 

未使用の IP アドレスについては

(Test-AzureStaticVNetIP -VNetName "AlwaysOnVNet" -IPAddress 172.0.0.0).AvailableAddresses

というような形で確認することができますので、こちらから確認するとよいかと。

ここまでの設定で Azure 側からアクセスするための設定が完了です。

次に SQL Server のリスナーを作成します。

 

■SQL Server のリスナーを作成


冒頭で書いたように MSDN とは手順が異なっています。

リスナーなしで可用性グループを設定した場合でも SSMS であとからリスナーを作成することが可能です。

image

リスナーを作成する際には「パブリック IP」「内部 IP」のどちらでアクセスする場合でも、内部 IP の未使用の IP を割り当てておきます。

image

これにより、SQL Server のリスナーのエントリが作成され、WSFC としても CAP が作成された状態となります。

imageimage

この後に PowerShell で CAP の設定を変更します。

# Define variables
$ClusterNetworkName = "クラスター ネットワーク 1" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
$IPResourceName = "AlwaysOn-AG_172.0.0.8" # the IP Address resource name 
$LoadBalancerIP = "xxx.xxx.xxx.xxx" # Virtual IP (VIP) address of your cloud service

Import-Module FailoverClusters

# If you are using Windows Server 2012 or higher, use the Get-Cluster Resource command. If you are using Windows Server 2008 R2, use the cluster res command. Both commands are commented out. Choose the one applicable to your environment and remove the # at the beginning of the line to convert the comment to an executable line of code. 

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$LoadBalancerIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0}

パブリック IP を使用する場合には、LoadBalancer IP にパブリック IP を、内部 IP を使用する場合には、ILB に設定した IP をしています。

ClusterNetworkName については、WSFCの「ネットワーク」の名称を

image

IPResourceName については、リスナーの IP アドレスのプロパティを開いて「名前」の設定を使用します。

image

PowerShell を実行することで、IP のリソースに ProbePort が設定されます。

これによりロードバランサーがどのノードに対して、アクセス要求をリダイレクトすればよいかを監視することができるようになります。

設定を有効にするためには一度 IP アドレスのリソースをオフライン→オンラインにする必要があります。

以上でリスナーの設定は終了です。

 

■可用性グループにアクセス


それでは可用性グループにアクセスしてみたいと思います。

パブリック IP でアクセスをする場合には、以下のように cloudapp.net 経由でアクセスをし、ALB 経由でアクセスを行います。

このケースでは、

  • パブリックの DNS 名が解決できる
  • 解決ができたパブリック IP にアクセスができる

を満たせれば接続ができるかと。

image

 

ILB を設定して、内部 IP でのアクセスをする場合には、以下のように内部 IP を解決できる名称 (リスナーに内部 IP を割り当てていればリスナー名) で接続を行います。

こちらは、

  • 内部の DNS 名 (リスナー名) が解決できる
  • 解決ができた内部 IP にアクセスができる

を満たせれば接続可能です。

# 内部 IP 経由でのアクセスになるため同一の仮想ネットワーク内の必要が出てきます。

image

 

パブリックポートが重複しなければ ALB と ILB の両方を作成することができます。

この環境を使用して、ALB / ILB の両方からアクセス可能なリスナーを作成しようとしたのですが挙動が不安定で作成できるときもあれば、作成できない時もあるという感じでした。

# 作成できない可能性のほうが高かったです。

リスナーに対して複数の IP を設定した際にオンラインにしようとすると障害が発生してしまい IP をオンラインにできないという現象が ALB / ILB を設定しようとしたときには頻繁に発生していました。

WSFC に参加するノードをすべてシャットダウンすれば、起動はできるケースもあったのですができないケースのあるので基本 ALB / ILB のどちらかのロードバランサーを使用するという考えていたほうがよさそうですね。

 

初見で設定の意味を理解しながら構築するのはなかなか難易度が高いですね。。。。

Written by masayuki.ozawa

12月 29th, 2014 at 12:36 am

Leave a Reply

*