適用対象:
Linux 上の SQL Server
この記事では、Linux 上の SQL Server フェールオーバー クラスター インスタンス (FCI) に関連する概念について説明します。
Linux上でSQL Server FCIを作成するには、「Linuxでフェイルオーバークラスタインスタンスを構成(RHEL)」をご覧ください。
クラスタリング レイヤー
Red Hat Enterprise Linux(RHEL)では、クラスタリング層はRHEL HAアドオンに基づいています。
Note
Red Hat HA アドオンとドキュメントにアクセスするには、サブスクリプションが必要です。
SUSE Linux Enterprise Server (SLES) では、クラスタリング レイヤーは、SUSE Linux Enterprise High Availability Extension (HAE) に基づいています。
クラスター構成、リソース エージェントのオプション、管理、ベスト プラクティス、推奨事項の詳細については、「SUSE Linux Enterprise High Availability Extension 15」を参照してください。
RHEL HA アドオンと SUSE HAE は、どちらも Pacemaker 上に構築されます。
次の図に示すように、2 台のサーバーに対してストレージが提示されます。 クラスタリング コンポーネント (Corosync と Pacemaker) によって、通信とリソース管理が調整されます。 1 台のサーバーで、ストレージ リソースと SQL Server へのアクティブ接続が行われます。 Pacemaker で障害が検出されると、クラスタリング コンポーネントによって他のノードにリソースが移動します。
Linux上のPacemakerとのSQL Server連携は、WindowsのWindows Serverフェイルオーバークラスタリング(WSFC)ほど連携していません。 SQL Server は、クラスターの存在を認識しません。 すべてのオーケストレーションはアウトサイド インで、サービスは Pacemaker によってスタンドアロン インスタンスとして制御されます。 さらに、仮想ネットワーク名は WSFC に固有であり、Pacemaker にはそれに相当するものはありません。 クラスター DMV @@SERVERNAME および sys.servers がレコードを返さないときに、sys.dm_os_cluster_nodes および sys.dm_os_cluster_properties はノード名を返すと予想されます。 サーバー名を指定する接続文字列を使用し、IPアドレスを使用しない場合は、仮想IPリソースの作成に使用したIPアドレスを、選択したサーバー名で使用しているDNSサーバーに登録する必要があります（以下のセクションで説明します）。
2025 SQL Server(17.x)では、Cumulative Update (CU) 3以降のバージョンとともに、Red Hat Enterprise Linux(RHEL)およびUbuntu向けの新しいPacemaker HAエージェントv2がmssql-server-haパッケージで利用可能になりました。
Pacemaker HA エージェント v2 では、次のような、以前のエージェントに対する信頼性とパフォーマンスの向上が導入されています。
フェールオーバーのパフォーマンスを向上させ、計画されたフェールオーバー時間と計画外のフェールオーバー時間の両方を短縮しました。
正常性チェックのタイムアウトと障害状態レベルの構成など、柔軟な自動フェールオーバー ポリシーのサポート。
Pacemaker クラスターと SQL Server 間の通信に対する TLS 1.3 のサポート。
Pacemaker HA エージェント v2 は現在プレビュー段階です。 既存の Pacemaker HA エージェント (v1) は、運用環境のデプロイで引き続き完全にサポートされています。
インスタンスとノードの数
SQL Server on Linux での重要な違いの 1 つは、Linux サーバーごとにインストールできる SQL Server は 1 台だけであるということです。 そのインストールをインスタンスと呼びます。 Windows ServerがWSFCごとに最大25のFCIをサポートするのに対し、LinuxベースのFCIはインスタンスが1つだけです。 この 1 つのインスタンスは、既定のインスタンスでもあります。Linux には、名前付きインスタンスという概念はありません。
Corosync が関与している場合、Pacemaker クラスターには最大 16 個のノードを含めることができるので、1 つの FCI は最大 16 台のサーバーにまたがることができます。 Standard Edition の SQL Server で実装された FCI では、Pacemaker クラスターに最大 16 個のノードがある場合でも、1 つのクラスターで最大 2 個のノードがサポートされます。
SQL Server FCIでは、SQL Serverインスタンスは一度に1つのノードでのみアクティブです。
IP アドレスと名前
Linux Pacemaker クラスターでは、各 SQL Server FCI に固有の IP アドレスと名前が必要です。 FCI 構成が複数のサブネットにまたがっている場合は、サブネットごとに 1 つの IP アドレスが必要です。 FCI へのアクセスでは、Pacemaker クラスターの下層のサーバーをアプリケーションやエンドユーザーが認識する必要がないように、一意の名前と IP アドレスが使用されます。
DNS 内の FCI の名前は、Pacemaker クラスター内に作成される FCI リソースの名前と同じである必要があります。 名前と IP アドレスの両方を DNS に登録する必要があります。
共有ストレージ
すべての FCI は、Linux サーバー上にあるか Windows Server 上にあるかにかかわらず、何らかの形式の共有ストレージを必要とします。 このストレージが FCI をホストできる可能性があるすべてのサーバーに提示されますが、FCI のためにこのストレージを使用できるのは常に 1 台のサーバーだけです。 Linux 上で使用できる共有ストレージのオプションを次に示します。
- iSCSI
- ネットワーク ファイル システム (NFS)
- サーバー メッセージ ブロック (SMB)
Windows Server には、少し異なるオプションがあります。 Linux ベースの FCI で現在サポートされていないオプションの 1 つとして、SQL Server の一時ワークスペースである tempdb のノードに対してローカルなディスクを使用する機能があります。
複数の場所にまたがる構成では、片方のデータ センターに格納されるものを他方のデータ センターと同期する必要があります。 フェールオーバーが発生した場合は、FCI をオンラインにすることができ、ストレージは同じものと認識されます。 これを実現するには、下層のストレージ ハードウェアによって実行されるか、ソフトウェアベースのユーティリティによって実行されるかにかかわらず、ストレージ レプリケーションのための外部的な方法が必要です。
Note
SQL Serverでは、サーバーに直接ディスクを提示するLinuxベースのデプロイメントはXFSまたはext4でフォーマットする必要があります。 それ以外のファイル システムは現在サポートされていません。
共有ストレージを提示するためのプロセスは、サポートされている他の方法と同じです。
- 共有ストレージを構成する
- FCI 用の Pacemaker クラスターのノードとして機能するサーバーに、ストレージをフォルダーとしてマウントする
- 必要に応じて SQL Server システム データベースを共有ストレージに移動する
- 共有ストレージに接続されている各サーバーから SQL Server が動作することをテストする
SQL Server on Linux での主要な違いの 1 つは、既定のユーザー データとログ ファイルの場所は構成することはできますが、システム データベースは常に /var/opt/mssql/data に存在する必要があるということです。 Windows Server では、tempdb などのシステム データベースを移動することができます。 この事実は、FCI 用に共有ストレージをどのように構成するかに関係します。
システム以外のデータベースの既定のパスを、mssql-conf ユーティリティを使用して変更できます。 デフォルトを変更する方法については、「 デフォルトデータの変更」または「ログディレクトリの場所の変更」をご覧ください。 また、SQL Serverのデータやトランザクションログは、適切なセキュリティが確保されている場所であれば、デフォルトの場所でなくても保存できます。場所は明示する必要があります。