Always On 可用性グループと Pacemaker を使用して Linux で SQL Server クラスタを設定する

このチュートリアルでは、高可用性（HA）と障害復旧（DR）のソリューションとして、Always On 可用性グループ（AOAG）と Pacemaker を使用して Linux に Microsoft SQL Server データベースシステムをデプロイする方法について説明します。このドキュメントにおいては、障害とはプライマリデータベースで障害が発生する、可用性が失われるイベントを意味します。

プライマリデータベースは、配置されているリージョンに障害が発生したり、アクセスできなくなったりした場合に障害となる可能性があります。リージョンが利用可能で正常に動作している場合でも、システムエラーが原因でプライマリデータベースに障害が発生することがあります。この場合、障害復旧はクライアントが処理を継続するために、セカンダリデータベースを利用できるようにするプロセスです。

このチュートリアルは、データベースアーキテクト、管理者、エンジニアを対象としています。

目標

Linux に SQL Server をデプロイする
高可用性と障害復旧のために Always On 可用性グループを作成する
SQL Server クラスタのフェイルオーバーを管理するために Pacemaker をインストールして構成する
SQL Server を使用して可用性グループにトラフィックをルーティングするようにロードバランサを構成する
STONITH（Shoot The Other Node In The Head）フェンスを設定して、HA の整合性を確保する
フェイルオーバーテストを実行して、SQL Server クラスタが想定どおりに動作していることを確認する

費用

このチュートリアルでは、Google Cloud の課金対象となる以下のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。

始める前に

このチュートリアルでは、Google Cloud プロジェクトが必要です。新しいプロジェクトを作成することも、すでに作成済みのプロジェクトを選択することもできます。

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

プロジェクトセレクタに移動
Google Cloud プロジェクトで課金が有効になっていることを確認します。
Google Cloud プロジェクトで NetApp Cloud Volumes API が有効になっていることを確認します。
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

プロジェクトとネットワークを準備する

SQL Server Always On 可用性グループをデプロイするために Google Cloud プロジェクトと VPC を準備するには、次の操作を行います。

Google Cloud コンソールで、[Cloud Shell をアクティブにする] ボタンをクリックして Cloud Shell を開きます。

Google Cloud コンソールに移動
デフォルトのプロジェクト ID を設定します。
```
gcloud config set project PROJECT_ID
```
PROJECT_ID は、Google Cloud プロジェクトの ID に置き換えます。
デフォルトのリージョンを設定します。
```
gcloud config set compute/region REGION
```
REGION は、デプロイするリージョンの ID に置き換えます。
デフォルトゾーンを設定します。
```
gcloud config set compute/zone ZONE
```
ZONE は、デプロイするゾーンの ID に置き換えます。前の手順で指定したリージョン内の有効なゾーンである必要があります。

Linux VM を作成する

SQL Server クラスタの HA とクォーラムを実現するには、3 台の Linux 仮想マシン（VM）をデプロイして SQL Server クラスタをホストします。

次の変数を初期化します。
```
PD_SIZE=30
MACHINE_TYPE=n2-standard-8
```

Linux VM を作成します。

gcloud compute instances create node-1 \
--project=PROJECT_ID \
--zone REGION-a \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-2 \
--project=PROJECT_ID \
--zone REGION-b \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-2,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-3 \
--project=PROJECT_ID \
--zone REGION-c \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-3,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

サブネット SUBNET_NAME は、VPC サブネットの名前に置き換えます。

node-1、node-2、node-3 の hosts ファイルを更新します。

注: 本番環境で使用する場合は、専用のドメインネームシステム（DNS）サーバーによってドメイン解決を管理する必要があります。
1. SSH を使用して各 VM に接続します。詳細については、Linux VM への接続のドキュメントをご覧ください。
2. hosts ファイルを開いて編集します。
```
sudo vi /etc/hosts
```
3. 各 Linux VM の内部 IP アドレスを見つけて、ホストエントリをファイルの末尾に追加します。
  
  Compute Engine に移動
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  NODE1_INTERNAL_IP、NODE2_INTERNAL_IP、NODE3_INTERNAL_IP は、各 Linux VM の内部 IP アドレスに置き換えます。
VM 間の通信を確認します。Always On 可用性グループに参加するすべての VM は、他の VM と通信できる必要があります。
1. 各 Linux VM に戻り、各 VM からコマンドを実行して、すべての VM が相互に通信できることを確認します。
```
ping -c 4 node-1
ping -c 4 node-2
ping -c 4 node-3
```

SQL Server をインストールして構成する

Always On 可用性グループに参加する 3 つの Linux VM に SQL Server エンジンをダウンロード、インストール、構成します。

