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

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

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

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

目標

費用

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

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

始める前に

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

  1. In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Cloud de Confiance project.

  3. In the Cloud de Confiance console, activate Cloud Shell.

    Activate Cloud Shell

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

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

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

      Cloud de Confiance コンソールに移動

    2. デフォルトのプロジェクト ID を設定します。

      gcloud config set project PROJECT_ID

      PROJECT_ID は、 Cloud de Confiance プロジェクトの ID に置き換えます。

    3. デフォルトのリージョンを設定します。

      gcloud config set compute/region REGION

      REGION は、デプロイするリージョンの ID に置き換えます。

    4. デフォルト ゾーンを設定します。

      gcloud config set compute/zone ZONE

      ZONE は、デプロイするゾーンの ID に置き換えます。前の手順で指定したリージョン内の有効なゾーンである必要があります。

    Linux VM を作成する

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

    1. 次の変数を初期化します。

      PD_SIZE=30
MACHINE_TYPE=n2-standard-8

    2. 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/REGION-a/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/REGION-b/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/REGION-c/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 サブネットの名前に置き換えます。

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

      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 アドレスに置き換えます。

    4. 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 エンジンをダウンロード、インストール、構成します。

    1. 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

    2. SQL Server を構成します。

      1. mssql-conf ツールを実行します。

        sudo /opt/mssql/bin/mssql-conf setup

      2. SQL Server のエディションとして [Developer] エディションを選択し、ライセンス契約に同意します。

        Developer エディションにはすべてのエンタープライズ機能が含まれていますが、本番環境以外でのみ使用できます。詳しくは、SQL Server のエディションと Microsoft ライセンスをご覧ください。

      3. SA アカウントのパスワードを指定します。

      4. mssql-server サービスが実行されていることを確認します。

        systemctl status mssql-server --no-pager

    3. 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 がインストールされました。接続するには、同じ VPC に Windows マシンを作成し、SQL Server Management Studio（SSMS）をインストールして、VM で新しく作成した SQL Server インスタンスに接続します。

    1. Windows VM を作成します。

      1. 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

    2. リモート デスクトップを使用して node-4 の Windows VM に接続します。

    3. 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. 保存して終了します。

    4. Linux VM への接続を確認します。

      1. node-4 の Windows VM に接続します
      2. [スタート] ボタンをクリックし、検索バーに「powershell」と入力します。
      3. クリックして Windows PowerShell ISE アプリを開きます。

      4. 次のコマンドを実行して接続をテストします。

        ping node-1
ping node-2
ping node-3

    5. 次の手順で 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 セッションが終了します。

    6. 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 で管理されるリソースとして追加する前に、まず可用性グループを作成する必要があります。

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

      sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server

    2. SSMS を使用して、可用グループのプライマリ ホストであるインスタンスに接続します。

      1. 新しいクエリ ウィンドウを開きます。

      2. 次のコード スニペットを実行して、暗号鍵、証明書、秘密鍵を作成します。

        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 を作成し、プライマリ クラスタノードからセカンダリ クラスタノードにファイルを転送します。

    1. Cloud Storage バケットを作成します。

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

        gcloud storage buckets create gs://BUCKET_NAME \
--project=PROJECT_ID \
--location=REGION \
--public-access-prevention

        BUCKET_NAME は、作成するバケットの名前に置き換えます。PROJECT_ID は　 Cloud de Confiance by S3NS 　プロジェクト ID に置き換え、REGION はバケットをデプロイするリージョンの ID に置き換えます。

      詳細については、バケットを作成するをご覧ください。

    2. node-1、node-2、node-3 で SSH に戻り、Google Cloud CLI を初期化します。

      1. 次のコマンドを実行して、Google Cloud CLI を初期化します。

        gcloud init

      2. プリインストールされているサービス アカウントを使用するには、[option [1]] を選択します。

      3. プロジェクトの名前を入力します。

      4. デフォルトのリージョンとゾーンを設定するには、質問に対して n と入力します。

    3. node-1 に戻り、ファイルを Cloud Storage にコピーします。

      1. 次のコマンドを使用して、新しく作成した 2 つのファイルを Cloud Storage にアップロードします。

        sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.cer gs://BUCKET_NAME/
sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME/

        BUCKET_NAME は、作成したバケットの名前に置き換えます。

    4. node-2 と node-3 に戻り、Cloud Storage からファイルをコピーします。

      1. Cloud Storage から node-2 に 2 つのファイルをダウンロードします。

        sudo gcloud storage cp gs://BUCKET_NAME/my_ag_certificate.cer /var/opt/mssql/data/
sudo gcloud storage 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.*

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

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

    1. 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 コマンドを実行して、データベース ミラーリングのエンドポイントを作成します。

        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 可用性グループを作成し、レプリケーション用に以前に作成したエンドポイントを使用します。

    1. Windows VM に戻り、SSMS を開きます。

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

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

      USE MASTER;

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

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

      1. 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

      2. 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

      3. 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 アカウントを作成します。

    1. node-1、node-2、node-3 で次の T-SQL コマンドを実行します。

      USE [master];

