DigiLoog

現行の自鯖機ではそれぞれのサーバ毎にDBを構築しているが、
今回の自鯖刷新を機にDBの集約化と構成変更も計る事にした。

パターンは色々あるが、今テストを行っているのは下記の通り

1. MariaDB + Replication + mysqlfailover
2. MariaDB + Replication + MaxScale
3. MariaDB Galera Cluster + Galera Arbitrator

現行維持で行くならば、レプリケーションを元にした構成になるが、
Galera Clusterを元にした構成も技術的に面白いので調査中。

ただし、クラスタ構成は3台以上の奇数構成を取らないと安定しない為、
“ns-lab BB”のサーバ構成になっているActive/Standbyとすると台数が足りなくなる。
その為、Arbitratorを何処かに構築して疑似的に奇数台数にする手があるのだが、
Arbitratorを使った構成例が極端に少なかったり、
そもそもドキュメントもお粗末な状況なので踏み切っていい物か手探り状態だったりする。

その為、MaxScaleを使った疑似リバプロ構成もテスト中。
久々に構成を大きく変更する事もあり、技術調査をしながら構築している為、
構成変更をブログに書くのは1ヶ月以上先になりそうだが何時か纏めようと思う。

自鯖のグローバルロードバランサ(GSLB)にはgdnsdとdnsdistを組み合わせつつ、
CloudGarageのVPS上に構築していたのだが、
元となるVPSサービス終了によって、何処かに引っ越す必要が出てきた (´・ω・｀)

何故にこの構成を取っていたかと言うと、GLSBを構築した時は通常の権威DNSと、
gdnsdを上手く同居させる術が無かった為、サーバを別立てしていた。
しかし、dnsdistをDNSロードバランサとして動かす事により、
DNSクエリの振り分けが出来る様になったので、権威DNSとGSLBの同居構成も可能となった。

という事でサーバ引越しの第一弾として、CloudGarageのVPSからGSLB切り離しを行いつつ、
“ns-lab BB”のInternet用権威DNSサーバに、グローバルロードバランサも合体させてみた。

“ns-lab”には様々な自宅サーバが稼働しているのだが、
その内の2台でClamAVが起動しなくなる事象が出た。
その2台は古めの仮想サーバホストに収容しており、
ClamAVが起動しきる前にsystemdによってdaemonをkillされている事が判った。

ClamAVはパターンファイルのサイズが肥大化しているので、
結果として起動時に読み込むパターンサイズも大きくなっている。
結果、起動する前にsystemdによってdaemonをkillされてしまい、
その後にsystemdによるservice再起動も重なる事で無限ループ状態に陥っていた。

対処は簡単で、systemd全体のタイムアウト時間を延ばすか、
ClamAVのサービスファイルに”TimeoutSec”を追記する。

こうする事で、TimeoutSecの時間はdaemonをkillせずに処理を待つ様になる。
ClamAVが起動しなくなる原因によるが、処理の遅いCPUを使っている場合には効果がある。