node-1、node-2、node-3 に SSH で接続し、次の手順を行います。
1. 公開リポジトリキーをインポートします。
```
wget -qO- https://packages.microsoft.com/keys/microsoft.asc \
| sudo tee /etc/apt/trusted.gpg.d/microsoft.asc
```
2. SQL Server Ubuntu リポジトリを登録します。
```
sudo add-apt-repository \
"$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list)"
```
3. パッケージインデックスファイルを更新して SQL Server をインストールします。
```
sudo apt-get update
sudo apt-get install -y mssql-server
```
SQL Server を構成します。
1. mssql-conf ツールを実行します。
```
sudo /opt/mssql/bin/mssql-conf setup
```
2. SQL Server のエディションとして [Developer] エディションを選択し、ライセンス契約に同意します。
  
  Developer エディションにはすべてのエンタープライズ機能が含まれていますが、本番環境以外でのみ使用できます。詳しくは、SQL Server のエディションと Microsoft ライセンスをご覧ください。
  
  注: VM インスタンスごとに SQL Server ライセンスが必要です。Microsoft アプリケーションサーバーを実行している場合は、ソフトウェアアシュアランスによるライセンスモビリティにより Google Cloud に移行できます。詳細については、Microsoft サーバーアプリケーションでライセンスモビリティを使用するをご覧ください。独自のライセンスの使用せず、Google からライセンスを購入する必要がある場合（PAYG）は、ブートディスクに SQL Server ライセンスを追加するの手順に沿って、VM インスタンスごとにライセンスを購入してください。
3. SA アカウントのパスワードを指定します。
4. mssql-server サービスが実行されていることを確認します。
```
systemctl status mssql-server --no-pager
```
VM でファイアウォールが有効になっている場合は、SQL Server のファイアウォールを開きます。
1. 次のコマンドを実行して、Uncomplicated Firewall がインストールされて有効になっているかどうかを確認します。
```
sudo ufw status
```
2. ステータスが有効になっている場合は、次のコマンドを実行してポートを開きます。
```
sudo ufw allow 1433
sudo ufw allow 5022
sudo ufw reload
```
  注: SQL Server または可用性グループのエンドポイントに他のポートを使用している場合は、ファイアウォールルールを適宜変更してください。

SQL Server に接続する

これで SQL Server がインストールされました。接続するには、同じ VPC に Windows マシンを作成し、SQL Server Management Studio（SSMS）をインストールして、VM で新しく作成した SQL Server インスタンスに接続します。

Windows VM を作成します。

Cloud Shell に戻り、次のコマンドを実行します。

gcloud compute instances create node4 \
--project=PROJECT_ID \
--zone ZONE \
--subnet SUBNET_NAME \
--machine-type=n2-standard-4 \
--create-disk=auto-delete=yes,boot=yes,device-name=node4,image=projects/windows-cloud/global/images/windows-server-2022-dc-v20240415,mode=rw,size=50,type=projects/p3rf-sqlserver/zones/ZONE/diskTypes/pd-balanced

リモートデスクトップを使用して node-4 の Windows VM に接続します。
node-4 の hosts ファイルを更新します。
1. メモ帳を管理者モードで開きます。
2. [File] > [Open] をクリックして、hosts ファイルを開きます。
```
c:\Windows\System32\drivers\etc\hosts
```
3. ホストエントリをファイルの末尾に追加します。
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  NODE1_INTERNAL_IP、NODE2_INTERNAL_IP、NODE3_INTERNAL_IP は、各 VM のそれぞれの内部 IP アドレスに置き換えます。
4. 保存して終了します。
Linux VM への接続を確認します。
1. node-4 の Windows VM に接続します
2. [スタート] ボタンをクリックし、検索バーに「powershell」と入力します。
3. クリックして Windows PowerShell ISE アプリを開きます。
4. 次のコマンドを実行して接続をテストします。
```
ping node-1
ping node-2
ping node-3
```
次の手順で Microsoft SQL Server Management Studio（SSMS）をインストールします。
1. リモートデスクトップを使用して node-4 の Windows VM に接続します。
2. RDP セッションで、すべてのウィンドウを最小化し、Windows PowerShell ISE アプリを起動します。
3. PowerShell プロンプトで、SSMS インストーラをダウンロードして実行します。
```
Start-BitsTransfer `
-Source "https://aka.ms/ssmsfullsetup" `
-Destination "$env:Temp\ssms-setup.exe"
& $env:Temp\ssms-setup.exe
```
4. SSMS インストーラで [インストール] をクリックします。
5. プロンプトの内容に同意して、変更を許可します。
6. インストールが完了したら、[再起動] をクリックしてリモートマシンを再起動します。これで RDP セッションが終了します。
node-1 の SQL Server インスタンスに接続します。
1. RDP を使用して node-4 VM に戻ります。
2. SSMS を開き、次のパラメータを使用して node-1 に接続します。
```
Server name: node-1
Authentication: SQL Server Authentication
Login: sa
```
  詳細については、SQL Server Management Studio のドキュメントで SQL Server インスタンスへの接続をご覧ください。
3. インストール時に作成した SA アカウントのパスワードを入力します。
4. [サーバー証明書を信頼する] を選択します。
5. [接続] をクリックします。

Always On 可用性グループを有効にする

Linux では、可用性グループを Pacemaker で管理されるリソースとして追加する前に、まず可用性グループを作成する必要があります。

可用性グループに参加している各 SQL Server インスタンスで Always On 可用性グループ機能を有効にします。node-1、node-2、node-3 で次のコマンドを実行します。

