SQL Server 2017 on Linux　　　　　　　　Pacemakerを利用した高可用性環境の構築

SQL Server 2017 on Linux

Pacemaker を利用した高可用性環境の構築

免責事項

このドキュメントに記載されている情報 (URL 等のインターネット Web サイトに関する情報を含む) は、将来予告なしに変更 することがあります。別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、 ドメイン名、電子メール アドレス、ロゴ、人物、場所、出来事などの名称は架空のものです。実在する商品名、団体名、個人 名などとは一切関係ありません。お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願いま す。これらの資料は、米国 Microsoft Corporation の書面による許諾を受けることなくこれらの資料を使用または配布するこ とは、禁じられています。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、 その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録な ど、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではあり ません。 マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権 を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商 標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

Copyright © 2018 Microsoft Corporation. All rights reserved.

Microsoft、Active Directory、Windows、Windows NT、および Windows Server は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

目次

免責事項 ... ii 目次 ... iii 1 はじめに ... 1 1.1 本ガイドの目的 ... 1 1.2 コマンド実行例について ... 1 2 Pacemaker を利用した SQL Server 高可用性ソリューションの概要 ... 2 2.1 Linux プラットフォームにおける高可用性ソリューションの選択肢 ... 2 2.1.1 Pacemaker とは ... 3 2.1.2 Pacemaker の概念と用語 ... 4 2.2 Always On フェールオーバー クラスター インスタンス (FCI) 概要 ... 7 2.2.1 Always On フェールオーバー クラスター インスタンス (FCI) とは... 7 2.3 Always On 可用性グループ (AG) 概要 ... 9 2.3.1 Always On 可用性グループ (AG) とは ... 9 3 Pacemaker を利用した SQL Server 高可用性ソリューションの構成 ... 11 3.1 Pacemaker を利用したフェールオーバー クラスター インスタンスの構成手順 ... 11 3.1.1 前提条件 ... 11 3.1.2 SQL Server のインストールと構成 ... 11 3.1.3 共有記憶域の構成 ... 13 3.1.4 Pacemaker のインストールと構成 ... 17 3.1.5 Pacemaker クラスターの作成 ... 19

3.2.3 Pacemaker のインストールと構成 ... 31 3.2.4 可用性グループ リスナーの構成 ... 36 4 Pacemaker を利用した SQL Server 高可用性ソリューションの運用 ... 37 4.1 OS 情報 ... 37 4.1.1 messages / syslog ... 37 4.1.2 インストール時のログ ... 37 4.1.3 カーネルバージョンとリリースバージョン ... 37 4.2 SQL Server 情報 ... 37 4.2.1 SQL Server のログ情報 ... 37 4.3 Pacemaker の基本的な操作 ... 38 4.3.1 クラスターの状態確認 ... 38 4.3.2 クラスターの起動 ... 38 4.3.3 クラスターの停止 ... 38 4.3.4 クラスターの再起動 ... 39 4.3.5 クラスターのログ確認 ... 39 4.4 Pacemaker を利用したフェールオーバー クラスター インスタンスの運用 ... 40 4.4.1 フェールオーバー クラスター インスタンスの自動フェールオーバー ... 40 4.4.2 フェールオーバー クラスター インスタンスの手動フェールオーバー ...41 4.5 Pacemaker を利用した可用性グループの運用 ... 42 4.5.1 可用性グループの自動フェールオーバー ... 42 4.5.2 可用性グループの手動フェールオーバー ... 45

1

はじめに

1.1

本ガイドの目的

