DigiLoog

前回の記事で自宅IPv6環境を刷新した事を書いたが、
ゲートウェイ設備にFortiGate 60Dを再利用していた。
NWトラフィックも順調に転送しているので刷新する気は無かったのだが、
RDNSSに対応していない事から、FortiGate配下のIPv6オンリー環境から、
Android端末を使えない課題が残った。

解決方法も判明しているし、しばらく放置する予定だったのだが、
日課のNW機器あさりをしていたら、v6.2.0を積んだFortiGate 50Eを発見
値段も手頃で「これも何かの縁」という事で買ってみた。

VDOM切っているので、5本のLANを接続。
ルーティングはOSPFとBGPを喋らせている。

自前でDHCPサーバを構築すると行ったら、ISC製のdhcpdを利用するのがセオリーな現状。
ただ、コレにも問題があり既に開発が終了している上、
設計が古い事から設定反映に再起動が必要な問題がある。

“ns-lab BB”もdhcpdを利用し続けていたのだが、
ビルドする為にソース改変が必要だったり、EUI-64に標準対応していなかったりと問題が多かったので、
自鯖刷新に合わせてkea-dhcpに移行する事とした。

従来、kea-dhcpはフェイルオーバーが実装されていなかったのだが、
Kea v1.4で実装されたので冗長化も図りやすくなった。
また、バックエンドを共通DBにしてしまえば、
ルータのhelper-addressに複数IPを記述する事で冗長化を図る事も出来る。

現在、IPv4環境用のkea-dhcpを構築したので実際に使ってテスト中。
近日中にIPv6環境用も構築し、両プロトコルで移行が出来るのか検証を進めつつ、
ある程度の構築ナレッジが溜まったらwikiにメモ予定。

老朽化した自宅サーバとサービス終了したCloudGarageからの引越し先として、
新サーバの構築を進めているのだが、内部データベースの構成をどうするかが課題だった。

当初、MariaDB Galera Clusterを利用しようと考えていたが、
安定稼働に必要なメモリ容量と、スプリットブレイン対策の奇数台数運用がネックだった。
また、DBが完全停止した時のサービス再起動にも細かい手順が必要だったり、
DBを本職としていない筆者には難易度が高すぎるのでお蔵入りになってしまった。

………

そうなると、レプリケーション構成が候補にあがるのだが、
こっちはこっちで、Master消失時にSlaveをMasterに自動昇格する方法が問題になった。
スクリプトを自作しても良かったが、日々のメンテナンスが辛くなりそうなので没に。
他に使えそうな物がないか調査した所、
MaxScaleを使うとクエリのロードバランスと自動昇格が出来る事が判明。

何処かのパブリッククラウド基盤にも採用していた筈で、稼働実績がありそうなのと、
MariaDB Galera Clusterの構成にMaxScaleも組み込まれている事が多いので、
今後の技術検証にも使えると判断し自鯖バックエンドDBに採用する事にした。