チュートリアル: Linux Virtual Machines で可用性グループリスナーを構成する

[アーティクル]
12/06/2023

このチュートリアルでは、Red Hat Enterprise Linux (RHEL)、SUSE Linux Enterprise Server (SLES)、および Ubuntu を対象に、Azure の Linux Virtual Machines (VM) で SQL Server の可用性グループリスナーを作成する手順について説明します。

学習内容は次のとおりです。

Azure portal でロードバランサーを作成する
ロードバランサーのバックエンドプールを構成する
ロードバランサーのプローブを作成する
負荷分散規則を設定する
クラスターにロードバランサーリソースを作成する
AG リスナーを作成する
リスナーへの接続をテストする
フェールオーバーをテストする

Note

バイアスフリーなコミュニケーション

この記事には、この文脈で使用した場合に不快感を与えると Microsoft が考える slave (スレーブ、奴隷) という用語の言及が含まれています。これはソフトウェアに現在表示されるものであるため、この記事に出現します。ソフトウェアからこの用語が削除された時点で、この記事から削除します。

前提条件

「チュートリアル: Azure の RHEL 仮想マシンで SQL Server の可用性グループを構成する」を完了していること。

Azure Portal でロードバランサーを作成する

次の手順では、「ロードバランサーと可用性グループリスナーの構成 (Azure VM 上の SQL Server)」の記事の「Azure portal でロードバランサーを作成および構成する」セクションの手順 1 から 4 を実行します。

ロードバランサーを作成する

Azure ポータルで、SQL Server の仮想マシンを含んだリソースグループを開きます。
リソースグループで、 [追加] を選択します。
ロードバランサーを探し、検索結果から [ロードバランサー] (Microsoft によって発行されたもの) を選択します。
[Load Balancer] ペインで、[作成] を選択します。

[ロードバランサーの作成] ダイアログボックスで、次のようにロードバランサーを構成します。

設定	値
名前	ロードバランサーを表すテキスト名たとえば、`sqlLB` のようにします。
Type	内部
仮想ネットワーク	作成された既定の仮想ネットワークには、`VM1VNET` という名前が設定されているはずです。
サブネット	SQL Server インスタンスが存在するサブネットを選択します。既定値は `VM1Subnet` である必要があります。
IP アドレスの割り当て	静的
プライベート IP アドレス	クラスター内に作成された `virtualip` IP アドレスを使用します。
サブスクリプション	対象のリソースグループに使用したサブスクリプションを使用します。
リソースグループ	SQL Server インスタンスが存在するリソースグループを選択します。
場所	Azure において SQL Server インスタンスが存在する場所を選択します。

バックエンドプールを構成する

Azure では、バックエンドアドレスプールを "バックエンドプール" と呼んでいます。この例では、AG に含まれる 3 つの SQL Server インスタンスのアドレスがバックエンドプールとなります。

リソースグループで、作成したロードバランサーを選択します。
[設定] で、[バックエンドプール] を選択します。
[バックエンドプール] の [追加] を選択してバックエンドアドレスプールを作成します。
[バックエンドプールの追加] の [名前] に、バックエンドプールの名前を入力します。
[関連付け先] で、 [仮想マシン] を選択します。
環境内の各仮想マシンを選択し、適切な IP アドレスを各選択項目に関連付けます。
[追加] を選択します。

プローブを作成する

このプローブで定義された方法で、現在どの SQL Server インスタンスが AG リスナーを所有しているかが Azure によって確認されます。 Azure は、プローブの作成時に定義されたポートで、IP アドレスに基づいてサービスをプローブします。

ロードバランサーの [設定] ウィンドウで [正常性プローブ] を選択します。
[正常性プローブ] ペインで [追加] を選択します。

[プローブの追加] ウィンドウで、プローブを構成します。次の値を使用してプローブを構成します。

設定	値
名前	プローブを表すテキスト名たとえば、`SQLAlwaysOnEndPointProbe` のようにします。
プロトコル	`TCP`
ポート	空いている任意のポートを使用できますたとえば、`59999` のようにします。
間隔	`5`
異常のしきい値	`2`