注: 変更を有効にするには、mssql-server サービスを再起動します。
```
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server
```
SSMS を使用して、可用グループのプライマリホストであるインスタンスに接続します。

ヒント: プライマリホストとして node-1 を選択することをおすすめします。
1. 新しいクエリウィンドウを開きます。
2. 次のコードスニペットを実行して、暗号鍵、証明書、秘密鍵を作成します。
  
  ヒント: 暗号鍵と秘密鍵には安全なパスワードを選択してください。後で使用するこれらのパスワードをメモしておきます。
  注: パスワードは 8 文字以上で、大文字、小文字、数字、記号の 4 種類の文字セットのうち 3 種類の文字を含める必要があります。
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate WITH SUBJECT = 'my_ag_cert';
BACKUP CERTIFICATE my_ag_certificate
TO FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    ENCRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  ENCRYPTION_KEY_PASSWORD と PRIVATE_KEY_PASSWORD は、暗号鍵と秘密鍵のパスワードに置き換えます。

証明書と鍵ファイルを転送する

前の手順で作成した証明書ファイルと鍵ファイルを SQL Server のセカンダリノードに移動する必要があります。証明書ファイルと鍵ファイルを node-2 と node-3 のセカンダリノードに移動する方法はいくつかあります。

その他の転送オプションについては、Linux VM にファイルを転送するをご覧ください。

Cloud Storage を使用して証明書と鍵ファイルを転送する

Cloud Storage を作成し、プライマリクラスタノードからセカンダリクラスタノードにファイルを転送します。

Cloud Storage バケットを作成します。
1. Cloud Shell に戻り、次のコマンドを実行します。
```
gcloud storage buckets create gs://BUCKET_NAME \
--project=PROJECT_ID \
--location=REGION \
--public-access-prevention
```
  BUCKET_NAME は、作成するバケットの名前に置き換えます。PROJECT_ID は Google Cloud プロジェクトの ID に置き換え、REGION はバケットをデプロイするリージョンの ID に置き換えます。
詳細については、バケットを作成するをご覧ください。
node-1、node-2、node-3 で SSH に戻り、Google Cloud CLI を初期化します。
1. 次のコマンドを実行して、Google Cloud CLI を初期化します。
```
gcloud init
```
2. プリインストールされているサービスアカウントを使用するには、[option [1]] を選択します。
3. プロジェクトの名前を入力します。
4. デフォルトのリージョンとゾーンを設定するには、質問に対して n と入力します。
node-1 に戻り、ファイルを Cloud Storage にコピーします。
1. 次のコマンドを使用して、新しく作成した 2 つのファイルを Cloud Storage にアップロードします。
```
sudo gsutil cp /var/opt/mssql/data/my_ag_certificate.cer gs://BUCKET_NAME/
sudo gsutil cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME/
```
  BUCKET_NAME は、作成したバケットの名前に置き換えます。
node-2 と node-3 に戻り、Cloud Storage からファイルをコピーします。
1. Cloud Storage から node-2 に 2 つのファイルをダウンロードします。
```
sudo gsutil cp gs://BUCKET_NAME/my_ag_certificate.cer /var/opt/mssql/data/
sudo gsutil cp gs://BUCKET_NAME/my_ag_certificate.pvk /var/opt/mssql/data/
```
  BUCKET_NAME は、作成したバケットの名前に置き換えます。
2. root シェルでコマンドを実行して、node-2 と node-3 のファイルのオーナー権限を変更します。
```
chown mssql:mssql /var/opt/mssql/data/my_ag_certificate.*
chmod 660 /var/opt/mssql/data/my_ag_certificate.*
```
  ヒント: コマンドを実行したら、必ず root シェルを終了してください。

データベースミラーリングエンドポイントを設定する

このセクションでは、SQL Server クラスタ内の各ノードで共有される暗号鍵と証明書を使用してデータベースエンドポイントを作成し、安全なデータレプリケーションを実現します。

node-4 の Windows VM に戻り、データベースミラーリングのエンドポイントを作成します。
1. SSMS を使用して、node-1、node-2、node-3 の SQL Server データベースに接続します。サーバー名として node-1、node-2、node-3 を使用し、SA アカウントに設定したパスワードをそれぞれ使用して、SQL Server への接続の手順を行います。
2. コピーしたファイルから、セカンダリ VM の node-2 と node-3 に証明書を作成します。プライマリノードで証明書と鍵を作成したときに指定したパスワードを使用します。
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate
FROM FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    DECRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  ENCRYPTION_KEY_PASSWORD と PRIVATE_KEY_PASSWORD は、暗号鍵と秘密鍵のパスワードに置き換えます。
3. SSMS に戻り、node-1、node-2、node-3 の T-SQL コマンドを実行して、データベースミラーリングのエンドポイントを作成します。
  
  ヒント: デフォルトのリスニングポートは 5022 ですが、使用可能な他のポートを使用することもできます。
```
CREATE ENDPOINT [my_ag_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE my_ag_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );

ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED;
```

Always On 可用性グループを作成して構成する

次に、SQL Server Management Studio を使用して SQL Server Always On 可用性グループを作成し、レプリケーション用に以前に作成したエンドポイントを使用します。

