Linux で高可用性を実現するために SQL Server の Always On 可用性グループを構成する

適用対象: はいSQL Server (サポートされているすべてのバージョン) - Linux

この記事では、Linux 上で、高可用性を実現するために SQL Server の Always On 可用性グループ (AG) を作成する方法について説明します。 AG には 2 種類の構成が存在します。 "高可用性" の構成では、クラスター マネージャーを使ってビジネス継続性を提供します。 この構成には、読み取りスケールのレプリカを含めることもできます。 このドキュメントでは、高可用性のための AG を作成する方法について説明します。

"読み取りスケール" のために、クラスター マネージャーなしで AG を作成することもできます。 読み取りスケールの AG は、パフォーマンス スケールアウトのための読み取り専用レプリカを提供します。高可用性は提供しません。 読み取りスケールの AG を作成するには、「Linux で読み取りスケールの SQL Server 可用性グループを構成する」をご覧ください。

高可用性とデータ保護が保証される構成のためには、2 つまたは 3 つの同期コミット レプリカが必要です。 3 つの同期レプリカを使う場合は、1 台のサーバーが使用できない場合でも AG が自動的に復旧されます。 詳細については、「可用性グループ構成の高可用性とデータ保護」をご覧ください。

すべてのサーバーは物理または仮想である必要があり、仮想サーバーは同じ仮想化プラットフォーム上にある必要があります。 この要件が生じるのは、フェンス エージェントがプラットフォーム固有であるためです。 ゲスト クラスターのポリシーに関するページをご覧ください。

ロードマップ

高可用性のために Linux サーバー上に AG を作成する手順は、Windows Server フェールオーバー クラスターでの手順とは異なります。 以下に、おおまかな手順を説明します。

  1. 3 台のクラスター サーバーで SQL Server を構成します

    重要

    AG 内の 3 台のサーバーはすべて同じプラットフォーム (物理または仮想) 上に配置する必要があります。これは、Linux の高可用性ではサーバー上のリソースを分離するためにフェンス エージェントが使われるためです。 フェンス エージェントは、各プラットフォームに固有のものです。

  2. AG を作成します。 この手順について、この現在の記事で説明します。

  3. Pacemaker などのクラスター リソース マネージャーを構成します。

    クラスター リソース マネージャーを構成する方法は、特定の Linux ディストリビューションによって異なります。 ディストリビューション固有の手順については、以下のリンクをご覧ください。

    重要

    運用環境では、高可用性のために STONITH のようなフェンス エージェントが必要です。 このドキュメントに含まれているデモでは、フェンス エージェントは使用しません。 このデモはテストと検証専用です。

    Linux クラスターでは、フェンスを使用して、クラスターが既知の状態に戻されます。 フェンスを構成する方法は、ディストリビューションと環境によって異なります。 現時点では、一部のクラウド環境ではフェンスを利用できません。 詳細については、RHEL 高可用性クラスターのサポート ポリシー (仮想化プラットフォーム) に関するページをご覧ください。

    SLES については、SUSE Linux Enterprise High Availability Extension に関するページをご覧ください。

  4. AG をリソースとしてクラスターに追加します。

    AG をリソースとしてクラスターに追加する方法は、Linux ディストリビューションによって異なります。 ディストリビューション固有の手順については、以下のリンクをご覧ください。

前提条件

可用性グループを作成する前に、以下のことを行う必要があります。

  • 可用性レプリカをホストするすべてのサーバーが通信できるように環境を設定します。
  • SQL Server をインストールします。

注意

Linux でクラスターで管理するには、クラスター リソースとして追加する前に可用性グループを作成する必要があります。 このドキュメントでは、可用性グループを作成する例を示します。 クラスターを作成し、可用性グループをクラスターのリソースとして追加するディストリビューション固有の説明については、「次のステップ」の後のリンクをご覧ください。

  1. 各ホストのコンピューター名を更新します。

    各 SQL Server 名には次の条件があります。

    • 15 文字以下。
    • ネットワーク内で一意。

    コンピューター名を設定するには、/etc/hostname を編集します。 次のスクリプトを使うと、vi/etc/hostname を編集できます。

    sudo vi /etc/hostname
    
  2. hosts ファイルを構成する。

    注意

    ホスト名が IP アドレスで DNS サーバーに登録されている場合、次の手順を実行する必要はありません。 可用性グループの一部として構成されているすべてのノードが、相互通信できることを確認します。 (そのホスト名を ping した場合、その対応する IP アドレスが返される必要があります)。また、/etc/hosts ファイルに、localhost IP アドレス 127.0.0.1 をノードのホスト名とマップするレコードが含まれないことを確認します。

    すべてのサーバー上の hosts ファイルには、可用性グループに参加するすべてのサーバーの IP アドレスと名前が含まれています。

    次のコマンドは、現在のサーバーの IP アドレスを返します。

    sudo ip addr show
    

    /etc/hosts を更新します。 次のスクリプトを使うと、vi/etc/hosts を編集できます。

    sudo vi /etc/hosts
    

    次の例は、node1/etc/hosts を示しています。node1node2node3 に対して追加があります。 このドキュメントで node1 は、プライマリ レプリカをホストするサーバーを指します。 また、node2node3 は、セカンダリ レプリカをホストするサーバーを指します。

    127.0.0.1   localhost localhost4 localhost4.localdomain4
    ::1       localhost localhost6 localhost6.localdomain6
    10.128.18.12 node1
    10.128.16.77 node2
    10.128.15.33 node3
    

