SQL Server on Linux でも AlwaysOn！
Microsoft Japan Data Platform Tech Sales Team
SQL Server on Linux に多くの反響をいただいております。 ただ、Linux 上で SQL Server が動いたとしても、本番環境に採用するには性能もさることながら可用性構成が取れるのかというのも大きなハードルの一つであるかと思います。SQL Server on Linux では、これまで実装されていた高可用性・災対向け機能の AlwaysOn を on Windows 同様にご利用いただけます。今回は AlwaysOn の中でも Availability Group(以降 AG と称す) にフォーカスしてご紹介いたします。 （AlwaysOn AGって何？という方はこちらをご参照ください）
Windows、および Linux 環境での AlwaysOn AG 構成で大きく違うのはクラスタウェア部分です。 (SQL Server vNext では Cluster-less AG もサポートされる予定ですが、本投稿では触れません。)
on Windows |
on Linux |
|
| データ同期 | AlwaysOn AG | AlwaysOn AG |
| クラスタウェア | Windows Server Failover Cluster | Linux 用クラスタウェア |
| ドメイン構成 | Active Directoryor非 Active Directory | 非 Active Directory |
Linux 用クラスタウェアですが、2017/4/3 時点では Pacemaker という OSS のクラスタウェアのみマニュアル上では言及されており、リソース監視用のスクリプト(リソースエージェント)も Pacemaker 用のみ入手可能なため、今回は Pacemaker に限定してお話を進めます。
Windows エンジニアにはあまり馴染みがないかもしれませんが、Linux エンジニアの方々は Pacemaker で高可用性システムを構築した経験をお持ちの方も多いかと思います。
Packemaker は広義の意味ではクラスタウェアと位置づけられますが、狭義の意味ではリソース制御部分の Packemaker と、クラスター制御部分 (Corosync or Heatbeat) に分けられます。狭義の意味においても、IP や AlwaysOn AG といったクラスターリソースの監視や制御を直接行うのは Pacemaker と言えます。更に具体的に言うと、Pacemaker の中の lrmd というプロセスがローカルのクラスターリソース、つまり IP や AlwaysOn AG に対して制御・監視を行います。lrmd は LSB(Linux Standard Base) や OCF(Open Clustering Framework) に準拠したスクリプト(リソースエージェントという) により各クラスタリソースを制御・監視します。
図1 Pacemaker(Pacemaker + Corosync) 関連コンポーネント
(Packemaker は クラスター制御部として Corosync、あるいは Heatbeat を組み合わせて使用することができますが、今回は Corosync で話を進めます。)
Pacemaker および Corosync はその他にもいくつかプロセスが存在し、運用などを含めるとそれぞれを理解しておく必要がありますが、ここまでの内容で一旦はこちらでご紹介している AlwaysOn AG on Linux のクラスタウェアを構成する各作業ステップの意味はご理解いただけるかと思います。
具体的な手順はマニュアルを参照いただくとして、以下では実際に構築した環境の構成を見ていきます。
[環境]
OS |
Redhat Enterprise Linux 7.3 x86_64 |
ノード |
kazrelsql01(プライマリ レプリカ) kazrelsql02(セカンダリ レプリカ) |
|
クラスタ |
kazcluster01 |
|
AlwaysOn AG |
ag1 |
|
AlwaysOn AG クラスターリソース |
ag_cluster | AlwaysOn AG “ag1”を監視、制御 |
AlwaysOn AG プライマリレプリカクラスターリソース |
ag_cluster-master | AlwaysOn AG “ag1”のmaster(プライマリレプリカ)を監視、制御 |
| AlwaysOn AG リスナークラスターリソース | virtualip | AlwaysOn AG リスナーを監視、制御 |
pcs コマンドなどを使って構成情報を確認することもできますが、今回はWebツールを使用して確認していきます。
先ずは”https://<ノード名>:2224”にアクセスし、”hacluster”ユーザーでログインします。
すると、下記のような画面が出てきますが、まだ管理するためのクラスターが登録されていません。
そこで、[Add Existing]をクリックしノード名を指定してクラスターを登録します。
するとノードが参加しているクラスターが管理対象として登録されます。
登録されたクラスターを選択すると、クラスターを構成する2台のノード名や AlwaysOn AG クラスターリソースと AG リスナークラスターリソースが参照できます。
ノードをクリックすると各ノードで動いているクラスターリソースなどが確認できます。
AlwaysOn AG クラスターリソースは両ノードで起動していますが、AG リスナークラスターリソースはプライマリ レプリカであるノードでしか起動していないことが分かります。
クラスターリソースについても詳細を確認するためクリックしてみます。 各リソースの依存関係ですが、AG リスナークラスターリソースは AlwaysOn AG プライマリレプリカクラスターリソースが promote (プライマリレプリカに昇格) してから起動するという順番になっていることが分かります。
また、AlwaysOn AG プライマリレプリカクラスターリソースと AG リスナークラスターリソースは常に同じノードで動作する関係になっていることも確認できます。
以上より、AlwaysOn AG の構成自体は on Windows とほぼ同等の構成を取れることが分かりました。
SQL Server on Linux は Linux 上で SQL Server を先ずは動かしてみようなどということを目標に開発しているわけではなく、本番環境での使用にも耐えうることを想定して開発を進めておりますので是非ご検討いただければと思います。