SQL Server 可用性グループ用の Pacemaker クラスターを構成する

  • [アーティクル]

適用対象: SQL Server - Linux

この記事では、Linux 上で Pacemaker を使用する 3 ノードのクラスターを作成し、以前に作成した可用性グループをクラスター内のリソースとして追加する方法について説明します。 高可用性を実現するため、Linux 上の可用性グループには 3 つのノードが必要です。可用性グループ構成の高可用性とデータ保護に関するページを参照してください。

Note

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

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

SQL Server は、Windows Server フェールオーバー クラスタリング (WSFC) ほど密接に Linux 上の Pacemaker と統合されていません。 SQL Server インスタンスでクラスターは認識されず、すべてのオーケストレーションは外部から取得されます。 Pacemaker は、クラスター リソース オーケストレーションを提供します。 また、仮想ネットワーク名は Windows Server フェールオーバー クラスタリングに固有のものであり、Pacemaker には対応するものがありません。 クラスター情報のクエリを実行する可用性グループの動的管理ビュー (DMV) では、Pacemaker クラスター上の空の行が返されます。 フェールオーバー後に透過的な再接続用のリスナーを作成するには、仮想 IP リソースの作成に使用される IP を使用して、リスナー名を DNS に手動で登録します。

フェールオーバー後の透過的な再接続のためにリスナーを引き続き作成できますが、仮想 IP リソースの作成に使用する IP で、DNS サーバーにリスナー名を手動で登録する必要があります (以下のセクションで説明します)。

以下のセクションでは、Pacemaker クラスターを設定し、高可用性のためにクラスターのリソースとして可用性グループを追加する手順について、サポートされている Linux ディストリビューションごとに説明します。

クラスタリング レイヤーは、Pacemaker の上に構築された Red Hat Enterprise Linux (RHEL) HA アドオンに基づいています。

注意

Red Hat の完全なドキュメントにアクセスするには、有効なサブスクリプションが必要です。

クラスター構成、リソース エージェント オプション、および管理の詳細については、RHEL リファレンス ドキュメントを参照してください。

ロードマップ

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

  1. クラスター ノードで SQL Server を構成します。

  2. 可用性グループを作成します。

  3. Pacemaker などのクラスター リソース マネージャーを構成します。 これらの手順については、この記事で説明します。

    クラスター リソース マネージャーを構成する方法は、特定の Linux ディストリビューションによって異なります。

    重要

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

  4. 可用性グループをクラスターのリソースとして追加します。

RHEL の高可用性を構成する

RHEL の高可用性を構成するには、高可用性サブスクリプションを有効にしてから、Pacemaker を構成します。

RHEL の高可用性サブスクリプションを有効にする

クラスター内の各ノードには、RHEL の適切なサブスクリプションと高可用性アドオンが必要です。 Red Hat Enterprise Linux に高可用性クラスター パッケージをインストールする方法に関するページで要件を確認してください。 サブスクリプションとリポジトリを構成するには、次の手順を実行します。

  1. システムを登録します。

    sudo subscription-manager register

    ユーザー名とパスワードを入力します。

  2. 登録に使用できるプールを一覧表示します。

    sudo subscription-manager list --available

    使用可能なプールの一覧から、高可用性サブスクリプションのプール ID を書き留めます。

  3. 次のスクリプトを更新します。 <pool id> を、前の手順の高可用性のプール ID に置き換えます。 スクリプトを実行してサブスクリプションをアタッチします。

    sudo subscription-manager attach --pool=<pool id>

  4. リポジトリを有効にします。

    RHEL 7

    sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms

    RHEL 8

    sudo subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms

詳細については、「Pacemaker - The Open Source, High Availability Cluster」を参照してください。

サブスクリプションを構成したら、次の手順を実行して Pacemaker を構成します。

Pacemaker を構成する

