SQL Server 2017 (14.x) 以降、SQL Serverは Linux と Windows の両方でサポートされています。 WindowsベースのSQL Serverデプロイと同様に、SQL Serverデータベースとインスタンスは Linux で高可用性である必要があります。 この記事では、Corosync を使用して Pacemaker を理解するための基本情報と、SQL Server構成用に計画およびデプロイする方法について説明します。
HA アドオン/拡張機能の基本
現在サポートされているすべてのディストリビューションには、Pacemaker クラスタリング スタックに基づく高可用性アドオン/拡張機能が付属しています。 このスタックには、次の 2 つの主要コンポーネントが組み込まれています。Pacemaker と Corosync。 スタックのすべてのコンポーネントは次のとおりです。
- ペースメーカー。 クラスター化されたコンピューター間の調整を行うコア クラスタリング コンポーネント。
- Corosync。 クォーラムなどの機能や、失敗したプロセスを再起動する機能などを提供するフレームワークと API のセット。
- libQB。 ログなどの機能を提供します。
- リソース エージェント。 アプリケーションが Pacemaker を統合できるように提供される特定の機能。
- フェンス エージェント。 ノードを分離し、問題が発生した場合にはそれらに対処できるようにするためのスクリプトまたは機能。
注
クラスター スタックは、Linux の世界では一般に Pacemaker と呼ばれています。
このソリューションは、いくつかの点で似ていますが、Windowsを使用したクラスター化された構成のデプロイとはさまざまな点で異なります。 Windowsでは、Windows Server フェールオーバー クラスター (WSFC) と呼ばれるクラスタリングの可用性形式がオペレーティング システムに組み込まれており、WSFC フェールオーバー クラスタリングの作成を可能にする機能は既定で無効になっています。 Windowsでは、AG と FCI は WSFC の上に構築され、SQL Serverによって提供される特定のリソース DLL のために緊密な統合を共有します。 この密結合のソリューションは、1 つのベンダーから提供されているからこそ実現できているとも言えます。
Linux では、サポートされている各ディストリビューションで Pacemaker を利用できますが、それぞれのディストリビューションでカスタマイズすることができ、実装とバージョンが少し異なる場合があります。 相違点の一部は、この記事の手順に反映されています。 クラスタリング レイヤーはopen sourceであるため、ディストリビューションに付属していても、WSFC がWindowsされているのと同じ方法で緊密に統合されません。 このため、Microsoft は SQL Server と Pacemaker スタックが、Windows 上の AG と FCI に近い、しかし完全に同一ではないエクスペリエンスを提供できるようにするために、mssql-server-ha を提供しています。
Pacemaker に関する完全なドキュメント (完全な参照情報を含んだ詳細な説明など) については、RHEL と SLES についてそれぞれ次を参照してください。
注
SQL Server 2025 (17.x) 以降、SUSE Linux Enterprise Server (SLES) はサポートされていません。
スタック全体の詳細については、ClusterLabs のサイトにある公式の Pacemaker ドキュメント ページも参照してください。
Pacemaker の概念と用語
このセクションでは、Pacemaker の実装に関する一般的な概念と用語について説明します。
Node
ノードとは、クラスターに参加しているサーバーのことです。 Pacemaker クラスターでは、最大 16 のノードがネイティブにサポートされています。 この数は、Corosync が追加のノードで実行されていない場合に超えることができますが、SQL Serverには Corosync が必要です。 そのため、SQL Server ベースの構成に対してクラスターに保持できるノードの最大数は 16 です。これは Pacemaker の制限であり、SQL Serverによって課される AG または FCI の最大制限とは関係ありません。
リソース
リソースの概念は、WSFC と Pacemaker のどちらのクラスターにも存在します。 リソースとは、クラスターのコンテキストで実行される特定の機能のことです(ディスクや IP アドレスなど)。 たとえば、Pacemaker では、FCI と AG の両方のリソースを作成できます。 これは WSFC で行われることとは異なります。ここでは、AG を構成するときに FCI または AG リソースのSQL Server リソースが表示されますが、SQL Serverと Pacemaker の統合方法の根本的な違いによってまったく同じではありません。
Pacemaker には、標準リソースとクローン リソースがあります。 クローン リソースとは、すべてのノードで同時に実行されるリソースのことです。 たとえば、負荷分散のために複数のノードで実行される IP アドレスなどがこれに該当します。 FCI 用に作成されたリソースでは、標準リソースが使用されます。これは、FCI は 1 つのノードでしか同時にホストできないためです。
注
この記事には、スレーブという用語(Microsoft使用されなくなった用語)への参照が含まれています。 ソフトウェアから用語が削除されると、この記事から削除されます。
AG を作成する際には、マルチステート リソースと呼ばれる特殊な形式の複製リソースが必要になります。 AG のプライマリ レプリカは 1 つだけですが、AG 自体は、動作元として構成されたすべてのノードで実行され、場合によっては、読み取り専用アクセスなども使用することができます。 これはノードの "ライブ" 使用なので、リソースには "昇格済み" (以前の "マスター") と "未昇格" (以前の "スレーブ") という 2 つの状態の概念があります。 詳細については、「多状態のリソース:複数モードのリソース」を参照してください。
リソース グループ/セット
WSFC のロールのように、Pacemaker クラスターにはリソース グループという概念があります。 リソース グループ (SLES では "セット" と呼ばれます) とは、連携的に機能し、1 つのノードから別のノードに 1 つの単位としてフェールオーバーすることができる、リソースのコレクションです。 リソース グループには、"昇格済み" または "未昇格" として構成されたリソースを含めることはできないため、これらを AG に使うことはできません。 リソース グループは FCI には使用できますが、通常は推奨される構成ではありません。
制約
WSFC には、リソースおよび依存関係のようなものに関するさまざまなパラメーターがあります。これにより、2 つの異なるリソース間の親子関係が WSFC に伝えられます。 依存関係とは、どのリソースを最初にオンラインにする必要があるかを WSFC に指示するルールのことです。
Pacemaker クラスターには、依存関係の概念はありませんが、制約という概念があります。 制約には、コロケーション、場所、順序という 3 つの種類があります。
- コロケーション制約は、2 つのリソースを同じノードで実行する必要があるかどうかを指示するものです。
- 場所制約は、リソースを実行できる (または実行できない) 場所を Pacemaker クラスターに指示するものです。
- 順序制約は、リソースの開始順序を Pacemaker クラスターに指示するものです。
注
コロケーション制約は、リソース グループ内のリソースには必要ありません (すべてのリソースが 1 つの単位として見なされるため)。
クォーラム、フェンス エージェント、STONITH
Pacemaker のクォーラムは、概念的には WSFC と似ています。 クラスターのクォーラム メカニズムの全体的な目的は、クラスターの稼働状態を維持することです。 Linuxディストリビューション向けのWSFCおよびHAのアドオンには、各ノードがクォーラムに対して1票としてカウントされるという投票の概念があります。 投票で賛成票が過半数を占めることが重要です。そうでないと、最悪のシナリオではクラスターがシャットダウンされます。
WSFC とは異なり、クォーラムを管理する際に使用される証人リソースがありません。 WSFC と同様に、投票者の数を奇数に維持することが目標とされます。 クォーラム構成では、AG について、FCI とは異なる考慮事項があります。
WSFC では、参加しているノードの状態が監視され、問題が発生したときにはそれらが処理されます。 新しいバージョンの WSFC では、誤動作しているノードや使用できないノード (ノードがオンになっていない、ネットワーク通信が停止しているなど) を検査する機能などが提供されます。 Linux 側では、この種の機能はフェンス エージェントによって提供されます。 この概念は、「フェンシング」と呼ばれることもあります。 ただし、これらのフェンス エージェントは、展開に固有のものであり、多くの場合、ハードウェア ベンダーや一部のソフトウェア ベンダー (ハイパーバイザーを提供するベンダーなど) によって提供されます。 たとえば、VMware では、vSphere を使用して仮想化された Linux VM 用に使用できるフェンス エージェントが提供されます。
クォーラムとフェンスは、STONITH (Shoot the Other Node in the Head) と呼ばれる別の概念と関連します。 STONITH では、すべての Linux ディストリビューションで Pacemaker クラスターがサポートされていることが要件となります。 詳細については、「Red Hat High Availability Cluster でのフェンス」を参照してください。
corosync.conf
この corosync.conf ファイルには、クラスターの構成が格納されます。 このファイルは /etc/corosync にあります。 通常の日常業務では、クラスターが適切に設定されていれば、このファイルを編集する必要はありません。
クラスター ログの場所
Pacemaker クラスターのログの場所は、ディストリビューションによって異なります。
- RHEL と SLES:
/var/log/cluster/corosync.log - Ubuntu：
/var/log/corosync/corosync.log
ログの既定の場所を変更するには、corosync.conf に変更を加えます。
SQL Serverの Pacemaker クラスターを計画する
このセクションでは、Pacemaker クラスターの重要な計画ポイントについて説明します。
SQL Server用に Linux ベースの Pacemaker クラスターを仮想化する
仮想マシンを使用して AG と FCI に Linux ベースのSQL Serverデプロイをデプロイする場合は、Windows ベースのデプロイと同じ規則が適用されます。 Microsoftが提供する「ハードウェア仮想化環境で実行されるMicrosoft SQL Server製品のサポートポリシー」には、仮想化されたSQL Server展開のサポートに関する基本ルールのセットがあります。 プラットフォーム自体の違いにより、MicrosoftのHyper-Vや VMware の ESXi などのハイパーバイザーによって、その上に異なる差異が生じる可能性があります。
仮想化環境で AG と FCI を使用する場合は、指定された Pacemaker クラスターのノードに対して、アンチアフィニティが設定されていることを確認してください。 AG または FCI 構成で高可用性を実現するように構成されている場合、SQL Serverをホストしている VM が同じハイパーバイザー ホスト上で実行されることはありません。 たとえば、2 ノードの FCI が展開されている場合、特にライブ マイグレーションや vMotion のような機能を使用している場合には、ホストで障害が発生したときに、ノードをホストしている VM のいずれかに対して移行先を確保できるよう、"少なくとも" 3 つのハイパーバイザー ホストを確保する必要があります。
Hyper-Vドキュメントについては、「
ネットワーク
WSFC とは異なり、Pacemaker では、Pacemaker クラスター自体に対して専用の名前を付けたり、少なくとも 1 つの専用 IP アドレスを持たせる必要はありません。 AG と FCI には IP アドレスが必要 (詳細については、それぞれのドキュメントを参照してください) ですが、ネットワーク名リソースがないので、名前は必要ありません。 SLES では、管理目的で IP アドレスを構成することができますが、「Pacemaker クラスターを作成する」で示されているように、必須ではありません。
WSFC と同様に、Pacemaker では冗長ネットワークの使用が推奨されます。つまり、ネットワーク カード (NIC または物理用の pNIC) ごとに個別の IP アドレスを持たせることが推奨されます。 クラスター構成の観点からいうと、各 IP アドレスには、専用のリングと呼ばれるものが使用されます。 ただし、現在の WSFC と同様に、多くの実装は仮想化されたり、パブリック クラウド上に置かれるため、サーバーに対して 1 つの仮想 NIC (vNIC) しか存在しません。 すべての pNIC と vNIC が同じ物理または仮想スイッチに接続されている場合、ネットワーク層には真の冗長性が確保されないため、複数の NIC を構成することは、仮想マシンにとっては一種の気休めということになります。 ネットワークの冗長性は、通常、仮想化されたデプロイ用にハイパーバイザーに組み込まれており、最終的にパブリック クラウドに組み込まれます。
複数の NIC を Pacemaker で使用する場合と WSFC で使用する場合の違いを 1 つ挙げると、Pacemaker では、同じサブネット上で複数の IP アドレスが許可されますが、WSFC では許可されません。 複数のサブネットと Linux クラスターの詳細については、「複数サブネットの Always On 可用性グループとフェールオーバー クラスター インスタンスを構成する」の記事を参照してください。
クォーラムと STONITH
クォーラムの構成と要件は、SQL SERVERの AG または FCI 固有のデプロイに関連します。
サポートされている Pacemaker クラスターには STONITH が必須です。 STONITH を構成するには、ディストリビューションのドキュメントを使用します。 たとえば、SLES の場合なら「ストレージベースのフェンス」を使用します。 ESXi ベースのソリューションの場合は、VMware vCenter 用の STONITH エージェントもあります。 詳細については、「VMware VM VCenter SOAP フェンス向け STONITH プラグイン エージェント (非公式)」を参照してください。
相互運用性
このセクションでは、Linux ベースのクラスターで、WSFC や他の Linux ディストリビューションとどのように連携できるかについて説明します。
WSFC
現時点では、WSFC と Pacemaker クラスターを連携させる直接的な方法はありません。 つまり、WSFC と Pacemaker をまたいで動作する AG や FCI を作成することはできません。 ただし、2 つの相互運用性ソリューションがあります。これらは、どちらも AG 向けに設計されています。 FCI をクロスプラットフォーム構成に参加させる唯一の方法は、次の 2 つのシナリオのいずれかで、FCI をインスタンスとして参加させる方法です。
- クラスタータイプが「なし」のAG。 詳細については、Windows availability グループのドキュメントを参照してください。
- 分散型 AG。これは、2 つの異なる AG を独自の可用性グループとして構成することができる、特別な種類の可用性グループです。 分散 AG の詳細については、ドキュメント「分散型可用性グループ」を参照してください。
他の Linux ディストリビューション
Linux では、Pacemaker クラスターのすべてのノードが同じディストリビューション上に存在している必要があります。 たとえば、RHEL ノードは、SLES ノードを持つ Pacemaker クラスターの一部にすることはできません。 この問題の主な理由は前に説明したとおりで、ディストリビューションのバージョンと機能が異なることで、正常に機能しない可能性があるためです。 ディストリビューションの混合については、WSFC と Linux の混合と同じ条件が適用されます。つまり、None または 分散型 AG を使用してください。