[OK] を選択します。
すべての仮想マシンにサインインし、次のコマンドを使用してプローブポートを開きます。
```
sudo firewall-cmd --zone=public --add-port=59999/tcp --permanent
sudo firewall-cmd --reload
```

Azure はこのプローブを作成、使用して、どの SQL Server インスタンスが AG のリスナーを所有しているかを判定します。

負荷分散規則を設定する

負荷分散規則を使って、ロードバランサーでトラフィックを SQL Server インスタンスにルーティングする方法を構成します。 3 つの SQL Server インスタンスのうち AG リスナーリソースを所有できるのは一度に 1 つだけであるため、このロードバランサーでは Direct Server Return を有効にします。

ロードバランサーの [設定] ウィンドウで [負荷分散規則] を選択します。
[負荷分散規則] ペインで、[追加] を選択します。

[負荷分散規則の追加] ウィンドウで、負荷分散規則を構成します。次の設定を使用します。

設定	値
名前	負荷分散規則を表すテキスト名。たとえば、`SQLAlwaysOnEndPointListener` のようにします。
プロトコル	TCP
ポート	`1433`
バックエンドポート	`1433`. この規則には [フローティング IP (Direct Server Return)] が使用されるため、この値は無視されます。
プローブ	このロードバランサーに対して作成したプローブの名前を使用します。
セッション永続化	なし
アイドルタイムアウト (分)	`4`
フローティング IP (ダイレクトサーバーリターン)	Enabled

Screenshot showing how to add a load balancing rule.

[OK] を選択します。
負荷分散規則が Azure によって構成されます。以上、AG のリスナーのホストとなっている SQL Server インスタンスにトラフィックをルーティングするようにロードバランサーを構成しました。

この時点で、リソースグループのロードバランサーがすべての SQL Server マシンに接続されています。またロードバランサーには、AG への要求にすべてのマシンが応答できるよう、SQL Server Always On AG リスナーの IP アドレスが格納されます。

可用性グループリスナーリソースを作成する

Pacemaker でロードバランサーリソースを作成する前に、まずリスナーリソースを作成します。

sudo crm configure primitive virtualip \
ocf:heartbeat:IPaddr2 \
params ip=x.y.z.a

前の例では、x.y.z.a はロードバランサーのフロントエンド IP アドレスを参照しています。

クラスターにロードバランサーリソースを作成する

構成しているディストリビューションの手順に従います。

プライマリ仮想マシンにログインします。 Azure ロードバランサーのプローブポートを有効にするには、リソースを作成する必要があります (この例では 59999 が使用されています)。次のコマンドを実行します。
```
sudo pcs resource create azure_load_balancer azure-lb port=59999
```
virtualip および azure_load_balancer リソースを含むグループを作成します。
```
sudo pcs resource group add virtualip_group azure_load_balancer virtualip
```

制約を追加する

Azure ロードバランサーの IP アドレスと AG リソースが同じノードで実行されるように、コロケーション制約を構成する必要があります。次のコマンドを実行します。
```
sudo pcs constraint colocation add azure_load_balancer ag_cluster-master INFINITY with-rsc-role=Master
```
順序制約を作成して、Azure ロードバランサーの IP アドレスよりも前に AG リソースが稼働するようにします。コロケーション制約により順序制約が暗黙に示されますが、これによって適用されます。
```
sudo pcs constraint order promote ag_cluster-master then start azure_load_balancer
```

制約を確認するには、次のコマンドを実行します。

sudo pcs constraint list --full

次の出力が表示されます。

Location Constraints:
Ordering Constraints:
  promote ag_cluster-master then start virtualip (kind:Mandatory) (id:order-ag_cluster-master-virtualip-mandatory)
  promote ag_cluster-master then start azure_load_balancer (kind:Mandatory) (id:order-ag_cluster-master-azure_load_balancer-mandatory)
Colocation Constraints:
  virtualip with ag_cluster-master (score:INFINITY) (with-rsc-role:Master) (id:colocation-virtualip-ag_cluster-master-INFINITY)
  azure_load_balancer with ag_cluster-master (score:INFINITY) (with-rsc-role:Master) (id:colocation-azure_load_balancer-ag_cluster-master-INFINITY)
