Linux デプロイでの SQL Server 可用性の基本
適用対象: 
SQL Server - Linux
SQL Server 2017 (14.x) 以降では、Linux と Windows の両方で SQL Server がサポートされています。 Windows ベースの SQL Server デプロイと同様に、SQL Server のデータベースとインスタンスは、Linux 下でも高可用性を備えている必要があります。 この記事では、高可用性を備えた Linux ベースの SQL Server データベースとインスタンスを計画し、デプロイするうえでの技術的な側面について説明すると共に、Windows ベースのインストールとの違いについて説明します。 Linux プロフェッショナルは SQL Server について聞き慣れなかったり、SQL Server プロフェッショナルは Linux について聞き慣れない場合があるかもしれないため、この記事では、一部のプロフェッショナルにとっては馴染みのある概念についても説明しています。
Linux デプロイでの SQL Server 可用性オプション
バックアップと復元に加えて、Linux では、Windows ベースのデプロイと同じ、3 つの可用性機能を使用できます。
Windows の場合、FCI には常に基になる Windows Server フェールオーバー クラスター (WSFC) が必要です。 デプロイ シナリオによっては、AG には通常、基になる WSFC が必要になります (ただし、SQL Server 2017 (14.x) の新しい None バリアントは例外です)。 WSFC は Linux には存在しません。 Linux でのクラスタリングの実装については、「Linux での可用性グループとフェールオーバー クラスター インスタンスのための Pacemaker」をご覧ください。
Linux についてのクイック ガイド
一部の Linux インストールはインターフェイスを使用してインストールされる場合がありますが、ほとんどの場合はそうではありません。つまり、オペレーティング システム レイヤーのほぼすべてがコマンド ラインにより実行されます。 Linux の世界では、このコマンド ラインを指す一般的な用語は "bash シェル" です。
Linux では、多くのコマンドを昇格された特権で実行する必要があります。これは、Windows Server で多くの操作を管理者として実行する必要があるのと似ています。 昇格された特権で実行するには、主に次の 2 つの方法があります。
適切なユーザーのコンテキストで実行します。 別のユーザーに変更するには、
suコマンドを使用します。suをユーザー名なしで単独で実行した場合、パスワードがわかっていれば、rootとしてシェルに入ることになります。より一般的な、セキュリティを意識した方法で実行するには、操作を実行する前に
sudoを使用することをお勧めします。 この記事の多くの例では、sudoを使用しています。
次に示すのは、いくつかの一般的なコマンドです。これらについては、さまざまなスイッチやオプションをオンラインで調べることができます。
cd- ディレクトリを変更しますchmod- ファイルまたはディレクトリのアクセス許可を変更しますchown- ファイルまたはディレクトリの所有者を変更しますls- ディレクトリの内容を表示しますmkdir- ドライブにフォルダー (ディレクトリ) を作成しますmv- ある場所から別の場所にファイルを移動しますps- 処理中のプロセスをすべて表示しますrm- ファイルをサーバー上でローカルに削除しますrmdir- フォルダー (ディレクトリ) を削除しますsystemctl- サービスを開始、停止、または有効化します- テキスト エディター コマンド。 Linux には、vi や emacs など、さまざまなテキスト エディター オプションがあります。
Linux 上の SQL Server の可用性構成に関する一般的なタスク
このセクションでは、Linux ベースのすべての SQL Server デプロイに共通するタスクについて説明します。
ファイルをコピーできることを確認する
あるサーバーから別のサーバーへのファイルのコピーは、Linux で SQL Server を使用するすべてのユーザーが実行できる必要があるタスクです。 このタスクは、AG の構成にとって非常に重要です。
アクセス許可の問題などは、Linux と Windows ベースのインストールに存在する可能性があります。 ただし、Windows でのサーバー間のコピー方法に詳しいユーザーは、Linux での方法については詳しくないこともあるでしょう。 一般的な方法は、コマンドライン ユーティリティ scp (セキュリティで保護されたコピーを意味します) を使用することです。 scp では、バックグラウンドで OpenSSH が使用されます。 SSH は、セキュリティで保護されたシェルを意味します。 Linux ディストリビューションによっては、OpenSSH 自体がインストールされない場合もあります。 その場合は、最初に OpenSSH をインストールする必要があります。 OpenSSH の構成の詳細については、各ディストリビューションに関する次のリンクを参照してください。
scp を使用する際には、サーバーが転送元または転送先ではない場合に、サーバーの資格情報を指定する必要があります。 たとえば、
scp MyAGCert.cer username@servername:/folder/subfolder
を使用すると、MyAGCert.cer ファイルが、もう一方のサーバー上の指定されたフォルダーにコピーされます。 コピーするには、ファイルのアクセス許可 (および場合によっては所有権) を持っている必要があるため、コピーする前に chown を使用しなければならない場合があります。 同様に、受信側では、アクセス権を持った適切なユーザーがファイルを操作する必要があります。 たとえば、証明書ファイルを復元するには、mssql のユーザーがそのファイルにアクセスできる必要があります。
サーバー メッセージ ブロック (SMB) の Linux バリアントである Samba を使用して、UNC パス (\\SERVERNAME\SHARE など) によってアクセスされる共有を作成することもできます。 Samba の構成の詳細については、各ディストリビューションに関する次のリンクを参照してください。
Windows ベースの SMB 共有を使用することもできます。SQL Server をホストしている Linux サーバー 上で Samba のクライアント部分が適切に構成されていて、共有に適切なアクセス権があれば、SMB 共有が Linux ベースである必要はありません。 混合環境では、これは Linux ベースの SQL Server デプロイの既存のインフラストラクチャを使うための 1 つの方法です。
重要なのは、デプロイされた Samba のバージョンが SMB 3.0 に準拠している必要があるということです。 SQL Server 2012 (11.x) で SMB サポートが追加されたときには、すべての共有で SMB 3.0 をサポートする必要がありました。 Windows Server ではなく、共有に Samba を使用する場合は、Samba ベースの共有で、SMB 3.1.1 をサポートしている Samba 4.0 以降 (できれば 4.3 以降) を使用する必要があります。 「SMB3 in Samba」は、SMB と Linux に関する情報源として有用です。
最後に、ネットワーク ファイル システム (NFS) 共有を使用することもできます。 NFS は、Windows ベースの SQL Server デプロイでは使用できず、Linux ベースのデプロイでのみ使用できます。
ファイアウォールの構成
Windows と同様に、Linux ディストリビューションにはファイアウォールが組み込まれています。 会社でサーバーに外部ファイアウォールが使用されている場合は、Linux でファイアウォールを無効にすることが許容される可能性があります。 ただし、ファイアウォールがどこで有効になっているかに関係なく、ポートは開いている必要があります。 次の表は、Linux 上の高可用性 SQL Server デプロイに必要な、一般的なポートを示したものです。
| ポート番号 | Type | 説明 |
|---|---|---|
111 |
TCP/UDP | NFS - rpcbind/sunrpc |
135 |
TCP | Samba (使用されている場合) - エンドポイント マッパー |
137 |
UDP | Samba (使用されている場合) - NetBIOS Name Service |
138 |
UDP | Samba (使用されている場合) - NetBIOS Datagram |
139 |
TCP | Samba (使用されている場合) - NetBIOS Session |
445 |
TCP | Samba (使用されている場合) - SMB over TCP |
1433 |
TCP | SQL Server - 既定のポート。必要に応じて、mssql-conf set network.tcpport <portnumber> を使用して変更できます |
2049 |
TCP、UDP | NFS (使用されている場合) |
2224 |
TCP | Pacemaker - pcsd によって使用されます |
3121 |
TCP | Pacemaker - Pacemaker Remote ノードがある場合に必要です |
3260 |
TCP | iSCSI Initiator (使用されている場合) - /etc/iscsi/iscsid.config (RHEL) で変更できますが、iSCSI Target のポートと一致している必要があります |
5022 |
TCP | SQL Server - AG エンドポイント用に使用される既定のポート。エンドポイントの作成時に変更できます |
5403 |
TCP | Pacemaker |
5404 |
UDP | Pacemaker - マルチキャスト UDP を使用している場合は Corosync で必要になります |
5405 |
UDP | Pacemaker - Corosync で必要です |
21064 |
TCP | Pacemaker - DLM を使用しているリソースで必要になります |
| 変数 | TCP | AG エンドポイント ポート。既定値は 5022 です |
| 変数 | TCP | NFS - LOCKD_TCPPORT 用のポート (RHEL では /etc/sysconfig/nfs にあります) |
| 変数 | UDP | NFS - LOCKD_UDPPORT 用のポート (RHEL では /etc/sysconfig/nfs にあります) |
| 変数 | TCP/UDP | NFS - MOUNTD_PORT 用のポート (RHEL では /etc/sysconfig/nfs にあります) |
| 変数 | TCP/UDP | NFS - STATD_PORT 用のポート (RHEL では /etc/sysconfig/nfs にあります) |
Samba で使用できるその他のポートについては、「Samba ポートの使用方法」を参照してください。
逆に、Linux でのサービスの名前を、ポートの代わりに例外として追加することもできます (たとえば、Pacemaker の high-availability など)。 このアプローチを採用する場合は、使用するディストリビューションで当該の名前を参照してください。 たとえば、RHEL では、Pacemaker を追加するコマンドは次のようになります
sudo firewall-cmd --permanent --add-service=high-availability
ファイアウォールのドキュメント
可用性のための SQL Server パッケージをインストールする
Windows ベースの SQL Server インストールでは、一部のコンポーネントは基本的なエンジンのインストールでもインストールされますが、それ以外はインストールされません。 Linux では、SQL Server エンジンのみがインストール プロセスの一部としてインストールされます。 その他はすべてオプションです。 Linux での高可用性 SQL Server インスタンスの場合、SQL Server と共に 2 つのパッケージをインストールする必要があります。
- SQL Server エージェント (
mssql-server-agent) - 高可用性 (HA) パッケージ (
mssql-server-ha)
SQL Server エージェントは厳密にはオプションですが、SQL Server のジョブのスケジューラであり、ログ配布で必要とされるため、インストールすることをお勧めします。
SQL Server 2017 (14.x) と CU 4 以降のバージョンでは、SQL Server エージェントはデータベース エンジン パッケージに含まれていますが、引き続きそれを有効にする必要があります。 Windows ベースのインストールでは、SQL Server エージェントはオプションではありません。
Note
SQL Server に聞き慣れない方のために説明すると、SQL Server Agent は SQL Server の組み込みのジョブ スケジューラです。 バックアップやその他の SQL Server メンテナンスなどをスケジュール設定できます。 SQL Server Agent が完全に別のサービスである Windows ベースの SQL Server インストールとは異なり、Linux では、SQL Server Agent は SQL Server 自体のコンテキストで実行されます。
AG または FCI が Windows ベースの構成で構成されている場合、それらはクラスター対応となります。 クラスター対応とは、SQL Server で、WSFC によって認識される特定のリソース DLL (FCI の場合は sqagtres.dll と sqsrvres.dll、AG の場合は hadrres.dll) があり、WSFC によってそれが使用されることで、SQL Server のクラスター化機能が稼働し、正常に機能していることが確認されることを意味します。 クラスタリングは SQL Server にとってだけでなく、Linux 自体にとっても外部的な機能であるため、Microsoft では、Linux ベースの AG デプロイや FCI デプロイのために、リソース DLL に相当するコードを記述する必要がありました。 それが、mssql-server-ha パッケージです (Pacemaker 用の SQL Server リソース エージェントとも呼ばれます)。 mssql-server-ha パッケージをインストールするには、「SQL Server on Linux 用の Pacemaker クラスターをデプロイする」をご覧ください。
Linux 上の SQL Server 用のその他のパッケージ (SQL Server フルテキスト検索 (mssql-server-fts) と SQL Server Integration Services (mssql-server-is)) は、FCI と AG のいずれについても、高可用性を確保するうえで必須ではありません。
SQL Server の高可用性とディザスター リカバリーのパートナー
SQL Server サービスの高可用性とディザスター リカバリーを提供するためのツールを、業界をリードする豊富な種類の中から選びます。 このセクションでは、SQL Server をサポートする高可用性とディザスター リカバリーのソリューションを提供する Microsoft パートナー会社を示します。
| Partner | 説明 |
|---|---|
| DH2i | DxEnterprise は、計画/計画外のダウンタイムをほぼゼロに抑え、大幅なコスト削減を実現し、管理を著しく簡素化し、物理と論理の両方を統合するために役立つ、Windows、Linux、Docker 向けのスマート可用性ソフトウェアです。 - Kubernetes で DH2i DxEnterprise を使用した可用性グループを配置する - チュートリアル: DH2i DxEnterprise を使用して 3 ノード Always On 可用性グループを設定する |
| HPE Serviceguard | HPE SGLX は、フェールオーバー クラスター インスタンスと Always On 可用性グループの状況依存型の監視と回復のオプションを提供しています。 HPE SGLX ではデータ整合性とパフォーマンスを損なわずに、アップタイムを最大化します。 - チュートリアル: HPE Serviceguard for Linux を使用して 3 ノード Always On 可用性グループをセットアップする。 |
| Pacemaker | Pacemaker は、オープンソースの高可用性クラスター リソース マネージャーです。 オープンソースのグループ通信システムである Corosync と共に使うことで、Pacemaker は、コンポーネントの障害を検出し、必要なフェールオーバー手順を調整して、アプリケーションの中断を最小限に抑えることができます。 - Linux 上の可用性グループとフェールオーバー クラスター インスタンスのための Pacemaker - SQL Server on Linux 用の Pacemaker クラスターをデプロイする |