2019年11月30日(土) - 22:07 | カテゴリ:
Linux
老朽化した自宅サーバとサービス終了したCloudGarageからの引越し先として、
新サーバの構築を進めているのだが、内部データベースの構成をどうするかが課題だった。
当初、MariaDB Galera Clusterを利用しようと考えていたが、
安定稼働に必要なメモリ容量と、スプリットブレイン対策の奇数台数運用がネックだった。
また、DBが完全停止した時のサービス再起動にも細かい手順が必要だったり、
DBを本職としていない筆者には難易度が高すぎるのでお蔵入りになってしまった。
………
そうなると、レプリケーション構成が候補にあがるのだが、
こっちはこっちで、Master消失時にSlaveをMasterに自動昇格する方法が問題になった。
スクリプトを自作しても良かったが、日々のメンテナンスが辛くなりそうなので没に。
他に使えそうな物がないか調査した所、
MaxScaleを使うとクエリのロードバランスと自動昇格が出来る事が判明。
何処かのパブリッククラウド基盤にも採用していた筈で、稼働実績がありそうなのと、
MariaDB Galera Clusterの構成にMaxScaleも組み込まれている事が多いので、
今後の技術検証にも使えると判断し自鯖バックエンドDBに採用する事にした。
概要図は次の通り。フロントエンドにMaxScaleを動かして、
バックエンドのMariaDBにクエリを分散させる構成にした。
VirtualIPは慣れたVRRPを使いたかったので、KeepaliveでVRRP v3を喋る事にした。

典型的な構成なので枯れていると言えばそれまでだが、
バックエンドのMariaDBを自動で昇格・降格出来るのと、
サービスの接続先がMaxScaleに集約出来るので、
MaxScaleが落ちない限りはセッションが切れず、可用性がかなり高くなった。
実際にSELECTを送りながらバックエンドのMariaDBをダウンさせてみたが、
クエリ停止せずに処理を継続する事が出来た。
流石に、UPDATE系はフェールオーバーするまで通らない事があるが、
3秒程度で収束出来るので自鯖レベルならば大満足の結果に。
チューニングすれば更に可用性を上げられそうだが、
MaxScale本体に負荷がかかるのでバランスを見極める必要がありそう。
………
流石に、エンタープライズ環境だとこんな簡単には行かないが、
アップデート系をクラスタDB、参照系をリードレプリカに分散させれば、
高可用性と負荷分散を両立する事が出来る。
DBクラウド使えばそれまでだが、バックエンドの仕組みを把握するとアプリ構成も最適化出来るのと、
勉強の領域としてデータベースはやる事が多いので、今後もアップグレードしながらテストしようと思う。
« 続きを隠す
2019年11月09日(土) - 22:18 | カテゴリ:
Linux
現行の自鯖機ではそれぞれのサーバ毎にDBを構築しているが、
今回の自鯖刷新を機にDBの集約化と構成変更も計る事にした。
パターンは色々あるが、今テストを行っているのは下記の通り
- MariaDB + Replication + mysqlfailover
- MariaDB + Replication + MaxScale
- MariaDB Galera Cluster + Galera Arbitrator
現行維持で行くならば、レプリケーションを元にした構成になるが、
Galera Clusterを元にした構成も技術的に面白いので調査中。
ただし、クラスタ構成は3台以上の奇数構成を取らないと安定しない為、
“ns-lab BB”のサーバ構成になっているActive/Standbyとすると台数が足りなくなる。
その為、Arbitratorを何処かに構築して疑似的に奇数台数にする手があるのだが、
Arbitratorを使った構成例が極端に少なかったり、
そもそもドキュメントもお粗末な状況なので踏み切っていい物か手探り状態だったりする。
その為、MaxScaleを使った疑似リバプロ構成もテスト中。
久々に構成を大きく変更する事もあり、技術調査をしながら構築している為、
構成変更をブログに書くのは1ヶ月以上先になりそうだが何時か纏めようと思う。
2019年09月08日(日) - 20:41 | カテゴリ:
Linux
自鯖のグローバルロードバランサ(GSLB)にはgdnsdとdnsdistを組み合わせつつ、
CloudGarageのVPS上に構築していたのだが、
元となるVPSサービス終了によって、何処かに引っ越す必要が出てきた (´・ω・`)
何故にこの構成を取っていたかと言うと、GLSBを構築した時は通常の権威DNSと、
gdnsdを上手く同居させる術が無かった為、サーバを別立てしていた。
しかし、dnsdistをDNSロードバランサとして動かす事により、
DNSクエリの振り分けが出来る様になったので、権威DNSとGSLBの同居構成も可能となった。
という事でサーバ引越しの第一弾として、CloudGarageのVPSからGSLB切り離しを行いつつ、
“ns-lab BB”のInternet用権威DNSサーバに、グローバルロードバランサも合体させてみた。
全体の構成は下記の通り。ユーザクエリを待受ける一番外側にはdnsdistを採用してクエリログを採取。
クエリを都度分析してGSLB宛のクエリならばgdnsd、
それ以外のクエリはBINDに流し込む構成にしてみた。

構築手順はwikiに書いてあるので、この場では割愛。
この構成ならバックエンドへのクエリロードバランスが出来たり、
PowerDNSなど他の権威DNSサーバを組み合わせる事も出来るので重宝しそう。
試運転も兼ねて2週間ほど実クエリを捌き続けているのだが、
メモリ2GBの低スペックサーバでも問題無く稼働している。
クエリも、秒間100発程度なら余裕で捌けているので、
チューニング次第ではエンタープライズ用途でも利用出来そうだった。
dnsdistをエンタープライズで利用している事例はほぼ無いのだが、
BINDからの脱却として様々な権威DNSの研究が進んでいる昨今を考えると、
今後は上記の様なマルチアプリケーションを採用した権威DNSが出てくるのかもしれない。
« 続きを隠す