Ticket Constraints:

このチュートリアルでは、次のサンプルリポジトリに SLES 15 を使用します。

プライマリ仮想マシンにログインします。 Azure Load Balancer のプローブポートを有効にするには、リソースを作成する必要があります (この例では 59999 が使用されています)。次のコマンドを実行します。
```
sudo crm configure
primitive azure_load_balancer azure-lb port=59999 op monitor timeout=20s interval=10
commit
quit
```

admin-ip および azure_load_balancer リソースを含むグループを作成します。

sudo crm configure group admin-ip-group admin-ip azure_load_balancer

グループを作成するとすぐに、次の例に示すように、コロケーション制約と順序制約が変更され、admin-ip リソースではなくグループに反映されるように更新されます。

INFO: modified colocation:vip_on_master from admin-ip to admin-ip-group
INFO: modified order:ag_first from admin-ip to admin-ip-group

状態を確認すると、次のようにグループが表示されます。

sudo crm status

Cluster Summary:
  * Stack: corosync
  * Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
  * Last updated: Fri Mar 10 15:50:53 2023
  * Last change:  Fri Mar 10 15:50:48 2023 by root via cibadmin on sles1
  * 3 nodes configured
  * 6 resource instances configured

Node List:
  * Online: [ sles1 sles2 sles3 ]

Full List of Resources:
  * rsc_st_azure        (stonith:fence_azure_arm):              Started sles2
  * Clone Set: ms-ag_cluster [ag_cluster] (promotable):
    * Masters: [ sles1 ]
    * Slaves: [ sles2 sles3 ]
  * Resource Group: admin-ip-group:
    * admin-ip  (ocf::heartbeat:IPaddr2):                       Started sles1
    * azure_load_balancer       (ocf::heartbeat:azure-lb):      Started sles1

変更された制約は、コマンド sudo crm configure show を使用して表示できます。

  node 1: sles1
  node 2: sles2
  node 3: sles3
  primitive admin-ip IPaddr2 \
         params ip=10.0.0.93 \
         op monitor interval=10 timeout=20
  primitive ag_cluster ocf:mssql:ag \
         params ag_name=ag1 \
         meta failure-timeout=60s \
         op start timeout=60s interval=0 \
         op stop timeout=60s interval=0 \
         op promote timeout=60s interval=0 \
         op demote timeout=10s interval=0 \
         op monitor timeout=60s interval=10s \
         op monitor timeout=60s interval=11s role=Master \
         op monitor timeout=60s interval=12s role=Slave \
         op notify timeout=60s interval=0
  primitive azure_load_balancer azure-lb \
         params port=59999 \
         op monitor timeout=20s interval=10
  primitive rsc_st_azure stonith:fence_azure_arm \
         params subscriptionId=61868ab8-16d4-44ec-a9ff-f35d05922847 resourceGroup=amvindomain tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47 login=b6940c8c-e3eb-4561-b45e-a9a51b791728 passwd="******" pcmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_host_map="sles1:sles1;sles2:sles2;sles3:sles3" \
         op monitor interval=3600 timeout=120
  group admin-ip-group admin-ip azure_load_balancer
  ms ms-ag_cluster ag_cluster \
         meta master-max=1 master-node-max=1 clone-max=3 clone-node-max=1 notify=true
  order ag_first Mandatory: ms-ag_cluster:promote admin-ip-group:start
  colocation vip_on_master inf: admin-ip-group ms-ag_cluster:Master
  property cib-bootstrap-options: \
         have-watchdog=false \
         dc-version="2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712" \
         cluster-infrastructure=corosync \
         cluster-name=sqlcluster \
         stonith-enabled=true \
         concurrent-fencing=true \
         stonith-timeout=900
  rsc_defaults rsc-options: \
         resource-stickiness=1 \
         migration-threshold=3
  op_defaults op-options: \
         timeout=600 \
         record-pending=true

以下のコマンドを実行して、Pacemaker でロードバランサーリソースを作成します。

sudo crm configure primitive azure-load-balancer azure-lb params port=59999