SQL Server をインストールする

SQL Server をインストールします。 次のリンクは、SQL Server のさまざまなディストリビューションでのインストール手順です。

AlwaysOn 可用性グループを有効にして mssql-server を再起動する

SQL Server インスタンスをホストする各ノードで AlwaysOn 可用性グループを有効にします。 次に、mssql-server を再起動します。 次のスクリプトを実行します。

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

AlwaysOn_health イベント セッションを有効にする

オプションで、AlwaysOn 可用性グループの拡張イベントを有効にすると、可用性グループのトラブルシューティング時の根本原因の診断に役立ちます。 SQL Server の各インスタンスで次のコマンドを実行します。

ALTER EVENT SESSION  AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO

この XE セッションの詳細については、Always On の拡張イベントに関する記事をご覧ください。

証明書を作成する

Linux 上の SQL Server サービスは、ミラーリングのエンドポイント間の通信を認証するのに証明書を使用します。

次の Transact-SQL スクリプトでは、マスター キーと証明書を作成します。 その後、証明書をバックアップし、秘密キーでファイルをセキュリティ保護します。 強力なパスワードでスクリプトを更新してください。 プライマリ SQL Server インスタンスに接続します。 次の Transact-SQL スクリプトを実行して、証明書を作成します。

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
   TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
   WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**'
       );

この時点で、プライマリ SQL Server レプリカの /var/opt/mssql/data/dbm_certificate.cer には証明書が、var/opt/mssql/data/dbm_certificate.pvk には秘密キーが作成されています。 これら 2 つのファイルを、可用性レプリカをホストするすべてのサーバー上の同じ場所にコピーします。 mssql ユーザーを使うか、またはこれらのファイルへのアクセス許可を mssql ユーザーに付与します。

たとえば、ソース サーバーでは、次のコマンドでファイルがターゲット コンピューターにコピーされます。 **<node2>** の値を、レプリカをホストする SQL Server インスタンスの名前に置き換えます。

cd /var/opt/mssql/data
scp dbm_certificate.* root@**<node2>**:/var/opt/mssql/data/

各ターゲット サーバーで証明書にアクセスするアクセス許可を mssql ユーザーに付与します。

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

セカンダリ サーバーで証明書を作成する

次の Transact-SQL スクリプトでは、プライマリ SQL Server レプリカで作成したバックアップからマスター キーと証明書を作成します。 強力なパスワードでスクリプトを更新してください。 暗号化解除パスワードは、前の手順で .pvk ファイルの作成に使ったものと同じパスワードです。 すべてのセカンダリ サーバーで次のスクリプトを実行し、証明書を作成します。

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
    DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
            );

すべてのレプリカにデータベース ミラーリング エンドポイントを作成する

データベース ミラーリング エンドポイントでは、伝送制御プロトコル (TCP) を使用して、データベース ミラーリング セッションに参加するサーバー インスタンス間、または可用性レプリカをホストするサーバー インスタンス間でメッセージを送受信します。 データベース ミラーリング エンドポイントでは、一意な TCP ポート番号でリッスンします。

次の Transact-SQL スクリプトでは、可用性グループに対して Hadr_endpoint という名前のリスニング エンドポイントを作成します。 エンドポイントが起動され、作成した証明書に接続許可が付与されます。 スクリプトを実行する前に、**< ... >** の間の値を置き換えます。 必要に応じて、IP アドレス LISTENER_IP = (0.0.0.0) を含めることができます。 リスナー IP アドレスは、IPv4 アドレスである必要があります。 0.0.0.0 を使用することもできます。

すべての SQL Server インスタンスで、ご利用の環境に合わせて次の Transact-SQL スクリプトを更新します。

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

注意

構成専用のレプリカのホストに 1 つのノードで SQL Server Express Edition を使用する場合、ROLE に有効な値は WITNESS のみです。 SQL Server Express Edition で次のスクリプトを実行します。

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

ファイアウォールの TCP ポートをリスナー ポート用に開く必要があります。

重要

