スマートスタイル TECH BLOG

Keepalived による MariaDB MaxScale の冗長化

本記事はMariaDB Corporationより寄稿された記事となります

はじめに

MariaDB MaxScale は以下のような特長を持つデータベースproxyですが,

  • Read/Write Splitter
  • SQLファイアウォール
  • データマスキング
  • 自動フェイルオーバー

反面,MaxScale ノード/インスタンスがダウンした場合に単一障害点(SPOF)になりえます。
そこで今回は MaxScale を2ノード構成とし,その上位に Keepalived を配した構成における MaxScale のフェイルオーバーについて解説致します。

テスト環境

  • CentOS 7.6.1810
  • MaxScale 2.3.4 GA
  • Keepalived 1.3.5

Keepalived とは

Keepalived は高可用性(HA)/ロードバランシングのためのルーティングツールです。今回は MaxScale を実行している2台のサーバー間で IPフェイルオーバーを設定します。アクティブ MaxScale に障害が発生した場合、スタンバイ MaxScale に仮想IP(VIP)をフェイルオーバーします。
下図にアーキテクチャを示します。各 MaxScale ノードでは MaxScale と Keepalived を実行し,クライアント/アプリケーションは Keepalived が管理する仮想IP(VIP)に接続します。

各 Keepalived(MaxScale)ノードは常にステータスをブロードキャストし,互いに通信します。片方のノードが他ノードより高い優先順位でステータスメッセージを受信しない場合,そのノードはVIPを要求しマスターになります。

現 MASTERノードが停止した場合,他方のノードは新MASTERとなり,VIPへのトラフィックは新MASTERに向けられ,オリジナルのMASTERノードへの接続は切断されます。再びオリジナルMASTERがオンラインになった場合,再度VIPを要求し、バックアップノードとの接続を切断します。

MaxScale は Keepalived のステータスには関知せず,シングルノード構成と場合と同様にバックエンドDBサーバを監視,クライアント接続を待機します。クライアントはVIPを介して接続しているため,MaxScaleとバックエンドDB間の接続は実IPを使用し,VIPの影響を受けません。

Keepalived の設定

MaxScale は Keepalived のための特殊な設定を必要としませんが,双方のノードで実行されている必要があり,MaxScale の設定は同様に設定する必要があります。MaxScale の service 設定では,クライアントがどちらの MaxScale ノードに接続したかを明確にするために version_string をノード毎に異なる値に設定することを推奨いたします。

プライマリ MaxScale ノードの R/Wスプリッター serviceの設定例

Keepalived は双方のノードで priority を異なる値に設定する必要があります。プライマリ・ノードでは /etc/keepalived/keepalived.conf を次のように設定します(priority 150)。

ここで,

  • state : 双方のノードで MASTER
  • virtual_router_id と auth_pass は同一
  • interface : 使用されるネットワークインタフェース
  • priority : どちらがMASTERになるべきかを決定するための優先度。ここではプライマリ・ノードを150にする
  • advert_int : 他のKeepalived ノードに自分の存在を”アドバタイズ”する時間間隔。ここでは1秒
  • virtual_ipaddress(VIP) は Keepalived ノードが利用しようとする仮想IPアドレス。VIPが同一LAN内にあり、LAN内の他ホストが利用していないIPアドレスである必要があります。

セカンダリ・ノード用の keepalived.conf の例を以下に示します(priority 100)。

MaxScale のヘルスチェック(死活監視)

MaxScale が Keepalived MASTERノードで稼働中であることを確認するには,ヘルスチェック・スクリプトを定期的に実行する必要があります。ヘルスチェック・スクリプトがエラーを返すと,ステータス・ブロードキャストを停止し,VIPを放棄します。
これにより他ノードが MASTERステータスを取得し,VIPを割り当てることができます。
例えばプライマリ・ノードでは次のように設定します。

参考: Keepalived Check and Notify Scripts

is_maxscale_running.sh の例:

MaxScale active/passive設定

MaxScale を複数稼働させていて,なおかつ MariaDB Monitor(mariadbmon) の auto_failover / auto_rejoin を有効にしている場合,MaxScale 間でMariaDB Monitor が競合しますので,BACKUPノードでは auto_failover / auto_rejoin を無効にする必要があり,グローバル設定の passive パラメータで制御することができます。

MASTER(Active) ノードでは,

により,passive=false (active) に設定,反対に BACKUP(Standby) ノードでは,

により,passive=true に設定します。
passive=true になると,auto_failover=false / auto_rejoin=false となり,自動 failover / rejoin を行いません。

MaxScale のフェイルオーバーテスト

プライマリ・ノードを reboot ,再起動中に MaxScale がセカンダリに自動 フェイルオーバーするかテストしてみます。

セカンダリ・ノードの /var/log/messages:

プライマリ・ノードがシャットダウンされた直後にセカンダリ・ノードが MASTER STATE に移行し,プライマリ・ノードの reboot が完了すると,セカンダリ・ノードが再び BACKUP STATE になっていることが確認できます。

まとめ

今回は SPOF を回避するために MaxScale を複数稼働させ,Keepalived を用いて片方の MaxScale がダウンした場合に高速自動フェイルオーバーする MaxScale の高可用構成について解説いたしました。DNS設定などでフェイルオーバーするロードバランサーなどと比較してより高速に切り替わることが確認できました。

参考 Knowledge Base ページ: MaxScale 2.3 Failover with Keepalived and MaxCtrl


執筆者情報

後藤 智(GOTO Satoru)
2017年6月よりMariaDB CorporationにてAPAC(Asia Pacific)地域におけるプリセールス業務を主に担当。現在は主に日本を担当。
この執筆者の他の記事をよむ
Return Top