Microsoft SQL Server といえば、Windows プラットフォームにのみ対応しているというイメージが強いリレーショナル データベー ス マネジメント システム (RDBMS）ですが、SQL Server 2017 からは Linux プラットフォームや Docker コンテナーに対応 し、マルチプラットフォームで動作するように進化を遂げました。 商用環境で RDBMS を利用する場合、高可用性を検討・構築することは避けては通れません。本ガイドは、Linux 環境でも 安心して SQL Server 2017 を運用できることをご認識いただくことを目的として、高可用性ソリューションの選択肢と、高可用 性ソリューションの具体的な構築手順についてご案内します。 本ガイドでは、以下の環境で SQL Server 2017 を構築した際の手順を元に記載しています。また、実際に構築される際は、 SQL Server の CU は最新のものを適用してから構築されることを推奨いたします。

OS Version: Red Hat Enterprise Linux 7.4 SQL Server Version: SQL Server 2017 CU9

1.2

コマンド実行例について

本ガイドでは、実行するコマンドについて記載しています。

以下の表記は Linux ターミナル上でのコマンドを示します。

コマンド

以下の表記は SQL Server ツール(SQLCMD, SQL Server Management Studio など)上でのコマンドを示します。

コマンド

以下の表記はコマンドの具体的な実行例を示します。

2

Pacemaker を利用した SQL Server 高可用性ソリューションの概要

2.1

Linux プラットフォームにおける高可用性ソリューションの選択肢

Linux プラットフォームで稼働する SQL Server 2017 では、Windows プラットフォームで稼働する場合と同様に、Always On 可用性グループや Always On フェールオーバー クラスター インスタンスを構成することが可能です。しかし、クラスタリングを行う ソフトウェアの部分が、Windows プラットフォームの場合と異なります。Linux プラットフォームで Always On ソリューションを構 築する場合はクラスタリング ソフトウェアとして Corosync を搭載した Pacemaker を使用します。

情報

各パートナー企業からも Linux プラットフォームで動作する SQL Server 2017 高可用性ソリューションが提供されていま す。パートナーとソリューションの一覧については以下をご参照ください。 SQL Server の高可用性とディザスター リカバリーのパートナー https://docs.microsoft.com/ja-jp/sql/sql-server/partner-hadr-sql-server?view=sql-server-2017

以下は Linux プラットフォーム (左) と Windows プラットフォーム (右) の Always On 構成の違いを示したものです。

Pacemaker を利用した Always On 構成は、Windows プラットフォームで構成する場合と比較して、概念的には類似して いますが、多くの点で異なります。 Windows では、Windows Server フェールオーバークラスター (WSFC）と呼ばれるクラスタ ーソフトウェアが OS に組み込まれており、WSFC と SQL Server の Always On 構成は緊密に統合されます。

2.1.1 Pacemaker とは

Pacemaker はオープン ソース ソフトウェア (OSS) として開発されている、HA クラスターソフトです。

内部のコンポーネントとしては、リソース制御部分の Pacemaker と、クラスター制御部分の Corosync に分けられます。 Pacemaker のプロセスである lrmd が LSB (Linux Standard Base) や OCF (Open Clustering Framework) に準拠した リソース エージェントにより各クラスター リソースを起動／監視／停止といった制御を行います。また、Corosync により、クォーラ ムの管理やプロセスの再起動などの制御が行われます。 SQL Server 2017 の OS の要件において動作環境として認定されているディストリビューションには、Pacemaker のクラスタリ ング スタックに基づく高可用性のアドオンもしくはエクステンションが用意されています。このスタックには、Pacemaker と Corosync の 2 つの主要コンポーネントが組み込まれています。OS 部分やクラスター部分のマイクロソフトからのサポートはベス ト エフォートとなるため、サポート体制についてはご利用になるディストリビューションのアドオンやエクステンションをご確認ください。

 Red Hat Enterprise Linux の場合

 Red Hat Enterprise Linux (RHEL) では、クラスタリング層は Red Hat Enterprise Linux HA アドオンに基づ いています。Red Hat HA アドオンおよびドキュメントにアクセスするためには、サブスクリプションが必要です。詳細 については以下をご参照ください。

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/

 SUSE Linux Enterprise の場合

 SUSE Linux Enterprise (SLES) では、クラスタリング層は SUSE Linux Enterprise High Availability

Extension (HAE）に基づいています。詳細については以下をご参照ください。

https://www.suse.com/ja-jp/products/highavailability/

注意

Linux プラットフォームで動作する SQL Server の高可用性ソリューションはフェールオーバー クラスター インスタンス、可 用性グループ、ログ配布の 3 つがあります。 (パートナー企業による高可用性ソリューションを除く)

Azure Virtual Machines 上でのフェールオーバー クラスター インスタンスと可用性グループを利用した高可用性ソリュー ションを構築する場合は Azure 上での高可用性アドオンの利用をサポートしているディストリビューションを利用する必要 があります。例えば、Red Hat Enterprise Linux の場合は 7.4 以降でサポートされています。詳細については各ディスト リビューションのアドオンやエクステンションをご確認ください。

Support Policies for RHEL High Availability Clusters - Microsoft Azure Virtual Machines as Cluster Members

2.1.2 Pacemaker の概念と用語 2.1.2.1 ノード ノードは、クラスターに参加しているサーバーを表します。 Pacemaker は最大 16 のノードをサポートします。このため、Linux 上の フェールオーバー クラスター インスタンスでのノードの最大数は 16 となります。(インスタンスは 1 つのみ(2.2.1 にて記載)) また、可用性グループでは 1 つのプライマリ レプリカと最大 8 つまでのセカンダリ レプリカをサポートするため、ノードの最大数は 9 となります。 2.1.2.2 リソース リソースとは、ディスクや IP アドレスなど、クラスターのコンテキストで実行される特定の機能です。Pacemaker には標準 (Primitive) リソース、クローン リソース、Master/Slave リソースの 3 種類があります。  標準 (Primitive) リソース どこか一つのノードで動作させ、故障時にフェールオーバーさせたいリソースに使用します。  クローン リソース すべてのノードで同時に動作させたいリソースに使用します。ロードバランシングの目的で複数のノード上で動作する IP アドレスが クローン リソースの一例です。  Master/Slave リソース クローン リソースの進化系であり、複数のノードで動作させ、且つ Master/Slave という親子関係のあるリソースに使用します。

2.1.2.3 リソース グループ Pacemaker クラスターにはリソース グループの概念があります。リソース グループは、一緒に機能し、単一のユニットとしてノード 間でフェールオーバーできる標準リソースの集合です。同じグループとなった標準リソースは必ず同じノードで定義された順番に起動 /停止します。 このリソース グループの設定をフェールオーバー クラスター インスタンスに使用することは可能ですが、通常は推奨される構成では ありません。また、リソース グループに Master/Slave リソースを含めることはできないため、可用性グループには使用できません。 2.1.2.4 制約 Pacemaker のクラスターには依存関係の概念はありませんが、制約があります。制約ではリソースが起動する際の条件を設定 します。コロケーション、位置、順序の 3 種類があります。  コロケーション (colocation)  同じノード上で 2 つのリソースを一緒に起動する必要があるかどうかを強制します  位置 (location)  リソースが実行できる（またはできない）ノードを Pacemaker クラスターに指示します  順序  リソースを開始する順序を Pacemaker クラスターに指示します 制約にはスコア値という概念があります。どのノードでリソースを起動するのか決定するための優先度を示す値です。ノードの起

2.1.2.5 クォーラム、フェンスエージェント、STONITH クラスターのクォーラム メカニズムの目的は、クラスターが確実に稼働していることを確認することです。WSFC と Linux ディストリ ビューションの HA アドオンにはどちらも Vote の概念があり、各ノードはクォーラムにカウントされ、Vote の過半数が求められま す。最悪の場合、クラスターは停止します。 Pacemaker の場合、クォーラムで動作する監視リソースはありません。 WSFC は、参加しているノードの状態を監視し、問題が 発生したときに利用できないノードの隔離などの機能が提供されますが、Linux では、この機能はフェンス エージェントによって提 供されます。通常、フェールオーバー発生時などに行われるリソースの停止はリソースエージェントによって行われますが、これが何ら かの理由で失敗してしまう場合があります。このままだとフェールオーバーが失敗してしまいますが、停止に失敗したノードの電源を 強制的に落とすことで、フェールオーバーを継続し、サービスを維持することができます。この動作を一般的にフェンシングと呼びま す。Pacemaker クラスターの場合は STONITH の機能によりフェンシングが提供されます。Pacemaker クラスターがサポートさ れる構成においても、STONITH が有効になっていることが必要です。 2.1.2.6 ネットワーク WSFC とは異なり、Pacemaker クラスター自体に専用名または専用 IP アドレスを必要としません。可用性グループおよび、フ ェールオーバー クラスター インスタンスには、IP アドレスが必要です。また、WSFC では許可されていませんが、Pacemaker は 同じサブネット上の複数の IP アドレスを許可しています。 2.1.2.7 相互運用性 現在、WSFC と Pacemaker のクラスターを連携させる直接的な方法はありませんが、以下の相互運用性ソリューションが用 意されており、間接的に連携させることが可能です。  クラスターレスの可用性グループ  分散型可用性グループ (2 つの異なる可用性グループを独自の可用性グループとして設定) また、Linux では、Pacemaker クラスターのすべてのノードは同じディストリビューションである必要があります。ディストリビューショ ンを混在させる場合は上記の相互運用性ソリューションを検討してください。

2.2

Always On フェールオーバー クラスター インスタンス (FCI) 概要

2.2.1 Always On フェールオーバー クラスター インスタンス (FCI) とは

Always On フェールオーバー クラスター インスタンス (FCI) は SQL Server インスタンス全体に対して可用性を提供するソリュ ーションです。ネットワーク上では 1 台のコンピューターで実行されている SQL Server のインスタンスのように見えますが、現在の ノードが使用できなくなった場合には、別のノードにフェールオーバーする機能を備えています。データベース、SQL Server エージェン ト ジョブ、リンクサーバーなどを含むインスタンス内のすべてが、稼働中のサーバーで問題が発生した場合に別のサーバーに移動し ます。 FCI には共有ストレージが必要です。 FCI のリソースは、1 つのノードでのみ実行および所有されます。 以下の図では、クラスタ ーの最初のノードが FCI を所有しています。これは、ストレージに実線で示されている共有ストレージ リソースを所有していることを 意味します。 フェールオーバー後は、所有権は次の図にように変更されます。 FCI ではデータ損失はありませんが、データのコピーがないため、基盤となる共有ストレージは単一障害点となるリスクがあります。

FCI は、クラスター内のどのノードがホストしているかを抽象化し、常に同じ名前を保持します。アプリケーションやユーザーはノード に直接接続することはなく、FCI に割り当てられた固有の名前を用いて接続します。

以下は、Windows プラットフォームと Linux プラットフォームの FCI で異なるポイントです。

 Windows Server では、FCI は SQL Server のインストール プロセスの一部ですが、Linux 上の FCI の場合は、 SQL Server のインストール後にクラスターを構成します。

 Linux の場合はサーバーごとに SQL Server を 1 つしかインストールできません。すべての FCI が既定のインスタンス になり、名前付きインスタンスという概念はありません。このため、Linux 上で動作する FCI は 1 つのインスタンスの みとなります。(Windows Server の場合は、WSFC あたり最大 25 個の FCI をサポートします。)

 Linux の FCI で使用される共通の名前は DNS で定義され、FCI 用に作成されたリソースと同じである必要があ ります。

2.3

Always On 可用性グループ (AG) 概要

2.3.1 Always On 可用性グループ (AG) とは Always On 可用性グループ (AG) では、複数の可用性レプリカよりホストされ、ユーザー データベースの保護を実現します。可 用性レプリカには、プライマリ レプリカとセカンダリ レプリカの 2 種類のレプリカがあり、プライマリ レプリカとセカンダリ レプリカ 間でユーザー データベースのデータの同期が行われます。 プライマリ レプリカで発生するトランザクションのトランザクション ログ レコードは、即時にセカンダリ レプリカに送信されるため、 リカバリポイントおよびリカバリー時間の目標が短い場合には、可用性グループを利用することが推奨されます。 可用性レプリカ間のデータベースの同期には、同期コミットモードと非同期コミットモードの 2 種類の同期モードがあります。 Enterprise Edition では、最大 3 つの可用性レプリカ (プライマリ レプリカを含む) を同期コミットモードとして使用できます。 可用性グループには、プライマリ レプリカに読み取り/書き込みが可能なデータベースがあり、セカンダリ レプリカにはプライマリ レ プリカのデータベースのコピーが配置されます。 セカンダリ レプリカがホストしているデータベースのテーブルをユーザーが更新することはできませんが、セカンダリ レプリカを読み取 り専用に構成することにより、読み取りワークロードをオフロードするよう構成することは可能です。 また、Always On 可用性グループはインスタンス レベルでの保護は行われていないため、同期の対象に含まれていない、インス タンスレベルのログイン、リンクサーバー構成設定、SQL Server エージェントジョブなどは、各セカンダリ レプリカに対して手動で 同期を行う必要があります。 可用性グループには、リスナーと呼ばれる別のコンポーネントもあります。リスナーにより、アプリケーションとエンド ユーザーは、プライ マリ レプリカがどのノードでホストされていても透過的に接続することができます。

Standard Edition と Enterprise Edition では、利用可能なレプリカ数やセカンダリ レプリカの活用可否について違いがあり ます。 基本的な可用性グループと呼ばれる Standard Edition の可用性グループは、可用性グループ内のデータベースが 1 つのみの 2 つのレプリカ (1 つはプライマリ、1 つはセカンダリ）をサポートします。 Enterprise Edition では、1 つの可用性グループに複数のデータベースを構成できるだけでなく、最大 9 つのレプリカ (1 つのプラ イマリ、8 つのセカンダリ）を持つことができます。 また、Enterprise Edition には、読み取り可能なセカンダリ レプリカ、セカン ダリ レプリカからのバックアップを作成する機能など、その他のオプションの利点があります。 Windows プラットフォームと Linux プラットフォームの場合で、以下の点において可用性グループの動作が異なります。  可用性グループのすべてのフェールオーバー (手動または自動）は Linux のクラスターを介して実施する必要がありま す。(強制フェールオーバーやクラスターレスの場合を除く)  Linux プラットフォームでの可用性グループは、3 台以上のレプリカで構成することが推奨されています。 (自動フェール オーバーを有効にするためには 3 台以上の構成が必要であるため)

 Linux では、各リスナーで使用される共通名は DNS に定義されている必要があります。(Windows Server のよう にクラスターでは定義されません)

3

Pacemaker を利用した SQL Server 高可用性ソリューションの構成

3.1

Pacemaker を利用したフェールオーバー クラスター インスタンスの構成手順

3.1.1 前提条件

 2 つのノードのクラスターを配置する 2 台のコンピューターと共有記憶域が必要です。

 有効な HA アドオンのサブスクリプションを持った Red Hat Enterprise Linux を使用します。  実稼働環境では STONITH を有効にして、フェンシング操作デバイスを構成します。 3.1.2 SQL Server のインストールと構成 1. 両方のノード上に SQL Server をインストールし、セットアップします。 詳細については、以下を参照してください。 Linux 上の SQL Server のインストールのガイダンス https://docs.microsoft.com/ja-jp/sql/linux/sql-server-linux-setup?view=sql-server-linux-2017 2. 構成のために、1 つのノードをプライマリとして指定し、もう片方をセカンダリとして指定します。 3. セカンダリ ノードで SQL Server を停止し無効にします。次の例では、SQL Server を停止して無効にします。

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

4. プライマリノードで、Pacemaker 用の SQL Server ログインを作成し、sp_server_diagnostics を実行するための権限を 付与します。 Pacemaker はこのアカウントを使用して、どのノードが SQL Server を実行しているかを確認します。SQL Server の master データベースに sa アカウントを使用して接続し、次のスクリプトを実行します。

USE [master] GO

CREATE LOGIN [<作成するログイン名>] with PASSWORD= N'<ログインのパスワード>' ALTER SERVER ROLE [sysadmin] ADD MEMBER [<作成するログイン名>]

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

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

6. 各クラスター ノードの hosts ファイルを構成します。hosts ファイルには、すべてのクラスター ノードの名前と IP アドレスを 含める必要があります。 各ノードの IP アドレスを確認してください。

次のスクリプトは、現在のノードの IP アドレスを示します。

sudo ip addr show

以下の部分から IP アドレスを確認します。

各ノードで、コンピューター名を /etc/hosts に追加します。

sudo vi /etc/hosts

以下の例では、/etc/hosts に sqlfcivm1 と sqlfcivm2 の 2 つのノードを追加しています。

127.0.0.1 localhost localhost4 localhost4.localdomain4 ::1 localhost localhost6 localhost6.localdomain6 10.0.1.4 sqlfcivm1

3.1.3 共有記憶域の構成 FCI で使用する共有記憶域を構成します。共有記憶域に使用できる形式は以下の通りです。  iSCSI  NFS  SMB 上記のいずれかの形式で共有記憶域を構成し、FCI の各ノードからマウントして使用します。本ガイドでは、NFS を使用した 共有記憶域の構成手順について示します。 3.1.3.1 NFS サーバーでの操作 1. NFS ボリュームを用意しマウントします。 2. nfs-utils パッケージをインストールします。nfs-utils パッケージは NFS サーバーとユーティリティが同梱されているパッケージで す。

sudo yum -y install nfs-utils

3. rpcbind デーモンを有効にして開始します。rpcbind ユーティリティは RPC サービスをポートにマップします。

sudo systemctl enable rpcbind && sudo systemctl start rpcbind

4. nfs-server デーモンを有効にして開始します。

sudo systemctl enable nfs-server && sudo systemctl start nfs-server

5. /etc/exports を編集して、共有するディレクトリをエクスポートします。必要な共有フォルダーごとに 1 行を必要とします。 以下に例を示します。

6. 共有をエクスポートします。

sudo exportfs -rav

7. パスがエクスポートされていることを確認するため、NFS サーバーから実行します。

sudo showmount -e

8. SELinux が有効であり、enforcing モードで動作している場合は、SELinux で例外を追加します。

sudo setsebool -P nfs_export_all_rw 1

9. サーバーのファイア ウォールを開きます。

sudo firewall-cmd --permanent --add-service=nfs sudo firewall-cmd --permanent --add-service=mountd sudo firewall-cmd --permanent --add-service=rpc-bind sudo firewall-cmd --reload

3.1.3.2 すべてのクラスター ノードでの操作

1. nfs-utils をインストールします。

sudo yum -y install nfs-utils

2. クライアントのファイアウォールを開きます。

sudo firewall-cmd --permanent --add-service=nfs sudo firewall-cmd --permanent --add-service=mountd sudo firewall-cmd --permanent --add-service=rpc-bind sudo firewall-cmd --reload

3. クライアント コンピューターで、NFS 共有を表示できることを確認します。

sudo showmount -e <NFS サーバーの IP>

以下のように表示されます。 4. すべてのクラスター ノードでこれらの手順を繰り返します。 3.1.3.3 共有記憶域のデータベース ファイル ディレクトリへのマウント 1. プライマリ ノード上で、一時的な場所にデータベース ファイルを保存します。次のスクリプトでは、新しい一時ディレクトリを作 成し、データベース ファイルを新しいディレクトリにコピーして、古いデータベース ファイルを削除します。 sudo su mssql mkdir /var/opt/mssql/tmp cp /var/opt/mssql/data/* /var/opt/mssql/tmp rm /var/opt/mssql/data/* exit 2. すべてのクラスター ノードで /etc/fstab ファイルへ以下を追加します。 <NFS サーバーの IP>:<共有ストレージのパス> <データベース ファイル ディレクトリのパス> nfs timeo=14,intr 以下は編集の例を示しています。

3. 以下のコマンドを実行して、マウントされたパスを更新します。

sudo mount -a

4. 1. で保存したデータベースとログ ファイルを新しくマウントされた共有ストレージにコピーします。この作業は、プライマリ ノード 上でのみ行います。SQL Server はローカル ユーザー mssql として実行されるため、mssql ローカル ユーザーに読み取り/ 書き込み権限を付与してください。

sudo chown mssql /var/opt/mssql/data sudo chgrp mssql /var/opt/mssql/data sudo su mssql cp /var/opt/mssql/tmp/* /var/opt/mssql/data/ rm /var/opt/mssql/tmp/* exit 5. 新しいファイル パスで SQL Server が正常に開始するかを各ノードで検証します。次のコマンドは、SQL Server を起動し、 状態を確認し、SQL Server を停止します。

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

3.1.4 Pacemaker のインストールと構成

1. 両方のクラスター ノードで、Pacemaker がログインするための SQL Server のユーザー名とパスワードを格納するファイルを 作成します。

sudo touch /var/opt/mssql/secrets/passwd

echo '<3.1.2 で作成したログイン名>' | sudo tee -a /var/opt/mssql/secrets/passwd echo '<3.1.2 で作成したログインのパスワード>' | sudo tee -a /var/opt/mssql/secrets/passwd sudo chown root:root /var/opt/mssql/secrets/passwd

sudo chmod 600 /var/opt/mssql/secrets/passwd

2. 両方のクラスター ノードで、Pacemaker ファイアウォールのポートを開きます。

sudo firewall-cmd --permanent --add-service=high-availability sudo firewall-cmd --reload

情報

組み込みの高可用性構成が備わっていない別のファイアウォールを使用する場合は、Pacemaker 用に次のポートを開 き、クラスター内の他のノードと通信できるようにする必要があります •TCP: ポート 2224、3121、21064 •UDP: ポート 5405 Linux プラットフォームで動作する SQL Server で通信が必要となるポートについては以下をご参照ください。 SQL Server availability basics for Linux deployments - Configure the firewall

https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-ha-basics?view=sql-server-linux-2017#common-tasks-for-availability-configurations-of-includessnoversion-mdincludesssnoversion-mdmd-on-linux

3. 各ノードに高可用性アドオンをインストールするために、次のコマンドを使用してサーバーを登録します。 有効なユーザー名とパ スワードを入力します。

sudo subscription-manager register

4. 登録に使用可能なプールの一覧を表示します。

sudo subscription-manager list --available

5. 次のコマンドを実行し、高可用性アドオンにアタッチします。

7. 各ノードに Pacemaker パッケージをインストールします。

sudo yum install pacemaker pcs fence-agents-all resource-agents

8. Pacemaker と Corosync のパッケージをインストールしたときに作成された既定のユーザー用のパスワードを設定します。 両方のノードで同じパスワードを使用します。

sudo passwd hacluster

9. pcsd デーモンと pacemaker デーモンを有効にし、起動します。 これにより、再起動後に自動的にクラスターが起動します。 両方のノードで、次のコマンドを実行します。

sudo systemctl enable pcsd sudo systemctl start pcsd sudo systemctl enable pacemaker

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

3.1.5 Pacemaker クラスターの作成

1. いずれかのノードで、クラスターを作成します。

sudo pcs cluster auth <ノード名 1 ノード名 2 …> -u hacluster

sudo pcs cluster setup --name <クラスター名> <ノード名 1 ノード名 2 …> sudo pcs cluster start --all

フェンシング エージェントを利用しない場合は、フェンシングを無効にする必要があります。(これは実稼働環境では推奨されま せん)

sudo pcs property set stonith-enabled=false sudo pcs property set start-failure-is-fatal=false

2. SQL Server、ファイル システム、仮想 IP リソースに対してクラスター リソースを構成し、クラスターに構成をプッシュします。 次の情報が必要です。  SQL Server リソース名: SQL Server のクラスター化リソースの名前  IP リソース名: 仮想 IP アドレス リソースの名前  IP アドレス: SQL Server のクラスター化されたインスタンスに接続するクライアントが使用する IP アドレス  ファイル システム リソース名: ファイル システム リソースの名前  デバイス:、NFS 共有のパス  デバイス: 共有にマウントしているローカル パス  _{fstype: ファイル共有の種類 (nfs など)} クラスター化されたサービスを構成および開始するために、次のスクリプトをいずれかのノード上で実行します。

sudo pcs cluster cib cfg

sudo pcs -f cfg resource create <SQL Server リソース名> ocf:mssql:fci

sudo pcs -f cfg resource create <IP リソース名> ocf:heartbeat:IPaddr2 ip=<IP アドレス>

sudo pcs -f cfg resource create <ファイル システム リソース名> Filesystem device=<NFS 共有のパス> directory=<共有に マウントしているローカル パス> fstype=<ファイル共有の種類>

sudo pcs -f cfg constraint colocation add <IP リソース名> <SQL Server リソース名>

sudo pcs -f cfg constraint colocation add <ファイル システム リソース名> <SQL Server リソース名> sudo pcs cluster cib-push cfg

次の例では、mssqlha という名前の SQL Server のクラスター化されたリソース、および IP アドレスが 10.0.0.99 の Floating IP リソースを作成します。 また、ファイル システム リソースを作成し、すべてのリソースが SQL リソースと同じノード に配置されるように制約を追加します。

sudo pcs cluster cib cfg

sudo pcs -f cfg resource create mssqlha ocf:mssql:fci

sudo pcs -f cfg resource create virtualip ocf:heartbeat:IPaddr2 ip=10.0.1.10

sudo pcs -f cfg resource create fs Filesystem device=10.0.1.6:/shared directory=/var/opt/mssql/data fstype=nfs sudo pcs -f cfg constraint colocation add virtualip mssqlha

sudo pcs -f cfg constraint colocation add fs mssqlha sudo pcs cluster cib-push cfg

構成がプッシュされると、SQL Server は 1 つのノードで開始されます。

この段階で、フェールオーバー クラスター インスタンスが構成されます。クラスターの状態を確認するには sudo pcs status コ マンドを実行します。

上記の例の①の部分より、sqlfcivm1 ノード、sqlfcivm2 ノードの 2 ノードが構成され、全てオンラインになっていることがわかり ます。また、mssqlha リソース、virtualip リソース、fs リソースの 3 リソースが構成され、全て sqlfcivm1 ノードで開始済である ことが確認できます。②の部分より、corosync、pacemaker、pcsd が全て動作(active)しており、pacemaker と pcsd が 有効化(enabled)されていることが確認できます。corosync は pacemaker が起動されると付随的に起動されるため、動作 していれば無効(disabled)の状態で問題ありません。

pacemaker デーモンが有効になっていない場合、OS 起動時に自動でクラスターが起動されません。自動起動を設定する場合 は pacemaker を有効化します。

sudo systemctl enable pacemaker

pcsd デーモンが起動していない場合、pcs コマンドが利用できません。pcs コマンドが利用できない場合は pcsd の有効化と 起動を行います。

①

3.2

Pacemaker を利用した可用性グループの構成手順

3.2.1 前提条件

 可用性を高めるためには Linux 上の可用性グループでは 3 台以上のノードが必要です。  _{有効な HA アドオンのサブスクリプションを持った Red Hat Enterprise Linux を使用します。}  実稼働環境では STONITH を有効にして、フェンシング操作デバイスを構成します。 3.2.2 SQL Server のインストールと構成 1. 各ノード上に SQL Server をインストールし、セットアップします。 詳細については、以下をご参照ください。 Linux 上の SQL Server のインストールのガイダンス https://docs.microsoft.com/ja-jp/sql/linux/sql-server-linux-setup?view=sql-server-linux-2017 2. 各クラスター ノードの hosts ファイルを構成します。hosts ファイルには、すべてのクラスター ノードの名前と IP アドレスを 含める必要があります。 各ノードの IP アドレスを確認してください。次のスクリプトは、現在のノードの IP アドレスを示しま す。

sudo ip addr show

3. 各ノードでコンピューター名を /etc/hosts に追加します。

sudo vi /etc/hosts

以下の例では、/etc/hosts に sqlagvm1、sqlagvm2、sqlagvm3 の 3 つのノードを追加しています。

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.0.2.4 sqlagvm1

10.0.2.5 sqlagvm2 10.0.2.6 sqlagvm3

4. SQL Server インスタンスをホストする各ノードで Always On 可用性グループを有効にし、mssql-server を再起動します。

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1 sudo systemctl restart mssql-server

5. SQL Server インスタンスをホストするすべてのノードで可用性グループのエンドポイント、証明書、ログイン、データベース ユー ザーを作成します。本ガイドでは 3 ノード分の作成例を以下に示します。

[ノード 1 での作業]

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<マスターキーのパスワード>'; CREATE CERTIFICATE Node1_Cert WITH SUBJECT = 'Node1 AG Certificate';

BACKUP CERTIFICATE Node1_Cert TO FILE = '/var/opt/mssql/data/Node1_Cert.cer'; CREATE ENDPOINT AGEP

STATE = STARTED AS TCP (

LISTENER_PORT = 5022, LISTENER_IP = ALL) FOR DATABASE_MIRRORING (

AUTHENTICATION = CERTIFICATE Node1_Cert, ROLE = ALL);

CREATE LOGIN Node2_Login WITH PASSWORD = '<ログインのパスワード>'; CREATE USER Node2_User FOR LOGIN Node2_Login;

CREATE LOGIN Node3_Login WITH PASSWORD = '<ログインのパスワード>'; CREATE USER Node3_User FOR LOGIN Node3_Login;

[ノード 2 での作業]

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<マスターキーのパスワード>'; CREATE CERTIFICATE Node2_Cert WITH SUBJECT = 'Node2 AG Certificate';

BACKUP CERTIFICATE Node2_Cert TO FILE = '/var/opt/mssql/data/Node2_Cert.cer'; CREATE ENDPOINT AGEP

STATE = STARTED AS TCP (

LISTENER_PORT = 5022, LISTENER_IP = ALL) FOR DATABASE_MIRRORING (

AUTHENTICATION = CERTIFICATE Node2_Cert, ROLE = ALL);

CREATE LOGIN Node1_Login WITH PASSWORD = '<ログインのパスワード>'; CREATE USER Node1_User FOR LOGIN Node1_Login;

CREATE LOGIN Node3_Login WITH PASSWORD = '<ログインのパスワード>'; CREATE USER Node3_User FOR LOGIN Node3_Login;

sudo scp /var/opt/mssql/data/Node2_Cert.* <ユーザー名>@<ノード 1 名>:/tmp sudo scp /var/opt/mssql/data/Node2_Cert.* <ユーザー名>@<ノード 3 名>:/tmp

[ノード 3 での作業]

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<マスターキーのパスワード>'; CREATE CERTIFICATE Node3_Cert WITH SUBJECT = 'Node3 AG Certificate';

BACKUP CERTIFICATE Node3_Cert TO FILE = '/var/opt/mssql/data/Node3_Cert.cer'; CREATE ENDPOINT AGEP

STATE = STARTED AS TCP (

LISTENER_PORT = 5022, LISTENER_IP = ALL) FOR DATABASE_MIRRORING (

AUTHENTICATION = CERTIFICATE Node3_Cert, ROLE = ALL);

CREATE LOGIN Node1_Login WITH PASSWORD = '<ログインのパスワード>'; CREATE USER Node1_User FOR LOGIN Node1_Login;

6. 5. で各ノードにコピーした cer ファイルを /var/opt/mssql/data 配下に移動し、mssql ユーザーに cer ファイルにアクセ スするためのアクセス許可を与えます。全てのノードで以下の作業を実施します。

sudo su cd /tmp

mv *.cer /var/opt/mssql/data

sudo chown mssql:mssql /var/opt/mssql/data/*.cer sudo ls -l /var/opt/mssql/data/

mssql ユーザーにアクセス許可があることを確認します。

7. Linux の SQL Server サービスは、証明書を使用してエンドポイント間の通信を認証します。各ノードの cer ファイルから 証明書を作成し、エンドポイントに対する接続許可を与えます。本ガイドでは 3 ノード分の作成例を以下に示します。 [ノード 1 での作業]

CREATE CERTIFICATE Node2_Cert AUTHORIZATION Node2_User

FROM FILE = '/var/opt/mssql/data/Node2_Cert.cer'; CREATE CERTIFICATE Node3_Cert

AUTHORIZATION Node3_User

FROM FILE = '/var/opt/mssql/data/Node3_Cert.cer'; GRANT CONNECT ON ENDPOINT::AGEP TO Node2_Login; GRANT CONNECT ON ENDPOINT::AGEP TO Node3_Login;

[ノード 2 での作業]

CREATE CERTIFICATE Node1_Cert AUTHORIZATION Node1_User

FROM FILE = '/var/opt/mssql/data/Node1_Cert.cer'; CREATE CERTIFICATE Node3_Cert

AUTHORIZATION Node3_User

FROM FILE = '/var/opt/mssql/data/Node3_Cert.cer'; GRANT CONNECT ON ENDPOINT::AGEP TO Node1_Login; GRANT CONNECT ON ENDPOINT::AGEP TO Node3_Login;

[ノード 3 での作業]

CREATE CERTIFICATE Node1_Cert AUTHORIZATION Node1_User

FROM FILE = '/var/opt/mssql/data/Node1_Cert.cer'; CREATE CERTIFICATE Node2_Cert

AUTHORIZATION Node2_User

FROM FILE = '/var/opt/mssql/data/Node2_Cert.cer'; GRANT CONNECT ON ENDPOINT::AGEP TO Node1_Login; GRANT CONNECT ON ENDPOINT::AGEP TO Node2_Login;

8. SQL Server インスタンスで利用するポート番号と、エンドポイントで指定したポート番号について、ファイアウォールを開きます。

sudo firewall-cmd --zone=public --add-port=<10.で指定したポート番号>/tcp --permanent sudo firewall-cmd --zone=public --add-port=1433/tcp --permanent

sudo firewall-cmd --reload

9. 自動フェールオーバーを保証する高可用性構成の場合、可用性グループには少なくとも 3 つのレプリカが必要で、以下のい ずれかの構成が必要です。

 3 つの同期レプリカ

10. 可用性グループを作成します。プライマリ レプリカをホストする SQL Server インスタンスで次のいずれかの Transact-SQL を実行します。  3 つの同期レプリカで可用性グループを作成する  2 つの同期レプリカと構成レプリカで可用性グループを作成する  2 つの同期レプリカで可用性グループを作成する 3.2.2.1 3 つの同期レプリカで可用性グループを作成する場合

CREATE AVAILABILITY GROUP [<可用性グループ名>]

WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL) FOR REPLICA ON N'<ノード名 1>' WITH ( ENDPOINT_URL = N'tcp://<ノード名 1>:<10. で設定したポート番号>', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC ), N'<ノード名 2>' WITH ( ENDPOINT_URL = N'tcp://<ノード名 2>:<10. で設定したポート番号>', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC ), N'<ノード名 3>' WITH( ENDPOINT_URL = N'tcp://<ノード名 3>:<10. で設定したポート番号>', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC );

3.2.2.2 2 つの同期レプリカと構成レプリカで可用性グループを作成する場合

CREATE AVAILABILITY GROUP [<可用性グループ名>] WITH (CLUSTER_TYPE = EXTERNAL)

FOR REPLICA ON N'<ノード名 1>' WITH ( ENDPOINT_URL = N'tcp://<ノード名 1>:<10. で設定したポート番号>', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC ), N'<ノード名 2>' WITH ( ENDPOINT_URL = N'tcp://<ノード名 2>:<10. で設定したポート番号>', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC ), N'<ノード名 3>' WITH ( ENDPOINT_URL = N'tcp://<ノード名 3>:<10. で設定したポート番号>', AVAILABILITY_MODE = CONFIGURATION_ONLY );

ALTER AVAILABILITY GROUP [<可用性グループ名>] GRANT CREATE ANY DATABASE;

3.2.2.3 2 つの同期レプリカで可用性グループを作成する場合

CREATE AVAILABILITY GROUP [<可用性グループ名>] WITH (CLUSTER_TYPE = EXTERNAL)

FOR REPLICA ON N'<ノード名 1>' WITH ( ENDPOINT_URL = N'tcp://<ノード名 1>:<10. で設定したポート番号>', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = EXTERNAL, SEEDING_MODE = AUTOMATIC ), N'<ノード名 2>' WITH ( ENDPOINT_URL = N'tcp://<ノード名 2>:<10. で設定したポート番号>', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,

11. セカンダリレプリカをホストする各 SQL Server インスタンスで、次の Transact-SQL を実行して可用性グループに参加しま す。

ALTER AVAILABILITY GROUP [<可用性グループ名>] JOIN WITH (CLUSTER_TYPE = EXTERNAL); ALTER AVAILABILITY GROUP [<可用性グループ名>] GRANT CREATE ANY DATABASE;

12. 可用性グループに追加するデータベースが完全モードで、有効なログ バックアップを持っていることを確認します。

13. プライマリ レプリカで、可用性グループへ参加させたいデータベースを可用性グループに追加します。

ALTER AVAILABILITY GROUP [<可用性グループ名>] ADD DATABASE [<データベース名>];

14. 可用性グループ上に追加されたデータベースが正常に同期されているかどうかを確認します。SQL Server Management Studio から接続する場合は、[Always On 高可用性] – [可用性グループ] - <可用性グループ名>で右クリックし、[ダッ シュボードの表示] から確認します。正常に同期されている場合は以下のように表示されます。

sqlcmd などのコマンドライン ツールから確認する場合は、以下のコマンドを実行して確認します。

SELECT ag.name AS 'ag_name',replica_server_name,is_primary_replica,DB_NAME(database_id) AS 'database',synchronization_state_desc,synchronization_health_desc

FROM sys.dm_hadr_database_replica_states rs LEFT JOIN sys.availability_groups ag

正常に同期されている場合は以下のように、synchronization_state_desc が [SYNCHRONIZED]、 synchronization_health_desc が [HEALTHY] と表示されます。

注意

この時点でセカンダリ レプリカでデータベースが正常に同期されていない場合は、SQL Server の ERRORLOG や以下の DMV から、各レプリカの接続状況やエラーの発生有無を確認してください。ERRORLOG は /var/opt/mssql/log に出 力されています。

3.2.3 Pacemaker のインストールと構成

3.2.3.1 Red Hat Enterprise Linux の高可用性サブスクリプションの有効化

クラスター内の各ノードには、高可用性アドオンの適切なサブスクリプションが必要です。高可用性サブスクリプションを有効にし てから、Pacemaker を設定します。

1. システムを登録します。

sudo subscription-manager register

2. 登録するために利用可能なプールを一覧表示します。使用可能なプールの一覧から、High Availability サブスクリプショ ンのプール ID を記録します。

sudo subscription-manager list --available

3. サブスクリプションを添付するスクリプトを実行します。

sudo subscription-manager attach --pool=<2.で確認したプール ID>

4. リポジトリを有効化します。

sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms

3.2.3.2 Pacemaker のインストール

1. すべてのクラスター ノードで、Pacemaker で使用するファイア ウォール ポートを開きます。

sudo firewall-cmd --permanent --add-service=high-availability sudo firewall-cmd --reload

2. すべてのノードに Pacemaker パッケージをインストールします。

sudo yum install pacemaker pcs fence-agents-all resource-agents

3. Pacemaker および Corosync パッケージのインストール時に作成される既定のユーザーのパスワードを設定します。すべての ノードで同じパスワードを使用します。

5. クラスターを作成します。いずれかのノードで次のコマンドを実行します。

sudo pcs cluster auth <ノード名 1> <ノード名 2> <ノード名 3> -u hacluster -p <hacluster のパスワード> sudo pcs cluster setup --name <クラスター名> <ノード名 1> <ノード名 2> <ノード名 3>

sudo pcs cluster start --all

注意

以前に同じノードにクラスターを設定していた場合は、pcs cluster setup を実行するときに--force オプションを使用する 必要があります。このオプションは、pcs cluster destroy を実行するのと同じです。Pacemaker を再度有効にするに は、sudo systemctl enable pacemaker を実行します。

7. SQL Server の SQL Server リソース エージェントをインストールします。すべてのノードで次のコマンドを実行します。 sudo yum install mssql-server-ha

8. フェンシング エージェントを利用しない場合は、フェンシングを無効にする必要があります。(これは実稼働環境では推奨され ません)

sudo pcs property set stonith-enabled=false

3.2.3.3 Pacemaker 用の SQL Server ログインを作成する

1. すべての SQL Server で、Pacemaker 用のサーバーログインを作成します。

USE [master] GO

CREATE LOGIN [<ログイン名>] with PASSWORD= N'<ログインのパスワード>' ALTER SERVER ROLE [sysadmin] ADD MEMBER [<ログイン名>]

2. すべての SQL Server で、SQL Server ログインの資格情報を保存します

echo '<ログイン名>' >> ~/pacemaker-passwd echo '<ログインのパスワード>' >> ~/pacemaker-passwd

sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd sudo chown root:root /var/opt/mssql/secrets/passwd

sudo chmod 400 /var/opt/mssql/secrets/passwd

3.2.3.4 可用性グループ リソースの作成

プライマリ レプリカで以下のコマンドを実行し、Master/Slave タイプの可用性グループ リソースを作成します。

sudo pcs resource create <可用性グループ リソース名> ocf:mssql:ag ag_name=<可用性グループ名> meta failure-timeout=30s master notify=true

3.2.3.5 可用性 IP リソースの作成

定義します。 コロケーションの制約を追加するには、いずれかのノードで以下のコマンドを実行します。

sudo pcs constraint colocation add <仮想 IP アドレス リソース名> ag_cluster-master INFINITY with-rsc-role=Master

3.2.3.7 順序制約の追加

フェールオーバー中に IP アドレスがフェールオーバー前のセカンダリを持つノードを一時的にポイントしてしまうことを防ぐために順序制 約を追加します。順序制約を追加するには、いずれかのノードで以下のコマンドを実行します。

sudo pcs constraint order promote ag_cluster-master then start <仮想 IP アドレス リソース名>

3.2.3.8 クラスター プロパティの設定 cluster-recheck-interval は、クラスターがリソース パラメータ、制約、クラスターオプションの変更をチェックするポーリング間隔を 示します。レプリカが停止すると、クラスターは、failure-timeout 値と cluster-recheck-interval 値によってバインドされた間 隔でレプリカを再起動しようとします。たとえば、failure-timeout が 60 秒に設定され、cluster-recheck-interval が 120 秒 に設定されている場合、再起動は 60 秒以上 120 秒未満の間隔で試行されます。 failure-timeout を 60 秒に設定し、 cluster-recheck-interval を 60 秒を超える値に設定することをお勧めします。 cluster-recheck-interval を小さい値に設定 することは推奨されません。 cluster-recheck-interval を 120 秒に設定する場合は以下のコマンドを実行します。

sudo pcs property set cluster-recheck-interval=2min

failure-timeout を 60 秒に更新する場合は以下のコマンドを実行します。

sudo pcs resource update <可用性グループ リソース名> meta failure-timeout=60s

また、Pacemaker パッケージ 1.1.18-11.el7 以上を使用している場合は、上記と併せて以下のコマンドを実行します。 (1.1.18-11.el7 における start-failure-is-fatal の動作変更の影響により、false に設定されている場合は障害発生時にセ カンダリ レプリカへ自動フェールオーバーされない可能性があります)

この段階で、可用性グループが構成されます。クラスターの状態を確認するには sudo pcs status コマンドを実行します。

上記の例の①の部分より、sqlagvm1 ノード、sqlagvm2 ノード、sqlagvm3 ノードの 3 ノードが構成され、全てオンラインになって いることがわかります。また、ag_cluster リソース、virtualip リソースが構成され、Master リソースと virtualip リソースが sqlfcivm1 ノードで開始済であることが確認できます。②の部分より、corosync、pacemaker、pcsd が全て動作(active)して おり、pacemaker と pcsd が有効化(enabled)されていることが確認できます。corosync は pacemaker が起動されると 付随的に起動されるため、動作していれば無効(disabled)の状態で問題ありません。

pacemaker デーモンが有効になっていない場合、OS 起動時に自動でクラスターが起動されません。自動起動を設定する場合 は pacemaker を有効化します。

sudo systemctl enable pacemaker

pcsd デーモンが起動していない場合、pcs コマンドが利用できません。pcs コマンドが利用できない場合は pcsd の有効化と 起動を行います。

sudo systemctl start pcsd sudo systemctl enable pcsd

①

3.2.4 可用性グループ リスナーの構成

1. リスナー名で可用性グループに透過的に接続する場合は、3.2.3.5 で可用性 IP リソースを作成した際に指定した IP アドレ スを DNS にリスナーの名前を登録します。(登録しない場合は、IP アドレスでの接続になります。)

2. プライマリ レプリカで以下のコマンドを実行します。IP アドレスは 3.2.3.5 で可用性 IP リソースを作成した際に指定した IP アドレスを指定します。

ALTER AVAILABILITY GROUP <可用性グループ名>

ADD LISTENER ‘<リスナーの DNS 名>’ ( WITH IP ( ('<IP アドレス>'),('<サブネット>') ) , PORT = <ポート#>); GO

3. 読み取り専用ルーティングを構成する場合は、各レプリカの SECONDARY_ROLE の設定を READ ONLY もしくは ALL に設定し、読み取り専用ルーティング URL と読み取り専用ルーティングリストを構成します。詳細については以下をご参照 ください。 可用性レプリカでの読み取り専用アクセスの構成 (SQL Server) https://docs.microsoft.com/ja-jp/sql/database-engine/availability-groups/windows/configure-read-only-access-on-an-availability-replica-sql-server?view=sql-server-2017 例えば、上記の構成を実施している以下の例では、プライマリ レプリカは sqlagvm1 ですが、リスナーを経由した読み取り専 用アクセスを行うと sqlagvm2 ノードに接続していることがわかります。

4

Pacemaker を利用した SQL Server 高可用性ソリューションの運用

4.1

OS 情報

4.1.1 messages / syslog

OS 標準のログは Red Hat Enterprise Linux では、既定で /var/log/messages に出力されます。

4.1.2 インストール時のログ

インストール時に問題が発生した場合は既定で /var/log/yum.log に出力されるインストールログを確認します。

4.1.3 カーネルバージョンとリリースバージョン

OS のカーネル バージョンとリリース バージョンを表示します。

sudo uname -srvimp cat /etc/os-release

4.2

SQL Server 情報

4.2.1 SQL Server のログ情報 SQL Server のログは /var/opt/mssql/log 配下に出力されます。出力されるログには以下のような種類があります。SQL Server の基本的な状況の確認には errorlog を確認します。 設定 説明 形式 errorlog SQL Server のログ テキスト log.trc 既定のトレース バイナリ system_health_0_<time>.xel システムの診断情報 バイナリ HkEngineEventFile_0_<time>.xel In-Memeory OLTP のイベント バイナリ sqlagent.out SQL Server Agent のログ テキスト

4.3

Pacemaker の基本的な操作

4.3.1 クラスターの状態確認

現在のクラスターの状態を表示します。

sudo pcs status

現在のクラスターの状態をより詳細に表示します。

sudo pcs status --full

クラスターの設定を表示します。 sudo pcs config クラスターとリソースのステータスを表示し、/var/log/cluster/corosync.log にあるリソース エージェント ログを確認します。 sudo crm_mon 4.3.2 クラスターの起動 全てのノードでクラスターを起動します。

sudo pcs cluster start --all

個別のノードでクラスターを起動する場合はノード名を指定します。

sudo pcs cluster start <対象ノード名>

クラスターが自動で起動しない場合は、pcs status の daemon status を確認します。Pacemaker が無効(disable)となって いる場合は有効化します。

sudo systemctl enable pacemaker

4.3.3 クラスターの停止

4.3.4 クラスターの再起動

クラスターを再起動する場合は、cluster stop と cluster start を併せて実行します。

sudo pcs cluster stop --all && pcs cluster start --all

4.3.5 クラスターのログ確認

クラスターの詳細な状態を確認する場合は、colosync.log を確認します。ログ出力の有無や、既定の場所はディストリビューシ ョンによって異なります。Red Hat Enterprise Linux 7.4 では、/var/log/cluster/corosync.log に出力されます。

4.4

Pacemaker を利用したフェールオーバー クラスター インスタンスの運用

4.4.1 フェールオーバー クラスター インスタンスの自動フェールオーバー フェールオーバー クラスター インスタンスをホストしているクラスター ノードに何らかの障害が発生した場合、自動的に別のノードに フェールオーバーが行われます。Pacemaker の場合は WSFC とは異なり、優先所有者を設定する方法がないため、 Pacemaker が FCI の新しいホストになるノードを選択します。 例えば、以下の例では、sqlfcivm1 ノードがプライマリ ノードとして動作しています。 この状態で sqlfcivm1 ノードに問題が発生すると、自動フェールオーバーが発生します。sqlfcivm2 が新たなプライマリ ノードとな っている様子がわかります。

4.4.2 フェールオーバー クラスター インスタンスの手動フェールオーバー

手動フェールオーバーを行う場合は、以下のコマンドを実行します。

sudo pcs resource move <SQL Server リソース名> <対象ノード名> sudo pcs resource clear <SQL Server リソース名>

Pacemaker は、手動によるフェールオーバー中に対象のリソースに位置制約を作成します。この動作により、フェールオーバー先が 優先的に起動するノードとして設定されます。例えば、ノード 1 からノード 2 へ手動フェールオーバーを行うと、ノード 2 が優先 的に起動するノードとして設定されます。その後、ノード 2 がダウンし、ノード 1 へフェールオーバーが行われた後、ノード 2 が復 旧したタイミングで自動フェールバック(再びノード 2 へフェールオーバー)が行われる動作となります。自動フェールバックを防止するた めには、move コマンドによる手動フェールオーバーを実行した後に、resource clear コマンドを実行して制約を削除する必要が あります。次の例では、mssqlha リソースを sqlfcivm2 という名前のノードにフェールオーバーし、制約を削除しています。

sudo pcs resource move mssqlha sqlfcivm2 sudo pcs resource clear mssqlha

例えば、以下の例では、sqlfcivm1 ノードがプライマリ ノードとして動作しています。

sqlfcivm1 から sqlfcivm2 へ手動フェールオーバーすると、プライマリ ノードが sqlfcivm1 ノードへ変更されます。フェールオーバー 後に制約を削除します。

4.5

Pacemaker を利用した可用性グループの運用

4.5.1 可用性グループの自動フェールオーバー SQL Server 2017 には、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT の設定が導入されています。この 設定により、プライマリ レプリカが各トランザクションをコミットする前に、指定された数のセカンダリ レプリカがトランザクション デ ータをログに書き込むことが保証されます。Pacemaker などの外部クラスター マネージャーを使用する場合、この設定は高可用 性とデータ保護の両方に影響します。設定の既定値は、クラスター リソースの作成時のアーキテクチャーによって異なります。 SQL Server リソース エージェント (mssql-server-ha）をインストールし、可用性グループのクラスター リソースを作成すると、ク ラスター マネージャーは可用性グループの構成を検出し、それに応じて REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を設定します。 4.5.1.1 3 つの同期レプリカの場合 3 つの同期レプリカで構成される可用性グループは、読み取りスケール、自動フェールオーバーおよびデータ保護が提供されます。 自動フェールオーバーおよびデータ保護を必要とする場合は REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を 1 に設定します。読み取りスケールを利用する場合は REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を 0 に設定します。 4.5.1.2 2 つの同期レプリカの場合 この構成は、データの保護と読み取りスケールが提供されます。 2 つの同期レプリカの構成は、自動フェールオーバーは提供され ないため、自動フェールオーバーを必要とする場合は 3 つの同期レプリカの構成を検討してください。 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT が 0 の場合は読み取りスケール、1 の場合はデータの保護 が提供されます。

4.5.1.3 2 つの同期レプリカと構成レプリカの場合 2 つ以上の同期レプリカと構成レプリカを持つ可用性グループは、データ保護と高可用性を提供します。この構成は SQL Server 2017 CU1 以降の新機能です。3 つの同期レプリカの場合と同様に 3 台以上での構成になりますが、その中の 1 台 を「構成のみ」の可用性モードとすることができます。3 つの同期レプリカの場合は、それぞれの SQL Server がデータの同期を 行う構成であるため全て同じエディションで構成する必要があり、3 台分の SQL Server のコストがかかることになります。構成 レプリカは無償版の Express Edition で構成ができるため、このノードについてはコストを抑えることができます。また、構成レプリ カは可用性グループのレプリカ数の制限に含まれないため、2 台のレプリカしか構成できない Standard Edition でも自動フェー ルオーバーを有効にすることができるというメリットがあります。 プライマリ レプリカはセカンダリ レプリカと構成レプリカの両方に構成データをプッシュします。セカンダリ レプリカはユーザーデータ も受け取ります。 構成レプリカはユーザーデータを受け取りません。 セカンダリ レプリカは同期モードです。構成のレプリカには、 可用性グループのデータベース（可用性グループに関するメタデータのみ）が含まれていません。 構成レプリカの構成データは、 同期してコミットされます。 1. セカンダリ レプリカへのユーザー データの同期レプリケーション。可用性グループ構成のメタデータも含まれています。 2. 可用性グループ構成のメタデータの同期レプリケーション。ユーザー データは含まれません。

注意

構成レプリカを持つ可用性グループは、SQL Server 2017 CU1 の新機能です。 可用性グループ内の SQL Server の すべてのインスタンスは、SQL Server 2017 CU1 以降である必要があります。

例えば、以下の例では、3 つの同期レプリカ構成で sqlagvm2 がプライマリ レプリカをホストしています。

この状態で sqlagvm2 ノードに問題が発生すると、自動フェールオーバーが発生します。先ほどの例では、sqlagvm1 が新たな プライマリ レプリカのホストとなっている様子がわかります。