Ubuntu クラスターと可用性グループ リソースを構成する

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

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

注意

現時点では、Linux 上の SQL Server と Pacemaker の統合では、Windows 上の WSFC のような連携は行われていません。 SQL の内部にはクラスターの存在に関する情報はなく、すべての調整は外部で実行され、サービスはスタンドアロン インスタンスとして Pacemaker によって制御されます。 さらに、仮想ネットワーク名は WSFC に固有のものであり、Pacemaker にはそれに該当するものはありません。 クラスターの情報を照会する Always On の動的管理ビューでは、空の行が返されます。 フェールオーバー後に透過的な再接続に使用するリスナーを引き続き作成できますが、仮想 IP リソースの作成に使用する IP で、DNS サーバーにリスナー名を手動で登録する必要があります (以下のセクションで説明します)。

次のセクションでは、フェールオーバー クラスター ソリューションを設定する手順について説明します。

ロードマップ

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

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

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

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

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

    重要

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

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

    フェンスは通常、オペレーティング システムで実装され、環境に依存します。 フェンスの取扱説明はオペレーティング システムのディストリビューターが提供するドキュメントにあります。

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

各クラスター ノードに Pacemaker をインストールして構成する

  1. すべてのノードで、ファイアウォールのポートを開きます。 Pacemaker 高可用性サービス、SQL Server インスタンス、および可用性グループ エンドポイント用にポートを開きます。 SQL Server が実行されているサーバーの既定の TCP ポートは 1433 です。

    sudo ufw allow 2224/tcp
    sudo ufw allow 3121/tcp
    sudo ufw allow 21064/tcp
    sudo ufw allow 5405/udp
    
    sudo ufw allow 1433/tcp # Replace with TDS endpoint
    sudo ufw allow 5022/tcp # Replace with DATA_MIRRORING endpoint
    
    sudo ufw reload
    

    または、単にファイアウォールを無効にしてもかまいません。

    sudo ufw disable
    
  2. Pacemaker パッケージをインストールします。 すべてのノードで、次のコマンドを実行します。

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

    sudo passwd hacluster
    

pcsd サービスと Pacemaker を有効にして開始する

次のコマンドを実行すると、pcsd サービスと Pacemaker が有効になり、開始されます。 すべてのノードで実行します。 これにより、再起動後にノードはクラスターに再度参加できます。

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

注意

Pacemaker のコマンド enable は、エラー "pacemaker Default-Start contains no runlevels, aborting" (Pacemaker Default-Start に実行レベルが含まれていません、中止します) で完了する場合があります。 これは害がないため、クラスターの構成を続行できます。

クラスターを作成する

  1. すべてのノードから既存のクラスター構成を削除します。

    "sudo apt-get install pcs" を実行すると、Pacemaker、corosync、pcs が同時にインストールされ、3 つのサービスすべての実行が開始されます。 corosync を開始すると、テンプレート "/etc/cluster/corosync.conf" ファイルが生成されます。 次の手順を成功させるには、このファイルが存在していてはなりません。そのため、回避策として、pacemaker/corosync を停止して "/etc/cluster/corosync.conf" を削除します。そうすれば、次の手順は正常に完了します。 "pcs cluster destroy" では同じことが行われ、1 回の初期クラスター セットアップ ステップとして使用できます。

    次のコマンドでは、既存のクラスター構成ファイルが削除されて、すべてのクラスター サービスが停止されます。 これにより、クラスターが完全に破棄されます。 運用前環境での最初のステップとしてそれを実行します。 "pcs cluster destroy" によって pacemaker サービスが無効にされているので、再度有効にする必要があることに注意してください。 すべてのノードで次のコマンドを実行します。

    警告

    そのコマンドでは、既存のすべてのクラスター リソースが破棄されます。

    sudo pcs cluster destroy 
    sudo systemctl enable pacemaker
    
  2. クラスターを作成します。

    警告

    クラスタリング ベンダーが調査している既知の問題のため、クラスターの開始 ("pcs cluster start") は、次のエラーで失敗します。 これは、クラスターのセットアップ コマンドの実行時に作成される /etc/corosync/corosync.conf で構成されるログ ファイルが間違っているためです。 この問題を回避するには、ログ ファイルを次のように変更します: /var/log/corosync/corosync.log。 または、/var/log/cluster/corosync.log ファイルを作成するのでもかまいません。

    Job for corosync.service failed because the control process exited with error code. 
    See "systemctl status corosync.service" and "journalctl -xe" for details.
    