サブスクリプションを登録したら、次の手順を実行して Pacemaker を構成します。

  1. すべてのクラスター ノードで、Pacemaker のファイアウォール ポートを開きます。 firewalld を使用してこれらのポートを開くには、次のコマンドを実行します。

    sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload

    ファイアウォールに高可用性構成が組み込まれていない場合、Pacemaker 用に次のポートを開きます。

    • TCP: ポート 2224、3121、21064
    • UDP: ポート 5405

  2. すべてのノードに Pacemaker パッケージをインストールします。

    sudo yum install pacemaker pcs fence-agents-all resource-agents

  3. Pacemaker と Corosync のパッケージをインストールしたときに作成された既定のユーザー用のパスワードを設定します。 すべてのノードで同じパスワードを使います。

    sudo passwd hacluster

  4. 再起動後にノードがクラスターに再度参加できるように、pcsd サービスを有効にして開始します。 すべてのノードで次のコマンドを実行します。

    sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker

  5. クラスターを作成します。 クラスターを作成するには、次のコマンドを実行します。

    RHEL 7

    sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all

    RHEL 8

    RHEL 8 では、ノードを個別に認証する必要があります。 プロンプトが表示されたら、hacluster のユーザー名とパスワードを手動で入力します。

    sudo pcs host auth <node1> <node2> <node3>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all

    注意

    前に同じノードでクラスターを構成した場合は、pcs cluster setup を実行するときに --force オプションを使用する必要があります。 このオプションは、pcs cluster destroy を実行するのと同等です。 Pacemaker を再度有効にするために、sudo systemctl enable pacemaker を実行します。

  6. SQL Server の SQL Server リソース エージェントをインストールします。 すべてのノードで次のコマンドを実行します。

    sudo yum install mssql-server-ha

Pacemaker を構成した後、pcs を使用してクラスターを操作します。 クラスターから 1 つのノードですべてのコマンドを実行します。

複数のネットワーク インターフェイス (NIC) に関する考慮事項

複数の NIC を使用しているサーバーで高可用性を設定する場合は、次の推奨事項に従います。

  • hosts ファイルが、複数の NIC のサーバー IP アドレスを各ノード上の Linux サーバーのホスト名に解決するように設定されていることを確認します。

  • Pacemaker を使用するクラスターを設定する場合、サーバーのホスト名を使用することで、すべての NIC の構成を設定するように Corosync を構成する必要があります。 Pacemaker または Corosync の通信は、1 つの NIC 経由でのみ必要です。 Pacemaker クラスターが構成されたら、corosync.conf ファイル内の構成を変更し、Pacemaker または Corosync の通信専用に使用する NIC の IP アドレスを更新します。

  • corosync.conf ファイル内に指定された <hostname> は、逆引き参照 (ping -a <ip_address>) の実行時に提供された出力と同じにする必要があり、ホストで構成された短い名前にする必要があります。 hosts ファイルが、名前解決に対して適切な IP アドレスを表していることも確認します。

corosync.conf ファイル対する変更の例を次に示します。

  nodelist {
    node {
        ring0_addr: <ip_address_of_node1_NIC1>
        name: <hostname_of_node1>
        nodeid: 1
    }
    node {
        ring0_addr: <ip_address_of_node2_NIC1>
        name: <hostname_of_node2>
        nodeid: 2
    }
    node {
        ring0_addr: <ip_address_of_node3_NIC1>
        name: <hostname_of_node3>
        nodeid: 3
    }
  }

フェンス デバイスを構成する

Pacemaker クラスター ベンダーは、サポートされているクラスター セットアップ用に構成されたフェンシング デバイスを使用して、障害が発生したノードをフェンシングする必要があります。 クラスター リソース マネージャーがノードまたはノード上のリソースの状態を判断できない場合は、、フェンシングによりクラスターが再び既知の状態になります。

フェンシング デバイスはフェンシング エージェントを提供します。 「Azure の Red Hat Enterprise Linux に Pacemaker をセットアップする」では、Azure でこのクラスター用のフェンシング デバイスを作成する方法の例が示されています。 環境の手順を変更します。

リソース レベルのフェンシングは、リソースを構成することにより、停止時にデータの破損がないことを保証します。 たとえば、リソース レベルのフェンスを使用して、通信リンクがダウンしたときにノード上のディスクを期限切れとしてマークすることができます。

