Linux 上の可用性グループとフェールオーバー クラスター インスタンスのための Pacemaker

適用対象: SQL Server - Linux

SQL Server 2017 (14.x) 以降では、Linux と Windows の両方で SQL Server がサポートされています。 Windows ベースの SQL Server デプロイと同様に、SQL Server のデータベースとインスタンスは、Linux 下でも高可用性を備えている必要があります。 この記事では、Pacemaker と Corosync について理解するための基本的な情報と、SQL Server の構成を計画して展開する方法について説明します。

HA アドオン/拡張機能の基本

現在サポートされているすべてのディストリビューションには、Pacemaker クラスタリング スタックに基づく高可用性アドオン/拡張機能が付属しています。 このスタックには、次の 2 つの主要コンポーネントが組み込まれています。Pacemaker と Corosync。 スタックのすべてのコンポーネントは次のとおりです。

• Pacemaker。 クラスター化されたコンピューター間の調整を行うコア クラスタリング コンポーネント。
• Corosync。 クォーラムなどの機能や、失敗したプロセスを再起動する機能などを提供するフレームワークと API のセット。
• libQB。 ログなどの機能を提供します。
• リソース エージェント。 アプリケーションが Pacemaker を統合できるように提供される特定の機能。
• フェンス エージェント。 ノードを分離し、問題が発生した場合にはそれらに対処できるようにするためのスクリプトまたは機能。

このソリューションは、ある意味では Windows を使用したクラスター化構成のデプロイと似ていますが、異なる点も多くあります。 Windows では、クラスタリングの可用性形式 (Windows Server フェールオーバー クラスター (WSFC)) がオペレーティング システムに組み込まれており、WSFC の作成を可能にする機能 (フェールオーバー クラスタリング) は既定で無効になっています。 Windows では、AG と FCI は WSFC の上に構築されており、SQL Server によって提供される特定のリソース DLL により、緊密な統合が共有されます。 この密結合のソリューションは、1 つのベンダーから提供されているからこそ実現できているとも言えます。

Linux では、サポートされている各ディストリビューションで Pacemaker を利用できますが、それぞれのディストリビューションでカスタマイズすることができ、実装とバージョンが少し異なる場合があります。 相違点の一部は、この記事の手順に反映されています。 クラスタリング レイヤーはオープンソースであるため、ディストリビューションに付属している場合でも、Windows 下の WSFC と同じ方法で緊密に統合されてはいません。 そのため、Microsoft では mssql-server-ha を提供してします。これにより、SQL Server と Pacemaker スタックでも、Windows 下の AG や FCI に近いエクスペリエンスを提供できるようになっています (ただし、完全に同じではありません)。

Pacemaker に関する完全なドキュメント (完全な参照情報を含んだ詳細な説明など) については、RHEL と SLES についてそれぞれ次を参照してください。

• RHEL
• SLES

Ubuntu には、可用性に関するガイドはありません。

スタック全体の詳細については、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 の両方のリソースを作成できます。 これは、AG の構成時に FCI または AG リソースに対する SQL Server リソースが表示される WSFC での操作と似ていますが、SQL Server と Pacemaker の統合方法に根本的な違いがあるため、まったく同じではありません。

Pacemaker には、標準リソースとクローン リソースがあります。 クローン リソースとは、すべてのノードで同時に実行されるリソースのことです。 たとえば、負荷分散のために複数のノードで実行される IP アドレスなどがこれに該当します。 FCI 用に作成されたリソースでは、標準リソースが使用されます。これは、FCI は 1 つのノードでしか同時にホストできないためです。

AG を作成する際には、マルチステート リソースと呼ばれる特殊な形式の複製リソースが必要になります。 AG のプライマリ レプリカは 1 つだけですが、AG 自体は、動作元として構成されたすべてのノードで実行され、場合によっては、読み取り専用アクセスなども使用することができます。 これはノードの "ライブ" 使用なので、リソースには "昇格済み" (以前の "マスター") と "未昇格" (以前の "スレーブ") という 2 つの状態の概念があります。 詳細については、「多状態のリソース:複数モードのリソース」を参照してください。

リソース グループ/セット

WSFC のロールのように、Pacemaker クラスターにはリソース グループという概念があります。 リソース グループ (SLES では "セット" と呼ばれます) とは、連携的に機能し、1 つのノードから別のノードに 1 つの単位としてフェールオーバーすることができる、リソースのコレクションです。 リソース グループには、"昇格済み" または "未昇格" として構成されたリソースを含めることはできないため、これらを AG に使うことはできません。 リソース グループは FCI には使用できますが、通常は推奨される構成ではありません。

