SQL Server 用に SLES 共有ディスク クラスターを構成する

適用対象: SQL Server - Linux

このガイドでは、SUSE Linux Enterprise Server (SLES) 上の SQL Server 用に 2 ノードの共有ディスク クラスターを作成する手順について説明します。 クラスタリング レイヤーは、Pacemaker の上に構築された SUSE High Availability Extension (HAE) に基づいています。

クラスター構成、リソース エージェントのオプション、管理、ベスト プラクティス、推奨事項の詳細については、「SUSE Linux Enterprise High Availability Extension 12 SP2」を参照してください。

前提条件

次のエンドツーエンドのシナリオを完了するには、2 ノードのクラスターと別のサーバーを配置して NFS 共有を構成するために、2 台のコンピューターが必要です。 以下の手順では、これらのサーバーの構成方法を説明します。

各クラスター ノードにオペレーティング システムをセットアップして構成する

最初の手順は、クラスター ノード上のオペレーティング システムを構成することです。 このチュートリアルでは、HA アドオンの有効なサブスクリプションで SLES を使用します。

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

1. 両方のノードに SQL Server をインストールしてセットアップします。 詳細については、SQL Server on Linux のインストールに関するページを参照してください。

2. 構成目的の場合は、1 つのノードをプライマリ、もう 1 つをセカンダリとして指定します。 このガイドでは、以降でこれらの用語を使用します。

3. セカンダリ ノードで SQL Server を停止して無効にします。 次の例では、SQL Server を停止して無効にしています。

   sudo systemctl stop mssql-server
   sudo systemctl disable mssql-server
   

   Note

   セットアップ時に、SQL Server インスタンスのサーバー マスター キーが生成され、/var/opt/mssql/secrets/machine-key に配置されます。 Linux では、SQL Server は常に mssql というローカル アカウントとして実行されます。 ローカル アカウントであるため、その ID はノード間で共有されません。 したがって、プライマリ ノードから各セカンダリ ノードに暗号化キーをコピーして、サーバー マスター キーの暗号化を解除するために各ローカル mssql アカウントがそれにアクセスできるようにする必要があります。

4. プライマリ ノードで、Pacemaker の SQL Server ログインを作成し、sp_server_diagnostics を実行するログイン権限を付与します。 Pacemaker は、このアカウントを使用して、SQL Server が実行されているノードを確認します。

   sudo systemctl start mssql-server
   

   「sa」アカウントを使用して SQL Server master データベースに接続し、次を実行します。

   USE [master]
   GO
   CREATE LOGIN [<loginName>] with PASSWORD= N'<loginPassword>'
   GRANT VIEW SERVER STATE TO <loginName>
   

5. プライマリ ノードで SQL Server を停止して無効にします。

6. SUSE のドキュメントの手順に従って、各クラスター ノードのホスト ファイルを構成および更新します。 "hosts" ファイルには、すべてのクラスター ノードの IP アドレスと名前が含まれている必要があります。

   現在のノードの IP アドレスを確認するには、次を実行します。

   sudo ip addr show
   

   各ノードのコンピューター名を設定します。 各ノードに 15 文字以下の一意の名前を指定します。 YAST を使用して、または手動で、/etc/hostname にコンピューター名を追加して設定します。

   次の例では、SLES1 および SLES2 という名前の 2 つのノードが追加された /etc/hosts を示します。

   127.0.0.1      localhost
   10.128.18.128  SLES1
   10.128.16.77   SLES2
   

   すべてのクラスター ノードは、SSH を使用して相互にアクセスできる必要があります。 hb_report or crm_report (トラブルシューティング用) などのツールや Hawk の History Explorer では、ノード間でパスワードなしの SSH アクセスが必要です。それ以外の場合は、現在のノード以外のデータは収集できません。 非標準の SSH ポートを使用する場合は、-X オプションを使用します (man ページを参照)。 たとえば、SSH ポートが 3479 の場合は、次のコマンドを実行して crm_report を呼び出します。

   crm_report -X "-p 3479" [...]
   

   詳細については、「管理ガイド」を参照してください。

次のセクションでは、共有ストレージを構成し、データベース ファイルをそのストレージに移動します。

共有ストレージを構成し、データベース ファイルを移動する