SQL Server 2017 リリースのデータベース ミラーリング エンドポイントでサポートされる唯一の認証方法は CERTIFICATE です。 WINDOWS オプションは今後のリリースで有効になる予定です。

詳細については、「データベース ミラーリング エンドポイント (SQL Server)」を参照してください。

AG を作成する

このセクションの例では、Transact-SQL を使って可用性グループを作成する方法について説明します。 SQL Server Management Studio の可用性グループ ウィザードを使うこともできます。 ウィザードを使って AG を作成した場合、AG にレプリカを参加させるとエラーが返されます。 これを修正するには、すべてのレプリカの AG のペースメーカーに ALTERCONTROL、および VIEW DEFINITIONS を付与します。 プライマリ レプリカにアクセス許可を付与したら、ウィザードを使って AG にノードを参加させます。ただし、HA を正常に機能させるために、すべてのレプリカに対して権限を付与します。

自動フェールオーバーを確実に行う高可用性を構成する場合、AG には少なくとも 3 つのレプリカが必要です。 次のいずれかの構成で高可用性をサポートできます。

詳しくは、「可用性グループ構成の高可用性とデータ保護」をご覧ください。

注意

可用性グループには、追加の同期または非同期レプリカを含めることができます。

Linux で高可用性のための AG を作成します。 CLUSTER_TYPE = EXTERNAL を指定した CREATE AVAILABILITY GROUP を使います。

  • 可用性グループ - CLUSTER_TYPE = EXTERNAL: 外部クラスター エンティティにより AG が管理されることを指定します。 Pacemaker は外部クラスター エンティティの例です。 AG のクラスターの種類が外部である場合は、

  • プライマリおよびセカンダリ レプリカを FAILOVER_MODE = EXTERNAL に設定します。 レプリカが外部クラスター マネージャー (Pacemaker など) と連携することを指定します。

以下の Transact-SQL スクリプトでは、ag1 という名前の高可用性の AG が作成されます。 このスクリプトでは、SEEDING_MODE = AUTOMATIC で AG レプリカが構成されます。 この設定により、各セカンダリ サーバー上に SQL Server によってデータベースが自動作成されます。 ご利用の環境に合わせて次のスクリプトを変更してください。 <node1><node2>、または <node3> の値を、レプリカをホストする SQL Server インスタンスの名前に置き換えます。 <5022> を、データ ミラーリング エンドポイント用に設定したポートに置き換えます。 AG を作成するには、プライマリ レプリカをホストしている SQL Server インスタンス上で次の Transact-SQL を実行します。

次のスクリプトの いずれか 1 つのみ を実行します。

  • 3 つの同期レプリカを使って AG を作成する

    CREATE AVAILABILITY GROUP [ag1]
         WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
         FOR REPLICA ON
             N'<node1>' 
              WITH (
                 ENDPOINT_URL = N'tcp://<node1>:<5022>',
                 AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
                 FAILOVER_MODE = EXTERNAL,
                 SEEDING_MODE = AUTOMATIC
                 ),
             N'<node2>' 
              WITH ( 
                 ENDPOINT_URL = N'tcp://<node2>:<5022>', 
                 AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
                 FAILOVER_MODE = EXTERNAL,
                 SEEDING_MODE = AUTOMATIC
                 ),
             N'<node3>'
             WITH( 
                ENDPOINT_URL = N'tcp://<node3>:<5022>', 
                AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
                FAILOVER_MODE = EXTERNAL,
                SEEDING_MODE = AUTOMATIC
                );
    
    ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
    

    重要

    上記のスクリプトを実行して 3 つの同期レプリカを持つ AG を作成した後は、以下のスクリプトは実行しないでください。

  • 2 つの同期レプリカと 1 つの構成レプリカを使って AG を作成する:

    重要

    このアーキテクチャでは、任意のエディションの SQL Server を使って 3 番目のレプリカをホストすることができます。 たとえば、SQL Server Express Edition 上で 3 番目のレプリカをホストできます。 Express Edition の場合、有効なエンドポイントの種類は WITNESS のみです。

    CREATE AVAILABILITY GROUP [ag1] 
        WITH (CLUSTER_TYPE = EXTERNAL) 
        FOR REPLICA ON 
         N'<node1>' WITH ( 
            ENDPOINT_URL = N'tcp://<node1>:<5022>', 
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
            FAILOVER_MODE = EXTERNAL, 
            SEEDING_MODE = AUTOMATIC 
            ), 
         N'<node2>' WITH (  
            ENDPOINT_URL = N'tcp://<node2>:<5022>',  
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
            FAILOVER_MODE = EXTERNAL, 
            SEEDING_MODE = AUTOMATIC 
            ), 
         N'<node3>' WITH ( 
            ENDPOINT_URL = N'tcp://<node3>:<5022>', 
            AVAILABILITY_MODE = CONFIGURATION_ONLY  
            );
    ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
    

  • 2 つの同期レプリカを使って AG を作成する

    同期可用性モードの 2 つのレプリカを含めます。 たとえば、次のスクリプトでは、ag1 という名前の AG が作成されます。 node1 および node2 では、自動シード処理と自動フェールオーバーを備えた、同期モードのレプリカがホストされます。

    重要

    2 つの同期レプリカを含む AG を作成する場合は、次のスクリプトだけを実行してください。 上記のスクリプトのいずれかを実行している場合は、以下のスクリプトを実行しないでください。

    CREATE AVAILABILITY GROUP [ag1]
        WITH (CLUSTER_TYPE = EXTERNAL)
        FOR REPLICA ON
        N'node1' WITH (
           ENDPOINT_URL = N'tcp://node1:5022',
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           FAILOVER_MODE = EXTERNAL,
           SEEDING_MODE = AUTOMATIC
        ),
        N'node2' WITH ( 
           ENDPOINT_URL = N'tcp://node2:5022', 
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           FAILOVER_MODE = EXTERNAL,
           SEEDING_MODE = AUTOMATIC
        );
    
    ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
    