次のコマンドでは、3 ノードのクラスターが作成されます。 スクリプトを実行する前に、< ... > の間の値を置き換えます。 プライマリ ノードで次のコマンドを実行します。

sudo pcs host auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
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" を実行するのと同じあり、"sudo systemctl enable pacemaker" を使用して、Pacemaker のサービスを再度有効にする必要がある点に注意してください。

フェンスを構成する (STONITH)

Pacemaker クラスターのベンダーは、STONITH を有効にして、サポートされているクラスター セットアップ用にフェンス デバイスを構成する必要があります。 クラスター リソース マネージャーでノードまたはノード上のリソースの状態を判断できない場合は、フェンスを使用してクラスターが既知の状態に戻されます。 リソース レベルのフェンスにより主に、リソースを構成することによって障害が発生した場合にデータが破損しないことが保証されます。 たとえば DRBD (分散レプリケートされたブロックデバイス) でリソース レベルのフェンスを使用して、通信リンクがダウンしたときにノード上のディスクを期限切れとしてマークすることができます。 ノード レベルのフェンスでは、ノードによってリソースが実行されないことが保証されます。 これはノードをリセットすることによって行われ、Pacemaker の実装は "STONITH" ("Shoot the Other Node in the Head") と呼ばれます。 Pacemaker では、サーバーの無停電電源装置や管理インターフェイス カードなど、さまざまな種類のフェンス デバイスがサポートされています。 詳細については、「ゼロから始める Pacemaker クラスター」および「フェンスと STONITH」をご覧ください

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

sudo pcs property set stonith-enabled=false

重要

STONITH を無効にするのは、テスト目的の場合だけです。 運用環境で Pacemaker を使用する予定がある場合は、環境に応じて STONITH の実装を計画し、有効にしておく必要があります。 特定のディストリビューションのフェンス エージェントに関する詳細は、オペレーティング システム ベンダーにお問い合わせください。

クラスター プロパティ 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 に戻す必要があります。 さらに、failover-timeout プロパティを含めるには、AG リソースを更新する必要があります。

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

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

既存の AG リソース プロパティ failure-timeout60s に更新して、次を実行します (ag1 は可用性グループ リソースの名前に置き換えてください)。

pcs resource update ag1 meta failure-timeout=60s

Pacemaker との統合のために SQL Server リソース エージェントをインストールする

すべてのノードで次のコマンドを実行します。

sudo apt-get install mssql-server-ha

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 権限が必要です。

  1. すべての 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 というマスター/下位タイプのリソースが作成されます。

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

注意

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

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

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

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

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

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

リソースを実行する場所の選択など、Pacemaker クラスターでのほぼすべての決定は、スコアを比較することによって行われます。 スコアはリソースごとに計算され、クラスター リソース マネージャーでは、特定のリソースのスコアが最も高いノードが選択されます。 (ノードにリソースの負のスコアがある場合、そのノードではリソースを実行できません。)制約を使用して、クラスターの決定を構成します。 制約にはスコアがあります。 制約のスコアが INFINITY より低い場合、これは単なる推奨設定です。 INFINITY のスコアは、それが必須であることを意味します。 プライマリ レプリカと仮想 IP リソースを同じホスト上に配置するには、INFINITY のスコアを持つコロケーション制約を定義します。 コロケーション制約を追加するには、1 つのノードで次のコマンドを実行します。

sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY

順序制約を追加する

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

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

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

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

    注意

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

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

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

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

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

sudo pcs constraint order promote ag_cluster-clone then start virtualip

重要

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

次のステップ

HA 可用性グループの操作