コロケーション制約と昇格制約を Pacemaker クラスターに追加する

リスナーと AG リソースがクラスター内の同じサーバーで常に実行されるようにするには、コロケーション制約を作成する必要があります。

sudo crm configure colocation ag-with-listener INFINITY: virtualip-group ms-ag1:Master

昇格/順序制約を作成します。この制約は、フェールオーバー中に新しいプライマリサーバーで可用性グループをオンラインにし、そのサーバーでリスナーを開始するように Pacemaker に指示します。

sudo crm configure order ag-before-listener Mandatory: ms-ag1:promote virtualip-group:start

コロケーション制約を表示します。

sudo crm configure show ag-with-listener

出力は次の例のようになります。

Colocation ag-with-listener inf: virtual ip-group ms-ag1:Master

順序制約を表示します。

sudo crm configure show ag-before-listener

出力は次の例のようになります。

order ag-before-listener Mandatory: ms-ag1:promot virtual ip-group:start

可用性グループリスナーを作成する

プライマリノードで、sqlcmd または SSMS で次のコマンドを実行します。以下で使用されている IP アドレスを virtualip の IP アドレスに置き換えてください。

SQL Server 2022 以降のバージョン:

ALTER AVAILABILITY GROUP [ag1]
ADD LISTENER 'ag1-listener' (
    WITH IP((
        '10.0.0.7',
        '0.0.0.0'
    )),
    PORT = 1433
);
GO

SQL Server 2017 および SQL Server 2019:

ALTER AVAILABILITY GROUP [ag1]
ADD LISTENER 'ag1-listener' (
    WITH IP((
        '10.0.0.7',
        '255.255.255.255'
    )),
    PORT = 1433
);
GO

各 VM ノードにログインします。次のコマンドを使用して hosts ファイルを開き、各マシンで ag1-listener のホスト名解決を設定します。
```
sudo vi /etc/hosts
```
vi エディターで、テキストを挿入するために「i」と入力します。空白行に、ag1-listener の IP アドレスを追加します。次に、IP アドレスの後にスペースを入れ、ag1-listener を追加します。
```
<IP of ag1-listener> ag1-listener
```
vi エディターを終了するには、まず Esc キーを押し、コマンド :wq を入力してファイルを書き込み、終了します。これを各ノードで行います。

リスナーとフェールオーバーをテストする

このセクションでは、SQL Server AG リスナーへのログインとフェールオーバーのテストについて説明します。

可用性グループリスナーを使用して SQL Server へのログインをテストする

sqlcmd を使用し、AG リスナー名を使用して SQL Server のプライマリノードにログインします。
- 以前に作成したログインを使用し、<YourPassword> を適切なパスワードに置き換えます。次の例では、SQL Server で作成された sa ログインを使用します。
```
sqlcmd -S ag1-listener -U sa -P <YourPassword>
```
接続先のサーバーの名前を確認します。 sqlcmd で次のコマンドを実行します。
```
SELECT @@SERVERNAME;
```
出力には、現在のプライマリノードが表示されます。フェールオーバーを一度もテストしたことがない場合、これは VM1 になります。

exit コマンドを入力して、SQL Server セッションを終了します。

フェールオーバーをテストする

次のコマンドを実行して、プライマリレプリカを <VM2> または別のレプリカに手動でフェールオーバーします。 <VM2> は、実際のサーバー名の値に置き換えてください。
```
sudo pcs resource move ag_cluster-master <VM2> --master
```
制約を確認すると、手動フェールオーバーが理由で別の制約が追加されたことがわかります。
```
sudo pcs constraint list --full
```
ID cli-prefer-ag_cluster-master の制約が追加されたことがわかります。
次のコマンドを使用して、ID が cli-prefer-ag_cluster-master の制約を削除します。
```
sudo pcs constraint remove cli-prefer-ag_cluster-master
```
コマンド sudo pcs resource を使用してクラスターリソースを確認すると、プライマリインスタンスが <VM2> になっていることがわかります。

Note

