SE の雑記

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

SQL Server 2016 CTP 2.0 の AlwaysOn 可用性グループを使ってみる その 2

leave a comment

前回の投稿では Standard Edition の可用性グループについて投稿しました。

今回は、機能拡張をされたものについて投稿してみたいと思います。

AlwaysOn 可用性グループの機能拡張としては、

Load-balancing of read-intent connection requests is now supported across a set of read-only replicas. The previous behavior always directed connections to the first available read-only replica in the routing list. For more information, see Configure load-balancing across read-only replicas.

The number of replicas that support automatic failover has been increased from two to three.

Group Managed Service Accounts are now supported for AlwaysOn Failover Clusters. For more information, see Group Managed Service Accounts. For Windows Server 2012 R2, an update is required to avoid temporary downtime after a password change. To obtain the update, see gMSA-based services can’t log on after a password change in a Windows Server 2012 R2 domain.

AlwaysOn Availability Groups supports distributed transactions and the DTC on Windows Server 2016. For more information, see SQL Server 2016 Support for DTC and AlwaysOn Availablity Groups.

You can now configure AlwaysOn Availability Groups to failover when a database goes offline. This change requires the setting the DB_FAILOVER option to ON in the CREATE AVAILABILITY GROUP (Transact-SQL) or ALTER AVAILABILITY GROUP (Transact-SQL) statements.

があります。

 

■ロードバランシングによるセカンダリレプリカへの接続

従来までの可用性グループは、ルールベースで使用するセカンダリレプリカにアクセスすることができました。
SQL Server 2016 では、ロードバランシングされたセカンダリレプリカへのアクセスが提供されるようになりました。

今までは、以下のようにセカンダリレプリカへのアクセス先を設定していました。

READ_ONLY_ROUTING_LIST = ('Server1','Server2', 'Server3', 'Server4')

この設定は該当サーバーに接続ができない場合は後続のサーバーに接続するという、設定順に応じたルールベースの設定となっていました。

上記の設定であれば、

  • Server1 → Server2 → Server3 → Server4

という順に接続できるサーバーで読み取りアクセスが行われます。

SQL Server 2016 では、Configure load-balancing across read-only replicas. に書かれているように、ルールベースは基本として、その中でロードバランシングの設定をすることができます。

READ_ONLY_ROUTING_LIST = (('Server1','Server2'), 'Server3', 'Server4')

 

これにより接続の順序が

  • Server1 または Server2 → Server 3 → Server4

という順序にすることができます。

今回は「SQL-2016-01」「SQL-2016-02」「SQL-2016-03」の 3 ノード構成の環境を使っているのですが、この場合は、以下のように設定することになるかと。

ALTER AVAILABILITY GROUP AlwaysOnAG
MODIFY REPLICA ON N'SQL-2016-01'
WITH (
SECONDARY_ROLE(READ_ONLY_ROUTING_URL=N'TCP://SQL-2016-01.alwayson.local:1433')
)
ALTER AVAILABILITY GROUP AlwaysOnAG
MODIFY REPLICA ON N'SQL-2016-02'
WITH (
SECONDARY_ROLE(READ_ONLY_ROUTING_URL=N'TCP://SQL-2016-02.alwayson.local:1433')
)
ALTER AVAILABILITY GROUP AlwaysOnAG
MODIFY REPLICA ON N'SQL-2016-03'
WITH (
SECONDARY_ROLE(READ_ONLY_ROUTING_URL=N'TCP://SQL-2016-03.alwayson.local:1433')
)
ALTER AVAILABILITY GROUP [AlwaysOnAG]
MODIFY REPLICA ON N'SQL-2016-01'
WITH (
PRIMARY_ROLE(READ_ONLY_ROUTING_LIST=((N'SQL-2016-02',N'SQL-2016-03'))
))
ALTER AVAILABILITY GROUP [AlwaysOnAG]
MODIFY REPLICA ON N'SQL-2016-02'
WITH (
PRIMARY_ROLE(READ_ONLY_ROUTING_LIST=((N'SQL-2016-01',N'SQL-2016-03'))
))
ALTER AVAILABILITY GROUP [AlwaysOnAG]
MODIFY REPLICA ON N'SQL-2016-03'
WITH (
PRIMARY_ROLE(READ_ONLY_ROUTING_LIST=((N'SQL-2016-01',N'SQL-2016-02'))
))

 

それでは、以下のようなコードでどのような動作になるか見てみたいと思います。

# シングルスレッドで実行してしまっているので、コネクションプーリングは切っています。有効な場合は、想定したようにロードバランスされなかったので。

