Azure Stack の SQL Hosting Service に Windows の SQL Server の AlwaysOn 可用性グループを組み込む方法が分かったので、次は SQL Server on Linux の可用性グループが組み込めるかを実験してみました。
検証のため STONITH は無効にしてしまっているのですが、この状態では SQL Server on Linux の可用性グループを組み込むことはできました。
(azure_arm が Azure Stack で動作するかは要検証ですね)
私は検証で Ubuntu を使用しているのですが、apt でインストールされる、pacemaker / corosync に含まれているリソースエージェントだけで実現することもできなくはないですが、Azure LB 向けのリソースエージェント (RA) が GitHub のリポジトリ には含まれていますので、それを組み込んだ方がよいかと思います。
SoL の可用性グループに参加する各ノードで次のコマンドを実行すれば RA が組み込めるかと。
OCFDIR=/usr/lib/ocf/resource.d/azure-lb mkdir $OCFDIR curl https://raw.githubusercontent.com/ClusterLabs/resource-agents/a77aec06be2a7d1b94ca2d9128ef780aa902b427/heartbeat/azure-lb > $OCFDIR/lb chmod 755 $OCFDIR/lb pcs resource providers pcs resource agents ocf:azure-lb pcs resource describe ocf:azure-lb:lb
これで、Azure LB のプローブポートをリスニングすることができる RA を使用することができるようになります。
pcs resource create azure-lb ocf:azure-lb:lb nc=/bin/nc port=59999 sudo pcs constraint colocation add azure-lb ag_cluster-master INFINITY with-rsc-role=Master
で、可用性グループのリソースが動いているノードでプローブポートがりスイングされる状態にすることができます。
ここまで出来れば、あとは Windows 版の AG を組み込んだ方法と同じです。
Azure LB の DNS 名でリスナーを作成しておけば、組み込むことができます。
Windows 版の AG の場合、プローブポートが IP アドレスリソースに設定されるため、リスナーの VIP をクラスターのリソースとして組み込む必要があるのですが、SoL の場合、プローブポートを独立したリソースとして作成することができますので、リスナーの VIP を Pacemaker のリソースとして登録しなくても LB 経由で接続ができたりします。
(読み取りのスケールアウトができるかまでは確認できていませんが)
SQL Server として、リスナー自体は作成しておく必要があります。
Pacemaker 側については、次のようなリソースの登録状況 (AG とプローブポートのみリソースが存在) で、Azure LB を経由して透過的にプライマリに接続ができたります。
Azure Stack の Azure LB からのリダイレクトが、プローブポートをホストしているサーバーへのリダイレクトというシンプルな動作だからですかね。
SQL Hosting Service に AlwaysOn 可用性グループのサーバーを追加する場合、次のようなクエリが実行されます。
USE [master];
REVOKE VIEW ANY DATABASE FROM PUBLIC;
SELECT [Version] = SERVERPROPERTY('productversion'),[Edition] = SERVERPROPERTY('edition')
SELECT [TotalPhysicalMemory] = CAST([total_physical_memory_kb] / 1024 AS INT) , [AvailablePhysicalMemory] = CAST([available_page_file_kb] / 1024 AS INT) FROM [master].[sys].[dm_os_sys_memory]
USE [master];
SELECT seeding_mode FROM sys.availability_replicas
SELECT [listener_id] FROM [master].[sys].[availability_group_listeners] WHERE [dns_name] = @serverName
リスナーの名称が、SQL Hosting Service を追加する際に指定した、FQDN のホスト名かどうかのチェックを実行しているようですので、SQL Server の情報としては、リスナーは必須となります。
現状、SoL の場合、SQL IaaS Extension が使用できないため、メンテナンス用のタスクの組み込みを構築側で実施する必要があるのですが、Azure Stack に SoL の可用性グループを組み込むことはできるのかもしれないですね。