はじめに

こんちには。

サムザップでSREチームに所属しており、主にパブリッククラウドなどを使用する業務に携わっている島田です。本記事ではOrchestratorというツールを導入検証してみたので、その特徴などを解説していきます。

引用: https://github.com/github/orchestrator

Orchestratorとは、MySQLレプリケーショントポロジ管理およびビジュアライゼーションツールです。同様の自動フェイルオーバーツールとしてMHAやmysqlfailoverのようなツールがあります。GitHubのバックエンドとしても使用されているそうです。複雑なレプリケーション構成の管理をしやすくするためのツールで以下のような特徴があります。

• レプリケーションクラスタの検出と調査
• 安全なトポロジリファクタリング：トポロジの周りのレプリカの移動
• 洗練されたトポロジの視覚化
• レプリケーションの問題の視覚化
• 直感的なドラッグアンドドロップによるトポロジの変更
• メンテナンスモードの宣言と実施
• オペレーションの監査
• more…

---

MHA, mysqlfailoverとの比較

もともとサムザップではMHAを使用してサービスを運用していたのですが、下記のようなMHAではない特徴がOrchestratorにはあるのでMHAの代わりとして使用できないか検証してみました。

GTIDの対応はmysql5.7以上を使用するならば欲しかった機能ですね。
また運用上ログを残せたり、手動で再セットアップ不要というのは大きなメリットです。

---

GCPによるフェイルオーバーの検討

gcpではインスタンスにvipを付与することが出来なかったので、当初はMHA+Haproxy+consul-template構成でフェイルオーバーを構成していました。しかしこの構成では使用するミドルウェアが多いことや、configファイルを書き換えなくてはいけないなど、システムが大変複雑になってしまいます。

しかし最近Alias IPがgceで使えるようになったので上記構成を見直しました。
MHAの代わりにOrchestratorを使用し、mysqlの障害時にAlias IPをつけかえるだけというとてもシンプルな構成です。

---

Orchestratorの設定

では早速orchestratorを試してみましょう!
手順は下記です。

1. mysqlのインストール

省略

2. orchestratorのインストール

Installationページ参照

3. 設定ファイルの記入

/etc/orchestrator.conf.jsonに以下の設定ファイルを作成します。

{
  "Debug": false,
  "EnableSyslog": false,
  "ListenAddress": ":3000",
  "AuthenticationMethod": "",

  "MySQLTopologyUser": "orchestrator_user",
  "MySQLTopologyPassword": "orchestrator_pass",

  "MySQLOrchestratorHost": "127.0.0.1",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orchestrator_user",
  "MySQLOrchestratorPassword": "orchestrator_pass",

  "RecoveryPeriodBlockSeconds": 3600,
  "RecoveryPollSeconds": 10,
  "RecoverMasterClusterFilters": [
    ".*"
  ],
  "PostMasterFailoverProcesses": [
    "sudo /usr/local/orchestrator/failover.sh {failedHost} {isSuccessful} {successorHost} {slaveHosts} >> /tmp/failover.log"
  ],
  "ApplyMySQLPromotionAfterMasterFailover": true
}

・ MySQLTopologyUser と MySQLTopologyPasswordがクラスター接続用のユーザ設定

・ MySQLOrchestratorUser と MySQLOrchestratorPasswordが情報保存用のユーザ設定

・ RecoveryPeriodBlockSeconds が一度フェイルオーバーが起こったあとに再度フェイルオーバー可能になるまでの時間

・ PostMasterFailoverProcesses にフェイルオーバー時に差し込む処理を記述出来ます

-> 今回はGCPのAliasIPの変更処理を /usr/local/orchestrator/failover.sh に記載しています

詳しくはConfigurationページ参照

4. 起動

省略

5. 監視するmysqlクラスターに接続用ユーザ作成

MySQLTopologyUser と MySQLTopologyPasswordで設定したユーザを監視クラスターのmysqlで作成

mysql> GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orchestrator_user'@'%' IDENTIFIED BY 'orchestrator_pass';
mysql> GRANT SELECT ON mysql.slave_master_info TO 'orchestrator_user'@'%';

6. webからmysqlクラスター登録

http://[orchestrator HOST]:3000/web/discover にアクセスしてクラスターマスターを入力するだけ(Enter host name)

するとレプリしているサーバも自動で検知してくれます。

もちろん複数クラスターを登録・監視することも可能です。

---

実際にフェイルオーバーを起こしてみる

mysqlのマスターを落とします。
するとマスターサーバはエラーとなり、スレーブだったサーバがマスターに昇格。
すぐにweb画面でもフェイルオーバーが確認出来ます。

またログも下記のように残っています。

---

まとめ

今回GCPでorchestratorの導入と実際にフェイルオーバーを起こしてみて接続が切り替わるかテストしてみました。導入は自身にmysqlが必要なので少し手間かもしれませんが、mysqlなどはよく使うのでコード化されていて問題ありません。それよりも監視対象にエージェントを入れなくてもよかったり、監視対象がwebで可視化されたり、Logが残ったりとメリットの方が大きいと感じました。フェイルオーバー時の処理も自由に挟み込めるので、環境に合わせて設定することが出来ます。今回はGCPで試しましたが、いろいろな環境に対応することが出来ますね。まだ本番環境には導入していませんが、今後MHAの代わりとして使用していきたいと思います。