ノード レベルのフェンスでは、ノードによってリソースが実行されないことが保証されます。 これを行うには、ノードをリセットします。 Pacemaker は、さまざまなフェンス デバイスをサポートしています。 例として、無停電電源装置やサーバーの管理インターフェイスカードなどがあります。

障害が発生したノードのフェンシングについては、次の記事を参照してください。

注意

ノード レベルのフェンス構成は環境に大きく依存しているため、このチュートリアルでは無効にします (後で構成できます)。 次のスクリプトは、ノード レベルのフェンスを無効にします。

sudo pcs property set stonith-enabled=false

フェンシングを無効にするのは、テスト目的の場合のみです。 運用環境で Pacemaker を使用する予定がある場合は、環境に応じて フェンシングの実装を計画し、有効にしておく必要があります。

クラスター プロパティ cluster-recheck-interval を設定する

cluster-recheck-interval は、クラスターがリソース パラメーター、制約、またはその他のクラスター オプションの変更をチェックするポーリング間隔を示します。 レプリカがダウンした場合、クラスターでは、failure-timeout 値と cluster-recheck-interval 値によってバインドされた間隔でレプリカの再起動が試みられます。 たとえば、failure-timeout が 60 秒に設定されていて、cluster-recheck-interval が 120 秒に設定されている場合、再起動は 60 秒より大きく 120 秒未満の間隔で試行されます。 failure-timeout は 60 秒、cluster-recheck-interval は 60 秒より大きい値に設定することをお勧めします。 cluster-recheck-interval を小さい値に設定することはお勧めしません。

プロパティ値を 2 minutes に更新するには、次を実行します。

sudo pcs property set cluster-recheck-interval=2min

既に Pacemaker クラスターによって管理されている可用性グループ リソースがある場合、Pacemaker パッケージ 1.1.18-11.el7 では、値が false の場合の start-failure-is-fatal クラスター設定の動作変更が導入されました。 この変更は、フェールオーバー ワークフローに影響します。 プライマリ レプリカで障害が発生した場合、クラスターは使用可能なセカンダリ レプリカのいずれかにフェールオーバーする必要があります。 代わりに、クラスターが失敗したプライマリ レプリカを起動しようとしていることがユーザーに通知されます。 そのプライマリが永久に停止したためにオンラインにならない場合は、クラスターが別の使用可能なセカンダリ レプリカにフェールオーバーすることはありません。 この変更により、以前に start-failure-is-fatal を設定するために推奨されていた構成が有効ではなくなったため、この設定を既定値の true に戻す必要があります。

さらに、failure-timeout プロパティを含めるには、AG リソースを更新する必要があります。

プロパティ値を true に更新するには、次を実行します。

sudo pcs property set start-failure-is-fatal=true

ag_cluster リソース プロパティ failure-timeout を 60s に更新するには、次のように実行します。

pcs resource update ag_cluster meta failure-timeout=60s

Pacemaker クラスターのプロパティの詳細については、「Pacemaker クラスターのプロパティ」を参照してください。

Pacemaker 用の SQL Server ログインを作成する

  1. すべての SQL Server インスタンスで、Pacemaker 用のサーバー ログインを作成します。

    次の Transact-SQL がログインを作成します。

    USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';

ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];

    可用性グループの作成時、Pacemaker ユーザーには、可用性グループを作成した後かつその可用性グループにノードを追加する前に、可用性グループに対するALTER、CONTROL、VIEW DEFINITION 権限が必要です。

  2. すべての SQL Server インスタンスで、SQL Server ログインに使用される資格情報を保存します。

    echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/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 # Only readable by root

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

可用性グループ リソースを作成するには、pcs resource create コマンドを使用し、リソースのプロパティを設定します。 次のコマンドを実行すると、ag1 という名前の可用性グループに対して、ocf:mssql:ag というマスター/下位タイプのリソースが作成されます。

RHEL 7

sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s master notify=true

