フェールオーバー クラスター インスタンス - SQL Server on Linux
適用対象: 
SQL Server - Linux
この記事では、Linux 上の SQL Server フェールオーバー クラスター インスタンス (FCI) に関連する概念について説明します。
Linux に SQL Server FCI を作成するには、「フェールオーバー クラスター インスタンスの構成 - SQL Server on Linux (RHEL)」を参照してください。
クラスタリング レイヤー
Red Hat Enterprise Linux (RHEL) では、クラスタリング レイヤーは Red Hat Enterprise Linux (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 上の SQL Server と Pacemaker の統合では、Windows 上の WSFC との統合ほどには連携していません。 SQL Server は、クラスターの存在を認識しません。 すべてのオーケストレーションはアウトサイド インで、サービスは Pacemaker によってスタンドアロン インスタンスとして制御されます。 さらに、仮想ネットワーク名は WSFC に固有であり、Pacemaker にはそれに相当するものはありません。 クラスター DMV sys.dm_os_cluster_nodes および sys.dm_os_cluster_properties がレコードを返さないときに、@@SERVERNAME および sys.servers はノード名を返すと予想されます。 IP ではなく、文字列サーバー名をポイントする接続文字列を使用するには、仮想 IP リソースを作成するために使用する IP (以降のセクションで説明) を、選択したサーバー名と共に DNS サーバーに登録する必要があります。
インスタンスとノードの数
SQL Server on Linux での重要な違いの 1 つは、Linux サーバーごとにインストールできる SQL Server は 1 台だけであるということです。 そのインストールをインスタンスと呼びます。 Windows Server フェールオーバー クラスター (WSFC) 当たり最大 25 の FCI がサポートされる Windows Server とは異なり、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 インスタンスは、片方のノードでのみアクティブになります。
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
- Network File System (NFS)
- Windows Server のサーバー メッセージ ブロック (SMB)。わずかに異なるオプションがあります。 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 のデータとトランザクションを格納することもできますが、その場所を明示する必要があります。