$ConString = "Server=SQL-2016-LN.alwayson.local;Database=SyncDB01;Integrated Security=True;ApplicationIntent=ReadOnly;pooling=false"
Clear-Host
for ($i = 1 ;$i -le 50; $i++){
    $Con = New-Object System.Data.SqlClient.SqlConnection
    $con.ConnectionString = $ConString
    $con.Open()
    $command = New-Object System.Data.SqlClient.SqlCommand
    $command.Connection = $con
    $command.CommandText = "SELECT @@SERVERNAME"
    $ret = $command.ExecuteReader()
    $ret.read()| Out-Null
    "{0} {1} {2}" -f $i.ToString("0#"), (Get-Date).ToString("yyyy/MM/dd hh:mm:ss"), $ret[0]
    $con.Close() | Out-Null
    $con.Dispose()
    Start-Sleep -Seconds 2
}

 

実行結果が以下になります。

image

最初は 2014 までの設定にしており、10 回目のタイミングで、ロードバランシングされた設定に切り替えています。

最初は、SQL-2016-02 にのみ接続がされていますが、切り替えたタイミングで使用されるサーバーが交互に切り替わっていることが確認できますね。

ロードバランシングを有効にすることで、セカンダリレプリカへのアクセスを分散させることができるようになります。

# 重みづけはできないので、どのようにロードバランスするかの設定まではできませんが。

 

■AlwaysOn フェールオーバークラスターで gMSA のサポート

SQL Server の gMSA (または、MSA) のサポートですが、まとまったドキュメントって意外とないですよね…。

gMSA for SQL Server Failover Clusters

MSA accounts used with SQL

Managed Service Accounts (MSA) and SQL 2012: Practical Tips

 

現状の情報で、SQL Server 自体に gMSA がサポートされているのかが微妙なのですが、AlwaysOn フェールオーバークラスターでは、サポートが明記されました。

# シングルインスタンスでも設定はできるんですが、サポートされているかの明記が見つかっていないのですよね。

■自動フェールオーバーターゲットの増加

従来までは、

  • 同期モードは最大で 3 ノード
  • その中で自動フェールオーバーターゲットを 2 台で設定

する形になっていました。

そのため、フェールオーバーモードを「自動」に設定しているノードについては 2 台までとなっています。

image

SQL Server 2016 では、この制限が緩和され、3 台で自動フェールオーバーを設定することができるようになりました。

image

これにより同期モード内はすべて自動フェールオーバーを設定することができるようになり、どのサーバーが自動フェールオーバーターゲットになっているかを気にしなくてよくなった感じでしょうかね。

 

■複数データベースまたぐトランザクションのサポート

SQL Server 2016 では、 Cross-Database Transactions Support For Database Mirroring or AlwaysOn Availability Groups (SQL Server) に書かれているように、複数データベースへのトランザクションサポートが追加されているようです。

従来までは データベース ミラーリングまたは AlwaysOn 可用性グループではサポートされない複数データベースにまたがるトランザクション (SQL Server) / [SQL Server] 高可用性ソリューションについて に書かれているようにサポートされていなかったものが緩和されるようです。

可用性グループを作成する際に、「データベースごとの DTC サポート」という設定が追加されており、これにより有効化をすることができます。

image

CREATE AVAILABILITY GROUP  に「DTC_SUPPORT」が追加されているのが確認できますね。

これを具体的に試すテストシナリオを持っていないので、実際の動作については後日確認してみたいと思います。(きっと)

XA Transaction, MSDTC and How to Configure Multiple MSDTC Instance on SQL AlwaysON Cluster Environment  辺りも見ておくとよいかもですね。

■データベース レベルの正常性検出

可用性グループで、「データベース レベルの正常性検出」が設定できるようになっています。

この設定については、可用性グループ作成後も変更をすることができます。

image

可用性グループでは CREATE AVAILABILITY GROUP の FAILURE_CONDITION_LEVEL レベルを設定して、フェールオーバーを実施していましたが、基本的にはインスタンスの状態を確認していた形になるかと思います。

上記のオプション (DB_FAILOVER) を使用することでデータベースのオフラインをトリガーとしてのフェールオーバーが実施可能となるようです。

オンラインとなっているデータベースのファイルが格納されているディスクを切断では、オフラインとして認識されず、フェールオーバーはしなかったので、どのような状態をトリガーとするかは、検証をする必要がありそうですが。

 

ざっくりとですが、機能拡張部分について、まとめてみました。

Share

Written by Masayuki.Ozawa

6月 14th, 2015 at 3:55 pm

Posted in SQL Server

Tagged with ,

Leave a Reply