制約

WSFC には、リソースおよび依存関係のようなものに関するさまざまなパラメーターがあります。これにより、2 つの異なるリソース間の親子関係が WSFC に伝えられます。 依存関係とは、どのリソースを最初にオンラインにする必要があるかを WSFC に指示するルールのことです。

Pacemaker クラスターには、依存関係の概念はありませんが、制約という概念があります。 制約には、コロケーション、場所、順序という 3 つの種類があります。

• コロケーション制約は、2 つのリソースを同じノードで実行する必要があるかどうかを指示するものです。
• 場所制約は、リソースを実行できる (または実行できない) 場所を Pacemaker クラスターに指示するものです。
• 順序制約は、リソースの開始順序を Pacemaker クラスターに指示するものです。

クォーラム、フェンス エージェント、STONITH

Pacemaker のクォーラムは、概念的には WSFC と似ています。 クラスターのクォーラム メカニズムの全体的な目的は、クラスターの稼働状態を維持することです。 Linux ディストリビューション用の WSFC アドオンと HA アドオンには、各ノードがクォーラムに対してカウントされる、投票という概念があります。 投票では、稼働状態のノードが多数を占めるのが理想です。そうでないと、最悪の場合はクラスターがシャット ダウンされます。

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 に変更を加えます。

Pacemaker クラスターを SQL Server 用に計画 する

このセクションでは、Pacemaker クラスターの重要な計画ポイントについて説明します。

Linux ベースの Pacemaker クラスターを SQL Server 用に仮想化する

仮想マシンを使用して Linux ベースの SQL Server デプロイを AG と FCI 用にデプロイする際には、Windows ベースの場合と同じ規則が適用されます。 仮想化された SQL Server デプロイのサポートに関する一連の基本原則は、「ハードウェア仮想化環境で実行されている Microsoft SQL Server 製品のサポート ポリシー」で Microsoft によって公開されています。 Microsoft Hyper-V や VMware の ESXi などの異なるハイパーバイザーでは、プラットフォーム自体の違いにより、さらに異なる変性が生じる場合があります。

仮想化環境で AG と FCI を使用する場合は、指定された Pacemaker クラスターのノードに対して、アンチアフィニティが設定されていることを確認してください。 AG または FCI の構成で高可用性向けに構成された場合、SQL Server をホストしている各 VM は、同じハイパーバイザー ホストで実行されないようにする必要があります。 たとえば、2 ノードの FCI が展開されている場合、特にライブ マイグレーションや vMotion のような機能を使用している場合には、ホストで障害が発生したときに、ノードをホストしている VM のいずれかに対して移行先を確保できるよう、"少なくとも" 3 つのハイパーバイザー ホストを確保する必要があります。

詳細については、以下を参照してください。

• Hyper-V のドキュメント - 高可用性のためのゲスト クラスタリングの使用
• ホワイトペーパー (Windows ベースのデプロイ向けに記述されていますが、ほとんどの概念が適用されます) - VMware vSphere を使用したミッション クリティカルな高可用性 SQL Server デプロイの計画

ネットワーク

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 をインスタンスとして参加させる方法です。

• クラスターの種類が None の AG。 詳細については、Windows の可用性グループに関するドキュメントを参照してください。
• 分散型 AG。これは、2 つの異なる AG を独自の可用性グループとして構成することができる、特別な種類の可用性グループです。 分散 AG の詳細については、ドキュメント「分散型可用性グループ」を参照してください。

他の Linux ディストリビューション

Linux では、Pacemaker クラスターのすべてのノードが同じディストリビューション上に存在している必要があります。 たとえば、RHEL ノードは、SLES ノードを持つ Pacemaker クラスターの一部にすることはできません。 この問題の主な理由は前に説明したとおりで、ディストリビューションのバージョンと機能が異なることで、正常に機能しない可能性があるためです。 ディストリビューションの混合については、WSFC と Linux の混合と同じ条件が適用されます。つまり、None または 分散型 AG を使用してください。

関連するコンテンツ

• SQL Server on Linux 用の Pacemaker クラスターをデプロイする
• SQL Server 可用性グループ用の Pacemaker クラスターを構成する