CREATE LOGIN [pacemaker] with PASSWORD= N'PACEMAKER_LOGIN_PASSWORD';
GO

      PACEMAKER_LOGIN_PASSWORD は、Pacemaker アカウントのパスワードに置き換えます。

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

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

    3. 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 にログイン アカウントを設定します。

    1. 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

    2. 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

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

      sudo passwd hacluster

    Corosync を設定する

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

    1. node-1 に Corosync の認証キーを作成します。

      sudo corosync-keygen

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

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

        sudo vi /etc/corosync/corosync.conf

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

        # 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 を使用して構成ファイルを転送する

    1. 生成された認証キーと corosync 構成ファイルを node-1 から Cloud Storage バケットにアップロードします。

      sudo gcloud storage cp /etc/corosync/authkey gs://BUCKET_NAME/
sudo gcloud storage cp  /etc/corosync/corosync.conf gs://BUCKET_NAME/

      BUCKET_NAME は、以前に作成したバケットの名前に置き換えます。

    2. Authkey と構成ファイルを node-2 と node-3 にダウンロードします。

      sudo gcloud storage cp gs://BUCKET_NAME/authkey /etc/corosync/
sudo gcloud storage cp gs://BUCKET_NAME/corosync.conf /etc/corosync/

      BUCKET_NAME は、Corosync 構成ファイルが転送されたバケットの名前に置き換えます。

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

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

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

    1. node-1、node-2、node-3 で Pacemaker サービスと Corosync サービスを再起動します。

      sudo systemctl restart pacemaker corosync

    2. node-1 で次のコマンドを実行して、クラスタのステータスを確認します。

      sudo crm status

      3 つのノードがすべてオンラインになっていることを確認します。

    クラスタを設定する

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

    1. 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

      詳細については、クラスタ オプションをご覧ください。

    2. node-1 でコマンドを実行して、クラスタ内のノードを承認します。以前に hacluster アカウントに設定したパスワードを使用します。

      sudo pcs cluster auth -u hacluster

      3 つのノードがすべて承認されていることを確認します。

    3. node-1、node-2、node-3 に Pacemaker と統合するための SQL Server リソース エージェントをインストールします。

      sudo apt-get install mssql-server-ha

    4. 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 アドレスとヘルスチェック リソースを作成します。

    1. 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 がデプロイされているリージョンとサブネットに置き換えます。

    2. クラスタノードごとに非マネージド インスタンス グループを作成し、新しく作成したインスタンス グループに割り当てます。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 がデプロイされているリージョンに置き換えます。

    3. 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。

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

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

      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 は、ネットワーク タグの名前に置き換えます。

    5. タグ名に基づいてヘルスチェックがクラスタノードに到達できるように、ファイアウォール ルールを作成します。

      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

      詳細については、ヘルスチェックのファイアウォール ルールをご覧ください。

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

      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

    7. 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

    8. ロードバランサの転送ルールを定義します。転送ルールでは、ロードバランサがトラフィックを受け入れるポートとプロトコルを指定します。

      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 アドレスに置き換えます。

      詳細については、転送ルールをご覧ください。

    9. 設定を完了し、ネットワーク ロードバランサが正しく設定されているかどうかをテストするには、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 つの非マネージド インスタンス グループがすべて正常に動作しているという報告が表示されたら、次のステップに進みます。

        sudo systemctl restart haproxy.service

    10. 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 のみで正常になります。

        [ロード バランシング] に移動

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

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

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

      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 サービスはノードレベルで動作し、応答しないノードや不明な状態のノードからクラスタを保護します。 Cloud de Confiance by S3NSの Compute Engine 専用の fence_gce フェンシング デバイスをおすすめします。

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

    1. fence_gce - Compute Engine のフェンス エージェントが node1 にインストールされているかどうかを確認します。

      sudo pcs stonith list | grep fence_gce

      詳しくは以下をご覧ください。

    2. 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 に置き換えます。

    3. フェンシング エージェントのステータスは、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

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

      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

    5. Pacemaker クラスタでフェンシングを有効にし、クラスタ フェンシング タイムアウトを設定します。

      sudo pcs -f stonith_cfg property set stonith-enabled=true
sudo pcs property set stonith-timeout="300s"

    6. クラスタのステータスを確認します。

      sudo crm status

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

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

    1. 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 に移動

    2. 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 ナレッジベースの記事をご覧ください。

    1. 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] セクションが表示されている場合は、ドロップイン ファイルの設定が正常に反映されています。

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

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

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

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

      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 に接続し、サーバー名を照会します。

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

    4. 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

    5. node-4 の PowerShell セッションに戻ります。

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

    6. 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

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

    クリーンアップ

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

    プロジェクトの削除

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

    プロジェクトを削除するには:

    1. In the Cloud de Confiance console, go to the Manage resources page.

      Go to Manage resources

    2. In the project list, select the project that you want to delete, and then click Delete.
    3. In the dialog, type the project ID, and then click Shut down to delete the project.