RHEL 8

RHEL 8 が使用できるようになると共に、create 構文が変更されました。 RHEL 8 を使用している場合は、用語 master が promotable に変更されています。 上記のコマンドの代わりに、次の create コマンドを使用します。

sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s promotable notify=true

Note

リソースを作成すると、以降は定期的に、可用性グループの構成に基づいて可用性グループの REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT の値を Pacemaker リソース エージェントが自動的に設定します。 たとえば、可用性グループに 3 つの同期レプリカがある場合、エージェントは REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を 1 に設定します。 詳細およびその他の構成オプションについては、「High availability and data protection for availability group configurations」 (可用性グループ構成の高可用性とデータ保護) を参照してください。

仮想 IP リソースを作成する

仮想 IP アドレス リソースを作成するには、1 つのノードで次のコマンドを実行します。 ネットワークから使用可能な静的 IP アドレスを使用します。 <10.128.16.240> 間の IP アドレスは有効な IP アドレスに置き換えてください。

sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>

Pacemaker では、仮想サーバー名に相当するものはありません。 IP アドレスではなく文字列サーバー名を指す接続文字列を使用するには、DNS の仮想 IP リソース アドレスと必要な仮想サーバー名を登録します。 DR 構成の場合は、必要な仮想サーバー名と IP アドレスを、プライマリ サイトと DR サイトの両方の DNS サーバーに登録します。

コロケーション制約を追加する

リソースを実行する場所の選択など、Pacemaker クラスターでのほぼすべての決定は、スコアを比較することによって行われます。 スコアはリソースごとに計算されます。 クラスター リソース マネージャーは、特定のリソースのスコアが最も高いノードを選択します。 ノードにリソースの負のスコアがある場合、そのノードではリソースを実行できません。

Pacemaker クラスターでは、制約を使用してクラスターの決定を操作できます。 制約にはスコアがあります。 制約のスコアが INFINITY より低い場合、Pacemaker は推奨設定とみなします。 INFINITY のスコアは必須です。

プライマリ レプリカと仮想 IP リソースが同じホスト上で実行されるようにするには、INFINITY のスコアを持つコロケーション制約を定義します。 コロケーション制約を追加するには、1 つのノードで次のコマンドを実行します。

RHEL 7

RHEL 7 で ag_cluster リソースを作成すると、リソースが ag_cluster-masterとして作成されます。 RHEL 7 では、次のコマンドを使用します。

sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master

RHEL 8

RHEL 8 で ag_cluster リソースを作成すると、リソースが ag_cluster-cloneとして作成されます。 RHEL 8 では、次のコマンドを使用します。

sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY with-rsc-role=Master

順序制約を追加する

コロケーション制約には、暗黙的な順序制約があります。 これにより、可用性グループ リソースが移動する前に、仮想 IP リソースが移動します。 既定では、イベントの順序は次のとおりです。

  1. ユーザーは、ノード 1 からノード 2 の可用性グループのプライマリに pcs resource move を発行します。

  2. 仮想 IP リソースがノード 1 で停止します。

  3. 仮想 IP リソースがノード 2 で開始します。

    Note

    この時点で、IP アドレスは一時的にノード 2 を指しますが、ノード 2 はフェールオーバー前のセカンダリのままです。

  4. ノード 1 の可用性グループのプライマリは、セカンダリに降格されます。

  5. ノード 2 の可用性グループのセカンダリは、プライマリに昇格されます。

IP アドレスが事前フェールオーバー セカンダリのノードを一時的に指さないようにするには、順序制約を追加します。

順序制約を追加するには、1 つのノードで次のコマンドを実行します。

RHEL 7

sudo pcs constraint order promote ag_cluster-master then start virtualip

RHEL 8

sudo pcs constraint order promote ag_cluster-clone then start virtualip

重要

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

pcs を使用して可用性グループの手動フェールオーバーを行います。 Transact-SQL を使用してフェールオーバーを開始しないでください。 手順については、フェールオーバーに関するページを参照してください。

関連するコンテンツ