SQL Server Management Studio または PowerShell を使って、CLUSTER_TYPE=EXTERNAL で AG を構成することもできます。

セカンダリ レプリカを AG に参加させる

ペースメーカーのユーザーは、すべてのレプリカ上の可用性グループに対して ALTERCONTROLVIEW DEFINITION のアクセス許可を持っている必要があります。 アクセス許可を付与するには、プライマ リレプリカと各セカンダリ レプリカ上に可用性グループが作成された後、それらが可用性グループに追加された直後に、次の Transact-SQL スクリプトを実行します。 このスクリプトを実行する前に、<pacemakerLogin> をペースメーカーのユーザー アカウントに置き換えます。 ペースメーカーのログインがない場合、ペースメーカーの SQL サーバー ログインを作成してください

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>

次の Transact-SQL スクリプトを実行すると、ag1 という名前の AG に SQL Server インスタンスを参加させることができます。 ご利用の環境に合わせてスクリプトを変更してください。 セカンダリ レプリカをホストしている各 SQL Server インスタンス上で、次の Transact-SQL を実行して AG に参加させます。

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
         
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

可用性グループにデータベースを追加する

可用性グループに追加するデータベースが、完全回復モードであり、有効なログ バックアップがあることを確認します。 テスト データベースまたは新しく作成されたデータベースの場合は、データベース バックアップを実行します。 プライマリ SQL Server で、次の Transact-SQL スクリプトを実行し、db1 という名前のデータベースを作成してバックアップします。

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

プライマリ SQL Server レプリカで、次の Transact-SQL スクリプトを実行して、db1 という名前のデータベースを ag1 という名前の可用性グループに追加します。

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];

セカンダリ サーバーにデータベースが作成されたことを確認する

各セカンダリ SQL Server レプリカで次のクエリを実行して、db1 データベースが作成されて同期されているかどうかを確認します。

SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;

重要

AG を作成したら、高可用性のために Pacemaker のようなクラスター テクノロジとの統合を構成する必要があります。 AG を使った読み取りスケール構成の場合 (SQL Server 2017 (14.x) 以降)、クラスターの設定は必要ありません。

このドキュメントに記載されている手順に従った場合は、まだクラスター化されていない AG ができます。 次の手順は、クラスターを追加することです。 この構成は、読み取りスケール/負荷分散のシナリオに対しては有効ですが、高可用性の場合は完全ではありません。 高可用性を実現するには、AG をクラスター リソースとして追加する必要があります。 手順については、「次の手順」をご覧ください。

メモ

重要

クラスターを構成し、AG をクラスター リソースとして追加した後は、Transact-SQL を使って AG リソースをフェールオーバーすることはできません。 Linux 上の SQL Server クラスター リソースは、Windows Server フェールオーバー クラスター (WSFC) ほど、オペレーティング システムと緊密に結合されていません。 SQL Server サービスでは、クラスターの存在は認識されません。 すべてのオーケストレーションは、クラスター管理ツールを使用して実行されます。 RHEL または Ubuntu では、pcs を使います。 SLES では crm を使います。

重要

AG がクラスター リソースの場合、現在のリリースには、非同期レプリカへのデータ損失を伴う強制フェールオーバーが機能しないという既知の問題があります。 これは今後のリリースで修正される予定です。 同期レプリカへの手動または自動フェールオーバーは成功します。

次のステップ

SQL Server 可用性グループ クラスター リソースに対して Red Hat Enterprise Linux クラスターを構成する

SQL Server 可用性グループ クラスター リソースに対して SUSE Linux Enterprise Server クラスターを構成する

SQL Server 可用性グループ クラスター リソースに対して Ubuntu クラスターを構成する