この記事には、Microsoft が使用しなくなった "スレーブ" という用語への言及が含まれています。ソフトウェアからこの用語が削除された時点で、この記事から削除します。
```
[<username>@<VM1> ~]$ sudo pcs resource
Master/Slave Set: ag_cluster-master [ag_cluster]
    Masters: [ <VM2> ]
    Slaves: [ <VM1> <VM3> ]
Resource Group: virtualip_group
    azure_load_balancer        (ocf::heartbeat:azure-lb):      Started <VM2>
    virtualip  (ocf::heartbeat:IPaddr2):       Started <VM2>
```
sqlcmd を使用し、リスナー名を使用してプライマリレプリカにログインします。
- 以前に作成したログインを使用し、<YourPassword> を適切なパスワードに置き換えます。次の例では、SQL Server で作成された sa ログインを使用します。
```
sqlcmd -S ag1-listener -U sa -P <YourPassword>
```
接続先のサーバーを確認します。 sqlcmd で次のコマンドを実行します。
```
SELECT @@SERVERNAME;
```
これで、フェールオーバー先の VM に接続していることがわかります。

可用性グループリスナーを使用して SQL Server へのログインをテストする

sqlcmd を使用し、AG リスナー名を使用して SQL Server のプライマリノードにログインします。
- 以前に作成したログインを使用し、<YourPassword> を適切なパスワードに置き換えます。次の例では、SQL Server で作成された sa ログインを使用します。
```
sqlcmd -S ag1-listener -U sa -P <YourPassword>
```
接続先のサーバーの名前を確認します。 sqlcmd で次のコマンドを実行します。
```
SELECT @@SERVERNAME;
```
出力には、現在のプライマリノードが表示されます。フェールオーバーを一度もテストしたことがない場合、これは VM1 になります。

exit コマンドを入力して、SQL Server セッションを終了します。

フェールオーバーをテストする

次のコマンドを実行して、プライマリレプリカを <VM2> または別のレプリカに手動でフェールオーバーします。 <VM2> は、実際のサーバー名の値に置き換えてください。
```
sudo crm resource move ms-ag_cluster sles2
```
制約を確認すると、手動フェールオーバーが理由で別の制約が追加されたことがわかります。
```
sudo crm configure show
```
ID cli-prefer-ms-ag_cluster の制約が追加されたことがわかります。
次のコマンドを使用して、ID が cli-prefer-ms-ag_cluster の制約を削除します。
```
sudo crm configure delete cli-prefer-ms-ag_cluster
```

コマンド sudo crm status を使用してクラスターリソースを確認すると、プライマリインスタンスが SLES2 になっていることがわかります。

Cluster Summary:
  * Stack: corosync
  * Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
  * Last updated: Fri Mar 10 15:55:50 2023
  * Last change:  Fri Mar 10 15:55:28 2023 by root via crm_resource on sles1
  * 3 nodes configured
  * 6 resource instances configured

Node List:
  * Online: [ sles1 sles2 sles3 ]

Full List of Resources:
  * rsc_st_azure        (stonith:fence_azure_arm):             Started sles2
  * Clone Set: ms-ag_cluster [ag_cluster] (promotable):
  * ag_cluster        (ocf::mssql:ag):         Slave sles1 (Monitoring)
  * ag_cluster        (ocf::mssql:ag):         Master sles2 (Monitoring)
  * Slaves: [ sles3 ]
Resource Group: admin-ip-group:
  * admin-ip                  (ocf::heartbeat:IPaddr2):        Started sles2
  * azure_load_balancer       (ocf::heartbeat:azure-lb):       Started sles2

sqlcmd を使用し、リスナー名を使用してプライマリレプリカにログインします。
- 以前に作成したログインを使用し、<YourPassword> を適切なパスワードに置き換えます。次の例では、SQL Server で作成された sa ログインを使用します。
```
sqlcmd -S ag1-listener -U sa -P <YourPassword>
```
接続先のサーバーを確認します。 sqlcmd で次のコマンドを実行します。
```
SELECT @@SERVERNAME;
```
これで、フェールオーバー先の VM に接続していることがわかります。

可用性グループリスナーを使用して SQL Server へのログインをテストする