Windows VM に戻り、SSMS を開きます。
1. node-1 の SQL Server データベースエンジンに接続し、新しいクエリウィンドウを開きます。

レプリケーションの準備として、データベースを作成してバックアップします。

USE MASTER;

CREATE DATABASE [bookshelf];
ALTER DATABASE [bookshelf] SET RECOVERY FULL;
BACKUP DATABASE [bookshelf]
TO DISK = N'/var/opt/mssql/data/bookshelf.bak';

Always On 可用性グループを作成します。

SSMS で node-1、node-2、node-3 に対して次の T-SQL コマンドを実行します。これにより、エンドポイントが有効になり、各ノードの SQL Server でデータレプリケーションの準備が整います。

IF (SELECT state FROM sys.endpoints WHERE name = N'my_ag_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED
END
GO

IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

node-1 で次の T-SQL コマンドを実行して、AOAG を作成します。

USE [master]
GO

CREATE AVAILABILITY GROUP [aoag1]
WITH (
    AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    DB_FAILOVER = OFF,
    DTC_SUPPORT = NONE,
    CLUSTER_TYPE = EXTERNAL,
    REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0
)
FOR DATABASE [bookshelf]
REPLICA ON N'node-1' WITH (
    ENDPOINT_URL = N'TCP://node-1:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-2' WITH (ENDPOINT_URL = N'TCP://node-2:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-3' WITH (ENDPOINT_URL = N'TCP://node-3:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)
);
GO

SQL Server インスタンスごとに node-2 と node-3 で次の T-SQL コマンドを実行して、新しい可用性グループに参加します。
```
ALTER AVAILABILITY GROUP [aoag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [aoag1] GRANT CREATE ANY DATABASE;
GO
```

bookshelf という新しいデータベースを作成し、node-1 で実行されている SQL Server インスタンスの aoag1 という新しい可用性グループに新しいデータベースを追加しました。Node-2 と node-3 が可用性グループに追加されました。bookshelf データベースのデータが 3 つのノードすべてにわたる SQL Server インスタンス間で同期的に複製されます。

Pacemaker をインストールして構成する

Pacemaker は、Corosync クラスタエンジンで使用されるオープンソースの高可用性リソースマネージャーソフトウェアです。このセクションでは、各 VM に Pacemaker をインストールして構成します。

Pacemaker クラスタマネージャーの SQL Server ログインを作成する

このセクションでは、Pacemaker が各 SQL Server インスタンスにログインして可用性グループを管理するために使用する新しい SQL Server アカウントを作成します。

node-1、node-2、node-3 で次の T-SQL コマンドを実行します。
```
USE [master];

CREATE LOGIN [pacemaker] with PASSWORD= N'PACEMAKER_LOGIN_PASSWORD';
GO
```
PACEMAKER_LOGIN_PASSWORD は、Pacemaker アカウントのパスワードに置き換えます。

T-SQL コマンドを実行して、Pacemaker のログイン権限を可用性グループに付与します。

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker];
GRANT VIEW SERVER STATE TO [pacemaker];
GO

node-1、node-2、node-3 で SSH に戻り、Pacemaker のログインとパスワードを SQL Server のシークレットフォルダに保存するコマンドを実行します。
```
echo 'pacemaker' >> ~/pacemaker-passwd
echo 'PACEMAKER_LOGIN_PASSWORD' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd
```
PACEMAKER_LOGIN_PASSWORD は、Pacemaker アカウントのパスワードに置き換えます。

Pacemaker をインストールする

次に、Pacemaker をインストールし、リソース管理のためにすべての Linux VM にログインアカウントを設定します。

Pacemaker のファイアウォールポートを開きます。
1. node-1、node-2、node-3 で次のコマンドを実行して、Uncomplicated Firewall がインストールされ、有効になっているかどうかを確認します。
```
sudo ufw status
```
2. ufw が有効になっている場合は、node-1、node-2、node-3 でファイアウォールポートを開きます。
```
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 5405/udp
sudo ufw allow 21064/tcp
sudo ufw allow 1433/tcp
sudo ufw allow 5022/tcp
sudo ufw reload
```
  注: SQL Server または可用性グループのエンドポイントに他のポートを使用している場合は、ファイアウォールルールを適宜変更してください。

node-1、node-2、node-3 に Pacemaker をインストールします。

sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents  fence-agents corosync python3-azure pcs

node-1、node-2、node-3 で hacluster ユーザーの新しいパスワードを設定します。

注: 3 つのノードすべてで同じパスワードを設定します。このパスワードは、残りのセットアップで必要になります。
```
sudo passwd hacluster
```

Corosync を設定する

ここで、クラスタ全体でクラスタメンバーシップとメッセージを管理するように Corosync を構成します。

node-1 に Corosync の認証キーを作成します。
```
sudo corosync-keygen
```

Corosync 構成ファイルを変更します。

node-1 に戻り、corosync.conf ファイルを変更します。
```
sudo vi /etc/corosync/corosync.conf
```

ハイライト表示されたセクションを更新します。編集後、ファイルは次の例のようになります。

# Please read the corosync.conf.5 manual page
totem {
    version: 2

    # Corosync itself works without a cluster name, but DLM needs one.
    # The cluster name is also written into the VG metadata of newly
    # created shared LVM volume groups, if lvmlockd uses DLM locking.
    cluster_name: my_agcluster

    # crypto_cipher and crypto_hash: Used for mutual node authentication.
    # If you choose to enable this, then do remember to create a shared
    # secret with "corosync-keygen".
    # enabling crypto_cipher, requires also enabling of crypto_hash.
    # crypto works only with knet transport
    transport: udpu
    crypto_cipher: none
    crypto_hash: none
}

logging {
    # Log the source file and line where messages are being
    # generated. When in doubt, leave off. Potentially useful for
    # debugging.
    fileline: off
    # Log to standard error. When in doubt, set to yes. Useful when
    # running in the foreground (when invoking "corosync -f")
    to_stderr: yes
    # Log to a log file. When set to "no", the "logfile" option
    # must not be set.
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    # Log to the system log daemon. When in doubt, set to yes.
    to_syslog: yes
    # Log debug messages (very verbose). When in doubt, leave off.
    debug: off
    # Log messages with time stamps. When in doubt, set to hires (or on)
    #timestamp: hires
    logger_subsys {
        subsys: QUORUM
        debug: off
    }
}
quorum {
    # Enable and configure quorum subsystem (default: off)
    # see also corosync.conf.5 and votequorum.5
    provider: corosync_votequorum
}
nodelist {
    # Change/uncomment/add node sections to match cluster configuration

    node {
        # Hostname of the node
        name: node-1
        # Cluster membership node identifier
        nodeid: 1
        # Address of first link
        ring0_addr: NODE1_INTERNAL_IP
        # When knet transport is used it's possible to define up to 8 links
        #ring1_addr: 192.168.1.1
    }
    node {
        name: node-2
        nodeid: 2
        ring0_addr: NODE2_INTERNAL_IP
    }
    node {
        name: node-3
        nodeid: 3
        ring0_addr: NODE3_INTERNAL_IP
    }
    # ...
}

NODE1_INTERNAL_IP、NODE2_INTERNAL_IP、NODE3_INTERNAL_IP は、各ノードの内部 IP アドレスに置き換えます。

Cloud Storage を使用して構成ファイルを転送する

生成された認証キーと corosync 構成ファイルを node-1 から Cloud Storage バケットにアップロードします。
```
sudo gsutil cp /etc/corosync/authkey gs://BUCKET_NAME/
sudo gsutil cp  /etc/corosync/corosync.conf gs://BUCKET_NAME/
```
BUCKET_NAME は、以前に作成したバケットの名前に置き換えます。
Authkey と構成ファイルを node-2 と node-3 にダウンロードします。
```
sudo gsutil cp gs://BUCKET_NAME/authkey /etc/corosync/
sudo gsutil cp gs://BUCKET_NAME/corosync.conf /etc/corosync/
```
BUCKET_NAME は、Corosync 構成ファイルが転送されたバケットの名前に置き換えます。

node-2 と node-3 のファイルの権限を更新します。

sudo chmod 400 /etc/corosync/authkey
sudo chmod 400 /etc/corosync/corosync.conf

クラスタの通信を再開して確認する

node-1、node-2、node-3 で Pacemaker サービスと Corosync サービスを再起動します。
```
sudo systemctl restart pacemaker corosync
```
node-1 で次のコマンドを実行して、クラスタのステータスを確認します。
```
sudo crm status
```
3 つのノードがすべてオンラインになっていることを確認します。

クラスタを設定する

次に、SQL Server Always On 可用性グループの新しいリソースを作成して、Pacemaker クラスタを設定します。

node-1 で次のコマンドを実行して、クラスタプロパティを設定します。
```
sudo crm configure property stonith-enabled=false
sudo crm configure property cluster-recheck-interval=2min
sudo crm configure property start-failure-is-fatal=true
```
詳細については、クラスタオプションをご覧ください。
node-1 でコマンドを実行して、クラスタ内のノードを承認します。以前に hacluster アカウントに設定したパスワードを使用します。
```
sudo pcs cluster auth -u hacluster
```
3 つのノードがすべて承認されていることを確認します。
node-1、node-2、node-3 に Pacemaker と統合するための SQL Server リソースエージェントをインストールします。
```
sudo apt-get install mssql-server-ha
```
node-1 に戻り、クラスタに可用性グループリソースを作成します。
1. クラスタリソースマネージャーを実行します。
```
sudo crm
```
2. 「configure」と入力して構成メニューに入ります。
3. 次の構成を入力します。
```
primitive aoag1-cluster \
ocf:mssql:ag \
params ag_name="aoag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 aoag1-cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
```
4. 「commit」と入力して変更を commit します。
  
  注: フェンシングルールが設定されていないという警告が表示されます。このメッセージは無視してください。フェンシングルールは後で設定します。
5. 「exit」と入力して、クラスタリソースマネージャーを終了します。
6. 構成を確認します。
```
sudo crm status
```
  node-1 がプライマリノードに昇格したことを確認できます。Node-2 と node-3 はセカンダリノードとして設定する必要があります。

ロードバランサと可用性グループのリスナーを設定する

このセクションでは、可用性グループにトラフィックを転送する内部パススルー TCP ロードバランサを使用して、クラスタに仮想 IP アドレスとヘルスチェックリソースを作成します。

Cloud Shell に戻り、クラスタ IP として使用する静的 IP アドレスを予約します。
```
gcloud compute addresses create aoag1-cluster \
--region REGION \
--subnet SUBNET_NAME
CLUSTER_ADDRESS=$(gcloud compute addresses describe aoag1-cluster \
--region $(gcloud config get-value compute/region) \
--format=value$address$) && \
echo "Cluster IP address: $CLUSTER_ADDRESS"
```
REGION と SUBNET_NAME は、Linux VM がデプロイされているリージョンとサブネットに置き換えます。

注: 予約した IP アドレスを保存します。これは後のステップで使用します。

クラスタノードごとに非マネージドインスタンスグループを作成し、新しく作成したインスタンスグループに割り当てます。Cloud Shell で以下のコマンドを実行します。

gcloud compute instance-groups unmanaged create node-1-uig \
--zone=REGION-a
gcloud compute instance-groups unmanaged add-instances node-1-uig \
--zone=REGION-a \
--instances=node-1

gcloud compute instance-groups unmanaged create node-2-uig \
--zone=REGION-b
gcloud compute instance-groups unmanaged add-instances node-2-uig \
--zone=REGION-b \
--instances=node-2

gcloud compute instance-groups unmanaged create node-3-uig \
--zone=REGION-c
gcloud compute instance-groups unmanaged add-instances node-3-uig \
--zone=REGION-c \
--instances=node-3

REGION は、Linux VM がデプロイされているリージョンに置き換えます。

TCP ヘルスチェックを作成します。ロードバランサは、ヘルスチェックを使用して、トラフィックに適切に応答するバックエンドインスタンスを決定します。
```
gcloud compute health-checks create tcp aoag1-healthcheck \
--port=HEALTH_CHECK_PORT --proxy-header=NONE \
--check-interval=10 --timeout=10 --unhealthy-threshold=2 \
--healthy-threshold=2
```
使用可能なポート（49152～65535 のプライベート範囲）を選択して、HEALTH_CHECK_PORT を置き換えます。例: 60000。

詳細については、ヘルスチェックの概要をご覧ください。

クラスタノードにネットワークタグを追加します。ネットワークタグは、ヘルスチェックのファイアウォールルールで使用されます。

gcloud compute instances add-tags node-1 \
--tags NETWORK_TAG_NAME \
--zone REGION-a
gcloud compute instances add-tags node-2 \
--tags NETWORK_TAG_NAME \
--zone REGION-b
gcloud compute instances add-tags node-3 \
--tags NETWORK_TAG_NAME \
--zone REGION-c

NETWORK_TAG_NAME は、ネットワークタグの名前に置き換えます。

タグ名に基づいてヘルスチェックがクラスタノードに到達できるように、ファイアウォールルールを作成します。
```
gcloud compute firewall-rules create mssql-aoag1-fw-rule \
--network VPC_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags NETWORK_TAG_NAME \
--rules tcp:HEALTH_CHECK_PORT
```
詳細については、ヘルスチェックのファイアウォールルールをご覧ください。

ロードバランサのバックエンドサービスを作成します。

gcloud compute backend-services create aoag1-backend \
--load-balancing-scheme internal \
--health-checks aoag1-healthcheck \
--no-connection-drain-on-failover \
--drop-traffic-if-unhealthy \
--failover-ratio 1.0 \
--region REGION \
--global-health-checks

3 つの非マネージドインスタンスグループをバックエンドサービスに追加します。

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-1-uig \
--instance-group-zone REGION-a \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-2-uig \
--instance-group-zone REGION-b \
--failover \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-3-uig \
--instance-group-zone REGION-c \
--failover \
--region REGION

ロードバランサの転送ルールを定義します。転送ルールでは、ロードバランサがトラフィックを受け入れるポートとプロトコルを指定します。
```
gcloud compute forwarding-rules create aoag1-fwd-rule \
--load-balancing-scheme internal \
--address CLUSTER_ADDRESS \
--subnet SUBNET_NAME \
--region REGION \
--backend-service aoag1-backend \
--ports ALL
```
CLUSTER_ADDRESS は、前に予約した IP アドレスに置き換えます。

ヒント: VPC ネットワークまたは接続されたネットワークの任意のリージョンにあるクライアントがクラスタにアクセスできるようにするには、転送ルールの定義に --allow-global-access を含める必要があります。
詳細については、転送ルールをご覧ください。
設定を完了し、ネットワークロードバランサが正しく設定されているかどうかをテストするには、node-1、node-2、node-3 に HAProxy tcp listener をインストールして構成します。
1. HAProxy をインストールします。
```
sudo apt-get install haproxy
```
2. [Y] を選択してインストールを完了します。
3. haproxy.cfg ファイルを編集します。
```
sudo vi /etc/haproxy/haproxy.cfg
```
4. haproxy.cfg file のデフォルトセクションで、モードを tcp に変更します。
5. haproxy.cfg ファイルの末尾に次のセクションを追加します。
```
#---------------------------------------------------------------
# Set up health check listener for SQL Server Availability Group
#---------------------------------------------------------------
listen healthcheck
bind *:HEALTH_CHECK_PORT
```
  HEALTH_CHECK_PORT は、前に選択したヘルスチェックのポートに置き換えます。例: 6000。
6. サービスを開始して、正しく構成されていることを確認します。
```
sudo systemctl start haproxy.service
sudo systemctl enable haproxy.service
sudo systemctl restart haproxy.service
```
7. [ロードバランシング] ページに移動し、ロードバランサをクリックします。3 つの非マネージドインスタンスグループが正常と報告されていることを確認します。
  
  [ロードバランシング] に移動
  - または、Cloud Shell で次のコマンドを実行して、バックエンドサービスのステータスを確認することもできます。
```
gcloud compute backend-services get-health aoag1-backend \
--region REGION
```
    REGION は、Linux VM がデプロイされているリージョンに置き換えます。
8. 3 つの非マネージドインスタンスグループがすべて正常に動作しているという報告が表示されたら、次のステップに進みます。
  
  注: 非マネージドインスタンスグループが正常と報告されない場合は、問題のノードから haproxy.service を再起動する必要がある場合があります。
```
sudo systemctl restart haproxy.service
```
Pacemaker でヘルスチェックリソースを作成します。
1. node-1 に SSH で接続し、Pacemaker クラスタに HAProxy サービスのヘルスチェックリソースを作成します。
```
sudo pcs resource create aoag1-healthcheck \
service:haproxy \
op monitor interval=10s timeout=20s
```
2. プライマリノード node-1 でヘルスリソースが開始されていることを確認します。
```
sudo crm status
```
3. ヘルスチェックリソースがプライマリノードで開始されていない場合は、次のコマンドを使用して移動します。
```
sudo pcs resource move aoag1-healthcheck node-1
sudo pcs resource clear aoag1-healthcheck
```
  ロードバランサのヘルスチェックは、node-1 のみで正常になります。
  
  [ロードバランシング] に移動
Pacemaker クラスタに仮想 IP アドレスリソースを作成します。
1. node-1 で SSH に戻り、ノードのネットワークインターフェースの名前を確認します。次のステップでこれが必要になります。
```
ip -c link
```
2. 仮想 IP アドレスリソースを作成します。
```
sudo pcs resource create aoag1-vip ocf:heartbeat:IPaddr2 \
ip="CLUSTER_ADDRESS" nic=NIC_NAME cidr_netmask=32 \
op monitor interval=3600s timeout=60s
```
  NIC_NAME は、前の手順で取得したネットワークインターフェース名に置き換え、CLUSTER_ADDRESS は予約済みの IP アドレスに置き換えます。
3. プライマリホストで仮想 IP アドレスリソースが開始されていることを確認します。
```
sudo crm status
```
4. 仮想 IP アドレスリソースがプライマリノードで開始されていない場合は、次のコマンドを使用して移動します。
```
sudo pcs resource move aoag1-vip node-1
```
5. ヘルスチェックと仮想 IP アドレスのリソースをグループ化します。
```
sudo pcs resource group add aoag1-group \
aoag1-healthcheck aoag1-vip
```
6. プライマリと同じノードに新しいグループを配置する制約を作成します。
```
sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY
```

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

可用性グループを使用する SQL Server への接続では、サーバー名ではなく可用性グループリスナー名を使用する必要があります。フェイルオーバーが発生すると、リスナーは接続をクラスタ内の新しいプライマリノードに自動的にリダイレクトします。

SSMS に戻り、node-1 データベースに接続します。

次のクエリを実行します。

ALTER AVAILABILITY GROUP aoag1
ADD LISTENER 'aoag1-listener' (
    WITH IP (('CLUSTER_ADDRESS','255.255.255.0')), PORT=1433
);
GO

CLUSTER_ADDRESS は、予約済みの IP アドレスに置き換えます。

STONITH フェンスを設定する

STONITH は、HA クラスタ内のノードの整合性を維持するためのフェンシング戦略です。STONITH サービスはノードレベルで動作し、応答しないノードや不明な状態のノードからクラスタを保護します。Google Cloud の Compute Engine 専用の fence_gce フェンシングデバイスをおすすめします。

フェンシングデバイスを設定する

fence_gce - Compute Engine のフェンスエージェントが node1 にインストールされているかどうかを確認します。
```
sudo pcs stonith list | grep fence_gce
```
詳しくは以下をご覧ください。
- Google Compute Engine のフェンスエージェント。
- エージェントの実行に関連付けられたパラメータを確認する。
```
sudo pcs stonith describe fence_gce
```

node-1 で、参加ノードごとに fence_gce フェンシングタイプのリソースを作成します。

sudo pcs stonith create node-1-fence fence_gce \
plug=node-1 \
zone=REGION-a \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-2-fence fence_gce \
plug=node-2 \
zone=REGION-b \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-3-fence fence_gce \
plug=node-3 \
zone=REGION-c \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

REGION は、Linux VM がデプロイされているリージョンに置き換え、PROJECT_ID はプロジェクト ID に置き換えます。

フェンシングエージェントのステータスは、status コマンドを実行して確認できます。

sudo fence_gce -o status -n node-1 --zone=REGION-a
sudo fence_gce -o status -n node-2 --zone=REGION-b
sudo fence_gce -o status -n node-3 --zone=REGION-c

フェンシングデバイスのロケーション制約を作成して、目的のインスタンスでのみ実行されるようにします。

sudo pcs constraint location node-1-fence avoids node-1
sudo pcs constraint location node-2-fence avoids node-2
sudo pcs constraint location node-3-fence avoids node-3

Pacemaker クラスタでフェンシングを有効にし、クラスタフェンシングタイムアウトを設定します。
```
sudo pcs -f stonith_cfg property set stonith-enabled=true
sudo pcs property set stonith-timeout="300s"
```
クラスタのステータスを確認します。
```
sudo crm status
```

フェンシングデバイスをテストする

フェンシングデバイスの設定後、次の手順でテストすることをおすすめします。

node-2 でフェンスを停止します。
1. node-1 に接続し、次のコマンドを実行して、クラスタから node-2 に関連付けられたフェンスデバイスをテストします。
```
fence_gce -o off -n node-2 --zone=REGION-b
```
2. クラスタのステータスを確認します。
```
sudo crm status
```
3. また、Compute Engine で node-2 が無効になっていることも確認できます。
  
  Compute Engine に移動
node-2 でフェンスを再起動します。
1. node-1 に戻り、次のコマンドを実行してインスタンスを再起動します。
```
fence_gce -o on -n node-2 --zone=REGION-b
```
2. Pacemaker と Compute Engine でクラスタのステータスを確認します。しばらくすると、node-2 がオンラインに戻ります。
```
sudo crm status
```

遅延再起動用に Corosync を構成する

タイミングの問題を回避し、フェンシングアクションの際に適切な順序で処理が行われるようにするには、Corosync サービスの再起動を 60 秒遅らせることをおすすめします。

詳細については、Red Hat ナレッジベースの記事をご覧ください。

node-1、node-2、node-3 で Corosync サービスの起動の遅延を設定する systemd ドロップインファイルを作成します。
1. corosync.service を編集用に開きます。
```
sudo systemctl edit corosync.service
```
2. 次の行を追加して、ファイルを保存し、エディタを終了します。
```
[Service]
ExecStartPre=/bin/sleep 60
```
3. サービスマネージャーを再読み込みし、構成が考慮されているかどうかを確認します。
```
sudo systemctl daemon-reload
systemctl status corosync.service --no-pager
```
  [Drop-In] セクションが表示されている場合は、ドロップインファイルの設定が正常に反映されています。

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

これで、フェイルオーバーが想定どおりに機能するかどうかをテストする準備が整いました。

リモートデスクトップを使用して node-4 の Windows VM に接続します。
PowerShell セッションを開きます。

次のスクリプトを実行します。

while ($True){
  $Conn = New-Object System.Data.SqlClient.SqlConnection
  $Conn.ConnectionString = "Server=CLUSTER_ADDRESS;User ID=sa;Password=SA_PASSWORD;Initial Catalog=master"
  $Conn.Open()

  $Cmd = New-Object System.Data.SqlClient.SqlCommand
  $Cmd.Connection = $Conn
  $Cmd.CommandText = "SELECT @@SERVERNAME"

  $Adapter = New-Object System.Data.SqlClient.SqlDataAdapter $Cmd
  $Data = New-Object System.Data.DataSet
  $Adapter.Fill($Data) | Out-Null
  $Data.Tables[0] + (Get-Date -Format "MM/dd/yyyy HH:mm:ss")

  Start-Sleep -Seconds 2
}

CLUSTER_ADDRESS はリスナーの IP アドレスに置き換え、SA_PASSWORD は SQL Server の SA アカウントのパスワードに置き換えます。

このスクリプトは、2 秒ごとに可用性グループリスナーまたは DNN リスナーを使用して SQL Server に接続し、サーバー名を照会します。

スクリプトを実行したままにします。

node-1 で SSH に戻り、次のコマンドを実行して node-2 へのフェイルオーバーをトリガーします。

sudo pcs resource move ms-ag1 node-2 --master
sudo pcs resource move aoag1-group  node-2
sudo pcs resource move aoag1-vip node-2

node-4 の PowerShell セッションに戻ります。
1. 実行中のスクリプトの出力を確認して、フェイルオーバーの結果として、サーバー名が node-1 から node-2 に変更されたことを確認します。

node-1 に戻り、node-1 へのフェイルバックを開始します。

sudo pcs resource move ms-ag1 node-1 --master
sudo pcs resource move aoag1-group  node-1
sudo pcs resource move aoag1-vip node-1

node-4 で PowerShell に戻り、Ctrl+C キーを押してスクリプトを停止します。

クリーンアップ

チュートリアルが終了したら、作成したリソースをクリーンアップして、割り当ての使用を停止し、課金されないようにできます。次のセクションで、リソースを削除または無効にする方法を説明します。

プロジェクトの削除

課金されないようにする最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除するには、次のようにします。

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.