注意: SQL Server Availability Group をRHEL Clusterで作る場合はHA add-on が必要ですが、このアドオンはAzure上ではサポートされていません。ということでサポート対象外だけど試したいという場合にAzure上でどうぞ。全体の作り方はAzure上に限らないはずです。
公開直後になんとなく作ったのですがそのときは挙動があやしかったので再度作り直してみた結果をまとめてみます。
作業の流れとしては、
- Clusterを構成する各NodeにSQL Serverをインストールする
- Availability Groupを構築する
- Cluster化する
となります。最後のCluste化するところではプラットフォームごとに利用するPacemaker管理ソフトが異なります。RHELの場合はpcsを使います。このエントリを読む前にこちらで概要を把握するのがよいと思われます。
作業の流れ自体はこちらに書いてある通りになります。このドキュメントが公開された当初はいろいろ記述が足りなかったのですが、今やった限りでは一通り揃っているようです。とはいえ、いろいろハマリどころが多かったのでその辺をまとめておきたいと思います。
Configure availability group for SQL Server on Linux | Microsoft Docs
ホストの用意とSQL Serverのインストール
今回はAzure上のVMで構築しました。問題としては最後にVIPを割り振った後、VIPでのアクセスが同じネットワーク内の別ホストからできないことなのですが、これはAzureのNetworkを勉強しないといけなさそうです。また同じVNETのSubnet内にNodeを配置するので、ホスト名での通信はデフォルトのAzure DNSでできる状態です。VMを起動したら、このドキュメントに沿って、各NodeにSQL Serverをインストールします。
また、sqlcmdで接続して処理を進める必要があるのでSQL Server Toolsも各ホストにインストールしておきました。
Availability Groupの構築
次にこのドキュメントに沿ってAvailability Groupの構築を行います。ちなみにこの中の手順で失敗して、復旧が難しい状態になったらSQL Serverのアンインストールをして最初からやりなおすことをオススメします。。。
Configure availability group for SQL Server on Linux | Microsoft Docs
手順をまとめると
- Always On availability groupsを有効化してmssql-serverサービス再起動(全Node)
- AlwaysOn_health event sessionの有効化(任意、やる場合は全Node)
- db mirroring endpoint user作成(全Node)
- Masterでのcertificate作成とMaster以外のNodeへの転送(Masterのみ)
- Secondary Nodesでのcertificate作成(Master以外の全Node)
- database mirroring endpoints作成(全Node、設定するIPアドレスはNode自身のアドレス*1なのでNodeにより異なる)
- availability group作成(Masterのみ、ノード名やリスナーのIPを環境に合わせて設定する)
- Secondary Server(s)をAvailability Groupに追加(Master以外の全Node)
- DBを作成し、Availability Groupに追加(Masterのみ)
- 追加したDBがSecondary Nodeからアクセスできることを確認(Master以外のNode)
となります。mirroring endpointの作成あたりから操作うまくいったか不安になるのですが、まずendpointができているかどうかはSELECT * FROM sys.endpoints
でわかります。
作ったエンドポイントのstate_desc
がSTARTED
になっていればOKです。おかしい場合はDROP ENDPOINT Hadr_endpoint
で消せるはずです。ちなみにちゃんとうごいていると上のクエリがすぐに結果を返しますが、変な状態になっていたら結果がかえるのにやたら時間がかかる状態になっていました。
また、Availability Group自体はこの時点で動いているのでその状態を確認することもできます。このブログを参考にしました。
なんとも見辛いですがこんな感じで表示されます。この環境はdb1とdb2を追加しています。
Cluster化
RHELではCluster化を行うのに、Pacemakerを利用して作られたHA add-onを使います。というわけでご利用の際には該当のSubscriptionが必要になります。
また、このCluster化の手順で失敗した場合、Availability Group本体に影響がなければこの手順のみをやりなおすことができます。その場合はまず、pcs cluster delete --all
をMasterで実行するか、pcs cluster delete
を各Nodeで実行するとよさそうです。クラスターを削除した場合、pacemakerがdisableになっているのでsudo systemctl enable pacemaker
を再実行します。また、pcs cluster auth
はclusterを削除しても認証が残ったままになりますが、ここもやり直したい場合は--force
オプションをつけることができます。
STONITH(Shoot-The-Other-Node-In-The-Head)の無効化ですが、テスト目的ではドキュメントどおり無効化すればよいのですが、本番環境では設定しておくべきでしょう。なぜかリンク先はRHEL6ですが、RHEL7向けのドキュメントはこちらです。
また、こちらのドキュメントなどを見ると、Azure上ではVMをShutdownさせてるようにするの一つの方法のようです。
負荷分散セットを使用して MySQL をクラスター化する | Microsoft Docs
あとはドキュメント通りに、PacemakerがヘルスチェックするためのSQL Serverログインユーザーを作成し、pcsのavailability groupリソースと virtual IPリソースを作成します。ここまで来ればpcsの状態でも確認できます。
VIPが着いている側のNICにVIPに設定した172.17.2.50が割り振られているのがわかります。
リソースを手動でFailoverするとsolnode2に移動するのもわかります。
solnode2側で見ればVIPがつけかわっています。
さて無事に動けばいいのですが、手順を誤まると動かないことがあります。実際にこんなエラーが出たことがありました。
こういうときはSQL Serverのエラーログを見てみましょう。/var/opt/mssql/log/errorlog
にあります。
というのがSQL Server Availability Group on RHEL Clusterを作ってみた感想になります。特にCluster化はHA add on を使うのでドキュメントに倣うだけでもある程度知っておくことが必要で、実際に使いこなすにはさらに習得しておく必要を感じました。
*1:このアドレスはクラスタ内の別Nodeからアクセスできるアドレス