sqlcmd を使用し、AG リスナー名を使用して SQL Server のプライマリノードにログインします。
- 以前に作成したログインを使用し、<YourPassword> を適切なパスワードに置き換えます。次の例では、SQL Server で作成された sa ログインを使用します。
```
sqlcmd -S <listenerIP> -U sa -P <YourPassword>
```
接続先のサーバーの名前を確認します。 sqlcmd で次のコマンドを実行します。
```
SELECT @@SERVERNAME;
```
出力には、現在のプライマリノードが表示されます。フェールオーバーを一度もテストしたことがない場合、これは Ubuntu1 になります。

exit コマンドを入力して、SQL Server セッションを終了します。

フェールオーバーをテストする

フェールオーバーをテストするには、次のコマンドでプライマリレプリカを別のノードへと移動します。

sudo crm configure delete cli-prefer-ms-ag1
sudo crm resource move ms-ag1 ubuntu2

次を実行して、状態を確認します。

sudo crm status

出力は次の例のようになります。

Cluster Summary:
  * Stack: corosync
  * Current DC: ubuntu1 (version 2.0.3-4b1f869f0f) - partition with quorum
  * Last updated: Wed Nov 29 07:01:32 2023
  * Last change:  Sun Nov 26 17:00:26 2023 by root via cibadmin on ubuntu1
  * 3 nodes configured
  * 6 resource instances configured

Node List:
  * Online: [ ubuntu1 ubuntu2 ubuntu3 ]

Full List of Resources:
  * Clone Set: ms-ag1 [ag1_cluster] (promotable):
    * Masters: [ ubuntu2 ]
    * Slaves : [ ubuntu1 ubuntu3 ]
  * Resource Group:  virtual ip-group:
    * azure-load-balancer  (ocf  :: heartbeat:azure-lb):           Started ubuntu2     
    * virtualip     (ocf :: heartbeat: IPaddr2):                   Started ubuntu2
  * fence-vm     (stonith:fence_azure_arm):                        Started ubuntu1

これで、フェンスを除くリソースが、新しいプライマリである ubuntu2 ノードに移動されました。

次のステップ

SQL Server インスタンスで可用性グループリスナーを利用するには、ロードバランサーを作成し、構成する必要があります。

Load balancer と可用性グループリスナーの構成 (Azure VM 上の SQL Server)

チュートリアル: Linux Virtual Machines で可用性グループリスナーを構成する

前提条件

Azure Portal でロードバランサーを作成する

ロードバランサーを作成する

バックエンドプールを構成する

プローブを作成する

負荷分散規則を設定する

可用性グループリスナーリソースを作成する

クラスターにロードバランサーリソースを作成する

制約を追加する

コロケーション制約と昇格制約を Pacemaker クラスターに追加する

可用性グループリスナーを作成する

リスナーとフェールオーバーをテストする

可用性グループリスナーを使用して SQL Server へのログインをテストする

フェールオーバーをテストする

可用性グループリスナーを使用して SQL Server へのログインをテストする

フェールオーバーをテストする

可用性グループリスナーを使用して SQL Server へのログインをテストする

フェールオーバーをテストする

次のステップ

フィードバック

フィードバック

その他のリソース

チュートリアル: Linux Virtual Machines で可用性グループ リスナーを構成する

前提条件

Azure Portal でロード バランサーを作成する

ロード バランサーを作成する

バックエンド プールを構成する

プローブを作成する

負荷分散規則を設定する

可用性グループ リスナー リソースを作成する

クラスターにロード バランサー リソースを作成する

制約を追加する

可用性グループ リスナーを作成する

リスナーとフェールオーバーをテストする

可用性グループ リスナーを使用して SQL Server へのログインをテストする

フェールオーバーをテストする

次のステップ

フィードバック

フィードバック

その他のリソース

チュートリアル: Linux Virtual Machines で可用性グループリスナーを構成する

Azure Portal でロードバランサーを作成する

ロードバランサーを作成する

バックエンドプールを構成する

可用性グループリスナーリソースを作成する

クラスターにロードバランサーリソースを作成する

可用性グループリスナーを作成する

可用性グループリスナーを使用して SQL Server へのログインをテストする