共有ストレージを提供するためのさまざまなソリューションがあります。 このチュートリアルでは、NFS を使用した共有ストレージの構成について説明します。 ベスト プラクティスに従い、Kerberos を使用して NFS をセキュリティで保護することをお勧めします。

• NFS でファイル システムを共有する

このガイダンスに従わないと、ネットワークにアクセスして SQL ノードの IP アドレスになりすますことができるユーザーが、データ ファイルにアクセスできてしまいます。 いつもどおり、運用環境で使用する前にシステムの脅威をモデル化してください。

もう 1 つのストレージ オプションは、SMB ファイル共有を使用することです。

• SUSE ドキュメントの Samba セクション

NFS サーバーを構成する

NFS サーバーを構成するには、SUSE のドキュメント「NFS サーバーの構成」にある次の手順を参照してください。

NFS 共有ストレージに接続するようにすべてのクラスター ノードを構成する

クライアント NFS を構成して、共有ストレージの場所を指すように SQL Server データベース ファイルのパスをマウントする前に、後で共有にコピーできるように、データベース ファイルを一時的な場所に保存します。

1. プライマリ ノードでのみ、データベース ファイルを一時的な場所に保存します。 次のスクリプトでは、新しい一時ディレクトリが作成され、データベース ファイルが新しいディレクトリにコピーされて、古いデータベース ファイルが削除されます。 SQL Server はローカル ユーザー mssql として実行されるので、マウントされた共有へのデータ転送後に、ローカル ユーザーが共有に読み取り/書き込みアクセスできることを、確認する必要があります。

   su mssql
   mkdir /var/opt/mssql/tmp
   cp /var/opt/mssql/data/* /var/opt/mssql/tmp
   rm /var/opt/mssql/data/*
   exit
   

   すべてのクラスター ノードで NFS クライアントを構成します。

   • クライアントの構成

   Note

   SUSE のベスト プラクティスと、高可用性 NFS ストレージに関する推奨事項に従うことをお勧めします (「DRBD および Pacemaker を使用した高可用性 NFS ストレージ」参照)。

2. SQL Server が新しいファイル パスで正常に起動されることを確認します。 これを各ノードで行います。 この時点では、一度に 1 つのノードだけで SQL Server を実行する必要があります。 両方が同時にデータ ファイルにアクセスしようとするため、両方を同時に実行することはできません (両方のノードで誤って SQL Server が開始されるのを防ぐために、ファイル システム の クラスター リソースを使用して、共有が異なるノードによって 2 回マウントされていないようにしてください)。 次のコマンドでは、SQL Server が起動され、状態が確認されてから、SQL Server が停止されます。

   sudo systemctl start mssql-server
   sudo systemctl status mssql-server
   sudo systemctl stop mssql-server
   

この時点で、SQL Server の両方のインスタンスが、共有ストレージ上のデータベース ファイルを使用して実行されるように構成されています。 次のステップでは、Pacemaker 用に SQL Server を構成します。

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

1. 両方のクラスター ノードで、Pacemaker にログインするための SQL Server のユーザー名とパスワードを格納するファイルを作成します。 次のコマンドは、このファイルを作成および設定します。

   sudo touch /var/opt/mssql/secrets/passwd
   sudo echo '<loginName>' >> /var/opt/mssql/secrets/passwd
   sudo echo '<loginPassword>' >> /var/opt/mssql/secrets/passwd
   sudo chown root:root /var/opt/mssql/secrets/passwd
   sudo chmod 600 /var/opt/mssql/secrets/passwd
   

2. すべてのクラスター ノードは、SSH を使用して相互にアクセスできる必要があります。 hb_report or crm_report (トラブルシューティング用) などのツールや Hawk の History Explorer では、ノード間でパスワードなしの SSH アクセスが必要です。それ以外の場合は、現在のノード以外のデータは収集できません。 非標準の SSH ポートを使用する場合は、-X オプションを使用します (man ページを参照)。 たとえば、SSH ポートが 3479 の場合は、次のコマンドを実行して hb_report を呼び出します。

   crm_report -X "-p 3479" [...]
   

   詳細については、SUSE ドキュメントのシステム要件と推奨事項をご覧ください。

3. High Availability Extension をインストールします。 この拡張機能をインストールするには、次の SUSE の記事の手順に従ってください。

   インストールとセットアップのクイック スタート

4. SQL Server の FCI リソース エージェントをインストールします。 両方のノードで、次のコマンドを実行します。

   sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/12/mssql-server-2017.repo
   sudo zypper --gpg-auto-import-keys refresh
   sudo zypper install mssql-server-ha
   

5. 最初のノードが自動的にセットアップされます。 次の手順では、1 つ目のノードである SLES1 を構成することにより、動作中の 1 ノード クラスターをセットアップします。 SUSE の記事「1 つ目のノードのセットアップ」の指示に従ってください。

   完了したら、crm status を使用してクラスターの状態を確認します。

   crm status
   

   ノード SLES1 が構成済みであることが表示されます。

6. 既存のクラスターにノードを追加します。 次に、ノード SLES2 をクラスターに参加させます。 SUSE の記事「2 つ目のノードの追加」の指示に従ってください。

   完了したら、crm status を使用してクラスターの状態を確認します。 2 つ目のノードが正常に追加されると、出力が次のようになります。

   2 nodes configured
   1 resource configured
   Online: [ SLES1 SLES2 ]
   Full list of resources:
   admin_addr     (ocf::heartbeat:IPaddr2):       Started SLES1
   

   Note

   admin_addr は、最初の 1 ノード クラスターのセットアップ時に構成された仮想 IP クラスターのリソースです。

7. 削除手順。 クラスターからノードを削除する必要がある場合は、ブートストラップ スクリプト ha-cluster-remove を使用します。 詳細については、「Overview of the Bootstrap Scripts (ブートストラップ スクリプトの概要)」をご覧ください。

SQL Server 用にクラスター リソースを構成する

次の手順では、SQL Server 用にクラスター リソースを構成する方法について説明します。 カスタマイズする必要のある設定が 2 つあります。

• SQL Server リソース名: クラスター化された SQL Server のリソースの名前。
• タイムアウト値: タイムアウト値は、リソースがオンラインになるまでクラスターが待機する時間です。 SQL Server の場合、これは SQL Server によって master データベースがオンラインにされるまでにかかることが予想される時間です。

実際の環境に合わせて、次のスクリプトの値を更新します。 1 つのノードで実行し、クラスター化されたサービスを構成して開始します。

sudo crm configure
primitive <sqlServerResourceName> ocf:mssql:fci op start timeout=<timeout_in_seconds>
colocation <constraintName> inf: <virtualIPResourceName> <sqlServerResourceName>
show
commit
exit

たとえば、次のスクリプトでは、mssqlha という名前のクラスター化された SQL Server リソースが作成されます。

sudo crm configure
primitive mssqlha ocf:mssql:fci op start timeout=60s
colocation admin_addr_mssqlha inf: admin_addr mssqlha
show
commit
exit

構成がコミットされた後、仮想 IP リソースと同じノードで SQL Server が起動されます。

詳細については、「クラスター リソースの構成と管理 (コマンド ライン)」を参照してください。

SQL Server が起動されていることを確認

SQL Server が起動されたことを確認するには、crm status コマンドを実行します。

crm status

次の例は、Pacemaker がクラスター化されたリソースとして正常に開始されたときの結果を示しています。

2 nodes configured
2 resources configured

Online: [ SLES1 SLES2 ]

Full list of resources:

 admin_addr     (ocf::heartbeat:IPaddr2):       Started SLES1
 mssqlha        (ocf::mssql:fci):       Started SLES1

クラスター リソースの管理

クラスター リソースの管理については、SUSE の記事「クラスター リソースの管理」を参照してください。

手動フェールオーバー

リソースはハードウェアまたはソフトウェアの障害が発生した場合にクラスターの他のノードに自動的にフェールオーバー (または移行) するように構成されていますが、Pacemaker の GUI またはコマンド ラインを使って、手動でクラスター内の別のノードにリソースを移動することもできます。

このタスクには migrate コマンドを使います。 たとえば、SQL リソースをクラスター ノード名 SLES2 に移行するには、以下を実行します。

crm resource
migrate mssqlha SLES2

関連するコンテンツ

• SUSE Linux Enterprise High Availability Extension - 管理ガイド